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

Статья
10/31/2023

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

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

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

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

Службы с поддержкой зон доступности Azure предназначены для обеспечения правильного уровня надежности и гибкости. Их можно настроить двумя способами. Они могут быть избыточными по зонам с автоматическим реплика tion между зонами или зональными экземплярами, закрепленными в определенной зоне. Эти подходы также можно объединить. Дополнительные сведения об зональной архитектуре, избыточной между зонами, см. в Рекомендации использования зональных зон и регионов.

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

Сначала удалите все 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.

Share via