Odzyskiwanie po awarii dla maszyn wirtualnych usługi Azure Stack Hub

W tym artykule opisano architekturę i zagadnienia dotyczące projektowania rozwiązania, które zapewnia zoptymalizowane podejście do odzyskiwania po awarii obciążeń uruchamianych na maszynach wirtualnych hostowanych w usłudze Azure Stack Hub.

Architektura

Pobierz plik programu Visio z tą architekturą.

Przepływ pracy

Składniki chmury proponowanego rozwiązania obejmują następujące usługi:

• Subskrypcja platformy Azure, która hostuje wszystkie zasoby w chmurze, które są częścią tego rozwiązania.

• Dzierżawa microsoft Entra ID skojarzona z subskrypcją platformy Azure, która zapewnia uwierzytelnianie podmiotów zabezpieczeń firmy Microsoft Entra w celu autoryzowania dostępu do zasobów platformy Azure.

• Magazyn usługi Azure Recovery Services w regionie świadczenia usługi Azure, który znajduje się najbliżej lokalnego centrum danych, które hostuje wdrożenie usługi Azure Stack Hub.

  Uwaga

  Wybór regionu platformy Azure znajdującego się najbliżej lokalnego centrum danych jest specyficzny dla przykładowego scenariusza zawartego w tym artykule. Z punktu widzenia odzyskiwania po awarii lepiej jest wybrać region świadczenia usługi Azure, który jest oddalony od lokalizacji, która hostuje środowisko produkcyjne. Decyzja może jednak zależeć od innych czynników, takich jak konieczność zminimalizowania opóźnienia regionalnych źródeł danych lub spełnienia wymagań dotyczących przechowywania danych.

• Obwód usługi Azure ExpressRoute, który łączy lokalne centra danych z regionem platformy Azure hostujący magazyn usługi Azure Recovery Services, skonfigurowany z prywatną komunikacją równorzędną i komunikacją równorzędną firmy Microsoft. Pierwszy zapewnia spełnienie wymagań dotyczących opóźnienia po przejściu w tryb failover. Celem tego ostatniego jest zminimalizowanie czasu replikacji zmian między obciążeniami lokalnymi a lokacją trybu failover na platformie Azure.

• Konto usługi Azure Storage, które zawiera obiekty blob zawierające pliki VHD utworzone przez replikację systemu operacyjnego i woluminów danych chronionych maszyn wirtualnych usługi Azure Stack Hub. Te pliki VHD służą jako źródło dysków zarządzanych maszyn wirtualnych platformy Azure, które są automatycznie aprowidowane po przejściu w tryb failover.

• Sieć wirtualna platformy Azure, która hostuje środowisko odzyskiwania po awarii. Jest on skonfigurowany w sposób dublujący środowisko sieci wirtualnej w usłudze Azure Stack Hub, który hostuje obciążenia produkcyjne, w tym składniki, takie jak moduły równoważenia obciążenia i sieciowe grupy zabezpieczeń. Ta sieć wirtualna jest zwykle połączona z siecią wirtualną usługi Azure Stack Hub za pośrednictwem połączenia usługi ExpressRoute w celu ułatwienia odzyskiwania na poziomie obciążenia.

  Uwaga

  Czasami wystarczy połączenie sieci VPN typu lokacja-lokacja w scenariuszach, w których wymagania celu punktu odzyskiwania (RPO) są mniej rygorystyczne.

• Izolowana sieć wirtualna platformy Azure przeznaczona do testowania trybu failover skonfigurowana w sposób dublujący środowisko sieci wirtualnej w usłudze Azure Stack Hub hostujących obciążenia produkcyjne, w tym składniki, takie jak moduły równoważenia obciążenia i sieciowe grupy zabezpieczeń.

Składniki lokalne proponowanego rozwiązania obejmują następujące usługi:

• Zintegrowany system usługi Azure Stack Hub w połączonym modelu wdrażania. System uruchamia bieżącą aktualizację (2002 od 9/20) i znajduje się w lokalnym centrum danych klienta.

• Subskrypcja usługi Azure Stack Hub i sieć wirtualna lub wiele równorzędnych sieci wirtualnych hostujących wszystkie lokalne maszyny wirtualne dla tego rozwiązania.

• Konfiguracja i serwery przetwarzania usługi Azure Site Recovery działające na maszynach wirtualnych usługi Azure Hub Stack w systemie Windows Server 2016 lub 2012 R2. Serwery zarządzają komunikacją z magazynem usługi Azure Recovery Services oraz routingiem, optymalizacją i szyfrowaniem ruchu replikacji.

  Uwaga

  Domyślnie serwer konfiguracji hostuje jeden serwer przetwarzania. Można wdrożyć dedykowane serwery przetwarzania, aby obsłużyć większy ruch związany z replikacją.

• Maszyny wirtualne usługi Azure Stack Hub, które mają być chronione. Działają obsługiwane wersje systemów operacyjnych Windows Server, CentOS i Ubuntu.

• Usługa Site Recovery usługa mobilności (nazywana również agentem mobilności), która działa na chronionych maszynach wirtualnych. Śledzi zmiany na dyskach lokalnych, rejestruje zmiany w dziennikach replikacji i replikuje dzienniki do serwera przetwarzania. Serwer przetwarzania kieruje je do docelowego konta usługi Azure Storage. Dzienniki służą do tworzenia punktów odzyskiwania dla dysków zarządzanych implementowanych przy użyciu obiektów blob przechowywanych na wyznaczonym koncie usługi Azure Storage.

Składniki

• Tożsamość Microsoft Entra
• Azure Virtual Network
• Azure Recovery Services
• Azure ExpressRoute
• Azure Blob Storage
• Azure Stack Hub

Alternatywy

Zalecane rozwiązanie opisane w tym artykule nie jest jedynym sposobem zapewnienia funkcji odzyskiwania po awarii dla obciążeń opartych na maszynach wirtualnych usługi Azure Stack Hub. Klienci mają inne opcje, w tym:

• Przejście w tryb failover do innej sygnatury usługi Azure Stack Hub. Użytkownicy, którzy muszą chronić się przed awarią centrum danych lub lokacji, mogą użyć innego wdrożenia usługi Azure Stack Hub w celu zaimplementowania aprowidowania odzyskiwania po awarii. W przypadku lokalizacji podstawowych i pomocniczych użytkownicy mogą wdrażać aplikacje w konfiguracji aktywne/pasywnej w dwóch środowiskach. W przypadku mniej krytycznych obciążeń dopuszczalne może być użycie nieużywanej pojemności w lokalizacji pomocniczej do wykonania przywracania aplikacji na żądanie z kopii zapasowej. Można również zaimplementować lokację odzyskiwania w innym centrum danych, które z kolei używa usługi Site Recovery do aprowizowania repliki lokacji odzyskiwania na platformie Azure. Kilka czynników określa, czy użycie usługi Site Recovery z platformą Azure jako lokacja trybu failover jest realnym rozwiązaniem. Te czynniki obejmują przepisy rządowe, zasady firmowe i wymagania dotyczące opóźnień.

  Uwaga

  Od lipca 2020 r. usługa Site Recovery nie obsługuje tego scenariusza, co oznacza, że implementacja musi używać rozwiązania partnerskiego lub wewnętrznego.

• Tworzenie kopii zapasowej i przywracanie. Tworzenie kopii zapasowych aplikacji i zestawów danych umożliwia szybkie odzyskiwanie po przestojach, które wynikają z uszkodzenia danych, przypadkowego usunięcia lub zlokalizowanych awarii. W przypadku aplikacji opartych na maszynach wirtualnych usługi Azure Stack Hub można użyć agenta gościa do ochrony danych aplikacji, konfiguracji systemu operacyjnego i danych przechowywanych na woluminach. Tworzenie kopii zapasowej maszyny wirtualnej przy użyciu agenta systemu operacyjnego gościa zwykle obejmuje przechwytywanie konfiguracji systemu operacyjnego, plików, folderów, woluminów, plików binarnych aplikacji i danych aplikacji. Odzyskiwanie aplikacji z agenta wymaga odtworzenia maszyny wirtualnej, a następnie instalacji systemu operacyjnego i agenta gościa. W tym momencie można przywrócić dane do systemu operacyjnego gościa.

• Tworzenie kopii zapasowych migawek dysku. Za pomocą migawek można przechwycić konfigurację maszyny wirtualnej usługi Azure Stack Hub i dyski dołączone do zatrzymanej maszyny wirtualnej. Ten proces wymaga produktów kopii zapasowych, które integrują się z interfejsami API usługi Azure Stack Hub w celu przechwytywania konfiguracji maszyny wirtualnej i tworzenia migawek dysków.

  Uwaga

  Od lipca 2020 r. używanie migawek dysków dla uruchomionej maszyny wirtualnej nie jest obsługiwane. Utworzenie migawki dysku dołączonego do uruchomionej maszyny wirtualnej może obniżyć wydajność lub wpłynąć na dostępność systemu operacyjnego lub aplikacji na maszynie wirtualnej.

• Tworzenie kopii zapasowych i przywracanie maszyn wirtualnych przy użyciu zewnętrznego rozwiązania do tworzenia kopii zapasowych w tym samym centrum danych, a następnie replikowanie kopii zapasowych do innej lokalizacji. W ten sposób można przywrócić maszyny wirtualne usługi Azure Stack Hub do tego samego wystąpienia usługi Azure Stack Hub lub do innego lub do platformy Azure.

Szczegóły scenariusza

Usługa Azure Stack Hub oferuje funkcję samonaprawiania, zapewniając automatyczne korygowanie w wielu scenariuszach obejmujących zlokalizowane awarie składników. Jednak awarie na dużą skalę, w tym awarie wpływające na stojaki serwerowe lub awarie na poziomie lokacji, wymagają dodatkowych zagadnień. Te zagadnienia powinny być częścią strategii ciągłości działania i odzyskiwania po awarii dla obciążeń użytkowników opartych na maszynach wirtualnych. Ta strategia musi również uwzględniać odzyskiwanie infrastruktury usługi Azure Stack, która jest oddzielona od odzyskiwania obciążenia.

Tradycyjne rozwiązania odzyskiwania obciążeń lokalnych są złożone w celu skonfigurowania, kosztownego i pracochłonnego utrzymania i trudności z automatyzacją, szczególnie w przypadku korzystania z innej lokalizacji lokalnej jako lokacji trybu failover. Firma Microsoft zaleca alternatywne rozwiązanie, które opiera się na połączeniu składników chmurowych i lokalnych w celu zapewnienia odpornych, opartych na wydajności, wysoce zautomatyzowanych i prostych sposobów implementowania, zabezpieczania i zarządzania opłacalną strategią odzyskiwania po awarii. Podstawowym elementem tego rozwiązania jest usługa Site Recovery z lokacją trybu failover znajdującej się na platformie Azure.

Potencjalne przypadki użycia

Usługa Site Recovery z platformą Azure jako lokacja trybu failover eliminuje wszystkie wyżej wymienione wady. Jej możliwości umożliwiają ochronę serwerów fizycznych i wirtualnych, w tym tych działających na platformach wirtualizacji Microsoft Hyper-V lub VMware ESXi. Możesz również użyć tych samych funkcji, aby ułatwić odzyskiwanie obciążeń uruchamianych na maszynach wirtualnych usługi Azure Stack Hub.

Podstawowe funkcje

Usługa Site Recovery to rozwiązanie odzyskiwania po awarii, które ułatwia ochronę komputerów fizycznych i wirtualnych, zapewniając dwa zestawy funkcji:

• Replikacja zmian na dyskach komputerowych, które znajdują się między lokalizacjami produkcyjnymi i odzyskiwania po awarii
• Orkiestracja trybu failover i powrotu po awarii między tymi dwiema lokalizacjami

Usługa Site Recovery oferuje trzy typy trybu failover:

• Testowanie pracy w trybie failover. Ten tryb failover umożliwia zweryfikowanie konfiguracji usługi Site Recovery w izolowanym środowisku bez utraty danych ani wpływu na środowisko produkcyjne.
• Planowana praca w trybie failover. Ten tryb failover umożliwia zainicjowanie odzyskiwania po awarii bez utraty danych, zwykle w ramach planowanego przestoju.
• Nieplanowane przejście w tryb failover. Ten tryb failover służy jako ostateczność w przypadku nieplanowanej awarii wpływającej na dostępność lokacji głównej i potencjalnie powodując utratę danych.

Usługa Site Recovery obsługuje kilka scenariuszy, takich jak tryb failover i powrót po awarii między dwiema lokacjami lokalnymi, tryb failover i powrót po awarii między dwoma regionami świadczenia usługi Azure oraz migracja z chmur dostawców innych firm. Jednak w kontekście tego artykułu skupimy się na replikacji dysków lokalnych maszyn wirtualnych usługi Azure Stack Hub do usługi Azure Storage oraz pracy w trybie failover i powrotu po awarii maszyny wirtualnej między stosem usługi Azure Stack Hub i regionem świadczenia usługi Azure Stack Hub.

Szczegóły architektury usługi Site Recovery i jej składników zależą od wielu kryteriów, w tym:

• Typy komputerów, które mają być chronione (fizyczne i wirtualne).
• W przypadku środowisk zwirtualizowanych typ funkcji hypervisor hostująca maszyny wirtualne do ochrony (Hyper-V a VMware ESXi).
• W przypadku środowisk funkcji Hyper-V używanie programu System Center Virtual Machine Manager (SCVMM) do zarządzania hostami funkcji Hyper-V.

W usłudze Azure Stack Hub architektura jest zgodna z architekturą, która ma zastosowanie do komputerów fizycznych. Nie jest to szczególnie zaskakujące, ponieważ w obu przypadkach usługa Site Recovery nie może korzystać z bezpośredniego dostępu do funkcji hypervisor. Zamiast tego mechanizm, który śledzi i replikuje zmiany na dyskach lokalnych, jest implementowany w chronionym systemie operacyjnym.

W tym celu usługa Site Recovery korzysta z usługa mobilności usługi Site Recovery (nazywanej również agentem mobilności), która jest automatycznie wdrażana na poszczególnych maszynach wirtualnych podczas rejestrowania ich w zakresie ochrony opartej na usłudze Site Recovery. Na każdej chronionej maszynie wirtualnej lokalnie zainstalowane wystąpienie agenta mobilności stale monitoruje i przekazuje zmiany do systemu operacyjnego i dysków danych na serwerze przetwarzania. Jednak aby zoptymalizować przepływ ruchu replikacji pochodzącego z chronionych maszyn wirtualnych i zarządzać nim, usługa Site Recovery implementuje dodatkowy zestaw składników uruchomionych na oddzielnej maszynie wirtualnej, nazywanym serwerem konfiguracji.

Serwer konfiguracji koordynuje komunikację z magazynem usługi Site Recovery i zarządza replikacją danych. Ponadto serwer konfiguracji hostuje składnik nazywany serwerem przetwarzania, który działa jako brama, odbiera dane replikacji, optymalizując je przez buforowanie i kompresję, szyfrując go, a na koniec przekazując je do usługi Azure Storage. W rzeczywistości serwer konfiguracji działa jako punkt integracji między usługą Site Recovery i chronionymi maszynami wirtualnymi uruchomionymi w usłudze Azure Stack Hub. Tę integrację należy zaimplementować, wdrażając serwer konfiguracji i rejestrując go w magazynie usługi Azure Recovery Services.

W ramach konfiguracji usługi Site Recovery należy zdefiniować zamierzone środowisko odzyskiwania po awarii, w tym takie składniki infrastruktury jak sieci wirtualne, moduły równoważenia obciążenia lub sieciowe grupy zabezpieczeń w sposób dublujący środowisko produkcyjne. Konfiguracja obejmuje również zasady replikacji, które określają możliwości odzyskiwania i składają się z następujących parametrów:

• Próg celu punktu odzyskiwania. To ustawienie reprezentuje żądany cel punktu odzyskiwania, który chcesz zaimplementować i określa częstotliwość generowania migawek punktów odzyskiwania spójnych na poziomie awarii. Jego wartość nie ma wpływu na częstotliwość replikacji, ponieważ ta replikacja jest ciągła. Usługa Site Recovery wygeneruje alert i opcjonalnie powiadomienie e-mail, jeśli bieżący obowiązujący cel punktu odzyskiwania dostarczony przez usługę Site Recovery przekroczy określony próg. Usługa Site Recovery generuje migawki punktu odzyskiwania spójne na poziomie awarii co pięć minut.

  Uwaga

  Migawka spójna na poziomie awarii przechwytuje dane, które znajdowały się na dysku podczas wykonywania migawki. Nie zawiera zawartości pamięci. W rzeczywistości migawka spójna na poziomie awarii nie gwarantuje spójności danych dla systemu operacyjnego ani aplikacji zainstalowanych lokalnie.

• Przechowywanie punktów odzyskiwania. To ustawienie reprezentuje czas trwania (w godzinach) okna przechowywania dla każdej migawki punktu odzyskiwania. Chronione maszyny wirtualne można odzyskać do dowolnego punktu odzyskiwania w oknie przechowywania. Usługa Site Recovery obsługuje do 24 godzin przechowywania maszyn wirtualnych replikowanych do kont usługi Azure Storage z warstwą wydajności Premium. W przypadku korzystania z kont usługi Azure Storage ze standardową warstwą wydajności istnieje 72-godzinny limit przechowywania.

• Częstotliwość migawek spójnych na poziomie aplikacji. To ustawienie określa częstotliwość (w godzinach), w której usługa Site Recovery generuje migawki spójne na poziomie aplikacji. Migawka spójna na poziomie aplikacji reprezentuje migawkę aplikacji działających na chronionej maszynie wirtualnej w czasie. Istnieje limit 12 migawek spójnych na poziomie aplikacji. W przypadku maszyn wirtualnych z systemem Windows Server usługa Site Recovery używa usługi kopiowania woluminów w tle (VSS). Usługa Site Recovery obsługuje również migawki spójne z aplikacjami dla systemu Linux, ale wymaga implementacji skryptów niestandardowych. Skrypty są używane przez agenta mobilności podczas stosowania migawki spójnej z aplikacją.

  Uwaga

  Aby uzyskać szczegółowe informacje dotyczące implementowania migawek spójnych na poziomie aplikacji na maszynach wirtualnych usługi Azure Stack Hub z systemem Linux, zobacz Ogólne pytania dotyczące usługi Site Recovery.

Dla każdego dysku chronionej maszyny wirtualnej usługi Azure Stack Hub wyznaczonej dane są replikowane do odpowiedniego dysku zarządzanego w usłudze Azure Storage. Dysk przechowuje kopię dysku źródłowego i wszystkie migawki spójne na poziomie awarii punktu odzyskiwania i migawki spójne na poziomie aplikacji. W ramach przejścia w tryb failover wybierasz migawkę spójną na poziomie punktu odzyskiwania lub spójną na poziomie aplikacji, która powinna być używana podczas dołączania dysku zarządzanego do maszyny wirtualnej platformy Azure, która służy jako replika chronionej maszyny wirtualnej usługi Azure Stack Hub.

Podczas zwykłych operacji biznesowych chronione obciążenia są uruchamiane na maszynach wirtualnych usługi Azure Stack Hub, a zmiany dysków są stale replikowane przez interakcje między agentem mobilności, serwerem przetwarzania i serwerem konfiguracji na wyznaczonym koncie usługi Azure Storage. Po zainicjowaniu testu, zaplanowanego lub nieplanowanego trybu failover usługa Site Recovery automatycznie aprowizuje maszyny wirtualne platformy Azure przy użyciu replik dysków odpowiednich maszyn wirtualnych usługi Azure Stack Hub.

Istnieje możliwość organizowania trybu failover przez utworzenie planów odzyskiwania zawierających kroki ręczne i zautomatyzowane. Aby zaimplementować ten ostatni, możesz użyć elementów Runbook usługi Azure Automation, które składają się z niestandardowych skryptów programu PowerShell, przepływów pracy programu PowerShell lub skryptów języka Python 2.

Po ponownym udostępnieniu lokacji głównej usługa Site Recovery obsługuje odwrócenie kierunku replikacji, co pozwala na powrót po awarii z zminimalizowanym przestojem i bez utraty danych. Jednak w przypadku usługi Azure Stack Hub ta metoda nie jest dostępna. Zamiast tego, aby powrócić po awarii, należy pobrać pliki dysku maszyny wirtualnej platformy Azure, przekazać je do usługi Azure Stack Hub i dołączyć je do istniejących lub nowych maszyn wirtualnych.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Niezawodność

Niezawodność gwarantuje, że aplikacja może spełnić zobowiązania, które należy wykonać dla klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.

Usługa Azure Stack Hub pomaga zwiększyć dostępność obciążeń dzięki odporności związanej z infrastrukturą. Ta odporność zapewnia wysoką dostępność maszyn wirtualnych usługi Azure Stack Hub chronionych przez usługę Site Recovery oraz podstawowych składników lokalnej infrastruktury usługi Site Recovery, w tym serwerów konfiguracji i przetwarzania.

Podobnie możesz użyć odporności składników chmury infrastruktury usługi Site Recovery. Domyślnie usługi Azure Recovery Services są geograficznie nadmiarowe, co oznacza, że jego konfiguracja jest automatycznie replikowana do regionu świadczenia usługi Azure będącego częścią wstępnie zdefiniowanej pary regionów. Istnieje możliwość zmiany ustawień replikacji na lokalnie nadmiarowy, jeśli jest to wystarczające dla potrzeb związanych z odpornością. Pamiętaj, że nie można zmienić tej opcji, jeśli magazyn zawiera jakiekolwiek chronione elementy. Ta sama opcja odporności jest dostępna dla wszystkich kont usługi Azure Storage ze standardową warstwą wydajności, chociaż można ją zmienić w dowolnym momencie.

Stopień odporności można dodatkowo zwiększyć, projektując i wdrażając rozwiązania rozszerzające zakres ochrony obciążeń. Jest to wartość dodana zapewniana przez usługę Site Recovery. W kontekście usługi Site Recovery działającej w usłudze Azure Stack Hub istnieją dwa główne aspekty dostępności obciążeń, które należy dokładniej zbadać:

• Przełączanie do trybu failover na platformie Azure
• Powrót po awarii do usługi Azure Stack Hub

Należy wziąć pod uwagę zarówno podczas opracowywania strategii odzyskiwania po awarii opartej na celach punktu odzyskiwania (RPO) i celów czasu odzyskiwania (RTO). Cel czasu odzyskiwania i cel punktu odzyskiwania reprezentują wymagania dotyczące ciągłości określone przez poszczególne funkcje biznesowe w organizacji. Cel punktu odzyskiwania wyznacza okres reprezentujący maksymalną akceptowalną utratę danych po incydencie, które miało wpływ na dostępność tych danych. Cel czasu odzyskiwania określa maksymalny dopuszczalny czas trwania, który może potrwać, aby przywrócić funkcje biznesowe po incydencie, które miało wpływ na dostępność tych funkcji.

Przełączanie do trybu failover na platformie Azure

Przejście w tryb failover na platformę Azure jest podstawą zagadnień dotyczących dostępności w kontekście ochrony maszyn wirtualnych usługi Azure Stack Hub na podstawie usługi Site Recovery. Aby zmaksymalizować dostępność obciążeń, strategia trybu failover powinna dotyczyć zarówno potrzeby zminimalizowania potencjalnej utraty danych (RPO) i zminimalizowania czasu pracy w trybie failover (RTO).

Aby zminimalizować potencjalną utratę danych, możesz rozważyć następujące kwestie:

• Maksymalizowanie przepływności i minimalizowanie opóźnienia ruchu replikacji, postępując zgodnie z zagadnieniami dotyczącymi skalowalności i wydajności. Aby uzyskać więcej informacji, zapoznaj się z następną sekcją tego artykułu.
• Zwiększenie częstotliwości punktów odzyskiwania spójnych na poziomie aplikacji dla obciążeń bazy danych (maksymalnie do jednego punktu odzyskiwania na godzinę). Punkty odzyskiwania spójne na poziomie aplikacji są tworzone na podstawie migawek spójnych na poziomie aplikacji. Migawki spójne z aplikacjami przechwytują dane aplikacji na dysku i w pamięci. Chociaż takie podejście minimalizuje potencjalną utratę danych, ma jedną główną wadę. Migawki spójne z aplikacjami wymagają użycia usługi kopiowania woluminów w tle w systemie Windows lub skryptów niestandardowych w systemie Linux, aby przełączać lokalnie zainstalowane aplikacje. Proces przechwytywania może zaszkodzić wydajności, zwłaszcza jeśli wykorzystanie zasobów jest wysokie. Nie zalecamy używania niskiej częstotliwości dla migawek spójnych na poziomie aplikacji dla obciążeń innych niż bazy danych.

Podstawowa metoda minimalizowania czasu pracy w trybie failover obejmuje użycie planów odzyskiwania usługi Site Recovery. Plan odzyskiwania organizuje tryb failover między lokacjami podstawowymi i dodatkowymi, definiując sekwencję, w której serwery chronione są przełączone w tryb failover. Plan można dostosować, dodając instrukcje ręczne i zadania automatyczne. Jego celem jest uczynienie procesu spójnym, dokładnym, powtarzalnym i zautomatyzowanym.

Podczas tworzenia planu odzyskiwania należy przypisać chronione serwery do grup odzyskiwania w celu przejścia w tryb failover. Serwery w każdej grupie są połączone w tryb failover. Pomaga to podzielić proces pracy awaryjnej na mniejsze, łatwiejsze w zarządzaniu jednostkami, reprezentujące zestawy serwerów, które mogą przechodzić w tryb failover bez polegania na zależnościach zewnętrznych.

Aby zminimalizować czas pracy w trybie failover, w ramach tworzenia planu odzyskiwania należy:

• Zdefiniuj grupy maszyn wirtualnych usługi Azure Stack Hub, które powinny zostać połączone w tryb failover.
• Definiowanie zależności między grupami maszyn wirtualnych usługi Azure Stack Hub w celu określenia optymalnej sekwencji trybu failover.
• Automatyzowanie zadań trybu failover, jeśli to możliwe.
• Uwzględnij niestandardowe akcje ręczne, jeśli jest to wymagane.

Należy zdefiniować plan odzyskiwania i utworzyć grupy odzyskiwania w celu przechwytywania właściwości specyficznych dla aplikacji. Rozważmy na przykład tradycyjną aplikację trójwarstwową z zapleczem opartym na programie SQL Server, składnikiem oprogramowania pośredniczącego i frontonem internetowym. Podczas tworzenia planu odzyskiwania można kontrolować kolejność uruchamiania serwerów w każdej warstwie, a serwery z uruchomionymi wystąpieniami programu SQL Server są najpierw dostępne w trybie online, a następnie te w warstwie oprogramowania pośredniczącego, a następnie przyłączone przez serwery hostujących fronton internetowy. Ta sekwencja gwarantuje, że aplikacja działa po uruchomieniu ostatniego serwera. Aby go zaimplementować, można po prostu utworzyć plan odzyskiwania z trzema grupami odzyskiwania zawierającymi serwery w odpowiednich warstwach.

Oprócz kontrolowania kolejności pracy w trybie failover i uruchamiania istnieje również możliwość dodawania akcji do planu odzyskiwania. Ogólnie rzecz biorąc, istnieją dwa typy akcji:

• Zautomatyzowane. Ta akcja jest oparta na elementach Runbook usługi Azure Automation, które obejmują jeden z dwóch typów zadań:
  • Aprowizowanie i konfigurowanie zasobów platformy Azure, w tym na przykład utworzenie publicznego adresu IP i skojarzenie go z interfejsem sieciowym dołączonym do maszyny wirtualnej platformy Azure.
  • Modyfikowanie konfiguracji systemu operacyjnego i aplikacji uruchomionych na maszynie wirtualnej platformy Azure, która została aprowizowana po przejściu w tryb failover.
• Ręczny. Ta akcja nie obsługuje automatyzacji i jest zawarta w planie odzyskiwania głównie na potrzeby dokumentacji.

Powrót po awarii do usługi Azure Stack Hub

W scenariuszach opartych na usłudze Site Recovery powrót po awarii, jeśli został prawidłowo zaimplementowany, nie obejmuje utraty danych. Oznacza to, że celem strategii trybu failover jest zminimalizowanie czasu powrotu po awarii (RTO). Jednak jak wspomniano wcześniej, podczas powrotu po awarii do usługi Azure Stack Hub nie można polegać na planach odzyskiwania. Zamiast tego powrót po awarii obejmuje następującą sekwencję kroków:

1. Zatrzymaj i cofnij przydział maszyn wirtualnych platformy Azure w środowisku odzyskiwania po awarii.
2. Zidentyfikuj parametr identyfikatora URI każdego z dysków zarządzanych dołączonych do maszyn wirtualnych, które chcesz pobrać.
3. Pobierz pliki wirtualnego dysku twardego (VHD) zidentyfikowane przez parametry identyfikatora URI zidentyfikowane w poprzednim kroku w środowisku lokalnym.
4. Przekaż pliki VHD do usługi Azure Stack Hub.
5. Dołącz przekazane dyski VHD do nowych lub istniejących maszyn wirtualnych usługi Azure Stack Hub.
6. Uruchom maszyny wirtualne usługi Azure Stack Hub.

Optymalne podejście do zminimalizowania czasu powrotu po awarii polega na zautomatyzowaniu go.

Zagadnienia dotyczące obciążenia

Usługa Site Recovery integruje się z aplikacjami i rolami opartymi na systemie Windows Server, takimi jak SharePoint, Exchange, SQL Server i domena usługi Active Directory Services (AD DS). Dzięki temu można użyć następujących funkcji w celu zaimplementowania ochrony i odzyskiwania na poziomie aplikacji:

• Integracja z technologiami replikacji na poziomie aplikacji, takimi jak zawsze włączone grupy dostępności programu SQL Server, grupy dostępności bazy danych programu Exchange i replikacja usług AD DS
• Migawki spójne na poziomie aplikacji dla aplikacji z jedną lub wieloma warstwami
• Bogata biblioteka automatyzacji, która udostępnia gotowe do produkcji skrypty specyficzne dla aplikacji, które można pobrać i zintegrować z planami odzyskiwania

Alternatywnie możesz użyć mechanizmów replikacji specyficznych dla obciążenia w celu zapewnienia odporności na poziomie lokacji. Jest to powszechnie używana opcja podczas implementowania odzyskiwania po awarii dla kontrolerów domeny usług AD DS, programu SQL Server lub programu Exchange, z których wszystkie natywnie obsługują replikację. Chociaż wymaga to aprowizacji maszyn wirtualnych platformy Azure hostujących te obciążenia w środowisku odzyskiwania po awarii, co zwiększa koszt, oferuje następujące korzyści:

• Skraca czas wymagany do przejścia w tryb failover i powrotu po awarii
• Upraszcza przechodzenie w tryb failover na poziomie obciążenia, a także scenariusze, w których tryb failover na poziomie lokacji nie jest wymagany

Zabezpieczenia

Zarządzanie odzyskiwaniem po awarii obciążeń opartych na maszynach wirtualnych użytkownika w scenariuszach hybrydowych gwarantuje dodatkowe zagadnienia dotyczące zabezpieczeń. Te zagadnienia można pogrupować w następujące kategorie:

• Szyfrowanie podczas przesyłania. Obejmuje to komunikację między chronionymi maszynami wirtualnymi usługi Azure Stack Hub, lokalnymi składnikami usługi Site Recovery i składnikami usługi Site Recovery opartymi na chmurze:

  • Agent mobilności zainstalowany na chronionych maszynach wirtualnych zawsze komunikuje się z serwerem przetwarzania za pośrednictwem protokołu Transport Layer Security (TLS) 1.2.
  • Komunikację z serwera konfiguracji na platformę Azure i z serwera przetwarzania na platformę Azure można używać protokołu TLS 1.1 lub 1.0. Aby zwiększyć poziom zabezpieczeń łączności hybrydowej, należy rozważyć wymuszanie użycia protokołu TLS 1.2.

  Uwaga

  Aby uzyskać szczegółowe informacje dotyczące konfigurowania szyfrowania opartego na protokole TLS 1.2, zapoznaj się z tematem Transport Layer Security (TLS) settings (Transport Layer Security) i Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows (Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows (Protokół TLS 1.1 i TLS 1.2)

• Szyfrowanie magazynowane. Obejmuje to usługi Azure Storage i maszyny wirtualne platformy Azure w lokacji odzyskiwania po awarii.

  • Usługa Azure Storage jest szyfrowana w spoczynku dla wszystkich kont magazynu przy użyciu 256-bitowego szyfrowania Advanced Encryption Standard i jest zgodna ze standardem Federal Information Processing Standard 140-2. Szyfrowanie jest włączane automatycznie i nie można go wyłączyć. Domyślnie szyfrowanie korzysta z kluczy zarządzanych przez firmę Microsoft, ale klienci mają możliwość używania własnych kluczy przechowywanych w usłudze Azure Key Vault.
  • Dyski zarządzane maszyn wirtualnych platformy Azure są automatycznie szyfrowane przy użyciu szyfrowania po stronie serwera dysków zarządzanych platformy Azure, które mają również zastosowanie do ich migawek, korzystając z kluczy szyfrowania zarządzanych przez platformę.

Ponadto można wymusić ograniczony dostęp do kont usługi Azure Storage hostujących zawartość dysków replikowanych przez usługę Site Recovery. W tym celu włącz tożsamość zarządzaną dla magazynu usługi Recovery Services i przypisz do tej tożsamości zarządzanej następujące role kontroli dostępu opartej na rolach (RBAC) platformy Azure na poziomie konta usługi Azure Storage:

• Konta magazynu oparte na usłudze Resource Manager (standardowa warstwa wydajności):
  • Współautor
  • Współautor danych w usłudze Blob Storage
• Konta magazynu oparte na usłudze Resource Manager (warstwa wydajności Premium):
  • Współautor
  • Właściciel danych obiektu BLOB usługi Storage

Magazyn usługi Azure Recovery Services oferuje mechanizmy, które dodatkowo chronią jego zawartość, w tym następujące zabezpieczenia:

• Kontrola dostępu oparta na rolach platformy Azure. Pozwala to na delegowanie i podział obowiązków zgodnie z zasadą najniższych uprawnień. Istnieją trzy wbudowane role związane z usługą Site Recovery, które ograniczają dostęp do operacji usługi Site Recovery:
  • Współautor usługi Site Recovery. Ta rola ma wszystkie uprawnienia wymagane do zarządzania operacjami usługi Site Recovery w magazynie usługi Azure Recovery Services. Użytkownik z tą rolą nie może jednak utworzyć ani usunąć magazynu ani przypisać praw dostępu innym użytkownikom. Ta rola jest najbardziej odpowiednia dla administratorów odzyskiwania po awarii, którzy mogą włączyć odzyskiwanie po awarii i zarządzać nim w dzierżawie usługi Azure Stack Hub.
  • Operator usługi Site Recovery. Ta rola ma uprawnienia do wykonywania operacji trybu failover i powrotu po awarii oraz zarządzania nimi. Użytkownik z tą rolą nie może włączać ani wyłączać replikacji, tworzyć ani usuwać magazynów, rejestrować nowej infrastruktury ani przypisywać praw dostępu innym użytkownikom. Ta rola jest najbardziej odpowiednia dla operatora odzyskiwania po awarii, który może przejąć maszyny wirtualne usługi Azure Stack Hub w przypadku poinstruowania przez właścicieli aplikacji i administratorów IT w rzeczywistym lub symulowanym scenariuszu awarii.
  • Czytelnik usługi Site Recovery. Ta rola ma uprawnienia do śledzenia wszystkich operacji zarządzania usługą Site Recovery. Ta rola jest najbardziej odpowiednia dla pracowników IT odpowiedzialnych za monitorowanie stanu chronionych maszyn wirtualnych usługi Azure Stack Hub i podnoszenie biletów pomocy technicznej, jeśli jest to wymagane.
• Blokady zasobów platformy Azure. Istnieje możliwość tworzenia i przypisywania blokad tylko do odczytu i usuwania do magazynu usługi Site Recovery w celu ograniczenia ryzyka przypadkowego i złośliwie zmienionego lub usuniętego magazynu.
• Usuwanie nietrwałe. Celem usuwania nietrwałego jest pomoc w ochronie magazynu i jego danych przed przypadkowym lub złośliwym usunięciem. W przypadku usuwania nietrwałego każda usunięta zawartość jest przechowywana przez 14 dodatkowych dni, co pozwala na ich pobieranie w tym okresie. Dodatkowe 14-dniowe przechowywanie zawartości magazynu nie wiąże się z żadnymi kosztami. Usuwanie nietrwałe jest domyślnie włączone.
• Ochrona operacji wrażliwych na zabezpieczenia. Magazyn usługi Azure Recovery Services umożliwia włączenie dodatkowej warstwy uwierzytelniania za każdym razem, gdy podejmowana jest próba wyłączenia ochrony. Ta dodatkowa walidacja pomaga zagwarantować, że autoryzowani użytkownicy wykonują takie operacje.
• Monitorowanie i alerty dotyczące podejrzanych działań. Usługi Azure Recovery Services zapewniają wbudowane monitorowanie i zgłaszanie alertów dotyczących zdarzeń wrażliwych na zabezpieczenia związane z operacjami magazynu.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.

Biorąc pod uwagę koszt rozwiązania do odzyskiwania po awarii opartego na usłudze Site Recovery opisanego w tym artykule, należy uwzględnić zarówno składniki lokalne, jak i oparte na chmurze. Model cen usługi Azure Stack Hub określa ceny składników lokalnych. Podobnie jak w przypadku platformy Azure usługa Azure Stack Hub oferuje układ płatności zgodnie z rzeczywistym użyciem, dostępny za pośrednictwem umów Enterprise Agreement i programu Dostawca rozwiązań w chmurze. Takie rozwiązanie obejmuje miesięczną cenę dla każdej maszyny wirtualnej z systemem Windows Server. Jeśli masz możliwość korzystania z istniejących licencji systemu Windows Server, możesz znacznie obniżyć koszt podstawowych cen maszyn wirtualnych. Jednak w przypadku usługi Site Recovery zwykle wymagana jest tylko jedna maszyna wirtualna usługi Azure Stack Hub na dzierżawę, która jest wymagana do zaimplementowania serwera konfiguracji specyficznego dla dzierżawy.

Opłaty związane z platformą Azure są skojarzone z użyciem następujących zasobów:

• Azure Recovery Services. Ceny są określane przez liczbę wystąpień chronionych. Warto zauważyć, że każde chronione wystąpienie nie powoduje naliczania opłat za usługę Site Recovery przez pierwsze 31 dni.

• Azure Storage. Ceny odzwierciedlają kombinację następujących czynników:

  • Warstwa wydajności
  • Ilość przechowywanych danych
  • Ilość wychodzącego transferu danych
  • Ilość i typy wykonanych operacji (tylko dla warstwy wydajności standardowej)
  • Nadmiarowość danych (tylko w przypadku warstwy wydajności standardowej)

• Azure ExpressRoute. Ceny są oparte na jednym z dwóch modeli:

  • Nieograniczona ilość danych. Ten model obejmuje opłatę miesięczną ze wszystkimi przychodzącymi i wychodzącymi transferami danych.
  • Mierzone dane. Ten model obejmuje miesięczną opłatę za wszystkie transfery danych przychodzących bezpłatnie i transfery danych wychodzących naliczane za GB.

  Uwaga

  Ta ocena nie obejmuje kosztów połączeń fizycznych dostarczanych przez dostawców łączności innych firm.

• Maszyny wirtualne platformy Azure. Ceny maszyn wirtualnych platformy Azure odzwierciedlają kombinację dwóch składników:

  • Koszt obliczeń. Rozmiar maszyny wirtualnej, jego czas działania i model licencjonowania systemu operacyjnego określają koszt.
  • Koszt dysku zarządzanego. Rozmiar dysku i warstwa wydajności określają koszt.

  Uwaga

  Warto zauważyć, że nawodnienie eliminuje konieczność uruchamiania maszyn wirtualnych platformy Azure podczas regularnych operacji biznesowych, a obciążenia uruchomione w usłudze Azure Stack Hub znacznie zmniejszają koszty obliczeń implementacji opartych na usłudze Site Recovery, zwłaszcza w porównaniu z tradycyjnymi rozwiązaniami odzyskiwania po awarii.

  Uwaga

  Ceny zasobów różnią się w zależności od regionów świadczenia usługi Azure.

  Uwaga

  Aby uzyskać szczegółowe informacje dotyczące cen, zapoznaj się z cennikiem platformy Azure.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Omówienie filaru doskonałości operacyjnej.

Podstawowe zagadnienia dotyczące zarządzania odzyskiwaniem po awarii opartej na usłudze Site Recovery maszyn wirtualnych usługi Azure Stack Hub obejmują:

• Implementacja usługi Site Recovery w usłudze Azure Stack Hub
• Procedury trybu failover i powrotu po awarii
• Delegowanie ról i obowiązków
• DevOps

Implementacja usługi Site Recovery w usłudze Azure Stack Hub

Aby zaimplementować usługę Site Recovery w usłudze Azure Stack Hub w małym i średnim środowisku z jedną dzierżawą, możesz postępować zgodnie z ręcznym procesem aprowizacji sterowanym przez graficzny interfejs magazynu usługi Recovery Services w witrynie Azure Portal. W przypadku implementacji z wieloma dzierżawami warto rozważyć automatyzację części procesu implementacji, ponieważ zazwyczaj trzeba skonfigurować oddzielną maszynę wirtualną serwera konfiguracji i oddzielny magazyn usługi Recovery Services dla każdej dzierżawy. Istnieje również możliwość zautomatyzowania wdrażania agenta mobilności, wykonując procedurę opisaną w temacie Przygotowywanie maszyny źródłowej do instalacji wypychanej agenta mobilności.

Procedury trybu failover i powrotu po awarii

Aby uprościć zarządzanie trybem failover, rozważ wdrożenie planów odzyskiwania dla wszystkich chronionych obciążeń. Aby uzyskać więcej informacji, zapoznaj się z sekcją Niezawodność we wcześniejszej części tego artykułu. Znajdziesz również zalecenia dotyczące optymalizacji zarządzania procedurą powrotu po awarii.

Delegowanie ról i obowiązków

Planowanie i wdrażanie odzyskiwania po awarii obciążeń opartych na maszynach wirtualnych usługi Azure Stack Hub przy użyciu usługi Site Recovery zwykle obejmuje interakcję z uczestnikami projektu:

• Operatorzy usługi Azure Stack Hub zarządzają infrastrukturą usługi Azure Stack Hub, zapewniając wystarczającą ilość zasobów obliczeniowych, magazynowych i sieciowych niezbędnych do zaimplementowania kompleksowego rozwiązania odzyskiwania po awarii i udostępnienia tych zasobów dzierżawcom. Współpracują również z właścicielami aplikacji i danych, aby ułatwić określenie optymalnego podejścia do wdrażania obciążeń w usłudze Azure Stack Hub.
• Administratorzy platformy Azure zarządzają zasobami platformy Azure niezbędnymi do wdrożenia hybrydowych rozwiązań odzyskiwania po awarii.
• Administratorzy firmy Microsoft Entra zarządzają zasobami firmy Microsoft Entra, w tym obiektami użytkowników i grup używanymi do aprowizacji, konfigurowania zasobów platformy Azure i zarządzania nimi.
• Dzierżawca usługi Azure Stack Hub projektuje, implementuje i zarządza usługą Site Recovery, w tym przejście w tryb failover i powrót po awarii.
• Użytkownicy usługi Azure Stack Hub muszą zapewnić wymagania celu punktu odzyskiwania i celu odzyskiwania punktu odzyskiwania oraz przesłać żądania wdrożenia odzyskiwania po awarii dla swoich obciążeń.

Upewnij się, że istnieje jasne zrozumienie ról i obowiązków przypisanych właścicielom i operatorom aplikacji w kontekście ochrony i odzyskiwania. Użytkownicy są odpowiedzialni za ochronę maszyn wirtualnych. Operatorzy są odpowiedzialni za stan operacyjny infrastruktury usługi Azure Stack Hub.

DevOps

Podczas konfigurowania odzyskiwania na poziomie maszyny wirtualnej przy użyciu usługi Site Recovery jest przede wszystkim odpowiedzialnym za operacje IT, istnieją pewne zagadnienia specyficzne dla metodyki DevOps, które należy uwzględnić w kompleksowej strategii odzyskiwania po awarii. Usługa Azure Stack Hub ułatwia implementowanie infrastruktury jako kodu (IaC), która obejmuje automatyczne wdrażanie różnych obciążeń, w tym aplikacji i usług opartych na maszynach wirtualnych. Za pomocą tej funkcji można usprawnić aprowizowanie scenariuszy odzyskiwania po awarii opartych na usłudze Site Recovery, co upraszcza początkową konfigurację w wielu scenariuszach dzierżawy.

Na przykład możesz użyć tych samych szablonów usługi Azure Resource Manager, aby aprowizować wszystkie zasoby sieciowe niezbędne do obsługi obciążeń opartych na maszynach wirtualnych w sygnaturze usługi Azure Stack Hub dla aplikacji w ramach jednej skoordynowanej operacji. Możesz użyć tego samego szablonu, aby aprowizować pasujący zestaw zasobów na platformie Azure w celu aprowizowania lokacji odzyskiwania po awarii. Aby uwzględnić wszelkie różnice między dwoma środowiskami, możesz po prostu określić różne wartości parametrów szablonu w każdym przypadku.

Efektywność wydajności

Efektywność wydajności to możliwość skalowania obciążenia w celu zaspokojenia zapotrzebowania użytkowników w wydajny sposób. Aby uzyskać więcej informacji, zobacz Omówienie filaru wydajności.

Podczas planowania wdrożenia usługi Site Recovery w usłudze Azure Stack Hub należy wziąć pod uwagę ilość zasobów przetwarzania, magazynu i sieci przydzielonych do serwerów konfiguracji i przetwarzania. Może być konieczne dostosowanie szacowanego rozmiaru maszyny wirtualnej usługi Azure Stack Hub obsługującej składniki usługi Site Recovery po wdrożeniu, aby uwzględnić zmiany w wymaganiach dotyczących przetwarzania lub magazynowania. Dostępne są trzy podstawowe opcje dostosowywania rozmiaru:

• Zaimplementuj skalowanie w pionie. Obejmuje to modyfikowanie ilości i typu zasobów procesora, pamięci i dysku maszyny wirtualnej usługi Azure Stack Hub hostujących serwer konfiguracji, w tym serwera przetwarzania. Aby oszacować wymagania dotyczące zasobów, możesz użyć informacji w poniższej tabeli:

  Tabela 1. Wymagania dotyczące ustalania rozmiaru serwera konfiguracji i przetwarzania

  Procesor CPU	Memory (Pamięć)	Dysk pamięci podręcznej	Szybkość zmian danych	Chronione maszyny
  8 procesorów wirtualnych 2 gniazda * 4 rdzenie @ 2,5 GHz	16 GB	300 GB	500 GB lub mniej	< 100 maszyn
  12 procesorów wirtualnych 2 gniazda * 6 rdzeni @ 2,5 GHz	18 GB	600 GB	500 GB–1 TB	Od 100 do 150 maszyn
  16 procesorów wirtualnych 2 gniazda * 8 rdzeni @ 2,5 GHz	32 GB	1 TB	1–2 TB	150–200 maszyn

• Zaimplementuj skalowanie w poziomie. Obejmuje to aprowizowanie lub anulowanie aprowizacji maszyn wirtualnych usługi Azure Stack Hub z zainstalowanym serwerem przetwarzania w celu dopasowania do wymagań przetwarzania chronionych maszyn wirtualnych usługi Azure Stack Hub. Ogólnie rzecz biorąc, jeśli konieczne jest skalowanie wdrożenia do ponad 200 maszyn źródłowych lub łączna dzienna liczba zmian wynosząca więcej niż dwa terabajty (TB), potrzebujesz dodatkowych serwerów przetwarzania do obsługi ruchu związanego z replikacją. Aby oszacować liczbę i konfigurację dodatkowych serwerów przetwarzania, zapoznaj się z zaleceniami dotyczącymi rozmiaru serwera przetwarzania.

• Modyfikowanie zasad replikacji. Obejmuje to zmianę parametrów zasad replikacji z fokusem na migawkach spójnych na poziomie aplikacji.

Z punktu widzenia sieci istnieje kilka różnych metod dostosowywania przepustowości dostępnej dla ruchu replikacji:

• Modyfikowanie rozmiaru maszyny wirtualnej. Rozmiar maszyn wirtualnych usługi Azure Stack Hub określa maksymalną przepustowość sieci. Należy jednak pamiętać, że nie ma żadnych gwarancji przepustowości. Zamiast tego maszyny wirtualne mogą korzystać z dostępnej przepustowości do limitu określonego przez ich rozmiar.

• Zamień przełączniki pasma. Systemy usługi Azure Stack Hub obsługują szereg przełączników sprzętowych, oferując kilka opcji szybkości pasma. Każdy węzeł klastra usługi Azure Stack Hub ma dwa pasma do góry przełączników stojaka w celu zapewnienia odporności na uszkodzenia. System przydziela połowę pojemności pasma dla infrastruktury krytycznej. Pozostała pojemność jest współdzielona dla usług Azure Stack Hub i całego ruchu użytkowników. Systemy wdrożone z szybszymi szybkościami mają większą przepustowość dostępną dla ruchu replikacji.

  Uwaga

  Chociaż istnieje możliwość segregowania ruchu sieciowego przez dołączenie drugiej karty sieciowej do serwera, przy użyciu maszyn wirtualnych usługi Azure Stack Hub cały ruch maszyn wirtualnych do Internetu współużytkuje ten sam pasma. Po drugie wirtualna karta sieciowa nie będzie segregować ruchu na poziomie transportu fizycznego.

• Modyfikowanie przepływności połączenia sieciowego z platformą Azure. Aby obsłużyć większy ruch związany z replikacją, warto rozważyć użycie usługi Azure ExpressRoute z komunikacją równorzędną firmy Microsoft na potrzeby połączeń między sieciami wirtualnymi usługi Azure Stack Hub i usługą Azure Storage. Usługa Azure ExpressRoute rozszerza sieci lokalne na chmurę firmy Microsoft za pośrednictwem połączenia prywatnego dostarczonego przez dostawcę łączności. Możesz kupić obwody usługi ExpressRoute dla szerokiego zakresu przepustowości, od 50 megabitów na sekundę (Mb/s) do 100 gb na sekundę.

  Uwaga

  Aby uzyskać szczegółowe informacje dotyczące implementowania usługi Azure ExpressRoute w scenariuszach usługi Azure Stack Hub, zobacz Połączenie Azure Stack Hub na platformie Azure przy użyciu usługi Azure ExpressRoute.

• Modyfikowanie ograniczania ruchu replikacji na serwerze przetwarzania. Możesz kontrolować, ile przepustowości jest używana przez ruch replikacji na maszynach wirtualnych hostujących serwery przetwarzania z interfejsu graficznego agenta usług Microsoft Azure Recovery Services. Obsługiwane możliwości obejmują ustawianie limitów dla pracy i godzin pracy, a wartości przepustowości wahają się od 512 kilobitów na sekundę do 1023 Mb/s. Alternatywnie można zastosować tę samą konfigurację przy użyciu polecenia cmdlet Set-OBMachineSetting programu PowerShell.

• Zmodyfikuj przepustowość sieci przydzieloną na chronioną maszynę wirtualną na serwerze przetwarzania. Aby to osiągnąć, zmodyfikuj wartość wpisu UploadThreadsPerVM w HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft\Windows Azure Backup\Replication key. Domyślnie wartość jest ustawiona na 4, ale można ją zwiększyć do 32, jeśli jest dostępna wystarczająca przepustowość sieci.

Wdrażanie tego scenariusza

Wymagania wstępne

Implementacja zalecanego rozwiązania jest zależna od spełnienia następujących wymagań wstępnych:

• Dostęp do subskrypcji platformy Azure z uprawnieniami wystarczającymi do aprowizowania wszystkich składników chmury składników usługi Site Recovery i zarządzania nimi, w tym:

  • Magazyn usługi Azure Recovery Services w regionie świadczenia usługi Azure Wyznaczony jako lokacja odzyskiwania po awarii dla środowiska produkcyjnego usługi Azure Stack Hub.
  • Konto usługi Azure Storage hostujące zawartość replikowanych dysków maszyn wirtualnych usługi Azure Stack Hub.
  • Sieć wirtualna platformy Azure reprezentująca środowisko odzyskiwania po awarii, z którym nawodnione maszyny wirtualne platformy Azure zostaną połączone po zaplanowanym lub nieplanowanym przejściu w tryb failover.
  • Izolowana sieć wirtualna platformy Azure reprezentująca środowisko testowe, do którego nawodnione maszyny wirtualne platformy Azure będą połączone po testowym przejściu w tryb failover.
  • Łączność oparta na usłudze Azure ExpressRoute między środowiskiem lokalnym, sieciami wirtualnymi platformy Azure i kontem usługi Azure Storage używanym do hostowania kopii plików VHD z zawartością replikowanymi z dysków chronionych maszyn wirtualnych usługi Azure Stack Hub.

• Subskrypcja użytkownika usługi Azure Stack Hub. Wszystkie maszyny wirtualne usługi Azure Stack Hub chronione przez pojedynczy serwer konfiguracji usługi Site Recovery muszą należeć do tej samej subskrypcji użytkownika usługi Azure Stack Hub.

• Sieć wirtualna usługi Azure Stack Hub. Wszystkie chronione maszyny wirtualne muszą mieć bezpośrednią łączność z maszynami wirtualnymi hostujący składnik serwera przetwarzania (domyślnie jest to maszyna wirtualna serwera konfiguracji).

• Maszyna wirtualna z systemem Windows Server usługi Azure Stack Hub, która będzie hostować serwer konfiguracji i serwer przetwarzania. Maszyna wirtualna musi należeć do tej samej subskrypcji i być dołączona do tej samej sieci wirtualnej co maszyny wirtualne usługi Azure Stack Hub, które muszą być chronione. Ponadto maszyna wirtualna musi:

  • Zgodność z wymaganiami dotyczącymi oprogramowania i sprzętu serwera konfiguracji usługi Site Recovery
  • Spełnij dokumentację wymagań dotyczących sieci łączności zewnętrznej.

  Uwaga

  Dodatkowe zagadnienia dotyczące magazynu i wydajności dla serwerów konfiguracji i przetwarzania zostały szczegółowo opisane w dalszej części tej architektury.

  • Spełnianie wymagań dotyczących łączności wewnętrznej. W szczególności maszyny wirtualne usługi Azure Stack Hub, które chcesz chronić, muszą mieć możliwość komunikowania się z:

    • Serwer konfiguracji za pośrednictwem portu TCP 443 (HTTPS) przychodzącego na potrzeby zarządzania replikacją
    • Serwer przetwarzania za pośrednictwem portu TCP 9443 w celu dostarczenia danych replikacji.

    Uwaga

    Port używany przez serwer przetwarzania dla łączności zewnętrznej i wewnętrznej można zmienić w ramach konfiguracji podczas uruchamiania ujednoliconej konfiguracji usługi Site Recovery.

• Maszyny wirtualne usługi Azure Stack Hub, które mają być chronione, uruchamiając dowolne z obsługiwanych systemów operacyjnych Aby chronić maszyny wirtualne usługi Azure Stack Hub z uruchomionymi systemami operacyjnymi Windows Server, należy:

  • Utwórz konto systemu Windows z uprawnieniami administracyjnymi. To konto można określić po włączeniu usługi Site Recovery na tych maszynach wirtualnych. Serwer przetwarzania używa tego konta do zainstalowania usługa mobilności usługi Site Recovery. W środowisku grupy roboczej należy wyłączyć kontrolę dostępu użytkowników zdalnych w docelowych systemach operacyjnych Windows Server, ustawiając wartość wpisu rejestru LocalAccountTokenFilterPolicyDWORD w HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Klucz systemu na 1.
  • Włącz udostępnianie plików i drukarek oraz reguły instrumentacji zarządzania Windows w zaporze usługi Microsoft Defender.

• Aby chronić maszyny wirtualne usługi Azure Stack Hub z uruchomionymi systemami operacyjnymi Linux, należy:

  • Utwórz konto użytkownika głównego. To konto można określić po włączeniu usługi Site Recovery na tych maszynach wirtualnych. Serwer przetwarzania używa tego konta do zainstalowania usługa mobilności usługi Site Recovery.
  • Zainstaluj najnowsze polecenia openssh, openssh-server i openssl packages.
  • Włącz i uruchom port Secure Shell (SSH) 22.
  • Włącz bezpieczny podsystem FTP i uwierzytelnianie haseł.

Ogólne kroki implementacji

Na wysokim poziomie implementacja odzyskiwania po awarii opartej na usłudze Site Recovery w usłudze Azure Stack Hub obejmuje następujące etapy:

1. Przygotuj maszyny wirtualne usługi Azure Stack Hub do ochrony przez usługę Site Recovery. Upewnij się, że maszyny wirtualne spełniają wymagania wstępne usługi Site Recovery wymienione w poprzedniej sekcji.

2. Tworzenie i konfigurowanie magazynu usługi Azure Recovery Services. Skonfiguruj magazyn usługi Azure Recovery Services i określ, co chcesz replikować. Składniki i działania usługi Site Recovery są konfigurowane i zarządzane przy użyciu magazynu.

3. Skonfiguruj środowisko replikacji źródłowej. Aprowizuj serwer konfiguracji usługi Site Recovery i serwer przetwarzania, instalując pliki binarne ujednoliconej konfiguracji usługi Site Recovery i rejestrując go w magazynie.

   Uwaga

   Możesz ponownie uruchomić ujednoliconą konfigurację usługi Site Recovery, aby zaimplementować dodatkowe serwery przetwarzania na maszynach wirtualnych usługi Azure Stack Hub.

4. Skonfiguruj docelowe środowisko replikacji. Utwórz lub wybierz istniejące konto usługi Azure Storage i sieć wirtualną platformy Azure w regionie świadczenia usługi Azure, które będzie hostować lokację odzyskiwania po awarii. Podczas replikacji zawartość dysków chronionych maszyn wirtualnych usługi Azure Stack Hub jest kopiowana na konto usługi Azure Storage. Podczas pracy w trybie failover usługa Site Recovery automatycznie aprowizuje maszyny wirtualne platformy Azure obsługujące jako repliki chronionych maszyn wirtualnych usługi Azure Stack Hub i łączy je z siecią wirtualną platformy Azure.

5. Włącz replikację. Skonfiguruj ustawienie replikacji i włącz replikację dla maszyn wirtualnych usługi Azure Stack Hub. Usługa mobilności jest instalowana automatycznie na każdej maszynie wirtualnej usługi Azure Stack Hub, dla której włączono replikację. Usługa Site Recovery inicjuje replikację każdej maszyny wirtualnej usługi Azure Stack Hub zgodnie z zdefiniowanymi ustawieniami zasad.

6. Przeprowadź test pracy w trybie failover. Po ustanowieniu replikacji sprawdź, czy tryb failover będzie działać zgodnie z oczekiwaniami, wykonując test pracy w trybie failover.

7. Wykonaj planowane lub nieplanowane przejście w tryb failover. Po pomyślnym przejściu w tryb failover możesz przeprowadzić planowane lub nieplanowane przejście w tryb failover na platformę Azure. Istnieje możliwość wyznaczenia maszyn wirtualnych usługi Azure Stack Hub do uwzględnienia w trybie failover.

8. Wykonaj powrót po awarii. Gdy wszystko będzie gotowe do powrotu po awarii, zatrzymaj maszyny wirtualne platformy Azure odpowiadające maszynom wirtualnym usługi Azure Stack Hub, pobierz pliki dysków do magazynu lokalnego, przekaż je do usługi Azure Stack Hub i dołącz je do istniejącej lub nowej maszyny wirtualnej.

Podsumowanie

Podsumowując, usługa Azure Stack Hub to unikatowa oferta, która różni się w wielu aspektach od innych platform wirtualizacji. W związku z tym uzasadnia ona szczególne uwagi w odniesieniu do strategii ciągłości działania dla obciążeń. Korzystając z usług platformy Azure, można uprościć projektowanie i implementowanie tej strategii. W tym artykule referencyjnym dotyczącym architektury omówiliśmy użycie usługi Microsoft Site Recovery do ochrony obciążeń opartych na maszynach wirtualnych usługi Azure Stack Hub w połączonym modelu wdrażania. Takie podejście umożliwia klientom korzystanie z odporności i możliwości zarządzania usługą Azure Stack Hub oraz z hiperskala i globalnej obecności chmury platformy Azure.

Należy pamiętać, że rozwiązanie odzyskiwania po awarii opisane tutaj koncentruje się wyłącznie na obciążeniach opartych na maszynach wirtualnych usługi Azure Stack Hub. Jest to tylko część ogólnej strategii ciągłości działania, która powinna uwzględniać inne typy obciążeń i scenariusze usługi Azure Stack Hub, które mają wpływ na ich dostępność.

Następne kroki

Dokumentacja produktu:

• Informacje o usłudze Site Recovery
• Omówienie usługi Azure Stack Hub
• Co to jest identyfikator Entra firmy Microsoft?
• Co to jest usługa Azure Blob Storage?
• Co to jest usługa Azure ExpressRoute?
• Co to jest usługa Azure Virtual Network?

Moduły microsoft Learn:

• Azure Stack Hub
• Konfigurowanie identyfikatora entra firmy Microsoft
• Konfigurowanie kont magazynu
• Konfigurowanie sieci wirtualnych
• Projektowanie i implementowanie usługi Azure ExpressRoute
• Projektowanie rozwiązania do odzyskiwania lokacji na platformie Azure

Powiązane zasoby

• Projektowanie architektury hybrydowej
• Tworzenie kopii zapasowych plików i aplikacji w usłudze Azure Stack Hub
• Połączenia hybrydowe
• Hybrydowy udział plików z odzyskiwaniem po awarii dla zdalnych i lokalnych pracowników oddziałów