Elke werkdag behandelt Computable een onderwerp waarover lezers kunnen discussiëren. Vandaag over het fenomeen downtime; ongepland en gepland.
Het tijdelijk niet beschikbaar zijn van systemen, services en functies is een fenomeen dat zo oud is als de ict zelf. Downtime wordt door velen geassocieerd met storingen, maar dat is ‘slechts’ ongeplande downtime. Daarnaast bestaat er ook nog het moedwillig, met voorbedachte rade uitschakelen van systemen: geplande downtime. Bijvoorbeeld voor updates, migraties en andere vormen van noodzakelijk ict-onderhoud. Downtime is dus onvermijdelijk. Wat vind jij?
Onvermijdelijk –> nee, er kan altijd iets gebeuren (of een samenloop van omstandigheden) waar je geen rekening mee gehouden had.
Tot een minimum beperken –> ja, maar je moet dan wel bereid zijn te investeren in redundantie
Is onvermijdelijk.
De combinaties van hard- en software die ingezet is, al dan niet in de vorm van redundantie, maakt dat eigenlijk niemand meer precies weet hoe het nou werkt. Als er dan iets “krak” zegt, dan gaat er veel tijd verloren omdat eerst achterhaald moet worden “hoe het ook alweer zat”.
Knuppel en hoenderhok en zo: de *kleinst* mogelijke downtime (gepland of ongepland) krijg je als je de hoeveelheid redundantie tot een minimum weet te beperken!
Downtime is zeker te voorkomen. Maar het is niet gratis. Vaak zijn de kosten van planning en voorbereiding die nodig zijn voor downtime-loos upgraden vele malen groter dan gepland 30 minuten op zwart op een rustig moment van de dag.
In de traditionele wereld is het normaal dat een SAP systeem in een ziekenhuis een halve dag downtime heeft voor een upgrade.
In de nieuwe digitale wereld bij bedrijven als Github, Stack Exchange, Evernote, etc. die vaak ook een complex landschap hebben, is er vaak geen of bijna geen downtime bij een upgrade.
Mooi topic voor een volgend onderwerp: Waar zit het verschil dan in?
Downtime van een server is niet te voorkomen maar hier hoeft de gebruiker niets van te merken. Van een redundant configuratie zoals mainframes al in de jaren 70 tot hardware clustering en later virtualisatie maken het mogelijk zowel storingen van componenten zonder downtime te verhelpen en automatische migraties van omgevingen voor reparaties of upgrades uit te voeren. Hoge of zelfs continue beschikbaarheid d.m.v. applicatie clustering is mogelijk. Beschikbaarheid (en dus Downtime) is vandaag een keuze en de vraag is op welke niveau je dit wilt invoeren en tot hoever je wilt gaan tegen welke kosten. Ieder voordeel heeft zijn nadeel en er is niet een eenvoudige oplossing voor alles.
Ik vind dat het er maar aan ligt wat je downtime noemt.
Even over mezelf opscheppen: Ik ben Site Reliability Engineer bij Google; mijn team (in Zurich, San Bruno en Mountain View) is hoofdverantwoordelijk voor de beschikbaarheid van YouTube en aanverwante systemen.
Bij Google/Youtube hebben we de zaak wel aardig voor elkaar, al zeg ik het zelf, maar zelfs wij hebben als doelstelling niet 100% beschikbaarheid, maar iets van 99.995% of zo. Bij dat soort getallen wordt het heel belangrijk dat je precies definieert wat “downtime” nu precies is.
Bij een groot/gedistribueerd systeem als YouTube komt het eigenlijk niet voor dat niemand in de wereld YouTube kan bereiken. Door de service in meerdere datacenters aan te bieden en met wat slim geoDNSsen en doordacht BGP route-injecten kun je er voor zorgen dat de verzoeken naar een datacenter gaan waar de applicatie in redelijk goede gezondheid is.
Echter, ondanks het feit dat we tienduizenden van alles hebben (CPUs, hard disks, netwerkkaarten, noem maar op) komt het wel eens voor dat er onderdelen van de site niet naar behoren werken. Soms komt dat omdat onze zelfreparerende systemen wel eens een paar minuten nodig hebben om zichzelf weer uit het moeras te trekken, een andere keer omdat er wat handmatig reddingswerk nodig is en de oncall engineer net even onder de douche staat.
Ook komt het zelf bij ons voor dat we eens wat onderhoud moeten plegen waarbij we de database even read-only moeten maken. Je kan dan nog steeds files uploaden, videos kijken, zoeken, en dergelijke, maar geen video titels aanpassen of playlists maken; die acties zijn ofwel onmogelijk (knopje weg op het scherm) of geven een foutmelding.
Echter zelfs onder de hierboven genoemde omstandigheden gaan 99.999% van alle requests wereldwijd nog steeds goed. Dat heb je dan met genoeg slimme redundantie en distributie. Zijn dergelijke voorvallen dan nog onder “downtime” te scharen? Dat is uiteindelijk een definitiekwestie, mag je zelf kiezen. Wij hebben daar een of andere formule voor en daar leven we dan naar.
Dat betekent overigens ook dat we onze uptime kunnen verbeteren door een andere formule te kiezen, maar dat is natuurlijk vals spelen…. 🙂
Met de traditionele computer gesturude telefoniesystemen was de downtijd garantie aan PTT mx 3 min per jaar (dat was inclusief alle patches, software upgrades, etc. Daarvoor was alles dubbel uitgevoerd, en de disks zelfs 4 maal. Er was nergens in het systeem een single point of failure. Dat is natuurlijk wel duur.
In de huidige distributed systems is een grote betrouwbaarheid goed te bereiken (moet je wel zorgen voor een dubbel netwerk, wat dan ook nergens in dezelfde stoep ligt).
De zorgen ontstaan pas in de software betrouwbaarheid. Als dezelfde softwarefout naar alle nodes wordt gedistribueerd zal de fout overal optreden! De kwaliteit van de SW wordt dan bepalend. Een goede downwards compatibility in combinatie met een gecontroleerde vertraagde uitrol kan daar ook extra zekerheid inbouwen.
Downtijd zou theoretisch voorkomen kunnen worden, maar dat kost wel geld!
Downtime zal best te voorkomen zijn, maar dan heb je te maken met de 80/20 regel, de laatste paar procentjes kosten buiten proportioneel veel werk.
Het is beter om gewoon te leren omgaan met een (acceptabele hoeveelheid) downtime op een gecontroleerde wijze.
Downtime door catastrofes of majeure incidenten is niet te voorkomen. Voor het overige wel, of doorn dit op te lossen in het ontwerp, dat kan omgaan met fouten of door er vreselijk veel geld tegen aan te gooiren. Het ligt er maar aan hoe belangrijk je het vindt.
Voor sommige diensten is ongeplanddowntime onaanvaardbaar. Denk aan geldautomaten en betaalautomaten. In veel gevallen zijn deze gehost door een Tandem Non-stop server. Deze is zodanig gebouwd dat je op de ene instantie het operatingsysteem kunt upgraden en vervolgens de ander. Beide systemen staan elkaar voortdurend te monitoren. Indien nodig nemen ze elkaar over. Dit was het beste fault tolerance systeem tot nu toe. Nu is dit deze technologie bij IBM HP te koop.