Fouttolerante cloudservices bouwen

Een groot deel van het beheer van datacenters-en cloudservices bestaat uit het ontwerpen en onderhouden van een betrouwbare service op basis van onbetrouwbare onderdelen. In de volgende afbeelding ziet u een deel van een training voor nieuwe medewerkers, en dit zou een beeld moeten geven van het grote aantal (en de typen) fouten die regelmatig optreden in een groot datacenter.

Afbeelding 2: Betrouwbaarheidsproblemen zoals weergegeven in een trainingspresentatie

Een storing in een systeem treedt op doordat als gevolg van een fout een ongeldige status in het systeem wordt geïntroduceerd. In systemen treden doorgaans fouten van een van de volgende typen op:

• Tijdelijke fouten: tijdelijke fouten in het systeem die zichzelf met tijd corrigeren.
• Permanente fouten: fouten die niet kunnen worden hersteld en die over het algemeen vervanging van resources vereisen.
• Onregelmatige fouten: fouten die periodiek optreden in een systeem.

Fouten kunnen van invloed zijn op de beschikbaarheid van het systeem door uitval of prestatieverlaging van de systeemfuncties te veroorzaken. Een fouttolerant systeem is in staat om de functie zelfs uit te voeren als er fouten zijn opgetreden in het systeem. In de cloud wordt een fouttolerant systeem vaak gezien als een systeem dat op een consistente manier services aanbiedt, met een lagere downtime dan volgens de SLA's (Service Level Agreement) is toegestaan.

Waarom is fouttolerantie belangrijk?

Storingen in grote bedrijfskritische systemen kunnen leiden tot aanzienlijke monetaire verliezen voor alle betrokken partijen. Kenmerkend voor systemen voor cloud-computing is dat ze een gelaagde architectuur hebben. Een fout in de ene laag van de cloudresources kan een fout veroorzaken in andere, hogere lagen of de toegang tot lagere lagen verbergen.

Een fout in een hardwareonderdeel van het systeem kan bijvoorbeeld gevolgen hebben voor de normale uitvoering van een SaaS-toepassing (Software as a Service) die wordt uitgevoerd op een virtuele machine die gebruikmaakt van de defecte resources. Fouten in een systeem hebben op elke laag dan ook een rechtstreekse relatie met de SLA's tussen de providers op elk niveau.

Proactieve maatregelen

Serviceproviders nemen verschillende maatregelen om het systeem op zo'n manier te ontwerpen dat bekende problemen, of voorspelbare fouten, worden voorkomen.

Profilering en testen

Het uitvoeren van belastings- en stresstesten op cloudresources om mogelijke oorzaken van fouten te begrijpen, is essentieel om de beschikbaarheid van services te garanderen. Profilering van deze metrische gegevens helpt bij het ontwerpen van een systeem dat de verwachte belasting zonder onvoorspelbaar gedrag kan weerstaan.

Over-inrichting

Over-inrichting is de praktijk van het implementeren van resources in volumes die groter zijn dan nodig is voor het algemeen verwachte gebruik van de resources op enig moment. In situaties waarin de exacte behoeften van het systeem niet noodzakelijkerwijs kunnen worden voorspeld, kan het over-inrichten van resources een acceptabele strategie zijn om onverwachte pieken in de belasting op te vangen.

Laten we als voorbeeld een e-commerceplatform nemen dat het hele jaar een gemiddelde consistente belasting op de servers te zien geeft, behalve tijdens de vakantieperioden wanneer er vaak sprake is van piekmomenten. Op deze piekmomenten is het raadzaam om extra resources in te richten op basis van de historische gegevens van piekgebruik. Een snelle toename in het verkeer is doorgaans moeilijk in korte tijd op te vangen. Zoals wordt beschreven in latere secties, is er sprake van een tijdsfactor bij dynamisch schalen, bestaande uit de tijdrovende stappen van het detecteren van een wijziging in het belastingspatroon en het inrichten van extra resources om de nieuwe belasting aan te kunnen. Voor beide stappen is tijd nodig. Deze vertraging bij het doorvoeren van een aanpassing kan voldoende zijn om het systeem te overbelasten, en in het slechtste geval te laten crashen. In het beste geval neemt in deze situatie alleen de kwaliteit van de service af.

Over-inrichting is ook een tactiek die wordt gebruikt om bescherming te bieden tegen DoS-aanvallen (Denial of service) of DDoS-aanvallen (gedistribueerde DoS). Hierbij genereren aanvallers aanvragen die zijn ontworpen om een systeem te overbelasten door grote hoeveelheden verkeer te produceren, als een poging om het systeem te laten vastlopen. Bij elke aanval duurt het altijd even voordat het probleem is opgemerkt en er corrigerende maatregelen in gang zijn gezet. Terwijl er een analyse van de aanvraagpatronen wordt uitgevoerd, is het systeem al kwetsbaar en moet het toegenomen verkeer kunnen worden opgevangen tot er een strategie kan worden geïmplementeerd om de aanval te bestrijden.

Replicatie

Kritieke systeemonderdelen kunnen worden gedupliceerd door extra hardware- en softwarecomponenten te gebruiken om fouten in delen van het systeem op de achtergrond af te handelen zonder dat het hele systeem in storing valt. Replicatie valt uiteen in twee basisstrategieën:

• Actieve replicatie, waarbij alle gerepliceerde resources gelijktijdig actief zijn en op alle aanvragen reageren en deze verwerken. Dit betekent dat voor elke clientaanvraag alle resources dezelfde aanvraag ontvangen, dat alle resources reageren op dezelfde aanvraag en dat de volgorde van de aanvragen de status tussen alle resources in stand houdt.
• Passieve replicatie, waarbij aanvragen alleen worden verwerkt door de primaire eenheid, en secundaire eenheden alleen de status onderhouden en het werk overnemen als de primaire eenheid uitvalt. De client heeft alleen contact met de primaire resource, die de statuswijziging doorgeeft aan alle secundaire resources. Het nadeel van passieve replicatie is dat er sprake kan zijn van wegvallende aanvragen of afgenomen QoS tijdens het overschakelen van de primaire naar de secundaire instantie.

Er is ook nog een hybride strategie, die semi-actiefwordt genoemd en die erg veel lijkt op de actieve strategie. Het verschil is dat alleen de uitvoer van de primaire resource wordt weergegeven aan de client. De uitvoer van de secundaire resources wordt onderdrukt en vastgelegd, en kan worden gebruikt zodra er een storing optreedt in de primaire resource. In de volgende afbeelding ziet u de verschillen tussen de replicatiestrategieën.

Afbeelding 3: Replicatiestrategieën

Een belangrijke factor om rekening mee te houden bij replicatie is het aantal secundaire resources dat moet worden gebruikt. Hoewel dit verschilt tussen toepassingen op basis van het belang van het systeem, zijn er drie formele niveaus van replicatie:

• N+1: Dit betekent in feite dat voor een toepassing die N-knooppunten nodig heeft, één extra resource wordt ingericht als een fail-safe.
• 2N: Op dit niveau wordt één extra knooppunt ingericht voor elk knooppunt dat is vereist voor de normale functie als een fail-safe.
• 2N+1: Op dit niveau wordt één extra knooppunt voor elk knooppunt dat vereist is voor de normale functie en één extra knooppunt in het algemeen ingericht als een fail-safe.

Reactieve maatregelen

Naast proactieve maatregelen kunnen systemen reactieve maatregelen nemen en storingen afhandelen als en wanneer deze zich voordoen:

Controles en monitoring

Alle resources worden voortdurend gecontroleerd om te kijken of er sprake is van onvoorspelbaar gedrag of verlies van resources. Op basis van de controlegegevens worden er herstel- of configuratiestrategieën ontworpen om resources opnieuw te starten of om nieuwe resources in te richten. Monitoring kan helpen bij het identificeren van storingen in de systemen. Storingen die ertoe leiden dat een service niet beschikbaar is, worden crashstoringen genoemd en storingen die een onregelmatig/onjuist gedrag veroorzaken in het systeem, worden Byzantine-storingen genoemd.

Er zijn verschillende monitoringtactieken die worden gebruikt om te controleren op crashstoringen in een systeem. Twee van deze tactieken zijn:

• Ping-echo: de bewakingsservice vraagt elke resource om de status en krijgt een tijdvenster om te reageren.
• Heartbeat: Elk exemplaar verzendt de status met regelmatige tussenpozen naar de bewakingsservice, zonder trigger.

Het monitoren van Byzantine-storingen is meestal afhankelijk van de eigenschappen van de service die wordt aangeboden. Monitoringsystemen kunnen basisgegevens controleren zoals latentie, CPU-gebruik en geheugengebruik, en de feitelijke waarden vergelijken met de verwachte waarden om vast te stellen of de kwaliteit van de service wordt beïnvloed. Daarnaast worden er meestal op elk belangrijk service-uitvoeringspunt toepassingsspecifieke supervisielogboeken onderhouden en worden deze regelmatig geanalyseerd om te controleren of de service altijd goed werkt (of dat er fouten in het systeem zijn geïntroduceerd).

Controlepunt en opnieuw starten

Verschillende programmeermodellen voor de cloud implementeren zogenaamde controlepuntstrategieën, waarbij de status op verschillende momenten van de uitvoering wordt opgeslagen om herstel naar een laatst opgeslagen controlepunt mogelijk te maken. In toepassingen voor gegevensanalyse worden vaak langdurig lopende, parallel gedistribueerde taken uitgevoerd op terabytes aan gegevenssets om gegevens te extraheren. Omdat deze taken worden uitgevoerd in verschillende kleine uitvoeringsblokken, kan tijdens elke stap in de uitvoering van het programma de algehele status van de uitvoering als een controlepunt worden opgeslagen. Op points of failure waar afzonderlijke knooppunten hun werk niet kunnen voltooien, kan de uitvoering opnieuw worden gestart vanaf een eerder controlepunt. De grootste uitdaging bij het identificeren van geldige controlepunten die moeten worden teruggedraaid, is wanneer parallelle processen gegevens delen. Een fout in een van de processen kan leiden tot een trapsgewijze terugdraaiactie in een ander proces, omdat de controlepunten die zijn gemaakt in dat proces het resultaat kunnen zijn van een fout in de gegevens die worden gedeeld door het proces met de fout. In latere modules besteden we meer aandacht aan fouttolerantie voor programmeermodellen.

Casestudy's voor tolerantietests

Cloudservices moeten worden gebouwd met redundantie en fouttolerantie in het achterhoofd, aangezien geen enkel onderdeel van een groot gedistribueerd systeem een beschikbaarheid of uptime van 100% kan garanderen.

Alle fouten (waaronder storingen van afhankelijkheden in hetzelfde knooppunt, rek, datacenter of regionaal redundante implementaties) moeten op de juiste wijze worden afgehandeld zonder dat van invloed te zijn op het systeem als geheel. Het testen van de mogelijkheid van het systeem om fatale fouten af te handelen, is belangrijk aangezien soms zelfs maar een paar seconden uitvaltijd of servicevermindering honderdduizenden zo niet miljoenen euro's verlies tot gevolg kan hebben.

Het is belangrijk om regelmatig te testen op fouten met echt verkeer, zodat het systeem wordt gehard en adequaat kan reageren wanneer er een niet-geplande onderbreking optreedt. Er zijn verschillende systemen beschikbaar om tolerantie te testen. Een voorbeeld van een dergelijke testsuite is Simian Army gebouwd door Netflix.

Simian Army bestaat uit services (aangeduid als monkeys) in de cloud voor het genereren van verschillende soorten fouten, het detecteren van abnormale omstandigheden en het testen van de mogelijkheden van het systeem om hier goed mee om te gaan. Het doel is om de cloud veilig en maximaal beschikbaar te houden. Dit zijn enkele van de monkeys in Simian Army:

• Chaos monkey: een hulpprogramma dat willekeurig een productie-exemplaar kiest en uitschakelt om ervoor te zorgen dat de cloud veelvoorkomende soorten fouten overleeft zonder dat er gevolgen voor de klant zijn. Netflix beschrijft Chaos Monkey als "Het idee om een wilde aap te ontketenen met een wapen in uw datacenter (of cloudregio) om willekeurig instanties neer te schieten en door kabels te kauwen - allemaal terwijl we onze klanten zonder onderbreking blijven bedienen. Dit soort tests met gedetailleerde bewaking kunnen verschillende vormen van zwakke plekken in het systeem blootstellen en automatische herstelstrategieën kunnen worden gebouwd op basis van de resultaten.
• Latentieap: een service die vertragingen veroorzaakt tussen RESTful-communicatie van verschillende clients en servers, waarbij servicedegradatie en downtime worden gesimt.
• Dokter aap: Een service die exemplaren vindt die beschadigd gedrag vertonen (bijvoorbeeld CPU-belasting) en verwijdert ze uit de service. Hiermee kunnen de service-eigenaren wat tijd winnen om de oorzaak van het probleem te achterhalen, waarna de instantie uiteindelijk wordt beëindigd.
• Chaos gorilla: een service die het verlies van een hele AWS-beschikbaarheidszone kan simuleren. Dit wordt gebruikt om te testen of de services de functionaliteit automatisch opnieuw verdelen over de resterende zones zonder dat dit zichtbare gevolgen voor de gebruiker heeft of handmatige tussenkomst vereist.