Планирование аварийного восстановления службы хранилища Azure и отработка отказа
Корпорация Майкрософт стремится непрерывно поддерживать доступность служб Azure. Однако иногда могут возникать незапланированные сбои служб. Ключевые компоненты хорошего плана аварийного восстановления включают стратегии:
- Защита данных
- Резервное копирование и восстановление
- Избыточность данных
- Тип отработки отказа
- Проектирование приложений для обеспечения высокой доступности
В этой статье описаны варианты, доступные для геоизбыточных учетных записей хранения, а также рекомендации по разработке высокодоступных приложений и тестированию плана аварийного восстановления.
Выбор правильного уровня избыточности
служба хранилища Azure поддерживает несколько копий учетной записи хранения, чтобы обеспечить выполнение целевых показателей доступности и устойчивости даже в случае сбоев. Способ репликации данных обеспечивает различные уровни защиты. Каждый вариант предлагает свои собственные преимущества, поэтому выбранный вариант зависит от степени устойчивости приложений.
Локально избыточное хранилище (LRS), вариант избыточности с наименьшей стоимостью, автоматически сохраняет и реплицирует три копии учетной записи хранения в одном центре обработки данных. Хотя LRS защищает данные от сбоев стойки сервера и диска, он не учитывает такие аварии, как пожар или наводнение в центре обработки данных. В случае таких аварий все реплики учетной записи хранения, настроенной для использования LRS, могут быть потеряны или неустранимы.
По сравнению с хранилищем, избыточное между зонами (ZRS), сохраняет копию учетной записи хранения и реплицирует ее в каждом из трех отдельных зон доступности в одном регионе. Дополнительные сведения о зонах доступности см . в разделе "Зоны доступности Azure".
Геоизбыточное хранилище и отработка отказа
Геоизбыточное хранилище (GRS), геозонное избыточное хранилище (GZRS) и геоизбыточное хранилище с доступом для чтения (RA-GZRS) являются примерами географически избыточного хранилища. При настройке использования геоизбыточного хранилища (GRS, GZRS и RA-GZRS) Azure копирует данные асинхронно в дополнительный географический регион. Эти регионы находятся сотни или даже тысячи миль от него. Этот уровень избыточности позволяет восстановить данные, если в основном регионе произошел сбой.
В отличие от LRS и ZRS, геоизбыточное хранилище также обеспечивает поддержку un плановая отработка отказа в дополнительный регион, если в основном регионе произошел сбой. Во время отработки отказа записи DNS (системы доменных имен) для конечных точек службы учетной записи хранения автоматически обновляются таким образом, чтобы конечные точки дополнительного региона стали новыми основными конечными точками. После завершения плановая отработка отказа клиенты могут начать запись в новые первичные конечные точки.
Геоизбыточное хранилище с доступом на чтение (RA-GRS) и геоизбыточное хранилище (RA-GZRS) для чтения также предоставляют геоизбыточное хранилище, но обеспечивают дополнительный доступ на чтение к вторичной конечной точке. Эти варианты идеально подходят для приложений, предназначенных для приложений с высоким уровнем доступности, критически важных для бизнеса. Если основная конечная точка испытывает сбой, приложения, настроенные для доступа на чтение к дополнительному региону, могут продолжать работать. Корпорация Майкрософт рекомендует RA-GZRS для обеспечения максимальной доступности и устойчивости учетных записей хранения.
Дополнительные сведения о избыточности для служба хранилища Azure см. в разделе служба хранилища Azure избыточности.
Планирование отработки отказа
учетные записи служба хранилища Azure поддерживают три типа отработки отказа:
- Управляемые клиентом плановая отработка отказа (предварительная версия) — клиенты могут управлять отработки отказа учетной записи хранения для тестирования плана аварийного восстановления.
- Отработка отказа, управляемая клиентом (внеплановая) — клиенты могут управлять отработки отказа учетной записи хранения, если произошел непредвиденный сбой службы.
- Отработка отказа, управляемого корпорацией Майкрософт, потенциально инициированная корпорацией Майкрософт из-за серьезной аварии в основном регионе. 1,2
1 Отработка отказа, управляемого корпорацией Майкрософт, не может быть инициирована для отдельных учетных записей хранения, подписок или клиентов. Дополнительные сведения см. в статье Отработка отказа под управлением корпорации Майкрософт.
2 . Используйте управляемые клиентом варианты отработки отказа для разработки, тестирования и реализации планов аварийного восстановления. Не полагаться на отработку отказа, управляемой корпорацией Майкрософт, которая будет использоваться только в чрезвычайных обстоятельствах.
Каждый тип отработки отказа имеет уникальный набор вариантов использования, соответствующие ожидания потери данных и поддержку учетных записей с включенным иерархическим пространством имен (Azure Data Lake Storage). В этой таблице перечислены аспекты каждого типа отработки отказа:
| Тип | Область отработки отказа | Вариант использования | Ожидаемая потеря данных | Поддерживаемое иерархическое пространство имен (HNS) |
|---|---|---|---|---|
| Управляемые клиентом плановая отработка отказа (предварительная версия) | Storage account | Доступны конечные точки службы хранилища для основных и вторичных регионов, и вы хотите выполнить аварийное восстановление. Доступны конечные точки службы хранилища для основного региона, но другая служба предотвращает правильное функционирование рабочих нагрузок. Чтобы заранее подготовиться к крупномасштабным бедствиям, таким как ураган, это может повлиять на регион. |
Нет | Да (В предварительной версии) |
| Отработка отказа, управляемого клиентом (незапланированная) | Storage account | Конечные точки службы хранилища для основного региона становятся недоступными, но дополнительный регион доступен. Вы получили рекомендации Azure, в которых корпорация Майкрософт советует выполнять отработку отказа учетных записей хранения, потенциально затронутых сбоем. |
Да | Да (В предварительной версии) |
| управляемый Майкрософт | Весь регион | Основной регион становится недоступным из-за значительной аварии, но дополнительный регион доступен. | Да | Да |
В следующей таблице сравнивается состояние избыточности учетной записи хранения после каждого типа отработки отказа:
| Результат отработки отказа на... | Управляемые клиентом плановая отработка отказа (предварительная версия) | Отработка отказа, управляемого клиентом (незапланированная) |
|---|---|---|
| ... дополнительный регион | Дополнительный регион становится новым первичным | Дополнительный регион становится новым первичным |
| ... исходный основной регион | Исходный основной регион становится новым вторичным | Копия данных в исходном основном регионе удаляется |
| ... Конфигурация избыточности учетной записи | Учетная запись хранения преобразуется в GRS | Учетная запись хранения преобразуется в LRS |
| ... конфигурация геоизбыточности | Геоизбыточное хранение | Геоизбыточность потеряна |
В следующей таблице приводится сводка результирующей конфигурации избыточности на каждом этапе процесса отработки отказа и восстановления размещения для каждого типа отработки отказа:
| Исходный текст настройка |
После отработка отказа |
После повторного включения геоизбыточность |
После восстановление размещения |
После повторного включения геоизбыточность |
|---|---|---|---|---|
| Управляемые клиентом плановая отработка отказа | ||||
| GRS | GRS | n/a1 | GRS | n/a1 |
| GZRS | GRS | n/a1 | GZRS | n/a1 |
| Отработка отказа, управляемого клиентом (незапланированная) | ||||
| GRS | LRS | GRS | LRS | GRS |
| GZRS | LRS | GRS | ZRS | GZRS |
1 Геоизбыточность сохраняется во время плановая отработка отказа и не требуется вручную перенастроить.
Управляемые клиентом плановая отработка отказа (предварительная версия)
Плановая отработка отказа может использоваться в нескольких сценариях, включая запланированное тестирование аварийного восстановления, упреждающий подход к крупномасштабным авариям или восстановление после неиспользуемых сбоев.
Во время плановая отработка отказа процесса первичные и вторичные регионы переключаются. Исходный первичный регион понижен и становится новым дополнительным регионом. В то же время исходный вторичный регион продвигается и становится новым первичным. После завершения отработки отказа пользователи могут перейти к данным в новом основном регионе, а администраторы могут проверить свой план аварийного восстановления. Учетная запись хранения должна быть доступна как в основных, так и в дополнительных регионах, прежде чем плановая отработка отказа может быть инициирована.
Потеря данных не ожидается во время процесса плановая отработка отказа и восстановления размещения до тех пор, пока основные и вторичные регионы доступны во всем процессе. Дополнительные сведения см. в разделе "Предвидение потери данных и несоответствий ".
Чтобы понять влияние этого типа отработки отказа на пользователей и приложения, полезно знать, что происходит во время каждого шага процессов плановая отработка отказа и восстановления размещения. Дополнительные сведения о том, как работает этот процесс, см. в статье о работе отработки отказа, управляемой клиентом (плановой).
Внимание
Управляемые клиентом плановая отработка отказа в настоящее время находятся в предварительной версии и ограничены следующими регионами:
- Центральная Франция
- Южная Франция
- Центральная Индия
- Западная Индия
- Восточная Азия
- Юго-Восточная Азия
Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.
Внимание
После плановая отработка отказа значение последней синхронизации (LST) учетной записи хранения может отображаться устаревшим или отображаться как NULL при наличии данных Файлы Azure.
Системные моментальные снимки периодически создаются в дополнительном регионе учетной записи хранения для поддержания согласованных точек восстановления, используемых во время отработки отказа и восстановления размещения. Запуск управляемых клиентом плановая отработка отказа приводит к тому, что исходный основной регион станет новым вторичным. В некоторых случаях в новой вторичной стороне нет системных моментальных снимков после завершения плановая отработка отказа, что приводит к тому, что общее значение LST учетной записи отображается устаревшим или отображается как Null.
Так как действия пользователей, такие как создание, изменение или удаление объектов, могут активировать создание моментальных снимков, любая учетная запись, в которой выполняются эти действия после плановая отработка отказа, не требует дополнительного внимания. Однако учетные записи без моментальных снимков или действий пользователя могут продолжать отображать Null значение LST до тех пор, пока не будет запущено создание системного моментального снимка.
При необходимости выполните одно из следующих действий для каждой общей папки в учетной записи хранения, чтобы активировать создание моментального снимка. По завершении учетная запись должна отображать допустимое значение LST в течение 30 минут.
- Подключите общую папку, а затем откройте любой файл для чтения.
- Отправьте тестовый или пример файла в общую папку.
Отработка отказа, управляемого клиентом (незапланированная)
Если конечные точки данных для служб хранения в учетной записи хранения становятся недоступными в основном регионе, можно инициировать отмену плановая отработка отказа в дополнительный регион. После завершения отработки отказа дополнительный регион становится новым основным, и пользователи могут перейти к данным там.
Чтобы понять влияние этого типа отработки отказа на пользователей и приложения, полезно знать, что происходит во время каждого шага процесса отмены плановая отработка отказа и восстановления размещения. Дополнительные сведения о том, как работает процесс, см. в статье о работе отработки отказа, управляемой клиентом (незапланированной).
Отработка отказа, управляемая корпорацией Майкрософт
Корпорация Майкрософт может инициировать региональную отработку отказа в чрезвычайных обстоятельствах, например катастрофическую катастрофу, которая влияет на весь географический регион. Во время этих событий никаких действий с вашей частью не требуется. Если учетная запись хранения настроена для RA-GRS или RA-GZRS, приложения могут считывать данные из дополнительного региона во время отработки отказа, управляемого корпорацией Майкрософт. Однако у вас нет доступа на запись к учетной записи хранения до завершения процесса отработки отказа.
Внимание
Используйте управляемые клиентом варианты отработки отказа для разработки, тестирования и реализации планов аварийного восстановления. Не полагаться на отработку отказа, управляемой корпорацией Майкрософт, которая может использоваться только в чрезвычайных обстоятельствах. Отработка отказа, управляемого корпорацией Майкрософт, будет инициирована для всей физической единицы, например региона или центра обработки данных. Его нельзя инициировать для отдельных учетных записей хранения, подписок или клиентов. Если вам нужна возможность выборочно отработки отказа отдельных учетных записей хранения, используйте управляемые клиентом плановая отработка отказа.
Прогнозирование потери данных и несоответствий
Внимание
Управляемый клиентом не плановая отработка отказа обычно включает некоторую потерю данных, а также может привести к несоответствиям файлов и данных. В плане аварийного восстановления важно учитывать влияние отработки отказа учетной записи на данные, прежде чем инициировать его.
Так как данные записываются асинхронно из основного региона в дополнительный регион, всегда возникает задержка перед копированием записи в основной регион в дополнительный. Если основной регион становится недоступным, возможно, что последние записи еще не будут скопированы в дополнительный.
Когда происходит отмена плановая отработка отказа, все данные в основном регионе теряются, так как дополнительный регион становится новым первичным. Все данные, уже скопированные в дополнительный регион, сохраняются при отработки отказа. Однако все данные, записанные в основной, который еще не существует в дополнительном регионе, окончательно теряются.
Новый основной регион настроен на локально избыточность (LRS) после отработки отказа.
Вы также можете столкнуться с несоответствиями файлов или данных, если учетные записи хранения имеют одну или несколько следующих возможностей:
- Иерархическое пространство имен (Azure Data Lake Storage)
- Канал изменений.
- Восстановление блочных BLOB-объектов на определенный момент времени
Время последней синхронизации
Свойство Last Sync Time указывает последнее время записи данных из основного региона в дополнительный регион. Для учетных записей, имеющих иерархическое пространство имен, то же свойство Времени последней синхронизации также применяется к метаданным, управляемым иерархическим пространством имен, включая списки управления доступом (ACL). Все данные и метаданные, записанные до последнего времени синхронизации, доступны на вторичной стороне. В отличие от этого, данные и метаданные, записанные после последнего времени синхронизации, пока не будут скопированы в дополнительный и потенциально могут быть потеряны. Во время сбоя используйте это свойство для оценки объема потери данных при запуске отработки отказа учетной записи.
Рекомендуется разработать приложение таким образом, чтобы можно было использовать время последней синхронизации для оценки ожидаемой потери данных. Например, ведение журнала всех операций записи позволяет сравнить время последней операции записи с последним временем синхронизации. Этот метод позволяет определить, какие записи еще не синхронизированы с вторичным и могут быть потеряны.
Дополнительные сведения о проверке свойства Время последней синхронизации см. в статье Проверка свойства "Время последней синхронизации" для учетной записи хранения.
Согласованность файлов для Azure Data Lake Storage
Репликация учетных записей хранения с включенным иерархическим пространством имен (Azure Data Lake Storage) происходит на уровне файла. Так как репликация происходит на этом уровне, сбой в основном регионе может препятствовать успешной репликации некоторых файлов в контейнере или каталоге в дополнительный регион. Согласованность для всех файлов в контейнере или каталоге после отработки отказа учетной записи хранения не гарантируется.
Несоответствия данных канала изменений и больших двоичных объектов
Отработка отказа учетных записей хранения с включенным каналом изменений может привести к несоответствиям между журналами канала изменений и данными больших двоичных объектов и /или метаданными. Такие несоответствия могут привести к асинхронной природе обновлений журнала изменений и репликации данных между основными и вторичными регионами. Вы можете избежать несоответствий, выполнив следующие меры предосторожности:
- Убедитесь, что все записи журнала удаляются в файлы журнала.
- Убедитесь, что все данные хранилища реплицируются из основного в дополнительный регион.
Дополнительные сведения о веб-канале изменений см. в разделе "Как работает веб-канал изменений".
Помните, что другие функции учетной записи хранения также требуют включения канала изменений. К этим функциям относятся оперативное резервное копирование Хранилище BLOB-объектов Azure, репликация объектов и восстановление на определенный момент времени для блочных BLOB-объектов.
Несоответствия восстановления на определенный момент времени
Отработка отказа, управляемого клиентом, поддерживается для учетных записей хранения уровня "Стандартный" версии 2, включающих блочные BLOB-объекты. Однако при выполнении отработки отказа, управляемой клиентом, в учетной записи хранения сбрасывается самая ранняя возможная точка восстановления для учетной записи. Данные для восстановления по точкам во времени для блочных BLOB-объектов согласованы только до времени завершения отработки отказа. В результате можно восстановить только блочные BLOB-объекты до точки во времени не раньше времени завершения отработки отказа. Вы можете проверить время завершения отработки отказа на вкладке избыточности учетной записи хранения в портал Azure.
Время и стоимость отработки отказа
Время, необходимое для завершения отработки отказа, управляемого клиентом, после инициирования может отличаться, хотя обычно это занимает менее одного часа.
Плановая отработка отказа, управляемая клиентом, не теряет геоизбыточность после отработки отказа и последующего восстановления размещения, но незапланированная отработка отказа, управляемая клиентом.
Инициируя управляемый клиентом не плановая отработка отказа автоматически преобразует учетную запись хранения в локально избыточное хранилище (LRS) в новом основном регионе и удаляет учетную запись хранения в исходном основном регионе.
Вы можете повторно включить геоизбыточное хранилище (GRS) или геоизбыточное хранилище (RA-GRS) для учетной записи, но повторно реплицировать данные в новом дополнительном регионе взимается плата. Кроме того, перед перенастройкой учетной записи для геоизбыточности необходимо восстановить архивированные BLOB-объекты на сетевой уровень. Это восстановление также несет дополнительную плату. Дополнительные сведения о ценах см. в следующем разделе:
После повторного включения GRS для учетной записи хранения Microsoft начинает репликацию данных в вашей учетной записи в новый вторичный регион. Время, необходимое для завершения репликации, зависит от нескольких факторов. К этим факторам относится следующее:
- Число и размер объектов в учетной записи хранения. Репликация множества небольших объектов может занять больше времени, чем репликация меньше и больше объектов.
- Доступные ресурсы для фоновой репликации, такие как ЦП, память, диск и пропускная способность WAN. Динамический трафик имеет приоритет над георепликацией.
- Количество моментальных снимков для каждого большого двоичного объекта, если применимо.
- Стратегия секционирования данных, если учетная запись хранения содержит таблицы. Процесс репликации не может масштабироваться сверх количества используемых ключей разделов.
Поддерживаемые типы учетных записей хранения
Все геоизбыточные предложения поддерживают отработку отказа, управляемой корпорацией Майкрософт. Кроме того, некоторые типы учетных записей поддерживают отработку отказа, управляемой клиентом, как показано в следующей таблице:
| Тип отработки отказа | Учетная запись | GZRS или RA-GZRS |
|---|---|---|
| Управляемые клиентом плановая отработка отказа (предварительная версия) | Учетные записи общего назначения версии 2 Учетные записи общего назначения версии 1 Устаревшие учетные записи Хранилища BLOB-объектов |
Учетные записи общего назначения версии 2. |
| Отработка отказа, управляемого клиентом (незапланированная) | Учетные записи общего назначения версии 2 Учетные записи общего назначения версии 1 Устаревшие учетные записи Хранилища BLOB-объектов |
Учетные записи общего назначения версии 2. |
| Отработка отказа, управляемая корпорацией Майкрософт | Все типы учетных записей | Учетные записи общего назначения версии 2. |
Классические учетные записи хранения
Внимание
Отработка отказа, управляемая клиентом, поддерживается только для учетных записей хранения, развернутых с помощью модели развертывания Azure Resource Manager (ARM). Модель развертывания Azure Service Manager (ASM), которая также называется классической моделью, не поддерживается. Чтобы сделать классические учетные записи хранения подходящими для отработки отказа управляемых клиентом учетных записей, сначала их необходимо перенести в модель ARM. Учетная запись хранения должна быть доступна для выполнения обновления, поэтому основной регион в настоящее время не может находиться в состоянии сбоя.
Во время аварии, затрагивающей основной регион, корпорация Майкрософт будет управлять отработкой отказа для классических учетных записей хранения. Дополнительные сведения см. в статье Отработка отказа под управлением корпорации Майкрософт.
Иерархическое пространство имен (HNS)
Внимание
Отработка отказа, управляемого клиентом (незапланированная) для учетных записей с включенным Azure Data Lake Storage 2-го поколения, в настоящее время доступна в предварительной версии и поддерживается во всех общедоступных регионах GRS/GZRS.
Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.
Внимание
Отработка отказа, управляемого клиентом (незапланированная) для учетных записей с включенным протоколом SSH-передачи файлов (SFTP), в настоящее время поддерживается в предварительной версии и поддерживается только в следующих регионах:
- "Центральная Индия" (Азиатско-Тихоокеанский регион);
- (Азиатско-Тихоокеанский регион) Юго-Восточная Азия
- "Северная Европа" (Европа);
- Северная Швейцария (Европа)
- (Европа) Западная Швейцария
- "Западная Европа" (Европа).
- (Северная Америка) Центральная Канада;
- (Северная Америка) Восточная часть США 2;
- (Северная Америка) Центрально-южная часть США;
Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.
В случае значительного сбоя, затрагивающего основной регион, корпорация Майкрософт будет управлять отработкой отказа для учетных записей с иерархическим пространством имен. Дополнительные сведения см. в статье Отработка отказа под управлением корпорации Майкрософт.
Неподдерживаемые функции и службы
Следующие функции и службы не поддерживаются для отработки отказа, управляемой клиентом:
- Синхронизация файлов Azure не поддерживает отработку отказа управляемой клиентом учетной записи. Учетные записи хранения, используемые в качестве облачных конечных точек для Синхронизация файлов Azure, не должны быть отработки отказа. Отработка отказа нарушает синхронизацию файлов и может привести к неожиданной потере данных новых многоуровневых файлов. Дополнительные сведения см. в рекомендациях по аварийному восстановлению с помощью Синхронизация файлов Azure подробных сведений.
- Не удается выполнить отработку отказа учетной записи хранения, содержащей BLOB-объекты класса Premium. Учетные записи хранения, поддерживающие blob-объекты блоков класса Premium, в настоящее время не поддерживают геоизбыточность.
- Отработка отказа, управляемого клиентом, не поддерживается для исходной или целевой учетной записи в политике репликации объектов.
- Сетевая файловая система (NFS) 3.0 (NFSv3) не поддерживается для отработки отказа учетной записи хранения. Нельзя создать учетную запись хранения, настроенную для геоизбыточности с включенным NFSv3.
Следующая таблица может использоваться для ссылки на поддержку функций.
| Плановая отработка отказа | Внеплановая отработка отказа | |
|---|---|---|
| Хранилище озера данных Azure | Поддерживается (предварительная версия) | Поддерживается (предварительная версия) |
| Канал изменений | Не поддерживается | Поддерживается |
| Репликация объектов | Не поддерживается | Не поддерживается |
| SFTP | Поддерживается (предварительная версия) | Поддерживается (предварительная версия) |
| NFS версии 3 | GRS не поддерживается | GRS не поддерживается |
| Действия хранилища | Поддерживается1 | Поддерживается1 |
| Восстановление на определенный момент времени (PITR) | Не поддерживается | Поддерживается |
1 Если вы инициируете плановую или неуправляемую клиентом задачу хранения плановая отработка отказа, задачи хранения не могут работать с учетной записью, пока она не вернется к исходному основному региону. Подробнее.
Отработка отказа не для миграции учетных записей
Отработка отказа учетной записи хранения — это временное решение, используемое для разработки и тестирования планов аварийного восстановления или восстановления после сбоя службы. Отработка отказа не должна использоваться в рамках стратегии миграции данных. Сведения о переносе учетных записей хранения см. в служба хранилища Azure обзоре миграции.
Учетные записи хранения, содержащие архивированные BLOB-объекты
Учетные записи хранения, содержащие архивные BLOB-объекты, поддерживают отработку отказа Однако после завершения отработки отказа, управляемого клиентом, все архивные blob-объекты должны быть восстановлены на онлайн-уровне, прежде чем учетная запись может быть настроена для геоизбыточности.
Поставщик ресурсов хранилища
Корпорация Microsoft предоставляет два интерфейса API для работы с ресурсами службы хранилища Azure. Эти API образуют базу для всех действий, которые можно выполнять с хранилищем Azure. REST API службы хранилища Azure позволяет работать с данными в учетной записи хранения, включая данные больших двоичных объектов, очередей, файлов и таблиц. Поставщик ресурсов службы хранилища Azure REST API позволяет управлять учетной записью хранения и связанными ресурсами.
После завершения отработки отказа клиенты смогут снова считывать и записывать служба хранилища Azure данные в новом основном регионе. Однако поставщик ресурсов служба хранилища Azure не выполняет отработку отказа, поэтому операции управления ресурсами по-прежнему должны выполняться в основном регионе. Если основной регион недоступен, вы не сможете выполнять операции управления в учетной записи хранения.
Так как поставщик ресурсов служба хранилища Azure не выполняет отработку отказа, свойство Location возвращает исходное основное расположение после завершения отработки отказа.
Виртуальные машины Azure
Виртуальные машины Azure не выполняет отработку отказа в рамках отработки отказа учетной записи хранения. Все виртуальные машины, отработки отказа в дополнительный регион в ответ на сбой, необходимо повторно создать после завершения отработки отказа. Отработка отказа учетной записи может привести к потере данных, хранящихся на временном диске при завершении работы виртуальной машины. Корпорация Майкрософт рекомендует использовать рекомендации по обеспечению высокого уровня доступности и аварийного восстановления , относящиеся к виртуальным машинам в Azure.
Неуправляемые диски Azure
Неуправляемые диски содержатся в службе хранилища Azure в виде страничных BLOB-объектов. Пока виртуальная машина работает в Azure, все подключенные к ней неуправляемые диски считаются арендованными. Отработка отказа учетной записи не может продолжаться, когда есть аренда большого двоичного объекта. Перед запуском отработки отказа в учетной записи, содержащей неуправляемые диски, подключенные к виртуальным машинам Azure, диски должны быть завершены. По этой причине рекомендации Майкрософт включают преобразование всех неуправляемых дисков в управляемые диски.
Чтобы выполнить отработку отказа в учетной записи, содержащей неуправляемые диски, выполните следующие действия:
- Прежде чем начать, запишите имена всех неуправляемых дисков, их логические номера единиц (LUN) и виртуальную машину, к которой они подключены. Это упростит восстановление подключений после отработки отказа.
- Выключите виртуальную машину.
- Удалите виртуальную машину, но сохраните файлы виртуального жесткого диска (VHD) для неуправляемых дисков. Зафиксируйте время удаления виртуальной машины.
- Подождите, пока не будет обновлено время последней синхронизации , и убедитесь, что оно позже, чем время удаления виртуальной машины. Этот шаг гарантирует, что вторичная конечная точка полностью обновляется с помощью VHD-файлов при отработке отказа и правильно работает виртуальная машина в новом основном регионе.
- Запустите отработку отказа учетной записи.
- Дождитесь завершения отработки отказа учетной записи, а дополнительный регион станет новым основным регионом.
- Создайте виртуальную машину в новом основном регионе и присоедините к ней виртуальные жесткие диски.
- Запустите новую виртуальную машину.
Не забывайте, что все хранимые данные на временном диске теряются при выключении виртуальной машины.
Копирование данных в качестве альтернативы отработки отказа
Как уже говорилось ранее, вы можете поддерживать высокий уровень доступности, настроив приложения для использования учетной записи хранения, настроенной для доступа на чтение к дополнительному региону. Однако если вы предпочитаете не выполнять отработку отказа во время сбоя в основном регионе, можно вручную скопировать данные в качестве альтернативы. Такие средства, как AzCopy и Azure PowerShell , позволяют копировать данные из учетной записи хранения в затронутом регионе в другую учетную запись хранения в небезопасном регионе. После завершения операции копирования можно перенастроить приложения для использования учетной записи хранения в небезопасном регионе для доступности чтения и записи.
Учет высокого уровня доступности при проектировании
Очень важно, чтобы разработка приложений изначально велась с учетом высокого уровня доступности. Ознакомьтесь с этими ресурсами Azure для получения рекомендаций при разработке приложения и планировании аварийного восстановления:
- Назначение устойчивых приложений для Azure: обзор основных понятий, применимых при разработке в Azure приложений с высоким уровнем доступности.
- Контрольный список устойчивости: контрольный список, позволяющий проверить соблюдение в приложении передовых рекомендаций по разработке для обеспечения высокой доступности.
- Используйте геоизбыточность для разработки высокодоступных приложений: руководство по проектированию для создания приложений с целью использования преимуществ геоизбыточного хранилища.
- Учебник "Сборка высокодоступного приложения с хранилищем BLOB": в этом руководстве показано, как создавать приложения с высоким уровнем доступности, которые автоматически переключаются между конечными точками при моделировании сбоев и восстановления работоспособности.
Ознакомьтесь с этими рекомендациями по обеспечению высокого уровня доступности данных служба хранилища Azure:
- Диски: используйте Azure Backup для резервного копирования дисков, используемых виртуальными машинами Azure. Кроме того, рекомендуется использовать Azure Site Recovery для защиты виртуальных машин от региональной аварии.
- Блочные BLOB-объекты: включите обратимое удаление, чтобы предотвратить удаление и перезапись на уровне объектов, или скопируйте блочные BLOB-объекты в другую учетную запись хранения, относящуюся к другому региону, с помощью AzCopy, Azure PowerShell или библиотеки перемещения данных Azure.
- Файлы: используйте Azure Backup для резервного копирования файловых ресурсов. Также включите обратимое удаление, чтобы защититься от случайного удаления файловых ресурсов. Для геоизбыточности, если GRS недоступен, используйте AzCopy или Azure PowerShell для копирования файлов в другую учетную запись хранения в другом регионе.
- Таблицы: используйте AzCopy для экспорта данных таблицы в другую учетную запись хранения в другом регионе.
Отслеживание сбоев
Клиенты могут подписаться на панель мониторинга работоспособности служб Azure, чтобы отслеживать работоспособность и состояние служба хранилища Azure и других служб Azure.
Кроме того, корпорация Майкрософт рекомендует учесть в приложении возможность сбоев при записи. Приложение должно информировать о сбоях при записи, чтобы вы своевременно получали сведения о возможных сбоях в основном регионе.
См. также
- Разработка высокодоступных приложений с геоизбыточностью
- Руководство. Создание высокодоступного приложения с помощью хранилища BLOB-объектов
- Репликация службы хранилища Azure
- Как работает управляемый клиентом плановая отработка отказа (предварительная версия)
- Как работает отработка отказа, управляемая клиентом (незапланированная)