Обзор групп отработки отказа и рекомендации (База данных SQL Azure)

  • Статья

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

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

Чтобы приступить к работе с функцией, просмотрите группу отработки отказа.

Примечание.

В этой статье рассматриваются группы отработки отказа для База данных SQL Azure. Сведения о Управляемый экземпляр SQL Azure см. в разделе "Группы отработки отказа" в Управляемый экземпляр SQL Azure.

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

Обзор

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

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

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

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

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

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

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

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

Политика отработки отказа

Группы отработки отказа поддерживают две политики отработки отказа:

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

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

Политика отработки отказа Отработка отказа область Вариант использования Потенциальная потеря данных
Управляемый клиентом
(Рекомендуется)		 Группы отработки отказа Одна или несколько баз данных в группах отработки отказа влияют на сбой и становятся недоступными. Вы можете выполнить отработку отказа. Да
Организуется корпорацией Майкрософт Все группы отработки отказа в регионе Широко распространенная сбой в центре обработки данных, зоне доступности или регионе приводит к недоступности баз данных, а команда службы SQL Microsoft Azure решает активировать принудительное отработку отказа.
Используйте этот параметр только в том случае, если вы хотите делегировать ответственность по аварийному восстановлению корпорации Майкрософт, а приложение терпимо к RTO (простой) не менее одного часа или более.		 Да

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

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

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

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

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

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

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

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

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

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

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

  • Группа отработки отказа (FOG)

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

    Важно!

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

  • Серверы

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

  • Источник

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

  • Вторичные

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

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

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

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

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

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

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

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

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

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

    Важно!

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

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

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

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

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

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

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

    Примечание.

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

  • Несколько групп отработки отказа

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

Архитектура группы отработки отказа

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

Diagram shows a typical configuration of a geo-redundant cloud application using multiple databases and a failover group.

При проектировании службы с учетом непрерывности бизнес-процессов следуйте общим указаниям и рекомендациям, приведенным в этой статье. При настройке группы отработки отказа убедитесь, что проверка подлинности и сетевой доступ на получателе настроены и будут должным образом работать после отработки отказа с георепликацией, когда дополнительный экземпляр с георепликацией станет новым первичным экземпляром. Дополнительные сведения см. в разделе Безопасность базы данных 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 и состоит из нескольких компонентов. Отработка отказа группы активируется только на основе состояния базы данных SQL Azure. Сбой может не влиять на другие службы Azure в основном регионе, а их компоненты могут быть по-прежнему доступны в этом регионе. Когда базы данных-источники переключаются во вторичный регион (DR), задержка между зависимыми компонентами может увеличиться. Чтобы избежать влияния более продолжительных задержек на производительность приложения, обеспечьте избыточность всех компонентов приложения в регионе DR, следуя этим рекомендациям по защите сети, а также выполните оркестрацию отработки отказа с георепликацией соответствующих компонентов приложения вместе с базой данных.

Возможность потери данных после принудительной отработки отказа

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

Важно!

Эластичные пулы с 800 или менее DTU или 8 или меньше виртуальных ядер, а более 250 баз данных могут столкнуться с проблемами, включая более длительные геоотработки и снижение производительности. Эти проблемы чаще всего возникают из-за рабочих нагрузок, интенсивно записывающих данные, если геореплики физически находятся далеко друг от друга или если используется несколько дополнительных геореплик для каждой базы данных. Симптомом этих проблем является увеличение задержки георепликации с течением времени, что потенциально может привести к более масштабной потере данных в случае сбоя. Эту задержку можно отслеживать с помощью sys.dm_geo_replication_link_status. Если такие проблемы возникают, то меры по их устранению включают масштабирование пула для увеличения количества единиц передачи данных или виртуальных ядер, или уменьшение количества геореплицированных баз данных в пуле.

Восстановление размещения

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

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

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

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

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

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