Wat een DR fail van Hitachi en NSE

hitachiOp 24 februari van dit jaar moest de NSE de handel staken omdat de IT, specifiek die van Hitachi, uitviel. Gedurende vier uur was de grootste beurs van India en op basis van volume een van de vijf grootste handelsplatformen ter wereld onbereikbaar.

Disaster Recovery zou moeten werken

Al snel was duidelijk dat de data storage clusters een belangrijke rol moesten hebben gespeeld. De NSE slaat de data uiteraard niet op een plek op. De primaire locatie is “de beursvloer”, vandaar worden zo goed als real time kopieën gemaakt op een secundaire locatie. Tussen die twee fysiek gescheiden locaties loopt glasvezel.

Op papier zou op die manier de bedrijfscontinuïteit geregeld moeten zijn en daarmee zou disaster recovery geen issue mogen zijn. Maar dat bleek dus een illusie te zijn.

Hitachi onder de loep

In eerste instantie is na het incident gekeken naar de hardware en software van Hitachi. Dat bedrijf voorziet de NSE van alle benodigde IT. Al snel leek de oorzaak een software bug te zijn. Op het moment dat een index van fondsen moest worden vastgesteld liep de software vast. De data kon niet worden weggeschreven naar de SAN. Dat blokkeerde vervolgens alle andere lees en schrijf acties van dat cluster.

Bij het uitvallen van een SAN moet volgens de DR regels het tweede externe cluster de primaire worden. Dat lukte niet, want het externe datacenter was onbereikbaar. Formeel heet het dat graafwerkzaamheden in de buurt de glasvezel verstoorden.

Het kan een bijzondere samenloop van omstandigheden zijn geweest waarbij twee incidenten tegelijk plaatsvonden. Maar dat maakt het probleem voor Hitachi en NSE alleen maar erger. Want elk DR scenario had hier rekening mee moeten houden. Zelfs zonder Chaos Monkey kan iedereen een vergelijkbaar voorval verzinnen en testen.

NSE wijst nadrukkelijk naar Hitachi als de schuldige:

“The Problem was caused by failover logic implemented by the vendor which did not conform to NSE’s stated design requirements, coupled with issues in the configuration done by the SAN vendor that triggered the failover logic. We note that the specific failure logic used by the vendor is not documented, was not communicated to the NSE, and was not appropriate for NSE’s setup.”

Blijft echter staan dat NSE duidelijk de architectuur niet heeft gecontroleerd. Iets simpels als het ontbreken van een dubbel en gescheiden glasvezel route had direct moeten opvallen. Een DR fail van deze omvang is daarbij niet eens zo uniek. Het komt alleen minder vaak voor dat het de pers haalt.

Share:

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.