Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Azure VMware Solution biedt privéclouds die VMware vSphere-clusters bevatten die zijn gebouwd op basis van een toegewezen bare-metal Azure-infrastructuur. U kunt workloads migreren vanuit uw on-premises omgevingen, nieuwe virtuele machines (VM's) implementeren en Azure-services gebruiken vanuit uw privéclouds. U kunt een combinatie van systeemeigen VMware- en Azure-mogelijkheden gebruiken om hoge beschikbaarheid en tolerantie van uw workloads mogelijk te maken.
Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.
In dit artikel wordt beschreven hoe u Azure VMware Solution tolerant maakt voor mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regiostoringen. Ook wordt beschreven hoe u back-ups kunt gebruiken om te herstellen van andere soorten problemen, en belicht het enkele belangrijke informatie over de Service Level Agreement (SLA) van Azure VMware Solution.
Aanbevelingen voor productie-implementatie
Implementaties van Azure VMware Solution vereisen zorgvuldige planning op verschillende gebieden en vereisen vaak meerdere Azure-services. Zie Azure VMware Solution-workloads in het Well-Architected Framework voor gedetailleerde richtlijnen.
Overzicht van betrouwbaarheidsarchitectuur
Azure VMware Solution maakt gebruik van een hypergeconvergeerde infrastructuur met VMware vSphere-clusters.
Wanneer u Azure VMware Solution implementeert, implementeert u een privécloud met een of meer clusters. Elk cluster bevat ESXi-hosts die rekenkracht, opslag via vSAN en netwerken bieden via VMware NSX. Er zijn twee generaties Azure VMware Solution:
- Gen 1 maakt gebruik van gespecialiseerde bare-metalhardware voor knooppunten en maakt gebruik van speciale netwerkmethoden. Zie azure VMware Solution-privécloud- en clusterconcepten voor meer informatie over de belangrijkste concepten.
- Gen 2 maakt gebruik van standaardtypen voor virtuele Azure-machines en virtuele Azure-netwerken. Deze architectuur vereenvoudigt de netwerkarchitectuur, verbetert de snelheid van gegevensoverdracht, vermindert de latentie voor workloads en verbetert de prestaties bij het openen van andere Azure-services.
Fouttolerantie
Azure VMware Solution biedt verschillende mechanismen voor het afhandelen van fouten op zowel infrastructuur- als toepassingsniveau:
vSphere High Availability (HA): HA bewaakt ESXi-hosts en VM's. Als een host mislukt, worden de betrokken VM's automatisch opnieuw opgestart op hosts die in orde zijn. vSphere HA is standaard ingeschakeld en behoudt reken- en geheugencapaciteit voor één knooppuntfout.
vSAN-fouttolerantie: vSAN-opslagbeleid beschermt tegen tijdelijke fouten op opslagniveau door meerdere kopieën van gegevens over hosts te onderhouden. Als een opslagpad of schijf tijdelijke problemen ondervindt, verwerkt vSAN automatisch failover naar gezonde opslagpaden.
Netwerkredundantie: Azure VMware Solution biedt redundante netwerkpaden en meerdere VMkernel-netwerkadapters voor het afhandelen van tijdelijke fouten op netwerkniveau.
Tolerantie voor tijdelijke fouten
Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.
Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.
Voor toepassingen die worden uitgevoerd op Azure VMware Solution-VM's, implementeert u standaardprocedures voor tijdelijke foutafhandeling:
- Geschikte herhaalbeleid configureren met exponentiële wachttijd
- Circuitonderbrekerpatronen gebruiken voor externe service-aanroepen
- De gezondheid van de applicatie bewaken en geleidelijke degradatie toepassen
- Ontwerp stateless toepassingen waar mogelijk om de impact van het opnieuw opstarten van VM's te verminderen
Tolerantie voor fouten in beschikbaarheidszones
Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.
Azure VMware Solution Gen 1 ondersteunt beschikbaarheidszones via stretched clusters, die ESXi-hosts verdelen over twee beschikbaarheidszones binnen een regio. Microsoft selecteert de zones die u wilt gebruiken. Uw cluster wordt uitgevoerd in een actief-actief-configuratie in de twee zones en vSAN omvat ook meerdere zones. U kunt aangeven of elke workload in een of twee zones wordt geïmplementeerd.
Een bewijsknooppunt wordt automatisch geïmplementeerd in een derde availabiliteitszone om quorum te bieden voor split-brain-scenario's. Microsoft beheert het witness-knooppunt automatisch.
Een standaardcluster is een cluster dat niet is uitgerekt tussen zones. In een standaardcluster worden het cluster en alle bijbehorende ESXi-hosts beschouwd als niet-standaard of regionaal. Niet-zonegebonden clusters kunnen worden geplaatst in een beschikbaarheidszone binnen de regio en Microsoft selecteert de zone. Als een beschikbaarheidszone in de regio een storing ondervindt, bevinden niet-zonegebonden clusters en hosts zich mogelijk in de betrokken zone en kunnen er downtime optreden.
Azure VMware Solution Gen 2 ondersteunt zonegebonden implementaties van privéclouds. Wanneer u een zonegebonden privécloud configureert, worden elk van de clusters en alle bijbehorende ESXi-hosts geïmplementeerd in één beschikbaarheidszone die u selecteert.
Een zonegebonden privécloud beschermt niet tegen storingen in de beschikbaarheidszone. U kunt meerdere privéclouds implementeren in afzonderlijke beschikbaarheidszones voor hogere tolerantie, maar u bent verantwoordelijk voor het onafhankelijk implementeren en configureren van elke privécloud.
Als u geen beschikbaarheidszone selecteert, worden uw privécloud, de bijbehorende clusters en al hun ESXi-hosts beschouwd als niet-zonegebonden of regionaal. Niet-zonegebonden clusters kunnen worden geplaatst in een beschikbaarheidszone binnen de regio en Microsoft selecteert de zone. Als een beschikbaarheidszone in de regio een storing ondervindt, bevinden niet-zonegebonden clusters zich mogelijk in de getroffen zone en kunnen er downtime optreden.
Als u informatie over ondersteuning voor beschikbaarheidszones voor andere generaties wilt weergeven, selecteert u de juiste generatie aan het begin van deze pagina.
Requirements
Regioondersteuning: Stretched clusters zijn beschikbaar in bepaalde Azure-regio's die ondersteuning bieden voor de stretched clusterconfiguratie. Controleer de beschikbaarheidszone van de Azure-regio naar de toewijzingstabel voor hosttypen voor de huidige regioondersteuning.
Minimale hosts: Implementeer minimaal zes hosts in twee beschikbaarheidszones (drie hosts per zone) om stretched clusterconfiguratie mogelijk te maken. Wanneer u in- of uitschaalt, moet u in paren schalen zodat het aantal hosts in elke zone gelijk is.
Host-SKU's: Stretched clusters worden ondersteund met AV36-, AV36P- en AV52-hosttypen. De AV64-SKU wordt niet ondersteund met stretched clusters.
Regioondersteuning: U kunt zonegebonden privéclouds implementeren in regio's die ondersteuning bieden voor Azure VMware Solution Gen 2 en ook beschikbaarheidszones ondersteunen.
Overwegingen
Elke beschikbaarheidszone in een regio kan specifieke hosttypen ondersteunen. Zie de Azure-regio beschikbaarheidszone naar hosttype-koppelingstabel voor een gedetailleerde lijst met de hosttypen die beschikbaar zijn in elke zone.
Kosten
Er worden kosten in rekening gebracht voor elk knooppunt in het cluster, ongeacht de configuratie van de beschikbaarheidszone van het cluster. Zie prijzen voor Azure VMware Solution voor gedetailleerde informatie over prijzen.
Ondersteuning voor beschikbaarheidszones configureren
Een nieuw cluster implementeren: Wanneer u een nieuwe Azure VMware Solution-privécloud maakt in een ondersteunde regio, kunt u deze configureren als een stretched cluster tijdens de implementatie. Met deze configuratie worden hosts automatisch verdeeld over twee beschikbaarheidszones. Zie VSAN-stretched clusters implementeren voor meer informatie.
Bestaande clusters: U kunt een standaardcluster niet converteren naar een stretched cluster en u kunt ook geen stretched cluster converteren naar een standaardcluster. In plaats daarvan moet u een nieuw cluster implementeren en uw workloads migreren.
Een nieuw cluster implementeren: Wanneer u een nieuwe Azure VMware Solution-privécloud maakt in een ondersteunde regio, kunt u de beschikbaarheidszone selecteren.
Bestaande clusters: U kunt de configuratie van de beschikbaarheidszone van een bestaand cluster niet wijzigen. In plaats daarvan moet u een nieuw cluster implementeren en uw workloads migreren.
Gedrag wanneer alle zones in orde zijn
In deze sectie wordt beschreven wat u kunt verwachten wanneer uw cluster wordt uitgerekt en alle beschikbaarheidszones operationeel zijn.
Bewerking tussen regio's: VM's kunnen worden uitgevoerd op hosts in een van beide beschikbaarheidszones. VM-plaatsing kan worden beheerd met vSphere DRS-affiniteits- en anti-affiniteitsregels om de prestaties of beschikbaarheid te optimaliseren volgens de vereisten.
Replicatie van gegevens in meerdere regio's: vSAN repliceert gegevens synchroon tussen beschikbaarheidszones. Elke schrijfbewerking wordt bevestigd door beide zones vóór voltooiing, waardoor consistente gegevensintegriteit wordt gegarandeerd.
In deze sectie wordt beschreven wat u kunt verwachten wanneer uw cluster wordt geïmplementeerd in een zonegebonden privécloud en alle beschikbaarheidszones operationeel zijn.
Bewerking tussen regio's: VM's worden uitgevoerd op hosts binnen de beschikbaarheidszone van het cluster.
Replicatie van gegevens in meerdere regio's: Er worden geen gegevens gerepliceerd naar een andere zone.
Gedrag tijdens een zonefout
In deze sectie wordt beschreven wat u kunt verwachten wanneer uw cluster wordt uitgebreid en er een storing in een beschikbaarheidszone optreedt.
- Detectie en reactie: Azure VMware Solution beheert de reactie op infrastructuurniveau op zonefouten. vSphere HA detecteert automatisch zonefouten en initieert zo nodig procedures voor het opnieuw opstarten van vm's.
- Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Resource Health echter gebruiken om te controleren op de status van een afzonderlijke resource en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt Azure Service Health ook gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.
Actieve aanvragen: Virtuele machines die worden uitgevoerd in de mislukte beschikbaarheidszone, worden opnieuw opgestart op hosts in de overlevende beschikbaarheidszone. Actieve aanvragen en verbindingen met betrokken VM's worden beëindigd en clients zijn verantwoordelijk voor het opnieuw proberen ervan.
Verwachte downtime: De tijd voor het opnieuw opstarten van mislukte Virtuele Machines (VM's) in de gezonde zone is doorgaans een paar minuten, afhankelijk van de VM-configuratie en opstartprocedures van de VM. Het stretched cluster blijft operationeel met verminderde capaciteit.
Als de mislukte beschikbaarheidszone het witness-knooppunt bevat, wordt de witness onbereikbaar. Zolang er voldoende gegevensreplica's beschikbaar blijven, blijven de gegevenshosts en actieve workloads werken zonder direct gegevensverlies. VSAN verliest echter quorum in deze toestand, waardoor het niet veilig plaatsings- en herstelbeslissingen kan maken en bepaalde bewerkingen worden geblokkeerd, zoals het inschakelen van VM's na storingen, herverdeling en reparaties.
Verwachte gegevensverlies: Omdat vSAN synchrone replicatie tussen zones gebruikt, is er geen gegevensverlies verwacht tijdens een zonefout.
Herdistributie: vSphere DRS herdistribueert VM-workloads automatisch naar de overlevende beschikbaarheidszone. Routering van netwerkverkeer via VMware NSX past zich automatisch aan de nieuwe VM-plaatsing aan.
In deze sectie wordt beschreven wat u kunt verwachten wanneer uw cluster wordt geïmplementeerd in een zonegebonden privécloud en er een storing in de beschikbaarheidszone optreedt.
- Detectie en reactie: U moet het verlies van een beschikbaarheidszone detecteren. Indien nodig kunt u een failover initiëren naar een secundair cluster dat u vooraf hebt gemaakt in een andere beschikbaarheidszone.
- Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Resource Health echter gebruiken om te controleren op de status van een afzonderlijke resource en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt Azure Service Health ook gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.
Actieve aanvragen: Actieve aanvragen en verbindingen met betrokken VM's worden beëindigd en clients zijn verantwoordelijk voor het opnieuw proberen ervan.
Verwachte downtime: Wanneer een zone niet beschikbaar is, zijn uw cluster en de bijbehorende workloads niet beschikbaar totdat de beschikbaarheidszone wordt hersteld.
Verwachte gegevensverlies: Gegevens in de getroffen zone zijn niet beschikbaar totdat de zone wordt hersteld.
Herverdeling: U bent verantwoordelijk voor het overschakelen van verkeer naar andere clusters in gezonde zones, indien nodig.
Zoneherstel
Wanneer de beschikbaarheidszone wordt hersteld, kan vSphere DRS optioneel VM's opnieuw distribueren naar de herstelde zone op basis van uw DRS-configuratie- en affiniteitsregels. U kunt de plaatsing van vm's ook handmatig beheren met behulp van vMotion-bewerkingen.
Wanneer de beschikbaarheidszone wordt hersteld, zijn clusters en hosts in de zone opnieuw beschikbaar. U bent verantwoordelijk voor alle zoneherstelprocedures en gegevenssynchronisatie die uw workloads nodig hebben.
Testen op zonefouten
U kunt zonefouten simuleren op:
Met vSphere kunt u hosts in de onderhoudsmodus plaatsen om fouten op zoneniveau te simuleren.
Valideren dat back-up- en bewakingssystemen blijven functioneren tijdens gesimuleerde fouten.
- Het testen van toepassingstolerantie voor het opnieuw opstarten van vm's en wijzigingen in het netwerkpad, met name wanneer u clusters hebt uitgerekt of toepassingen implementeert in afzonderlijke clusters in verschillende zones.
Omdat Azure VMware Solution de infrastructuurrespons op zonefouten beheert, moet u voornamelijk het antwoord van uw toepassing testen op het opnieuw opstarten van de VIRTUELE machine.
U bent verantwoordelijk voor alle infrastructuurreacties op zonefouten, zoals failover naar een ander cluster in een andere zone of regio. Zorg ervoor dat u uw reactieprocessen grondig test.
Tolerantie voor storingen in de hele regio
Elk Azure VMware Solution-cluster wordt geïmplementeerd binnen één Azure-regio. Als de regio niet meer beschikbaar is, worden uw privécloud en alle resources erin niet meer beschikbaar.
U kunt echter ook aangepaste oplossingen voor meerdere regio's ontwerpen die verschillende benaderingen combineren of integreren met uw bestaande infrastructuur om te voldoen aan uw specifieke bedrijfsvereisten en hersteldoelstellingen.
Aangepaste oplossingen voor meerdere regio's voor veerkracht
Als u tolerantie voor meerdere regio's wilt bereiken met Azure VMware Solution, moet u afzonderlijke privéclouds implementeren in meerdere regio's en failover- en andere oplossingen voor herstel na noodgevallen implementeren.
Er zijn verschillende opties die verschillende vereisten ondersteunen. Zie voor meer informatie back-up- en hersteloplossingen van derden voor Azure VMware: beperkingen, compatibiliteit en bekende problemen.
Backups en herstel
Azure VMware Solution maakt automatisch een back-up van beheeronderdelen (vCenter Server, NSX Manager en HCX Manager indien ingeschakeld). Als u deze beheerback-ups wilt herstellen, maakt u een Azure-ondersteuningsaanvraag.
Voor uw VM-workloads ondersteunt Azure VMware Solution meerdere back-upmethoden. Voor gedetailleerde informatie, zie Back-upoplossingen voor Azure VMware Solution-VM's.
Tolerantie voor serviceonderhoud
Azure voert automatisch platformonderhoud uit om beveiligingsupdates toe te passen, nieuwe functies te implementeren en de servicebetrouwbaarheid te verbeteren.
Voor meer informatie over het effect dat onderhoud kan hebben op de onderdelen van Azure VMware Solution en om inzicht te krijgen in de onderdelen die u verantwoordelijk bent voor onderhoud en de onderdelen die Door Microsoft worden onderhouden, raadpleegt u best practices voor het onderhoud van de privécloud van Azure VMware Solution.
U kunt de onderhoudsvensters voor uw cluster configureren om de kans op onderhoud dat van invloed is op uw productieworkloads te verminderen. Zie Selfservice-onderhoud plannen voor Azure VMware Solution (openbare preview) voor meer informatie.
Diensteniveauovereenkomst
De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.
Azure VMware Solution biedt verschillende beschikbaarheids-SLA's voor workloadinfrastructuur en voor beheerbewerkingen.
Clusters die zijn geconfigureerd als stretched clusters hebben een hogere SLA voor infrastructuurbeschikbaarheid bij werkbelasting.
Als u echter in aanmerking wilt komen voor de beschikbaarheids-SLA's, moet u uw cluster op specifieke manieren configureren. Raadpleeg de SLA-tekst voor gedetailleerde informatie.