Failover: hoe systemen zichzelf overeind houden bij een storing
Stel je een ziekenhuis voor tijdens een stroomstoring. Op het moment dat het licht uitvalt, springt binnen enkele seconden een noodgenerator aan, zodat beademingsapparatuur en operatiekamers gewoon door blijven draaien. De meeste patiënten merken er weinig van. Dit automatisch overschakelen naar een reservevoorziening zodra iets uitvalt, heet in de techniek failover.
In de digitale wereld werkt het net zo. Een populaire website draait normaal op één server. Valt die server uit door een defect of overbelasting, dan neemt een tweede, identiek ingerichte server het automatisch over. Bezoekers zien in het beste geval helemaal niets van de storing; in het slechtste geval een korte onderbreking van een paar seconden. Failover is dus geen technologie op zich, maar een ontwerpprincipe: zorg dat er altijd een back-up klaarstaat die het werk overneemt zonder dat een mens hoeft in te grijpen.
Wat is het precies?
Een failoversysteem bestaat minimaal uit twee onderdelen: een primair systeem dat normaal alle taken uitvoert, en een secundair systeem dat klaarstaat om over te nemen. Dat secundaire systeem kan passief zijn (het staat stil te wachten, ook wel active-passive genoemd) of actief meedraaien en een deel van het werk al doen (active-active, waarbij beide systemen tegelijk belasting verwerken).
Om te weten wanneer moet worden overgeschakeld, controleren systemen elkaar voortdurend met zogeheten heartbeats: korte signaaltjes die zeggen "ik leef nog". Blijft dat signaal een aantal keer achter elkaar uit, dan concludeert het systeem dat er een storing is. Deze health checks gebeuren vaak elke paar seconden.
Zodra een storing is vastgesteld, volgt de daadwerkelijke omschakeling. Dat kan op meerdere manieren: door het verkeer te herrouteren via een load balancer (een verkeersregelaar die bepaalt welke server een verzoek krijgt), door een virtueel IP-adres te verhuizen naar de reserveserver, door DNS-instellingen aan te passen, of via gespecialiseerde clustersoftware die dit allemaal automatisch regelt.
Cruciaal is dat de reserveserver over actuele gegevens beschikt. Dit gebeurt via datareplicatie: elke wijziging op het primaire systeem wordt vrijwel gelijktijdig gekopieerd naar de standby. Hoeveel data je hierbij maximaal kunt verliezen, wordt uitgedrukt in de Recovery Point Objective (RPO). Hoe lang de omschakeling maximaal mag duren, heet de Recovery Time Objective (RTO). Kritieke financiële systemen streven naar een RPO en RTO van vrijwel nul; minder kritieke diensten accepteren soms minuten downtime.
Is het probleem verholpen, dan volgt vaak een failback: de terugkeer naar het oorspronkelijke, herstelde systeem. Een bekend risico hierbij is split-brain: een situatie waarin zowel het oude als het nieuwe systeem denkt dat het de baas is, waardoor gegevens uit elkaar kunnen gaan lopen. Goede failoversystemen zijn juist zorgvuldig ontworpen om dit te voorkomen, bijvoorbeeld met een derde, onafhankelijke "scheidsrechter" die bepaalt welk systeem leidend is.
Wat wil men ermee bereiken?
Het overkoepelende doel is hoge beschikbaarheid: een dienst die (bijna) altijd bereikbaar is. Beschikbaarheid wordt vaak uitgedrukt in "negens": 99,9% uptime betekent ruim acht uur downtime per jaar, terwijl 99,999% uptime ("vijf negens") neerkomt op nog geen vijf minuten per jaar. Dat laatste niveau is alleen haalbaar met goed werkende failover.
Achterliggend gaat het om bedrijfscontinuïteit: een webshop die urenlang plat ligt, verliest omzet en klanten; een bank die niet kan betalen, verliest vertrouwen. Voor sectoren als bankwezen en zorg gelden bovendien wettelijke eisen (compliance) rond beschikbaarheid en gegevensbescherming, waar failover een verplicht onderdeel van is.
Ten slotte maakt failover het mogelijk om onderhoud te plegen zonder de dienst stil te leggen: technici kunnen een server bijwerken terwijl het verkeer tijdelijk naar de reserve gaat. Bij echt kritieke infrastructuur — het stroomnet, verkeersleiding op luchthavens, ziekenhuisapparatuur, betalingsverkeer — is failover uiteindelijk een kwestie van vertrouwen: mensen moeten erop kunnen rekenen dat een storing op de achtergrond wordt opgevangen.
Voorbeelden uit de praktijk
AWS Multi-AZ (sinds 2010): Amazon Web Services biedt voor zijn databasedienst RDS een functie genaamd Multi-AZ, waarbij automatisch een kopie van de database in een andere "availability zone" (een fysiek gescheiden datacenterlocatie) wordt bijgehouden. Valt de primaire database uit, dan schakelt AWS binnen ongeveer een minuut automatisch over.
Netflix en Chaos Monkey (2011): Netflix ontwikkelde als onderdeel van zijn "Simian Army" de tool Chaos Monkey, die willekeurig servers in productie uitschakelt om te testen of failover daadwerkelijk werkt. Na een grote storing bij AWS met kerstavond 2012, waardoor Netflix zelf uitviel, investeerde het bedrijf zwaar in het kunnen uitwijken naar andere regio's.
Google Cloud Spanner (2017): deze wereldwijd verspreide database van Google kan bij het uitvallen van een hele regio automatisch doordraaien op datacenters elders, dankzij ingebouwde consensusmechanismen die continu bepalen welke kopie leidend is.
Kubernetes (breed in gebruik sinds circa 2015): dit open source-systeem voor het beheren van softwarecontainers bevat een "controller-loop" die voortdurend controleert of onderdelen (pods) nog gezond zijn. Valt een server (node) uit, dan worden de daarop draaiende onderdelen automatisch elders opnieuw gestart.
TARGET2, het Europese betalingssysteem van de ECB: dit systeem, waarmee banken in de eurozone grote betalingen afwikkelen, draait met uitwijkvoorzieningen om te voorkomen dat een storing het Europese betalingsverkeer platlegt. Over de precieze technische inrichting van deze uitwijk is publiekelijk beperkte informatie beschikbaar.
Hoe ver is de techniek?
Failover is geen nieuw idee. Al in 1983 bracht computerfabrikant DEC de VAXcluster op de markt, een van de eerste commerciële systemen waarbij meerdere computers samen één geheel vormden en elkaars taken konden overnemen. Latere clusteroplossingen zoals Oracle RAC (2001) en Windows Server Failover Clustering brachten dit naar bedrijfsdatabases en -servers.
De opkomst van cloud computing heeft failover sterk toegankelijker gemaakt: waar bedrijven vroeger zelf dubbele hardware moesten inkopen en beheren, regelen clouddiensten dit nu grotendeels automatisch, tegen betaling. Ook algoritmische doorbraken hielpen: het Paxos-algoritme van informaticus Leslie Lamport (jaren negentig) en het latere, beter te begrijpen Raft-algoritme (2014, ontwikkeld door Diego Ongaro) maken het mogelijk dat een groep computers automatisch en betrouwbaar met elkaar afspreekt wie de "leider" is, zonder menselijke tussenkomst.
De huidige ontwikkeling richt zich vooral op failover over hele regio's en zelfs meerdere cloudleveranciers heen, en op "chaos engineering": het opzettelijk veroorzaken van storingen om te toetsen of failover echt werkt, vaak ondersteund door zogeheten service meshes die netwerkverkeer tussen onderdelen slim kunnen omleiden.
Toch blijven er reële beperkingen. Split-brain-problemen zijn nooit volledig uit te sluiten. Dubbele infrastructuur kost geld, wat lang niet elke organisatie zich voor elk systeem kan veroorloven. En misschien wel de grootste eerlijke onzekerheid: failovermechanismen worden in de praktijk vaak onvoldoende getest, omdat een echte storing simuleren risicovol en omslachtig is. Daardoor blijkt een failoversysteem soms pas tijdens een daadwerkelijke crisis niet naar behoren te werken.
Wie werken eraan?
De grote cloudpartijen — Amazon (AWS), Google Cloud, Microsoft Azure en het Chinese Alibaba Cloud — bouwen failover standaard in hun diensten in en investeren voortdurend in verbetering ervan. Daarnaast speelt open source een grote rol: projecten onder de paraplu van de Cloud Native Computing Foundation (CNCF), zoals Kubernetes, de gegevensopslag etcd en HashiCorp's Consul, vormen de basis van veel moderne failoversystemen.
Softwareleveranciers als Red Hat (met OpenShift), VMware, Oracle en IBM bieden bedrijven kant-en-klare clusteroplossingen. Aan de wetenschappelijke basis werkten onderzoekers als Leslie Lamport (later verbonden aan Microsoft Research) en Diego Ongaro en John Ousterhout aan Stanford University, wiens werk aan consensusalgoritmes de theoretische grondslag legde voor betrouwbare, geautomatiseerde failover.
Op het gebied van normen en richtlijnen speelt het Uptime Institute een rol met zijn bekende "tier"-classificatie voor de betrouwbaarheid van datacenters, en houdt het Europese cyberbeveiligingsagentschap ENISA zich bezig met richtlijnen voor de weerbaarheid van kritieke infrastructuur. Sectoren als bankwezen (denk aan de Europese Centrale Bank en het internationale betalingsnetwerk SWIFT) en telecom investeren van oudsher zwaar in dit soort systemen, omdat uitval daar direct maatschappelijke gevolgen heeft.