Надежность в файлах Azure

В этой статье описывается поддержка надежности в файлах Azure. Файлы Azure предоставляют полностью управляемые общие папки в облаке, доступные через протоколы SMB и сетевой файловой системы (NFS).

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

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

Замечание

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

Рекомендации по развертыванию в производственной среде

Чтобы узнать, как развернуть файлы Azure для поддержки требований к надежности решения и как надежность влияет на другие аспекты архитектуры, ознакомьтесь с рекомендациями по архитектуре для файлов Azure в Azure Well-Architected Framework.

Обзор архитектуры надежности

Локально избыточное хранилище (LRS) реплицирует данные в учетных записях хранения в одну или несколько зон доступности Azure, расположенных в основном регионе вашего выбора. Хотя нет возможности выбрать предпочтительную зону доступности, Azure может перемещать или расширять учетные записи LRS между зонами, чтобы повысить балансировку нагрузки. Нет гарантии, что ваши данные распределены по зонам. Дополнительные сведения о availability zones см. в разделе "Что такое Зоны доступности?"

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

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

Файлы Azure доступны на двух уровнях мультимедиа:

  • Уровень "Премиум" использует твердотельные накопители (SSD) для высокой производительности. Этот уровень рекомендуется для рабочих нагрузок, требующих низкой задержки.

  • Уровень "Стандартный " поддерживает жесткие диски (HDD). Общие папки HDD предоставляют экономичный вариант хранения общих папок общего назначения.

Дополнительные сведения см. в разделе "Планирование развертывания файлов Azure — уровни хранилища".

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

Устойчивость к временным сбоям

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

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

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

Чтобы убедиться, что для общей папки NFS установлены только безопасные подключения, рекомендуется настроить частную конечную точку для учетной записи хранения. Частная конечная точка использует Приватный канал Azure для назначения статического IP-адреса учетной записи хранения внутри частного адресного пространства вашей виртуальной сети. Частная конечная точка помогает предотвратить прерывания подключения от изменений динамических IP-адресов. Дополнительные сведения о безопасности общих папок NFS см. в разделе "Общие папки NFS" — безопасность и сеть.

Устойчивость к сбоям зоны доступности

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

Файлы Azure предоставляют две типы поддержки зоны доступности:

Требования

  • Поддержка региона:

  • Типы общих папок:

    • ZRS: ZRS поддерживается всеми типами общих папок.

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

      • Необходимо использовать уровень хранилища уровня "Премиум" (уровень носителей SSD).
      • Только классические файловые ресурсы Azure (используйте поставщик ресурсов Microsoft.Storage). Вы не можете использовать зональное размещение для общих файловых ресурсов, созданных поставщиком ресурсов Microsoft.FileShares.

Себестоимость

Влияние на затраты отличается в зависимости от типа поддержки зоны доступности.

  • ZRS: При включении хранилища с зональной избыточностью (ZRS) плата взимается по другому тарифу, чем за локально избыточное хранилище (LRS), из-за дополнительных накладных расходов на репликацию и хранение.

  • LRS с зональным размещением: LRS с зональным размещением взимается по той же ставке, что и LRS.

Подробные сведения о ценах см. в разделе о ценах на файлы Azure.

Настройка поддержки зоны доступности

Поведение, когда все зоны работоспособны

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

  • Маршрутизация трафика между зонами:

    • ZRS: Хранилище Azure с избыточностью между зонами (ZRS) автоматически распределяет запросы между кластерами хранения в нескольких зонах доступности. Распределение трафика прозрачно для приложений и не требует настройки на стороне клиента.

    • LRS с зональным размещением: Служба хранилища Azure с локальным избыточным хранилищем (LRS) автоматически распределяет запросы между кластерами хранилища в выбранной зоне доступности. Распределение трафика прозрачно для приложений и не требует настройки на стороне клиента.

  • Репликация данных между зонами:

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

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

Поведение во время сбоя зоны

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

  • Обнаружение и ответ:

    • ZRS: Корпорация Майкрософт автоматически обнаруживает сбои зоны и инициирует процессы восстановления. Для учетных записей хранилища с избыточностью между зонами (ZRS) никаких действий со стороны клиента не требуется. Если зона становится недоступной, Azure выполняет обновления сети, такие как переназначение системы доменных имен (DNS).

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

  • Активные запросы:

    • ZRS: Запросы, выполняемые в данный момент, могут быть потеряны в процессе восстановления и должны быть повторены. Приложения должны реализовать логику повторных попыток для обработки этих временных прерываний.

    • LRS с зональным размещением: Запросы в процессе выполнения отменяются и должны быть повторены при восстановлении зоны.

  • Ожидаемая потеря данных:

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

    • LRS с зональным размещением: Данные о файловых ресурсах в затронутой зоне недоступны до тех пор, пока зона не восстановится.

  • Ожидаемое время простоя:

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

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

  • Перенаправка трафика:

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

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

Восстановление зоны

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

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

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

Тестирование на сбои в зоне

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

  • ZRS: При использовании зонально избыточного хранилища (ZRS) служба хранилища Azure автоматически управляет репликацией, маршрутизацией трафика и реакцией на сбои в зонах. Так как эта функция полностью управляема, не требуется инициировать или проверять процессы сбоя зоны доступности.

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

Устойчивость к сбоям на уровне региона

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

Это важно

Геоизбыточное хранилище (GRS) работает только в парных регионах Azure. Если регион вашей учётной записи хранения не входит в региональную пару, рекомендуется использовать настраиваемые мультирегиональные решения для повышения отказоустойчивости.

Георезервное хранилище для парных регионов

Хранилище Azure поддерживает несколько типов GRS в парных регионах. Независимо от используемого типа GRS служба всегда реплицирует данные в дополнительном регионе с помощью локально избыточного хранилища (LRS). Этот подход обеспечивает защиту от сбоев оборудования в дополнительном регионе.

Это важно

Файлы Azure поддерживают только геоизбыточность (GRS или GZRS) для стандартных файловых хранилищ (HDD).

Файлы Azure не поддерживают геоизбыточное хранилище для чтения (RA-GRS) или геозонально избыточное хранилище для чтения (RA-GZRS). Если учетная запись хранения настроена для использования RA-GRS или RA-GZRS, стандартные файловые доли (HDD) настраиваются и тарифицируются по GRS или GZRS.

Типы аварийного переключения

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

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

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

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

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

Требования

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

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

  • Только стандартные файловые ресурсы: Файлы Azure поддерживают только геоизбыточность (GRS или GZRS) для стандартных файловых ресурсов (HDD). Общие папки уровня "Премиум" (SSD) должны использовать LRS или ZRS. Если у вас есть файловые ресурсы уровня "Премиум" и вы хотите реплицировать данные между регионами для повышения устойчивости, см. Пользовательские мультирегиональные решения для обеспечения устойчивости.

  • Только для GRS и GZRS: Файлы Azure не поддерживают геоизбыточное хранилище с доступом только для чтения (RA-GRS) и гео-зональное хранилище с доступом только для чтения (RA-GZRS). Если учетная запись хранения настроена для использования RA-GRS или RA-GZRS, стандартные файловые доли (HDD) настраиваются и тарифицируются по GRS или GZRS.

Соображения

При реализации многорегионных Файлы Azure следует учитывать следующие важные факторы:

  • Задержка асинхронной репликации: Репликация данных в дополнительный регион является асинхронной, что означает, что задержка между записью данных в основной регион и когда она становится доступной в дополнительном регионе. Эта задержка может привести к потенциальной потере данных, если происходит сбой основного региона до репликации последних данных. Потеря данных измеряется целевой точкой восстановления (RPO). Можно ожидать, что задержка репликации составит менее 15 минут, однако это лишь ориентировочная оценка, и такой срок не гарантируется.

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

  • Время последней синхронизации: Для Файлы Azure время последней синхронизации определяется последним системным снимком во вторичном регионе.

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

  • Доступ к дополнительному региону: Дополнительный регион недоступен для чтения до отказоустойчивости.

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

Себестоимость

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

Подробные сведения о ценах см. в разделе о ценах на файлы Azure.

Настройка поддержки нескольких регионов

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

  • Включите геоизбыточное использование существующей учетной записи хранения файлов. Сведения о преобразовании существующей учетной записи файлового хранилища в GRS см. в разделе "Изменение конфигурации избыточности для файлов Azure".

    Предупреждение

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

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

  • Отключите геоизбыточность. Преобразуйте учетные записи GRS обратно в однорегионные конфигурации (LRS или ZRS) через процесс изменения конфигурации для управления избыточностью.

Поведение, когда все регионы работоспособны

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

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

  • Репликация данных между регионами: Операции записи сначала фиксируются в основном регионе с помощью настроенного типа избыточности (LRS для GRS или ZRS для GZRS). После успешного завершения в основном регионе данные асинхронно реплицируются в дополнительный регион, где он хранится с помощью LRS.

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

Поведение во время сбоя региона

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

  • Аварийное переключение, управляемое клиентом (незапланированное): Используйте незапланированное аварийное переключение в случае недоступности хранилища в основном регионе.

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

      • Показывает ли Azure Работоспособность ресурсов проблемы с доступом к учетной записи хранилища в основном регионе

      • Советует ли корпорация Майкрософт выполнить аварийное переключение в другой регион

      Предупреждение

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

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

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

    • Ожидаемая потеря данных: Потеря данных возможна при внеплановом переключении при отказе из-за задержки асинхронной репликации, а это означает, что недавние операции записи могут не быть реплицированы. Вы можете посмотреть свойство «Время последней синхронизации», чтобы понять, сколько данных может быть потеряно при незапланированном переключении при отказе. Ожидаемая потеря данных часто называется целевой точкой восстановления (RPO). Обычно можно ожидать, что RPO будет менее 15 минут, но это время не гарантируется.

    • Ожидаемое время простоя: Количество ожидаемого простоя часто называется целевой задачей времени восстановления (RTO). Отказоустойчивость, контролируемая клиентом, обычно занимает до 60 минут в зависимости от размера аккаунта и сложности.

    • Перенаправка трафика: По завершении отработки отказа Azure автоматически обновляет конечные точки учетной записи хранения, чтобы приложения не должны быть перенастроены. Если приложение хранит записи системы доменных имен (DNS), возможно, потребуется очистить кэш, чтобы убедиться, что приложение отправляет трафик в новый первичный регион.

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

    Дополнительные сведения о том, как инициировать отработку отказа, управляемую клиентом, см. в статьях Как работает отработка отказа, управляемая клиентом (внеплановая) и Инициирование отработки отказа учетной записи хранения данных.

  • Переключение при отказе, инициируемое клиентом (плановое): Используйте плановое переключение при отказе, если хранилище продолжает работать в основном регионе, но по другой причине вам необходимо выполнить переключение всей системы во вторичный регион. Например, другая служба Azure может столкнуться с проблемой, и вам нужно переключиться на использование дополнительного региона для всего решения. Или вы можете использовать плановое переключение на резерв для выполнения учебного восстановления после аварии для целей соответствия требованиям и аудита.

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

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

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

    • Ожидаемая потеря данных: Потеря данных не ожидается, так как процесс отработки отказа завершается только после синхронизации всех данных, что обеспечивает целевое время восстановления (RPO) равное нулю.

    • Ожидаемое время простоя: Отработка отказа обычно завершается в течение 60 минут, что означает, что ожидаемое время восстановления (RTO) составляет 60 минут в зависимости от размера учетной записи и сложности. Во время отработки отказа конечные точки основной и вторичной учетной записи хранения становятся временно недоступными для операций чтения и записи.

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

    • Конфигурация после отработки отказа: После завершения плановой отработки отказа учетная запись хранилища в целевом регионе продолжает геореплицироваться и остается на уровне GRS (Geo-Redundant Storage).

    Дополнительные сведения о том, как инициировать переключение при отказе, управляемое клиентом, см. в статьях Как работает переключение при отказе, управляемое клиентом (плановое) и Инициирование переключения при отказе учетной записи хранения данных.

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

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

    Это важно

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

Восстановление региона

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

  • Управляемое клиентом аварийное переключение (внеплановое): После внепланового аварийного переключения учетная запись хранения настраивается на использование локально избыточного хранилища (LRS). Чтобы выполнить возврат после отработки отказа, необходимо повторно настроить связь с геоизбыточным хранилищем (GRS) и дождаться репликации данных.

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

  • Аварийное переключение, управляемое корпорацией Майкрософт: Если корпорация Майкрософт инициирует аварийное переключение, скорее всего, в основном регионе произошла крупная авария, и основной регион может оказаться невосстановимым. Любые сроки или планы восстановления зависят от масштаба регионального бедствия и усилий по восстановлению. Следует отслеживать коммуникации Работоспособность служб Azure для получения подробной информации.

Проверка сбоев в регионе

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

Кастомные многорегиональные решения для повышения отказоустойчивости

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

  • Ваша учетная запись хранения находится в непарализованном регионе.

  • Цели вашей компании по обеспечению бесперебойной работы не достигаются с помощью времени восстановления или потери данных, которые предполагают встроенные варианты автоматического переключения.

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

  • Для разных регионов требуется активная и активная конфигурация.

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

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

Рассмотрим следующие распространенные подходы высокого уровня:

  • Несколько учетных записей хранения: Файлы Azure можно развертывать в нескольких регионах с помощью отдельных учетных записей хранения в каждом регионе. Этот подход обеспечивает гибкость в выборе регионов, возможность использовать непарные регионы и более точный контроль над временем репликации и согласованностью данных. При реализации нескольких учетных записей хранения в разных регионах необходимо настроить репликацию данных между регионами, реализовать политики балансировки нагрузки и отработки отказа и обеспечить согласованность данных между регионами.

  • Репликация на уровне приложения: Реализация пользовательской логики репликации с помощью фабрики данных Azure или AzCopy для синхронизации данных между общими папками в разных регионах. Для этого подхода требуются пользовательские механизмы разработки и разрешения конфликтов.

  • Синхронизация файлов Azure позволяет реплицировать файлы в общую папку в другом регионе Azure. Вы можете использовать Синхронизация файлов Azure для синхронизации между SMB-общей папкой Azure (облачной конечной точкой), локальным файловым сервером Windows и монтированной общей папкой, которая работает на виртуальной машине в другом регионе Azure (конечная точка сервера аварийного восстановления).

    Этот подход требует развертывания нескольких общих папок и виртуальной машины для координации процесса синхронизации.

    Если вы используете этот подход для репликации файлов между несколькими регионами:

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

    • Подготовка достаточного хранилища на виртуальной машине Azure для хранения всего набора данных.

    • Доступ и изменение файлов на конечной точке сервера, а не в Azure, чтобы обеспечить быструю репликацию изменений в дополнительный регион.

Резервное копирование и восстановление

Резервное копирование файлов Azure — это встроенная интеграция файлов Azure и Azure Backup, предназначенная для защиты данных от случайного удаления, повреждения и атак программ-шантажистов.

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

Вы можете создавать моментальные снимки и хранить их двумя способами:

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

  • Архивное хранилище резервных копий: Используя архивное копирование, вы можете скопировать ежедневные моментальные снимки в хранилище служб восстановления Azure. Чтобы повысить безопасность, это хранилище изолировано и отключено от сети основной учетной записи хранилища.

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

Соглашение об уровне обслуживания

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

Связанный контент

  • Last updated on