Valt er een server uit, dan draait je applicatie gewoon door

Alles staat op een server. De webshop, de database, de planning, het orderportaal waar je klanten op inloggen. Zolang die machine draait merkt niemand dat er maar een van is. Tot er een schijf stukgaat, een geheugenmodule uitvalt of een update de boel laat hangen, en het hele bedrijf ineens wacht op een monteur en een terugzetactie die uren duurt.

Wat high availability wel en niet oplost

High availability betekent dat er van elk onderdeel dat kan stukgaan een tweede is, en dat het overnemen automatisch gebeurt. Valt een server weg, dan pakt de andere het verkeer op. Valt een schijf weg, dan draait de opslag door op de rest. Valt een netwerkpoort weg, dan gaat het over de tweede. Wat je overhoudt is geen onsterfelijk systeem, maar een systeem waarin een enkel defect geen bedrijfsstoring meer is.

Even belangrijk is wat het niet doet. Een fout in je eigen code wordt keurig naar beide servers gerepliceerd. Een verkeerd commando dat een tabel leegt, gaat binnen een seconde mee naar de kopie. Een leverancier die zijn koppeling omgooit, ligt er op allebei uit. Redundantie beschermt tegen kapotte spullen, niet tegen menselijke vergissingen, en daarvoor blijf je een geteste back-up nodig hebben. Wij zeggen dat aan het begin, niet nadat de rekening is getekend.

Twee servers, gerepliceerde data en een schakelaar

De opzet bestaat bijna altijd uit drie stukken. Twee of meer servers die dezelfde applicatie draaien, meestal twee virtuele machines of twee Dedicated servers in gescheiden racks. Daarachter je data, die synchroon wordt gerepliceerd zodat de tweede machine dezelfde regels heeft als de eerste; draait daar een zware database onder, dan zetten we die apart neer als Managed databases. En ervoor iets dat de bezoeker naar de gezonde server stuurt, met een gezondheidscontrole die elke paar seconden kijkt of de andere kant nog antwoordt.

Hoe ver je dat doortrekt hangt af van wat je wil opvangen. Twee servers naast elkaar in hetzelfde datacenter vangen kapotte hardware op. Twee locaties vangen ook een stroomstoring of een netwerkprobleem in dat ene gebouw op, maar de afstand kost je milliseconden bij elke schrijfactie en dat merk je in je applicatie. Draait je software al in containers, dan is de stap naar Kubernetes & containers vaak logischer dan twee losse machines. We kiezen de opzet op wat jouw applicatie nodig heeft, en de plek in onze beheerde omgevingen die daarbij past.

De failover testen voordat je hem nodig hebt

Een failover die nooit is uitgeprobeerd, is een aanname. We zien in de praktijk vaker een omschakeling die halverwege blijft steken dan een die netjes werkt: een certificaat dat alleen op de eerste server staat, een achtergrondtaak die op beide machines tegelijk begint te draaien, een verbinding met de boekhouding die het adres van de oude server hardcoded had staan. Dat soort dingen vind je door de stekker eruit te trekken, niet door het ontwerp nog eens te lezen.

Daarom zetten we voor de oplevering een server bewust uit terwijl jij meekijkt, en klok je zelf hoe lang het duurt voordat de applicatie weer reageert. Daarna oefenen we het terugschakelen, want dat is het moment waarop data uit elkaar kan lopen. Het draaiboek dat daaruit komt krijg je op papier. De monitoring bewaakt vervolgens niet alleen of de site het doet, maar ook of je nog echt twee werkende helften hebt, want een cluster dat maanden op een been staat is gewoon een dure enkele server.

Wanneer het de moeite niet waard is

Een dubbele opzet is complexer dan een enkele. Meer machines om te onderhouden, replicatie die kan achterlopen, updates die in de juiste volgorde moeten. Die complexiteit is het waard als stilstand je direct geld of vertrouwen kost: een webshop die dag en nacht verkoopt, een portaal waar klanten hun eigen dossier in doen, een systeem dat aan een productie of een planning vastzit. Voor een intern kantoorpakket dat een ochtend kan wachten, is een goed beheerde machine met Managed hosting en een back-up die echt is teruggezet een verstandiger keuze.

In de gratis intake rekenen we het daarom eerst nuchter door: wat ligt er stil, hoe lang, en wat gebeurt er in die tijd. Komt daar uit dat je genoeg hebt aan snellere hardware, een tweede internetverbinding of een strak geregelde Backup & disaster recovery, dan bouwen we geen cluster. Blijkt het wel nodig, dan bouwen we het en zorgen we dat je het zelf begrijpt. De servers staan op naam van je eigen organisatie, de inrichting is gedocumenteerd en je bent de eigenaar, ook als je het beheer later ergens anders onderbrengt.