Udostępnij za pośrednictwem

Odzyskiwanie po awarii dla usługi Azure Automation

  • Artykuł

Dotyczy: ✔️ Maszyny wirtualne z systemem Linux maszyny wirtualne z ✔️ systemem Windows

W tym artykule wyjaśniono strategię odzyskiwania po awarii w celu obsługi awarii w całym regionie lub w całym regionie.

Musisz mieć strategię odzyskiwania po awarii, aby obsługiwać awarię usługi w całym regionie lub awarię całej strefy, aby zmniejszyć wpływ i skutki wynikające z nieprzewidywalnych zdarzeń dla twojej firmy i klientów. Odpowiadasz za skonfigurowanie odzyskiwania po awarii kont usługi Automation oraz zasobów zależnych, takich jak moduły, połączenia, poświadczenia, certyfikaty, zmienne i harmonogramy. Ważnym aspektem planu odzyskiwania po awarii jest przygotowanie do przejścia w tryb failover do repliki konta usługi Automation utworzonego z wyprzedzeniem w regionie pomocniczym, jeśli konto usługi Automation w regionie podstawowym stanie się niedostępne. Upewnij się, że strategia odzyskiwania po awarii uwzględnia twoje konto usługi Automation i zasoby zależne.

Oprócz wysokiej dostępności oferowanej przez strefy dostępności niektóre regiony są sparowane z innym regionem w celu zapewnienia ochrony przed awariami regionalnymi lub dużymi geograficznymi. Niezależnie od tego, czy region podstawowy ma parę regionalną, czy nie, strategia odzyskiwania po awarii dla konta usługi Automation pozostaje taka sama. Aby uzyskać więcej informacji na temat par regionalnych, dowiedz się więcej.

Włączanie odzyskiwania po awarii

Każde utworzone konto usługi Automation wymaga lokalizacji, której należy użyć do wdrożenia. Będzie to region podstawowy konta usługi Automation, który obejmuje zasoby, elementy Runbook utworzone dla konta usługi Automation, dane wykonywania zadań i dzienniki. W przypadku odzyskiwania po awarii konto usługi Automation repliki musi być już wdrożone i gotowe w regionie pomocniczym.

  • Zacznij od utworzenia konta usługi Automation repliki w dowolnym regionie alternatywnym.
  • Wybierz wybrany region pomocniczy — sparowany region lub dowolny inny region, w którym jest dostępna usługa Azure Automation.
  • Oprócz tworzenia repliki konta usługi Automation zreplikuj zasoby zależne, takie jak elementy Runbook, moduły, połączenia, poświadczenia, certyfikaty, zmienne, harmonogramy i uprawnienia przypisane dla konta Uruchom jako i tożsamości zarządzane w ramach konta usługi Automation w regionie podstawowym do konta usługi Automation w regionie pomocniczym. Skrypt programu PowerShell umożliwia migrowanie zasobów konta usługi Automation z jednego regionu do innego.
  • Jeśli używasz szablonów usługi ARM do definiowania i wdrażania elementów Runbook usługi Automation, możesz użyć tych szablonów do wdrożenia tych samych elementów Runbook w dowolnym innym regionie świadczenia usługi Azure, w którym tworzysz konto usługi Automation repliki. W przypadku awarii całego regionu lub awarii całej strefy w regionie podstawowym można wykonać elementy Runbook replikowane w regionie pomocniczym, aby kontynuować działalność w zwykły sposób. Gwarantuje to, że region pomocniczy będzie kontynuować pracę, jeśli region podstawowy ma zakłócenia lub awarię.

Uwaga

Ze względu na wymagania dotyczące rezydencji danych dane zadań i dzienniki obecne w regionie podstawowym nie są dostępne w regionie pomocniczym.

Scenariusze dla zadań chmurowych i hybrydowych

Scenariusz: Wykonywanie zadań w chmurze w regionie pomocniczym

W przypadku zadań w chmurze wystąpiłby niewielki przestój, pod warunkiem że konto usługi Automation repliki oraz wszystkie zasoby zależne i elementy Runbook są już wdrożone i dostępne w regionie pomocniczym. Możesz użyć konta repliki do wykonywania zadań w zwykły sposób.

Scenariusz: Wykonywanie zadań w hybrydowym procesie roboczym elementu Runbook wdrożonym w regionie innym niż podstawowy region awarii

Jeśli hybrydowy proces roboczy elementu Runbook systemu Windows lub Linux jest wdrażany przy użyciu podejścia opartego na rozszerzeniu w regionie innym niż podstawowy region awarii, wykonaj następujące kroki, aby kontynuować wykonywanie zadań hybrydowych:

  1. Usuń rozszerzenie zainstalowane w hybrydowym procesie roboczym elementu Runbook na koncie usługi Automation w regionie podstawowym.
  2. Dodaj ten sam hybrydowy proces roboczy elementu Runbook do grupy hybrydowych procesów roboczych na koncie usługi Automation w regionie pomocniczym. Rozszerzenie hybrydowego procesu roboczego jest instalowane na maszynie w repliki konta usługi Automation.
  3. Wykonaj zadania w hybrydowym procesie roboczym elementu Runbook utworzonym w kroku 2.

W przypadku hybrydowego procesu roboczego elementu Runbook wdrożonego przy użyciu podejścia opartego na agencie wybierz jedną z poniższych opcji:

Jeśli hybrydowy proces roboczy elementu Runbook systemu Windows jest wdrażany przy użyciu podejścia opartego na agencie w regionie innym niż podstawowy region awarii, wykonaj kroki, aby kontynuować wykonywanie zadań hybrydowych:

  1. Odinstaluj agenta z hybrydowego procesu roboczego elementu Runbook obecnego na koncie usługi Automation w regionie podstawowym.
  2. Zainstaluj ponownie agenta na tej samej maszynie na koncie usługi Automation repliki w regionie pomocniczym.
  3. Teraz można wykonywać zadania w hybrydowym procesie roboczym elementu Runbook utworzonym w kroku 2.

Scenariusz: Wykonywanie zadań w hybrydowym procesie roboczym elementu Runbook wdrożonym w regionie podstawowym awarii

Jeśli hybrydowy proces roboczy elementu Runbook zostanie wdrożony w regionie podstawowym i wystąpi błąd obliczeniowy w tym regionie, maszyna nie będzie dostępna do wykonywania zadań automatyzacji. Musisz aprowizować nową maszynę wirtualną w regionie alternatywnym i zarejestrować ją jako hybrydowy proces roboczy elementu Runbook na koncie usługi Automation w regionie pomocniczym.

Skrypt migracji zasobów konta usługi Automation z jednego regionu do innego

Tych skryptów można użyć do migracji zasobów konta usługi Automation z konta w regionie podstawowym do konta w regionie pomocniczym. Te skrypty służą do migrowania tylko elementów Runbook, modułów, połączeń, poświadczeń, certyfikatów i zmiennych. Wykonanie tych skryptów nie ma wpływu na konto usługi Automation i jego zasoby obecne w regionie podstawowym.

Wymagania wstępne

  1. Upewnij się, że konto usługi Automation w regionie pomocniczym jest tworzone i dostępne, aby zasoby z regionu podstawowego mogły zostać zmigrowane do niego. Preferowane jest, jeśli docelowe konto automatyzacji jest jedno bez żadnych zasobów niestandardowych, ponieważ zapobiega potencjalnemu starciu zasobów z powodu takiej samej nazwy i utraty danych.

  2. Upewnij się, że tożsamości zarządzane przypisane przez system są włączone na koncie usługi Automation w regionie podstawowym.

  3. Upewnij się, że przypisane przez system tożsamości zarządzane podstawowego konta usługi Automation mają dostęp współautora do subskrypcji, do której należy.

  4. Upewnij się, że tożsamość zarządzana podstawowego konta usługi Automation ma dostęp Współautor z uprawnieniami do odczytu i zapisu do konta usługi Automation w regionie pomocniczym. Aby włączyć, podaj niezbędne uprawnienia w tożsamościach zarządzanych konta pomocniczej usługi Automation. Dowiedz się więcej.

  5. Upewnij się, że skrypt ma dostęp do zasobów konta usługi Automation w regionie podstawowym. W związku z tym należy wykonać go jako element runbook na tym koncie usługi Automation w celu pomyślnej migracji.

  6. Jeśli podstawowe konto usługi Automation jest wdrażane przy użyciu konta Uruchom jako, przed migracją należy przełączyć je na tożsamość zarządzaną. Dowiedz się więcej.

  7. Wymagane moduły to:

    • Az.Accounts w wersji 2.8.0
    • Az.Resources w wersji 6.0.0
    • Az.Automation w wersji 1.7.3
    • Az.Storage w wersji 4.6.0

  8. Upewnij się, że zarówno źródłowe, jak i docelowe konta usługi Automation powinny należeć do tej samej dzierżawy usługi Microsoft Entra.

Tworzenie i wykonywanie elementu Runbook

Możesz użyć skryptu programu PowerShell lub elementu Runbook przepływu pracy programu PowerShell albo zaimportować go z galerii elementów Runbook i wykonać go, aby umożliwić migrację zasobów z jednego konta usługi Automation do innego.

Wykonaj kroki importowania i wykonywania elementu Runbook:

  1. Zaloguj się w witrynie Azure Portal.
  2. Przejdź do konta usługi Automation, które chcesz przeprowadzić migrację do innego regionu.
  3. W obszarze Automatyzacja procesów wybierz pozycję Elementy Runbook.
  4. Wybierz pozycję Przeglądaj galerię i w wyszukiwaniu wprowadź ciąg Migrate Automation account assets from one region to another (Migrowanie zasobów konta usługi Automation z jednego regionu do innego ) i wybierz pozycję PowerShell script (Skrypt programu PowerShell).
  5. Na stronie Importowanie elementu Runbook wprowadź nazwę elementu Runbook.
  6. Wybierz wersję środowiska uruchomieniowego jako 5.1 lub 7.1 (wersja zapoznawcza)
  7. Wprowadź opis i wybierz pozycję Importuj.
  8. Na stronie Edytowanie elementu Runbook programu PowerShell zmodyfikuj wymagane parametry i wykonaj je.

Możesz wybrać jedną z opcji edytowania i wykonywania skryptu. Można podać siedem obowiązkowych parametrów, jak podano w opcji 1 lub trzech obowiązkowych parametrów podanych w opcji 2, aby edytować i wykonywać skrypt.

Dostępne opcje:

Nazwa/nazwisko Wymagane Opis
SourceAutomationAccountName Prawda Nazwa konta usługi Automation w regionie podstawowym, z którego należy migrować zasoby.
DestinationAutomationAccountName Prawda Nazwa konta usługi Automation w regionie pomocniczym, do którego należy migrować zasoby.
SourceResourceGroup Prawda Nazwa grupy zasobów konta usługi Automation w regionie podstawowym.
DestinationResourceGroup Prawda Nazwa grupy zasobów konta usługi Automation w regionie pomocniczym.
SourceSubscriptionId Prawda Identyfikator subskrypcji konta usługi Automation w regionie podstawowym
DestinationSubscriptionId Prawda Identyfikator subskrypcji konta usługi Automation w regionie pomocniczym.
Typ[] Prawda Tablica składająca się ze wszystkich typów zasobów, które muszą zostać zmigrowane, możliwe wartości to Certyfikaty, Połączenia, Poświadczenia, Moduły, Elementy Runbook i Zmienne.

Ograniczenia

  • Skrypt migruje tylko niestandardowe moduły programu PowerShell. Domyślne moduły i pakiety języka Python nie zostaną zmigrowane do konta repliki usługi Automation.
  • Skrypt nie migruje harmonogramów i tożsamości zarządzanych znajdujących się na koncie usługi Automation w regionie podstawowym. Należy je utworzyć ręcznie na koncie usługi Automation repliki.
  • Dane zadań i dzienniki aktywności nie zostaną zmigrowane do konta repliki.

Następne kroki