Edytuj

Korzystanie z klastrów rozproszonych usługi Azure Stack HCI w celu odzyskiwania po awarii

Azure Blob Storage
Azure Backup
Azure Monitor
Azure Stack HCI

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

Architektura

Diagram przedstawiający aktywny-aktywny i aktywny-pasywny klaster rozproszony Usługi Azure Stack HCI z woluminami magazynu i historią wydajności klastra replikowaną za pośrednictwem repliki magazynu. W trybie aktywny-aktywny ruch replikacji odbywa się w każdym kierunku, a obie lokacje hostują maszyny wirtualne usługi Azure Stack HCI. W trybie aktywne-pasywne replikacja jest jednokierunkowa z aktywną lokacją hostująca maszyny wirtualne usługi Azure Stack HCI.

Pobierz plik programu Visio z tą architekturą.

Składniki

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

  • Azure Stack HCI (20H2). Azure Stack HCI to hiperkonwergentne rozwiązanie klastra infrastruktury (HCI), które hostuje zwirtualizowane obciążenia systemu Windows i Linux oraz ich magazyn w hybrydowym środowisku lokalnym. Rozproszony klaster może składać się z czterech do 16 węzłów fizycznych.
  • Replika 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.
  • Migracja na żywo. Migracja na żywo to funkcja funkcji Hyper-V w systemie Windows Server, która umożliwia bezproblemowe przenoszenie uruchomionych maszyn wirtualnych z jednego hosta funkcji Hyper-V do drugiego bez postrzeganego przestoju.
  • Monitor chmury. Monitor w chmurze to monitor kworum klastra trybu failover, który używa Azure Blob Storage firmy Microsoft do głosowania w kworum klastra.

Szczegóły scenariusza

Ta architektura jest zwykle używana do odzyskiwania po awarii z automatycznym przejściem w tryb failover maszyn wirtualnych usługi Azure Stack HCI i udziałami plików między dwiema lokalizacjami fizycznymi w zakresie 5 ms opóźnienia sieci.

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 w usłudze Azure Stack HCI

Aby zwiększyć wbudowaną odporność usługi Azure Stack HCI, zaimplementuj rozproszony klaster Azure Stack HCI składający 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 klaster usługi Azure Stack HCI. Węzły muszą spełniać standardowe wymagania sprzętowe HCI.

Rozproszony klaster usługi Azure Stack HCI opiera się na repliki magazynu w celu przeprowadzenia synchronicznej replikacji magazynu między woluminami magazynu hostowanymi przez dwie grupy węzłów w odpowiednich lokacjach fizycznych. Jeśli awaria wpływa 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ć migracji na żywo funkcji Hyper-V do bezproblemowego przenoszenia obciążeń do innej lokacji, co pozwala całkowicie uniknąć przestojów. 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.

Uwaga

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

Przestroga

Wymaganie replikacji synchronicznej 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.

Uwaga

Funkcja podpisywania i szyfrowania repliki magazynu automatycznie chroni ruch replikacji.

Zagadnienia do rozważenia

Platforma Microsoft Azure Well-Architected Framework to zestaw wskazówek, które są przestrzegane w tej architekturze referencyjnej. Poniższe zagadnienia są oprawione w kontekście tych zestawów.

Niezawodność

Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.

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

Uwaga

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 będzie identyfikować 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 zaprojektowanie 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 lub grupy klastra. 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 faworyzuje tę witrynę. Jeśli na przykład łączność między dwoma lokacjami hostowanymi węzłami klastra rozproszonego nie powiedzie się, a monitor klastra nie jest osiągalny, preferowana lokacja pozostaje w trybie online, podczas gdy węzły w innej lokacji są eksmitowane.

  • Ulepszona szybkość naprawy woluminu Bezpośrednie miejsca do magazynowania. Bezpośrednie miejsca do magazynowania zapewnia automatyczne ponowne synchronizowanie następujących zdarzeń, które wpływają na dostępność dysków w puli magazynów, takich jak zamknięcie jednego z węzłów klastra lub zlokalizowane awarie sprzętu. Usługa Azure Stack HCI implementuje rozszerzony proces ponownego synchronizowania , 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 Stack HCI zapewnia wiele poziomów odporności, ale ze względu na jej hiperkonwergentną architekturę odporność podlega ograniczeniom nakładanym nie tylko przez kworum klastra, ale także przez kworum puli.

  • Integracja z szeregiem usług platformy Azure, które zapewniają dodatkowe zalety odporności. Możesz zintegrować zwirtualizowane obciążenia uruchomione w klastrach Azure Stack HCI z takimi usługami platformy Azure, jak Azure Backup i Azure Site Recovery.

  • Przyspieszony tryb failover. Możesz zoptymalizować infrastrukturę sieci i jej konfigurację, aby przyspieszyć ukończenie trybu failover na poziomie lokacji. Można na przykład korzystać z 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.

Przestroga

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

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.

  • Ochrona podczas przesyłania. Replika magazynu oferuje wbudowane zabezpieczenia ruchu replikacji, które obejmują 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 Stack HCI 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ń. Możesz zintegrować zwirtualizowane obciążenia uruchomione w klastrach azure Stack HCI 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 węzłami replikowania.

Przestroga

Klastry rozproszone repliki magazynu i usługi Azure Stack HCI muszą działać w środowisku usług AD DS. Podczas planowania wdrożenia rozproszonych klastrów usługi Azure Stack HCI 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 Omówienie filaru optymalizacji kosztów.

  • Konfiguracja aktywna-aktywna a aktywna-pasywna. Rozproszone klastry Usługi Azure Stack HCI obsługują tryby aktywne-pasywne i aktywne-aktywne. W trybie aktywne-pasywne 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ść trybu failover w przypadku awarii w obu lokacjach. Tryb aktywny-aktywny pomaga zminimalizować koszty ciągłości działania, eliminując konieczność dedykowanej lokacji odzyskiwania po awarii.

  • Monitor w chmurze a monitor udziału plików. Zasób monitora jest obowiązkowym składnikiem w klastrach usługi Azure Stack HCI. 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 wyznaczasz 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.

Uwaga

Monitor w chmurze platformy Azure jest zalecanym wyborem dla klastrów rozproszonych usługi Azure Stack HCI, 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. Usługa Azure Stack HCI i replika magazynu obsługują 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 usługi Azure Stack HCI. Deduplikacja pomaga zwiększyć użyteczną pojemność magazynu, identyfikując zduplikowane części plików i przechowując je tylko raz.

Przestroga

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 usługi Azure Stack HCI. Ponieważ deduplikacja danych zarządza zapisami, powinna być uruchamiana tylko na źródłowych węzłach klastra. Węzły docelowe zawsze otrzymują deduplikowane kopie każdego woluminu.

Efektywność 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.

  • 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/poprzedniej lokacji dodatkowej z powrotem do nowej lokacji dodatkowej/poprzedniej jest również automatyczny. Aby zapobiec potencjalnej utracie danych, klaster zapobiega powrotowi po awarii do momentu pełnej synchronizacji replikowanych woluminów.

  • Uproszczone środowisko aprowizacji i zarządzania przy użyciu Windows Admin Center. Kreator tworzenia klastra w Windows Admin Center udostępnia interfejs oparty na kreatorze, który przeprowadzi Cię przez proces tworzenia klastra rozproszonego usługi Azure Stack HCI. Kreator wykrywa, czy węzły klastra znajdują się w dwóch odrębnych lokacjach 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.

Uwaga

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 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 Windows PowerShell. Program PowerShell można uruchomić lokalnie z jednego z serwerów rozwiązania Azure Stack HCI lub zdalnie z komputera zarządzania.

  • Integracja z szeregiem usług platformy Azure, które zapewniają dodatkowe korzyści operacyjne. Zwirtualizowane obciążenia uruchomione w klastrach rozwiązania Azure Stack HCI można zintegrować z takimi usługami platformy Azure, jak Usługa Azure Monitor i rozwiązania Azure Automation, w tym Śledzenie zmian i spis i Update Management. Po wstępnej obowiązkowej procedurze rejestracji klastry rozwiązania Azure Stack HCI mogą korzystać z usługi Azure Arc do monitorowania i rozliczeń. Integracja usługi 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 klaster usługi Azure Stack HCI, co skutecznie rozszerza płaszczyznę zarządzania platformy Azure na usługę Azure Stack HCI.

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 wydajności.

  • Zoptymalizowany ruch związany z replikacją. Podczas projektowania infrastruktury dla klastrów rozproszonych usługi Azure Stack HCI należy wziąć pod uwagę dodatkowy ruch repliki magazynu, migracji na żywo i historii wydajności 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 funkcji Hyper-V.

Przestroga

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ć dodatkowe przepisy oddzielające je od ruchu między węzłami w tej samej lokacji.

Uwaga

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

Następne kroki