Bewerken

Delen via

DR voor Azure Data Platform - Dit scenario implementeren

Azure Synapse Analytics
Azure Machine Learning
Azure Cosmos DB
Azure Data Lake
Azure Event Hubs

Vereiste klantactiviteiten

Pre-incident

Voor Azure-services

  • Vertrouwd zijn met Azure Service Health in Azure Portal. Deze pagina fungeert als de 'one-stop shop' tijdens een incident.
  • Overweeg het gebruik van Service Health-waarschuwingen, die kunnen worden geconfigureerd om automatisch meldingen te genereren wanneer Azure-incidenten optreden.

Voor Power BI

  • Vertrouwd zijn met Service Health in de Microsoft 365-beheercentrum. Deze pagina fungeert als de 'one-stop shop' tijdens een incident.
  • Overweeg het gebruik van Microsoft 365-beheer mobiele app om automatische waarschuwingsmeldingen voor serviceincidenten te ontvangen.

Tijdens het incident

Voor Azure-services

  • Azure Service Health in hun Azure-beheerportal biedt de nieuwste updates.
    • Als er problemen zijn met het openen van Service Health, raadpleegt u de azure-statuspagina.
    • Als er ooit problemen zijn met het openen van de statuspagina, gaat u naar @AzureSupport X (voorheen Twitter).
  • Als de impact/problemen niet overeenkomen met het incident (of behouden na beperking), neemt u contact op met de ondersteuning om een serviceondersteuningsticket in te dienen.

Voor Power BI

Na Microsoft-herstel

Zie de onderstaande secties voor dit detail.

Incident plaatsen

Voor Azure-services

Voor Power BI

Wachten op Microsoft-proces

Het proces 'Wachten op Microsoft' wacht gewoon totDat Microsoft alle onderdelen en services in de betrokken primaire regio herstelt. Nadat het gegevensplatform is hersteld, valideert u de binding van het gegevensplatform naar gedeelde of andere services van het bedrijf, de datum van de gegevensset en voert u vervolgens de processen uit om het systeem up-to-date te brengen.

Zodra dit proces is voltooid, kunnen technische en zakelijke deskundigen (SME)-validatie worden voltooid, zodat de belanghebbende goedkeuring kan krijgen voor het herstel van de service.

Opnieuw implementeren bij noodgeval

Voor een strategie 'Opnieuw implementeren op noodgeval' kan de volgende processtroom op hoog niveau worden beschreven.

  1. De gedeelde bedrijfsservices en bronsystemen van Contoso herstellen

    Diagram met het herstel van de gedeelde services en bronsystemen van Contoso.

    • Deze stap is een vereiste voor het herstel van het gegevensplatform.
    • Deze stap wordt voltooid door de verschillende operationele ondersteuningsgroepen van Contoso die verantwoordelijk zijn voor de gedeelde bedrijfsservices en operationele bronsystemen.

  2. Azure-services herstellen verwijst naar de toepassingen en services die de Azure Cloud-aanbieding maken, zijn beschikbaar in de secundaire regio voor implementatie.

    Diagram van het herstel van de Azure-services.

    Azure Services verwijst naar de toepassingen en services die de Azure Cloud-aanbieding maken, zijn beschikbaar in de secundaire regio voor implementatie.

    • Deze stap is een vereiste voor het herstel van het gegevensplatform.
    • Deze stap wordt voltooid door Microsoft en andere PaaS-partners (Platform as a Service)/Software as a Service (SaaS).

  3. De basis van het gegevensplatform herstellen

    Diagram met het herstel van de basissystemen van het gegevensplatform.

    • Deze stap is het toegangspunt voor de platformherstelactiviteiten.
    • Voor de strategie voor opnieuw implementeren wordt elke vereiste component/service aangeschaft en geïmplementeerd in de secundaire regio.
      • Zie de sectie Azure Service en Component in deze reeks voor een gedetailleerde uitsplitsing van de onderdelen en implementatiestrategieën.
    • Dit proces moet ook activiteiten omvatten zoals de binding met de gedeelde bedrijfsservices, waardoor de connectiviteit voor toegang/verificatie wordt gewaarborgd en dat de offloading van het logboek werkt, terwijl er ook verbinding wordt gegarandeerd met zowel upstream- als downstreamprocessen.
    • Gegevens/verwerking moeten worden bevestigd. Bijvoorbeeld validatie van de tijdstempel van het herstelde platform.
      • Als er vragen zijn over gegevensintegriteit, kan de beslissing worden genomen om verder terug te draaien voordat de nieuwe verwerking wordt uitgevoerd om het platform up-to-date te brengen.
    • Het hebben van een prioriteitsvolgorde voor processen (op basis van bedrijfsimpact) helpt bij het organiseren van het herstel.
    • Deze stap moet worden afgesloten door technische validatie, tenzij zakelijke gebruikers rechtstreeks met de services communiceren. Als er directe toegang is, moet er een bedrijfsvalidatiestap zijn.
    • Zodra de validatie is voltooid, vindt een overdracht aan de afzonderlijke oplossingsteams plaats om hun eigen herstelproces voor noodherstel (DR) te starten.
      • Deze overdracht moet een bevestiging bevatten van de huidige tijdstempel van de gegevens en processen.
      • Als belangrijke zakelijke gegevensprocessen worden uitgevoerd, moeten de afzonderlijke oplossingen hiervan op de hoogte worden gesteld: inkomende/uitgaande stromen, bijvoorbeeld.

  4. De afzonderlijke oplossingen herstellen die worden gehost door het platform

    Diagram met het herstel van afzonderlijke platformsystemen.

    • Elke afzonderlijke oplossing moet een eigen DR-runbook hebben. De runbooks moeten ten minste de genomineerde zakelijke belanghebbenden bevatten die testen en bevestigen dat serviceherstel is voltooid.
    • Afhankelijk van resourceconflicten of prioriteit kunnen belangrijke oplossingen/workloads prioriteit krijgen boven andere: kernprocessen voor bedrijfsprocessen via ad-hoclabs, bijvoorbeeld.
    • Zodra de validatiestappen zijn voltooid, wordt er een overdracht naar de downstreamoplossingen uitgevoerd om het herstelproces voor herstel na noodgeval te starten.

  5. Overdracht naar downstream-, afhankelijke systemen

    Diagram met de afhankelijke systemen.

    • Zodra de afhankelijke services zijn hersteld, is het herstelproces voor E2E DR voltooid.

    Notitie

    Hoewel het theoretisch mogelijk is om een E2E DR-proces volledig te automatiseren, is het onwaarschijnlijk dat het risico van de gebeurtenis versus de kosten van de SDLC-activiteiten die nodig zijn om het E2E-proces te dekken.

  6. Terugval naar de primaire regio terugval is het proces van het verplaatsen van de gegevensplatformservice en de bijbehorende gegevens terug naar de primaire regio, zodra deze beschikbaar is voor BAU.

Afhankelijk van de aard van de bronsystemen en verschillende gegevensprocessen kan het terugval van het gegevensplatform onafhankelijk van andere onderdelen van het gegevenssysteem worden uitgevoerd.

Klanten worden geadviseerd om de afhankelijkheden van hun eigen gegevensplatform (zowel upstream als downstream) te controleren om de juiste beslissing te nemen. In de volgende sectie wordt ervan uitgegaan dat het gegevensplatform onafhankelijk wordt hersteld.

  • Zodra alle vereiste onderdelen/services beschikbaar zijn in de primaire regio, zouden klanten een betrouwbaarheidstest uitvoeren om het Herstel van Microsoft te valideren.
  • De configuratie van onderdelen/services wordt gevalideerd. Delta's worden aangepakt via opnieuw implementeren vanuit broncodebeheer.
  • De systeemdatum in de primaire regio wordt tot stand gebracht voor stateful onderdelen. De verschillen tussen de vastgestelde datum en de datum/tijdstempel in de secundaire regio moeten worden aangepakt door de gegevensopnameprocessen vanaf dat moment opnieuw uit te voeren of opnieuw af te spelen.
  • Met goedkeuring van zowel zakelijke als technische belanghebbenden wordt een terugvalvenster geselecteerd. In het ideale geval moet dit gebeuren tijdens een lull in systeemactiviteit en -verwerking.
  • Tijdens de terugval wordt de primaire regio gesynchroniseerd met de secundaire regio voordat het systeem werd overgeschakeld.
  • Na een periode van een parallelle uitvoering wordt de secundaire regio offline gehaald uit het systeem.
  • De onderdelen in de secundaire regio worden verwijderd of verwijderd, afhankelijk van de geselecteerde DR-strategie.

Warm reserveproces

Voor een "Warm Reserve"-strategie is de processtroom op hoog niveau nauw afgestemd op die van de 'Opnieuw implementeren op noodgeval', het belangrijkste verschil dat onderdelen al zijn aangeschaft in de secundaire regio. Deze strategie elimineert het risico van resourceconflicten van andere organisaties die hun eigen herstel na noodgeval in die regio willen voltooien.

Hot Spare-proces

De strategie 'Hot Spare' betekent dat de Platform-services, waaronder PaaS- en IaaS-systemen (Infrastructure as a Service), blijven bestaan ondanks de noodgeval, omdat de secundaire systemen samen met de primaire systemen worden uitgevoerd. Net als bij de 'Warm Spare'-strategie elimineert deze strategie het risico op conflicten tussen resources van andere organisaties die hun eigen DR in die regio willen voltooien.

Hot Spare-klanten controleren het Microsoft-herstel van onderdelen/services in de primaire regio. Zodra dit is voltooid, valideren klanten de primaire regiosystemen en voltooien ze de terugval naar de primaire regio. Dit proces zou vergelijkbaar zijn met het failoverproces voor herstel na noodgevallen, controleer de beschikbare codebasis en gegevens, en implementeer indien nodig opnieuw.

Notitie

Hier moet een speciale opmerking worden gemaakt om ervoor te zorgen dat alle systeemmetagegevens consistent zijn tussen de twee regio's.

  • Zodra terugval naar de primaire is voltooid, kunnen de load balancers van het systeem worden bijgewerkt om de primaire regio weer in de systeemtopologie te brengen. Indien beschikbaar, kan een canary-releasebenadering worden gebruikt om incrementeel over te schakelen naar de primaire regio voor het systeem.

Planstructuur voor herstel na noodgeval

Een effectief DR-plan bevat een stapsgewijze handleiding voor serviceherstel die kan worden uitgevoerd door een technische Azure-resource. Hier volgt een lijst met een voorgestelde MVP-structuur voor een DR-plan.

  • Procesvereisten
    • Elk processpecifieke details van de klant, zoals de juiste autorisatie die is vereist om dr te starten, en belangrijke beslissingen te nemen over het herstel indien nodig (inclusief "definitie van gereed"), serviceondersteuning dr ticketing referentie en details van war room.
    • Resourcebevestiging, inclusief de dr-lead en uitvoerdersback-up. Alle resources moeten worden gedocumenteerd met primaire en secundaire contactpersonen, escalatiepaden en agenda's verlaten. In kritieke dr-situaties moeten roostersystemen mogelijk worden overwogen.
    • Laptop, power packs of back-upstroom, netwerkconnectiviteit en mobiele telefoongegevens voor de DR-uitvoerder, DR-back-up en eventuele escalatiepunten.
    • Het proces dat moet worden gevolgd als aan een van de procesvereisten niet wordt voldaan.
  • Vermelding van contactpersonen
    • DR-leiderschap en ondersteuningsgroepen.
    • Kleine en middelgrote ondernemingen die de test-/beoordelingscyclus voor het technische herstel zullen voltooien.
    • Betrokken bedrijfseigenaren, inclusief de goedkeurders voor serviceherstel.
    • Betrokken technische eigenaren, met inbegrip van de goedkeurders voor technisch herstel.
    • SME-ondersteuning voor alle betrokken gebieden, inclusief belangrijke oplossingen die worden gehost door het platform.
    • Beïnvloede downstreamsystemen : operationele ondersteuning.
    • Upstream-bronsystemen – operationele ondersteuning.
    • Contactpersonen voor gedeelde bedrijfsservices. Bijvoorbeeld ondersteuning voor toegang en verificatie, beveiligingsbewaking en gatewayondersteuning
    • Externe leveranciers of externe leveranciers, inclusief ondersteuningscontactpersonen voor cloudproviders.
  • Architectuurontwerp
    • Beschrijf het end-endscenario (E2E) en voeg alle bijbehorende ondersteuningsdocumentatie toe.
  • Afhankelijkheden
    • Vermeld alle relaties en afhankelijkheden van de onderdelen.
  • Vereisten voor herstel na noodgeval
    • Bevestiging dat upstream-bronsystemen beschikbaar zijn zoals vereist.
    • Verhoogde toegang tot de stack is verleend aan de dr-uitvoerdersbronnen.
    • Azure-services zijn beschikbaar zoals vereist.
    • Het proces dat moet worden gevolgd als aan een van de vereisten is voldaan.
  • Technisch herstel - stapsgewijze instructies
    • Uitvoeringsvolgorde.
    • Beschrijving van stap.
    • Vereiste stap.
    • Gedetailleerde processtappen voor elke afzonderlijke actie, inclusief URL's.
    • Validatie-instructies, inclusief het vereiste bewijs.
    • Verwachte tijd om elke stap te voltooien, inclusief onvoorziene gebeurtenissen.
    • Het proces dat moet worden gevolgd als de stap mislukt.
    • De escalatiepunten in het geval van storingen of SME-ondersteuning.
  • Technisch herstel - na vereisten
    • Bevestig de huidige datumtijdstempel van het systeem voor belangrijke onderdelen.
    • Bevestig de DR-systeem-URL's en IP-adressen.
    • Bereid u voor op het beoordelingsproces van zakelijke belanghebbenden, inclusief bevestiging van toegang tot systemen en het mkb dat de validatie en goedkeuring voltooit.
  • Beoordeling en goedkeuring van zakelijke belanghebbenden
    • Contactgegevens voor zakelijke resources.
    • De stappen voor bedrijfsvalidatie volgens het bovenstaande technische herstel.
    • Het bewijsspoor dat is vereist van de fiatteur die het herstel aftekent.
  • Herstel na vereisten
    • Overdracht naar operationele ondersteuning om de gegevensprocessen uit te voeren om het systeem up-to-date te brengen.
    • Handover de downstreamprocessen en oplossingen – de datum en verbindingsgegevens van het DR-systeem bevestigen.
    • Bevestig het herstelproces dat is voltooid met de dr-lead: bevestig het bewijstrail en het voltooide runbook.
    • Beveiligingsteams waarschuwen dat verhoogde toegangsbevoegdheden kunnen worden verwijderd uit het DR-team.

Bijschriften

  • Het is raadzaam om systeemschermafbeeldingen van elk stapproces op te nemen. Deze schermopnamen helpen de afhankelijkheid van het mkb van het systeem aan te pakken om de taken te voltooien.
    • Om snel veranderende cloudservices bij te houden, moet het DR-plan regelmatig opnieuw worden bekeken, getest en uitgevoerd door resources met de huidige kennis van Azure en de bijbehorende services.
  • De stappen voor technisch herstel moeten de prioriteit van het onderdeel en de oplossing voor de organisatie weerspiegelen. Belangrijke ondernemingsgegevensstromen worden bijvoorbeeld hersteld voordat ad-hoc gegevensanalyselabs worden gebruikt.
  • De stappen voor technisch herstel moeten de volgorde van de werkstromen volgen (meestal van links naar rechts), zodra de basisonderdelen of service zoals Key Vault zijn hersteld. Deze strategie zorgt ervoor dat upstream-afhankelijkheden beschikbaar zijn en dat onderdelen op de juiste wijze kunnen worden getest.
  • Zodra het stapsgewijze plan is voltooid, moet een totale tijd voor activiteiten met onvoorziene gebeurtenissen worden verkregen. Als dit totaal de overeengekomen beoogde hersteltijd (RTO) heeft bereikt, zijn er verschillende opties beschikbaar:
    • Geselecteerde herstelprocessen automatiseren (indien mogelijk).
    • Zoek naar mogelijkheden om geselecteerde herstelstappen parallel uit te voeren (indien mogelijk). Het is echter mogelijk dat voor deze strategie aanvullende dr-uitvoerprogramma's nodig zijn.
    • Hef belangrijke onderdelen op naar hogere servicelagen, zoals PaaS, waarbij Microsoft meer verantwoordelijkheid neemt voor serviceherstelactiviteiten.
    • Breid de RTO uit met belanghebbenden.

DR-tests

De aard van de Azure Cloud-service die wordt aangeboden, resulteert in beperkingen voor testscenario's voor herstel na noodgeval. Daarom is het de richtlijnen om een DR-abonnement op te stellen met de onderdelen van het gegevensplatform, omdat ze beschikbaar zouden zijn in de secundaire regio.

Vanaf deze basislijn kan het runbook voor herstel na noodgeval selectief worden uitgevoerd, waarbij specifieke aandacht wordt besteed aan de services en onderdelen die kunnen worden geïmplementeerd en gevalideerd. Voor dit proces is een gecureerde testgegevensset vereist, waardoor de bevestiging van de technische en bedrijfsvalidatiecontroles volgens het plan wordt ingeschakeld.

Een DR-plan moet regelmatig worden getest om er niet alleen voor te zorgen dat het up-to-date is, maar ook om 'spiergeheugen' te bouwen voor de teams die failover- en herstelactiviteiten uitvoeren.

  • Back-ups van gegevens en configuratie moeten ook regelmatig worden getest om ervoor te zorgen dat ze 'geschikt voor doel' zijn om herstelactiviteiten te ondersteunen.

Het belangrijkste gebied waar u zich tijdens een DR-test op moet richten, is ervoor te zorgen dat de prescriptieve stappen nog steeds correct zijn en dat de geschatte tijdsinstellingen nog steeds relevant zijn.

  • Als de instructies de portalschermen weerspiegelen in plaats van code, moeten de instructies ten minste om de 12 maanden worden gevalideerd vanwege de frequentie van wijzigingen in de cloud.

Hoewel het streven is om een volledig geautomatiseerd DR-proces te hebben, kan volledige automatisering onwaarschijnlijk zijn vanwege de zeldzaamheid van het evenement. Daarom is het raadzaam om de herstelbasislijn met dsc-infrastructuur (Desired State Configuration) als code (IaC) te bepalen die wordt gebruikt om het platform te leveren en vervolgens op te tillen als nieuwe projecten op basis van de basislijn worden gebouwd.

  • Na verloop van tijd als onderdelen en services worden uitgebreid, moet een NFR worden afgedwongen, waardoor de pijplijn voor productie-implementatie moet worden geherstructureerd om dekking te bieden voor herstel na noodgeval.

Als de timing van uw runbook groter is dan uw RTO, zijn er verschillende opties:

  • Breid de RTO uit met belanghebbenden.
  • Verlaag de tijd die nodig is voor de herstelactiviteiten, via automatisering, het parallel uitvoeren van taken of migratie naar hogere cloudserverlagen.

Azure Chaos Studio

Azure Chaos Studio is een beheerde service voor het verbeteren van de tolerantie door fouten in uw Azure-toepassingen te injecteren. Met Chaos Studio kunt u foutinjectie op een veilige en gecontroleerde manier op uw Azure-resources organiseren met behulp van experimenten. Zie de productdocumentatie voor een beschrijving van de typen fouten die momenteel worden ondersteund.

De huidige iteratie van Chaos Studio omvat alleen een subset van Azure-onderdelen en -services. Totdat er meer foutbibliotheken worden toegevoegd, is Chaos Studio een aanbevolen benadering voor geïsoleerde tolerantietests in plaats van voor volledige systeemhersteltests.

Meer informatie over Chaos Studio vindt u in de documentatie van Azure Chaos Studio.

Azure Site Recovery

Voor IaaS-onderdelen beveiligt Azure Site Recovery de meeste workloads die worden uitgevoerd op een ondersteunde VM of fysieke server

Er is sterke richtlijnen voor:

Volgende stappen

Nu u hebt geleerd hoe u het scenario kunt implementeren, kunt u een samenvatting lezen van de DR voor azure-gegevensplatformreeksen.