Betrouwbaarheid in Azure Storage-acties
In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure Storage-acties 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.
Azure Storage Actions is een serverloos framework dat u kunt gebruiken om algemene gegevensbewerkingen uit te voeren op miljoenen objecten in meerdere opslagaccounts. De service zelf is regionaal en heeft geen SKU's of ondersteuning voor beschikbaarheidszones. Het besturingsvlak van de service ondersteunt echter automatisch zoneredundantie. Het gegevensvlak kan ook redundantie ondersteunen, afhankelijk van of het opslagaccount wordt uitgevoerd op een zone-redundante configuratie.
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.
Hoewel de Azure Storage Actions-service regionaal is en geen SKU's of beschikbaarheidszones biedt, is zoneredundantie beschikbaar vanuit het besturingsvlak en voorwaardelijk vanuit het gegevensvlak:
Het besturingsvlak van de service is zone-redundant. Wanneer een zone in één regio uitvalt, blijft het besturingsvlak beschikbaar. Tijdens een zone-down scenario kunt u de taakdefinitie en -toewijzing blijven beheren.
Het gegevensvlak (taaktoewijzingsuitvoering) neemt de zonegebonden eigenschappen over van het bovenliggende opslagaccount. Als het opslagaccount is geïmplementeerd in een mislukte zone, is het account niet meer beschikbaar en vanuit het perspectief van de klant is het gegevensabonnement niet beschikbaar. Als het opslagaccount zone-redundant is, blijft het account beschikbaar en blijft de service bewerkingen op het account uitvoeren.
Zone-down-ervaring
In een zone-gereed scenario blijft de opslagactieservice beschikbaar. De voortgang van taken is afhankelijk van de ondersteuning van opslagaccounts in de beschikbaarheidszone waarop ze worden uitgevoerd. Als het account niet wordt beïnvloed door de downed zone, blijven de taken doorgaan met het maken van de voortgang. Anders mislukken de taken.
Voorbereiding en herstel van zonestoring
De opslagactieservice is niet zonegebonden, maar het opslagaccount is. Als het opslagaccount wordt beïnvloed door een zonestoring, mislukken opslagtaken die aan het account zijn toegewezen. Nadat de zone en het opslagaccount beschikbaar zijn, worden geplande taken volgens schema uitgevoerd. Als de taak eenmaal is geconfigureerd om te worden uitgevoerd, moet u mogelijk de taak plannen om opnieuw uit te voeren.
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.
Opslagactie is een regionale service en wordt uitgevoerd op accounts in dezelfde regio. Wanneer een regio niet beschikbaar is, zijn zowel het opslagaccount als de service ook offline. De service biedt geen ondersteuning voor herstel na noodgevallen tussen regio's. Als u een failover van het opslagaccount naar een andere regio activeert, kunnen opslagtaken pas worden uitgevoerd voor het opslagaccount als er een failback naar de oorspronkelijke regio wordt uitgevoerd. Hoewel u mogelijk het opslagaccount kunt herstellen, kan de opslagtaak dus niet worden uitgevoerd.
Belangrijk
Als u uw opslagaccount migreert van een PRIMAIRE GRS- of GZRS-primaire regio naar een secundaire regio of omgekeerd, worden alle opslagtaken die zijn gericht op het opslagaccount niet geactiveerd en kunnen bestaande taakuitvoeringen mislukken.
Detectie, melding en beheer van storingen
Opslagtaken verzenden geen meldingen wanneer er een storing is in de service zelf. Het is belangrijk dat u de status van de opslagtaak controleert en taken opnieuw probeert nadat de service/regio is hersteld.