Noodherstelanalyse uitvoeren
In deze les krijgt u informatie over Site Recovery-noodanalyses: wat u moet overwegen en hoe u een test uitvoert om te controleren of de configuratie juist is.
U kunt dr-oefeningen (disaster recovery) gebruiken om de mogelijkheid van uw organisatie te testen om te herstellen na een storing zonder dat dit van invloed is op een productieservice.
In de vorige oefening hebt u het instellen van Azure Site Recovery voltooid en moet u nu uw infrastructuurreplicatie testen. Test uw configuratie door een DR-herstelanalyse uit te voeren. Met Azure Site Recovery kunt u deze drills veilig uitvoeren, zodat dit geen invloed heeft op uw productieomgeving. U voert ook enkele kwaliteitscontroletests uit op de configuratie om ervoor te zorgen dat uw DR-oplossing werkt.
Wat is een noodherstelanalyse?
Een DR-herstelanalyse is een manier om te controleren of u de oplossing correct hebt geconfigureerd. De analyse geeft u en uw bedrijf het vertrouwen dat uw gegevens en services beschikbaar zijn, zelfs als er zich een noodgeval voordoet. Normaal gesproken stellen organisaties een beoogde hersteltijd (RTO) in, wat aangeeft hoe lang het duurt om de infrastructuur te herstellen. Uw bedrijf moet ook een RPO (Recovery Point Objective) definiëren, waarmee de hoeveelheid gegevensverlies wordt bepaald die acceptabel is als een functie van tijd. Als de RPO van uw bedrijf bijvoorbeeld een dag is, moet u elke dag een back-up maken van al uw gegevens. U moet er ook voor zorgen dat het minder dan een dag duurt om deze back-up te herstellen.
U ontvangt meldingen op het Site Recovery-dashboard om ervoor te zorgen dat u de DR-tests uitvoert.
Waarom moet u een noodherstelanalyse uitvoeren?
Een DR-analyse is essentieel om ervoor te zorgen dat de geïmplementeerde oplossing voldoet aan de vereisten voor bedrijfscontinuïteit en herstel na noodgevallen (BCDR) en om ervoor te zorgen dat de replicatie op de juiste wijze werkt. Uw DR-analyse, gecombineerd met RTO en RPO, moet grondig worden getest om ervoor te zorgen dat replicatie, failover en herstel plaatsvinden in de vereiste periode.
Stel dat uw RTO een uur is en dat de RPO zes uur is. Als er elk uur een back-up wordt gemaakt van uw systemen, hebt u één uur aan verloren gegevens plus het extra uur dat nodig is om uw systemen te herstellen.
Stel dat de werkelijke hersteltijd vijf uur is. Uw systemen zijn nu bijna zes uur verouderd, wat betekent dat u de BCDR RPO-doelstelling schendt. Door te testen hoeveel tijd er werkelijk nodig is om te herstellen van storingen, kunt u erop vertrouwen dat uw systemen de BCDR-plannen volgen.
Testfailover van afzonderlijke computers
Met een failovertest kunt u een noodgeval simuleren en de effecten ervan bekijken. U kunt een failovertest starten vanaf het Site Recovery-dashboard of rechtstreeks vanuit het menu herstel na noodgevallen op een specifieke VIRTUELE machine. Als eerste kiest u een herstelpunt. U kunt kiezen uit het laatst verwerkte herstelpunt, het laatste toepassingsconsistente punt in de tijd of een aangepast herstelpunt.
Een failovertest maken
Maak een geïsoleerd virtueel netwerk, zodat uw productie-infrastructuur niet wordt beïnvloed. Dit doet u als volgt:
Open de doel-VM met de naam patiëntrecords. Een eenvoudige manier om dit te vinden is door alle resources te filteren om alleen Type == Virtuele machine weer te geven. Selecteer patiëntrecords in de lijst met resultaten.
Schuif in het resourcemenu naar Bewerkingen en selecteer vervolgens Herstel na noodgevallen.
Er wordt een nieuw deelvenster Gerepliceerde items weergegeven. Selecteer Vernieuwen totdat u Beveiligd in het statusveld ziet. Selecteer vervolgens in de bovenste menubalk testfailover.
Zodra de validatie is geslaagd, selecteert u uw virtuele netwerk in de vervolgkeuzelijst van het virtuele Azure-netwerk en selecteert u vervolgens de knop Failover testen . Met deze optie wordt een testfailover van de VIRTUELE machine uitgevoerd en kunt u de voortgang ervan volgen via de pagina Site Recovery-taken door het pictogram Meldingen te selecteren en de taak starten te selecteren om een testfailover van de koppeling naar virtuele machines uit te voeren.
Na voltooiing wordt de failover-VM weergegeven in de portal onder Virtuele machines in de herstelregio. U kunt vervolgens controleren of de VM wordt uitgevoerd, de juiste omvang heeft, op de juiste manier is verbonden en een spiegeling is van de bron-VM, maar in een andere Azure-regio.
Nadat u hebt gecontroleerd of alles naar verwachting heeft gewerkt, kunt u de gerepliceerde VM verwijderen door De testfailover opschonen te selecteren in het deelvenster Herstel na noodgevallen. Op dit moment raden we u aan notities over het testresultaat toe te voegen. Schakel het selectievakje naast Testen is voltooid om de virtuele machine voor testfailover te verwijderen en selecteer VERVOLGENS OK.
Flexibele failover van meerdere machines
Site Recovery biedt u de flexibiliteit om een volledig DR-testscenario uit te voeren voor al uw VM's. U kunt herstelplannen maken die een of meer van uw VM's omvatten. Failovers kunnen zo vaak als u wilt worden uitgevoerd en bieden een flexibel beleid om verschillende infrastructuurcombinaties te testen.
De test voor het opschonen van afzonderlijke virtuele machines is ook beschikbaar voor alle onderdelen in de cloud die in het herstelplan zijn opgenomen.
Het verschil tussen een analyse en een productie-failover
Het uitvoeren van een productie-failover in Site Recovery lijkt op het uitvoeren van een testanalyse. Er zijn echter wel een aantal verschillen. Ten eerste moet u Failover selecteren in plaats van Testfailover. U kunt ervoor kiezen de bron-VM af te sluiten voordat de failover wordt gestart, zodat er geen gegevens verloren gaan tijdens de overschakeling. Site Recovery schoont de bronomgeving niet op nadat de failover is voltooid.
Nadat de failover is voltooid, controleert u of de VM naar verwachting werkt. Met Site Recovery kunt u het herstelpunt in deze fase wijzigen. Als u tevreden bent over de werking van de failover, kunt u de failover Doorvoeren. Site Recovery verwijdert alle bron-VM-herstelpunten en voltooit de failover. Nu de infrastructuur en gegevens zijn gerepliceerd in de secundaire regio, moet u niet vergeten dat de nieuwe VM in de secundaire regio ook moet worden beveiligd.