Eventual Consistency is dé truc waarmee vele NOSql databases hun beschikbaarheid gevoelig kunnen verbeteren. Maar kunnen we dit principe ook doortrekken naar de rest van de architectuur, en misschien zelfs laten meespelen op business niveau? Of is het sop de kool niet waard, en moeten we kiezen voor de eenvoudig bruikbare garanties die Strong Consistency ons biedt?

In dit blogartikel gaan we het concept Eventual Consistency (EC) verder uitdiepen. Wat betekent het precies? Wat zijn goede voorbeelden? En – uiteraard – wat hebben we er precies aan? Wanneer wordt dit principe nuttig?

Wat is Eventual Consistency?

Het principe / model van Eventual Consistency bestaat reeds lang, maar werd vooral bekend door het gebruik ervan in NOSql databases. Deze databases waren een broodnodige revolutie toen populaire webtoepassingen een zodanig grote schaal kregen dat traditionele databases ontoereikend bleken.

Het grote voordeel van deze databases is namelijk dat ze enorm schaalbaar zijn en, zelfs bij het voorkomen van netwerkfalen, blijven werken. Het is precies het EC model dat hiervoor zorgt. Maar wat doet dit principe nu juist?

Het Eventual Consistency model is van toepassing op gedistribueerde systemen; m.a.w. systemen met meerdere nodes, verbonden door een netwerk. Een systeem dat als consistentiemodel EC heeft, zal ervoor zorgen dat een update aan een gegeven na verloop van tijd op alle nodes zal geraken. Tot die tijd kan het zijn dat we op bepaalde nodes nog de vorige waarde van het gegeven uitlezen.

Dit is natuurlijk een erg zwakke garantie, maar ze laat toe dat de nodes afzonderlijk kunnen blijven werken, zelfs indien het netwerk ertussen faalt, of indien een aantal nodes een tijdlang uitgeschakeld worden. Wanneer alles terug in orde geraakt, zal het systeem ervoor zorgen dat alles overal terug up-to-date is.

Eventual Consistency wordt ook wel Optimistische Replicatie genoemd. Wanneer een EC systeem de nodige updates heeft verwerkt en terug consistent is, zeggen we dat het systeem is geconvergeerd. De tijd die verstrijkt tussen een update en het convergeren, noemen we de inconsistency window. Deze willen we natuurlijk liefst zo kort mogelijk houden. In de huidige state of the art zal dit in de meeste gevallen, indien er geen falende nodes of netwerkpartities zijn, slechts milliseconden tot seconden duren.

Natuurlijk maakt het Eventual Consistency model het ook wel moeilijker om te redeneren en om te gaan met de data. Zo zijn er een aantal problemen waar developers een antwoord op zullen moeten hebben, indien ze EC willen gebruiken. Wat doe je bijvoorbeeld met clients die een node consulteren die nog niet de laatste nieuwe gegevens heeft? En – erger nog – wat als twee nodes een update binnenkrijgen voor hetzelfde gegeven, vóór ze elkaar op de hoogte hebben gebracht?

De meeste developers zijn gewend aan de luxe van “Strong Consistency” bij de systemen waarop ze verder bouwen. Deze tegenhanger van EC garandeert dat indien er een update is gebeurd, élke leesopdracht die daarna nog volgt deze update zal zien. Daarenboven is het in zo’n systeem niet mogelijk om conflicterende updates te doen aan éénzelfde gegeven.

Je kan natuurlijk al aanvoelen dat Strong Consistency zijn eigen problemen heeft: wanneer de schaal groter en groter wordt, kan het steeds vaker voorkomen dat clients moeten wachten, omdat het systeem bezig is ervoor te zorgen dat alle nodes consistent zijn. Het systeem wordt daardoor dus minder beschikbaar. Of nog: onvoldoende nodes kunnen met elkaar communiceren om consistentie te garanderen, en het volledige systeem wordt onbeschikbaar. Dit is natuurlijk precies de te maken keuze die wordt geïllustreerd door het CAP / PACELC theorema, waarover we reeds eerder hebben geblogd. Een gedistribueerd systeem moet altijd Partitietolerant zijn (P), dus daarna blijft nog de keuze over om te focussen op Consistentie (C) of Availability (A), maar alle drie samen gaat niet (zelfs de laatste evolutie in databases, de NewSql databases, maken hierin de keuze voor consistentie, al voorzien ze heel wat verbeteringen om toch nog zo beschikbaar mogelijk te zijn).

Voorbeelden

Buiten het typische voorbeeld van NOSql Databases die EC storage kunnen leveren aan applicaties, kunnen we ook een aantal voorbeelden geven waarbij de EC op een hoger niveau van abstractie zijn werk doet binnen een applicatie, en zelfs op business niveau zijn impact heeft.

1. Domain Name System (DNS)

DNS, een zeer bekend systeem in de informatica, koppelt internet domeinnamen aan IP-adressen. Het is een hiërarchisch systeem, doch grotendeels gedecentraliseerd. Noodzakelijkerwijs moet de data sterk verspreid en gerepliceerd worden, want het volledige internet maakt gebruik van dit systeem, en geen enkele individuele machine of zelfs cluster zou deze schaal aankunnen.

Wanneer er een update gebeurt binnen dit systeem, zal dit eerst op één server gebeuren. Deze server (de “authoritatieve server” voor een bepaald domein) heeft dan het correcte IP-adres dat bij een domeinnaam hoort, maar andere servers nog niet. Na verloop van tijd zal de informatie zich echter verspreiden doorheen het hele DNS systeem. Uiteindelijk zullen alle servers die de desbetreffende domeinnaam stockeren, hun cache laten verlopen, en de meest recente versie opvragen, en op deze manier is DNS dus eventually consistent.

Zonder verdere maatregelen, zullen clients die toevallig naar een bepaalde site willen surfen, terwijl de cache van hun DNS server nog naar oude data verwijst, niet naar het nieuwe IP adres kunnen gaan. Met een goed beheer van je DNS data kan je dit echter voorkomen (b.v. op het oude IP adres nog een tijdlang een redirect server plaatsen).

2. Webwinkel

Voor een webwinkel kan elke minuut dat mensen geen bestellingen kunnen doen, een groot verlies betekenen. Beschikbaarheid (van het winkelgedeelte op zijn minst) is dus cruciaal.

Om hiervoor te zorgen, kan er worden gebruik gemaakt van Eventual Consistency in verschillende gradaties. Men zou bijvoorbeeld kunnen stellen dat men veranderingen in het inventorysysteem (b.v. hoeveel van dit artikel is nog in stock?) slechts met enige vertraging laat doorsijpelen tot het frontend systeem, dat de clients bedient, die bezig zijn met winkelen. Je zou dus iets in je winkelkarretje kunnen leggen dat niet meer in stock is. Op het moment echter van de eigenlijke bestelling, zou men wel via een transactie kunnen werken, waarbij men effectief de huidige inventaris gaat nakijken alvorens de bestelling te laten doorgaan. Indien het artikel er niet meer is, krijgt de klant op dat moment een foutboodschap met verontschuldigingen en b.v. de optie om bericht te krijgen wanneer de stock is bijgevuld.

Op deze manier voorziet men reeds een loskoppeling tussen het winkelsysteem zelf, en de inventory backend, waardoor de eerste beschikbaar blijft, zelfs wanneer de laatste niet goed werkt.

Men kan hier de Eventual Consistency zelfs nog verder doortrekken: we laten de bestelling doorgaan zonder de inventory op te nemen in de transactie, en we brengen deze pas later (eventually) up-to-date. Zo kan een klant een item zelfs bestellen indien het niet meer in stock is. Uiteraard zal er echter wel iets moeten gebeuren in zo een geval. We kunnen dan op zoek gaan naar mitigerende processen op business niveau. Er kan bijvoorbeeld een email gestuurd worden met verontschuldigingen: “spijtig genoeg moeten we dit artikel nabestellen en zal het dus iets later zijn; u krijgt de verzendingskosten terug of mag de bestelling alsnog annuleren”. Of nog: “We kunnen dit helaas nu niet leveren; we annuleerden uw bestelling en u krijgt een waardebon”. Hier zijn tal van mogelijkheden, de ene al klantvriendelijker dan de andere, waaruit de business kan kiezen als strategie.

3. Het bancair systeem

Het lijkt misschien contra-intuïtief, maar een aantal aspecten van het bancair systeem, bijvoorbeeld bij het “settlen” van rekeningen, zijn via EC geregeld, en dit was noodzakelijkerwijs zelfs al zo voordat er sprake was van computers!

Wanneer in de IT een voorbeeld van de bankwereld wordt gebruikt, zal men typisch de atomaire transactie uitleggen die moet gebeuren bij een overschrijving: indien één rekening gedebiteerd wordt, moét de andere gecrediteerd worden, of vice versa. Dit is natuurlijk een voorbeeld van Strong Consistency.

Maar er zijn tal van manieren waarop de stand van een rekening niet overeenkomt met wat de waarde ervan zou moeten zijn, rekening houdend met alle transacties die al hebben plaatsgevonden of nog moeten plaatsvinden. Zo kan ik b.v. allerlei online zaken bestellen op zondag, terwijl ik zaterdag al ben gaan winkelen. De bancontact transactie van de winkel is nog niet doorgekomen, en het saldo op mijn rekening is dus een pak hoger, waardoor ik meer geld kan uitgeven dan ik heb. Op maandag wordt alles dan vereffend en komt mijn rekening onder nul. Gelukkig werd op vrijdag mijn loon gestort en komt dit óók maandag tot uiting op mijn rekening. Net op tijd om de cheque aan te kunnen die geïnd zal worden op dinsdag, maar die ik reeds een week geleden aan iemand heb gegeven voor een grote aankoop, met de vraag of die even wou wachten met het innen.

Er kunnen dus allerlei zaken gebeuren die het saldo van een rekening beïnvloeden en die soms zelfs het saldo van de rekening nakijken, zonder dat het saldo al met al deze zaken rekening houdt. De rekeningstand is dus “eventually consistent”: uiteindelijk komen alle transacties erop terecht, maar dit kan even duren.

De bankwereld heeft geen probleem met het bestaan van dit soort inconsistenties in hun systeem, die zelfs op business niveau zichtbaar zijn. Misbruik ervan wordt dan ook vrijwel geheel vermeden door allerlei provisies (eveneens op business niveau): b.v. wetten die fraude strafbaar maken.

4. Onze sector?

We kunnen niet direct voorbeelden geven van zaken die binnen onze sector via eventual consistency zijn geïmplementeerd, maar we kunnen wel eens verkennen waar er eventueel mogelijkheden bestaan om dit in de toekomst te gaan doen.

Als we de typische workflows binnen de overheid in beschouwing nemen, zien we dat er geregeld processen zijn waarbij iets wordt aangevraagd, of een dossier wordt ingediend, dat dan later wordt nagekeken en wordt verwerkt met menselijke tussenkomst. Dit is een heel goede indicator dat we misschien wel EC kunnen gebruiken, gezien er reeds een natuurlijke vorm van uitstel in het proces zit. Hetzelfde zien we bij die processen waarin gegevens verplicht moeten worden ingediend, maar niet noodzakelijkerwijs onmiddellijk worden behandeld door de desbetreffende overheidsdienst.

Kijken we anderzijds naar de gezondheidssector (eHealth). Hier is het uiteraard cruciaal dat de toegang tot patiëntendossiers een zo hoog mogelijke beschikbaarheid biedt. Maar is het absoluut noodzakelijk dat de informatie tot op de seconde up-to-date is? Persoonlijk zou ik denken van niet. Indien mijn huisarts mijn dossier een half uurtje geleden heeft geüpdated, is het allicht niet erg dat ze dit in het ziekenhuis nog niet kunnen zien. De volgende dag, als ik naar het ziekenhuis ga, wil ik dit uiteraard wel, maar tegen dan heeft men tijd genoeg gehad om alle nodes van het systeem voldoende met elkaar te laten communiceren.

En wat met apothekers die de verzekerbaarheid van iemand moeten nagaan? Het is cruciaal dat deze informatie beschikbaar is wanneer iemand een medicijn komt kopen. Maar de kans dat dit gegeven is veranderd gedurende het voorbije half uur is enorm klein; ook hier kan men dus overweg met gegevens die niet tot op de seconde up-to-date zijn. Voeg daarbij eventueel een mitigerende regel op business niveau toe, voor de minieme hoeveelheid uitzonderingen waarbij men toch een medicijn zonder korting zou verschaffen terwijl de klant hier wel recht op had (b.v. een terugbetaling achteraf, wanneer dit wordt vastgesteld dankzij de zich convergerende gegevens).

Evaluatie en Besluit

De voorbeelden maakten het reeds duidelijk: Eventual Consistency kan ervoor zorgen dat een systeem gewoon blijft doorwerken, zelfs wanneer er zaken mislopen. Op die manier kan de resiliëntie gevoelig worden verhoogd. Er moet in zo’n geval echter wel met een aantal inconsistenties in de data worden rekening gehouden, op IT vlak óf op business vlak, en dit maakt het complexer om over deze systemen te redeneren en om deze te bouwen. En uiteraard heeft een complex systeem ook een verhoogde kans op falen, net door de verhoogde kans op fouten die deze complexiteit met zich meebrengt.

We zullen dan ook een afweging moeten maken, samen met de business, om te zien waar de prioriteiten liggen. Hoe belangrijk is het dat dit systeem een beschikbaarheid heeft van vele negens (99,9% beschikbaarheid, “triple nine availability”, is b.v. nog haalbaar zonder EC voor een niet al te groot systeem)? Hoeveel data zal het systeem op termijn gaan bevatten / behandelen? In welke mate zal het moeten schalen voor gebruik door vele gelijktijdige clients?

We kunnen stellen dat Eventual Consistency enorm vruchten begint af te werpen, wanneer men met systemen te maken krijgt van een redelijk grote schaal. Voor dit soort systemen wordt het sowieso complex om ze draaiende te houden en zal de bijkomende complexiteit die EC met zich meebrengt, relatief een minder groot verschil maken. Het voordeel van de verhoogde resiliëntie zal in dat geval meer doorwegen. Sommige experts stellen zelfs dat sterke consistentie een sprookje wordt vanaf een bepaalde (erg grote) schaal, en dat men dus op een bepaald moment altijd naar eventual consistency zal moeten grijpen bij een sterk groeiend systeem.

Indien men echter met een klein systeem zit, b.v. bedoeld voor intern gebruik en met beperkte volumes aan data, dan zal het sop de kool meestal niet waard zijn en kan men, voor het gemak, best gebruik maken van Strong Consistency, wat het veel eenvoudiger maakt voor de ontwikkelaars van het systeem om het te bouwen en onderhouden.

Ten slotte kan men best bij elk project van enige omvang eens kritisch kijken naar de business processen die worden gedigitaliseerd. Vergen alle te implementeren functionaliteiten daadwerkelijk sterke consistentie doorheen het volledige proces? Moet alle data binnen de paar seconden gegarandeerd overal up-to-date zijn? Of zijn er misschien van nature stappen aanwezig waar menselijke tussenkomst is vereist, en men dus sowieso met wachttijden zit? Bestaan er eventueel op business niveau reeds mitigerende processen om om te gaan met een inconcistentie?

Vaak zal men dan zien dat sterke consistentie toch niet nodig is, en zeker niet overheen het volledige systeem, en ontstaan er dus mogelijkheden om de resiliëntie te verbeteren via Eventual Consistency.

De nieuwe Databases als kruising van NOSQL en SQL…

NewSQL (uitspraak: “new sequel”) is een recente, moderne klasse van DataBase Management Systemen (DBMS), of, kortweg, databases. Deze klasse positioneert zich tegenover de reeds bestaande klasses van Relationele DBMS (RDBMS) en de zogenaamde NOSQL (“no sequel”) databases, waarbij NOSQL staat voor “Not Only SQL”, maar echter nog vaak als “No SQL” wordt begrepen.

Deze laatste categorie maakte een decennium geleden furore als alternatief voor de traditionele RDBMS, en had als doel om zaken als performantie, schaalbaarheid, beschik-baarheid en distribueerbaarheid te verhogen, ten koste van de consistentie. Bij NOSQL databases sprak men vaak van “eventual consistency”, wat betekent dat men niet via transacties werkt, maar er eerder op rekent dat het systeem na verloop van tijd altijd opnieuw in een consistente toestand zal geraken. Dit maakt onderdeel uit van de “BASE principes” (zie kader). NOSQL databases bekeken we bij onderzoek reeds 9 jaar geleden, en recent gingen we dieper in op de subcategorie graph databases.

Voor vele toepassingen gebruikt men echter nog graag de traditionele RDBMS, nu smalend “Old SQL databases” genoemd. De reden is dat deze databases de verantwoordelijkheid om de data consistent te houden voor een groot stuk naar zich toetrekken, door het aanbieden van transactielogica. Deze logica zit vervat in de zogenaamde ACID principes (zie kader), die door deze databases worden ondersteund. Daarnaast kunnen applicatiebouwers ook moeilijk afscheid nemen van het gemak van SQL ondersteuning. Deze taal neemt heel wat werk uit handen van de developers (vaak wordt SQL ook gegenereerd door een library).

Met de NewSQL databases probeert men nu de voordelen van zowel NOSQL als RDBMS te verenigen. Dit type databases wordt beschreven als de oplossing om, zoals bij NOSQL mogelijk is, een horizontaal schaalbare en gedistribueerde database op te zetten. Men streeft er dus naar om de performantie van NOSQL databases, die typisch hoger is dan die van RDBMS, te evenaren. Tegelijk probeert men dit te doen zonder aan de traditionele ACID principes te raken, die door RDBMS naar voren worden geschoven.

Hoe de NewSQL databases erin slagen deze eigenschappen te combineren, verschilt van geval tot geval. Een paar zaken hebben ze echter gemeen: ze ondersteunen, in tegenstelling tot de meeste NOSQL databases, het relationele model en ze gebruiken de taal SQL als de belangrijkste manier om met de database te interageren. Dit zijn typisch ook de belangrijkste kenmerken voor een RDBMS.

De vraag kan dus gesteld worden hoe gemakkelijk het is om een RDBMS te vervangen door een NewSQL database, gezien de manier om ermee om te gaan zo gelijkaardig is. Het is dus mogelijk dat NewSQL databases de resiliëntie van applicaties kunnen verhogen, doordat de resiliëntie van de onderliggende database verhoogt, en dit mogelijks met een beperkte migratie-effort, vanwege de compatibiliteit met de huidige gebruikte RDBMS. Verschillende NewSQL databases claimen compatibiliteit met een bestaande RDBMS (b.v. PostgreSQL) en slagen hier dus redelijk in. Er zijn echter soms toch enige beperkingen op hoeveel men precies ondersteunt van SQL in vergelijking met de RDBMS. Dit komt doordat men niet ontsnapt aan het fundamentele CAP theorema.

Het CAP theorema voor gedistribueerde systemen kwam reeds lang geleden aan bod op deze blog. Kort uitgelegd komt het erop neer dat je hoogstens twee van de volgende 3 zaken tegelijk kan hebben: Availability (je krijgt altijd een antwoord van het systeem), Consistency (je ziet ten allen tijde de meest recent geschreven data), Partition tolerance (het systeem blijft werken, ook al functioneert het netwerk tussen de nodes van het systeem niet meer). Ook het CAP theorema werd bij onderzoek reeds uitvoerig belicht.

Sowieso zal je in een gedistribueerd systeem altijd te maken krijgen met netwerk falen, dus je moet “iets” doen daarmee en dus de “P” ondersteunen. Dan rest dus nog de keuze of je voor “A” of “C” gaat. NOSQL databases kiezen voor “A”: alle nodes blijven werken, ook al zijn ze niet meer verbonden. Bijgevolg verliezen ze “C”: de data in de losgekoppelde nodes kan verschillen. Dit noemt men een “AP” systeem. NewSQL databases kiezen voor de andere aanpak: een aantal van de nodes die niet meer bereikbaar zijn, zullen een foutmelding geven en dus niet beschikbaar zijn. Zolang er een bepaalde meerderheid van nodes met elkaar kan communiceren, zullen deze beschikbaar blijven, maar het systeem is dus niet “100% beschikbaar”, enkel de nodes die de meerderheid vormen zijn dat. Dit wordt dan een “CP” systeem genoemd, want de nodes die nog werken zijn wel consistent. In Fig. 1 zie je het CAP theorema grafisch uitgebeeld; wanneer er geen rekening wordt gehouden met Partition Tolerance (de bovenste van de drie doorsnedes), zit je met het type database “SQL”, t.t.z. de traditionele RDBMS die niet gedistribueerd werken.

Wordt Vervolgd…

NewSQL databases lijken erg veelbelovend. Ze bieden een consistente gegevensopslag aan, bovenop een performant en resiliënt gedistribueerd systeem. Ondanks het feit dat ze de Availability uit het CAP theorema laten vallen, bieden ze een hogere SLA aan dan niet-gedistribueerde databases. Daarnaast vertonen ze een vrij grote compatibiliteit met de traditionele RDBMS databases.

Momenteel loopt er bij Smals Onderzoek een studie naar deze soort databases, waarbij we deze claims verder zullen toetsen aan de hand van een paar testen, en waarin we ook enkele concrete producten zullen uitproberen. Meer hierover in een latere blog.

In enterprise applicaties is functionaliteit een belangrijk, maar vaak ook het gemakkelijkere deel van software ontwerp.  Zolang iedereen maar weet wat ie wilt: dat heeft meer  te maken met visie, duidelijke communicatie, verantwoordelijkheden en overleg, ethiek, eerlijkheid, psychologisch en sociologisch inzicht, dan met informatica.

Niet-functionele requirements (NFRs) zijn de uitdaging

De niet-functionele requirements maken software ontwerp echter moeilijk op een andere manier omdat ze niet dicteren wàt de software moet doen, maar hoé ze haar werk moet doen.  Behalve dat het verband tussen niet-functionele requirements en een ontwerp minder expliciet zijn (hoe druk je robuustheid van software formeel uit in functie van de geschreven code?), verhogen ze ook aanzienlijk de dimensionaliteit van het op te lossen vraagstuk. Het is niet moeilijk om snelle code te schrijven, het wordt moeilijk als ze ook functioneel correct moet zijn, hoogbeschikbaar, schaalbaar, elegant, uitbreidbaar, goedkoop in onderhoud en ga zo maar voort.

De vraag is: hoe kun je software leveren die een bepaalde beschikbaarheid belooft (bv. max. 8u downtime per jaar voor 99.9%) als je de beschikbaarheid nog nooit gemeten hebt? Of maar gedurende 3 maand in Acceptatie? Misschien had je geluk (goede statistische corner)? Is deze meting wel onder een realistische load gebeurd? Dezelfde redenering gaat op voor schaalbaarheid, fail-over, aanpasbaarheid, robuustheid, continuous operations, …

Meet de test de applicatie of omgekeerd?

Uit ethisch standpunt zou dus elke applicatie die in productie gezet wordt, rigoureus getest moeten worden op alle NFRs.  Hiervoor moet uiteraard test-software geschreven worden.  Essentieel hierbij is dat de test-software zeer goed geschreven en beheersd wordt, zodat we bij het verkijgen van een resultaat zeker weten dat deze beïnvloed werd door de applicatie en niet door de test.  Dit is de reden waarom test-apparatuur in elektronica zo duur is, bijvoorbeeld.

De arrogantie van de onwetendheid

Als een mens naar de wolken kijkt en zegt welke figuur zij/hij ziet, zegt dit meer over die persoon dan over de wolken. Niemand heeft de arrogantie om anders te beweren – waarom kunnen we dan niet hetzelfde bij software ontwerp?

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…

Het streven van 99% naar 99.9% availability is een veel grotere stap dan de stap van 95% naar 99%.  De traditionele manier van werken schiet ruimschoots tekort (ad-hoc processen, de software-architectuur en ontwerp, een deterministische failover, …). Door alles “juist iets beter doen”, zullen we er niet komen.  De specifieke elementen van High Availability systemen worden in dit artikel kort besproken.

10 misvattingen bij gedistribueerde systemen

Bij het ontwerpen van systemen in een gedistribueerde context (bv. verschillende webservers moeten toegang krijgen tot dezelfde databank), wordt nog te vaak uitgegaan van veronderstellingen die in praktijk helemaal niet gelden, waardoor systemen falen:

1. Het netwerk is betrouwbaar;
2. De latency is nul;
3. De bandbreedte is oneindig;
4. Het netwerk is veilig;
5. De topology verandert niet;
6. Er is slechts één administrator.
7. Transport is gratis;
8. Het netwerk is homogeen.

Bij het ontwerpen van gedistribueerde systemen moet er vanuit worden gegaan dat deze elementen zullen falen. Tijdens testing moeten deze situaties dan ook expliciet gevalideerd worden!

Hoge beschikbare systemen

Voor het bouwen van systemen met een hoge beschikbaarheid, zijn volgende punten essentieel:

Governance

Het robuust maken van een systeem vereist dat men het systeem goed beheerst en dat er bijgevolg een hoge voorspelbaarheid heerst. ITIL processen moeten geïnstalleerd worden en zich in een mature fase bevinden. Denken we bijvoorbeeld aan IT Asset Management (welke hardware, welke software, welke applicaties, business processen, netwerkconnecties, … hebben we?), Release Management, Configuration Management (welke configuraties bevinden zich waar & waarom?), …

Duidelijke processen

De hoeveelheid menselijke interventie moet geminimiseerd worden (de meeste fouten gebeuren door mensen) en bijgevolg moeten zoveel mogelijk processen geautomatiseerd worden (hier is goede governance voor nodig uiteraard).  Er moet een duidelijk inzicht zijn van de processen, wie waarvoor verantwoordelijk is, een duidelijke documentatie aanwezig zijn en de complexiteit moet verlaagd proberen te worden.

Vanaf het ontwerp

Het ontwerp van systemen met een hoge beschikbaarheid steunt op

1. Transparantie: Lange termijn betrouwbaarheid is steeds gebaseerd op een transparante en begrijpelijke documentatie.
   
2. Lage complexiteit: Complexe systemen moeten opgedeeld worden in subsystemen met lagere complexiteit.
3. Redundantie: Redundante systemen voorzien een extra instantie voor in het geval een kritische component uitvalt; deze neemt automatisch over in geval van falen (failover) en zet een proces in gang dat de oorspronkelijke component laat heropstarten of vervangen.
4. Diversiteit: Diversiteit kan de kans op gezamenlijk falende componenten verminderen. Men kiest componenten & architecturen die fundamenteel andere faalmechanismes vertonen

Het CAP theorema

Theorema

Er bestaat een fundamenteel theorema, bewezen door de MIT, dat stelt dat bij gedistribueerde systemen, van de volgende drie niet-functionele requirements (NFR’s):

• Consistency (elk deelsysteem geeft hetzelfde antwoord)
• Availability (we krijgen steeds antwoord)
• Partition tolerance (verlies van willekeurig aantal netwerkpakketten is toegelaten)

er slechts twéé tegelijk voldaan kunnen zijn.

Grafisch bewijs

Zonder in detail te treden (Er bestaat een bewijs van de MIT), zullen we het theorema grafisch intuïtief illustreren.

Geval 1: Alles verloopt naar wens

1. Proces A schrijft een nieuwe waarde V1 weg naar de databank in node N1
2. Een message M gaat over het netwerk naar N2
3. De nieuwe waarde V1 is beschikbaar in de databank in node N2
4. Proces B beschikt over de nieuwe waarde

Geval 2: Het netwerk is onbeschikbaar

In dit geval komt de boodschap M met de change niet toe bij N2.  De eerste stappen blijven hetzelfde:

1. Proces A in systeem N1 schrijft V1 weg naar V0
2. Node N1 stuurt een boodschap M naar node N2

Op dit moment kan systeem N1 niet weten of het systeem N2 dan wel het netwerk down is (het systeem is partition-tolerant). Volgens het CAP theorema zijn nu twee keuzes:

A. Kiezen voor consistency
Omdat proces N1 geen ontvangstbevestiging gekregen heeft van N2, wordt het proces A afgebroken (atomicity) daar de consistency tussen de twee databanken in N1 en N2 niet gegarandeerd kan worden.  Het systeem is unavailable.

B. Kiezen voor availability
Hoewel systeem N1 geen ontvangstbevestiging gekregen heeft van N2, wordt de transactie toch afgehandeld (het systeem is dus available).  Op dit moment bezitten N1 en N2 verschillende versies van de gegevens.  Het systeem is inconsistent.

Geval 3: Kiezen voor partition intolerance

Het geval dat men kiest om partition intolerant te zijn, gaat men er in feite van uit dat het netwerk nooit faalt. Het systeem is dus gevoelig aan het verlies van netwerkpakketten. De deelsystemen gaan er immers vanuit dat elk verzonden pakket ook toekomt.  In bovenstaand geval kan het zijn dat node N2 “down” is.  In dit geval kan node N1 dit detecteren (niet kunnen communiceren is dan immers equivalent aan “de node is down” omdat we gevoelig zijn aan partities) en hier rekening mee houden. De databank is consistent en available, maar niet partition tolerant.

Conclusies

Het in productiestellen en onderhouden van hoog-beschikbare systemen, vereist een goede controle evenals een goed inzicht.  Daarom is het belangrijk

1. Een goede governance te hebben (ITIL, …)
2. Menselijke interactie te minimiseren in alle processen
3. Rekening te houden met High Availability vanaf het begin van het ontwikkelproject

De belangrijkste basistechnieken gebruikt in High Availability architecturen zijn:

1. Transparantie (goede documentatie!)
2. Verlagen van de complexiteit
3. Redundantie
4. Diversiteit
   

Essentieel is echter te beseffen dat Consistentie, Availability en Partition Tolerance niet op hetzelfde moment gegarandeerd kunnen worden maar afgewogen moeten worden!! In praktijk zal men kiezen voor Eventually Consistent systemen die tijdelijke consistentie problemen tgv. de unavailability van een deelsysteem later zullen opvangen en oplossen op business niveau.  Hier moet vanaf het begin van het ontwerp rekening mee gehouden worden!

]]> https://www.smalsresearch.be/99-9-availability-fundamenteel-anders/feed/ 1