Virtuele systemen zijn niet echt. Onzin natuurlijk, want miljoenen bedrijven wereldwijd werken met virtuele systemen. Een virtuele server heet ook wel Virtual Machine of kortweg VM. In de IT kent vrijwel iedereen die term. Een VM bootst een fysieke omgeving na, compleet met virtueel werk- en opslaggeheugen en andere zaken die zorgen dat het ‘echt’ werkt. Wat is dan een virtuele test of controle van een Disaster Recovery (DR)- of High Availability (HA)-omgeving?Om de lengte van deze blog niet langer te maken dan nodig, beperk ik mij tot oplossingen voor IBM iSeries of Power-systemen met OS/400-operating systems. Ook laat ik zoveel mogelijk technische termen achterwege om de leesbaarheid te vergroten. Het zal op andere type servers en operating systemen overigens niet heel anders werken.
In essentie wordt een DR- of HA-omgeving gecreëerd door ‘alles’ (data, applicaties, OS, et cetera) van het productiesysteem naar het back-upsysteem te repliceren. Het DR- of HA-systeem is dan de spiegel van het productiesysteem geworden. Wijzigt er iets op de productieserver, dan wijzigt dat ook op de back-upserver. De systemen zijn ‘in sync’ of ‘gespiegeld’, zoals dat populair heet.
TESTEN ZONDER SPIEGELING
Zou je iets willen testen, dan is de back-upserver een logische keuze waarop je dat doet. Je gaat tenslotte niet iets in een productie-omgeving testen. Echter, de DR- of HA-software voorkomt doorgaans dat je aan kunt loggen op de back-upserver. Alles wat je daar doet wordt immers direct ongedaan gemaakt door het spiegelingsproces dat beide omgevingen gespiegeld houdt.
Testen vereist dus dat de spiegeling wordt stopgezet. Het probleem is vervolgens dat je op dat moment en zo lang de test duurt niet langer een actieve en dus geen correcte DR- of HA-omgeving hebt. Zal je net zien dat er iets ernstigs gebeurt waardoor je van de back-upserver gebruik moet maken, en dan staat de laatste informatie er niet op! Sterker nog, er is waarschijnlijk (rare) testdata aangemaakt. Stel dat er 100 orders op het systeem staan en ik wil iets testen in een order. Ik maak een order aan die volgnummer 101 krijgt. Op de productieserver draait de business ondertussen gewoon door. Daar is inmiddels ook ordernummer 101 aangemaakt, en 102, 103, enzovoorts. De database is compleet inconsistent geworden.
VIRTUELE TEST
Een virtuele test werkt eigenlijk heel simpel. Onder de motorkap is het natuurlijk een technisch vernuft van jewelste. Voor een virtuele test wordt het aanbrengen van de wijzigingen op de back-upserver gestopt. Het verzamelen van alle wijzigingen op de productieserver en het versturen daarvan naar de back-upserver gaat echter door. Dat is heel belangrijk. Stel dat de productieserver tijdens de test crasht, dan staan alle wijzigingen toch op de back-upserver. Alles wordt dus steeds netjes gelogd, overgestuurd en bewaard.
Ik kan nu aanloggen op de back-upserver en mijn test uitvoeren. Alles wat ik op die back-upserver doe, wordt gelogd. Een groot voordeel is overigens dat je de log kan bekijken en dus kan controleren wat wel en niet geraakt wordt door de test.
De back-upserver bootst nu een tijdelijke productieserver na. Het is niet ‘echt’, dus is het ‘virtueel’. Vandaar de naam ‘virtuele test’ of ‘virtual role swap’ of ‘virtual switch’. De productieserver draait immers ongestoord door.
Wanneer ik klaar ben met mijn test, zal de Virtual Switch-functie van de DR- of HA-software alle aanpassingen op de back-upserver ongedaan maken. Het behouden van een consistente database wordt nauwkeurig bewaakt. Zodra dat klaar is, worden alle opgespaarde wijzigingen aangebracht die al die tijd steeds op de back-upserver zijn bewaard. De taak die dit doet wordt doorgaans ‘apply job’ genoemd. Tijdens dit proces worden nieuwe wijzigingen van de productie- naar de back-upserver ook gewoon doorgestuurd en vastgelegd. Het aanbrengen van alle wijzigingen gaat door totdat beide servers weer volledig ‘in sync’ zijn.
ROLE SWAP OF SWITCH NOODZAKELIJK
Externe systemen die met een productieserver zijn verbonden, blijven daarmee verbonden tijdens een test. Niet alles kan dus tijdens een virtuele test worden getest of gecontroleerd. Naast een virtuele controle blijft een echte role swap-test of switch-test noodzakelijk. Zo kan alles getest worden en weet je zeker dat de DR- of HA-omgeving 100 procent werkt in het geval je die echt nodig hebt. Wees er wel van bewust dat de switch-tijd langer duurt als je tijdens een virtuele test onverhoopt echt moet switchen. Alle wijzigingen op de back-upserver moeten immers ongedaan worden gemaakt. Ook moeten alle wijzigingen van de productieserver die dan al op de back-upserver staan nog worden aangebracht.
Oude producten, zoals OMS/ODS bieden de virtual switch test niet. Moderne producten als iTera Availability en Mimix Availability doen dat wel. Het is het overwegen waard om te migreren naar zo’n moderner product. Al zou je de virtuele test niet gebruiken en vind je ‘gewoon testen’ voldoende, dan nog is het veiliger wanneer alle wijzigingen toch naar de back-upserver worden gestuurd als het aanbrengen van data op de back-upserver wordt gestopt. Bij oudere producten wordt de data dan gelogd op de productieserver in plaats van op de back-upserver. Als er dan werkelijk iets gebeurt, ben je al die gegevens alsnog kwijt. En dat is nou precies niet de bedoeling van een goede (moderne) DR- of HA-oplossing.
CONCLUSIE?
Een virtuele test biedt het voordeel dat deze niet altijd op nare tijden, zoals ’s nachts, tijdens een weekend of ‘in periode van minder gebruik’, hoeft te worden uitgevoerd. De productie draait door. Ik ken IT-managers die gewoon tijdens werktijden virtuele tests laten uitvoeren.
MORAAL VAN DIT VERHAAL?
Virtueel is niet altijd reëel. Echt testen blijft noodzakelijk. Laat dat er niet bij inschieten, want schijnveiligheid is snel gecreëerd. En daar is niets virtueel aan.
PS: Excuus voor de twee wat minder scherpe plaatjes deze keer 🙂
Bronnen: