Powrót po awarii maszyn wirtualnych VMware po odzyskiwaniu po awarii na platformę Azure

Po przejściu w tryb failover na platformę Azure w ramach procesu odzyskiwania po awarii możesz wrócić po awarii do lokacji lokalnej. Istnieją dwa różne typy powrotu po awarii, które są możliwe w usłudze Azure Site Recovery:

  • Powrót po awarii do oryginalnej lokalizacji
  • Powrót po awarii do lokalizacji alternatywnej

Jeśli maszyna wirtualna VMware została przełączona w tryb failover, możesz wrócić po awarii do tej samej źródłowej lokalnej maszyny wirtualnej, jeśli nadal istnieje. W tym scenariuszu replikowane są tylko zmiany. Ten scenariusz jest nazywany odzyskiwaniem oryginalnej lokalizacji. Jeśli lokalna maszyna wirtualna nie istnieje, scenariusz jest alternatywnym odzyskiwaniem lokalizacji.

Uwaga

Powrót po awarii można przywrócić tylko do oryginalnego serwera vCenter i konfiguracji. Nie można wdrożyć nowego serwera konfiguracji i wrócić po awarii przy użyciu niego. Ponadto nie można dodać nowego programu vCenter do istniejącego serwera konfiguracji i powrotu po awarii do nowego programu vCenter.

Odzyskiwanie oryginalnej lokalizacji (OLR)

Jeśli zdecydujesz się powrócić po awarii do oryginalnej maszyny wirtualnej, należy spełnić następujące warunki:

  • Jeśli maszyna wirtualna jest zarządzana przez serwer vCenter, host ESX głównego obiektu docelowego powinien mieć dostęp do magazynu danych maszyny wirtualnej.
  • Jeśli maszyna wirtualna znajduje się na hoście ESX, ale nie jest zarządzana przez program vCenter, dysk twardy maszyny wirtualnej musi znajdować się w magazynie danych, do którego może uzyskać dostęp host obiektu docelowego głównego.
  • Jeśli maszyna wirtualna znajduje się na hoście ESX i nie używa programu vCenter, przed ponownym włączeniem ochrony należy ukończyć odnajdywanie hosta ESX głównego obiektu docelowego. Dotyczy to również awarii serwerów fizycznych.
  • Powrót po awarii do sieci magazynu wirtualnego (vSAN) lub dysku opartego na nieprzetworzonym mapowaniu urządzenia (RDM), jeśli dyski już istnieją i są połączone z lokalną maszyną wirtualną.

Ważne

Należy włączyć wartość disk.enableUUID= TRUE, aby podczas powrotu po awarii usługa Azure Site Recovery mogła zidentyfikować oryginalny zestaw VMDK na maszynie wirtualnej, do której zostaną zapisane oczekujące zmiany. Jeśli ta wartość nie jest ustawiona na wartość TRUE, usługa próbuje zidentyfikować odpowiedni lokalny zestaw VMDK na podstawie najlepszego wysiłku. Jeśli odpowiedni zestaw VMDK nie zostanie znaleziony, utworzy dodatkowy dysk i dane zostaną zapisane w tym celu.

Odzyskiwanie lokalizacji alternatywnej (ALR)

Jeśli lokalna maszyna wirtualna nie istnieje przed ponownym włączeniem ochrony maszyny wirtualnej, scenariusz jest nazywany odzyskiwaniem lokalizacji alternatywnej. Przepływ pracy ponownego włączania ochrony ponownie tworzy lokalną maszynę wirtualną. Spowoduje to również pełne pobieranie danych.

  • Po powrocie po awarii do lokalizacji alternatywnej maszyna wirtualna zostanie odzyskana na tym samym hoście ESX, na którym wdrożono główny serwer docelowy. Magazyn danych używany do utworzenia dysku będzie tym samym magazynem danych, który został wybrany podczas ponownego włączania ochrony maszyny wirtualnej.
  • Powrót po awarii można przywrócić tylko do systemu plików maszyny wirtualnej (VMFS) lub magazynu danych vSAN. Jeśli masz rdM, ponowne włączanie ochrony i powrót po awarii nie będzie działać.
  • Ponowne włączanie ochrony obejmuje jeden duży początkowy transfer danych, po którym następują zmiany. Ten proces istnieje, ponieważ maszyna wirtualna nie istnieje lokalnie. Pełne dane muszą być replikowane z powrotem. Ta ponowna ochronę zajmie również więcej czasu niż oryginalne odzyskiwanie lokalizacji.
  • Nie można wrócić po awarii do dysków opartych na rdm. W magazynie danych VMFS/vSAN można tworzyć tylko nowe dyski maszyn wirtualnych.

Uwaga

Maszyna fizyczna, po przejściu w tryb failover na platformę Azure, może zostać przywrócona po awarii tylko jako maszyna wirtualna VMware. Jest to zgodny z tym samym przepływem pracy co odzyskiwanie lokalizacji alternatywnej. Upewnij się, że odnajdujesz co najmniej jeden główny serwer docelowy i niezbędne hosty ESX/ESXi, do których należy powrócić po awarii.

Następne kroki

Wykonaj kroki, aby wykonać operację powrotu po awarii.