Notfallwiederherstellung für Azure Automation

  • Artikel

Gilt für: ✔️ Linux-VMs ✔️ Windows-VMs

In diesem Artikel wird eine Notfallwiederherstellungsstrategie zum Behandeln eines regions- oder zonenweiten Ausfalls erläutert.

Sie benötigen eine Notfallwiederherstellungsstrategie zum Behandeln eines regionsweiten Dienstausfalls oder eines zonenweiten Ausfalls, um die Auswirkungen unvorhersehbarer Ereignisse auf Ihr Unternehmen und Ihre Kundschaft zu verringern. Sie sind dafür verantwortlich, eine Notfallwiederherstellung von Automation-Konten und den abhängigen Ressourcen wie Modulen, Verbindungen, Anmeldeinformationen, Zertifikaten, Variablen und Zeitplänen einzurichten. Ein wichtiger Aspekt eines Notfallwiederherstellungsplans ist die Vorbereitung eines Failovers auf das Replikat des Automation-Kontos, das im Voraus in der sekundären Region erstellt wurde, wenn das Automation-Konto in der primären Region nicht mehr verfügbar ist. Stellen Sie sicher, dass Ihre Notfallwiederherstellungsstrategie Ihr Automation-Konto und die abhängigen Ressourcen einschließt.

Zusätzlich zur Hochverfügbarkeit, die von Verfügbarkeitszonen angeboten wird, sind einige Regionen mit einer anderen Region gekoppelt, um Schutz vor regionalen oder großen geografischen Katastrophen zu bieten. Die Notfallwiederherstellungsstrategie für das Automation-Konto ist unabhängig davon, ob die primäre Region über eine regionale Kopplung verfügt. Weitere Informationen zu regionalen Paaren finden Sie hier.

Aktivieren der Notfallwiederherstellung

Jedes Automation-Konto, das Sie erstellen, erfordert einen Speicherort für die Bereitstellung. Dies ist die primäre Region für Ihr Automation-Konto und umfasst Ressourcen, für das Automation-Konto erstellte Runbooks, Auftragsausführungsdaten und Protokolle. Für die Notfallwiederherstellung muss das Automation-Replikatkonto bereits in der sekundären Region bereitgestellt und bereit sein.

  • Erstellen Sie zunächst ein Automation-Replikatkonto in einer beliebigen alternativen Region.
  • Wählen Sie die gewünschte sekundäre Region aus: eine gekoppelte Region oder eine andere Region, in der Azure Automation verfügbar ist.
  • Neben dem Erstellen eines Replikats des Automation-Kontos replizieren Sie die abhängigen Ressourcen wie Runbooks, Module, Verbindungen, Anmeldeinformationen, Zertifikate, Variablen, Zeitpläne und Berechtigungen, die für das ausführende Konto und verwaltete Identitäten im Automation-Konto in der primären Region zugewiesen sind, in das Automation-Konto in der sekundären Region. Sie können das PowerShell-Skript zum Migrieren von Ressourcen des Automation-Kontos von einer Region in eine andere verwenden.
  • Wenn Sie ARM-Vorlagen zum Definieren und Bereitstellen von Automation-Runbooks verwenden, können Sie mit diesen Vorlagen dieselben Runbooks in der anderen Azure-Region bereitstellen, in der Sie das Automation-Replikatkonto erstellen. Bei einem regionsweiten Ausfall oder einem zonenweiten Ausfall in der primären Region können Sie die in der sekundären Region replizierten Runbooks ausführen, um die Geschäftstätigkeit normal fortzusetzen. Dadurch wird sichergestellt, dass die Arbeit in der sekundären Region fortgesetzt werden kann, wenn die primäre Region eine Unterbrechung oder einen Ausfall aufweist.

Hinweis

Aufgrund von Datenresidenzanforderungen sind Auftragsdaten und Protokolle in der primären Region nicht in der sekundären Region verfügbar.

Szenarien für Cloud- und Hybridaufträge

Szenario: Ausführen von Cloudaufträgen in der sekundären Region

Bei Cloudaufträgen kommt es zu einer vernachlässigbaren Ausfallzeit, sofern ein Automation-Replikatkonto und alle abhängigen Ressourcen und Runbooks bereits in der sekundären Region bereitgestellt und verfügbar sind. Sie können das Replikatkonto wie gewohnt zum Ausführen von Aufträgen verwenden.

Szenario: Ausführen von Aufträgen auf einem Hybrid Runbook Worker, die in einer anderen Region als der primären ausgefallenen Region bereitgestellt sind

Wenn der Windows- oder Linux-Hybrid Runbook Worker mit dem erweiterungsbasierten Ansatz in einer anderen Region als der primären ausgefallenen bereitgestellt wird, führen Sie die folgenden Schritte aus, um die Ausführung der Hybridaufträge fortzusetzen:

  1. Löschen Sie die auf Hybrid Runbook Worker im Automation-Konto in der primären Region installierte Erweiterung.
  2. Fügen Sie den gleichen Hybrid Runbook Worker einer Hybrid Worker-Gruppe im Automation-Konto in der sekundären Region hinzu. Die Hybrid Worker-Erweiterung wird auf dem Computer im Replikat des Automation-Kontos installiert.
  3. Führen Sie die Aufträge auf dem in Schritt 2 erstellten Hybrid Runbook Worker aus.

Wählen Sie für Hybrid Runbook Worker, die mithilfe des agentbasierten Ansatzes bereitgestellt werden, eine der folgenden Optionen aus:

Wenn der Windows-Hybrid Runbook Worker mit einem agentbasierten Ansatz in einer anderen Region als der primären ausgefallenen bereitgestellt wird, führen Sie die folgenden Schritte aus, um die Ausführung von Hybridaufträgen fortzusetzen:

  1. Deinstallieren Sie den Agent aus dem Hybrid Runbook Worker im Automation-Konto in der primären Region.
  2. Installieren Sie den Agent erneut auf dem gleichen Computer im Automation-Replikatkonto in der sekundären Region.
  3. Sie können nun die Aufträge auf dem in Schritt 2 erstellten Hybrid Runbook Worker ausführen.

Szenario: Ausführen von Aufträgen auf einem Hybrid Runbook Worker, der in der primären ausgefallenen Region bereitgestellt ist

Wenn der Hybrid Runbook Worker in der primären Region bereitgestellt wurde und in dieser Region ein Computeausfall auftritt, ist der Computer nicht für die Ausführung von Automation-Aufträgen verfügbar. Sie müssen einen neuen virtuellen Computer in einer alternativen Region bereitstellen und ihn als Hybrid Runbook Worker im Automation-Konto in der sekundären Region registrieren.

Skript zum Migrieren von Automation-Kontoressourcen von einer Region in eine andere

Sie können diese Skripts für die Migration von Automation-Kontoressourcen vom Konto in der primären Region zum Konto in der sekundären Region verwenden. Mit diesen Skripts werden nur Runbooks, Module, Verbindungen, Anmeldeinformationen, Zertifikate und Variablen migriert. Die Ausführung dieser Skripts wirkt sich nicht auf das Automation-Konto und seine Ressourcen in der primären Region aus.

Voraussetzungen

  1. Stellen Sie sicher, dass das Automation-Konto in der sekundären Region erstellt wurde und verfügbar ist, damit Ressourcen aus der primären Region zu diesem migriert werden können. Das Automation-Zielkonto sollte bevorzugt ein Konto ohne benutzerdefinierte Ressourcen sein, da dadurch ein potenzieller Ressourcenkonflikt aufgrund desselben Namens und Datenverluste verhindert werden.

  2. Stellen Sie sicher, dass die systemseitig zugewiesenen verwalteten Identitäten im Automation-Konto in der primären Region aktiviert sind.

  3. Stellen Sie sicher, dass die systemseitig zugewiesenen verwalteten Identitäten des primären Automation-Kontos über den Zugriff „Mitwirkender“ auf das zugehörige Abonnement verfügen.

  4. Stellen Sie sicher, dass die verwaltete Identität des primären Automation-Kontos über den Zugriff „Mitwirkender“ mit Lese- und Schreibberechtigungen für das Automation-Konto in der sekundären Region verfügt. Legen Sie zum Aktivieren die erforderlichen Berechtigungen in den verwalteten Identitäten des sekundären Automation-Kontos fest. Weitere Informationen

  5. Stellen Sie sicher, dass das Skript Zugriff auf die Automation-Kontoressourcen in der primären Region hat. Es sollte somit für eine erfolgreiche Migration als Runbook in diesem Automation-Konto ausgeführt werden.

  6. Wenn das primäre Automation-Konto mithilfe eines ausführenden Kontos bereitgestellt wird, muss es vor der Migration auf verwaltete Identität umgestellt werden. Weitere Informationen

  7. Erforderliche Module sind:

    • Az.Accounts, Version 2.8.0
    • Az.Resources, Version 6.0.0
    • Az.Automation, Version 1.7.3
    • Az.Storage, Version 4.6.0

  8. Stellen Sie sicher, dass das Automation-Quellkonto und das Zielkonto zum selben Microsoft Entra-Mandanten gehören.

Erstellen und Ausführen des Runbooks

Sie können dasPowerShell-Skript oder das Runbook PowerShell-Workflow verwenden oder aus es dem Runbook-Katalog importieren und ausführen, um die Migration der Ressourcen von einem Automation-Konto zu einem anderen zu ermöglichen.

Führen Sie die Schritte zum Importieren und Ausführen des Runbooks aus:

  1. Melden Sie sich beim Azure-Portal an.
  2. Wechseln Sie zu dem Automation-Konto, das Sie zu einer anderen Region migrieren möchten.
  3. Wählen Sie unter Prozessautomatisierung die Option Runbooks aus.
  4. Wählen Sie Katalog durchsuchen aus, geben Sie in der Suche Migrieren von Automation-Kontoressourcen von einer Region in eine andere ein, und wählen Sie PowerShell-Skript aus.
  5. Geben Sie auf der Seite Runbook importieren einen Namen für das Runbook ein.
  6. Wählen Sie für Runtimeversion eine der Optionen 5.1 oder 7.1 (Vorschauversion) aus.
  7. Geben Sie die Beschreibung ein, und wählen Sie Importieren aus.
  8. Bearbeiten Sie auf der Seite PowerShell-Runbook bearbeiten die erforderlichen Parameter, und führen Sie es aus.

Sie können eine der Optionen zum Bearbeiten und Ausführen des Skripts auswählen. Sie können sieben obligatorische Parameter gemäß Option 1 oder drei obligatorische Parameter gemäß Option 2 angeben, um das Skript zu bearbeiten und auszuführen.

Die Optionen sind:

Name Erforderlich Beschreibung
SourceAutomationAccountName True Name des Automation-Kontos in der primären Region, von dem Ressourcen migriert werden müssen
DestinationAutomationAccountName True Name des Automation-Kontos in der sekundären Region, zu dem Ressourcen migriert werden müssen
SourceResourceGroup True Ressourcengruppenname des Automation-Kontos in der primären Region
DestinationResourceGroup True Ressourcengruppenname des Automation-Kontos in der sekundären Region
SourceSubscriptionId True Abonnement-ID des Automation-Kontos in der primären Region
DestinationSubscriptionId True Abonnement-ID des Automation-Kontos in der sekundären Region
Typ[] True Array aus allen Typen von Ressourcen, die migriert werden müssen. Mögliche Werte sind Zertifikate, Verbindungen, Anmeldeinformationen, Module, Runbooks und Variablen.

Begrenzungen

  • Das Skript migriert nur benutzerdefinierte PowerShell-Module. Standardmodule und Python-Pakete werden nicht zum Automation-Replikatkonto migriert.
  • Das Skript migriert keine vorhandenen Zeitpläne und verwalteten Identitäten im Automation-Konto in der primären Region. Diese müssen manuell im Automation-Replikatkonto erstellt werden.
  • Auftragsdaten und Aktivitätsprotokolle werden nicht zum Replikatkonto migriert.

Nächste Schritte