Back-up en herstel na noodherstel voor Azure-toepassingen

  • Artikel
  • 6 minuten om te lezen

Herstel na noodherstel is het proces van het herstellen van de 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. U moet waar mogelijk het testen van uw toepassingen automatiseren, maar u moet erop voorbereid zijn wanneer ze mislukken. Als dit gebeurt, wordt het belangrijk om strategieën voor back-up en herstel te hebben.

Uw tolerantie voor verminderde functionaliteit tijdens een noodlot 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 vertraagde verwerking voor een bepaalde periode. Voor andere toepassingen is elke 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 beperkte 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 om contact op te nemen 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 voor verschillende 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 na noodscenario's uit om het plan te valideren en te verbeteren.

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

Testen van operationele gereedheid

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. U kunt een storing ook 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.

Testen van failover en failback

Test failover en failback om te controleren of de afhankelijke services van uw toepassing tijdens herstel na noodherstel op een gesynchroniseerde manier worden hersteld. 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 live probleem te compenseren. Zorg er ook voor dat failover en failback van afhankelijke services in de juiste volgorde worden gebruikt.

Als u virtuele Azure Site Recovery repliceert, 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 op Azure voor meer informatie.

Afhankelijke service-uitval

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, is het waarschijnlijk dat u uw plan voor herstel na nood gevallen verbetert. Een voorbeeld: Azure Event Hubs ondersteuning voor het overgezet 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 beperkte functionaliteit:

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

Herstelautomatisering

De stappen die nodig zijn om de toepassing in foutsituaties te herstellen of een failover uit te voeren naar een secundaire Azure-regio, 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 failover-procedures 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 in verschillende regio's. Deze moeten worden afgestemd op de specifieke bedrijfsvereisten en -omstandigheden van de toepassing. Op hoog niveau kunnen de benaderingen worden onderverdeeld in de volgende categorieën:

  • Opnieuw worden geïmplementeerd bij nood: bij deze benadering wordt de toepassing op het moment van nood opnieuw geïmplementeerd. Dit is geschikt voor niet-kritieke toepassingen waarvoor geen gegarandeerde hersteltijd is vereist.

  • Warm Spare (actief/passief): Er wordt een secundaire gehoste service gemaakt in een alternatieve regio en rollen worden geïmplementeerd 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 hogere capaciteit dan vereist voor herstel na noodherstel. De cloudservices kunnen ook zo nodig worden geschaald op het moment van een noodlottigheid en failover. Deze aanpak vereist aanzienlijke investeringen 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 als gevolg van een natuurramp. Azure biedt mogelijkheden voor het maken van toepassingen die worden gedistribueerd over zones en regio's. Een dergelijke distributie 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

Foutafhandeling

Terug het hoofdartikel: Testen