Аварийное восстановление для службы автоматизации Azure

Область применения: ✔️ Виртуальные машины Linux ✔️ Виртуальные машины Windows

В этой статье объясняется стратегия восстановления после катастроф для решения региональных отказов.

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

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

Чтобы узнать больше о надёжности Cлужба автоматизации Azure, включая высокую доступность через поддержку зоны доступности, см. раздел «Надежность в Cлужба автоматизации Azure».

Включение аварийного восстановления

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

• Начните с создания резервной учетной записи службы автоматизации в любом другом регионе.
• Выберите дополнительный регион вашего выбора — парный регион или любой другой регион, где доступен служба автоматизации Azure.
• Помимо создания реплики учетной записи Automation, необходимо реплицировать зависимые ресурсы, такие как runbook-и, модули, подключения, учетные данные, сертификаты, переменные, расписания и разрешения, назначенные для учетной записи Run As и управляемых удостоверений, из учетной записи Automation в основном регионе в учетную запись Automation во вторичном регионе. Скрипт PowerShell можно использовать для переноса ресурсов учетной записи службы автоматизации из одного региона в другой.
• Если вы используете шаблоны ARM для определения и развертывания модулей Runbook службы автоматизации, эти шаблоны можно использовать для развертывания тех же модулей Runbook в любом другом регионе Azure, где вы создаете учетную запись реплики службы автоматизации. В случае сбоя во всём основном регионе вы можете выполнить сценарии, реплицированные во вторичный регион, чтобы продолжить работу в обычном режиме. Такой подход гарантирует, что вторичный регион возьмёт на себя ответственность за продолжение работы в случае сбоя или отказа в первичном регионе.

Сценарии для облачных и гибридных заданий

Сценарий. Выполнение облачных заданий в дополнительном регионе

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

Сценарий: запуск заданий в Hybrid Runbook Worker, развернутом в регионе, отличном от основного региона, в котором произошёл сбой

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

1. Удалите расширение, установленное на гибридном рабочем процессе Runbook в учетной записи Automation в основном регионе.
2. Добавьте тот же гибридный рабочий процесс Runbook Worker в группу гибридных рабочих процессов в учётной записи Automation во вторичном регионе. Расширение гибридного рабочего процесса установлено на компьютере в реплицированной учетной записи службы автоматизации.
3. Выполните задания в Hybrid Runbook Worker, созданном на шаге 2.

Сценарий: Выполнение заданий в гибридном рабочем процессе Runbook, развернутом в основном регионе, в котором произошел сбой

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

• См. шаги по установке в статье о развертывании пользовательского гибридного рабочего процесса Runbook для Windows или Linux на основе расширений.

Скрипт для переноса ресурсов учетной записи службы автоматизации из одного региона в другой

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

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

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

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

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

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

5. Убедитесь, что скрипт имеет доступ к ресурсам учетной записи службы автоматизации в основном регионе. Таким образом, он должен выполняться в качестве модуля Runbook в этой учетной записи службы автоматизации для успешной миграции.

6. Обязательные модули:

   • Az.Accounts версии 2.8.0
   • Az.Resources версии 6.0.0
   • Az.Automation версии 1.7.3
   • Az.Storage версии 4.6.0

7. Убедитесь, что учетные записи исходной и целевой службы автоматизации должны принадлежать одному клиенту Microsoft Entra.

Создание и выполнение модуля Runbook

Вы можете использовать скрипт PowerShell или рабочий процесс PowerShell в модуле runbook либо импортировать его из коллекции Runbook и выполнить, чтобы обеспечить возможность миграции ресурсов из одной учетной записи Automation в другую.

Выполните действия по импорту и выполнению модуля Runbook:

Доступные параметры:

Ограничения

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

Следующие шаги

• Надежность в Cлужба автоматизации Azure
• Регионы, поддерживающие зоны доступности.