Как работает управляемый клиентом плановая отработка отказа (предварительная версия)

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

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

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


Внимание

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

  • Центральная Франция
  • Южная Франция
  • Центральная Индия
  • Западная Индия
  • Восточная Азия
  • Юго-Восточная Азия

Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.

Чтобы войти в предварительную версию, ознакомьтесь с разделом "Настройка предварительных версий функций в подписке Azure" и указание AllowSoftFailover в качестве имени функции. Имя поставщика для этой предварительной версии — Microsoft.Storage.

Внимание

После плановая отработка отказа значение последней синхронизации (LST) учетной записи хранения может отображаться устаревшим или отображаться как NULL при наличии данных Файлы Azure.

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

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

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

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

Управление избыточностью во время плановая отработка отказа и восстановления размещения

Совет

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

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

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

Примечание.

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

Как инициировать отработку отказа

Сведения о том, как инициировать отработку отказа, см. в статье "Запуск отработки отказа учетной записи".

Процесс плановая отработка отказа и восстановления размещения

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

В обычных условиях клиент записывает данные в учетную запись хранения в основном регионе с помощью конечных точек службы хранилища (1). Затем данные копируются асинхронно из основного региона в дополнительный регион (2). На следующем рисунке показано обычное состояние учетной записи хранения, настроенной как GRS:

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

Процесс плановая отработка отказа (GRS/RA-GRS)

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

  1. Исходный основной регион становится доступным только для чтения.
  2. Репликация всех данных из основного региона в дополнительный регион завершается.
  3. Записи DNS для конечных точек службы хранилища в дополнительном регионе повышаются и становятся новыми основными конечными точками для учетной записи хранения.

Отработка отказа обычно занимает около часа.

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

После завершения отработки отказа исходный основной регион становится новым вторичным (1), а исходный дополнительный регион становится новым первичным (2). URI для конечных точек службы хранилища для больших двоичных объектов, таблиц, очередей и файлов остаются неизменными, но их записи DNS изменяются, чтобы указать на новый первичный регион (3). Пользователи могут возобновить запись данных в учетную запись хранения в новом основном регионе, а затем данные затем копируются асинхронно в новый дополнительный (4), как показано на следующем рисунке:

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

В состоянии отработки отказа выполните аварийное восстановление.

Запланированный процесс восстановления размещения (GRS/RA-GRS)

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

  1. Исходный основной регион становится доступным только для чтения.
  2. Все данные завершают репликацию из текущего основного региона в текущий дополнительный регион.
  3. Записи DNS для конечных точек службы хранилища изменяются, чтобы указать на регион, который был основным до выполнения первоначальной отработки отказа.

Восстановление размещения обычно занимает около часа.

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

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

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

См. также