Надежность в служба хранилища Azure Mover

Статья
11/20/2024

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

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

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

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

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

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

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

Внимание

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

Необходимые компоненты

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

Взаимодействие с зонами вниз

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

Выполните действия, описанные в статье о развертывании агента служба хранилища Azure Mover, чтобы зарегистрировать новый агент в новом ресурсе 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

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

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

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

Поделиться через