Share via


Betrouwbaarheid in Azure Operator Nexus

Belangrijk

Deze functie is momenteel beschikbaar in preview. Previews worden voor u beschikbaar gesteld op voorwaarde dat u akkoord gaat met de aanvullende gebruiksvoorwaarden.

In dit artikel wordt de betrouwbaarheidsondersteuning in Azure Operator Nexus beschreven en wordt de tolerantie binnen de regio met beschikbaarheidszones behandeld. Zie Azure-betrouwbaarheid voor een gedetailleerder overzicht van betrouwbaarheid in Azure.

Ondersteuning voor beschikbaarheidszone

Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.

Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.

Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor meer informatie over zone-redundante versus zone-redundante architectuur voor het gebruik van beschikbaarheidszones en regio's.

Azure Operator Nexus biedt standaard zone-redundante implementaties voor beschikbaarheid. Operator Nexus-onderdelen, zoals ClusterBeheer en Network Fabric Controller, worden allemaal geïmplementeerd op een AKS-cluster (Azure Kubernetes Service) dat is ingeschakeld met beschikbaarheidszones. Andere serviceafhankelijkheden, zoals de opslagaccountservice en KeyVault, worden ook geconfigureerd met beschikbaarheidszoneredundantie.

Notitie

Operator Nexus On-Premises implementeert een ontwerp met meerdere rekken dat fysieke redundantie biedt op alle niveaus van de stack. Elk rek is ontworpen als een foutdomein of Nexus-zone. Workloads van klanten kunnen worden geïmplementeerd in meerdere racks/knooppunten, wat in feite een vergelijkbare ervaring met meerdere beschikbaarheidszones biedt.

Down-ervaring voor Azure-beschikbaarheidszone

In een scenario met een beschikbaarheidszone-down werken API-aanroepen voor het cluster en resourceproviders zonder onderbreking. Er is geen invloed op de momenteel uitgevoerde on-premises tenantworkloads of op de mogelijkheid om nieuwe tenantworkloads te maken. Er moet ook geen gegevensverlies optreden, omdat de tolerantie van de Operator Nexus en andere resourcetypen wordt gegarandeerd.

Ondersteuning voor failover van Azure-beschikbaarheidszone

In het geval van een fout in de beschikbaarheidszone is opnieuw verbinding maken met een andere Azure-beschikbaarheidszone automatisch en is er geen interactie van de gebruiker vereist.

Beschikbaarheid in implementaties van Operator Nexus-exemplaren

Het garanderen van beschikbaarheid in de Azure Operator Nexus-workloadimplementaties is een gesplitste verantwoordelijkheid. Zoals aangegeven in de vorige sectie, worden de op Nexus AKS gebaseerde operatorbronnen geïmplementeerd met redundantie in de beschikbaarheidszone. In deze sectie houden we rekening met aanbevolen procedures voor beschikbaarheid van on-premises workloads.

Over het algemeen worden beschikbaarheidsdoelen bereikt via lokale en geografisch redundante implementaties.

Nexus-zone: een mechanisme voor redundantie van lokale workloads

Operator Nexus on-premises exemplaren bestaan uit een ontwerp met meerdere rekken dat fysieke redundantie biedt op alle niveaus van de stack. Elk rek wordt aangewezen als een foutdomein en kan dus worden geconfigureerd als een Nexus-zone waar deze zones kunnen en, bij voorkeur, moeten worden gebruikt voor implementaties van lokale redundante werkbelastingen.

Nexus-exemplaar: een mechanisme voor redundantie van geo-workload

De Nexus on-premises exemplaren worden gehost in een specifieke Azure-regio. Zoals eerder vermeld, worden de gebruikte Azure-services en de Nexus-resources geïmplementeerd in meerdere beschikbaarheidszones van die Azure-regio.

Nexus-exemplaren die geografisch zijn verdeeld, d.w., niet in hetzelfde operatordatacentrum (mogelijk niet dezelfde geografische regio) en die worden gehost in verschillende Azure-regio's , moeten worden gebruikt om redundantie workloads voor georedundantie te implementeren.

Waarschuwing

Het implementeren van workloads op bijvoorbeeld twee geografisch gedistribueerde Nexus-exemplaren is onvoldoende om echte georedundantie te bereiken, tenzij de geografisch redundante Nexus-exemplaren worden gehost in verschillende Azure-regio's.

In het onwaarschijnlijke geval dat een Azure-regio niet meer beschikbaar is, zijn de Azure-services en de Nexus-resources in die regio ook niet meer beschikbaar. Dit heeft geen invloed op actieve workloads, maar voorkomt mogelijkheden zoals het starten van nieuwe workloads, analyses, enzovoort.

Meerdere Nexus-exemplaren op dezelfde geografische locatie

Er zijn scenario's waarin meerdere Nexus-exemplaren moeten worden geïmplementeerd op dezelfde geografische locatie. Georedundantie van werkbelastingen wordt uiteraard niet bereikt door workloads op Nexus-exemplaren op dezelfde geografische locatie te implementeren.

Een overweging bij het ontwerpen van betrouwbaarheid, behalve beschikbaarheid, is tolerantie en de mogelijkheid om te herstellen van fouten. Voor herstel na storingen en de mogelijkheid om te voldoen aan de doelstellingen van de hersteltijd, moeten we de straal van 'blast' of impact van fouten beperken. In het scenario waarin meerdere Nexus-exemplaren op dezelfde geografische locatie worden geïmplementeerd, vraagt tolerant ontwerp dat deze Nexus-exemplaren worden gehost in verschillende Azure-regio's. Wanneer een Azure-regio mislukt, is de impact dus beperkt tot één Nexus-exemplaar.

Volgende stappen