Używanie lokalnych klastrów rozproszony platformy Azure na potrzeby odzyskiwania po awarii

Poniższa architektura referencyjna ilustruje sposób projektowania i implementowania odzyskiwania po awarii usługi Azure Local przy użyciu klastrowania rozproszonego.

Architektura

Pobierz plik programu Visio tej architektury.

Składniki

Architektura obejmuje następujące składniki i możliwości:

• Azure Stack HCI, wersja 22H2. azure Local to rozwiązanie klastra infrastruktury hiperkonwergentnej (HCI), którego można użyć do hostowania zwirtualizowanych obciążeń systemu Windows i Linux oraz ich magazynu w hybrydowym środowisku lokalnym. Klaster rozproszony można skonfigurować z 4 do 16 węzłów fizycznych.
• repliki magazynu . Replika magazynu to technologia systemu Windows Server, która umożliwia replikację woluminów między serwerami lub klastrami w celu odzyskiwania po awarii.
• migracji na żywo. Migracja na żywo to funkcja Hyper-V w systemie Windows Server, która umożliwia bezproblemowe przenoszenie uruchomionych maszyn wirtualnych z jednego hosta Hyper-V do innego bez postrzeganego przestoju.
• monitora w chmurze. Monitor w chmurze to monitor kworum klastra trybu failover, który używa usługi Microsoft Azure Blob Storage do głosowania w kworum klastra.

Szczegóły scenariusza

Zazwyczaj używasz tej architektury do odzyskiwania po awarii z automatycznym przełączeniem w tryb failover lokalnych maszyn wirtualnych platformy Azure i udziałami plików między dwiema lokalizacjami fizycznymi w zakresie 5 ms opóźnienia sieci w obie strony.

Zalecenia

Poniższe zalecenie dotyczy większości scenariuszy. Postępuj zgodnie z zaleceniem, chyba że masz określone wymaganie, które je zastępuje.

Używanie klastrów rozproszony do implementowania zautomatyzowanego odzyskiwania po awarii dla zwirtualizowanych obciążeń i udziałów plików hostowanych na platformie Azure Lokalnie

Aby zwiększyć wbudowaną odporność lokalnej platformy Azure, zaimplementuj rozproszone wystąpienie lokalne platformy Azure składające się z dwóch grup węzłów z jedną grupą na lokację. Każda grupa musi zawierać co najmniej dwa węzły. Całkowita liczba węzłów w klastrze nie może przekraczać maksymalnej liczby węzłów obsługiwanych przez wystąpienie lokalne platformy Azure. Węzły muszą spełniać standardowe wymagania sprzętowe HCI.

Rozproszone wystąpienie lokalne platformy Azure opiera się na repliki magazynu do przeprowadzania synchronicznej replikacji magazynu między woluminami magazynu hostowanymi przez dwie grupy węzłów w odpowiednich lokacjach fizycznych. Jeśli awaria wpłynie na dostępność lokacji głównej, klaster automatycznie przenosi obciążenia do węzłów w lokacji ocalałej, aby zminimalizować potencjalny przestój. W przypadku planowanych lub oczekiwanych przestojów w lokacji głównej można użyć Hyper-V migracji na żywo, aby bezproblemowo przenieść obciążenia do innej lokacji, unikając całkowitego przestoju. W tym scenariuszu należy pamiętać o lokalizacji przechowywania. Najpierw należy odwrócić kierunek replikacji repliki magazynu, a następnie przeprowadzić migrację na żywo maszyn wirtualnych. Będzie to miało wpływ na wydajność do momentu ukończenia migracji na żywo.

Zagadnienia dotyczące

Te zagadnienia obejmują implementację filarów platformy 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ść zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Design review checklist for Reliability(Lista kontrolna dotycząca niezawodności).

• Domeny błędów na poziomie lokacji. Każda fizyczna lokacja lokalnego klastra rozproszonego platformy Azure reprezentuje odrębne domeny błędów, które zapewniają dodatkową odporność. Domena błędów to zestaw składników sprzętowych współużytkujących pojedynczy punkt awarii. Aby zapewnić odporność na uszkodzenia na określonym poziomie, na tym poziomie jest potrzebnych wiele domen błędów.

• Rozpoznawanie witryn. Rozpoznawanie witryn umożliwia kontrolowanie umieszczania zwirtualizowanych obciążeń przez wyznaczenie preferowanych witryn. Określenie preferowanej lokacji dla klastra rozproszonego oferuje wiele korzyści, w tym możliwość grupowania obciążeń na poziomie lokacji i dostosowywania opcji głosowania kworum. Domyślnie podczas zimnego uruchamiania wszystkie maszyny wirtualne używają preferowanej lokacji, chociaż można również skonfigurować preferowaną lokację na poziomie roli klastra lub grupy. Dzięki temu można przydzielić określone maszyny wirtualne do odpowiednich lokacji w trybie aktywny-aktywny. Z perspektywy kworum preferowany wybór witryny wpływa na alokację głosów w sposób, który sprzyja tej witrynie. Jeśli na przykład łączność między dwiema lokacjami hostowanymi węzłami klastra rozproszonego zakończy się niepowodzeniem, a monitor klastra nie jest osiągalny, preferowana witryna pozostaje w trybie online, podczas gdy węzły w drugiej lokacji są eksmitowane.

• Ulepszona szybkość naprawy woluminów bezpośrednich miejsc do magazynowania. Funkcja Bezpośrednie miejsca do magazynowania zapewnia automatyczną ponowną synchronizację po zdarzeniach wpływających na dostępność dysków w puli magazynów, takich jak zamknięcie jednego z węzłów klastra lub zlokalizowane awarie sprzętu. Platforma Azure Local implementuje ulepszony proces ponownej synchronizacji, który działa na znacznie bardziej szczegółowym poziomie niż Windows Server 2019. Ten proces znacznie skraca czas trwania operacji ponownej synchronizacji i minimalizuje potencjalny wpływ wielu nakładających się awarii sprzętowych.

• Limity odporności. Usługa Azure Local zapewnia wiele poziomów odporności, ale ze względu na jej hiperkonwergentną architekturę odporność podlega limitom nałożonym nie tylko przez kworum klastra , ale także przez kworum puli .

• Integracja z szeregiem usług platformy Azure, które zapewniają dodatkowe korzyści z odporności. Zwirtualizowane obciążenia działające w wystąpieniach lokalnych platformy Azure można zintegrować z takimi usługami platformy Azure, jak Azure Backup i azure Site Recovery.

• Przyspieszone przejście w tryb failover. Możesz zoptymalizować infrastrukturę sieci i jej konfigurację, aby przyspieszyć ukończenie pracy w trybie failover na poziomie lokacji. Można na przykład użyć rozproszonych wirtualnych sieci LAN (VLAN), urządzeń abstrakcji sieci i krótszych wartości czasu wygaśnięcia (TTL) w rekordach DNS reprezentujących zasoby klastrowane. Ponadto rozważ obniżenie domyślnego okresu odporności , który określa okres, w którym klasterowana maszyna wirtualna może działać w stanie izolowanym.

Bezpieczeństwo

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotyczącazabezpieczeń.

• Ochrona podczas przesyłania. Replika magazynu oferuje wbudowane zabezpieczenia ruchu replikacji, w tym podpisywanie pakietów, pełne szyfrowanie danych AES-128-GCM, obsługę przyspieszania szyfrowania intel AES-NI i zapobiegania atakom typu man-in-the-middle. Replika magazynu używa również protokołu Kerberos AES256 do uwierzytelniania między węzłami replikowania.

• Szyfrowanie magazynowane. Usługa Azure Local obsługuje szyfrowanie dysków funkcją BitLocker dla woluminów danych, co ułatwia zgodność ze standardami, takimi jak FIPS 140-2 i HIPAA.

• Integracja z szeregiem usług platformy Azure, które zapewniają dodatkowe korzyści zabezpieczeń. Zwirtualizowane obciążenia uruchomione w wystąpieniach lokalnych platformy Azure można zintegrować z takimi usługami platformy Azure, jak Microsoft Defender for Cloud

• Konfiguracja przyjazna dla zapory. Ruch repliki magazynu wymaga ograniczonej liczby otwartych portów między replikujących węzłami.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dlaoptymalizacji kosztów.

• Konfiguracja aktywna-aktywna a aktywna-pasywna. Rozproszone wystąpienia lokalne platformy Azure obsługują tryby aktywne-pasywne i aktywne-aktywne. W trybie aktywny-pasywny wyznaczona lokacja główna jednokierunkowo replikuje do innej lokacji, która zapewnia możliwość odzyskiwania po awarii. W trybie aktywny-aktywny dwie lokacje replikują swoje woluminy jednokierunkowo do siebie, zapewniając możliwość pracy w trybie failover w przypadku awarii w każdej lokacji. Tryb aktywny-aktywny pomaga zminimalizować koszty ciągłości działania, eliminując potrzebę dedykowanej lokacji odzyskiwania po awarii.

• Monitor w chmurze a monitor udziału plików. Zasób monitora jest obowiązkowym składnikiem w ramach wystąpień lokalnych platformy Azure. Aby go zaimplementować, wybierz monitor w chmurze platformy Azure lub monitor udziału plików. Monitor w chmurze platformy Azure opiera się na obiekcie blob na koncie usługi Azure Storage, które jest wyznaczane jako punkt arbitrażowy, aby zapobiec scenariuszom podziału mózgu. Monitor udziału plików opiera się na udziale plików bloku komunikatów serwera (SMB), aby osiągnąć ten sam cel.

• Deduplikacja danych. Replika lokalna i magazynowa platformy Azure obsługuje deduplikację danych. Począwszy od systemu Windows Server 2019, deduplikacja jest dostępna na woluminach sformatowanych przy użyciu systemu plików ReFS (Resilient File System), który jest zalecanym systemem plików dla platformy Azure Local. Deduplikacja pomaga zwiększyć użyteczną pojemność magazynu, identyfikując zduplikowane części plików i przechowując je tylko raz.

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 Lista kontrolna przeglądu projektu dotycząca doskonałości operacyjnej.

• Automatyczne przechodzenie w tryb failover i odzyskiwanie. Awaria lokacji głównej wyzwala automatyczne przejście w tryb failover. Po przejściu w tryb failover proces ustanawiania replikacji z nowej lokacji głównej/dawnej lokacji dodatkowej z powrotem do nowej lokacji dodatkowej/dawnej jest również automatyczny. Aby zapobiec potencjalnej utracie danych, klaster uniemożliwia powrót po awarii do czasu pełnej synchronizacji replikowanych woluminów.

• Uproszczone środowisko aprowizacji i zarządzania przy użyciu programu Windows Admin Center. Kreator tworzenia klastra w programie Windows Admin Center udostępnia interfejs oparty na kreatorze, który przeprowadzi Cię przez proces tworzenia lokalnego klastra rozproszonego platformy Azure. Kreator wykrywa, czy węzły klastra znajdują się w dwóch odrębnych lokacjach usług Active Directory Domain Services (AD DS), czy też ich adresy IP należą do dwóch różnych podsieci. Jeśli znajdują się one w dwóch różnych podsieciach, kreator automatycznie tworzy i konfiguruje odpowiednie lokacje klastra z każdą reprezentującą oddzielną domenę błędów. Umożliwia również wyznaczenie preferowanej witryny. Podobnie Windows Admin Center upraszcza proces aprowizacji replikowanych woluminów.

• Obsługa automatycznej aprowizacji klastra rozproszonego i zarządzania magazynem przy użyciu programu Windows PowerShell. Program PowerShell można uruchomić lokalnie z jednego z komputerów lokalnych platformy Azure lub zdalnie z komputera zarządzania.

• Integracja z szeregiem usług platformy Azure, które zapewniają dodatkowe korzyści operacyjne. Obciążenia zwirtualizowane uruchomione na wystąpieniach lokalnych platformy Azure można zintegrować z takimi usługami platformy Azure, jak Azure Monitor i rozwiązaniami usługi Azure Automation, w tym rozwiązaniami Change Tracking and Inventory i Update Management. Po początkowej obowiązkowej procedurze rejestracji wystąpienia lokalne platformy Azure mogą korzystać z usługi Azure Arc do monitorowania i rozliczeń. Integracja z usługą Azure Arc oferuje rozszerzoną integrację z innymi usługami hybrydowymi, takimi jak Azure Policy i Log Analytics. Rejestracja wyzwala tworzenie zasobu usługi Azure Resource Manager reprezentującego wystąpienie lokalne platformy Azure, co skutecznie rozszerza płaszczyznę zarządzania platformy Azure na lokalną platformę Azure.

Wydajność

Wydajność to zdolność obciążenia do zaspokojenia wymagań, które są na nim nakładane przez użytkowników w wydajny sposób. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu pod kątem wydajności.

• Zoptymalizowany ruch związany z replikacją. Podczas projektowania infrastruktury dla lokalnych klastrów rozproszony platformy Azure należy wziąć pod uwagę dodatkowy ruch historii wydajności repliki magazynu, migracji na żywo i klastra repliki magazynu przepływającego między lokacjami. Replikacja synchroniczna wymaga co najmniej 1 Gb zdalnego bezpośredniego dostępu do pamięci (RDMA) lub połączenia Ethernet/TCP między rozprosowanymi lokacjami klastra. Jednak w zależności od ilości ruchu replikacji może być konieczne szybsze połączenie RDMA. Należy również aprowizować wiele połączeń między lokacjami, co zapewnia korzyści z odporności i umożliwia oddzielenie ruchu repliki magazynu od ruchu migracji na żywo Hyper-V.

• Obsługa początkowej synchronizacji inicjowanej. Można zaimplementować wstępne synchronizacji początkowej w scenariuszach, w których należy zminimalizować czas synchronizacji początkowej lub gdy między dwiema lokacjami hostowanymi klastrem rozproszonym jest ograniczona przepustowość.

• Zoptymalizowane przetwarzanie operacji we/wy magazynu. Upewnij się, że optymalną konfigurację replikowanych woluminów danych i dzienników, w tym ich warstwy wydajności, rozmiaru woluminu i sektora, typu dysku i systemu plików.

Następne kroki

• omówienie rozwiązania lokalnego platformy Azure
• klastry trybu failover w systemach Windows Server i Azure Local
• wdrażanie monitora w chmurze dla klastra trybu failover
• Co nowego w lokalnej platformy Azure
• — często zadawane pytania dotyczące platformy Azure

Powiązane zasoby

• projektowanie architektury hybrydowej
• opcje hybrydowe platformy Azure
• Używanie lokalnego połączenia bez przełącznika platformy Azure i uproszczonego kworum dla biura zdalnego lub biura oddziału
• Optymalizowanie administrowania wystąpieniami programu SQL Server w środowiskach lokalnych i wielochmurowych przy użyciu usługi Azure Arc
• Azure Automation State Configuration