Overzicht
Deze reeks bevat een illustratief voorbeeld van hoe een organisatie een dr-strategie (disaster recovery) kan ontwerpen voor een Azure Enterprise-gegevensplatform.
- Deze reeks artikelen vormt een aanvulling op de richtlijnen van het Cloud Adoption Framework van Microsoft, het Azure Well-Architected Framework en Business Continuity Management.
Azure biedt een breed scala aan tolerantieopties die servicecontinuïteit kunnen bieden in geval van een noodgeval. Maar hogere serviceniveaus kunnen complexiteit en een kostenpremie introduceren. De afweging van kosten versus tolerantie versus complexiteit is de belangrijkste besluitvormingsfactor voor de meeste klanten met betrekking tot herstel na noodgevallen.
Hoewel er incidentele puntfouten optreden in het Azure-platform, hebben de Azure-datacenters en Azure-services van Microsoft meerdere lagen redundantie ingebouwd. Fouten worden normaal gesproken beperkt binnen het bereik en worden doorgaans binnen een paar uur opgelost. In het verleden is het veel waarschijnlijker dat een belangrijke service, zoals identiteitsbeheer, een serviceprobleem ondervindt in plaats van dat een hele Azure-regio offline gaat.
Het moet ook worden bevestigd dat cyberaanvallen, met name ransomware, nu een tastbare bedreiging vormen voor elk modern gegevensecosysteem en kunnen leiden tot een storing in het gegevensplatform. Hoewel dit buiten het bereik van deze reeks valt, wordt klanten aangeraden controles te implementeren tegen dergelijke aanvallen als onderdeel van het beveiligings- en tolerantieontwerp van een gegevensplatform.
- Microsoft-richtlijnen voor ransomwarebeveiliging zijn beschikbaar in de basisprincipes van Azure Cloud
Bereik
Het bereik van deze reeks artikelen omvat:
- Het serviceherstel van een Azure-gegevensplatform na een fysieke ramp voor een illustratieve persona van de klant. Deze illustratieve klant is:
- Een middelgrote organisatie met een gedefinieerde operationele ondersteuningsfunctie, na een ITIL-methodologie (Information Technology Infrastructure Library) op basis van servicebeheer.
- Niet cloudeigen, met zijn kernbedrijf, gedeelde services, zoals toegangs- en verificatiebeheer en incidentbeheer dat on-premises blijft.
- Tijdens het traject van cloudmigratie naar Azure, ingeschakeld door automatisering.
- Het Azure-gegevensplatform heeft de volgende ontwerpen geïmplementeerd binnen de Azure-tenancy van de klant:
- Landingszone voor ondernemingen: het bieden van de platformbasis, waaronder netwerken, bewaking, beveiliging, enzovoort.
- Azure Analytics-platform : het leveren van de gegevensonderdelen die ondersteuning bieden voor de verschillende oplossingen en gegevensproducten die door de service worden geleverd.
- De processen die in dit artikel worden beschreven, worden uitgevoerd door een technische Azure-resource in plaats van een specialist azure-onderwerpexpert (SME). Als zodanig moeten de resources het volgende niveau van kennis/vaardigheden hebben:
- Basisinformatie over Azure: werkende kennis van Azure, de belangrijkste services en gegevensonderdelen.
- Werkende kennis van Azure DevOps. Kan navigeren door broncodebeheer en pijplijnimplementaties uitvoeren.
- Deze processen die in dit artikel worden beschreven, hebben betrekking op servicefailoverbewerkingen, van de primaire naar de secundaire regio.
Buiten bereik
De volgende items worden beschouwd als buiten het bereik van deze reeks artikelen:
- Het terugvalproces, van de secundaire regio terug naar de primaire regio.
- Alle niet-Azure-toepassingen, -onderdelen of -systemen: dit omvat, maar is niet beperkt tot on-premises, andere cloudleveranciers, webservices van derden, enzovoort.
- Herstel van upstreamservices, zoals on-premises netwerken, gateways, gedeelde bedrijfsservices en andere services, ongeacht eventuele afhankelijkheden van deze services.
- Herstel van downstreamservices, zoals on-premises operationele systemen, rapportagesystemen van derden, gegevensmodellering of data science-toepassingen, en andere, ongeacht eventuele afhankelijkheden van deze services.
- Scenario's voor gegevensverlies, waaronder herstel van ransomware of vergelijkbare gegevensbeveiligingsincidenten
- Strategieën voor gegevensback-up en gegevensherstelplannen
- De hoofdoorzaak van een DR-gebeurtenis vaststellen.
- Voor azure-service-/onderdeelincidenten publiceert Microsoft een hoofdoorzaakanalyse binnen de status - webpagina Geschiedenis
Belangrijkste veronderstellingen
De belangrijkste aannames voor dit dr-voorbeeld zijn:
- De organisatie volgt een op ITIL gebaseerde servicebeheermethodologie voor operationele ondersteuning van het Azure-gegevensplatform.
- De organisatie heeft een bestaand proces voor herstel na noodgevallen als onderdeel van het serviceherstelframework voor IT-assets.
- Infrastructure as Code (IaC) is gebruikt om het Azure-gegevensplatform te implementeren dat is ingeschakeld door een automatiseringsservice, zoals Azure DevOps of vergelijkbaar.
- Elke oplossing die wordt gehost door het Azure-gegevensplatform heeft een Business Impact Assessment of een vergelijkbare oplossing voltooid, met duidelijke servicevereisten voor RPO (Recovery Point Objective), RTO (Recovery Time Objective) en gemiddelde tijd voor het herstellen van metrische gegevens (MTTR).
Volgende stappen
Nu u op hoog niveau hebt geleerd over het scenario, kunt u verder gaan met meer informatie over de architectuur die is ontworpen voor de use-case.