Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Корпорация Майкрософт стремится непрерывно поддерживать доступность служб Azure. Однако незапланированные сбои служб могут возникнуть, и у вас должен быть план аварийного восстановления (АВ) для обработки сбоя региональной службы. Важной частью плана аварийного восстановления является подготовка к переключению на вторичный узел в случае недоступности основного узла. В этой статье описываются основные понятия и процессы, связанные с аварийным восстановлением (DR) и отработкой отказа учетной записи хранения.
Это важно
Azure File Sync поддерживает отказоустойчивость учетной записи хранения только в том случае, если также осуществляется отказоустойчивость службы синхронизации хранилища. Это связано с тем, что синхронизация файлов Azure требует, чтобы учетная запись хранения и служба синхронизации хранилища были в одном регионе Azure. Если выполняется отработка отказа только учетной записи хранения, синхронизация и операции по уровням облака завершаются сбоем до отработки отказа службы синхронизации хранилища в дополнительный регион. Если вы хотите выполнить отработку отказа учетной записи хранения, содержащей общие папки Azure, используемые в качестве облачных конечных точек в службе "Синхронизация файлов Azure", ознакомьтесь с рекомендациями по аварийному восстановлению службы "Синхронизация файлов Azure" и восстановлением сервера синхронизации файлов Azure.
Применимо к
| Модель управления | Модель выставления счетов | Уровень медиа | Избыточность | Малый и средний бизнес (SMB) | Сетевая файловая система (NFS) |
|---|---|---|---|---|---|
| Microsoft.Storage | Настроенная версия 2 | HDD (стандартный) | Локальное (LRS) |
|
|
| Microsoft.Storage | Настроенная версия 2 | HDD (стандартный) | Зона (ZRS) |
|
|
| Microsoft.Storage | Настроенная версия 2 | HDD (стандартный) | Гео (GRS) |
|
|
| Microsoft.Storage | Настроенная версия 2 | HDD (стандартный) | GeoZone (GZRS) |
|
|
| Microsoft.Storage | Настроенная версия v1 | SSD (премиум) | Локальное (LRS) |
|
|
| Microsoft.Storage | Настроенная версия v1 | SSD (премиум) | Зона (ZRS) |
|
|
| Microsoft.Storage | Оплата по мере использования | HDD (стандартный) | Локальное (LRS) |
|
|
| Microsoft.Storage | Оплата по мере использования | HDD (стандартный) | Зона (ZRS) |
|
|
| Microsoft.Storage | Оплата по мере использования | HDD (стандартный) | Гео (GRS) |
|
|
| Microsoft.Storage | Оплата по мере использования | HDD (стандартный) | GeoZone (GZRS) |
|
|
Управляемая клиентом отработка отказа (предварительная версия)
Отказоустойчивость, управляемая клиентом, также может быть использована в различных сценариях, включая запланированное тестирование восстановления после стихийных бедствий, проактивный подход к большим катастрофам или для восстановления после перебоев, не связанных с хранилищем данных.
Во время запланированного процесса перехода на резерв, первичные и вторичные регионы меняются местами. Оригинальный основной регион понижается в статусе и становится новым вторичным регионом. В то же время исходный вторичный регион продвигается и становится новым первичным. После завершения отработки отказа пользователи могут начать доступ к данным в новом основном регионе, а администраторы могут проверить свой план аварийного восстановления. Учетная запись хранения должна быть доступна как в первичных, так и во вторичных регионах, прежде чем может быть инициировано плановое переключение при отказе.
Потеря данных не ожидается во время запланированного процесса переключения на резервную копию и возврата на основной источник до тех пор, пока первичные и вторичные регионы доступны в течение всего процесса. Дополнительные сведения см. в разделе "Предвидение потери данных и несоответствий ".
Чтобы понять влияние этого типа переключения на пользователей и приложения, полезно знать, что происходит на каждом шаге запланированных процессов переключения и возврата. Дополнительные сведения о том, как работает этот процесс, см. в статье «Как работает отработка отказа, управляемая клиентом (плановая)».
Это важно
Отзывы пользователей включаются в планируемую пользователем отработку отказа (предварительная версия), и функция временно недоступна во всех регионах. После завершения обновленная документация будет выпущена, чтобы отразить регионы, в которых доступна функция.
Метрики восстановления и затраты
Чтобы сформулировать эффективную стратегию аварийного восстановления, организация должна понимать следующее:
- Сколько данных может позволить себе потерять в случае сбоя (цель точки восстановления или RPO)
- Как быстро она должна быть в состоянии восстановить бизнес-функции и данные (цель восстановления или RTO)
Стоимость аварийного восстановления обычно увеличивается с меньшим или нулевым RPO/RTO. Компании, которые должны начать работу в течение нескольких секунд после аварии и не могут допустить потери данных, будут платить больше за аварийное восстановление, в то время как те, у кого более высокие показатели RPO/RTO, будут платить меньше. Azure предоставляет решения, которые могут работать с различными требованиями RPO и RTO.
Выберите правильный вариант резервирования
Файлы Azure предлагают различные варианты избыточности для защиты данных от запланированных и незапланированных событий, начиная от временных сбоев оборудования, сетевых сбоев и сбоев питания до стихийных бедствий. Все общие папки Azure могут использовать локально избыточное хранилище (LRS) или зонально избыточное хранилище (ZRS). Дополнительные сведения см. в разделе Избыточность файлов Azure.
Файлы Azure поддерживают отказоустойчивость учетной записи для общих папок HDD, сконфигурированных с использованием геоизбыточного хранилища (GRS) и геозонного избыточного хранилища (GZRS) для защиты от региональных сбоев. Отработка отказа учетной записи позволяет инициировать процесс отработки отказа для учетной записи хранения в тех случаях, когда основная конечная точка становится недоступной. Отработка отказа преобразует вторичную конечную точку в основную конечную точку учетной записи хранения. Когда отработка отказа завершится, клиенты смогут записывать данные в новую основную конечную точку.
GRS и GZRS всё ещё несут риск потери данных, так как данные копируются во вторичный регион асинхронно, то есть сначала происходит запись в основной регион, а потом с задержкой копирование во вторичный регион. В случае сбоя операции записи в основную конечную точку, которая еще не скопирована в вторичную конечную точку, будут потеряны. Это означает, что сбой, влияющий на основной регион, может привести к потере данных, если основной регион не может быть восстановлен. Интервал между последней записью в главный регион и последней записью в дополнительный регион является RPO. Файлы Azure обычно имеют RPO в течение 15 минут или меньше, хотя в настоящее время нет соглашения об уровне обслуживания, определяющего время репликации данных во вторичный регион.
Это важно
GRS/GZRS не поддерживаются для общих папок SSD. Однако вы можете синхронизировать между двумя общими папками Azure для обеспечения географической избыточности.
Проектирование высокого уровня доступности
Важно разработать приложение для обеспечения высокой доступности с самого начала. Дополнительные сведения о разработке приложения и планировании аварийного восстановления см. в следующих ресурсах Azure:
- Проектирование устойчивых приложений для Azure: общие сведения о ключевых понятиях для разработки высокодоступных приложений в Azure.
- Контрольный список устойчивости: контрольный список для проверки того, что приложение реализует рекомендации по проектированию для обеспечения высокой доступности.
- Используйте геоизбыточность для разработки высокодоступных приложений: руководство по проектированию приложений для использования геоизбыточного хранилища для общих папок SMB.
Мы также рекомендуем разработать приложение для подготовки к возможному сбою записи. Приложение должно информировать о сбоях при записи, чтобы вы своевременно получали сведения о возможных сбоях в основном регионе.
Рекомендуется разработать приложение, чтобы проверить свойство времени последней синхронизации , чтобы оценить ожидаемые потери данных. Например, если вы регистрируете все операции записи, то можно сравнить время последних операций записи с временем последней синхронизации, чтобы определить, какие записи не были синхронизированы с вторичным.
Отслеживание отключений
Вы можете подписаться на панель мониторинга работоспособности служб 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. Дополнительные сведения о том, как инициировать отработку отказа, см. Инициация отказа учетной записи.
Отказоустойчивость под управлением Microsoft
В чрезвычайных обстоятельствах, когда регион утрачивается из-за значительной катастрофы, корпорация Майкрософт может инициировать региональное переключение. В этом случае никаких действий не требуется. До завершения отработки отказа, управляемой корпорацией Майкрософт, у вас не будет доступа к учетной записи хранения.