De computerstoring bij de gemeente Groningen is opgelost. De oorzaak van de kapotte firmware heeft HP echter nog niet kunnen vinden. De storing ontstond begin van de week in de firmware van het storage are network (san), draaiend in een Enterprise Virtual Array (EVA)-opslagomgeving van HP. Amerikaanse hulp was nodig, maar of ook andere klanten er last van kunnen krijgen kan de automatiseerder nog niet aangeven.
Maandagmiddag 6 februari 2012 begon in een van de datacentra van de gemeente Groningen de firmware die de EVA-controller aanstuurt te haperen en aan/uit, aan/uit te flikkeren. De andere controller, die het bij een storing zou moeten overnemen, voerde de handelingen echter niet naar tevredenheid uit. Leverancier HP kon in eerste instantie de storing oplossen, maar dinsdagochtend viel de firmware opnieuw uit en gaven beide controllers de geest. 'Zo'n 80 procent van onze systemen lagen plat, zowel in de backoffice als in de frontoffice', zegt Peter Wouters, concernmanager I&A van de gemeente Groningen. 'Dat betekende dat onze geautomatiseerde publieke dienstverlening was lamgelegd, zowel via internet als voor de medewerkers aan het loket.'
Opgeschaald
HP is dinsdag de hele dag in touw gezet om de storing te verhelpen. De oorzaak was niet duidelijk: de EVA-omgeving is niet verouderd (al start er dit jaar na drie jaar een nieuwe san-aanbesteding), er was recent geen upgrade uitgevoerd en met de vrieskou had het ook niets te maken. 'De san staat in een geconditioneerde computerzaal', aldus Wouters. 'Het was voor HP de eerste keer dat het bedrijf met zo'n storing te maken kreeg. Uiteindelijk is het probleem opgeschaald naar de Verenigde Staten waar een aantal system engineers op level 3 de EVA-omgeving weer in de lucht konden brengen door een nieuwe versie van de firmware te implementeren. HP had inmiddels gezorgd voor diverse reserveonderdelen voor de san-installatie, maar vervanging van onderdelen bleek niet nodig.'
Corrupte metadata
Wouters maakte met zijn ict-team benauwde moment door nadat het leek alsof alle metadata corrupt waren geworden. 'Die metadata zijn nodig om aan te geven welke gegevens op welke plek in een san zijn opgeslagen en in welke context. Zonder die metadata wordt het een grote losse verzameling bits en bytes. Gelukkig bleek HP na de invoering van de nieuwe firmware de metadata te kunnen terugzetten. We hebben natuurlijk een back-up maar als je die moet terugzetten ben je een paar dagen van de straat.'
Nadat alle gemeentelijke processen weer in de lucht waren, is er in de nacht van dinsdag op woensdag volop getest. Alleen het e-mailsysteem voor een gemeentelijk onderdeel en een aantal webformulieren functioneerden nog niet naar behoren. Die klachten waren woensdagavond verholpen.
Gespiegeld
De gemeente gaat de storing nog evalueren met HP. Zij wil bijvoorbeeld weten hoe het komt dat in de dubbel uitgevoerde san-omgeving de storing niet kon worden opgevangen. Ook zal de gemeente zichzelf moeten afvragen of er meer maatregelen nodig zijn. 'Zo'n storing toont maar weer eens aan hoe afhankelijk we van ict zijn geworden', zegt Wouters. 'Alleen, aan alles hangt een kostenplaatje. We kunnen er bijvoorbeeld voor kiezen om een totaal gespiegelde omgeving in te richten, waarbij twee systemen in realtime naast elkaar draaien. Dat is een stuk duurder. Bovendien, een zekerheid van 100 procent bestaat niet.'
De gemeente is wel in overleg met een tiental (semi-)overheidsinstanties in de regio om te bepalen of er gezamenlijke rekencentrumdiensten kunnen worden afgenomen. 'Dan kun je grote investeringen delen', stelt Wouters.
Analyse
HP laat in een reactie weten niet in te kunnen gaan op de vraag of de firmwarestoring in de EVA-omgeving alleen een typisch Gronings geval is of dat die ook zou kunnen optreden bij andere klanten. 'Onze eerste prioriteit was om de gemeente Groningen zo snel mogelijk weer in staat te stellen hun diensten aan burgers te vervolgen en herhaling van het probleem te voorkomen. Uiteraard zullen we de kennis die we in het analysetraject op doen over onze producten en de dienstverlening daar omheen, gebruiken waar nodig', aldus een zegsman van HP Nederland.
Tja… de gemeente zou ook 1x in de zoveel tijd zijn eigen systemen kunnen gaan testen ipv blind op de leverancier te vertrouwen. Dat is in de financiele sector vrij normaal
@JanJ: grote woorden. Er staat immers nergens in het artikel ook maar één woord over de testfrequentie bij Groningen.
Maar vertel eens aan ons allen: precies welke testprocedure had dit probleem vooraf aan het licht gebracht?
Euh, banken bedoel je? Oh dat was dus het probleem, testen in productietijd. Dank je voor de opheldering! 🙂
Je kunt nu niet eenmaal alle scenario’s testen.
Op zich ben ik het redelijk eens met JanJ.
Je leverancier blind vertrouwen is nooit goed. Hoe goed hij of zij ook is.
Een uitwijkomgeving moet zo nu en dan getest worden. Tevens dient zo’n omgeving op up te date en gelijk te blijven aan de productie omgeving.
Ik ben zelf meer een voorstander van een active-active setup. Verdeel de load over 2 omgevingen ( 50-50%) en zorg dat ze elkaars backup kunnen zijn. Dit hoeft niet perse realtime te zijn. Ik zou eerder kiezen voor een a-synchrone replicatie. Hier mee voorkom je dat fouten van de ene site direct gerepliceerd worden naar je andere omgeving.
Ik ben mij natuurlijk er van bewust dat hier een bepaald kosten plaatje aan vast zit. En dit betekent altijd enig data-verlies. Echter is dat met de huidige technologie (CDP) zo beperkt mogelijk te houden. Dit data verlies is natuurlijk niet voor iedere type organisatie ( lees banken ) wenselijk.
Hiermee zorg je tevens dat je 2e omgeving up to date blijft aangezien deze actief gebruikt wordt. Ook is de investering voor een 2e omgeving beter te verantwoorden als deze ook actief ingezet wordt. Anders is het in veel gevallen toch een duur betaalde verzekering.
Zolang je de 2e omgeving actief gebruikt is de kans op dit soort escalaties een stuk kleiner.
Vergelijk het met auto’s. Als je je 2e (boodschappen) auto nooit gebruikt en hier nooit onderhoud op laat plegen kan je er natuurlijk nooit vanuit gaan dat deze het ook gaat doen als je hem onverhoopt nodig hebt.
@Ruud Mulder,
Leuk zo’n a-synchrone replica terwijl je primaire site dus neergaat en de sync nog niet heeft plaatsgevonden.
Ik ben blij dat we het allemaal zo goed weten 🙂
Het kan namelijk best zijn dat de fail-over in Groningen gewoon gedegen getest is, echter door een firmware probleem die optrad kunnen er onvoorspelbare dingen wel of niet gebeuren, waaronder dus het uitblijven van de fail-over.
@Ruud:
Peter Wouters geeft aan dat er geen geld is voor zo’n gespiegelde setup. Het zou misschien wel kunnen (in het algemeen), als gemeentes niet ‘om de haverklap’ onnodige nieuwe gemeentehuizen (nutteloze prestigeprojecten) zouden bouwen van 20 miljoen of meer terwijl ze al schulden hebben. Zoals er nu ook een mooi artikel in NRC next staat: vroeger werden schulden van armen kwijtgescholden. Tegenwoordig worden de rijken (bestuur van banken, naar het buitenland verhuisde deriverende speculanten etc.) dan gecompenseerd ten koste van de andere armen. Daarom zou de overheid meer moeten doen om te voorkomen dat mensen schulden aangaan. Maar als zelfs de gemeenten niet het goede voorbeeld kunnen geven in dezen… Tja. Dan houdt ’t eigenlijk wel op.
Welk type EVA met welke firmware ?? Ik ken EVA’s lang genoeg en die gaan niet ‘zomaar’ flippen… er is altijd een externe oorzaak in het spel … maar die zullen we wel nooit te horen krijgen…
Chapeau voor de openheid, dit zie je niet vaak van klanten en hun leverancier. Dit voorkomt speculatie.
Er wordt in sommige reacties gerept over een 2e omgeving, of een uitwijk omgeving. Daarvan is in het oorspronkelijke bericht geen sprake. Een EVA heeft altijd twee controllers, die allebei gebruikt worden. Om precies te zijn, het is een asymetrische active/active storage array. Als één controller uitvalt dan neemt de andere al het werk over. Komt de controller weer bij, dan gaan ze het werk weer verdelen. Dit overnemen van werk neemt in beide gevallen enige tijd in beslag (tientallen seconden). Gaat een controller als een jojo aan/uit verdrag vertonen, dan kan ik mij voorstellen dat de andere controller zodanig in de stress raakt dat hij ook uitvalt, maar dat is speculatie. Er was blijkbaar wel nieuwere firmware voorhanden, want die is geïnstalleerd. Hoeveel versies zaten tussen de oude en de nieuwe firmware? Waarom stond die nieuwe firmware er nog niet op? En bovenal, waarom was er geen tweede EVA die het werk kon overnemen?
En dan kan je het gespiegeld uitvoeren, maar als je een storing hebt als deze, dan weet je niet of die ook optreedt in de gespiegelde omgevingen (en daar dus ook onderuit gaat).