Планирование аварийного восстановления службы хранилища Azure и отработка отказа

  • Статья

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

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

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

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

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

Восстановление одной копии учетной записи хранения происходит автоматически с помощью LRS и ZRS.

Глобально избыточное хранилище и отработка отказа

С глобально избыточным хранилищем (GRS, GZRS и RA-GZRS) Azure копирует данные асинхронно в дополнительный географический регион по крайней мере сотни миль. Это позволяет восстановить данные при сбое в основном регионе. Функция, которая отличает глобально избыточное хранилище от LRS и ZRS, — возможность отработки отказа в дополнительный регион, если в основном регионе произошел сбой. Процесс отработки отказа обновляет записи DNS для конечных точек службы учетной записи хранения, чтобы конечные точки для дополнительного региона стали новыми основными конечными точками для учетной записи хранения. После завершения отработки отказа клиенты могут начать запись в новые первичные конечные точки.

Конфигурации избыточности RA-GRS и RA-GZRS предоставляют геоизбыточное хранилище с дополнительным преимуществом доступа на чтение к вторичной конечной точке, если в основном регионе произошел сбой. Если в основной конечной точке возникает сбой, приложения, настроенные для доступа на чтение к дополнительному региону и предназначенные для обеспечения высокой доступности, могут продолжать читаться из вторичной конечной точки. Корпорация Майкрософт рекомендует RA-GZRS для обеспечения максимальной доступности и устойчивости учетных записей хранения.

Дополнительные сведения об избыточности в службе хранилища Microsoft Azure см. в статье Избыточность в службе хранилища Azure.

Планирование отработки отказа учетной записи хранения

учетные записи служба хранилища Azure поддерживают два типа отработки отказа:

  • Отработка отказа, управляемой клиентом, — клиенты могут управлять отработой отказа учетной записи хранения при неожиданном сбое службы.
  • Отработка отказа, управляемого корпорацией Майкрософт, потенциально инициируется корпорацией Майкрософт только в случае серьезной аварии в основном регионе. 1,2

1Отработка отказа, управляемого корпорацией Майкрософт, не может быть инициирована для отдельных учетных записей хранения, подписок или клиентов. Дополнительные сведения см. в статье об отработки отказа, управляемой корпорацией Майкрософт.
2 План аварийного восстановления должен основываться на отработки отказа, управляемой клиентом. Не полагаться на отработку отказа, управляемой корпорацией Майкрософт, которая будет использоваться только в чрезвычайных обстоятельствах.

Каждый тип отработки отказа имеет уникальный набор вариантов использования, соответствующие ожидания потери данных и поддержку учетных записей с включенным иерархическим пространством имен (Azure Data Lake Storage 2-го поколения). В этой таблице перечислены аспекты каждого типа отработки отказа:

Тип Область отработки отказа Вариант использования Ожидаемая потеря данных Поддерживаемые HNS
управляемые пользователем Storage account Конечные точки службы хранилища для основного региона становятся недоступными, но дополнительный регион доступен.

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

Отработка отказа, управляемая клиентом

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

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

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

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

Внимание

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

Прогнозирование потери данных и несоответствий

Внимание

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

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

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

Новый основной регион настроен на локально избыточность (LRS) после отработки отказа.

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

Время последней синхронизации

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

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

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

Согласованность файлов для Azure Data Lake Storage 2-го поколения

Репликация учетных записей хранения с включенным иерархическим пространством имен (Azure Data Lake Storage 2-го поколения) происходит на уровне файла. Это означает, что если происходит сбой в основном регионе, возможно, что только некоторые файлы в контейнере или каталоге могли успешно реплика в дополнительный регион. Согласованность всех файлов в контейнере или каталоге после отработки отказа учетной записи хранения не гарантируется.

Несоответствия данных канала изменений и больших двоичных объектов

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

Сведения о том, как работает веб-канал изменений, см. в разделе "Как работает веб-канал изменений".

Помните, что другие функции учетной записи хранения требуют включения канала изменений, например оперативного резервного копирования Хранилище BLOB-объектов Azure, восстановления объектов реплика и восстановления точек во времени для блочных BLOB-объектов.

Несоответствия восстановления на определенный момент времени

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

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

Время и стоимость отработки отказа

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

Отработка отказа, управляемая клиентом, теряет геоизбыточное значение после отработки отказа (и восстановления размещения). Учетная запись хранения автоматически преобразуется в локально избыточное хранилище (LRS) в новом основном регионе во время отработки отказа, а учетная запись хранения в исходном основном регионе удаляется.

Вы можете повторно включить геоизбыточное хранилище (GRS) или геоизбыточное хранилище (RA-GRS) для учетной записи, но обратите внимание, что преобразование из LRS в GRS или RA-GRS несет дополнительную стоимость. Плата взимается за исходящий сетевой трафик для повторной репликации данных в новый дополнительный регион. Кроме того, перед настройкой учетной записи для геоизбыточности все архивные BLOB-объекты необходимо восстановить на онлайн-уровне, что приведет к затратам. Дополнительные сведения о ценах см. в следующем разделе:

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

  • Число и размер объектов в учетной записи хранения. Репликация множества небольших объектов может занять больше времени, чем реплика, что меньше и больше объектов.
  • Доступные ресурсы для фоновой репликации, такие как ЦП, память, диск и пропускная способность WAN. Динамический трафик имеет приоритет над георепликацией.
  • Если учетная запись хранения содержит большие двоичные объекты, количество моментальных снимков для каждого большого двоичного объекта.
  • Если учетная запись хранения содержит таблицы, стратегия секционирования данных. Процесс репликации не может масштабироваться сверх количества используемых ключей разделов.

Поддерживаемые типы учетных записей хранения

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

Тип отработки отказа Учетная запись GZRS или RA-GZRS
Отработка отказа, управляемая клиентом Учетные записи общего назначения версии 2
Учетные записи общего назначения версии 1
Устаревшие учетные записи Хранилища BLOB-объектов		 Учетные записи общего назначения версии 2.
Отработка отказа, управляемая корпорацией Майкрософт Все типы учетных записей Учетные записи общего назначения версии 2.

Классические учетные записи хранения

Внимание

Отработка отказа управляемых клиентом учетных записей поддерживается только для учетных записей хранения, развернутых с помощью модели развертывания Azure Resource Manager (ARM). Модель развертывания Azure Service Manager (ASM), которая также называется классической, не поддерживается. Чтобы сделать классические учетные записи хранения подходящими для отработки отказа управляемых клиентом учетных записей, сначала их необходимо перенести в модель ARM. Учетная запись хранения должна быть доступна для выполнения обновления, поэтому основной регион в настоящее время не может находиться в состоянии сбоя.

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

Azure Data Lake Storage 2-го поколения

Внимание

Отработка отказа управляемой клиентом учетной записи для учетных записей с иерархическим пространством имен (Azure Data Lake Storage 2-го поколения) в настоящее время доступна в предварительной версии и поддерживается только в следующих регионах:

  • "Центральная Индия" (Азиатско-Тихоокеанский регион);
  • (Азиатско-Тихоокеанский регион) Юго-Восточная Азия
  • "Северная Европа" (Европа);
  • Северная Швейцария (Европа)
  • (Европа) Западная Швейцария
  • "Западная Европа" (Европа).
  • (Северная Америка) Центральная Канада;
  • (Северная Америка) Восточная часть США 2;
  • (Северная Америка) Центрально-южная часть США;

Чтобы войти в предварительную версию, ознакомьтесь с разделом "Настройка предварительных версий функций в подписке Azure" и указание AllowHNSAccountFailover в качестве имени функции.

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

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

Неподдерживаемые функции и службы

Для отработки отказа учетной записи не поддерживаются следующие функции и службы:

  • Синхронизация файлов Azure не поддерживает отработку отказа, инициированной клиентом учетной записи хранения. служба хранилища учетные записи, содержащие общие папки Azure, используемые в качестве облачных конечных точек в Синхронизация файлов Azure, не должны быть отработки отказа. Это приведет к прекращению синхронизации или даже к непредвиденной потере данных, если некоторые файлы недавно стали многоуровневыми. Дополнительные сведения см. в рекомендациях по аварийному восстановлению с помощью Синхронизация файлов Azure подробных сведений.
  • Не удается выполнить отработку отказа учетной записи хранения, содержащей BLOB-объекты класса Premium. служба хранилища учетные записи, поддерживающие blob-объекты блоков premium, в настоящее время не поддерживают геоизбыточность.
  • Отработка отказа, управляемого клиентом, не поддерживается для исходной или целевой учетной записи в политике реплика tion объекта.
  • Чтобы выполнить отработку отказа учетной записи с включенным протоколом SFTP, необходимо сначала отключить SFTP для учетной записи. Если вы хотите возобновить использование SFTP после завершения отработки отказа, просто повторно включите его.
  • Сетевая файловая система (NFS) 3.0 (NFSv3) не поддерживается для отработки отказа учетной записи хранения. Вы не можете создать учетную запись хранения, настроенную для глобальной избыточности с включенным NFSv3.

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

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

служба хранилища учетные записи, содержащие архивированные BLOB-объекты

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

Поставщик ресурсов хранилища

Корпорация Microsoft предоставляет два интерфейса API для работы с ресурсами службы хранилища Azure. Эти API образуют базу для всех действий, которые можно выполнять с хранилищем Azure. REST API службы хранилища Azure позволяет работать с данными в учетной записи хранения, включая данные больших двоичных объектов, очередей, файлов и таблиц. Поставщик ресурсов службы хранилища Azure REST API позволяет управлять учетной записью хранения и связанными ресурсами.

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

Так как поставщик ресурсов хранилища Microsoft Azure не выполняет отработку отказа, свойство Location возвратит исходное первичное расположение после завершения перехода на другой ресурс.

Виртуальные машины Azure

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

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

Неуправляемые диски Azure

Корпорация Майкрософт рекомендует преобразовать все неуправляемые диски в управляемые диски. Тем не менее, если вам потребуется отработка отказа учетной записи, которая содержит неуправляемые диски, подключенные к виртуальным машинам Azure, перед выполнением такой отработки отказа вам придется завершить работу виртуальной машины.

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

  1. Перед началом отработки отказа запишите имена всех неуправляемых дисков, их логические номера устройств (LUN) и имена виртуальных машин, к которым они подключены. Это упростит восстановление подключений после отработки отказа.
  2. Выключите виртуальную машину.
  3. Удалите виртуальную машину, сохраняя файлы VHD для неуправляемых дисков. Зафиксируйте время удаления виртуальной машины.
  4. Дождитесь, пока параметр Время последней синхронизации будет содержать более позднее время, чем время удаления виртуальной машины. Этот шаг важен, так как если вторичная конечная точка не была полностью обновлена с VHD-файлами при отработке отказа, виртуальная машина может работать неправильно в новом основном регионе.
  5. Запустите отработку отказа учетной записи.
  6. Дождитесь, пока отработка отказа учетной записи завершится, и дополнительный регион станет новым основным регионом.
  7. Создайте виртуальную машину в новом основном регионе и присоедините к ней виртуальные жесткие диски.
  8. Запустите новую виртуальную машину.

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

Копирование данных вместо отработки отказа

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

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

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

Имейте в виду следующие рекомендации по поддержанию высокого уровня доступности для данных служба хранилища Azure:

  • Диски: используйте Azure Backup для резервного копирования дисков, используемых виртуальными машинами Azure. Кроме того, рекомендуется использовать Azure Site Recovery для защиты виртуальных машин в случае региональной аварии.
  • Блочные BLOB-объекты: включите обратимое удаление, чтобы предотвратить удаление и перезапись на уровне объектов, или скопируйте блочные BLOB-объекты в другую учетную запись хранения, относящуюся к другому региону, с помощью AzCopy, Azure PowerShell или библиотеки перемещения данных Azure.
  • Файлы: используйте Azure Backup для резервного копирования файловых ресурсов. Также включите обратимое удаление, чтобы защититься от случайного удаления файловых ресурсов. Для геоизбыточности, если GRS недоступен, используйте AzCopy или Azure PowerShell для копирования файлов в другую учетную запись хранения в другом регионе.
  • Таблицы. Используйте AzCopy для экспорта данных из таблиц в другую учетную запись хранения, относящуюся к другому региону.

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

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

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

См. также