High availability of disaster recovery?

We zijn verwend geraakt door het Internet: de meeste websites lijken het altijd te doen. High Availability, hoge beschikbaarheid, wordt als de norm ervaren. Een internet bankieren site die niet werkt haalt het NOS Journaal. Waarom worstelt internet bankieren met beschikbaarheid waar een transactie verwerkende site als Booking.com dat niet doet?

Het verschil tussen High Availability en Disaster Recovery

High Availability (HA) is niet hetzelfde als het hoofd kunnen bieden aan calamiteiten. Daar kom je op het gebied van Disaster Recovery (DR). High Availability (HA) gaat over beschikbaarheid ondanks toevallige storingen in de hardware, de software en het netwerk of moedwillige verstoringen van buiten af.  HA heeft een sterke pro-actieve component in de zin dat op basis van monitoring mogelijke verstoringen vroegtijdig ontdekt en verholpen worden.

DR maatregelen treden reactief in werking als ondanks alle HA maatregelen een systeem toch door de knieën gaat. DR heeft ook een pro-actieve component, namelijk alles wat nodig is om systemen constant up-to-date te houden, zodat bij een noodzakelijk recovery de meest recente data en software versies beschikbaar komt. Dat is een significant verschil met HA; een DR omgeving is goed afgeschermd van de primaire omgeving. In geval van een calamiteit mag de DR omgeving natuurlijk niet worden geraakt door de ramp die de primaire omgeving heeft aangetast.

Er is nog een fundamenteel verschil tussen HA en DR: HA neigt snel naar zeer complexe, moeilijk te beheren oplossingen. Applicaties dienen specifiek ontwikkeld te zijn voor HA wil het überhaupt kans van slagen hebben. HA software moet bijvoorbeeld “in-service-updates” mogelijk maken om onderhoudsvensters te vermijden. Het verzekeren van de consistentie van de data is tijdens zo’n upgrade cyclus een grote uitdaging.

DR daarentegen is verhoudingsgewijs eenvoudiger te realiseren omdat het niet meer is dan een kopie van de productie omgeving, die à la minute kan worden opgestart. Een goed geteste DR is bijvoorbeeld een goed bruikbaar roll-back scenario bij upgrades, die niet binnen de geplande onderhoudsvenster zijn af te ronden.

Zakelijke perspectief van beschikbaarheid

Zakelijke overwegingen bepalen wat een effectieve oplossing is. Effectiviteit wordt vastgesteld aan de hand van het gedrag van de klant. Voor een webwinkel, waar een bezoeker binnen een paar seconden naar de concurrent doorklikt, heeft beschikbaarheid een andere economische waarde dan in een kantooromgeving. In een kantoor kan een gedwongen 5 minuten koffiepauze acceptabel zijn mits het sporadisch voorkomt en de systemen gewoonlijk een geaccepteerde responsetijd hebben. Immers tijdverlies voor een medewerker is de optelsom van down-time plus wachttijd bij elke transactie. Daarentegen lijkt een website waar je sowieso moet zijn, bijvoorbeeld de eerder genoemde bank, meer op een kantoorsituatie. Klanten overwegen immers om pas naar een andere bank over te stappen na meerdere langdurige verstoringen.

Waarom is Booking.com altijd beschikbaar en mijn internetbankieren niet?

Een partij als Booking.com is als webwinkel zo afhankelijk van beschikbaarheid dat applicatieredundantie van levensbelang is. Vanaf dag één is software gebouwd met redundantie als randvoorwaarde. Daarnaast worden servers wegens performance geografisch dicht bij de afnemers in de buurt geplaatst. Dat betekent automatisch dat dezelfde functionaliteit meerdere malen gerepliceerd beschikbaar is in verschillende datacenters. Voor onderhoud kunnen groepen servers selectief en gecontroleerd off-line gehaald worden zonder dat de gebruiker daar last van ondervindt of het zelfs maar in de gaten heeft.

Waarom pakken banken het niet op dezelfde manier aan?

De gevestigde banken zijn ooit begonnen hun systemen te bouwen voor intern gebruik. Beschikbaarheid werd gemeten in uren in plaats van seconden omdat data verwerking overwegend een batch proces was. Dergelijke systemen ombouwen tot of koppelen aan interactieve systemen brengt een enorme complexiteit met zich mee.

Over het algemeen hebben banken een beperkte geografische spreiding. Zelf als we over de grote internationale takken van banken praten, zijn de klantenkringen klein omdat wet- en regelgeving per land verschillen en daarmee de applicaties van elkaar verschillen. Daarnaast is internetbankieren aanvankelijk vooral gezien als een kostenbesparend klantkanaal, bovenop het van origine batch ingerichte betalingssystemen van banken.

Complexiteit en onderschat zakelijke belang, hebben geleid tot een evolutionaire ontwikkeling. De erfenis uit het verleden geeft ook hierin helaas geen garanties voor de toekomst.

Wat zouden banken kunnen doen?

Banken zouden kunnen overwegen om enerzijds een bedrijfszekere DR in te richten en anderzijds de verwachting te managen bij hun klanten omtrent beschikbaarheid. Altijd voldoen aan de verwachtingen van klanten is een van de pijlers onder commercieel succes. Het alternatief is wedijveren met jongere bedrijven op technologisch gebied die minder ballast uit het verleden meeslepen en dat vraagt meer dan een evolutionaire ontwikkeling.

High availabity of disaster recovery?

Zelfs binnen IT afdelingen bestaat spraakverwarring over high available en disaster recovery oplossingen. Zoals duidelijk gemaakt, verschillen de twee oplossingen enorm van elkaar en hebben ze een totaal andere karakteristiek. Organisaties hebben dus de mogelijkheid om te kiezen tussen HA, DR of te kiezen voor beide. Zoals altijd zou de behoefte van de te bedienen klant bepalend moeten zijn, voor de te kiezen oplossing. Dat is precies de reden waarom veel organisaties maar een paar applicaties high available uitvoeren.