Обзор групп аварийного переключения и наилучшие практики (База данных Azure SQL)

Применимо к: База данных SQL Azure

Функция групп переключения на резервный сервер позволяет управлять репликацией и переключением на резервный сервер некоторых или всех баз данных на одном логическом сервере в логический сервер в другом регионе. В этой статье представлен обзор функции группы автоматического переключения, с наилучшими методами и рекомендациями по использованию с базой данных Azure SQL.

Чтобы приступить к работе с функцией, просмотрите Настройка группы отказоустойчивости для базы данных Azure SQL Database.

Дополнительные сведения о аварийном восстановлении База данных SQL Azure см. в этом видео:

Обзор

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

Сведения о географическом отказоустойчивом переключении RPO и RTO см. в обзоре обеспечения непрерывности бизнеса.

Перенаправление конечных точек

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

Разгрузка рабочих нагрузок, доступных только для чтения

Чтобы снизить объем трафика к основным базам данных, можно также использовать вторичные базы данных в группе отработки отказа для переноса рабочих нагрузок, доступных только для чтения. Используйте прослушиватель, доступный только для чтения, чтобы направить трафик только для чтения в доступную вторичную базу данных.

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

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

Политика резервирования

Группы отказоустойчивости поддерживают две политики отказоустойчивости.

• Управляемый клиентом (рекомендуется). Клиенты могут выполнять переключение на резерв группы, когда они замечают непредвиденный сбой, влияющий на одну или несколько баз данных в группе переключения на резерв. При использовании таких средств командной строки, как PowerShell, Azure CLI или Rest API, значение политики отработки отказа для управляемого клиентом решения равно manual.
• Управляемый Майкрософт. В случае широкомасштабного сбоя, затрагивающего основной регион, корпорация Майкрософт инициирует переключение всех затронутых групп переключения при отказе, для которых политика переключения настроена как управляемая Майкрософт. Отказоустойчивость под управлением Microsoft не будет инициирована для отдельных групп фейловера или их подмножеств в регионе. При использовании таких средств командной строки, как PowerShell, Azure CLI или Rest API, значение политики отработки отказа для управляемых Корпорацией Майкрософт — automatic.

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

Управляемые клиентом

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

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

Организуется корпорацией Майкрософт

С помощью управляемой Майкрософт политики отработки отказа, ответственность за аварийное восстановление делегирована службе Azure SQL. Чтобы служба SQL Azure начала принудительное переключение, должны быть выполнены следующие условия:

• Затронуты неполадки центра обработки данных, зоны доступности или уровня региона, вызванные событием стихийных бедствий, изменениями конфигурации, ошибками программного обеспечения или аппаратными компонентами и многими базами данных в регионе.
• Льготный период истек. Так как проверка масштаба и устранение последствий сбоя зависит от человеческих действий, льготный период не может быть установлен ниже одного часа.

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

Установите политику отработки отказа корпорацией Майкрософт, управляемую только в следующих случаях:

• Вы хотите делегировать ответственность за аварийное восстановление службе SQL Azure.
• Приложение способно выдерживать недоступность базы данных в течение по крайней мере одного часа или более.
• Можно инициировать принудительный отказ системы через некоторое время после истечения льготного периода, так как фактическое время отказа может значительно варьироваться.
• Приемлемо, что все базы данных в группе аварийного переключения переключаются вне зависимости от конфигурации избыточности зоны или состояния доступности. Хотя базы данных, настроенные для избыточности зоны, устойчивы к зональным сбоям и могут не пострадать от них, они по-прежнему будут переведены на другой экземпляр, если входят в группу отработки отказа с политикой, управляемой компанией Microsoft.
• Допускается принудительная отработка отказа баз данных в группе отказоустойчивости без учета зависимости приложения от других компонентов или служб Azure, используемых этим приложением, что может привести к снижению производительности или недоступности приложения.
• Приемлемо допустить неизвестную степень потери данных, поскольку точное время принудительного переключения невозможно контролировать, и состояние синхронизации вторичных баз данных игнорируется.
• Все основные и вторичные базы данных в группе резервного переключения и все связи георепликации имеют одинаковые уровни обслуживания, вычислений (выделенные или бессерверные) и размер вычислительных ресурсов (DTU или виртуальные ядра). Если объектив уровня обслуживания (SLO) всех баз данных не совпадает, то политика резервного переключения будет со временем обновлена с управляемой Microsoft на управляемую заказчиком в службе Azure SQL.

Когда отработка отказа инициируется корпорацией Майкрософт, в журнал действий Azure Monitor добавляется запись для имени операции отработки отказа группы отказоустойчивости Azure SQL. Запись содержит имя группы отказа в Ресурс, а в Событие инициировано отображается дефис (-), чтобы указать, что отказ был инициирован корпорацией Майкрософт. Эту информацию также можно найти на странице журнала действий нового основного сервера или экземпляра в портале Azure.

Терминология и возможности

• Группа резервирования на случай отказа (FOG)

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

  Внимание

  Имя группы отказоустойчивости должно быть уникальным в глобальном масштабе в пределах домена .database.windows.net.

• Servers

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

• Основной

  Логический сервер, на котором размещаются основные базы данных в группе отработки отказа.

• Вторичные

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

• Отработка отказа (без потери данных)

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

  • Проведение тренировочных упражнений по аварийному восстановлению в рабочей среде, если потеря данных не допускается
  • Перемещение рабочей нагрузки в другой регион
  • Верните рабочую нагрузку в основной регион после устранения сбоя (восстановление размещения)

• Принудительное переключение на резерв (потенциальная потеря данных)

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

• Льготный период с потерей данных

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

• Добавление отдельных баз данных в группу аварийного переключения

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

  Внимание

  • Убедитесь, что на вторичном логическом сервере нет базы данных с тем же именем, если она не является существующей вторичной базой данных.
  • Если база данных содержит объекты OLTP, работающие в памяти, основная база данных и вторичная база данных с георепликой должны иметь одинаковые уровни обслуживания, так как эти объекты хранятся в оперативной памяти. Более низкий уровень обслуживания в геореплицируемой базе данных может привести к проблемам нехватки памяти. В этом случае георепликация может не восстановить базу данных, что приведет к недоступности вторичной базы данных, а также объектов OLTP в памяти на гео-вторичном сервере. Это, в свою очередь, может привести к неудачной отработке механизма переключения. Чтобы избежать этого, убедитесь, что уровень услуг гео-вторичной базы данных соответствует уровню базы данных-источника. Обновление уровня услуг может представлять собой операции, связанные с объемом данных, и может занять некоторое время.

• Добавление баз данных в эластичном пуле в группу отработки отказа

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

• Прослушиватель чтения и записи для группы отработки отказа

  Запись DNS CNAME, которая указывает на текущий основной. Он создается автоматически при создании группы отработки отказа и позволяет рабочим нагрузкам на чтение и запись прозрачно переподключаться к первичной базе данных, когда главная база данных меняется после отработки отказа. При создании группы отработки отказа на сервере для URL-адреса прослушивателя формируется CNAME-запись DNS следующего вида: <fog-name>.database.windows.net. После отработки отказа запись DNS автоматически обновляется для перенаправления прослушивателя на новый первичный объект.

• Только для чтения прослушиватель группы для обеспечения отказоустойчивости

  Запись CNAME DNS, которая указывает на текущий вторичный сервер. Он создается автоматически при создании группы автоматического переключения и позволяет рабочей нагрузке SQL только для чтения прозрачно подключаться к вторичному ресурсу, когда вторичный изменяется после отработки отказа. При создании группы отработки отказа на сервере запись DNS CNAME для URL-адреса прослушивателя формируется следующим образом: <fog-name>.secondary.database.windows.net. По умолчанию переключение на резервный канал для прослушивателя только для чтения отключено, так как это гарантирует, что производительность основного сервера не затрагивается, когда вторичный сервер находится в автономном режиме. Однако это также означает, что сеансы только для чтения не смогут подключаться, пока вторичный не будет восстановлен. Если вы не можете терпеть простой для сеансов только для чтения, а можете использовать основной сервер для трафика как только для чтения, так и для записи за счет возможного снижения его производительности, вы можете включить отработку отказа для слушателя только для чтения, настроив свойство AllowReadOnlyFailoverToPrimary. В этом случае трафик только для чтения автоматически перенаправляется на основной сервер, если вторичный сервер недоступен.

  Примечание.

  Свойство AllowReadOnlyFailoverToPrimary действует только в том случае, если включена управляемаm Майкрософтом политика отработки отказа и был инициирован принудительный отказ. В этом случае, если свойство имеет значение true, новый основной сервер будет обслуживать сеансы чтения и записи, а также сеансы только для чтения.

• Несколько групп переключения при отказе

  Вы можете настроить несколько групп отработки отказа для одной пары серверов, чтобы управлять масштабом отработок отказа с георепликацией. Каждая группа выполняет отработку отказа независимо от других групп. Если ваше приложение типа "клиент на базу данных" развернуто в нескольких регионах и использует эластичные пулы, вы можете воспользоваться этой возможностью, чтобы объединить базу данных-источник и базу данных-получатель в каждом пуле. Таким образом, вы можете уменьшить влияние сбоя только на некоторые базы данных клиента.

Архитектура группы резервирования

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

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

Использование сопряженных регионов

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

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

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

Начальное заполнение

При добавлении баз данных или эластичных пулов в группу автоматического переключения выполняется начальное заполнение перед началом репликации данных. Начальная фаза заполнения — это самая продолжительная и дорогостоящая операция. После завершения первоначального заполнения данные синхронизируются, а затем реплицируются только последующие изменения данных. Время завершения начального заполнения зависит от размера данных, количества реплицированных баз данных, нагрузки на базы данных-источника и скорости сетевой связи между первичной и вторичной базой данных. В нормальных обстоятельствах возможная скорость заполнения составляет до 500 ГБ в час для Базы данных SQL. Заполнение выполняется для всех баз данных в параллельном режиме.

Количество баз данных в группе переключения при отказе

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

• Во время переключения на резервный (также известного как плановое переключение), мы убеждаемся, что все основные базы данных полностью синхронизированы со своими вторичными копиями и достигают состояния готовности. Чтобы избежать перегрузки плоскости управления, базы данных подготавливаются в пакетах. Поэтому настоятельно рекомендуется ограничить количество баз данных в группе отказоустойчивости.
• В случае принудительного отказа этап подготовки ускоряется, так как синхронизация данных не инициируется. Чтобы добиться более быстрого и предсказуемого времени отработки отказа, может быть полезно сократить количество баз данных в группе отработки отказа на меньшее количество.

Используйте несколько групп отказоустойчивости для переключения нескольких баз данных.

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

Используйте прослушиватель чтения-записи (основной)

Для рабочих нагрузок для чтения и записи используйте в качестве имени сервера в строке подключения <fog-name>.database.windows.net. Подключения автоматически направляются к основному. Это имя не изменяется после переключения на резервный сервер. Обратите внимание, что переключение на резервный сервер включает в себя обновление DNS-записи, поэтому перенаправление клиентских подключений на новый первичный сервер произойдет только после обновления DNS-кэша клиента. Время жизни (TTL) основной и дополнительной записи DNS прослушивателя составляет 30 секунд.

Используйте слушатель в режиме только для чтения

Если у вас есть логически изолированные рабочие нагрузки, предназначенные для чтения и устойчивые к задержкам данных, вы можете запускать их на гео-вторичном экземпляре. Для сеансов только для чтения используйте в качестве имени сервера в строке подключения <fog-name>.secondary.database.windows.net. Подключения автоматически направляются на георезервную. Также рекомендуется указывать намерение чтения с помощью ApplicationIntent=ReadOnly в строке подключения.

В уровнях служб "Премиум", "Бизнес-критический" и "Гипермасштабирование" база данных SQL поддерживает использование реплик только для чтения для разгрузки рабочих нагрузок запросов с помощью параметра ApplicationIntent=ReadOnly в строке подключения. Если вы настроили гео-вторичный узел, вы можете использовать эту возможность для подключения к реплике только для чтения в основном месте или в гео-вторичном месте.

Для подключения к реплике только для чтения в резервном местоположении используйте ApplicationIntent=ReadOnly и <fog-name>.secondary.database.windows.net.

Возможная деградация производительности после перехода на резервный сервер

Типичное приложение Azure использует несколько служб Azure и состоит из нескольких компонентов. Отказ группы активируется исключительно на основе состояния базы данных Azure SQL. Сбой может не влиять на другие службы Azure в основном регионе, а их компоненты могут быть по-прежнему доступны в этом регионе. Когда базы данных-источники переключаются во вторичный регион (DR), задержка между зависимыми компонентами может увеличиться. Чтобы избежать влияния большей задержки на производительность приложения, обеспечьте резервирование всех компонентов приложения в регионе DR, следуя этим рекомендациям по защите сети, а также организуйте географическое резервирование соответствующих компонентов приложения вместе с базой данных.

Возможная потеря данных после принудительного переключения.

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

Возврат после отказа

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

Разрешения и ограничения

Ознакомьтесь с руководством по настройке группы аварийного переключения, чтобы получить список разрешений и ограничений.

Программное управление группами отказоустойчивости

Группами резервного переключения можно также управлять программно с помощью Azure PowerShell, Azure CLI и REST API. Дополнительные сведения см. в статье Настройка группы аварийного переключения для базы данных SQL Azure.

Включите высокую доступность (зональная избыточность)

Доступность благодаря избыточности улучшает устойчивость, защищая от сбоев в зоне доступности в пределах региона.

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

Избыточность зоны с базами данных без гипермасштабирования

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

Зональная избыточность с гипермасштабированием

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

Региональная поддержка зон доступности

В сценарии, когда высокая доступность включена в основной базе данных, а вторичная база данных находится в регионе, который еще не поддерживает зоны доступности, процесс завершится с ошибкой с кодом 45122: "Операция создания или обновления группы автоматического переключения успешно завершена; однако некоторые базы данных не могут быть добавлены в группу автоматического переключения или удалены из нее. Поддержка создания базы данных/пула с зональной избыточностью не предусмотрена для данного запроса. Чтобы обойти эту проблему, используйте Активную георепликацию, с помощью которой вы можете включить или отключить высокую доступность при создании вторичной базы данных. Затем вы можете по желанию добавить эти базы данных в группу для перехода на отказ.

Связанный контент

• Примеры скриптов см. в следующем разделе:
  • Настройка активной георепликации для базы данных SQL Azure с помощью PowerShell
  • Настройка активной георепликации для базы данных в пуле в Базе данных SQL Azure с помощью PowerShell
  • Используйте PowerShell для добавления базы данных Azure SQL в группу аварийного восстановления
• Сведения об обеспечении непрерывности бизнес-процессов и возможные сценарии описаны в обзоре непрерывности бизнес-процессов
• Чтобы узнать об автоматически создаваемых резервных копиях базы данных SQL Azure, ознакомьтесь с разделом Общие сведения об автоматическом резервном копировании базы данных SQL.
• Чтобы узнать об использовании автоматически создаваемых резервных копий для восстановления, ознакомьтесь с восстановлением базы данных из резервных копий, инициируемых службой.
• Дополнительные сведения о требованиях к проверке подлинности для новых сервера-источника и базы данных-источника см. в статье Безопасность базы данных SQL после аварийного восстановления.