I datacentre opstår der hver dag mange fejl, som på den ene eller anden måde skal afhjælpes.
Som regel kan fejlene afhjælpes, uden at brugerne bemærker noget, men i enkelte tilfælde forplanter små fejl sig til hele datacentret og kan medføre et decideret nedbrud, som det skete den 9. april for IBM.
Fejl er en del af virkeligheden i et datacenter. Erfarne datacenterkonsulenter beskriver her, hvad der kan gå galt, og hvordan katastroferne kan undgås.
Failover er mange ting
Noget af det første, man skal gøre sig klart vedrørende failover, er, at det ikke kun er ét begreb.
I et datacenter er der mange hardware- og softwarekomponenter, der indgår i et kompliceret samspil. Ved at have en – eller flere – kopier af komponenterne i datacentret kan man have såkaldt redundans.
Hvis en komponent fejler, tager kopien over fra den fejlende komponent, og systemet kører videre, uden at brugerne bemærker noget.
Det lyder enkelt, men i realiteten er det en kompleks opgave, da det skal foregå i et komplekst miljø.
“Der indgår mange, mange, mange forskellige komponenter inden for storage, netværk og servere,” siger Josh Krischer, der betragtes som en af de mest indsigtsfulde og erfarne datacenterkonsulenter.
Som research vice president hos analysevirksomheden Gartner specialiserede han sig i en årrække inden for server-, storage- og datacenterteknologi.
Han fremhæver, at failover-mekanismerne skal sørge for at bevare datakonsistens, hvis man foretager failover fra et primært datacenter til et sekundært datacenter.
Fejl er en daglig foreteelse
Netop muligheden for failover mellem datacentre er noget, som IBM’s kunder forventer, og noget som IBM selv fremhæver.
I en Computerworld CTO-artikel fra 2006 beskriver IBM, hvordan højhastighedsfiber forbinder IBM’s datacentre og skaber et virtuelt datacenter:
“Datacentrene er bundet sammen med dark fiber, så de kan betragtes som ét datacenter. En mainframe i Ballerup kan have storage i Ejby; højhastighedsforbindelsen betyder, at den geografiske afstand ikke har nogen betydning. Rent sikkerhedsmæssigt har den geografiske afstand dog betydning, da centrene kan aflaste hinanden i tilfælde af en ulykke som brand eller lignende,” sagde nordic site manager Henrik Melms.
IBM har ikke ønsket at kommentere oplysningerne fra 2006-artiklen yderligere.
Leder af et datacenter, der står bag et højt profileret website, er Amazons CTO Werner Vogels.
“Amazon.com fejler hele tiden. Det kan være fejl i alt fra memory-chips over en server til et helt datacenter. Det er ikke interessant, hvor mange gange der er nedbrud. Det er interessant, hvor lang tid et nedbrud varer. Hvis vi har et udfald på et par sekunder, betyder det ikke så meget, som hvis udfaldet måles i timer. Vi bygger så vidt muligt autonomi ind i vores arkitektur. Enhver komponent skal helst være i stand til at træffe uafhængige beslutninger og må ikke være afhængig af andre,” udtalte Amazons øverste tekniske chef til Computerworld CTO i 2006.
Vigtigheden af konsistens
En tilsvarende åbenhed om de uundgåelige fejl møder man hos Google:
“Komponentfejl er normen, ikke undtagelsen. Vi har set problemer forårsaget af applikationsfejl, operativsystem-fejl, menneskelige fejl og nedbrud i diske, memory, netværk og strømforsyninger. Derfor er konstant overvågning, fejlfinding, fejltolerance og automatisk recovery integreret i systemet,” skriver Google-arkitekterne Sanjay Ghemawat, Howard Gobioff og Shun-Tak Leung i deres whitepaper om Google File System, som er rygraden i Googles søgemaskine-arkitektur.
Skal man foretage failover fra et datacenter til et andet datacenter, er det vigtigt, at man har opdaterede data tilgængelige i det sekundære datacenter.
Det kan ske ved hjælp af replikeringsteknologier som Peer to Peer Remote Copy (PPRC) eller Extended Remote Copy (XRC). Teknologier som IBM har udviklet.
“På recovery-sitet skal man have den rette hardware – servere, SAN og mainframe – som anvendes på det primære site. Samtidigt skal man sørge for at replikere data til recovery-sitet. Her er det vigtigt, at data er konsistente. Hvis data ikke er konsistente, kan det tage meget lang tid at komme sig efter et nedbrud,” siger Josh Krischer.
Med datakonsistens menes, at data på de sekundære diske har alle opdateringer op til et bestemt tidspunkt, og at skrive-sekvensen til de sekundære diske er bevaret.
Såkaldte “rullende katastrofer” kan betyde, at man ikke får alle data med i den rigtige rækkefølge til de sekundære diske.
Ved nedbrud er det nemlig ikke alle primære diske, der stopper på samme tid, ligesom det heller ikke er alle netværksforbindelser, der nødvendigvis går ned på samme tid.
I de fleste tilfælde vil der gå sekunder eller minutter, før systemet er lukket ned, hvilket betyder, at data ikke sendes til recovery-sitet i den korrekte rækkefølge.
“Det er vigtigt, at den rigtige sekvens af disk-kommandoer sendes til de sekundære diske. Hvis det ikke sker, kan data blive ødelagt,” forklarer Josh Krischer.
Skriv det ind i kontrakten
For outsourcing-kunder kan det være en udfordring at sikre sig, at en outsourcing-leverandør reelt leverer den vare, som kunden ønsker.
“Kunder har som regel ikke den tekniske indsigt, så de må tro på, at datacentret gør et professionelt stykke arbejde. Samtidig er viden om disaster recovery ret sjælden. Kunder kan generelt ikke gå ind i de tekniske detaljer. En smart kunde vil derfor tage en tredjepart til at auditere disaster recovery,” siger Josh Krischer, som har fungeret som ekstern revisor af outsourcing-virksomheders infrastruktur.
Her gennemgår han datacenter-arkitekturen og påpeger eventuelle svagheder. Svagheder, som en outsourcing-kunde sammen med en såkaldt business impact-analysis kan anvende til at forhandle en kontrakt med outsourcing-leverandøren.
“Det er vigtigt for enhver organisation at foretage en business impact-analysis. Her vurderes, hvad et nedbrud i it-systemerne betyder for virksomheden. Hvis analysen viser, at det koster en million kroner i timen at være nede, så skal der indarbejdes en passende bod i servicekontrakten, hvis systemet går ned,” anbefaler Josh Krischer.
Carlsberg vil fremover kræve, at IBM ikke kun tester failover via en på forhånd fastlagt fremgangsmåde, men også tester for uventede nedbrud. Det støtter Josh Krischer, som betegner failover-test under kontrollerede forhold som en halv test.
Hvordan testes failover?
Da it-infrastrukturen i et datacenter er kompleks, mener Josh Krischer dog ikke, at man kan foretage en fuldstændig test, der garanterer mod fremtidige nedbrud.
“Hvis nogen siger, at de har bygget disaster recovery, og de har testet, at alting virker perfekt, så vil jeg kalde dem løgnere. Man kan ikke give en 100 procent garanti for, at det virker. Måske er der ændret noget siden sidste test.
Change management- og configuration management-processer er ingen garanti for, at det virker. Hardware virker som regel, problemet er normalt menneskelige fejl,” siger Josh Krischer.
Ifølge Josh Krischer er IBM’s praksis med selv at teste failover almindelig i branchen.
“Normalt er det datacentret selv, der tester failover. Det burde være en ekstern auditør, så det sikres, at datacentret ikke snyder med testen. Hvis der ikke testes disaster recovery mindst en gang om året, så er disaster recovery ikke noget værd,” siger Josh Krischer.
IBM har ikke ønsket at medvirke til denne artikel.
