Stretched vSAN-clusters ontwerpen

In dit artikel leert u hoe u een vSAN stretched cluster ontwerpt voor een Azure VMware Solution-privécloud.

Achtergrond

De wereldwijde infrastructuur van Azure is onderverdeeld in regio's. Elke regio ondersteunt de services voor een bepaalde geografie. Binnen elke regio bouwt Azure geïsoleerde en redundante eilanden van infrastructuur met de naam beschikbaarheidszones (AZ). Een AZ fungeert als een grens voor resourcebeheer. De rekenresources en andere resources die beschikbaar zijn voor een AZ zijn eindig en kunnen uitgeput raken door de behoeften van de klant. Een AZ is gebouwd om onafhankelijk tolerant te zijn, wat betekent dat fouten in de ene AZ geen invloed hebben op andere AZ's.

Met Azure VMware Solution bevinden ESXi-hosts die zijn geïmplementeerd in een standaard vSphere-cluster zich traditioneel in één Azure-beschikbaarheidszone (AZ) en worden beveiligd door hoge beschikbaarheid van vSphere. De workloads worden echter niet beschermd tegen een Azure AZ-fout. Ter bescherming tegen een AZ-fout kan één vSAN-cluster worden ingeschakeld om twee afzonderlijke beschikbaarheidszones te omvatten, een vSAN-stretched cluster genoemd.

Met stretched clusters kan de configuratie van vSAN-foutdomeinen in twee AZ's vCenter Server waarschuwen dat hosts zich in elke beschikbaarheidszone (AZ) bevinden. Elk foutdomein is vernoemd naar de AZ waarin het zich bevindt om de duidelijkheid te vergroten. Wanneer u een vSAN-cluster over twee AZ's in een regio uitrekt, wordt een AZ uitgezet als een vSphere HA-gebeurtenis en wordt de virtuele machine opnieuw opgestart in de andere AZ.

Voordelen van stretched cluster:

• De beschikbaarheid van toepassingen verbeteren.
• Bied een RPO-mogelijkheid (Zero Recovery Point Objective) voor bedrijfstoepassingen zonder dat u ze opnieuw hoeft te ontwerpen of dure noodhersteloplossingen (DR) hoeft te implementeren.
• Een privécloud met stretched clusters is ontworpen om 99,99% beschikbaarheid te bieden vanwege de tolerantie voor AZ-fouten.
• Klanten in staat stellen zich te richten op de belangrijkste toepassingsvereisten en -functies, in plaats van de beschikbaarheid van de infrastructuur.

Ter bescherming tegen split-brain-scenario's en bij het meten van de sitestatus wordt een beheerde vSAN Witness gemaakt in een derde AZ. Met een kopie van de gegevens in elke AZ probeert vSphere HA te herstellen na een fout met behulp van een eenvoudige herstart van de virtuele machine.

In het volgende diagram ziet u een vSAN-cluster dat is uitgerekt over twee AZ's.

Kortom, stretched clusters vereenvoudigen de beveiligingsbehoeften door dezelfde vertrouwde besturingselementen en mogelijkheden te bieden, naast de schaal en flexibiliteit van de Azure-infrastructuur.

Het is belangrijk om te begrijpen dat stretched cluster-privéclouds alleen een extra tolerantielaag bieden en dat ze niet alle foutscenario's aanpakken. Bijvoorbeeld stretched cluster privéclouds:

• Beveilig niet tegen storingen op regioniveau in Azure of scenario's voor gegevensverlies die worden veroorzaakt door toepassingsproblemen of slecht gepland opslagbeleid.
• Biedt bescherming tegen een storing in één zone, maar is niet ontworpen om bescherming te bieden tegen dubbele of progressieve fouten. Bijvoorbeeld:

  • Ondanks verschillende redundantielagen die zijn ingebouwd in de infrastructuur, als een inter-AZ-fout resulteert in de partitionering van de secundaire site, start vSphere HA de workload-VM's op de secundaire site uit.

    In het volgende diagram ziet u het scenario voor partitionering van secundaire sites.

    

  • Als de secundaire sitepartitionering in plaats daarvan in de fout van de primaire site is opgetreden, of als er een volledige partitionering is ontstaan, probeert vSphere HA de workload-VM's op de secundaire site opnieuw op te starten. Als vSphere HA heeft geprobeerd de workload-VM's opnieuw op te starten op de secundaire site, worden de workload-VM's dan in een niet-plaats geplaatst.

    In de volgende diagrammen ziet u de voorkeurssitefouten en voltooit u scenario's voor netwerkpartitionering.

    

    

Er moet worden opgemerkt dat deze typen fouten, hoewel zeldzaam, buiten het bereik vallen van de beveiliging die wordt geboden door een stretched cluster-privécloud. Vanwege deze soorten zeldzame fouten moet een stretched clusteroplossing worden beschouwd als een multi-AZ-oplossing voor hoge beschikbaarheid die afhankelijk is van vSphere HA. Het is belangrijk dat u begrijpt dat een stretched clusteroplossing niet is bedoeld om een uitgebreide strategie voor herstel na noodgevallen in meerdere regio's te vervangen die kan worden gebruikt om de beschikbaarheid van toepassingen te garanderen. De reden hiervoor is dat een oplossing voor herstel na noodgevallen doorgaans afzonderlijke beheer- en besturingsvlakken heeft in afzonderlijke Azure-regio's. Stretched Clusters van Azure VMware Solution hebben één beheer- en besturingsvlak dat is verdeeld over twee beschikbaarheidszones binnen dezelfde Azure-regio. Bijvoorbeeld één vCenter Server, één NSX Manager-cluster, één NSX Edge VM-paar.

Beschikbaarheid van stretched clusters in regio's

Stretched Clusters van Azure VMware Solution zijn beschikbaar in de volgende regio's:

• VK - zuid (op AV36 en AV36P)
• Europa - west (op AV36 en AV36P)
• Duitsland - west-centraal (op AV36 en AV36P)
• Australië - oost (op AV36P)
• VS - oost (op AV36P)

Ondersteund opslagbeleid

De volgende SPBM-beleidsregels worden ondersteund met een PFTT van Dual Site Mirroring en SFTT van RAID 1 (Mirroring), ingeschakeld als de standaardbeleidsregels voor het cluster:

• Instellingen voor noodtolerantie voor sites (PFTT):
  • Dubbele sitespiegeling
  • Geen- gegevens bewaren op voorkeur
  • Geen- gegevens bewaren op niet-afgeschafte gegevens
• Lokale fouten om te tolereren (SFTT):
  • 1 fout – RAID 1 (spiegeling)
  • 1 fout : RAID 5 (Erasure coding), vereist minimaal vier hosts in elke AZ
  • 2 fouten : RAID 1 (spiegeling)
  • 2 fouten : RAID 6 (Erasure coding), vereist minimaal zes hosts in elke AZ
  • 3 fouten : RAID 1 (spiegeling)

Veelgestelde vragen

Zijn er andere regio's gepland?

Er worden momenteel vijf regio's ondersteund voor stretched clusters.

Wat voor soort SLA biedt Azure VMware Solution de stretched clusters?

Een privécloud die is gemaakt met een vSAN stretched cluster is ontworpen om een beschikbaarheidsverplichting van 99,99% voor infrastructuur te bieden wanneer de volgende voorwaarden bestaan:

• Er worden minimaal zes knooppunten geïmplementeerd in het cluster (3 in elke beschikbaarheidszone).
• Wanneer een VM-opslagbeleid van PFTT van 'Dual-Site Mirroring' en een SFTT van 1 wordt gebruikt door de workload-VM's.
• Naleving van de aanvullende vereisten die zijn vastgelegd in de SLA-details van Azure VMware Solution is vereist om de beschikbaarheidsdoelen te bereiken.

Kan ik de beschikbaarheidszone kiezen waarin een privécloud wordt geïmplementeerd?

Nee Er wordt een stretched cluster gemaakt tussen twee beschikbaarheidszones, terwijl de derde zone wordt gebruikt voor het implementeren van het witness-knooppunt. Omdat alle zones effectief worden gebruikt voor het implementeren van een stretched clusteromgeving, is er geen keuze aan de klant. In plaats daarvan kiest de klant ervoor om hosts in meerdere AZ's te implementeren op het moment van het maken van een privécloud.

Waar moet ik rekening mee houden?

• Zodra een privécloud is gemaakt met een stretched cluster, kan deze niet worden gewijzigd in een standaard privécloud van een cluster. Op dezelfde manier kan een standaardcluster-privécloud niet worden gewijzigd in een stretched cluster-privécloud na het maken.
• Uitschalen en inschalen van stretched clusters kan alleen in paren plaatsvinden. Minimaal zes knooppunten en maximaal 16 knooppunten worden ondersteund in een stretched clusteromgeving. Zie Azure-abonnement en servicelimieten, quota en beperkingen voor meer informatie.
• Vm's voor klantworkloads worden opnieuw opgestart met een gemiddelde vSphere HA-prioriteit. Beheer-VM's hebben de hoogste prioriteit voor opnieuw opstarten.
• De oplossing is afhankelijk van vSphere HA en vSAN voor opnieuw opstarten en replicatie. De beoogde hersteltijd (RTO) wordt bepaald door de hoeveelheid tijd die vSphere HA kost om een virtuele machine opnieuw te starten op de overlevende AZ na de storing van één AZ.
• Momenteel niet ondersteund in een stretched clusteromgeving:
  • Onlangs uitgebrachte functies zoals openbaar IP-adres naar NSX Edge en externe opslag, zoals ANF-gegevensarchieven.
  • Invoegtoepassingen voor herstel na noodgevallen, zoals VMware SRM, Zerto en JetStream.
• Open een ondersteuningsticket vanuit Azure Portal voor de volgende scenario's (zorg ervoor dat u Stretched Clusters als probleemtype selecteert):
  • Een privécloud verbinden met een stretched cluster-privécloud.
  • Verbind twee stretched cluster-privéclouds in één regio.

Wat voor latentie moet ik verwachten tussen de beschikbaarheidszones (AZ's)?

vSAN stretched clusters werken binnen een retourtijd van 5 milliseconden (RTT) en 10 Gb/s of meer bandbreedte tussen de AZ's die als host fungeren voor de workload-VM's. De stretched clusterimplementatie van Azure VMware Solution volgt dat leidende principe. Houd er rekening mee dat informatie bij het implementeren van toepassingen (met SFTT van dubbele sitespiegeling, die synchrone schrijfbewerkingen gebruikt) waarvoor strenge latentievereisten gelden.

Kan ik stretched en standaardclusters combineren in mijn privécloud?

Nee Een combinatie van stretched en standaardclusters wordt niet ondersteund binnen dezelfde privécloud. Er wordt een stretched of standaardclusteromgeving geselecteerd wanneer u de privécloud maakt. Zodra een privécloud wordt gemaakt met een stretched cluster, wordt ervan uitgegaan dat alle clusters die in die privécloud zijn gemaakt, van aard zijn.

Hoeveel kost de oplossing?

Klanten worden in rekening gebracht op basis van het aantal knooppunten dat in de privécloud is geïmplementeerd.

Worden er kosten in rekening gebracht voor het witness-knooppunt en voor inter-AZ-verkeer?

Nee Klanten zien geen kosten voor het witness-knooppunt en het inter-AZ-verkeer. Het witness-knooppunt wordt volledig beheerd en Azure VMware Solution biedt het vereiste levenscyclusbeheer van het witness-knooppunt. Omdat de hele oplossing wordt beheerd door de service, hoeft de klant alleen het juiste SPBM-beleid te identificeren dat moet worden ingesteld voor de virtuele machines van de workload. De rest wordt beheerd via Microsoft.