« Het nut van USB stick… | Home | Wat Vista belooft en … »

99,999% beschikbaarheid

Ik hoor regelmatig de vreemdste cijfers als het om beschikbaarheideisen gaat.

Voor nieuwe systemen wordt vaak maar wat geroepen: "Het systeem moet 95% van de tijd beschikbaar zijn" of "Het systeem mag nooit uitvallen" of "Wij nemen alleen genoegen met 99,999% uptime (5 negens)". Vaak zijn deze cijfers niet onderbouwd of heeft men geen idee hoeveel het kost om een bepaalde beschikbaarheid te behalen.

Voor de duidelijkheid: Alle hardware gaat eens kapot. Het is niet de vraag OF iets kapot gaat, maar WANNEER iets kapot gaat.

Even wat rekenvoorbeelden:

Er zitten 24*365=8760 uren in een jaar. 1% hiervan is 87,6 uur. Een systeem met een beschikbaarheid van 95% mag dus ongepland 438 uur onbeschikbaar zijn. Dit is 18 volle dagen per jaar!

Het andere uiterste is 99,999%, hierbij mag een systeem slechts 5 minuten per jaar uitvallen (en dat is dus inclusief de reparatie van een eventuele storing!). Een beschikbaarheid van 5 negens is een populair getal de laatste jaren.

Berekenen van de beschikbaarheid

Beschikbaarheid kan worden berekend door de MTBF te vermenigvuldigen met de MTTR.

MTBF

Voor hardware wordt vaak een MTBF afgegeven (Mean Time Between Failures). Een Seagate Cheetah harddisk heeft bijvoorbeeld een MTBF van 1.200.000 uur. Dit betekent dat gemiddeld het apparaat eens per 136 jaar uitvalt. Een systeem bestaat echter uit vele hardwarecomponenten, die elk een MTBF hebben. Stelt u zich een schijvencabinet voor met 64 schijven voor (dit is geen uitzonderlijk groot schijvencabinet voor een SAN). Dan gaat er gemiddeld elke 2 jaar een disk kapot.

Hoewel disken de componenten zijn die de meeste kans hebben om uit te vallen (ze bevatten veel bewegende delen, die aan slijtage onderhevig zijn), hebben alle andere componenten van een systeem ook een MTBF. Denk bijvoorbeeld aan servers (ventilatoren in voedingen), routers, switches en zelfs bekabeling.

De MTBF is vaak een marketing instrument. Hoe kan Seagate bijvoorbeeld aantonen dat haar schijven er inderdaad 136 jaar over doen om defect te raken?

MTTR

Behalve MTBF kennen we ook MTTR; Mean Time To Repair. Dit is de tijd die nodig is om bij uitval het component te repareren of te vervangen. Vaak wordt de MTTR laag gehouden door een service contract af te sluiten met de leverancier van de hardware of door reserve hardware vooraf aan te schaffen. Goede afspraken met leveranciers kunnen een goede MTTR garanderen. U wilt tenslotte niet in de situatie geraken dat een component dat na 5 jaar uitvalt, niet meer leverbaar blijkt te zijn...

Software

Buiten hardware bestaat een systeem ook uit software. Voor de MTBF en de MTTR van software zijn over het algemeen geen waarden te berekenen. Er zal geen programmeur zijn die een MTBF wil afgeven van de door hem geschreven software. Wat is de MTBF van Windows? En van Linux? Van SAP? Van uw maatwerksoftware?

Het menselijk aspect

Uitval wordt slechts in 20% van de gevallen veroorzaakt door technisch falen. In 80% van de gevallen betreft het menselijke fouten. Een beheerder trekt ergens per ongeluk een verkeerde kabel uit, of geeft een foutief commando. Uiteraard helpt het om goed gekwalificeerde en goed opgeleide systeembeheerders te hebben, die een gezond verantwoordelijkheidsgevoel hebben. Fouten maken is echter menselijk, en er is geen MTBF of MTTR voor te berekenen.

Conclusie

Uit bovenstaande kan worden afgeleid dat beschikbaarheidcijfers van een systeem vooraf niet zijn te garanderen. MTBF en MTTR zijn vaak onbekend, niet te berekenen of overdreven.

Beschikbaarheid kan alleen achteraf worden bepaald, als een systeem enkele jaren heeft gedraaid. Met deze kennis achteraf kunnen toekomstige systemen worden ontwikkeld die waarschijnlijk een hogere beschikbaarheid hebben.

Uiteraard is de afgelopen jaren veel kennis opgebouwd over hoe men hoogbeschikbare systemen moet bouwen, bijvoorbeeld door het toepassen van clustering, failover, redundancy, gestructureerd programmeren, het voorkomen van Single Points of Failures (SPOF's) en het opzetten van goed beheer.

De IT architect (en eventueel de security architect) dient aandacht aan beschikbaarheid te besteden. Omdat de kosten voor beschikbaarheid enorm kunnen oplopen is een goede afstemming tussen techniek en de business door de IT architect enorm belangrijk.

Er zijn three reacties, klik hier om uw mening te geven:

Is er ook een standaard voor het berekenen van uptime tijdens werktijd?
Michel Laan () (URL) - 12 09 06 - 13:22

Waarom is het eigenlijk niet gebruikelijker om verschillende uptime percentages te stellen voor werktijd en niet werktijd? Het reguliere onderhoud valt onder downtime, maar als dat buiten werktijd plaats kan vinden, is het minder belastend voor de organisatie. Het is een beetje onzin om een groot probleem te maken als er geen eindgebruikers aan het werk zijn en het systeem is een paar uur niet beschikbaar. Als dat gebeurt tijdens werktijd en er zijn honderd mensen die niet kunnen werken, is dat wel een probleem.
Michel Laan - 04 10 06 - 10:07

Dat klopt, als het om interactieve applicaties gaat.
Als het om webservices gaat, of om een internationaal bedrijf, dan is het al snel nodig 24/7 uptime te hebben.
Sjaak - 05 10 06 - 11:30