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.


This entry was posted on Zondag 03 September 2006

Earlier articles

Quantum computing

My Book

Security bij cloudproviders wordt niet beter door overheidsregulering

Passend Europees cloudinitiatief nog ver weg

Data Nederlandse studenten in cloud niet grootschalig toegankelijk voor bedrijven VS

VS kan nog steeds Europese data Microsoft opeisen ondanks nieuwe regels

The cloud is as insecure as its configuration

Infrastructure as code

DevOps for infrastructure

Infrastructure as a Service (IaaS)

(Hyper) Converged Infrastructure

Object storage

Software Defined Networking (SDN) and Network Function Virtualization (NFV)

Software Defined Storage (SDS)

What's the point of using Docker containers?

Identity and Access Management

Using user profiles to determine infrastructure load

Public wireless networks

Supercomputer architecture

Desktop virtualization

Stakeholder management

x86 platform architecture

Midrange systems architecture

Mainframe Architecture

Software Defined Data Center - SDDC

The Virtualization Model

What are concurrent users?

Performance and availability monitoring in levels

UX/UI has no business rules

Technical debt: a time related issue

Solution shaping workshops

Architecture life cycle

Project managers and architects

Using ArchiMate for describing infrastructures

Kruchten’s 4+1 views for solution architecture

The SEI stack of solution architecture frameworks

TOGAF and infrastructure architecture

The Zachman framework

An introduction to architecture frameworks

How to handle a Distributed Denial of Service (DDoS) attack

Architecture Principles

Views and viewpoints explained

Stakeholders and their concerns

Skills of a solution architect architect

Solution architects versus enterprise architects

Definition of IT Architecture

What is Big Data?

How to make your IT "Greener"

What is Cloud computing and IaaS?

Purchasing of IT infrastructure technologies and services

IDS/IPS systems

IP Protocol (IPv4) classes and subnets

Introduction to Bring Your Own Device (BYOD)

IT Infrastructure Architecture model

Fire prevention in the datacenter

Where to build your datacenter

Availability - Fall-back, hot site, warm site

Reliabilty of infrastructure components

Human factors in availability of systems

Business Continuity Management (BCM) and Disaster Recovery Plan (DRP)

Performance - Design for use

Performance concepts - Load balancing

Performance concepts - Scaling

Performance concept - Caching

Perceived performance

Ethical hacking

Computer crime

Introduction to Cryptography

Introduction to Risk management

The history of UNIX and Linux

The history of Microsoft Windows

Engelse woorden in het Nederlands

Infosecurity beurs 2010

The history of Storage

The history of Networking

The first computers

Cloud: waar staat mijn data?

Tips voor het behalen van uw ITAC / Open CA certificaat

Ervaringen met het bestuderen van TOGAF

De beveiliging van uw data in de cloud

Proof of concept

Een consistente back-up? Nergens voor nodig.

Measuring Enterprise Architecture Maturity

The Long Tail

Open group ITAC /Open CA Certification

Human factors in security

Google outage

SAS 70

De Mythe van de Man-Maand

TOGAF 9 - wat is veranderd?

Landelijk Architectuur Congres LAC 2008

InfoSecurity beurs 2008

Spam is big business

De zeven eigenschappen van effectief leiderschap

Een ontmoeting met John Zachman

Persoonlijk Informatie Eigendom

Archivering data - more than backup

Sjaak Laan


Recommended links

Genootschap voor Informatie Architecten
Ruth Malan
Gaudi site
XR Magazine
Esther Barthel's site on virtualization
Eltjo Poort's site on architecture


Feeds

 
XML: RSS Feed 
XML: Atom Feed 


Disclaimer

The postings on this site are my opinions and do not necessarily represent CGI’s strategies, views or opinions.

 

Copyright Sjaak Laan