Wanneer de populariteit van je website, webshop of webapplicatie groeit krijg je te maken met nieuwe technische uitdagingen. Je gehoste applicatie moet om kunnen gaan met meer verkeer (load), het verminderen van downtime en het elimineren van ‘single points of failures’. Met High Availability (HA), een manier om je infrastructuur in te richten, kun je dit bereiken.
Wat is beschikbaarheid?
Voordat we de term High Availabillity uit kunnen leggen moeten we eerst stilstaan bij de term availability (beschikbaarheid). In de computerwereld wordt availability vaak in één adem genoemd met de tijd die sytemen bereikbaar en beschikbaar moeten zijn. Vaak wordt dit principe aangeduid met een percentage, zoals de hoeveelheid % uptime dat een systeem heeft. 100% uptime betekent bijvoorbeeld dat het systeem nooit offline is.
In de praktijk komt een uptime van 100% eigenlijk nooit voor. Elk systeem, of het nou een server is of een applicatie, heeft te maken met downtime (onbeschikbaarheid). Dat kan zijn omdat er onderhoud gepleegd wordt (updates, patches) of omdat er een calamiteit plaatsvindt (stroomuitval, security-incident).
Voor sommige systemen is het echter nodig om garanties te hebben over de uptime. En als we het over garanties hebben, dan hebben we het ook over ‘High Availability (HA)’.
Wat is High Availability (HA)?
High Availability (HA) kun je het best zien als een garantie die een hosting- of cloudprovider je geeft over de uptime van je website, webshop of webapplicatie.
Je kunt namelijk bij een hosting- of cloudserviceprovider een Service Level Agreement (SLA) afsluiten. In zo’n overeenkomst staat onder andere (vaak per server) hoeveel % uptime je als klant mag verwachten. De % uptime kun je doorvertalen naar dagen, aantal uren of zelfs milliseconden downtime per jaar.
Een bekende manier om de beschikbaarheid aan te duiden is met de ‘nines’. Het % beschikbaarheid in tijd kan dan omgerekend worden naar het aantal negens achter de komma.
Zie bijvoorbeeld dit schema:
Hoe meer negens er achter de komma van de 99, hoe beter zou je denken. Er valt hier veel over te zeggen. Elke hostingprovider hanteert namelijk zijn eigen interpretaties.
Je kunt echter van één ding uitgaan: als het over HA gaat dan kun je daar met je hostingprovider afspraken over vastleggen in een SLA.
Wanneer is High Availability belangrijk?
High Availability is met name belangrijk als je websites, webshops of webapplicaties hebt waar uitval tot serieuze omzetverlies of reputatieschade kan leiden. Als de website vaak een hoge prioriteit heeft voor een organisatie, is het belangrijk om ook na te denken over hoge beschikbaarheid. Pas je dit niet toe, dan kunnen je applicaties – hoe robuust ze ook zijn opgezet – alsnog te maken krijgen met uitval.
Het toepassen van een High Availability strategie zorgt ervoor dat je de impact van uitval kunt reduceren. Reduceren, omdat voorkomen niet altijd mogelijk is. Zoals gezegd is 100% uptime niet realistisch en is het altijd mogelijk dat er onverwachts een situatie voordoet.
Vaak kunnen HA systemen ook automatisch herstellen bij uitval, zonder dat er een mens bij komt kijken. Handig, omdat webomgevingen steeds complexer worden. Het kan veel tijd schelen als er de systemen bij uitval zelf een oplossing kunnen genereren, want de oorzaak van is door een mens niet altijd gelijk te vinden. Door dit te automatiseren kan het probleem sneller opgelost worden.
Is voor je bedrijf enkele minuten of uren downtime een behoorlijke calamiteit? Dan is het verstandig om na te denken over een HA strategie.
Wat maakt systemen High Available?
Een van de doelen van HA is om ‘single points of failures’ te elimeren in alle lagen van de infrastructuur en hostingomgeving.
‘Single points of failures’ zijn componenten in je infrastructuur of hostingomgeving die voor een interruptie kunnen zorgen als er een fout plaatsvindt. Denk aan een enkele load balancer (komen we zo op terug), de opslag van data of een verkeerde configuratie in een webserver. In de basis geldt dat er bij single points of failures geen sprake is van redudantie. Redundantie is een ander woord voor ‘meervoudig’. In het geval van systemen betekent het dat je altijd een soort reservecomponent hebt op op terug te vallen als het eerste component uitvalt.
Single points of failures tackelen
Om alle ‘single points of failures’ te tackelen is het belangrijk om naar alle lagen van de infrastructuur en hostingomgeving te bekijken. Je kunt bijvoorbeeld beginnen met de fysieke laag (het datacenter) en vanaf daar elke keer een niveau omlaag gaan.
Wat gebeurt er bijvoorbeeld als een datacenter geen stroom meer krijgt? Wat gebeurt er als er een enkele server uitvalt? Wat gebeurt er als we daar een load balancer voor zetten? Voor elk component in de infrastructuur of hostingomgeving vallen vragen te stellen over ‘single points of failures’.
Waar bestaat een High Available setup uit?
Er zijn vele single points of failures en ook vele verschillende manieren om ze op te lossen. We behandelen een paar begrippen.
Server clustering
Server clustering is het samenbrengen van verschillende servers zodat ze als één geheel werken. Met server clustering verdeel je de workloads en minimaliseer je onderbrekingen van een van je diensten, omdat de rest van het cluster de taken overneemt als er bijvoorbeeld een onderdeel uitvalt.
Server clustering wordt met name ingezet als een bedrijf garanties wil hebben over de beschikbaarheid. Het is dus voor de meeste HA-set-ups een noodzakelijkheid. Aan een cluster zijn doorgaans nieuwe (virtuele) webservers toe te voegen, zodat het ook berekent is op meer capaciteit. Verwacht je bijvoorbeeld piekverkeer door bijvoorbeeld een promotie, dan valt zo’n cluster uit te brengen.
Er zijn verschillende manieren om servers met elkaar te clusteren. In de basis is het vaak een verdubbeling van het aantal machines (servers) rondom dezelfde taken. Door servers te clusteren vermijd je een ‘single point of failure’, omdat er altijd iets is om op terug te vallen.
Load balancer
Een load balancer kun je zien als een soort verkeersregelaar. Op het moment dat jij naar een website surft (bijv. true.nl), dan bepaalt de load balancer welke server je uiteindelijk de content van die website serveert. De load balancer maakt deze beslissing op basis van het verkeer dat als naar true.nl komt. Om te voorkomen dat het te druk wordt, verdeelt hij het verkeer dus over meerdere servers.
Zonder een load balancer kan je website te maken krijgen met te veel verkeer (load). Als veel gebruikers namelijk tegelijk een verzoek doen aan de server, raakt de server overbelast en duurt het langer om een pagina te tonen, of kan hij de verbinding helemaal niet vinden.
Met een load balancer en ten minste één aanvullende webserver is dit op te lossen. Op deze extra webserver staat exact dezelfde content als op de andere webserver. Het voordeel is hiervan is dat de load balancer altijd op willekeurige manier het verkeer kan verdelen naar webserver A of webserver B. Een load balancer is vrijwel altijd onderdeel van een server cluster.
Zonder load balancing:
Met load balancing:
Hoe kiest een load balancer de server?
Dit is sterk afhankelijk van de software die gebruikt wordt als load balancer. Meestal doet de load balancing software eerst ‘health checks’ bij de webservers, een proces dat continu doorgaat. Als een server als ‘unhealthy’ wordt aangevinkt, zal de load balancer het verkeer naar een andere server sturen.
Verder zijn er in de software diverse configuraties in te stellen waarmee het algoritme een besluit kan vormen. Dit kan bijvoorbeeld op basis van IP-adres of op basis van geschatte sessieduur.
De load balancer als single point of failure
We hebben het eerder gehad over *single points of failures’. Een enkele load balancer is ook een single point of failure. Als de load balancer overspoelt raakt met verzoeken / bezoekersverkeer, kan het alsnog zo zijn dat de website te maken krijgt trage laadtijden of met downtime. Dit is geen ongewoon scenario.
Geografische locatie
Een andere belangrijk factor bij High Availability set-ups is ook de locatie van de hostingprovider en het datacenter. Als dit slechts op één locatie is, dan is dat te zien als een risico. Eén locatie kan namelijk altijd getroffen worden door een calamiteit: een brand, een aardbeving (gelukkig in Nederland weinig last van), stroomuitval of een overstroming.
Bij veel cloudproviders kun je daarom redundantie inbouwen in andere geografische locaties. Zo kun je een applicatie primair hosten in datacenters van een cloudserviceprovider in Europa, maar ook in de datacenters in een locatie in Amerika.
De geografische locatie kan ook kleiner zijn. Bijvoorbeeld twee verschillende datacenterlocaties in Amsterdam. Bij True maken we gebruik van vier verschillende datacenterlocaties. Klanten kunnen met een multi-datacenterset-up daardoor redundant zijn over meerdere omgevingen.
Monitoring
Een ander belangrijk aspect bij HA is monitoring. Omdat er op elke laag van de infrastructuur een probleem zich kan voordoen, is het ook belangrijk om elke laag te monitoren. Een hostingprovider doet dit voor je. Deze signaleert de fouten of afwijkingen en springt hier tijdig op in.
Monitoring wordt extra belangrijk naarmate applicaties ontwikkeld worden op een nieuwere manieren, bijvoorbeeld met microservices. Dat kun je zien als kleine applicaties die samen (in de front-end) één grote applicatie vormen. Elke microservice kan te maken krijgen met connectiviteitsproblemen. Daarom is het verstandig om daarop te monitoren.
Garanties
High Availability is met name van belang bij garanties voor de uptime van je website, webshop of webapplicatie. Die garanties leg je vast bij je hostingprovider in een SLA. Vaak gebeurt dit op serverniveau.
De hostingprovider helpt je vervolgens met het elimineren van single points of failures. Door servers te clusteren, load balancers te instellen en door je content eventueel ook geografisch te verspreiden met een multi-datacenter dienst. En uiteraard wordt dat goed in de gaten gehouden met monitoringtools, zodat afwijkingen snel gezien worden.
Over de auteur: Kilian Drewel werkt als content marketeer bij True.
