Предполагая, что вам необходимо убедиться, что ваше приложение, которое использует SQL Server 2012 в качестве бэкэнда базы данных, доступно круглосуточно, даже в случае сбоя одного из серверов.

Как разработчик, а не администратор баз данных, я пытаюсь понять, когда использовать какой сценарий для моей отказоустойчивости / высокой доступности:

• Два (или более) сервера в отказоустойчивом кластере Windows, SQL Server в качестве кластерного экземпляра
• Два (или более) экземпляра SQL Server, которые обновляются с помощью репликации транзакций
• Два (или более) SQL-сервера в группе доступности SQL-сервера, настроенные в режиме синхронного принятия

Какой из этих сценариев подходит для какой рабочей нагрузки, и какой тип отказа / сбоя может быть обработан этими сценариями? Они даже сопоставимы / заменяемы?

Мне всегда нравится визуализировать решения высокой доступности:

Экземпляр отказоустойчивого кластера SQL Server (FCI)

Что высоко доступно? Весь экземпляр. Сюда входят все объекты сервера (имена входа, задания агента SQL Server и т. Д.). Это также включает базы данных и содержащие их объекты. Это отличное решение для высокодоступных экземпляров SQL Server, потому что это будет уровень сдерживания с данным решением.

Как насчет отчетности? Нет, NULL, не существует. Экземпляр отказоустойчивого кластера имеет активный узел, доставляющий группу кластеров, содержащую этот экземпляр, VNN и т. Д., А все остальные узлы пассивны, находятся в режиме ожидания (что касается текущей группы кластеров) и ожидают переключения при сбое.

Что происходит, когда происходит аварийное переключение? Время простоя для FCI будет определяться количеством времени, которое пассивному узлу требуется для захвата ресурса кластера и перевода экземпляра SQL Server в рабочее состояние. Это обычно минимально по времени.

Любая клиентская абстракция? Да, это будет встроено в имя виртуальной сети для экземпляра отказоустойчивого кластера. Это всегда будет указывать на активный узел, который в данный момент доставляет ресурс кластера SQL Server.

Группы доступности AlwaysOn

Что высоко доступно? Группа доступности будет здесь логическим сдерживанием высокой доступности, тогда как группа доступности состоит из нескольких баз данных и имени виртуальной сети (слушатель, необязательный ресурс кластера). Стоит отметить, что объекты сервера, такие как учетные записи и задания агента SQL Server, не будут частью решения высокой доступности, и необходимо принять особые меры для обеспечения их правильной реализации с группой доступности. Не слишком обременительное требование, но о нем нужно заботиться.

Как насчет отчетности? Это отличное решение для создания отчетов, хотя я, вероятно, не буду использовать синхронную реплику в качестве экземпляра отчетов. Существует два отношения фиксации, синхронные и асинхронные. По моему мнению и из того, что я видел на практике, ваша вторичная синхронная реплика находится там в ожидании катастрофы. Думайте об этом как о той реплике, которая готова принять аварийное переключение без потери данных в случае возникновения проблемы. Затем существуют асинхронные реплики, которые могут обрабатывать эту рабочую нагрузку. Вы не используете эту реплику в качестве вышеупомянутого решения, но в большей степени для таких вещей, как отчетность. Отчеты о рабочих нагрузках могут быть направлены на эту реплику (напрямую или косвенно через маршрутизацию только для чтения через слушателя).

Что происходит, когда происходит аварийное переключение? Для вторичной реплики синхронной фиксации, которая связана с автоматическим переключением при сбое, это будет изменение состояния роли реплики с SECONDARY_NORMAL на PRIMARY_NORMAL. Для того чтобы происходил автоматический переход на другой ресурс, вам необходимо иметь синхронную вторичную реплику, которая в настоящий момент синхронизирована, и в ней реализована гибкая политика перехода на другой ресурс, чтобы определить, когда на самом деле должно происходить это переключение. Эта политика действительно настраивается.

Любая клиентская абстракция? Да, вы можете дополнительно настроить прослушиватель группы доступности AlwaysOn. По сути, это просто имя виртуальной сети (может рассматриваться через WSFC как ресурс кластера в группе кластеров AG), которое указывает на текущую первичную реплику. Это ключевая часть перемещения рабочей нагрузки по отчетам, а также настройки списка маршрутизации только для чтения на любых серверах, на которые вы хотите перенаправлять трафик ReadOnly (это задается через строку подключения с помощью поставщика .NET Framework для SQL Сервер, это будет параметр Application Intent , установленный на ReadOnly ). Вам также необходимо установить URL-адрес маршрутизации только для чтения для каждой реплики, для которой вы хотите получать эту рабочую нагрузку создания отчетов, находясь в роли вторичной реплики.

Транзакционная репликация

Что высоко доступно? Это спорно, но я собираюсь сказать ничего . Я не рассматриваю репликацию как решение высокой доступности. Да, изменения данных передаются подписчикам, но мы говорим на уровне публикации / статьи. Это будет подмножество данных (может включать в себя все данные, но оно не будет применено. Т.е. вы создаете новую таблицу в базе данных издателя, и она не будет автоматически отправляться подписчикам). Что касается HA, то это «дно», и я не буду группировать его там с надежным решением HA.

Как насчет отчетности? Отличное решение для составления отчетов по подмножеству данных, без сомнений. Если у вас есть база данных объемом 1 ТБ с высокой транзакционной нагрузкой, и вы хотите сохранить эту рабочую нагрузку отчетов вне базы данных OLTP, репликация транзакций является отличным способом передачи подмножества данных подписчику (или подписчикам) для рабочей нагрузки отчетности. Что произойдет, если из этого 1 ТБ данных ваша рабочая нагрузка составляет всего около 50 ГБ? Это разумное решение, которое можно настроить в соответствии с потребностями вашего бизнеса.

Резюме

То, к чему это сводится, является горсткой вопросов, на которые нужно ответить (частично бизнесом):

1. Что должно быть доступно ?
2. Что SLA диктует для HA / DR?
3. Какого рода отчетность будет осуществляться и какие задержки допустимы?
4. Что нам нужно делать с географически распределенной ГА? (Репликация хранилища стоит дорого, но обязательно с FCI. AGs не требуют общего хранилища от автономных экземпляров, и вы можете использовать свидетеля общего файлового ресурса для кворума, что потенциально устраняет необходимость в общем хранилище)

два (или более) сервера в отказоустойчивом кластере Windows, SQL Server в качестве кластерного экземпляра

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

2. Минусы / Проблемы - Единственная точка отказа - это ваше хранилище и все его компоненты. Поставщики SAN всегда говорят «SAN не выходят из строя», но в сети хранения данных есть много движущихся частей, и, как я уже писал здесь , они могут. Кроме того - вы платите за дополнительный сервер, который не может ничего делать, кроме как зависать и ждать. Теперь вы можете сделать Active / Active / Multi-Node и иметь два активных экземпляра, которые могут переключаться при сбое в любом направлении и использовать второй узел.

3. Автоматический отказоустойчивый? «Самый» автоматический. Свидетель не нужен, это кластер. Это работа кластера, чтобы сделать его как можно более плавным. Теперь с любым из них, когда происходит аварийное переключение, вы «почувствуете» это, потому что SQL должен запускаться или соединения должны указывать. Здесь, когда это происходит, вы, по сути, чувствуете, что перезапускаете SQL, базы данных возвращаются и запускают восстановление и т.д.

Если у меня есть клиент, который говорит: «Я хочу полностью использовать все базы данных, все имена входа и т. Д.» В среде высокой доступности в моем локальном центре обработки данных, поскольку у меня невероятно низкий допуск на время простоя, я бы рассмотрел экземпляры отказоустойчивого кластера (хотя последний вариант, о котором вы упомянули, является сильным соперником, за исключением того, что приходится делать некоторые накладные расходы на управление). Я бы, вероятно, сделал локальный FCI и дополнительный асинхронный AG для защиты от сбоя сайта или SAN.

два (или более) экземпляра SQL Server, которые обновляются с помощью репликации транзакций

1. Какой вид нагрузки? Честно говоря, я бы не стал использовать это в качестве первого варианта для обеспечения высокой доступности или аварийного восстановления. Не в SQL 2012 точно. Но в основном это хорошо, если вам приходилось ходить в дата-центр, который не был близко, вы не могли использовать AG (может быть, проблема домена, мешающая вам использовать кластер Windows, необходимый для AG), возможно, вы хотели быть в стандарте SQL Server, который может выполнять репликацию, но не AG, но вы все еще хотели иметь возможность читать на вторичной стороне и быть асинхронными.
2. Минусы / Проблемы - это репликация. Это связано с накладными расходами, оно может быть не синхронизировано, у вас могут возникнуть проблемы с производительностью на стороне источника и т. Д.
3. Автоматический отказоустойчивость - Нет. Вы должны справиться с этим самостоятельно. Либо через CNAME, которые указывают на одно или другое, и вы можете теоретически написать свой собственный процесс для этого, но из коробки? Обратите внимание здесь.

два (или более) SQL-сервера в группе доступности SQL-сервера, настроенные в режиме синхронного принятия

Это то, что я помогаю людям внедрять все больше и больше в последнее время, хотя иногда я все еще иду к кластеризации.

1. Какой вид нагрузки? Это замечательно, когда у меня есть управляемый набор баз данных для синхронизации, а также ресурсы и время, чтобы обеспечить синхронизацию заданий, имен входа, новых баз данных и т. Д. (Хотя команда SQL Skills создала отличное дополнение к автоматизировать некоторые из них для вас, что делает его еще более сильным вариантом). Мне нравится это, когда я хочу держать вещи совершенно отдельно. Я защищаю от аппаратных проблем, проблем ОС, проблем установки SQL, исправлений и проблем SAN / Storage. Я также получаю возможность иметь вторичное (если я хочу заплатить за него корпоративную лицензию) активное вторичное устройство, с которого я могу читать, делать резервные копии и т. Д. Кроме того, в будущем я могу добавить треть вторичный, асинхронный на удаленном сайте и имеющий аварийное переключение / DR.
2. Минусы / Проблемы Лицензирование, максимальное количество реплик, затраты на лицензирование, чтобы воспользоваться некоторыми из самых больших преимуществ (активные вторичные), требует предприятия, требует вдвое больше памяти, чем кластеризация.
3. Автоматический отказоустойчивость - да. Это может произойти при установке свидетеля, и разработчики вашего приложения могут подключиться к слушателю, а не к узлу, поэтому аварийное переключение происходит с тем местом, куда указывает слушатель, и вам должно быть хорошо там. Так что да, вы можете сделать это здесь - и должны - но, конечно, вы должны проверить это хорошо.

Резюме

HA и DR разные. И эти технологии помогают обеспечить части либо. Высокая доступность означает (для меня), что вы можете быстро восстановиться, если с одной машиной произойдет что-то плохое, у вас короткая цель восстановления и время восстановления. Это кластеризация и синхронный АГ.

Аварийное восстановление - это «вы можете встать, если у вас есть сбой даже в вашем решении высокой доступности. Для меня это могут быть AG, когда вы переходите в другой центр обработки данных, зеркалирование или даже репликацию».

Также важно учитывать, что является общим .

Отказоустойчивая кластеризация использует два или более серверных узла, совместно использующих один дисковый массив. Если дисковый массив выходит из строя, то вы теряете обслуживание, независимо от того, сколько существует серверных узлов. Если серверная комната, где расположен этот дисковый массив, загорается или затопляется, то вы теряете обслуживание.

Группы доступности AlwaysOn и зеркальное отображение базы данных - это технология кластеризации, в которой нет общего доступа. База данных присутствует в нескольких дисковых массивах на нескольких серверах. Если у вас хорошие сетевые соединения, то несколько серверов могут находиться в нескольких серверных комнатах, защищая вас от пожаров и наводнений.

Просто для полноты, есть возможность использования простого старого зеркалирования. Преимущества здесь включают наличие двух копий базы данных без сложности использования групп доступности и без необходимости общего хранилища для отказоустойчивой кластеризации. Недостатком, хотя и незначительным, является то, что зеркалирование не рекомендуется.

Время отработки отказа с зеркальным отображением составляет порядка 10 секунд, хотя код приложения должен иметь возможность повторять любые транзакции, которые происходят во время отработки отказа.