Betrouwbaarheid in Azure Event Hubs

In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure Event Hubs beschreven en wordt zowel binnen regionale tolerantie behandeld als beschikbaarheidszones en herstel na noodgevallen in meerdere regio's en bedrijfscontinuïteit. Zie Azure-betrouwbaarheid voor een gedetailleerder overzicht van betrouwbaarheidsprincipes 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 het gebruik van beschikbaarheidszones en regio's voor meer informatie over zone-redundante architectuur en zone-redundante architectuur.

Event Hubs implementeert transparante mechanismen voor foutdetectie en failover, zodat, wanneer er een fout optreedt, de service blijft werken binnen de verzekerde serviceniveaus en zonder merkbare onderbrekingen. Als u een Event Hubs-naamruimte maakt in een regio die beschikbaarheidszones ondersteunt, wordt zoneredundantie automatisch ingeschakeld. Met zoneredundantie wordt fouttolerantie verhoogd en beschikt de service over voldoende capaciteitsreserves om te kunnen omgaan met de storing van een hele faciliteit. Zowel metagegevens als gegevens (gebeurtenissen) worden gerepliceerd tussen datacenters in elke zone.

Vereisten

Ondersteuning voor beschikbaarheidszones is alleen beschikbaar in Azure-regio's met beschikbaarheidszones.

Een resource maken waarvoor beschikbaarheidszones zijn ingeschakeld

Wanneer u Azure Portal gebruikt, wordt zoneredundantie automatisch ingeschakeld. Wanneer u een naamruimte maakt, ziet u het volgende gemarkeerde bericht wanneer u een regio selecteert die beschikbaarheidszones ondersteunt.

Beschikbaarheidszones uitschakelen

Azure Portal biedt geen ondersteuning voor het uitschakelen van beschikbaarheidszones. Gebruik een van de volgende methoden om beschikbaarheidszones uit te schakelen:

• Azure CLI-opdracht az eventhubs namespace met --zone-redundant=false

• PowerShell-opdracht New-AzEventHubNamespace om -ZoneRedundant=false een naamruimte te maken waarvoor zoneredundantie is uitgeschakeld.

Migratie van beschikbaarheidszone

Wanneer u beschikbaarheidszones maakt in een regio die deze ondersteunt, worden beschikbaarheidszones automatisch ingeschakeld. Als u wilt weten hoe u uw Event Hub verplaatst naar een nieuwe regio die beschikbaarheidszones ondersteunt, raadpleegt u Event Hubs verplaatsen naar een andere regio.

Prijzen

Informatie nodig. Eventuele prijsoverwegingen bij het gebruik van beschikbaarheidszones?

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallen voordat u begint na te denken over het maken van uw plan voor herstel na noodgevallen.

Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.

Het all-actieve Azure Event Hubs-clustermodel met ondersteuning voor beschikbaarheidszones biedt tolerantie tegen hardware- en datacenterstoringen. Als er echter een noodgeval is waarbij een hele regio en alle zones niet beschikbaar zijn, kunt u geo-noodherstel gebruiken om uw workload en toepassingsconfiguratie te herstellen.

Er zijn twee functies die geo-noodherstel bieden in Azure Event Hubs.

• Herstel na geo-noodgeval (herstel na noodgevallen van metagegevens) die alleen replicatie van alleen metagegevens biedt.

  Herstel na geo-noodgeval zorgt ervoor dat de volledige configuratie van een naamruimte (Event Hubs, Consumentengroepen en instellingen) continu wordt gerepliceerd van een primaire naamruimte naar een secundaire naamruimte wanneer deze is gekoppeld.

  De functie voor geo-noodherstel van Azure Event Hubs is een oplossing voor herstel na noodgevallen. De concepten en werkstroom die in dit artikel worden beschreven, zijn van toepassing op noodscenario's en niet op tijdelijke storingen. Zie dit artikel voor een gedetailleerde bespreking van herstel na noodgevallen in Microsoft Azure.

  Met herstel na noodgevallen kunt u op elk gewenst moment een eenmalige failover starten van de primaire naar de secundaire. De failover verplaatst de gekozen aliasnaam voor de naamruimte naar de secundaire naamruimte. Na de verplaatsing wordt de koppeling vervolgens verwijderd. De failover is bijna onmiddellijk nadat deze is gestart.

  Zie Azure Event Hubs - Geo-disaster recovery voor gedetailleerde informatie en voorbeelden en verdere documentatie over geo-noodherstel in Event Hubs.

• Geo-replicatie (openbare preview), die replicatie van zowel metagegevens als gegevens biedt, repliceert configuratiegegevens en alle gegevens van een primaire naamruimte naar een of meer secundaire naamruimten. Wanneer een failover wordt uitgevoerd, wordt de geselecteerde secundaire de primaire en wordt de vorige primaire een secundaire. Gebruikers kunnen desgewenst een failover uitvoeren naar de oorspronkelijke primaire server.

  Zie Geo-replicatie voor gedetailleerde informatie en voorbeelden en verdere documentatie over geo-replicatie in Event Hubs.

Volgende stappen

• Betrouwbaarheid in Azure