Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Управляемая клиентом плановая отработка отказа может оказаться полезной в таких сценариях, как планирование аварийного восстановления и тестирование, упреждающее исправление ожидаемых крупномасштабных аварий и сбоев, не связанных с хранилищем данных.
Во время процесса плановой отработки отказа основные и вторичные регионы учетной записи хранилища переключаются. Первоначальный первичный регион понижается и становится новым вторичным, в то время как первоначальный вторичный регион повышается и становится новым первичным. Учетная запись хранения должна быть доступна как в первичных, так и во вторичных регионах, прежде чем может быть инициировано плановое переключение при отказе.
В этой статье описывается, что происходит на каждом этапе управляемого клиентом планируемого переключения и восстановления. Сведения о том, как происходит переключение на резервный канал из-за непредвиденного сбоя конечной точки хранилища, см. в источнике Управление клиентом (незапланированное переключение) на резервный канал.
Управление отказоустойчивостью во время планового перехода на резерв и возврата
Совет
Подробные сведения о различных состояниях отказоустойчивости во время процесса отработки отказа и восстановления работоспособности, управляемого клиентом, см. в статье избыточность Azure Storage, где приведены определения каждого из них.
Во время плановой отработки отказа конечные точки службы хранения данных основного региона переводятся в режим только для чтения, в то время как оставшиеся обновления завершают репликацию в вторичный регион. Затем переключаются все записи службы доменных имен (DNS) конечной точки службы хранилища. Вторичные конечные точки учетной записи хранения становятся новыми основными конечными точками, а исходные первичные конечные точки становятся новыми вторичными. Репликация данных в каждом регионе остается неизменной, даже когда основные и вторичные регионы переставляются.
Запланированный процесс возврата по сути совпадает с процессом планового переключения на резерв, но с одним исключением. Во время планируемого возврата Azure сохраняет исходную конфигурацию избыточности вашей учетной записи хранилища и восстанавливает её в исходное состояние при возврате. Например, если ваша учетная запись хранения была изначально настроена как GZRS, она будет GZRS после возврата.
Примечание.
В отличие от переключения отказа, управляемого клиентом (незапланированного), во время планового переключения отказа репликация из основного во вторичный регион должна быть завершена до того, как записи DNS для конечных точек будут изменены на новую вторичную зону. Из-за этого потеря данных не ожидается во время плановой отработки отказа или возврата к исходному состоянию до тех пор, пока первичные и вторичные регионы доступны на протяжении всего процесса.
Как инициировать переключение на резерв
Сведения о том, как инициировать отказ учетной записи, см. в статье "Запуск отказа учетной записи".
Запланированный процесс переключения при сбое и возврата после сбоя
На следующих схемах показано, что происходит во время управляемого клиентом планового отказа и восстановления учетной записи хранения.
В обычных условиях клиент записывает данные в учетную запись хранения в основном регионе с помощью конечных точек службы хранилища (1). Затем данные копируются асинхронно из основного региона в дополнительный регион (2). На следующем рисунке показано обычное состояние учетной записи хранения, настроенной как GRS:
Плановый процесс переключения (GRS/RA-GRS)
Начните тестирование аварийного восстановления, переключив ваш аккаунт хранения на вторичный регион. Ниже описаны шаги в процессе планируемого перехода на резервный узел, а на следующем изображении представлена схема.
Учетная запись хранения в обоих основной и вторичном регионе временно потеряет доступ на чтение и запись.
Репликация всех данных из основного региона в дополнительный регион завершается.
DNS-записи конечных точек службы хранения в вторичном регионе продвигаются и становятся новыми основными точками для вашей учетной записи хранения.
Переключение на резервный режим обычно занимает около часа.
После завершения переключения на резервный узел исходный основной регион становится новым вторичным (1), а исходный вторичный регион становится новым основным (2). URI для конечных точек службы хранилища для больших двоичных объектов, таблиц, очередей и файлов остаются неизменными, но их записи DNS изменяются, чтобы указать на новый первичный регион (3). Пользователи могут возобновить запись данных в учетную запись хранения в новом основном регионе, а затем данные затем копируются асинхронно в новый дополнительный (4), как показано на следующем рисунке:
В состоянии отработки отказа выполните тестирование аварийного восстановления.
Примечание.
Служба Azure Files поддерживает соединения, сохраняющие состояние, что означает, что приложениям может потребоваться перемонтировать общие папки или перезапустить после отказа системы для продолжения доступа к данным.
Запланированный процесс возврата к основному состоянию (GRS/RA-GRS)
После завершения тестирования выполните еще одно переключение на резервную площадку и возврат в исходный основной регион. В процессе переключения, как показано на следующем рисунке:
Учетная запись хранения в обоих основной и вторичном регионе временно потеряет доступ на чтение и запись.
Все данные завершают репликацию из текущего основного региона в текущий вторичный регион.
Записи DNS для точек доступа службы хранилища изменяются, чтобы указать на регион, который был основным до переноса нагрузки в случае отказа.
Откат обычно занимает около часа.
После завершения возврата на исходную конфигурацию учетная запись хранения восстанавливаецца до исходной конфигурации избыточности. Пользователи могут возобновить запись данных в учетную запись хранения в исходном основном регионе (1), при этом репликация на исходную вторичную (2) продолжается как до отказа.
