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

Аварийное восстановление и отработка отказа для Файлы Azure

  • Статья

Корпорация Майкрософт стремится непрерывно поддерживать доступность служб Azure. Однако незапланированные сбои служб могут возникнуть, и у вас должен быть план аварийного восстановления (АВАРИЙНОго восстановления) для обработки сбоя региональной службы. Важной частью плана аварийного восстановления является подготовка к отработке отказа на вторичную конечную точку в случаях, когда основная конечная точка станет недоступной. В этой статье описываются основные понятия и процессы, связанные с аварийного восстановления (аварийного восстановления) и отработкой отказа учетной записи хранения.

Внимание

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

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

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

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

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

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

Внимание

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

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

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

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

Внимание

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

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

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

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

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

Метрики восстановления и затраты

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

  • Сколько данных может позволить себе потерять в случае сбоя (цель точки восстановления или RPO)
  • Как быстро она должна быть в состоянии восстановить бизнес-функции и данные (цель восстановления или RTO)

Стоимость аварийного восстановления обычно увеличивается с меньшим или нулевым RPO/RTO. Компании, которые должны работать и работать в течение нескольких секунд после аварии и не могут поддерживать потери данных, будут платить больше за аварийное восстановление, в то время как те, с более высокими номерами RPO/RTO будут платить меньше. Azure предоставляет решения, которые могут работать с различными требованиями RPO и RTO.

Выбор правильного уровня избыточности

Файлы Azure предлагает различные варианты избыточности для защиты данных от запланированных и незапланированных событий, начиная от временных сбоев оборудования, сетевых сбоев и сбоев питания до стихийных бедствий. Все общие папки Azure могут использовать локально избыточное хранилище (LRS) или хранилище, избыточное между зонами (ZRS). Дополнительные сведения см. в разделе Файлы Azure избыточности.

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

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

Внимание

GRS/GZRS не поддерживаются для общих папок Azure класса Premium. Однако вы можете синхронизировать между двумя общими папками Azure для обеспечения географической избыточности.

Учет высокого уровня доступности при проектировании

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

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

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

Отслеживание сбоев

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

Сведения о процессе отработки отказа учетной записи

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

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

Процесс отработки отказа учетной записи

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

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

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

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

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

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

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

Внимание

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

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

Подготовка к потерям данных

Внимание

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

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

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

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

Проверка свойства "Время последней синхронизации"

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

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

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

Можно запросить значение свойства времени последней синхронизации с помощью Azure PowerShell, Azure CLI или клиентской библиотеки. Свойство Время последней синхронизации содержит значение даты и времени по Гринвичу (в формате GMT). Дополнительные сведения см. в разделе Проверка свойства "Время последней синхронизации" для учетной записи хранения.

Соблюдайте осторожность при возврате на исходную основную конечную точку

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

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

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

По завершении операции восстановления размещения можно снова настроить географическую избыточность для нового основного региона. Если исходный основной объект настроен для LRS, его можно настроить для GRS. Если исходный основной объект настроен для ZRS, его можно настроить для GZRS. Сведения о дополнительных вариантах см. в разделе Изменение способа репликации для учетной записи хранения.

Инициирование отработки отказа учетной записи

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

Отработка отказа, управляемая корпорацией Майкрософт

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

См. также