Я немного погуглил и не смог найти ответ на этот вопрос более поздний, чем несколько лет назад, поэтому я решил спросить. Функция Oracle RAC обеспечивает балансировку нагрузки для операций чтения и записи, а также масштабирование и высокую доступность без простоев (по крайней мере, насколько я понимаю, - мы собираемся развернуть наши первые базы данных, использующие RAC, поэтому мы посмотрим как пойдет).
Существует ли какой-либо набор функций SQL Server (или сторонний компонент, который вы можете установить поверх), который обеспечивает эквивалентную функциональность? Мы всегда использовали кластеризацию Windows, где событие аварийного переключения вызывает примерно 20-30 секунд простоя SQL - всегда допустимо, но не идеально. Теперь, с AlwaysOn в SQL 2012, SQL Server сокращает это примерно до 15 секунд и добавляет концепцию вторичных баз данных, доступных только для чтения, но они все еще требуют, чтобы транзакции записи были забиты через одну точку соединения (значительно улучшено, поскольку многие транзакции просто прочитайте, но по-прежнему не распределяете нагрузку), а в случае сбоя узла или необходимости исправления время простоя остается.
Я предполагаю, что это просто больше любопытства - я чувствую, что это единственная область, в которой SQL Server отстает от Oracle (по крайней мере, среди функций, которые я лично видел). Я хотел посмотреть, есть ли какие-нибудь варианты, чтобы закрыть этот пробел и, возможно, улучшить наше собственное развертывание SQL Server, пока мы ждем, когда будет добавлена эквивалентная функция Microsoft - возможно, в SQL 2014/2015?
Ответы:
Нет, ничто в SQL Server не может дать вам то же самое из коробки .
В настоящее время единственной технологией SQL Server, позволяющей одновременную запись на нескольких узлах, является одноранговая репликация . Обратите внимание, что я не сказал «масштабирование при записи», потому что он работает таким образом, что вся система имеет емкость записи только одного узла. Вводный абзац этой страницы тщательно сформулирован, чтобы включить термин «масштабирование», не говоря «писать масштабирование». Уя за маркетинг-говори.
Из того, что я прочитал , Oracle RAC в этом отношении одинаков. Функционально единственное, чего не хватает в SQL Server в этой конфигурации, - это решение для балансировки нагрузки, которое является как преимуществом (вы можете реализовать его любым удобным способом), так и недостатком (его нет в комплекте или не поддерживается Microsoft), когда сравнивая с конкурирующими продуктами.
И наоборот, Oracle RAC не дает вам того же, что и SQL Server , из коробки . Например, рекомендуется использовать RAC с узлами в пределах 100 км друг от друга из-за задержки сети в реальном времени, тогда как для репликации между равноправными узлами такого ограничения нет. (Я не говорю, что одно решение лучше другого: я просто указываю, что они разные. Бизнес должен выбрать решение, которое лучше всего соответствует их конкретным потребностям.)
источник
Я администратор баз данных, поддерживающий 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, стоимость будет только увеличиваться.
источник
Прямой ответ на ваш вопрос - нет, SQL Server не имеет эквивалентной функциональности. Существуют аспекты SQL Server, которые обеспечивают требуемый уровень отказоустойчивости (даже в SQL Server 2005 при использовании зеркалирования БД и приложения, поддерживающего зеркалирование), но с Oracle RAC нет 1: 1.
источник
Лучшим сравнением AlwaysOn была бы функция Data Guard от Oracle. Активно-пассивная кластеризация. (да, вы можете читать из режима ожидания, но он доступен только для чтения, поэтому активен только один узел ")
Oracle RAC - это совершенно другое животное и активно-активная кластеризация. Я не видел никаких шагов, если Microsoft когда-либо захочет реализовать это.
источник
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-подобных возможностей без изменений в приложении.
источник