Edytuj

Udostępnij za pośrednictwem

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

Lokalna platforma Azure
Azure Blob Storage
Azure Backup
Azure Monitor

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

Architektura

Diagram ilustrujący aktywny-aktywny i aktywny-pasywny klaster rozproszony platformy Azure z woluminami magazynu i historią wydajności klastra replikowaną za pomocą repliki magazynu. W trybie aktywny-aktywny ruch replikacji odbywa się w każdym kierunku, a obie lokacje hostuje lokalne maszyny wirtualne platformy Azure. W trybie aktywny-pasywny replikacja jest jednokierunkowa, a aktywna lokacja hostuje lokalne maszyny wirtualne platformy Azure.

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.

Nuta

Replikacja synchroniczna zapewnia spójność awarii z zerową utratą danych na poziomie systemu plików podczas pracy w trybie failover.

Ostrożność

Synchroniczne wymaganie replikacji mające zastosowanie do klastrów rozproszonych nakłada limit 5 ms opóźnienia sieci między dwiema grupami węzłów klastra w replikowanych lokacjach. W zależności od cech łączności sieciowej fizycznej ograniczenie to zwykle przekłada się na około 20-30 mil fizycznych.

Nuta

Funkcja podpisywania i szyfrowania repliki magazynu automatycznie chroni ruch związany z replikacją.

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.

Nuta

Jeśli każda lokalizacja odpowiada oddzielnej lokacji usług AD DS, proces aprowizacji klastra automatycznie konfiguruje przypisanie lokacji. Jeśli nie ma oddzielnych lokacji usług AD DS reprezentujących dwie lokalizacje, ale węzły znajdują się w dwóch różnych podsieciach, proces aprowizacji klastra zidentyfikuje lokacje na podstawie przypisań podsieci. Jeśli węzły znajdują się w tej samej podsieci, należy jawnie zdefiniować przypisanie lokacji.

  • 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 wszystkie maszyny wirtualne używają preferowanej lokacji podczas zimnego startu, chociaż istnieje również możliwość skonfigurowania preferowanej lokacji 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. Załóżmy na przykład, że łączność między dwiema lokacjami hostowanymi węzłami klastra rozproszonego kończy się niepowodzeniem, a monitor klastra nie jest osiągalny. W takim przypadku preferowana witryna pozostaje w trybie online, podczas gdy węzły w innej 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.

Ostrożność

Korzystanie z klastrów rozproszonych z siecią SDN jest uważane za zaawansowaną konfigurację i należy skontaktować się z integratorem systemów lub pomocą techniczną firmy Microsoft, aby uzyskać dalszą pomoc.

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.

Ostrożność

Replika magazynu i lokalne klastry rozproszone platformy Azure muszą działać w środowisku usług AD DS. Podczas planowania wdrożenia klastrów rozproszony platformy Azure upewnij się, że łączność z kontrolerami domeny usług AD DS w każdej lokacji hostuje węzły klastra.

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.

Nuta

Monitor w chmurze platformy Azure jest zalecanym wyborem dla klastrów rozproszony platformy Azure, pod warunkiem że wszystkie węzły serwera w klastrze mają niezawodne połączenia internetowe. Odpowiednie opłaty za platformę Azure są niewielkie; są one oparte na cenie małego obiektu blob z rzadkimi aktualizacjami odpowiadającymi zmianom stanu klastra. W scenariuszach obejmujących klastry rozproszone monitor udziału plików powinien znajdować się w trzeciej lokacji, co może znacznie zwiększyć koszty implementacji, chyba że trzecia lokacja jest już dostępna i ma istniejące niezawodne połączenia z lokacjami hostowanymi węzłami klastra rozproszonego.

  • 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.

Ostrożność

Mimo że należy zainstalować usługę roli serwera deduplikacji danych na serwerach źródłowych i docelowych, nie należy włączać deduplikacji danych w węzłach docelowych w klastrze rozproszonych platformy Azure. Ponieważ deduplikacja danych zarządza zapisami, powinna być uruchamiana tylko w źródłowych węzłach klastra. Węzły docelowe zawsze otrzymują deduplikowane kopie każdego woluminu.

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.

Nuta

Tworzenie woluminów i dysków wirtualnych dla klastrów rozproszony jest bardziej zaangażowane niż w przypadku klastrów z jedną lokacją. Klastry rozproszone wymagają co najmniej czterech woluminów składających się z dwóch woluminów danych i dwóch woluminów dziennika z parą woluminów danych/dziennika w każdej lokacji. Podczas tworzenia replikowanego woluminu danych przy użyciu programu Windows Admin Center proces automatycznie aprowizuje wolumin dziennika w lokacji głównej oraz zarówno dane, jak i woluminy replikowane dzienników w lokacji dodatkowej, zapewniając, że każdy z nich ma wymagany rozmiar i ustawienia konfiguracji.

  • 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.

Ostrożność

Funkcja RDMA jest domyślnie włączona dla całego ruchu między węzłami klastra w tej samej lokacji w tej samej podsieci. Funkcja RDMA jest wyłączona i nie jest obsługiwana między lokacjami lub między różnymi podsieciami. Należy wyłączyć funkcję SMB Direct dla ruchu między lokacjami lub zaimplementować dodatkowych aprowizowanie, które oddzielają go od ruchu między węzłami w tej samej lokacji.

  • 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.

Nuta

Program Windows Admin Center automatycznie przypisuje optymalną konfigurację, jeśli używasz jej do aprowizacji woluminów klastra rozproszonego .

Następne kroki