Надежность в службе Azure Storage Mover

Статья
2025-04-02

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

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

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

Дополнительные сведения о зонах доступности в Azure см. в статье "Что такое зоны доступности?"

Azure Storage Mover поддерживает зонально-избыточную модель развертывания.

При развертывании ресурса Azure Storage Mover необходимо выбрать определенный регион, в котором хранятся метаданные экземпляра ресурса.

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

Внимание

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

Предварительные условия

Чтобы развернуть приложение с поддержкой зон доступности, необходимо выбрать регион, где они поддерживаются. Сведения о том, какие регионы поддерживают зоны доступности, см. в списке поддерживаемых регионов.
(Optional) Если ваша целевая учетная запись хранилища не поддерживает зоны доступности и вы хотите перенести учетную запись на поддержку зон доступности, см. статью "Миграция учетных записей хранилища Azure на поддержку зон доступности".

Опыт снижения уровня зон

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

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

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

Аварийное восстановление между регионами и непрерывность бизнес-процессов

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

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

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

Storage Mover поддерживает две формы аварийного восстановления:

Аварийное восстановление, инициированное Azure
Аварийное восстановление, инициированное клиентом

Внимание

Аварийное восстановление локальных источников данных является ответственностью клиента.

Аварийное восстановление, инициированное Azure

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

служба хранилища Azure Mover использует Cosmos DB для хранения метаданных экземпляра. Потеря данных может произойти только в случае непоправимой катастрофы в Azure Cosmos DB. Дополнительные сведения см. в разделе "Сбои в регионе". Восстановление, инициированное Azure, является активно-пассивным, и полное восстановление региона может занять до 24 часов.

Аварийное восстановление, инициированное клиентом

Аварийное восстановление, инициированное клиентом, не ограничено парными регионами.

Перед наступлением регионального сбоя:

Разверните Storage Mover с избыточностью между зонами, создав ресурсы Storage Mover в регионе, поддерживающем зоны доступности.
Периодически ( по расписанию или после внесения существенных изменений) сделайте моментальный снимок ресурсов Mover хранилища. Хранение моментальных снимков с помощью системы управления версиями — это хороший способ хранения и отслеживания истории моментальных снимков. Вы будете использовать последний хороший моментальный снимок в случае аварии, где необходимо восстановить ресурсы в новом регионе.

Во время регионального сбоя:

Вы можете выполнить одно из двух действий.

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

Совет

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

Развертывание ресурсов в другом регионе

Дополнительные инструкции по экспорту ресурсов в качестве шаблона Azure Resource Manager (ARM) см. в документации по экспорту шаблонов .

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

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

Чтобы использовать экспортируемый шаблон для аварийного восстановления, потребуется несколько изменений в шаблоне.

Сначала удалите ресурсы Microsoft.StorageMover/agents и Microsoft.HybridCompute/machines из шаблона. Не забудьте удалить все ссылки на зависимости на эти ресурсы.
Затем удалите agentResourceId свойство из всех определений заданий. После развертывания вам потребуется назначить их новому агенту.
После удаления всех ссылок на ресурсы агента и ресурсы машины Hybrid Compute, обновите свойство расположения верхнеуровнего ресурса Storage Mover. Замените имя развернутого в настоящее время региона именем нового региона.
Наконец, определите, следует ли хранить существующий идентификатор ресурса учетной записи хранения. При необходимости замените ее другой учетной записью хранения.

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

Регистрация нового агента

Выполните действия, описанные в статье о развертывании агента Azure Storage Mover, чтобы зарегистрировать нового агента в новом ресурсе Storage Mover.

Назначение агента определениям заданий

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

См. раздел "определение нового задания миграции" для справки о доступе к определениям заданий для вашего проекта.


## Update the agent in a job definition resource
$resourceGroupName  = "[Your resource group name]"
$storageMoverName   = "[Your storage mover name]"
$projectName        = "[Your project name]"
$jobDefName         = "[Your job definition name]"
$agentName          = "[The name of an agent previously registered to the same storage mover resource]"

Update-AzStorageMoverJobDefinition `
    -ResourceGroupName $resourceGroupName `
    -StorageMoverName $storageMoverName `
    -ProjectName $projectName `
    -Name $jobDefName `
    -AgentName $agentName

Предоставление агенту доступа к целевому контейнеру хранилища

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

Теперь вы готовы начать задания по миграции, используя недавно развернутые ресурсы Storage Mover.