Back-up en herstel na noodherstel voor Azure-toepassingen

Herstel na noodherstel is het proces van het herstellen van toepassingsfunctionaliteit na een onherstelbare verlies.

In de cloud bevestigen we van te voren dat er fouten optreden. In plaats van fouten helemaal te proberen te voorkomen, is het doel de effecten van een onderdeel met een storing te beperken. Testen is één manier om deze effecten te minimaliseren. Automatiseer waar mogelijk het testen van uw toepassingen, maar u moet worden voorbereid op wanneer ze mislukken. Wanneer er een fout is, wordt het belangrijk om strategieën voor back-up en herstel te hebben.

Uw tolerantie voor verminderde functionaliteit tijdens een noodlott is een zakelijke beslissing die per toepassing varieert. Het kan acceptabel zijn dat sommige toepassingen niet beschikbaar zijn of gedeeltelijk beschikbaar zijn met verminderde functionaliteit of een tijdje vertraagde verwerking. Voor andere toepassingen is een verminderde functionaliteit onaanvaardbaar.

Belangrijkste punten

  • Maak en test regelmatig een noodherstelplan met behulp van belangrijke foutscenario's.
  • Ontwerp een strategie voor herstel na noodherstel om de meeste toepassingen met verminderde functionaliteit uit te voeren.
  • Ontwerp een back-upstrategie die is afgestemd op zakelijke vereisten en omstandigheden van de toepassing.
  • Stappen en processen voor failover en failback automatiseren.
  • Test en valideer de failover- en failback-benadering ten minste één keer.

Plan voor herstel na een noodgeval

Begin met het maken van een herstelplan. Het plan wordt als voltooid beschouwd nadat het volledig is getest. Neem de personen, processen en toepassingen op die nodig zijn om de functionaliteit te herstellen binnen de Service Level Agreement (SLA) die u voor uw klanten hebt gedefinieerd.

Houd rekening met de volgende suggesties bij het maken en testen van uw noodherstelplan:

  • Neem het proces op voor contact opnemen met ondersteuning en voor het escaleren van problemen. Deze informatie helpt langdurige downtime te voorkomen wanneer u het herstelproces voor de eerste keer uitwerkt.
  • Evalueer de impact van toepassingsfouten op uw bedrijf.
  • Kies een herstelarchitectuur tussen regio's voor bedrijfskritieke toepassingen.
  • Identificeer een specifieke eigenaar van het noodherstelplan, inclusief automatisering en testen.
  • Documenteren van het proces, met name handmatige stappen.
  • Automatiseer het proces zoveel mogelijk.
  • Stel een back-upstrategie op voor alle referentie- en transactionele gegevens en test het herstel van back-ups regelmatig.
  • Stel waarschuwingen in voor de stack van de Azure-services die door uw toepassing worden gebruikt.
  • Train operationele medewerkers om het plan uit te voeren.
  • Voer regelmatig simulaties van noodscenario's uit om het plan te valideren en te verbeteren.

Als u Azure-Site Recovery virtuele machines (VM's) repliceert, maakt u een volledig geautomatiseerd herstelplan om een fail over de hele toepassing uit te voeren.

Operationele gereedheid testen

Voer een operationele gereedheidstest uit voor failover naar de secundaire regio en voor failback naar de primaire regio. Veel Azure-services ondersteunen handmatige failover of testfailover voor DR-herstelanalyse. In plaats daarvan kunt u een storing simuleren door Azure-services af te sluiten of te verwijderen.

Geautomatiseerde operationele reacties moeten regelmatig worden getest als onderdeel van de normale toepassingslevenscyclus om operationele effectiviteit te garanderen.

Failover- en failbacktests

Test failover en failback om te controleren of de afhankelijke services van uw toepassing op een gesynchroniseerde manier worden hersteld tijdens herstel na noodherstel. Wijzigingen in systemen en bewerkingen kunnen van invloed zijn op failover- en failbackfuncties, maar de impact kan pas worden gedetecteerd als het hoofdsysteem uitvalt of overbelast raakt. Test de failovermogelijkheden voordat ze nodig zijn om een liveprobleem te compenseren. Zorg er ook voor dat failover en failback van afhankelijke services in de juiste volgorde zijn.

Als u Azure-Site Recovery om VM's te repliceren, moet u periodiek noodhersteloefeningen uitvoeren door failovers te testen om uw replicatiestrategie te valideren. Een test-failover heeft geen invloed op de lopende VM-replicatie of uw productieomgeving. Zie Een noodhersteloefening uitvoeren naar Azure voor meer informatie.

Uitval van afhankelijke service

Voor elke afhankelijke service moet u de gevolgen van serviceonderbreking begrijpen en de manier waarop de toepassing reageert. Veel services bevatten functies die tolerantie en beschikbaarheid ondersteunen, dus als u elke service onafhankelijk evalueert, wordt uw plan voor herstel na noodherstel waarschijnlijk verbeterd. Een voorbeeld: Azure Event Hubs ondersteuning voor een over-naar-de-secundaire naamruimte.

Netwerkstoring

Wanneer delen van het Azure-netwerk niet toegankelijk zijn, hebt u mogelijk geen toegang tot uw toepassing of gegevens. In dit geval raden we u aan de strategie voor herstel na noodherstel te ontwerpen om de meeste toepassingen met verminderde functionaliteit uit te voeren.

Als het verminderen van functionaliteit geen optie is, zijn de resterende opties downtime van toepassingen of failover naar een alternatieve regio.

In een scenario met verminderde functionaliteit:

  • Als uw toepassing geen toegang heeft tot de gegevens vanwege een netwerkstoring in Azure, kunt u lokaal uitvoeren met verminderde toepassingsfunctionaliteit met behulp van gegevens in de cache.
  • U kunt gegevens opslaan op een alternatieve locatie totdat de verbinding is hersteld.

Herstelautomatisering

De stappen die nodig zijn om de toepassing te herstellen of een failover uit te voeren naar een secundaire Azure-regio in foutsituaties, moeten worden gecodificeerd, bij voorkeur op een geautomatiseerde manier, om ervoor te zorgen dat er mogelijkheden bestaan om effectief te reageren op een storing op een manier die de impact beperkt. Er moeten ook vergelijkbare gecodificeerde stappen bestaan om het proces vast te leggen dat nodig is om een failback van de toepassing naar de primaire regio uit te voeren zodra een probleem met een failovertrigger is opgelost.

Bij het automatiseren van failoverprocedures moet u ervoor zorgen dat de hulpprogramma's die worden gebruikt voor het in de organisatie van de failover ook worden overwogen in de failoverstrategie. Als u bijvoorbeeld uw failover vanuit Jenkins op een virtuele machine hebt uitgevoerd, hebt u problemen als die virtuele machine deel uitmaakt van de storing. Azure DevOps Projects zijn ook beperkt tot een regio.

Back-upstrategie

Er zijn veel alternatieve strategieën beschikbaar voor het implementeren van gedistribueerde rekenkracht tussen regio's. Deze strategieën moeten worden afgestemd op de specifieke zakelijke vereisten en omstandigheden van de toepassing. Op hoog niveau kunnen de benaderingen worden onderverdeeld in de volgende categorieën:

  • Opnieuw toepassen bij nood: Bij deze benadering wordt de toepassing op het moment van nood opnieuw geïmplementeerd. Het opnieuw in gebruik nemen van een nieuwe oplossing is geschikt voor niet-kritieke toepassingen waarvoor geen gegarandeerde hersteltijd is vereist.

  • Warm Spare (actief/passief): maak een secundaire gehoste service in een alternatieve regio en implementeer rollen om minimale capaciteit te garanderen. De rollen ontvangen echter geen productieverkeer. Deze aanpak is handig voor toepassingen die niet zijn ontworpen om verkeer over regio's te verdelen.

  • Hot Spare (actief/actief): De toepassing is ontworpen om productiebelasting in meerdere regio's te ontvangen. De cloudservices in elke regio kunnen worden geconfigureerd voor een hogere capaciteit dan is vereist voor herstel na noodherstel. In plaats daarvan kunnen de cloudservices zo nodig worden geschaald op het moment van een noodlottigheid en failover. Deze aanpak vereist een grote investering in het ontwerp van toepassingen, maar heeft aanzienlijke voordelen. Dit zijn onder andere lage en gegarandeerde hersteltijd, continue tests van alle herstellocaties en efficiënt gebruik van capaciteit.

Plannen voor regionale storingen

Azure is fysiek en logisch onderverdeeld in eenheden die regio's worden genoemd. Een regio bestaat uit een of meer datacenters in de nabijheid. Veel regio's en services ondersteunen ook beschikbaarheidszones, die kunnen worden gebruikt om meer tolerantie te bieden tegen uitval in één datacenter. Overweeg het gebruik van regio's met beschikbaarheidszones om de beschikbaarheid van uw oplossing te verbeteren.

Onder zeldzame omstandigheden is het mogelijk dat faciliteiten in een volledige beschikbaarheidszone of regio ontoegankelijk kunnen worden, bijvoorbeeld vanwege netwerkfouten. Of faciliteiten kunnen volledig verloren gaan, bijvoorbeeld vanwege een natuurramp. Azure biedt mogelijkheden voor het maken van toepassingen die zijn gedistribueerd over zones en regio's. Een dergelijke verdeling helpt de kans te minimaliseren dat een storing in de ene zone of regio invloed kan hebben op andere zones of regio's.

Volgende stap

Terug het hoofdartikel: Testen