SQL Server эквивалентен функциональности Oracle RAC? [закрыто]


11

Я немного погуглил и не смог найти ответ на этот вопрос более поздний, чем несколько лет назад, поэтому я решил спросить. Функция Oracle RAC обеспечивает балансировку нагрузки для операций чтения и записи, а также масштабирование и высокую доступность без простоев (по крайней мере, насколько я понимаю, - мы собираемся развернуть наши первые базы данных, использующие RAC, поэтому мы посмотрим как пойдет).

Существует ли какой-либо набор функций SQL Server (или сторонний компонент, который вы можете установить поверх), который обеспечивает эквивалентную функциональность? Мы всегда использовали кластеризацию Windows, где событие аварийного переключения вызывает примерно 20-30 секунд простоя SQL - всегда допустимо, но не идеально. Теперь, с AlwaysOn в SQL 2012, SQL Server сокращает это примерно до 15 секунд и добавляет концепцию вторичных баз данных, доступных только для чтения, но они все еще требуют, чтобы транзакции записи были забиты через одну точку соединения (значительно улучшено, поскольку многие транзакции просто прочитайте, но по-прежнему не распределяете нагрузку), а в случае сбоя узла или необходимости исправления время простоя остается.

Я предполагаю, что это просто больше любопытства - я чувствую, что это единственная область, в которой SQL Server отстает от Oracle (по крайней мере, среди функций, которые я лично видел). Я хотел посмотреть, есть ли какие-нибудь варианты, чтобы закрыть этот пробел и, возможно, улучшить наше собственное развертывание SQL Server, пока мы ждем, когда будет добавлена ​​эквивалентная функция Microsoft - возможно, в SQL 2014/2015?


1
Я не уверен, что SQL Server действительно сильно отстает от Oracle. Да, у него есть функция, которой нет у SQL Server, но обязательно вернитесь к этой теме после того, как вы запустили ее в течение нескольких месяцев, и сообщите нам, все ли это розы или нет. :-) У меня тоже нет опыта, но коллегам, у которых не всегда есть что сказать по этому поводу.
Аарон Бертран

2
Также я надеюсь, что вы не ожидаете каких-либо точных предположений о возможностях в будущих версиях SQL Server. Те, кто знает, есть ли такие функции на этапе планирования, не могут сказать вам; те, кто не может сказать вам тоже. :-)
Аарон Бертран

1
@AaronBertrand: Справедливо, я не ожидаю каких-либо предположений о возможностях, так как понимаю, что это будет не совсем точно. Хотя AlwaysOn является улучшением (в некоторых случаях), у меня были большие надежды на то, что он будет более точно дублировать функциональность RAC и заполнит этот пробел. На мой взгляд, MSSQL делает некоторые вещи лучше, чем Oracle, но это одна из областей, где Oracle, по моему мнению, держит эстафету.
SqlRyan

1
@ rwmnau еще раз, я предлагаю вам похвалить RAC, пока вы не внедрили его и не использовали его в течение нескольких месяцев. :-) Возможно, ты прав; это может быть все, что он обещает и идеально подходит для вас. Но вы можете быть озадачены блестящим блеском на коробке. :-)
Аарон Бертран

2
@AaronBertrand: Ха, точка взята. Я слышал ряд критических замечаний, таких как то, что он слишком чувствителен к задержке в сети и быстро высвобождает узлы и тому подобное, поэтому я определенно придерживаюсь общего суждения до тех пор, пока мы не развернем его, и я использовал его не понаслышке , SQL Server, хотя и имеет несколько опций HA, похоже, не перемещается в пространство «множественный доступный для записи интерфейс». Может быть, я собираюсь выяснить причину почему :)
SqlRyan

Ответы:


8

Нет, ничто в SQL Server не может дать вам то же самое из коробки .

В настоящее время единственной технологией SQL Server, позволяющей одновременную запись на нескольких узлах, является одноранговая репликация . Обратите внимание, что я не сказал «масштабирование при записи», потому что он работает таким образом, что вся система имеет емкость записи только одного узла. Вводный абзац этой страницы тщательно сформулирован, чтобы включить термин «масштабирование», не говоря «писать масштабирование». Уя за маркетинг-говори.

Из того, что я прочитал , Oracle RAC в этом отношении одинаков. Функционально единственное, чего не хватает в SQL Server в этой конфигурации, - это решение для балансировки нагрузки, которое является как преимуществом (вы можете реализовать его любым удобным способом), так и недостатком (его нет в комплекте или не поддерживается Microsoft), когда сравнивая с конкурирующими продуктами.

И наоборот, Oracle RAC не дает вам того же, что и SQL Server , из коробки . Например, рекомендуется использовать RAC с узлами в пределах 100 км друг от друга из-за задержки сети в реальном времени, тогда как для репликации между равноправными узлами такого ограничения нет. (Я не говорю, что одно решение лучше другого: я просто указываю, что они разные. Бизнес должен выбрать решение, которое лучше всего соответствует их конкретным потребностям.)


1
Основная причина в 100 км заключается в том, что Oracle остается ACID-совместимым между узлами - им нужно общаться друг с другом через высокоскоростное соединение, и скорость света становится проблемой. SQL Server в аналогичной конфигурации распространяет изменения, и вы можете получить конфликты на уровне строк, если два узла обновляют одну и ту же строку в течение определенного периода времени - не ACID - ни одной базы данных. Набор экземпляров RAC - это одна база данных, и это различие.
Philᵀᴹ

@Phil: Да, это была моя точка зрения - они разные.
Джон Зигель

6

Я администратор баз данных, поддерживающий SQL 2000-2012, Oracle 11g и Oracle 11g RAC.

IMO, группы Always On Availability в SQL 2012 очень близки к доступности и масштабируемости RAC при гораздо меньших затратах, как в долларах, так и в плане сложности. Вы можете масштабировать чтения, выполняя запросы к зеркалам, но вы хотите перенаправить весь DML на основной сервер (зеркала SQL Server не могут быть обновлены). В случае сбоя основного SQL Server переключение на одно из зеркал происходит практически мгновенно. RAC испытывает аналогичную паузу, если происходит сбой узла, когда незафиксированные транзакции на отказавшем узле откатываются оставшимся в живых узлом.

Самым большим преимуществом (IMHO) SQL 2012 AAAG перед RAC является то, что это архитектура без общего доступа. RAC разделяет хранилище. Если это не удается, весь кластер не работает. Это огромный SPOF в RAC, о котором все, кажется, забывают. Если вы хотите защитить себя от этого, вам нужно настроить резервный сервер. Если вы хотите, чтобы это был RAC, стоимость будет только увеличиваться.


1
Хороший вопрос о SPOF RAC.
СтэнлиДжонс

5

Прямой ответ на ваш вопрос - нет, SQL Server не имеет эквивалентной функциональности. Существуют аспекты SQL Server, которые обеспечивают требуемый уровень отказоустойчивости (даже в SQL Server 2005 при использовании зеркалирования БД и приложения, поддерживающего зеркалирование), но с Oracle RAC нет 1: 1.


1

Лучшим сравнением AlwaysOn была бы функция Data Guard от Oracle. Активно-пассивная кластеризация. (да, вы можете читать из режима ожидания, но он доступен только для чтения, поэтому активен только один узел ")

Oracle RAC - это совершенно другое животное и активно-активная кластеризация. Я не видел никаких шагов, если Microsoft когда-либо захочет реализовать это.


-2

SQL Server 2012/2014 с AlwaysOn добавляет множество возможностей, которые приближают вас к Oracle RAC, а в некоторых случаях улучшают его. (Вспомните, что с RAC вам необходимо использовать сервер приложений Oracle, weblogic и JDBC - плюс работать в одном центре обработки данных, и приложение может подключаться только к одному кластеру RAC - общее хранилище означает, что RAC не работает в облаке) ,

С AlwaysOn вы получаете второстепенные только для чтения (4 в 12, 8 в 14) и поддержку автоматического перехода на другой ресурс. Однако есть несколько сложностей: AlwaysOn не поддерживает балансировку нагрузки - если вы не напишите сценарий, он всегда будет отображать первый сервер в списке. Отказоустойчивость также влияет на приложение - оно не прозрачно, поэтому приложения могут быть перезапущены.

Полное раскрытие - я работаю в компании, которая делает программное обеспечение, которое дополняет AlwaysOn. Наш программный интерфейс для балансировки нагрузки на базу данных SQL Server - он выполняет разделение на чтение и запись от имени приложения, выполняет балансировку нагрузки на основе времени отклика, охватывающую центры обработки данных, и ставит в очередь входящие записи / транзакции во время отработки отказа, чтобы приложения не видели ошибок , Посмотрите, как Microsoft, Dell, Quicken Loans и другие предприятия используют программное обеспечение ScaleArc для расширения SQL Server AlwaysOn и получения RAC-подобных возможностей без изменений в приложении.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.