Udostępnij za pośrednictwem


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. W usłudze Azure Site Recovery możliwe są dwa typy powrotu po awarii:

  • 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 tylko zmiany są replikowane z powrotem. 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 przywrócić go po awarii. 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ę wrócić po awarii do oryginalnej maszyny wirtualnej, muszą zostać spełnione 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, jego dysk twardy musi znajdować się w magazynie danych dostępnym dla hosta głównego obiektu docelowego.
  • 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 obiektu docelowego głównego. Ma to zastosowanie również w przypadku powrotu po awarii serwerów fizycznych.
  • Powrót po awarii do wirtualnej sieci magazynowania (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 są zapisywane oczekujące zmiany. Jeśli ta wartość nie jest ustawiona na wartość TRUE, usługa próbuje zidentyfikować odpowiedni lokalny zestaw VMDK na podstawie najlepszych wysiłków. Jeśli nie można odnaleźć odpowiedniego zestawu VMDK, zostanie utworzony dodatkowy dysk, a 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. Ponownie chroniony przepływ pracy tworzy lokalną maszynę wirtualną. Powoduje 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 tworzenia dysku jest 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 usługę 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. Ponowne włączanie ochrony zajmuje również więcej czasu niż odzyskiwanie oryginalnej lokalizacji.
  • Nie można powró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 tylko jako maszyna wirtualna VMware. Dzieje się tak samo jak w przypadku odzyskiwania lokalizacji alternatywnej. Upewnij się, że odnajdujesz co najmniej jeden główny serwer docelowy i niezbędne hosty ESX/ESXi, do których należy wrócić po awarii.

Następne kroki

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