Architektura odzyskiwania po awarii serwera fizycznego na platformę Azure — modernizacja
W tym artykule opisano zmodernizowaną architekturę i procesy używane podczas replikacji, trybu failover i odzyskiwania fizycznych serwerów z systemem Windows i Linux między lokacją lokalną a platformą Azure przy użyciu usługi Azure Site Recovery .
Aby uzyskać informacje o wymaganiach serwera konfiguracji w wersjach klasycznych, zobacz Architektura odzyskiwania po awarii serwera fizycznego na platformie Azure.
Uwaga
Upewnij się, że utworzono nowy magazyn usługi Recovery Services na potrzeby konfigurowania urządzenia replikacji usługi ASR. Nie używaj istniejącego magazynu.
Składniki architektury
Poniższa tabela i grafika zawierają ogólny widok składników używanych do odzyskiwania po awarii maszyny fizycznej na platformie Azure.
| Składnik | Wymaganie | Szczegóły |
|---|---|---|
| Azure | Subskrypcja platformy Azure, konto usługi Azure Storage na potrzeby pamięci podręcznej, dysku zarządzanego i sieci platformy Azure. | Replikowane dane z maszyn lokalnych są przechowywane w usłudze Azure Storage. Maszyny wirtualne platformy Azure są tworzone przy użyciu replikowanych danych podczas uruchamiania trybu failover ze środowiska lokalnego na platformę Azure. Maszyny wirtualne platformy Azure nawiązują połączenie z siecią wirtualną platformy Azure, gdy są tworzone. |
| Urządzenie replikacji usługi Azure Site Recovery | Jest to podstawowy blok konstrukcyjny całej infrastruktury lokalnej usługi Azure Site Recovery. Wszystkie składniki urządzenia koordynują się z urządzeniem replikacji. Ta usługa nadzoruje wszystkie kompleksowe działania usługi Site Recovery, w tym monitorowanie kondycji chronionych maszyn, replikacji danych, automatycznych aktualizacji itp. |
Urządzenie hostuje różne kluczowe składniki, takie jak: Serwer proxy: ten składnik działa jako kanał proxy między agentem mobilności a usługami Site Recovery w chmurze. Gwarantuje to, że nie jest wymagana dodatkowa łączność z Internetem z obciążeń produkcyjnych w celu generowania punktów odzyskiwania. Odnalezione elementy: ten składnik zbiera informacje o programie vCenter i koordynuje je z usługą zarządzania usługi Azure Site Recovery w chmurze. Serwer ponownej ochrony: ten składnik koordynuje się między platformą Azure i maszynami lokalnymi podczas operacji ponownego włączania ochrony i powrotu po awarii. Serwer przetwarzania: ten składnik jest używany do buforowania, kompresji danych przed wysłaniem na platformę Azure. Dowiedz się więcej o urządzeniu replikacji i sposobie używania wielu urządzeń replikacji. Agent usługi Recovery Service: ten składnik służy do konfigurowania/rejestrowania w usługach Site Recovery oraz monitorowania kondycji wszystkich składników. Dostawca usługi Site Recovery: ten składnik służy do ułatwiania ponownej ochrony. Identyfikuje ona między lokalizacją alternatywną ponownie chroń i oryginalną lokalizację, aby ponownie chronić maszynę źródłową. Usługa replikacji: ten składnik służy do replikowania danych z lokalizacji źródłowej do platformy Azure. |
| Zreplikowane maszyny | Usługa mobilności jest instalowana na każdym serwerze fizycznym, który jest replikowany. | Zalecamy zezwolenie na automatyczną instalację usługi mobilności. Alternatywnie możesz zainstalować usługę ręcznie. |
Konfigurowanie wychodzącej łączności sieciowej
Aby usługa Site Recovery działała zgodnie z oczekiwaniami, należy zmodyfikować wychodzącą łączność sieciową, aby umożliwić replikację środowiska.
Uwaga
Usługa Site Recovery nie obsługuje sterowania łącznością sieciową za pomocą uwierzytelniającego serwera proxy.
Połączenia ruchu wychodzącego dla adresów URL
Jeśli używasz serwera proxy zapory opartego na adresach URL do kontrolowania łączności wychodzącej, zezwól na dostęp do następujących adresów URL:
| Adres URL | Szczegóły |
|---|---|
| portal.azure.com | Przejdź do witryny Azure Portal. |
*.windows.net *.msftauth.net*.msauth.net*.microsoft.com*.live.com *.office.com |
Aby zalogować się do subskrypcji platformy Azure. |
*.microsoftonline.com |
Utwórz aplikacje firmy Microsoft Entra dla urządzenia w celu komunikowania się z usługą Azure Site Recovery. |
| management.azure.com | Utwórz aplikacje firmy Microsoft Entra dla urządzenia w celu komunikowania się z usługą Azure Site Recovery. |
*.services.visualstudio.com |
Przekaż dzienniki aplikacji używane do monitorowania wewnętrznego. |
*.vault.azure.net |
Zarządzanie wpisami tajnymi w usłudze Azure Key Vault. Uwaga: Upewnij się, że maszyny do replikacji mają dostęp do tego. |
| aka.ms | Zezwalaj na dostęp do linków aka.ms. Służy do aktualizacji urządzenia usługi Azure Site Recovery. |
| download.microsoft.com/download | Zezwalaj na pobieranie ze strony pobierania przez firmę Microsoft. |
*.servicebus.windows.net |
Komunikacja między urządzeniem a usługą Azure Site Recovery. |
*.discoverysrv.windowsazure.com |
Połączenie do adresu URL usługi odnajdywania usługi Azure Site Recovery. |
*.hypervrecoverymanager.windowsazure.com |
Połączenie do adresów URL mikrousług usługi Azure Site Recovery |
*.blob.core.windows.net |
Przekazywanie danych do usługi Azure Storage, która służy do tworzenia dysków docelowych |
*.backup.windowsazure.com |
Adres URL usługi ochrony — mikrousługa używana przez usługę Azure Site Recovery do przetwarzania i tworzenia replikowanych dysków na platformie Azure |
Proces replikacji
Po włączeniu replikacji dla systemu rozpoczyna się replikacja początkowa do usługi Azure Storage przy użyciu określonych zasad replikacji. Należy zwrócić uwagę na następujące kwestie:
- W przypadku maszyn fizycznych replikacja jest na poziomie bloku, niemal ciągła, przy użyciu agenta usługa mobilności uruchomionego w systemie.
- Wszystkie ustawienia zasad replikacji są stosowane:
- Próg celu punktu odzyskiwania. To ustawienie nie ma wpływu na replikację. Pomaga to w monitorowaniu. Zostanie zgłoszone zdarzenie i opcjonalnie wysłana wiadomość e-mail, jeśli bieżący cel punktu odzyskiwania przekroczy określony limit progowy.
- Przechowywanie punktów odzyskiwania. To ustawienie określa, jak daleko w czasie chcesz przejść po wystąpieniu zakłóceń. Maksymalny okres przechowywania wynosi 15 dni.
- Migawki spójne na poziomie aplikacji. Migawka spójna na poziomie aplikacji może być wykonywana co 1 do 12 godzin, w zależności od potrzeb aplikacji. Migawki to standardowe migawki obiektów blob platformy Azure. Agent mobilności uruchomiony na maszynie fizycznej żąda migawki usługi VSS zgodnie z tym ustawieniem, a zakładki, które znajdują się w punkcie w czasie jako punkt spójny dla aplikacji w strumieniu replikacji.
Uwaga
Wysoki okres przechowywania punktu odzyskiwania może mieć wpływ na koszt magazynu, ponieważ może być konieczne zapisanie większej liczby punktów odzyskiwania.
Ruch jest replikowany do publicznych punktów końcowych usługi Azure Storage za pośrednictwem Internetu. Alternatywnie możesz użyć usługi Azure ExpressRoute z komunikacją równorzędną firmy Microsoft. Replikowanie ruchu przez wirtualną sieć prywatną typu lokacja-lokacja (VPN) z lokacji lokalnej do platformy Azure nie jest obsługiwane.
Początkowa operacja replikacji gwarantuje, że całe dane na maszynie w momencie włączenia replikacji są wysyłane na platformę Azure. Po zakończeniu replikacji początkowej rozpoczyna się replikacja zmian różnicowych na platformę Azure. Śledzone zmiany maszyny są wysyłane do serwera przetwarzania.
Komunikacja odbywa się w następujący sposób:
- Maszyny komunikują się z urządzeniem lokalnym na porcie HTTPS 443 przychodzącym na potrzeby zarządzania replikacją.
- Urządzenie organizuje replikację za pomocą platformy Azure za pośrednictwem portu HTTPS 443 wychodzącego.
- Maszyny wysyłają dane replikacji do serwera przetwarzania na porcie HTTPS 9443 przychodzącym. Ten port można zmodyfikować.
- Serwer przetwarzania odbiera dane replikacji, optymalizuje je i szyfruje oraz wysyła je do usługi Azure Storage za pośrednictwem portu 443 wychodzącego.
Dzienniki danych replikacji najpierw trafiają na konto magazynu pamięci podręcznej na platformie Azure. Te dzienniki są przetwarzane, a dane są przechowywane na dysku zarządzanym platformy Azure (nazywanym asrseeddisk). Punkty odzyskiwania są tworzone na tym dysku.
Proces pracy w trybie failover i podczas powrotu po awarii
Po skonfigurowaniu replikacji i uruchomieniu próbnego odzyskiwania po awarii (test pracy w trybie failover) w celu sprawdzenia, czy wszystko działa zgodnie z oczekiwaniami, możesz uruchomić przejście do trybu failover zgodnie z potrzebami.
Uwaga
W przypadku serwerów fizycznych powrót po awarii nie jest obsługiwany
- Możesz uruchomić tryb failover dla pojedynczej maszyny lub utworzyć plan odzyskiwania w celu jednoczesnego przejścia w tryb failover wielu serwerów. Zaletą planu odzyskiwania zamiast trybu failover pojedynczej maszyny jest:
- Zależności aplikacji można modelować, włączając wszystkie serwery w aplikacji w ramach jednego planu odzyskiwania.
- Możesz dodawać skrypty, elementy Runbook platformy Azure i wstrzymywać akcje ręczne.
- Po wyzwoleniu początkowego trybu failover należy zatwierdzić go, aby rozpocząć uzyskiwanie dostępu do obciążenia z maszyny wirtualnej platformy Azure.
Proces ponownej synchronizacji
- Czasami podczas replikacji początkowej lub podczas przesyłania zmian różnicowych mogą wystąpić problemy z łącznością sieciową między maszyną źródłową a serwerem przetwarzania lub między serwerem przetwarzania na platformie Azure. Jeden z tych elementów może prowadzić do niepowodzeń w transferze danych na platformę Azure.
- Aby uniknąć problemów z integralnością danych i zminimalizować koszty transferu danych, usługa Site Recovery oznacza maszynę do ponownej synchronizacji.
- Maszynę można również oznaczyć do ponownej synchronizacji w sytuacjach, takich jak w następujących sytuacjach, aby zachować spójność między maszyną źródłową a danymi przechowywanymi na platformie Azure
- Jeśli maszyna zostanie wymusi zamknięcie
- Jeśli maszyna przechodzi zmiany konfiguracyjne, takie jak zmiana rozmiaru dysku (modyfikowanie rozmiaru dysku z 2 TB do 4 TB)
- Ponowne synchronizowanie wysyła tylko dane różnicowe na platformę Azure. Transfer danych między środowiskiem lokalnym a platformą Azure przez zminimalizowanie przez obliczanie sum kontrolnych danych między maszyną źródłową a danymi przechowywanymi na platformie Azure.
- Domyślnie ponowna synchronizacja jest zaplanowana do automatycznego uruchamiania poza godzinami pracy. Jeśli nie chcesz czekać na domyślną ponowną synchronizację poza godzinami, możesz ponownie zsynchronizować system ręcznie. Aby to zrobić, przejdź do witryny Azure Portal, wybierz maszynę >fizyczną Ponownie za pomocą synchronizacji.
- Jeśli domyślna ponowna synchronizacja zakończy się niepowodzeniem poza godzinami pracy i wymagana jest ręczna interwencja, na określonym komputerze w witrynie Azure Portal zostanie wygenerowany błąd. Możesz usunąć błąd i ręcznie wyzwolić ponowną synchronizację.
- Po zakończeniu ponownej synchronizacji replikacja zmian różnicowych zostanie wznowiona.
Zasady replikacji
Po włączeniu replikacji maszyny wirtualnej platformy Azure usługa Site Recovery domyślnie tworzy nowe zasady replikacji z ustawieniami domyślnymi podsumowanymi w tabeli.
| Ustawienie zasad | Szczegóły | Wartość domyślna |
|---|---|---|
| Przechowywanie punktów odzyskiwania | Określa, jak długo usługa Site Recovery przechowuje punkty odzyskiwania | 1 dzień |
| Częstotliwość migawek spójnych na poziomie aplikacji | Jak często usługa Site Recovery tworzy migawkę spójną na poziomie aplikacji | Disabled |
Migawki i punkty odzyskiwania
Punkty odzyskiwania są tworzone na podstawie migawek dysków maszyny wykonanych w określonym momencie w czasie. Podczas przełączania systemu w tryb failover należy użyć punktu odzyskiwania, aby przywrócić maszynę fizyczną jako maszynę wirtualną w lokalizacji docelowej.
W przypadku przełączania w tryb failover zwykle chcemy upewnić się, że maszyna wirtualna zaczyna się od braku uszkodzenia lub utraty danych, a dane maszyny wirtualnej są spójne dla systemu operacyjnego oraz aplikacji uruchamianych na maszynie wirtualnej. Zależy to od typu wykonanych migawek.
Usługa Site Recovery tworzy migawki w następujący sposób:
- Usługa Site Recovery domyślnie tworzy migawki spójne na poziomie awarii danych i migawki spójne z aplikacjami, jeśli określisz dla nich częstotliwość.
- Punkty odzyskiwania są tworzone na podstawie migawek i przechowywane zgodnie z ustawieniami przechowywania w zasadach replikacji.
Spójność
W poniższej tabeli opisano różne typy spójności.
Spójne na poziomie awarii
| Opis | Szczegóły | Zalecenie |
|---|---|---|
| Migawka spójna na poziomie awarii przechwytuje dane, które znajdowały się na dysku podczas wykonywania migawki. Nie zawiera żadnych elementów w pamięci. Zawiera odpowiednik danych na dysku, które byłyby obecne, jeśli system uległ awarii lub przewód zasilający został ściągnięty z serwera w momencie utworzenia migawki. Spójność na poziomie awarii nie gwarantuje spójności danych dla systemu operacyjnego ani aplikacji na maszynie. |
Usługa Site Recovery domyślnie tworzy punkty odzyskiwania spójne na poziomie awarii co pięć minut. Tego ustawienia nie można zmodyfikować. |
Obecnie większość aplikacji może odzyskać się dobrze po punktach spójnych na poziomie awarii. Punkty odzyskiwania spójne na poziomie awarii są zwykle wystarczające dla replikacji systemów operacyjnych i aplikacji, takich jak serwery DHCP i serwery wydruku. |
Spójne na poziomie aplikacji
| Opis | Szczegóły | Zalecenie |
|---|---|---|
| Punkty odzyskiwania spójne na poziomie aplikacji są tworzone na podstawie migawek spójnych na poziomie aplikacji. Migawka spójna na poziomie aplikacji zawiera wszystkie informacje w migawce spójnej na poziomie awarii oraz wszystkie dane w pamięci i w toku transakcji. |
Migawki spójne na poziomie aplikacji używają usługi kopiowania woluminów w tle (VSS): 1) Usługa Azure Site Recovery używa metody kopii zapasowej tylko do kopiowania (VSS_BT_COPY), która nie zmienia czasu tworzenia kopii zapasowej dziennika transakcji programu Microsoft SQL i numeru sekwencji 2) Po zainicjowaniu migawki usługa VSS wykonuje operację kopiowania na zapis (COW) na woluminie. 3) Przed wykonaniem operacji COW usługa VSS informuje każdą aplikację na maszynie, że musi opróżnić dane rezydenta pamięci na dysk. 4) Usługa VSS umożliwia następnie aplikacji do tworzenia kopii zapasowej/odzyskiwania po awarii (w tym przypadku usługi Site Recovery) odczytywanie danych migawki i kontynuowanie. |
Migawki spójne na poziomie aplikacji są wykonywane zgodnie z ową częstotliwością. Ta częstotliwość powinna być zawsze mniejsza niż ustawiona na potrzeby przechowywania punktów odzyskiwania. Jeśli na przykład zachowasz punkty odzyskiwania przy użyciu domyślnego ustawienia 24 godzin, należy ustawić częstotliwość na mniej niż 24 godziny. Są one bardziej złożone i trwa dłużej niż migawki spójne na poziomie awarii. Mają one wpływ na wydajność aplikacji uruchomionych w systemie włączonym na potrzeby replikacji. |
Następne kroki
Wykonaj czynności opisane w tym samouczku , aby włączyć replikację maszyny fizycznej i oprogramowania VMware do platformy Azure.