Projektowanie klastrów rozproszony vSAN
W tym artykule dowiesz się, jak zaprojektować rozproszony klaster vSAN dla chmury prywatnej usługi Azure VMware Solution.
Tło
Globalna infrastruktura platformy Azure jest podzielona na regiony. Każdy region obsługuje usługi dla danej lokalizacji geograficznej. W każdym regionie platforma Azure tworzy izolowane i nadmiarowe wyspy infrastruktury nazywane strefami dostępności (AZ). Az działa jako granica zarządzania zasobami. Zasoby obliczeniowe i inne dostępne dla az są skończone i mogą zostać wyczerpane przez wymagania klientów. Moduł AZ jest zbudowany w taki sposób, aby był niezależnie odporny, co oznacza, że awarie w jednym az nie wpływają na inne strefy dostępności.
Dzięki rozwiązaniu Azure VMware Hosty ESXi wdrożone w standardowym klastrze vSphere tradycyjnie znajdują się w jednej strefie dostępności platformy Azure (AZ) i są chronione przez wysoką dostępność vSphere. Nie chroni jednak obciążeń przed awarią modułu AZ platformy Azure. Aby chronić się przed awarią modułu AZ, można włączyć pojedynczy klaster vSAN obejmujący dwie oddzielne strefy dostępności nazywane klastrem rozproszony vSAN.
Klastry rozproszone umożliwiają konfigurację domen błędów sieci vSAN w dwóch strefach dostępności w celu powiadamiania serwera vCenter, że hosty znajdują się w każdej strefie dostępności (AZ). Każda domena błędów ma nazwę po tym, w którym znajduje się az, aby zwiększyć przejrzystość. W przypadku rozciągnięcia klastra vSAN między dwiema strefami AZ w regionie, jeśli az spadnie, będzie traktowany jako zdarzenie vSphere HA, a maszyna wirtualna zostanie ponownie uruchomiona w innym module AZ.
Korzyści z klastra rozproszonego:
- Zwiększanie dostępności aplikacji.
- Zapewnienie zerowej możliwości celu punktu odzyskiwania (RPO) dla aplikacji dla przedsiębiorstw bez konieczności ich przeprojektowania lub wdrażania kosztownych rozwiązań odzyskiwania po awarii.
- Chmura prywatna z rozproszonymi klastrami została zaprojektowana tak, aby zapewnić dostępność na 99,99% ze względu na odporność na awarie az.
- Umożliwienie klientom skupienia się na podstawowych wymaganiach i funkcjach aplikacji zamiast na dostępności infrastruktury.
Aby chronić się przed scenariuszami podzielonymi mózgami i pomóc w mierzeniu kondycji lokacji, zarządzany monitor vSAN jest tworzony w trzecim az. W przypadku kopii danych w każdym az vSphere HA próbuje odzyskać po awarii przy użyciu prostego ponownego uruchomienia maszyny wirtualnej.
Na poniższym diagramie przedstawiono klaster vSAN rozciągnięty w dwóch strefach dostępności.
Podsumowując, rozproszone klastry upraszczają potrzeby ochrony, zapewniając te same zaufane mechanizmy kontroli i możliwości oprócz skalowania i elastyczności infrastruktury platformy Azure.
Ważne jest, aby zrozumieć, że rozproszone chmury prywatne klastra oferują tylko dodatkową warstwę odporności i nie dotyczą wszystkich scenariuszy awarii. Na przykład rozproszone chmury prywatne klastra:
- Nie chronij przed awariami na poziomie regionu w scenariuszach utraty danych ani na platformie Azure spowodowanych problemami z aplikacjami lub niewłaściwie zaplanowanymi zasadami magazynu.
- Zapewnia ochronę przed awarią pojedynczej strefy, ale nie są zaprojektowane w celu zapewnienia ochrony przed podwójnymi lub postępowymi awariami. Na przykład: .
Pomimo różnych warstw nadmiarowości wbudowanych w sieć szkieletową, jeśli awaria między az powoduje partycjonowanie lokacji dodatkowej, vSphere HA rozpoczyna zasilanie maszyn wirtualnych obciążeń w lokacji dodatkowej.
Na poniższym diagramie przedstawiono scenariusz partycjonowania lokacji dodatkowej.
Jeśli partycjonowanie lokacji dodatkowej zakończyło się niepowodzeniem lokacji głównej lub spowodowałoby ukończenie partycjonowania, program vSphere HA podejmie próbę ponownego uruchomienia maszyn wirtualnych obciążenia w lokacji dodatkowej. Jeśli vSphere HA próbowała ponownie uruchomić maszyny wirtualne obciążenia w lokacji dodatkowej, spowoduje to umieszczenie maszyn wirtualnych obciążenia w stanie niestabilności.
Na poniższych diagramach przedstawiono preferowaną awarię lokacji i kompletne scenariusze partycjonowania sieci.
Należy zauważyć, że tego typu awarie, choć rzadkie, wykraczają poza zakres ochrony oferowanej przez rozproszony chmurę prywatną klastra. Ze względu na te typy rzadkich awarii rozwiązanie klastra rozproszonego powinno być traktowane jako rozwiązanie o wysokiej dostępności obejmujące wiele az oparte na wysokiej dostępności vSphere HA. Ważne jest, aby zrozumieć, że rozwiązanie klastra rozproszonego nie ma na celu zastąpienia kompleksowej strategii odzyskiwania po awarii w wielu regionach, która może być stosowana w celu zapewnienia dostępności aplikacji. Przyczyną jest to, że rozwiązanie odzyskiwania po awarii zwykle ma oddzielne płaszczyzny zarządzania i sterowania w oddzielnych regionach świadczenia usługi Azure. Rozproszone klastry usługi Azure VMware Solution mają pojedynczą płaszczyznę zarządzania i sterowania rozciągniętą w dwóch strefach dostępności w tym samym regionie świadczenia usługi Azure. Na przykład jeden serwer vCenter, jeden klaster menedżera NSX, jedna para maszyn wirtualnych NSX Edge.
Dostępność regionów klastrów rozproszony
Rozproszone klastry usługi Azure VMware Solution są dostępne w następujących regionach:
- Południowe Zjednoczone Królestwo (na AV36 i AV36P)
- Europa Zachodnia (w usługach AV36 i AV36P)
- Niemcy Zachodnio-środkowe (w av36 i AV36P)
- Australia Wschodnia (na AV36P)
- Wschodnie stany USA (w usłudze AV36P)
Obsługiwane zasady magazynu
Następujące zasady SPBM są obsługiwane z pfTT "Podwójne dublowanie lokacji" i SFTT "RAID 1 (dublowanie)" włączone jako domyślne zasady dla klastra:
- Ustawienia odporności na awarie lokacji (PFTT):
- Dublowanie podwójnej lokacji
- Brak — zachowaj preferowane dane
- Brak — przechowywanie danych na niepreferowanych
- Błędy lokalne tolerowane (SFTT):
- 1 błąd — RAID 1 (dublowanie)
- 1 błąd — RAID 5 (kodowanie wymazywania) wymaga co najmniej czterech hostów w każdym az
- 2 błędy — RAID 1 (dublowanie)
- 2 błędy — RAID 6 (kodowanie wymazywania) wymaga co najmniej sześciu hostów w każdym az
- 3 awarie — RAID 1 (dublowanie)
Często zadawane pytania
Czy planowane są inne regiony?
Obecnie istnieją cztery regiony obsługiwane dla klastrów rozproszony.
Jakiego rodzaju umowa SLA zapewnia rozwiązanie Azure VMware Solution z rozproszonymi klastrami?
Chmura prywatna utworzona przy użyciu klastra rozproszonego vSAN została zaprojektowana tak, aby zapewnić zobowiązanie dostępności infrastruktury o 99,99%, gdy istnieją następujące warunki:
- Co najmniej sześć węzłów jest wdrażanych w klastrze (3 w każdej strefie dostępności).
- Gdy zasady magazynu maszyn wirtualnych PFTT "Dublowanie podwójnej lokacji" i SFTT 1 są używane przez maszyny wirtualne obciążenia.
- Aby osiągnąć cele dostępności, wymagana jest zgodność z dodatkowymi wymaganiami przechwyconymi w szczegółach umowy SLA rozwiązania Azure VMware Solution .
Czy mogę wybrać strefę dostępności, w której wdrożono chmurę prywatną?
L.p. Klaster rozproszony jest tworzony między dwiema strefami dostępności, podczas gdy trzecia strefa jest używana do wdrażania węzła monitora. Ponieważ wszystkie strefy są skutecznie używane do wdrażania rozproszonego środowiska klastra, wybór nie jest udostępniany klientowi. Zamiast tego klient decyduje się wdrożyć hosty w wielu strefach ZZ podczas tworzenia chmury prywatnej.
Jakie są ograniczenia, o których powinienem wiedzieć?
- Po utworzeniu chmury prywatnej za pomocą klastra rozproszonego nie można go zmienić na standardową chmurę prywatną klastra. Podobnie po utworzeniu nie można zmienić standardowej chmury prywatnej klastra na rozproszony klaster prywatny.
- Skalowanie w poziomie i skalowanie klastrów rozproszonych może odbywać się tylko w parach. Co najmniej sześć węzłów i maksymalnie 16 węzłów jest obsługiwanych w środowisku klastra rozproszonego. Aby uzyskać więcej informacji, zobacz Limity, przydziały i ograniczenia usług i subskrypcji platformy Azure.
- Maszyny wirtualne obciążenia klienta są ponownie uruchamiane z średnim priorytetem vSphere HA. Maszyny wirtualne zarządzania mają najwyższy priorytet ponownego uruchamiania.
- Rozwiązanie opiera się na vSphere HA i vSAN na potrzeby ponownego uruchamiania i replikacji. Cel czasu odzyskiwania (RTO) jest określany przez czas potrzebny vSphere HA do ponownego uruchomienia maszyny wirtualnej na ocalałym az po awarii pojedynczego az.
- Obecnie nieobsługiwane w środowisku klastra rozproszonego:
- Ostatnio wydane funkcje, takie jak publiczny adres IP w dół do sieci NSX Edge i magazynu zewnętrznego, takie jak magazyny danych ANF.
- Dodatki odzyskiwania po awarii, takie jak VMware SRM, Zerto i JetStream.
- Otwórz bilet pomocy technicznej w witrynie Azure Portal, aby zapoznać się z następującymi scenariuszami (pamiętaj, aby wybrać pozycję Klastry rozproszone jako typ problemu):
- Połączenie chmurę prywatną do rozproszonej chmury prywatnej klastra.
- Połączenie dwie rozproszone chmury prywatne klastra w jednym regionie.
Jakiego rodzaju opóźnienia należy oczekiwać między strefami dostępności (AZ)?
Klastry rozproszone vSAN działają w ciągu 5 milisekund w czasie rundy (RTT) i 10 Gb/s lub większa przepustowość między strefami ZZ hostujących maszyny wirtualne obciążenia. Wdrożenie rozproszonego klastra usługi Azure VMware Solution jest zgodne z zasadą przewodnią. Należy wziąć pod uwagę te informacje podczas wdrażania aplikacji (z SFTT podwójnego dublowania lokacji, które korzystają z synchronicznych zapisów), które mają rygorystyczne wymagania dotyczące opóźnień.
Czy mogę mieszać klastry rozproszone i standardowe w chmurze prywatnej?
L.p. Kombinacja rozproszyonych i standardowych klastrów nie jest obsługiwana w tej samej chmurze prywatnej. Podczas tworzenia chmury prywatnej wybierane jest rozproszone lub standardowe środowisko klastra. Po utworzeniu chmury prywatnej za pomocą klastra rozproszonego zakłada się, że wszystkie klastry utworzone w ramach tej chmury prywatnej mają charakter rozproszony.
Ile kosztuje rozwiązanie?
Opłaty są naliczane na podstawie liczby węzłów wdrożonych w chmurze prywatnej.
Czy opłaty są naliczane za węzeł monitora i ruch między az?
L.p. Klienci nie widzą opłat za węzeł monitora i ruch między azami. Węzeł monitora jest całkowicie zarządzany przez usługę, a rozwiązanie Azure VMware Solution zapewnia wymagane zarządzanie cyklem życia węzła monitora. Ponieważ całe rozwiązanie jest zarządzane przez usługę, klient musi zidentyfikować tylko odpowiednie zasady SPBM, które mają być ustawione dla maszyn wirtualnych obciążenia. Reszta jest zarządzana za pośrednictwem firmy Microsoft.