Wat als je webapplicatie uit de lucht is?

...haal het Disaster Recovery Plan maar uit de kast

Joost

Geschreven door Joost Saanen op 4-1-2018
5 minuten leestijd

Grote problemen bij de hoster. Je webapplicatie werkt niet meer. Het nieuwe jaar is begonnen en laat dit nou net zo’n drukke periode zijn. De DevOps engineers zijn volop bezig om het probleem te verhelpen, maar tot nu toe is er weinig succes. De tijd tikt door en de mensen worden ongeduldig. Tijd om het Disaster Recovery Plan uit de kast te halen. Maar eh, die is er toch wel hoop ik?

disaster-recover-comic

In een Disaster Recovery Plan (soms ook wel business continuïteits plan genoemd) wordt beschreven wat er moet gebeuren wanneer er zich een ramp voordoet met betrekking tot het ICT-landschap. In zo’n plan worden de voorzorgsmaatregelen beschreven én wat er moet gebeuren wanneer zich een ramp voordoet. Hoe dit precies wordt ingevuld heeft vooral te maken met hoe bedrijfskristisch de applicatie is.

Waarom een Disaster Recovery Plan?

Kabisa is ontwikkelaar van mobiele apps en webapplicaties. Voor beiden heb je een Disaster Recovery plan nodig. Ja, ook voor mobiele apps. Er zijn namelijk nog maar weinig mobiele apps die niet gekoppeld zijn aan een webserver. Wanneer deze niet meer werkt kun je raden dat de mobiele app ook niet meer functioneert.

fire-datacenter

En zoals bovenstaande foto al laat zien, een ramp in de vorm van een brand kan helaas werkelijkheid zijn. Hoe klein de kans misschien ook lijkt. Zorg dus dat je bent voorbereid.

Recoveren of restoren naar de Cloud

Bij Kabisa hosten we onze (web)applicaties bij voorkeur in de cloud. Een tijd geleden schreven we al eens een blogpost over deze trend van hosting (inmiddels wordt er al zoveel gehost in de cloud dat we niet meer kunnen spreken van een trend).

Een belangrijke reden om te hosten in de cloud is naast dat je snel kunnen op- en afschalen, je ook makkelijk kunt schakelen bij calamiteiten of disasters (voor het gemak zal ik vanaf nu ‘ramp’ noemen).

Stel je voor, dit draait op eigen hardware. Wil je in dat geval snel kunnen anticiperen bij een ramp, dan moet je eigenlijk het complete serverpark dubbel hebben uitgevoerd. En het liefst op een fysiek andere locatie. Deze extra servers staan de meeste tijd niets te doen, maar moeten wel worden betaald en beheerd. Host je in de cloud dan is het “Pay as you Go”. Je betaalt dan alleen voor wat je werkelijk gebruikt. Dus geen onnodige uitgaven aan hardware die de helft van de tijd niets te doen heeft.

Dat wij bij Kabisa fan zijn van de cloud mag duidelijk zijn, maar dit wil niet zeggen dat je applicatie niet gewoon on premise (op eigen locatie of hardware) kunt draaien. Juist dan wil je bij een ramp uitwijken naar de cloud.

Kosten/Baten

Let wel, zo’n recovery plan kan een dure aangelegenheid zijn. Er zijn verschillende varianten mogelijk. Duur is natuurlijk relatief, want de belangrijkste vraag voor het bepalen van de meest geschikte variant is:

“Wat zijn de kosten voor ons bedrijf, wanneer de applicatie uit de lucht is?” of “Wat kost het ons als bedrijf, wanneer de primaire bedrijfsprocessen niet gecontinueerd kunnen worden?”

Het beantwoorden van deze vraag kan je een richting geven over wat de best passende recovery-methode is.

Recovery tijd en dataverlies

Het vaststellen van de volgende objectives kunnen hierbij ook helpen:

Recovery Time Objective (RTO)

Na hoeveel tijd moet de applicatie of infrastructuur weer in de lucht zijn? Bijvoorbeeld: de ramp doet zich voor om 11:00 uur in de ochtend. Wanneer de RTO is vastgesteld op 8 uur, dan is het acceptabel dat de omgeving vóór 19:00 uur weer draait.

Recovery Point Objective (RPO)

Hoeveel verlies van data mag er zijn? Bijvoorbeeld: een ramp doet zich voor om 17:00 uur, is het dan acceptabel als de data wordt hersteld tot het tijdstip van 16:00 uur?

Verschillende recovery methoden

dr-levels

In bovenstaande afbeelding zijn de verschillende recovery methoden weergegeven. Hierbij is de meest linkse Backup & Restore de goedkoopste en de methode waarbij de hersteltijd en dataverlies het grootste is. Hoe meer je naar rechts gaat, hoe sneller dat je weer in de lucht bent – maar ook hoe duurder de oplossing. Overigens zijn de genoemde uren gebaseerd op gemiddelden en deze kunnen daarom per oplossing verschillen. Ook is het mogelijk om in sommige gevallen variaties te maken van de verschillende methoden.

In de volgende afbeeldingen wordt steeds “Primaire datacenter A” genoemd. Dit kan een willekeurig datacenter zijn: een cloud-provider of een eigen datacenter. “Backup Datacenter B” is in dit geval een cloud-hosting provider (bijvoorbeeld Amazon AWS)

Backup and restore

backup-and-restore

Backups van databases en data kunnen in geval van een recovery worden teruggezet. Dit is de goedkoopste oplossing, maar ook die met de langste RTO en RPO. Dit is de minimale methode benodigd om een recovery mogelijk te maken. Een “Backup Datacenter B” kan hierbij nodig zijn (afhankelijk van de ernst van de ramp).

Pilot Light

pilot-light

De naam pilot light komt van het waakvlammetje van een gasinstallatie. Zo’n vlammetje kan zich snel manifesteren tot een grotere vlam. Bij een technische infrastructuur is dit net zo. In dit scenario wordt er een minimale kopie gemaakt van de infrastructuur en in het backup datacenter geplaatst. De omgeving is minimaal uitgerust en staat standaard uit om kosten te besparen.

Wanneer er een recovery nodig is, kan er worden uitgeweken naar de nieuwe locatie. De applicatie kan dan relatief snel worden opgestart. Vervolgens draait deze nog niet op volle kracht maar is wel weer beschikbaar. Om weer volledig operationeel te zijn moet er verder worden opgeschaald.

Warm standby

warm-standby

Bij een warm standby staat er een minimale kopie in het backup datacenter. Het verschil met pilot light is dat deze omgeving volledig functioneert én actief is (aan staat). Er wordt alleen nog geen gebruik van gemaakt – er wordt nog geen productie verkeer naar toe gestuurd. Dit gebeurt pas bij een ramp. De omgeving is zo ingeregeld dat deze snel en automatisch kan worden opgeschaald zodat binnen een zeer korte tijd alles weer volledig operationeel is.

Multi-site

multi-site

Bij multi-site is er een volledig operationele infrastructuur in twee verschillende datacenters. Deze wordt ook al actief gebruikt. Eventueel kan er worden geconfigureerd hoeveel procent van de bezoekers bij de servers van de verschillende datacenters terecht komen. Door ervoor te kiezen om een kleiner deel van het verkeer naar datacenter B te sturen kan deze omgeving lichter worden uitgerust. Indien nodig kan er bij ramp nog extra worden bijgeschaald.

Ben je geïnteresseerd geraakt?

Bij Kabisa zitten we samen met onze klanten aan tafel voor het opstellen van een Disaster Recovery Plan. We bekijken wat de meest geschikte en haalbare methode is. Ben je benieuwd of wij iets voor jouw bedrijf kunnen betekenen, of heb je andere vragen? Neem dan contact met ons op.

Joost

Joost Saanen

Gepassioneerde all-rounder met brede interesses; van serverbeheer en cloudhosting tot (UI)design en (web)development. Hardloopt en schrijft het liefst tegelijk.

Bij Kabisa staat privacy hoog in het vaandel. Wij vinden het belangrijk dat er zorgvuldig wordt omgegaan met de data die onze bezoekers achterlaten. Zo zult u op onze website geen tracking-cookies vinden van third-parties zoals Facebook, Hotjar of Hubspot. Er worden alleen cookies geplaatst van Google en Vimeo. Deze worden gebruikt voor analyses, om zo de gebruikerservaring van onze websitebezoekers te kunnen verbeteren. Tevens zorgen deze cookies ervoor dat er relevante advertenties worden getoond. Lees meer over het gebruik van cookies in ons privacy statement.