Wanneer een webserver uitvalt, hoeft dat niet automatisch te betekenen dat een website langdurig offline blijft. Met server failover kan een tweede server klaarstaan om de dienstverlening over te nemen wanneer de primaire server niet meer bereikbaar of gezond is.
Voor bedrijven die voor aanvragen, verkopen, klantportalen of andere processen afhankelijk zijn van hun website kan zo’n redundante infrastructuur interessant zijn.
Een goede failover-oplossing bestaat echter uit veel meer dan simpelweg een tweede kopie van de website op een andere server plaatsen. Er moet onder andere worden nagedacht over monitoring, DNS, databases, bestanden, SSL, synchronisatie, e-mail, failback en de manier waarop wordt bepaald dat een server daadwerkelijk is uitgevallen.
In dit artikel leggen we uit wat server failover is, hoe DNS failover werkt en waar je rekening mee moet houden wanneer je de beschikbaarheid van een website wilt vergroten.
Wat is server failover?
Server failover is een techniek waarbij een andere server of infrastructuur beschikbaar is om diensten over te nemen wanneer de primaire omgeving uitvalt.
Een eenvoudige opzet kan bijvoorbeeld bestaan uit:
Primaire server → monitoring → storing gedetecteerd → reserve-server neemt over
De primaire server verwerkt normaal gesproken het verkeer. De secundaire server staat klaar als reserve.
Wanneer monitoring vaststelt dat de primaire omgeving niet meer gezond is, kan verkeer naar de andere omgeving worden gestuurd.
DNS-diensten zoals Amazon Route 53 ondersteunen bijvoorbeeld health checks waarbij verkeer niet langer naar een endpoint wordt gestuurd zodra dit als ongezond wordt beoordeeld.
Waarom server failover gebruiken?
De belangrijkste reden is het verkleinen van de afhankelijkheid van één server.
Zonder redundantie kan een storing aan één server ervoor zorgen dat de hele website of applicatie niet meer bereikbaar is.
Een server kan bijvoorbeeld problemen krijgen door:
- hardwareproblemen;
- netwerkproblemen;
- softwarefouten;
- databaseproblemen;
- mislukte updates;
- overbelasting;
- problemen in een datacenter;
- fouten in een hostingomgeving.
Failover voorkomt niet dat dergelijke problemen ontstaan.
Het doel is dat een storing van één onderdeel niet noodzakelijk de volledige dienstverlening stillegt.
Wat is het verschil tussen failover en een back-up?
Een backup server en een back-up zijn niet hetzelfde.
Back-up
Een back-up is een opgeslagen kopie van bestanden, databases of andere gegevens.
Deze gebruik je bijvoorbeeld wanneer:
- bestanden per ongeluk worden verwijderd;
- een database beschadigd raakt;
- een website moet worden teruggezet;
- een verkeerde wijziging ongedaan moet worden gemaakt.
Failover
Failover draait om beschikbaarheid.
Een tweede omgeving staat klaar om de dienstverlening over te nemen wanneer de primaire omgeving niet beschikbaar is.
Een failover-server vervangt een normale back-upstrategie dus niet.
Je hebt idealiter beide:
back-ups voor gegevensherstel + failover voor beschikbaarheid.
Hoe werkt automatische server failover?
Bij automatische failover moet eerst betrouwbaar worden vastgesteld of de primaire server nog gezond is.
Daarvoor worden health checks gebruikt.
Een controlesysteem kan bijvoorbeeld periodiek testen:
- reageert de server?
- geeft de website HTTP 200 terug?
- werkt een specifieke pagina?
- reageert de applicatie binnen een bepaalde tijd?
- is een achterliggende service beschikbaar?
Zodra een vooraf bepaalde foutdrempel wordt bereikt, kan het systeem de primaire omgeving als ongezond markeren.
AWS beschrijft bijvoorbeeld een DNS-failoverproces waarbij health checks de status van applicaties controleren en DNS-records van een ongezond endpoint niet meer worden aangeboden, waarna verkeer richting de gezonde omgeving gaat.
Waarom alleen een ping controleren niet genoeg is
Een server kan technisch bereikbaar zijn terwijl de website zelf niet meer functioneert.
Stel bijvoorbeeld dat:
- de server ping beantwoordt;
- de webserver draait;
- maar de database niet reageert.
Vanaf buiten lijkt de machine dan online, terwijl bezoekers een foutmelding krijgen.
Daarom is een goede health check bij voorkeur gericht op de daadwerkelijke dienstverlening.
Voor een webshop kan het bijvoorbeeld belangrijker zijn om te controleren of een dynamische pagina correct wordt opgebouwd dan alleen of het IP-adres reageert.
Wat is DNS failover?
Bij DNS failover wordt DNS gebruikt om bezoekers naar een andere server te sturen.
Een domeinnaam zoals:
www.voorbeeld.nl
wijst normaal naar een bepaald IP-adres.
Bij een failoveropstelling kunnen er bijvoorbeeld twee servers zijn:
Server A – primaire server
Server B – secundaire server
Een health-checksysteem controleert Server A.
Wordt Server A als ongezond gemarkeerd, dan kan DNS verkeer naar Server B laten gaan.
AWS Route 53 beschrijft precies dit principe: wanneer meerdere resources dezelfde functie uitvoeren, kunnen health checks worden gebruikt zodat DNS alleen gezonde resources teruggeeft.
DNS failover en TTL
Bij DNS speelt TTL, oftewel Time To Live, een belangrijke rol.
TTL bepaalt hoe lang DNS-resolvers een antwoord mogen cachen.
Bij een zeer lange TTL kunnen bezoekers na een wijziging langer het oude IP-adres blijven gebruiken.
Een kortere TTL kan een failover sneller zichtbaar maken, maar heeft eveneens gevolgen voor het aantal DNS-query’s en de manier waarop de infrastructuur wordt ingericht.
AWS adviseert voor zijn Route 53 DNS Failover bijvoorbeeld een TTL van 60 seconden of minder om de periode waarin verkeer nog naar een uitgevallen endpoint kan gaan te beperken.
Dat betekent niet dat iedere failoveroplossing automatisch dezelfde TTL moet gebruiken. De geschikte waarde hangt af van de gebruikte DNS-provider en architectuur.
DNS failover is niet volledig onmiddellijk
Een belangrijk punt is dat DNS op verschillende plaatsen wordt gecachet.
Na een wijziging kan een deel van de bezoekers daardoor nog korte tijd het oude antwoord gebruiken.
Daarom moet bij het ontwerpen van failover hosting rekening worden gehouden met:
- DNS TTL;
- resolvercache;
- browser- en netwerkgedrag;
- gebruikte DNS-provider;
- health-checkinterval;
- aantal mislukte controles voordat failover plaatsvindt.
Wie een absolute omschakeling binnen milliseconden nodig heeft, zal doorgaans verder moeten kijken dan uitsluitend traditionele DNS-failover.
Active-passive failover
Een veelgebruikte configuratie is active-passive failover.
Daarbij verzorgt de primaire server normaal gesproken het verkeer.
De tweede server blijft beschikbaar als reserve.
De structuur is dan ongeveer:
Server A – actief
↓
Server B – standby
Wanneer Server A uitvalt, wordt Server B actief.
Dit kan praktisch zijn omdat één omgeving normaal gesproken leidend blijft.
Amazon Route 53 ondersteunt onder andere dit type active-passive failover via een failover-routingbeleid.
Active-active failover
Een andere mogelijkheid is active-active.
Daarbij verwerken meerdere servers tegelijkertijd verkeer.
Wanneer één server uitvalt, blijft de andere server actief.
Bijvoorbeeld:
Server A → bezoekers
Server B → bezoekers
valt Server A uit:
Server B → bezoekers
Het voordeel is dat de secundaire infrastructuur niet uitsluitend als ongebruikte reserve staat te wachten.
Daar staat tegenover dat synchronisatie en applicatiearchitectuur complexer kunnen worden.
Route 53 ondersteunt zowel active-active als active-passive configuraties.
Websitebestanden synchroniseren tussen servers
Een tweede server heeft weinig waarde wanneer daar een verouderde versie van de website op staat.
Daarom moet worden bepaald hoe bestanden worden gesynchroniseerd.
Bij een relatief statische website kan periodieke synchronisatie soms voldoende zijn.
Bij een website die voortdurend verandert, is dat lastiger.
Denk aan:
- nieuwe uploads;
- pluginupdates;
- gewijzigde bestanden;
- productafbeeldingen;
- gegenereerde bestanden;
- gebruikersuploads.
De primaire en secundaire omgeving moeten voldoende gelijk blijven om bij een omschakeling correct te functioneren.
Database synchroniseren bij failover
Voor WordPress en WooCommerce is de database vaak nog belangrijker dan de bestanden.
WordPress bewaart daarin bijvoorbeeld:
- pagina’s;
- berichten;
- gebruikers;
- instellingen;
- plugininformatie.
WooCommerce voegt daar dynamische bedrijfsgegevens aan toe, zoals:
- bestellingen;
- klanten;
- voorraad;
- winkelwagens;
- productgegevens.
Wanneer de database van de secundaire server twintig minuten achterloopt, kan een failover betekenen dat recente gegevens ontbreken.
Daarom moet vóór invoering van failover worden bepaald:
- welke database leidend is;
- hoe replicatie plaatsvindt;
- hoe snel wijzigingen worden gekopieerd;
- wat gebeurt wanneer de hoofdserver terugkomt;
- hoe conflicterende wijzigingen worden voorkomen.
Dit is een van de redenen waarom echte high availability hosting complexer is dan twee losse kopieën van een website.
Failover voor WordPress
Een server failover voor WordPress kan interessant zijn voor websites waarbij beschikbaarheid belangrijk is.
Een mogelijke architectuur bevat onder andere:
- primaire webserver;
- secundaire webserver;
- health monitoring;
- DNS-failover;
- bestandssynchronisatie;
- databasesynchronisatie;
- SSL op beide omgevingen;
- back-ups.
Ook caching moet goed worden ingericht.
Wanneer de failover-server oude cachebestanden bevat of afhankelijk is van services op de primaire server, kan de tweede omgeving alsnog problemen geven.
Failover voor WooCommerce
Voor WooCommerce wordt failover ingewikkelder.
Een webshop bevat immers gegevens die continu veranderen.
Stel dat op het moment van de storing drie klanten een bestelling plaatsen.
Dan moet worden voorkomen dat:
- bestellingen verloren gaan;
- voorraad terugloopt naar een oude stand;
- klantaccounts ontbreken;
- ordernummers conflicteren;
- betalingen niet meer aan bestellingen gekoppeld zijn.
Daarom moet bij een WooCommerce-failover vooral naar de databasearchitectuur worden gekeken.
Een reservekopie van gisteren is geen echte failoveromgeving voor een actieve webshop.
SSL op de secundaire server
Ook de reserveomgeving moet HTTPS correct kunnen verwerken.
Wanneer bezoekers na failover op de tweede server terechtkomen maar daar geen geldig SSL-certificaat aanwezig is, krijgen ze een beveiligingswaarschuwing.
Controleer daarom onder andere:
- SSL-certificaat;
- domeinnaam;
- certificaatvernieuwing;
- HTTPS-redirects;
- www/non-www;
- eventuele subdomeinen.
Beide omgevingen moeten klaar zijn om daadwerkelijk productie-verkeer te ontvangen.
Wat gebeurt er met e-mail bij server failover?
Websitefailover betekent niet automatisch dat ook e-mail wordt overgenomen.
Dat hangt af van de infrastructuur.
Wanneer e-mail bij een aparte mailprovider draait, kan de maildienst volledig losstaan van de webserver.
Wanneer website en e-mail echter op dezelfde server draaien, moet apart worden bepaald wat er gebeurt bij een storing.
Denk bijvoorbeeld aan:
- MX-records;
- mailboxdata;
- SMTP;
- inkomende berichten;
- uitgaande berichten;
- SPF;
- DKIM;
- DMARC.
DNS-failover van de website mag dus niet blind alle andere DNS-records wijzigen.
Server monitoring is essentieel
Zonder betrouwbare monitoring weet het failoversysteem niet wanneer het moet overschakelen.
Een goede monitoringomgeving controleert daarom continu de gezondheid van de dienstverlening.
Microsoft beschrijft bij failoverclustering eveneens dat health monitoring onder andere resources, services, opslag en netwerkconnectiviteit bewaakt om beschikbaarheidsproblemen te signaleren.
Belangrijk is ook dat monitoring niet te gevoelig wordt ingesteld.
Eén gemiste aanvraag betekent niet noodzakelijk dat de hele server defect is.
Anders kan een kort netwerkprobleem onnodig een complete failover veroorzaken.
False positives voorkomen
Een false positive ontstaat wanneer monitoring denkt dat de primaire server uitgevallen is terwijl deze eigenlijk nog functioneert.
Dat kan bijvoorbeeld gebeuren bij:
- tijdelijke netwerkvertraging;
- een korte CPU-piek;
- onderhoud;
- DNS-problemen;
- te agressieve health checks.
Daarom gebruiken failoversystemen vaak meerdere controles voordat een endpoint definitief als ongezond wordt gezien.
De juiste balans is belangrijk:
te langzaam reageren betekent meer downtime;
te snel reageren kan onnodige failovers veroorzaken.
Wat is failback?
Na een storing kan de primaire server worden hersteld.
Het terugzetten van verkeer naar de oorspronkelijke server wordt vaak failback genoemd.
Dit moet net zo zorgvuldig worden behandeld als de oorspronkelijke failover.
Stel dat bezoekers gedurende twee uur de secundaire server hebben gebruikt.
In die periode kunnen daar nieuwe gegevens zijn ontstaan.
Je kunt dan niet zonder meer verkeer terugsturen naar een primaire database die twee uur achterloopt.
Daarom moet vóór failback worden gecontroleerd:
- zijn gegevens gesynchroniseerd?
- is de primaire server stabiel?
- werkt SSL?
- functioneren applicatie en database?
- zijn nieuwe uploads aanwezig?
- zijn caches correct?
- zijn achtergrondtaken actief?
Pas daarna kan verkeer veilig worden teruggezet.
Failover versus load balancing
Failover en load balancing worden soms door elkaar gehaald.
Ze hebben echter een ander hoofddoel.
Failover
Failover richt zich voornamelijk op beschikbaarheid bij een storing.
A actief → A valt uit → B neemt over
Load balancing
Load balancing verdeelt verkeer over meerdere actieve servers.
bezoekers → server A + server B + server C
Beide technieken kunnen ook gecombineerd worden.
Je kunt bijvoorbeeld meerdere actieve servers in het primaire datacenter hebben en daarnaast een secundaire omgeving voor calamiteiten.
Failover is geen vervanging voor onderhoud
Een failoveromgeving maakt slecht serverbeheer niet ineens veilig.
Wanneer dezelfde configuratiefout automatisch naar beide servers wordt gesynchroniseerd, kunnen beide omgevingen problemen krijgen.
Hetzelfde geldt voor:
- malware;
- foutieve updates;
- corrupte databases;
- applicatiefouten.
Daarom blijven noodzakelijk:
- serverupdates;
- WordPress onderhoud;
- beveiliging;
- monitoring;
- back-ups;
- hersteltests.
Redundantie is één onderdeel van een bredere beschikbaarheidsstrategie.
Wanneer is server failover interessant?
Niet iedere website heeft een uitgebreide failoverarchitectuur nodig.
Voor een kleine informatieve website kan normale hosting met goede back-ups voldoende zijn.
Failover wordt interessanter wanneer downtime direct gevolgen kan hebben voor:
- omzet;
- bestellingen;
- aanvragen;
- medewerkers;
- klanten;
- bedrijfsprocessen.
Voorbeelden zijn:
- webshops;
- klantportalen;
- grote zakelijke websites;
- platforms;
- reserveringssystemen;
- websites met veel dagelijks verkeer;
- bedrijfskritische webapplicaties.
De kosten en complexiteit moeten daarbij altijd worden afgewogen tegen de gevolgen van downtime.
Server failover checklist
Wie een failover server wil inzetten, moet minimaal over de volgende onderwerpen nadenken:
- Welke server is primair?
- Welke server is secundair?
- Wat bepaalt dat de primaire server ongezond is?
- Hoe vaak worden health checks uitgevoerd?
- Hoe wordt DNS aangepast?
- Welke TTL wordt gebruikt?
- Hoe worden websitebestanden gesynchroniseerd?
- Hoe wordt de database gerepliceerd?
- Zijn SSL-certificaten op beide servers actief?
- Wat gebeurt er met e-mail?
- Waar draaien cronjobs?
- Hoe worden dubbele processen voorkomen?
- Hoe wordt de secundaire server gemonitord?
- Hoe werkt failback?
- Zijn daarnaast onafhankelijke back-ups aanwezig?
Pas wanneer deze vragen zijn beantwoord ontstaat een failoveroplossing die verder gaat dan alleen een reserve-server.
Server redundantie en failover via Sanum
Voor zakelijke websites kan Sanum helpen bij het ontwerpen en beheren van een hostingomgeving waarbij beschikbaarheid en redundantie worden meegenomen.
Afhankelijk van de toepassing kan daarbij worden gekeken naar:
- primaire en secundaire servers;
- VPS-omgevingen;
- DNS failover;
- health monitoring;
- website-synchronisatie;
- databases;
- SSL;
- back-ups;
- WordPress;
- WooCommerce;
- serverbeheer.
De juiste oplossing hangt af van het risico dat je wilt afdekken.
Een eenvoudige bedrijfswebsite heeft niet dezelfde infrastructuur nodig als een webshop of platform waarbij iedere minuut downtime direct gevolgen kan hebben.
Wil je onderzoeken of server failover zinvol is voor jouw website of platform? Neem contact op met Sanum voor advies over hosting, VPS, serverredundantie en failover.
Veelgestelde vragen over server failover
Wat betekent server failover?
Server failover betekent dat een andere server of infrastructuur diensten kan overnemen wanneer de primaire server uitvalt.
Hoe werkt DNS failover?
Een DNS-failoveroplossing controleert via health checks of een server gezond is. Wanneer de primaire omgeving niet meer beschikbaar is, kan DNS bezoekers naar een gezond alternatief endpoint sturen.
Is failover hetzelfde als een back-up?
Nee. Een back-up is bedoeld om gegevens te herstellen. Failover is vooral gericht op het beschikbaar houden van een dienst wanneer een server uitvalt.
Hoe snel werkt DNS failover?
Dat hangt onder andere af van health checks, TTL en DNS-caching. DNS-failover is daarom niet noodzakelijk overal exact op hetzelfde moment zichtbaar.
Kan WordPress met twee servers werken?
Ja, maar bestanden, database, uploads, SSL en caching moeten zo zijn ingericht dat de tweede omgeving daadwerkelijk kan overnemen.
Is server failover geschikt voor WooCommerce?
Ja, maar een webshop vraagt extra aandacht voor database- en voorraadsynchronisatie omdat bestellingen en klantgegevens continu veranderen.
Wat is active-passive failover?
Bij active-passive verwerkt één server normaal het verkeer en staat een tweede server klaar om over te nemen bij een storing.
Wat is active-active failover?
Bij active-active zijn meerdere resources normaal actief. Wanneer één resource ongezond wordt, kan verkeer naar de overige gezonde resources blijven gaan.
