Аварийное восстановление и отработка отказа для Файлы Azure
Корпорация Майкрософт стремится непрерывно поддерживать доступность служб Azure. Однако незапланированные сбои служб могут возникнуть, и у вас должен быть план аварийного восстановления (АВАРИЙНОго восстановления) для обработки сбоя региональной службы. Важной частью плана аварийного восстановления является подготовка к отработке отказа на вторичную конечную точку в случаях, когда основная конечная точка станет недоступной. В этой статье описываются основные понятия и процессы, связанные с аварийного восстановления (аварийного восстановления) и отработкой отказа учетной записи хранения.
Внимание
Синхронизация файлов Azure поддерживает отработку отказа только учетной записи хранения, если служба синхронизации служба хранилища также выполняет отработку отказа. Это связано с тем, что Синхронизация файлов Azure требует, чтобы учетная запись хранения и служба синхронизации служба хранилища были в одном регионе Azure. Если только учетная запись хранения выполняется отработка отказа, синхронизация и операции по уровням облака завершаются сбоем, пока служба синхронизации служба хранилища не будет отработка отказа в дополнительный регион. Если вы хотите выполнить отработку отказа учетной записи хранения, содержащей общие папки Azure, которые используются в качестве облачных конечных точек в Синхронизация файлов Azure, Синхронизация файлов Azure ознакомьтесь с рекомендациями по аварийному восстановлению Синхронизация файлов Azure сервера.
Метрики восстановления и затраты
Чтобы сформулировать эффективную стратегию аварийного восстановления, организация должна понимать следующее:
- Сколько данных может позволить себе потерять в случае сбоя (цель точки восстановления или 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 приложений с высоким уровнем доступности.
- Контрольный список устойчивости: контрольный список, позволяющий проверить соблюдение в приложении передовых рекомендаций по разработке для обеспечения высокой доступности.
- Используйте геоизбыточное использование для разработки высокодоступных приложений: руководство по созданию приложений для использования геоизбыточного хранилища для общих папок S МБ.
Мы также рекомендуем разработать приложение для подготовки к возможному сбою записи. Приложение должно информировать о сбоях при записи, чтобы вы своевременно получали сведения о возможных сбоях в основном регионе.
Рекомендуется разработать приложение, чтобы проверка свойству времени последней синхронизации, чтобы оценить ожидаемую потерю данных. Например, если вы регистрируете все операции записи, то можно сравнить время последних операций записи с временем последней синхронизации, чтобы определить, какие записи не были синхронизированы с дополнительным.
Отслеживание сбоев
Вы можете подписаться на панель мониторинга работоспособности служб 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. Дополнительные сведения о запуске отработки отказа учетной записи вы найдете в статье Запуск отработки отказа учетной записи.
Отработка отказа, управляемая корпорацией Майкрософт
В чрезвычайных обстоятельствах, когда регион теряется из-за значительной аварии, корпорация Майкрософт может инициировать региональную отработку отказа. В этом случае никаких действий не требуется. До завершения отработки отказа под управлением корпорации Майкрософт вы не получите доступ на запись к учетной записи хранения.