Centraal in het debat rond High Availability staat het zogenaamde “CAP theorema” dat (grofweg) stelt dat niet alle systemen op elk ogenblik de meest up-to-date informatie kunnen bezitten als hoge beschikbaarheid vereist is.

Hoewel dit op het eerste gezicht dramatisch lijkt, is dit in de praktijk niet het geval omdat “tijd” een verschillende betekenis heeft in business context dan in IT context. Bekijken we het voorbeeld van een patiënt die een elektronisch voorschrift krijgt bij de dokter, en dan naar de apotheker gaat om zijn “bestelling” op te halen:

Hoewel 10 seconden in computertermen een eeuwigheid is, is dat in business context niet.   De kans dat een patiënt binnen 40 seconden na het voorschrijven, de dokter kan betalen en bij de apotheker geraakt is quasi-onbestaande.

Het CAP theorema stelt bij dit voorbeeld dan ook geen problemen.  Deze deadlock situatie kan alleen opgelost worden door de business mee te betrekken. Om deze reden is het essentieel om High Availability reeds vanaf de requirements analyse in rekening te brengen.

De noodzakelijke evolutie naar “distributed systems”

Het CAP theorema zou omzeild kunnen worden (in theorie althans) door te evolueren naar één monolithisch systeem. Dit is echter geen oplossing omdat men dan het probleem verschuift naar binnen de grenzen van dit systeem.  In de moderne wereld waarbij online toepassingen door steeds meer mensen gebruikt worden, kan de nodige performantie immers vaak niet eens door één systeem geleverd worden.  Het lijkt er dus op dat we dus noodzakelijkerwijs evolueren naar gedistribueerde systemen. Redundantie is in dat geval een erg efficiënte manier om de beschikbaarheid te verhogen.

Availability tijdens de requirements analyse

Het CAP theorema zal het ons dus moeilijk maken! Zoals reeds gezegd, kan men in de praktijk echter veel verbeteren door High Availability reeds vanaf de requirements analyse in rekening te brengen door:

• de levensduur en vluchtigheid van de gegevens in kaart te brengen (de 40s in bovenstaand voorbeeld) en
• de eisen op vlak van beschikbaarheid te specificeren voor elke use-case in plaats van voor het volledige systeem.

Tijdens de architectuurfase kan men dan specifiek optimiseren naar deze niet-functionele beschikbaarheidsbehoeftes.

Beter vele kleintjes dan een paar grote

Het punt dat ik wil maken in deze post, is dat bij een redundante architectuur, de strategie van vele kleintjes vaak beter is dan een paar grote.  Bij een traditioneel actief-passief failover systeem behandelt één systeem alle aanvragen tenzij dit systeem uitvalt, waarbij het passief systeem actief wordt en haar taken overneemt.  In dit geval bevat elk apart deelsysteem de mogelijkheid om het volledige probleem “op te lossen” en het falen van een systeem is intrinsiek een incident.

Stel daarentegen een gedistribueerd systeem voor waarbij 10 kleine, goedkope servers elk een deel van de taak op zich nemen en hierover voortdurend met elkaar communiceren.  Als er eentje uitvalt, zijn er nog 9 beschikbaar om de taken te herverdelen (de performantie zal wel wat afnemen).  Door de architectuur hierop ingesteld is, integreert een nieuw opgestart deelsysteem zich automatisch in het geheel.  Het vervangen van zo’n deel-systeem wordt een standaard, dagdagelijkse onderhoudstaak, juist zoals het nemen van een backup.

WC papier?

De vergelijking die ik graag wil maken is het onderhoud van WC papier.  Laten we twee situaties vergelijken:

• er is één rol van 400 vellen geïnstalleerd
• er zijn vier rollen van elk 100 vellen geïnstalleerd

Elke dag nagekeken wordt of de rol op is.  Indien nodig wordt de rol vervangen.  Bekijken we de grafiek van de hoeveelheid beschikbare wc papier in functie van de tijd:

Zoals duidelijk op te maken valt uit dit simpele conceptuele voorbeeld, is er steeds WC papier beschikbaar indien men kiest voor kleinere deelsystemen. In de situatie waarbij men één rol van 400 vellen heeft, moet men ofwel kiezen voor “waste” (weggooien van wc papier) of voor “downtime” (de afwezigheid van wc-papier).  Deze conclusies kunnen formeel geabstraheerd worden naar andere systemen.

Maar nu moet ik nog even mijn handen wassen…