Настройка аварийного восстановления для SQL Server

Статья
03/29/2023

В этой статье описывается, как защитить серверную часть SQL Server приложения. Это можно сделать, используя сочетание технологий непрерывности бизнес-процессов и аварийного восстановления (BCDR) SQL Server и Azure Site Recovery.

Прежде чем начать, убедитесь, что вы понимаете возможности аварийного восстановления SQL Server. Эти возможности включают:

Отказоустойчивая кластеризация
Группы доступности AlwaysOn
Зеркальное отображение базы данных
доставка журналов;
Активная георепликация
Группы автоматической отработки отказа

Объединение технологий BCDR с Site Recovery

Выбор технологии BCDR для восстановления экземпляров SQL Server должен делаться на основе целевого времени восстановления (RTO) и целевой точки восстановления (RPO), как описано в следующей таблице. Объедините Site Recovery с операцией отработки отказа выбранной технологии, чтобы управлять восстановлением всего приложения.

Тип развертывания	Технология BCDR	Ожидаемое RTO для SQL Server	Ожидаемая RPO для SQL Server
SQL Server на виртуальной машине (VM) в инфраструктуре как услуге (IaaS) Azure или в локальной среде.	Группы доступности AlwaysOn	Время, необходимое для того, чтобы сделать вторичную реплику первичной.	Так как репликация во вторичную реплику является асинхронной, возможна потеря некоторой части данных.
SQL Server на VM в IaaS Azure или в локальной среде.	Отказоустойчивая кластеризация (AlwaysOn FCI)	Время, необходимое для выполнения отработки отказа между узлами.	Так как FCI Always On использует общее хранилище, для отработки отказа доступно то же представление экземпляра хранилища.
SQL Server на VM в IaaS Azure или в локальной среде.	Зеркальное отображение базы данных (режим высокой производительности)	Время, необходимое для принудительного запуска службы, в котором зеркальный сервер используется в качестве резервного сервера.	Репликация выполняется асинхронно. Зеркальная база данных может несколько отставать от основной базы данных. Задержка обычно мала. Но она может стать больше, если система основного или зеркального сервера испытывает серьезную нагрузку. Доставка журналов может быть дополнением к зеркальному отображению базы данных. Это приемлемая альтернатива асинхронному зеркальному отображению базы данных.
SQL как платформа как услуга (PaaS) в Azure. Этот тип развертывания включает в себя отдельные базы данных и эластичные пулы.	Активная георепликация	30 секунд после активации отработки отказа. При активации отработки отказа для одной из баз данных-получателей все прочие получатели автоматически привязываются к новой базой данных-источнику.	RPO — пять секунд. Активная георепликация использует технологию Always On SQL Server. Она асинхронно реплицирует зафиксированные транзакции в базе данных-источнике в базу данных-получатель, используя изоляцию моментального снимка. Вторичные данные гарантированно никогда не будут иметь частичные транзакции.
SQL как PaaS, настроенный с активной георепликацией в Azure. Этот тип развертывания включает управляемые экземпляры, эластичные пулы и отдельные базы данных.	Группы автоматической отработки отказа	RTO — один час.	RPO — пять секунд. Группы автоматической отработки отказа обеспечивают семантику группы поверх активной георепликации. Но используется тот же механизм асинхронной репликации.
SQL Server на VM в IaaS Azure или в локальной среде.	Репликация с помощью Azure Site Recovery	RTO обычно менее 15 минут. Дополнительные сведения см. в разделе Соглашение об уровне обслуживания RTO, предоставляемое Site Recovery.	Один час для согласованности приложений и пять минут для отказоустойчивости. Если вы ищете более низкие значения RPO, используйте другие технологии BCDR.

Примечание.

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

Site Recovery не зависит от приложения. Site Recovery помогает защитить любую версию SQL Server, развернутую в поддерживаемой операционной системе. Дополнительные сведения см. в таблице поддержки для восстановления реплицированных компьютеров.
Вы можете использовать Site Recovery для любого развертывания в Azure, Hyper-V, VMware или физической инфраструктуре. Указания, приведенные в конце этой статьи, помогут защитить кластер SQL Server с помощью Site Recovery.
Убедитесь, что частота изменения данных на компьютере находится в пределах ограничений Site Recovery. Частота изменений измеряется в байтах, записанных в секунду. Для компьютеров под управлением Windows можно просмотреть эту частоту изменений, перейдя на вкладку Производительность в диспетчере задач. Обратите внимание на скорость записи для каждого диска.
Site Recovery поддерживает репликацию экземпляров отказоустойчивого кластера в Локальные дисковые пространства. Дополнительные сведения см. в разделе Включение репликации в Локальные дисковые пространства.

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

Аварийное восстановление приложения

Site Recovery организует тестовую отработку отказа и отработку отказа всего вашего приложения с помощью планов восстановления.

Для обеспечения полной настройки плана восстановления в соответствии с вашими требованиями необходимо выполнить некоторые предварительные условия. Для любого развертывания SQL Server обычно требуется развертывание Active Directory. Также требуется подключение к уровню приложения.

Шаг 1. Настройка Active Directory

Для правильной работы SQL Server на вторичном сайте восстановления необходимо настроить Active Directory.

Небольшое предприятие: у вас есть несколько приложений и один контроллер домена для локального сайта. Если вы хотите выполнять отработку отказа всего сайта, используйте репликацию Site Recovery. Эта служба реплицирует контроллер домена во вторичный центр обработки данных или в Azure.
Для средних и крупных предприятий. Вам может потребоваться настроить дополнительные контроллеры домена.
- Если у вас имеется большое количество приложений и лес Active Directory, то для выполнения отработки отказа для каждого отдельного приложения или рабочей нагрузки рекомендуется настроить дополнительный контроллер домена во вторичном центре обработки данных или в Azure.
- Если для восстановления удаленного сайта вы используете группы доступности Always On, настройте дополнительный контроллер домена на вторичном сайте или в Azure. Этот контроллер домена используется для восстановленного экземпляра SQL Server.

В инструкциях, которые приводятся в этой статье, предполагается, что контроллер домена доступен во вторичном расположении. Дополнительные сведения см. в описании процедур, помогающих защитить Active Directory с помощью Site Recovery.

Шаг 2. Обеспечение подключения к другим уровням

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

Чтобы понять, как следует проектировать приложения для обеспечения подключения, см. следующие примеры.

Шаг 3. Взаимодействие с Always On, активной георепликацией и группами автоматической отработки отказа

Технологии BCDR Always On, активная георепликация и группы автоматической отработки отказа имеют вторичные реплики SQL Server, выполняющиеся в целевом регионе Azure. Первым шагом для отработки отказа приложения является указание этой реплики в качестве основной. В этом шаге предполагается, что у вас уже есть контроллер домена на вторичном сайте. Если вы решили выполнить автоматическую отработку отказа, этот шаг может быть не нужен. Отработка отказа веб-уровня и уровня приложений выполняется только после завершения отработки отказа базы данных.

Примечание.

Если вы помогли защитить машины SQL с помощью Site Recovery, вам просто нужно создать группу восстановления для этих машин и добавить их отработку отказа в план восстановления.

Создайте план восстановления с виртуальными машинами уровня приложений и веб-уровня. Ниже показано, как добавить отработку отказа уровня базы данных.

Импортируйте скрипты для отработки отказа группы доступности SQL в виртуальной машине Resource Manager и классической виртуальной машине. Импортируйте скрипты в свою учетную запись службы автоматизации Azure.
Добавьте скрипт ASR-SQL-FailoverAG как предварительное действие первой группы плана восстановления.
Чтобы создать переменную автоматизации, следуйте инструкциям в этом скрипте. Эта переменная предоставляет имена групп доступности.

Шаг 4. Проведение тестовой отработки отказа

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

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

Действия по отработке отказа

После добавления скрипта в шаге 3 и его проверки в шаге 4 можно выполнить отработку отказа плана восстановления, созданного в шаге 3.

Шаги отработки отказа для уровня приложений и веб-уровня должны быть одинаковыми в плане тестовой отработки отказа и плане восстановления после отработки отказа.

Как обеспечить защиту кластера SQL Server

Для кластера под управлением SQL Server выпуска Standard или SQL Server 2008 R2 рекомендуется использовать репликацию Site Recovery, чтобы защитить SQL Server.

Из Azure в Azure и из локальной среды в Azure

Site Recovery не поддерживает гостевой кластер при репликации в регион Azure. SQL Server Standard также не предоставляет экономичное решение для аварийного восстановления. В этом сценарии рекомендуется защитить локальный кластер SQL Server с помощью автономного экземпляра SQL Server в основном расположении и его восстановления во вторичном расположении.

Настройте другой автономный экземпляр SQL Server в основном регионе Azure или на локальном сайте.
Настройте этот экземпляр в качестве зеркальной копии баз данных, которые требуется защитить. Настройте зеркальное отображение в режиме высокой безопасности.
Настройте Site Recovery на первичном сайте для виртуальных машин и физических серверов VMware, Azure или Hyper-V.
Используйте репликацию Site Recovery для репликации нового экземпляра SQL Server на дополнительный сайт. Так как это зеркальная копия с высокой безопасностью, она синхронизируется с основным кластером, но реплицируется с помощью репликации Site Recovery.

Часто задаваемые вопросы

Как лицензируется SQL Server при использовании с Site Recovery?

Репликация Site Recovery для SQL Server охватывается Преимуществом аварийного восстановления Software Assurance. Это покрытие применимо ко всем сценариям Site Recovery: от аварийного восстановления в локальной среде до Azure и аварийного восстановления Azure IaaS в разных регионах. Дополнительные сведения см. в разделеЦены на Azure Site Recovery.

Будет ли Site Recovery поддерживать мою версию SQL Server?

Site Recovery не зависит от приложения. Site Recovery помогает защитить любую версию SQL Server, развернутую в поддерживаемой операционной системе. Дополнительные сведения см. в таблице поддержки для восстановления реплицированных компьютеров.

Работает ли Azure Site Recovery с репликацией транзакций SQL?

Из-за использования Azure Site Recovery с помощью копирования на уровне файлов SQL sql не может гарантировать, что серверы в связанной топологии репликации SQL синхронизированы во время отработки отказа Azure Site Recovery. Это может привести к сбою агентов чтения журналов и (или) агентов распространения из-за несоответствия LSN, что может нарушить репликацию. При отработке отказа издателя, распространителя или подписчика в топологии репликации необходимо перестроить репликацию. Рекомендуется повторно инициализировать подписку на SQL Server.

Следующие шаги

Дополнительные сведения об архитектуре Site Recovery.
Дополнительные сведения о решениях высокой доступности для SQL Server в Azure, предназначенных для восстановления в дополнительном регионе Azure.
Дополнительные сведения о вариантах непрерывности бизнес-процессов и высокой доступности для восстановления Базы данных SQL в дополнительном регионе Azure.
Дополнительные сведения о вариантах высокой доступности для восстановления компьютеров SQL Server на виртуальных машинах Azure.

Поделиться через