Het aantal aanbieders in de High Availability-markt voor i5/OS is de laatste tijd erg veranderd. Hadden we voorheen zes aanbieders die een applicatie aanboden in Nederland, nu zijn dat er nog maar drie. Hierdoor zien we ook dat de diverse business partners opeens wisselen van de ene HA-applicatie naar de andere. Ook de toekomst van een aantal producten is niet geheel duidelijk, wat in geval van een HA-applicatie wel van cruciaal belang is.

door Leo Oppenheimer

Om een uiteindelijke teleurstelling na de aanschaf van een High Availability-product te voorkomen, dient allereerst het beoogde doel goed op het netvlies te staan. Dit geeft de mogelijkheid om de juiste vragen te stellen voordat u tot koop overgaat. Het doel is simpel: kan ik indien nodig eenvoudig, snel, en betrouwbaar switchen van mijn productie- naar mijn back-upcomputer? En weer terug? Dit lijkt een open deur, maar alleen het formuleren van deze wens impliceert al dat alleen het repliceren/kopiëren van data en objecten niet voldoende is. Het gaat erom de tijd tussen de keuze om te gaan switchen en het daadwerkelijk zonder problemen in productie zijn op het andere systeem tot een minimum te beperken. Hoe korter de tijd, hoe beter het product. Hoe langer u nodig heeft, hoe groter de kans dat u beter een tape restore had kunnen doen.

De basis van alle HA-software is een replicatieproces. Sommige gebaseerd op local , sommige op remote journaling voor data, en allen maken gebruik van de (lokale) audit journal. Alle entries in deze journals die een wijziging inhouden, dienen betrouwbaar en snel te worden aangebracht op het targetsysteem. De tijd die zit tussen het maken van de wijzigingen op de source en het aanbrengen op de target bepaalt in hoge mate de snelheid waarmee u kunt switchen. Idealiter is er geen tijdsverschil en wordt het proces synchroon uitgevoerd. Risico van asynchrone replicatie is dat de integriteit van de database wordt aangetast en/of er vertragingen ontstaan bij het aanbrengen van de wijzigingen.

Verder dient er bij de applicatie/journalingkeuze rekening gehouden te worden met het feit dat remote journaling veel meer bandbreedte vraagt tussen de twee systemen. Dit in verband met het overzenden van alle journal entries. Local journaling biedt de mogelijkheid de journal receiver te filteren en alleen die data te verzenden die daadwerkelijk een wijziging betekenen. Dit heeft een reductie tot gevolg van 40 tot 60% van de hoeveelheid data die over de communicatielijn gestuurd moet worden.

Wat gebeurt er met de replicatie en apply op het moment dat u een back-up maakt op uw targetmachine, voor het geval dat er een calamiteit plaatsvindt ten tijde van of vlak na de back-up? Het aanbrengen van alle wijzigingen dient in de juiste sequence te gebeuren. Dit lijkt een gemeenplaats, maar als voor elke data-journal een apart apply-proces draait, evenals voor elk soort object (IFS, spoolfiles, user profiles, etc.) uit de audit journal, dient u wel te letten op dit aspect en de eventuele problemen die een verkeerde volgorde tot gevolg kan hebben.

Wie waren er tijdens de crash aan het werk op het source-systeem en welke taken waren actief? Welke batchtaken waren net afgerond of juist nog bezig, en in het laatste geval, hoe snel kunt u terugrollen naar het moment dat de taak gestart werd? Welke taken moet u nog submitten en hoe snel kunt u dit doen? In een ideale wereld staat de target in een afgesloten ruimte waar niemand bij kan en waar niemand op kan inloggen tot dit voor de switch noodzakelijk is. In de praktijk wordt er vaak getest en/of gewerkt op deze computer. Hierdoor bestaat de zeker niet ondenkbare mogelijkheid dat er wijzigingen aan data en objecten hebben plaatsgevonden, waardoor uw back-upmachine in feite onbetrouwbaar is geworden. Wat doet de HA-software als deze een fout constateert op de doelcomputer? Hoe kunt u zelf een controlemechanisme inbouwen en hoeveel tijd bent u dagelijks kwijt met het controleren van de status en de betrouwbaarheid van de back-up van dat moment?

Als u tevreden bent over de betrouwbaarheid en de snelheid van het HA-product, komt natuurlijk ‘the proof of the pudding’: de switch. Bent u in staat om een switch binnen een acceptabele tijd uit te voeren? Heeft u rekening gehouden met de verschillende mogelijke scenario’s en zijn deze scenario’s geïmplementeerd in de software en bovenal, bent u in staat om dit zelf te doen? Want hoe gecompliceerder het switchproces, hoe minder geneigd u zult zijn om dit te testen en hoe minder u in feite kunt vertrouwen op een goede afloop in geval van een calamiteit.

Tot slot. Als u geswitcht bent, houdt er dan rekening mee dat u op een zeker moment terug moet naar uw source. In het geval van een calamiteit kan er niet teruggerepliceerd worden naar de originele computer, die is immers down. Als u genoodzaakt wordt uw journal receivers te verwijderen wegens gebrek aan schijfruimte, kunt u dan alleen maar terug door middel van een save/restore? Als dit het geval is, bent u alsnog uren kwijt voor de switch terug en heeft u uw doelstelling niet bereikt, namelijk het eenvoudig, snel en betrouwbaar kunnen switchen!

Leo Oppenheimer is werkzaam bij Databalance, distributeur van de High Availability-software Quick-EDD.
U kunt Leo bereiken via l.oppenheimer@databalance.nl.