Wat zijn failover en failback?

Dit artikel bevat een algemeen overzicht van hoe failover en failback worden uitgevoerd in een cloudomgeving. Voor meer informatie over failover moet u echter eerst de redundantie en replicatie begrijpen. Zie Redundantie, replicatie en back-up voor meer informatie over deze concepten voordat u verdergaat met dit artikel.

Een veelvoorkomende reden voor het onderhouden van redundante kopieën van zowel toepassingen als gegevensreplica's is het uitvoeren van een failover. Met failover kunt u verkeer en verzoeken van ongezonde exemplaren omleiden naar gezonde exemplaren. Zodra de oorspronkelijke exemplaren weer in orde zijn, kunt u een failback uitvoeren om terug te keren naar de oorspronkelijke configuratie.

Actieve en passieve instance-rollen

In de context van failover kan een exemplaar één onderdeel zijn, zoals een database, of een verzameling van meerdere onderdelen waaruit een service-implementatie in een regio bestaat. Over een hele oplossing kunt u op verschillende manieren en in verschillende situaties een failover uitvoeren voor verschillende onderdelen van die oplossing.

Voor een onderdeel of verzameling onderdelen die zijn geconfigureerd voor failover en failback, zijn meerdere exemplaren vereist. Elk van deze exemplaren neemt een bepaalde rol aan:

• Primaire of actieve exemplaren werken actief, zoals het verwerken van binnenkomende aanvragen van clients. Meestal is er één primair exemplaar op een bepaald moment.
• Secundaire of passieve exemplaren zijn inactief, maar kunnen indien nodig worden overgeschakeld naar de primaire instantie. Er kunnen verschillende secundaire exemplaren zijn.

Er zijn verschillende manieren om passieve exemplaren te configureren. Elke manier omvat compromissen tussen hersteltijd en andere factoren, zoals kosten en operationele complexiteit:

• Hot stand-bys, die zijn ontworpen om op elk gewenst moment productieverkeer te accepteren.
• Warme stand-bys, die zijn ontworpen om bijna klaar te zijn om productieverkeer te verwerken, maar die enige configuratiewijzigingen of schaalveranderingen kunnen vereisen voordat ze verkeer aankunnen.
• Pilotlicht-standbys, die gedeeltelijk in een minimale configuratie zijn geïmplementeerd en waarvoor aanzienlijke voorbereidingen moeten worden getroffen voordat ze productieverkeer kunnen accepteren.
• Koude standbys, die mogelijk helemaal niet worden ingezet en afhankelijk zijn van onderdelen die moeten worden ingezet voordat ze productieverkeer kunnen accepteren.

Failoverbereiken

Voor verschillende situaties zijn verschillende failoverstrategieën vereist. Als u deze mogelijke strategieën wilt illustreren, kunt u een voorbeeldoplossing overwegen die bestaat uit een toepassing die toegang heeft tot gegevens uit een database. U configureert de oplossing voor failover door redundante kopieën van uw toepassingsserver en meerdere replica's van de database te maken. Vervolgens configureert u het volgende:

• Zoneredundantie door kopieën en replica's in verschillende beschikbaarheidszones binnen een Azure-regio te plaatsen.
• Georedundantie met behulp van een globale load balancer voor failover tussen regio's.

Hier volgt een vereenvoudigd diagram dat de algehele architectuur in normale bewerkingen illustreert:

Verschillende situaties kunnen verschillende failover-gebeurtenissen in deze oplossing activeren. Elk van deze komt overeen met een failoverbereik, dat de granulariteit vertegenwoordigt van de onderdelen waarvoor een failover wordt uitgevoerd:

• Een failover van een databasereplica kan optreden wanneer de actieve databasereplica niet meer beschikbaar is. De passieve replica wordt gepromoveerd tot de actieve replica. Normaal gesproken kunnen toepassingen hun aanvragen snel omleiden naar de nieuwe actieve replica:

  

• Een failover van een beschikbaarheidszone kan optreden als een volledige beschikbaarheidszone een storing ondervindt. Voor dit type storing moet al het verkeer worden gerouteerd naar de webserver in de resterende zone en ervoor zorgt dat de databasereplica in de overlevende zone de actieve replica wordt indien dat nog niet het geval is.

  

• Een regiofailover kan optreden als er sprake is van een catastrofaal verlies van de hele primaire Azure-regio.

  

Hoewel elk van deze domeinen een type failover biedt, hebben ze mogelijk verschillende failoververeisten en -processen. Daarnaast kan Microsoft verantwoordelijk zijn voor sommige aspecten van failover, zoals bij het gebruik van zone-redundante services, terwijl u mogelijk verantwoordelijk bent voor failover op bredere schaal, zoals failover tussen Azure-regio's.

Planning voor failover en bedrijfscontinuïteit

Onderdeel van de planning voor bedrijfscontinuïteit is het ontwerpen van uw failoverstrategieën, inclusief de verschillende bereiken waarvoor u een failover kunt uitvoeren.

Over het algemeen moeten uw bedrijfscontinuïteitsplannen geautomatiseerde failoverprocedures bevatten binnen of tussen beschikbaarheidszones. Dit type failover maakt deel uit van uw strategie voor hoge beschikbaarheid. Als de actieve replica van een database bijvoorbeeld mislukt, kan een geautomatiseerd proces een passieve replica promoveren tot de actieve replica. Vervolgens communiceren de webservers met de nieuwe actieve replica. Als een beschikbaarheidszone mislukt, worden veel oplossingen gebouwd om automatisch te herstellen met behulp van de resterende zones.

Verschillende failoverprocedures worden gebruikt voor noodscenario's, zoals in het onwaarschijnlijke geval van een storing in een volledige regio. In het geval van een storing in een regio kunt u de binnenkomende webaanvragen omschakelen naar de tweede regio, en een failover van de database activeren naar een replica in de secundaire regio.

Houd er rekening mee dat als u failoverprocedures in uw bedrijfscontinuïteitsplanning wilt opnemen, u meer gedetailleerd ontwerp en testen moet uitvoeren. Zie Wat zijn bedrijfscontinuïteit, hoge beschikbaarheid en herstel na noodgevallen voor meer informatie.

Geplande en niet-geplande failovers

Niet-geplande failovers zijn failovers die worden uitgevoerd tijdens een storing van een onderdeel, zodat u de service kunt herstellen met behulp van een ander exemplaar. Niet-geplande failovers leiden soms tot downtime of gegevensverlies, afhankelijk van hoe een oplossing is ontworpen. Niet-geplande failovers vereisen iets om de fout te detecteren en om te bepalen wanneer de failover moet worden geactiveerd.

Geplande failovers zijn daarentegen de failovers die u proactief activeert. U kunt dit doen in afwachting van iets, zoals een virtuele machine die wordt gepatcht en opnieuw wordt opgestart. Geplande failovers kunnen een lagere tolerantie hebben voor downtime en gegevensverlies, omdat ze deel uitmaken van reguliere onderhoudsprocedures.

De werking van failover

Failover bestaat over het algemeen uit de volgende stappen, die handmatig of door een geautomatiseerd systeem kunnen worden uitgevoerd. De specifieke details voor elk van deze stappen zijn afhankelijk van het specifieke systeem.

1. Detecteer een fout (alleen niet-geplande failovers). Een geautomatiseerde failover vereist dat iets detecteert wanneer een exemplaar niet beschikbaar is, wat doorgaans is gebaseerd op een bepaalde statuscontrole. Verschillende services definiëren hun gezondheid op verschillende manieren. Sommige services verzenden bijvoorbeeld proactief heartbeat-gebeurtenissen tussen exemplaren. Voor anderen is een afzonderlijk onderdeel vereist om elke instantie op een regelmatig interval te controleren. Het duurt vaak even voordat gezondheidsmonitors een exemplaar als mislukt hebben gedetecteerd, en het is vaak belangrijk om een gratieperiode te geven voor het geval het exemplaar gewoon bezet was en niet kon reageren.

2. Kies ervoor om over te schakelen naar failover. Op een bepaald moment wordt een beslissing genomen om een failover uit te voeren. De beslissing kan worden genomen door een geautomatiseerd hulpprogramma of handmatig. De risicotolerantie van uw organisatie kan van invloed zijn op hoe snel deze beslissing wordt genomen. Als u een lage tolerantie voor risico's hebt, kunt u ervoor kiezen om snel een failover uit te voeren als er sprake is van een probleem. Als u een hogere risicotolerantie hebt, kunt u ervoor kiezen te wachten om te zien of het probleem kan worden opgelost voordat u een failover uitvoert.

3. Selecteer een nieuw primair exemplaar. Een van de resterende voorbeelden moet de nieuwe primaire instantie worden.

   In sommige situaties hebt u mogelijk vooraf gedefinieerd welke instantie de nieuwe primaire moet worden, of misschien hebt u slechts één instantie om naartoe over te schakelen.

   In andere situaties is er een geautomatiseerd proces waarmee het systeem een nieuw primair exemplaar selecteert. Er zijn een aantal consensusalgoritmen die worden gebruikt in gedistribueerde computing, waaronder voor leiderverkiezing. Deze algoritmen worden geïmplementeerd binnen de relevante services, zoals databases. In sommige systemen is het belangrijk dat elke instantie op de hoogte wordt gesteld van de nieuwe primaire replica, zodat de resultaten van de selectie automatisch aan elke replica worden aangekondigd.

4. Omleidingsaanvragen. Configureer uw omgeving zodat verzoeken worden omgeleid naar de gezonde instanties of naar de nieuwe primaire instantie.

   Hiervoor moet u mogelijk andere systemen bijwerken, zodat ze weten waar aanvragen moeten worden verzonden. Dit kan betrekking hebben op het bijwerken van een taakverdelingssysteem om het beschadigde exemplaar uit te sluiten. In andere situaties wordt het domain name system (DNS) vaak gebruikt als een manier om aanvragen te verzenden naar een actief exemplaar van een systeem. Als onderdeel van het failoverproces moet u doorgaans DNS-records bijwerken, zodat aanvragen worden doorgestuurd naar het nieuwe primaire exemplaar. DNS heeft het concept van een time-to-live (TTL), waarmee clients wordt geïnstrueerd hoe vaak ze moeten controleren op bijgewerkte DNS-records. Als uw TTL is ingesteld op een lange waarde, kan het even duren voordat clients informatie over de failover ontvangen en ze mogelijk aanvragen blijven verzenden naar de oude primaire server.

Omdat failoverprocessen vertragingen kunnen bevatten, is het belangrijk dat u uw failoverprocedures plant om te voldoen aan uw vereisten voor downtime (uw herstelpuntdoelstelling of RTO) en gegevensverlies (uw herstelpuntdoelstelling of RPO). Zie Wat zijn bedrijfscontinuïteit, hoge beschikbaarheid en herstel na noodgevallen voor meer informatie.

Failback

Failback is het proces van het herstellen en omleiden van verkeer naar de oorspronkelijke primaire instantie.

In sommige situaties is het helemaal niet nodig om een failback uit te voeren omdat elk exemplaar even geschikt is om te fungeren als de primaire instantie. Er zijn echter situaties waarin het belangrijk is om een failback uit te voeren, bijvoorbeeld wanneer u uw toepassingen vanuit een bepaalde Azure-regio moet uitvoeren en tijdelijk een failover naar een andere regio hebt uitgevoerd tijdens een regionale storing.

Soms wordt failback op dezelfde manier verwerkt als een failover. Failback kan echter ook complexer zijn dan failover, om verschillende redenen:

• Problemen met gegevenssynchronisatie. Tijdens en zelfs na een normale failover heeft het vorige primaire exemplaar mogelijk nog wat werk uitgevoerd of sommige gegevens naar een gegevensarchief geschreven. Een onderdeel van het failbackproces is het garanderen van gegevensconsistentie en -integriteit in uw oplossing, waaronder het beheren van conflicten of duplicaties tussen de primaire en secundaire exemplaren.

  Het is gebruikelijk dat problemen met gegevenssynchronisatie handmatige tussenkomst vereisen. Als u de conflicterende gegevens niet nodig hebt, kunt u ervoor kiezen om de database of een andere status opnieuw in te stellen.

• Herstelstappen. Als er herstelstappen zijn uitgevoerd op de primaire server voordat er een failover is opgetreden, hebben ze mogelijk het primaire exemplaar in een onbekende status achtergelaten.

  Als er een risico bestaat dat het primaire exemplaar een inconsistente status heeft, moet u het primaire exemplaar mogelijk vernietigen en opnieuw implementeren, zodat deze een bekende goede status heeft voordat u een failback uitvoert.

• Extra stilstand. Downtime tijdens het failbackproces kan langer zijn dan tijdens een failover vanwege herconfiguraties die vereist zijn of bewerkingen om gegevensconsistentie te herstellen.

  U kunt dit probleem oplossen door failbackprocessen uit te voeren tijdens een onderhoudsvenster of door gebruikers van de wijziging van tevoren te adviseren. U kunt mogelijk ook enkele voorbereidende bewerkingen uitvoeren terwijl het systeem online is en de vereiste downtime minimaliseren.

• Risicotolerantie. Als de failover is opgetreden vanwege een storing, kan de tolerantie van de organisatie voor downtime of andere risico's tijdens failback lager zijn.

  Zakelijke belanghebbenden moeten gedurende het hele proces op de hoogte worden gehouden van de situatie en moeten volledig worden geïnformeerd over de noodzaak van failback en de gevolgen van de failbackprocedures. Mogelijk kunt u onderhandelen over een geschikte tijd om de wijzigingen aan te brengen.

Failover en failback in Azure-services

Hoewel het belangrijk is om te begrijpen hoe failover in het algemeen werkt, moet u er rekening mee houden dat elke Azure-service failover en failback anders kan benaderen. Zie de betrouwbaarheidshandleiding van elke service voor informatie over hoe specifieke Azure-services werken vanuit het perspectief van betrouwbaarheid.

Veel Azure-services verwerken automatisch bepaalde soorten failover. Wanneer u bijvoorbeeld Azure-services gebruikt die zijn geconfigureerd om zone-redundant te zijn, voert Microsoft automatisch een failover uit tussen beschikbaarheidszones voor u. Zie Wat zijn beschikbaarheidszones en de azure-servicebetrouwbaarheidshandleidingen voor meer informatie.

Als u virtuele machines gebruikt, repliceert Azure Site Recovery virtuele machines en de bijbehorende schijven tussen beschikbaarheidszones of naar een andere Azure-regio en kan failover voor u uitvoeren.

Wanneer u uw eigen oplossing ontwerpt die meerdere Azure-services combineert, worden uw failoververeisten mogelijk complexer. Stel dat u een oplossing ontwerpt met een toepassingslaag en -database en u een actieve/passieve architectuur voor meerdere regio's wilt maken. Tijdens een storing in de primaire regio is het belangrijk dat uw toepassing en database beide een failover naar de secundaire regio uitvoeren. Afhankelijk van de exacte services die u gebruikt, moet u mogelijk uw eigen failoverbenadering plannen om te schakelen tussen de implementaties in elke regio. Azure biedt wereldwijde verkeersroutering en taakverdeling via Azure Front Door en Azure Traffic Manager, en u kunt de technologie selecteren die voldoet aan uw failoververeisten. Elke service ondersteunt het bewaken van de status van elk regionaal exemplaar van uw toepassing en u kunt deze zo configureren dat verkeer automatisch wordt omgeleid naar het gezonde exemplaar.

Volgende stappen

• Meer informatie over de gedeelde verantwoordelijkheid voor betrouwbaarheid.
• Meer informatie over aanbevelingen voor een hoog beschikbaar multiregionale ontwerp in het Azure Well-Architected Framework.