Blog

Een upgrade met rampzalige gevolgen

Aanbevelen

Gepubliceerd:07-12-2009 om 13:05 Auteur:Matt Prigge

Het is niet zo moeilijk bij een upgrade fouten te maken. Helemaal wanneer je het belang van goede infrastructuur vergeet en niet de juiste procedures volgt.

Niet lang geleden in een land hier niet ver vandaan, was een productiebedrijf erop gebrand een versie-upgrade te doen van zijn meest bedrijfskritische applicatie. Het bedrijf leunde op het programma dat het hart van het bedrijf vormde. Zonder zou het bedrijf niet kunnen werken; er zouden geen orders verstuurd kunnen worden.

Het bedrijf investeerde een hoop tijd en moeite in het testen van de nieuwe versie. Gebruikers werden van testsysteem naar testsysteem gesleept in de maanden voor de datum om live te gaan. De applicatieleverancier, die het bedrijf die maanden ervoor bijstond om bijvoorbeeld bugs te repareren, bleek gedurende het upgradeproces een geweldige partner. De nieuwe functionaliteit werd grondig getest en de gebruikers waren dolenthousiast.

De planning om live te gaan was nogal complex van aard. De backend van de applicatie draaide op een databasecluster op de beste en duurste servers. De database zelf draaide op een highly redundant storage array die geplaatst was tijdens de vorige applicatieupgrade van enkele jaren terug.

De nieuwe applicatie zou veel aanpassingen aan de gebruikte datastructuur met zich meebrengen. Er was een gecompliceerd conversieproces dat offline moest gebeuren. Gelukkig was dit proces eerder al een paar keer getest, maar er waren ook nieuwe procedures nodig waarvoor ook de werkstations geüpgrade moesten worden met een nieuwe versie. De oude cliëntversie van de applicatie werd hierna onbruikbaar.

Eindelijk was het tijd om live te gaan. Je kon de klok erop gelijk zetten, 7 uur ’s avonds op een zaterdag begon het conversieproces. De volgende ochtend was het migratieteam klaar. De database leek klaar om gebruikt te worden en werd geïmplementeerd op de applicatieservers. Gebruikerstests begonnen opnieuw en alles leek uitstekend te werken. Toen kwam het besluit om de nieuwe cliëntsoftware te pushen; ruwweg 1000 werkstations ontvingen de update van de cliëntsoftware.

De lawine komt los

Het eerste teken van onheil was een telefoontje dat de helpdesk ontving van een intensieve gebruiker. Hij probeerde een order te updaten, maar vond het relatief lang duren voordat hij naar een volgend scherm kon klikken. Het was geen groot probleem, maar hij herinnerde zich dat het tijdens de trainingsfase sneller ging. Op het moment van de melding waren slechts 150 gebruikers ingelogd op het nieuwe systeem. Leden van het applicatieteam voelden het lood in de schoenen zakken toen ze het bericht hoorden. Het leek alsof de temperatuur in het datacenter ineens met 20 graden gezakt was.

In de twee daarop volgende uren werd duidelijk dat er iets geweldig fout was gegaan. Hoe meer gebruikers in het systeem inlogden, hoe trager de applicatie werd. De eerste gedachte was dat er een netwerkprobleem was ontstaan en de netwerkbeheerder ging op onderzoek uit. Tegelijkertijd doken systeembeheerders in de logbestanden van de applicatieservers en desktopexperts bekeken de werkstations terplekke. Uit het netwerkonderzoek kwam niets bijzonders. Ook de applicatieservers en werkstations werkten naar behoren. Niemand dacht dat het probleem te maken zou kunnen hebben met de databaseservers; deze waren veel krachtiger dan de taak waarop ze berekend waren. Maar naar verloop van tijd bleek het de enige plek waar het probleem had kunnen ontstaan.

Zes uur nadat de cliëntcomputers waren geüpgrade, bladerde het hoofd systeembeheer door de logbestanden van de databaseservers. Gebruik van CPU en het geheugen vertoonde waarden significant hoger dan ooit tevoren , maar ze bleven veruit binnen de maximale capaciteit van de dure servers. Pas als laatste keek de beheerder naar de logs van de diskarray. Ze kreeg de schrik van haar leven. Het gebruik van de diskarray was ongelooflijk hoog, zo hoog dat de array de belasting niet aankon. Verdere analyse onthulde dat een set van diep in het systeem opgeslagen procedures, allemaal verbonden met de nieuwe functionaliteit, de aanstichter moest zijn.

Negen uur na de lancering van het nieuwe systeem werd een noodvergadering belegd. De prestaties van het nieuwe systeem waren intussen zo dramatisch, dat bij plaatsing van de orders aanzienlijke vertraging ontstond. Helaas was er geen plan beschikbaar om terug te kunnen gaan naar de oude versie van de cliëntapplicatie. Omschakelen was geen optie meer. Een trage applicatie was nog altijd beter dan het tijdelijk stilzetten van de productie om handmatig alle cliënts terug te zetten naar de oude versie.

De week die daarop volgde was een inktzwarte periode voor de IT-afdeling van het bedrijf. De productieplanning had aanzienlijke vertraging opgelopen, klanten waren ontevreden en productiviteit ging verloren. De politieke gevolgen waren enorm. Om het probleem op te lossen werd uiteindelijk een nieuwe dure high performance storage array geplaatst waarna de productie verder kon met de nieuwe cliëntversie.

Leermomentje?

De hierboven beschreven situatie kan gezien worden als ‘leermoment’. In dit rampscenario zijn er zeven of acht dingen die ervan geleerd kunnen worden. Als je eerste reactie is dat je nooit een upgrade mag uitvoeren zonder eenvoudig terug te kunnen vallen op de oude situatie, heb je gelijk Ook als je zegt dat je nooit het proefkonijn van de leverancier mag zijn. Maar er is een nog duidelijker les.

De voornaamste reden voor het falen was de impact van de nieuwe software op de prestaties van de server- en storagearchitectuur. Als tijdens het testen de belasting van het systeem beter gecontroleerd werd en de belasting tijdens de trainingsfase werd geëxtrapoleerd naar de werkelijke situatie, dan zou snel duidelijk zijn geweest dat de storagearchitectuur aangepast moet worden om de belasting aan te kunnen. Verwacht niet dat een softwareleverancier dit voor je doet. Zij kennen de hardwareomgeving niet op dezelfde manier als jij deze kent. Uiteindelijk ben jij degene wiens baan op het spel kan komen te staan in een dergelijke situatie.

Matt Prigge is systeem- en netwerkarchitect bij de consultants van de SymQuest Group. Heb jij ook een horror-upgrade meegemaakt, vertel het ons hier of stuur een mail naar de redactie.