Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

5-negen beschikbaarheid is noodzaak

Connect the cloud 3

 

Computable Expert

Olav van Doorn
CEO, Custom Connect BV. Expert van Computable voor de topics Mobility en Infrastructuur.

De ketting in datacommunicatie is net zo sterk als de zwakste schakel. Connectivity is een van de belangrijkste schakels, maar wordt nogal eens veronachtzaamd. Hier is het derde deel van een serie blogs over connectivity en enterprise computing. De ontwikkeling van connectivity binnen datacentric computing kent drie maturity fasen, in lijn met it in het algemeen: zelf doen, uitbesteden en als een kant-en-klare service afnemen (cloud).

In mijn vorige blog heb ik het belang van een goede 0-meting (Zero Assessment) uitgelegd om vast te stellen wat de minimaal en maximaal benodigde bandbreedte is en wat de latency-effecten zijn vanuit het perspectief van de gebruikers en van de applicaties.

Aan de hand van de Zero Assessment kunnen keuzes worden gemaakt over de inzet van de bandbreedte. Vaak kiezen bedrijven voor een one-size-fits-all benadering. Dat is eenvoudig en overzichtelijk. Naar mijn stellige overtuiging is het vanuit kostenoogpunt en ook vanuit risk management-beleid veel beter om per applicatie de benodigde bandbreedte in te regelen. Het is gewoonweg niet nodig de bedrijfsbrede connectivity af te stemmen op de piekbelasting van een enkele bedrijfskritische applicatie.

Vijf negens

Hoe groot de beschikbaarheid van de verbindingen moet zijn, hangt af van de benodigde bedrijfszekerheid van de verbinding. We mogen gerust stellen dat in de verbinding tussen datacenters een 5-negen beschikbaarheid noodzakelijk is (99,999 procent uptime). Kiezen voor een dergelijke beschikbaarheid stelt eisen aan het vendor management. Er zijn genoeg connectivity providers die een sla afsluiten op basis van dit getal. In de optiek van veel aanbieders is dat vooral een administratief cijfer, de basis voor een eventueel te betalen boete als deze beschikbaarheid niet wordt gehaald. Maar er ontstaat dan altijd een heilloze discussie: de klant moet aantonen dat de beloofde beschikbaarheid niet is gehaald, de provider zal zich als het even kan beroepen op force majeure (‘zeekabel is kapotgetrokken door ankerend schip, sorry’) en uiteindelijk staat de betaalde boete niet in verhouding tot de door de klant geleden schade.

Een minderheid van de providers doet het anders, deze heeft de infrastructuur zo opgezet dat materieel invulling gegeven kan worden aan de 99,999 procent beschikbaarheid. Deze providers vatten het 5-negen getal op als leidraad bij het bouwen van het netwerk. Dit brengt met zich mee dat elke component in het netwerk dubbel is uitgevoerd.

Als toets om te bepalen tot welk kamp de provider behoort (de administratieve sla of de materiële sla), kunt je de vraag stellen of je de netwerk topologie mag zien. Veel providers zullen niet in staat zijn die aan te leveren vanwege matig beheer of de complexiteit van de oplossing. Als ze zelf niet in beeld hebben hoe het netwerk eruit ziet, hoe kunnen ze jou dan end-to-end redundancy garanderen? En als er een provider is die wel in staat is daadwerkelijk te laten zien hoe het netwerk is opgezet, moet je erop toezien dat hij zich nadrukkelijk committeert aan de gepresenteerde topologie.

In mijn volgende blogs zal ik verder ingaan op de drie fasen van maturity. Stay tuned!

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4993744). © Jaarbeurs IT Media.

?


Lees meer over


Partnerinformatie
 

Reacties

Ja, ik begrijp wat je zegt, nee, ik zou je mijn netwerktopologie ook niet laten zien. Dit om een paar redenen waarvan de grootste gewoon het zakelijke aspect is.

Goh meneer de kok, u kookt fantastisch, maar om er zeker van te zijn dta u geen ingrediënten gebruikt die mijn maag doen omkeren, wil ik eerst even zien waaruit uw gerechten zijn opgebouwd. Niet? Tja jammer dan...

Dat werkt zo niet helemaal en je hebt contracten die dat afdekken.

Herinnert u zich de single point of faillure nog van Vodafone in Rotterdam? Brand bij de buren, geen brandvertragende muur tussen beide panden, geen sprinkler, klaarblijkelijk ook niet eens een duidelijk monitor en waarschuwingssysteem? ( Cam 9.95 en free software die hitte in je pizzadoos weet te meten...dus waar heb je het over?)

We hebben het dan nog even niet over het feit dat dat punt niet redundant was uitgevoerd en dat Vodafone weken nodig had masten handmatig weer op te moeten starten en te connecten. Engineers werden van 'all out of EU' ingevlogen.

Ik weet niet wat schadelijker is. de wetenschap dat Vodafone voor een kleine 6 miljoen extra gewoon in de lucht had kunnen blijven of de verzekerde schade van 22 miljoen. Los even van het gegeven van naam en reputatieschade want je zal als grote 'tokobaas', welke cloudleverancier wil zich niet als zodanig presenteren naar haar of zijn klanten??, maar zo in de publiciteit komen, dat brei je tot in lengte van tijd niet zo 1,2,3 terug.

Hoe het ook zij, als een eigenaar van een datacenter zijn datacenter niet resilliant uit wil voeren, is dat natuurlijk zijn goed recht. Ik zou mijn zaak ook niet schalen naar het idee van mijn klanten. Tenminste, niet qua opzet, hoogstens mijn diensten ietwat aanpassen.

Het contract is alles bepalend en je ziet pas wat een contract werkelijk waard is wanneer er zaken mis gaan. Want laten we wel zijn, ik kan iedereen op papier alles laten zien wat die graag zou willen zien. Dat de werkelijkheid misschien totaal anders is? Ach, dat is nou gewoon ouderwets marketing..... toch?

Goede toevoeging NumoQuest.

Je haalt een paar valide punten aan.

Het contract en de daarbij behorende sla en mogelijke boetes voor het niet halen zijn hier cruciaal.

@Olav
Uiteindelijk is het allemaal statistiek. Redundantie sluit nu eenmaal niet uit dat een fout plaatsvindt. De kans op een fout wordt echter wel kleiner, zodat de aanbieder van de sla minder risico loopt.

Er zijn echter wat kanttekeningen te maken :
- de theorie gaat uit van storingen die onafhankelijk zijn van elkaar. De kans op falen van component B is niet afhankelijk van component A. Dit gaat niet op bij netwerken die bijvoorbeeld zijn voorzien van dezelfde enkele power supply.
- bij toename van het aantal netwerkcomponenten kan de kans op falen weer toe gaan nemen omdat dan de gecombineerde kans op falen van een component de overhand krijgt op de enkelvoudige redundantie. Je hebt in zo'n geval dan ook meer redundantie nodig.

Hier is een artikel met wat meer wiskunde :
http://www.availabilitydigest.com/public_articles/0101/calculating_availability.pdf

Mijn beleving van deze artikelreeks is dat:
(1) - de "prestaties" van een netwerk wordt uitgedrukt in bandbreedte (Zero Assessment)
(2) - de kwaliteit van de netwerk “dienst” gemeten wordt op basis van SLA's over de uptime en oplostijd op het moment dat er een kink in de kabel komt
(3) - dit eventueel vastgelegd wordt in contracten en gekoppeld aan een bonus/malus regeling.

Hoewel bandbreedte, uptime, SLA’s en oplostijden inderdaad belangrijk zijn, ben ik van mening dat een organisatie veel meer baat heeft bij een minimale netwerk vertraging en maximale doorvoersnelheid tussen twee eindpunten (versus de uptime)?
Eventueel gecombineerd met de mogelijkheden rondom alternatieve paden (versus wel/niet halen van de uptime-SLA).
Met name de eerste, de netwerk vertraging, is iets waar een organisatie elke minuut dat een applicatie gebruikt wordt, de vruchten van plukt - positief of negatief…

Terwijl 5 negens beschikbaarheid pas relevant is op het moment dat er een discussie gevoerd moet worden over de mate waarin de contractuele verplichtingen zijn nagekomen.

:-)

Will,

Een organisatie heeft baat bij twee zaken: performance (latency/bandbreedte) en beschikbaarheid (SLA).

De nulmeeting zoals door de schrijver aangehaald is perfect om de juiste keuzes te maken. Alleen wordt daar schaalbaarheid nog wel eens vergeten. Kan ik opschalen en is dit snel en flexibel in te regelen. Dit is de vraag die je vooraf zeker niet moet vergeten te stellen.

Maar de beschikbaarheid is net zo belangrijk. Je kan wel een supersnelle verbinding hebben met veel bandbreedte en weinig latency. Maar als deze niet beschikbaar is, heb je er natuurlijk weinig aan. Het is een beetje kip en het ei discussie.

Kleine toevoeging. Ook is het van belang dat de rest van de ict-Infrastructuurketen voldoet aan de juiste beschikbaarheid.
Vijf negens op netwerk is leuk en vaak cruciaal. Alleen moet je dit natuurlijk wel door vertalen naar de rest van de keten (storage, compute, applications, people).

Het is zoals Ruud al in zijn 2e aanvulling geeft: de hele keten moet kloppen. Wat heb ik aan een 99.999% uptime als ik geen personeel heb dat 24/24 aanwezig is om te monitoren en in te grijpen waar nodig. Wat heb ik aan zulke getallen dat het datacentrum altijd up en running is, maar ik afhankelijk ben van een 3e partij voor het netwerk?

En zo zijn er natuurlijk nog talloze andere voorbeelden te bedenken. Hoe je het ook wendt of keert, de zwakste schakel zal bepalend zijn.

En laten we wel wezen, hoe groot is (met uitzondering van sommige sectoren) de schade nu echt als we even een uurtje niet bij onze spullen kunnen? We zijn met z'n allen zo verslaafd geraakt aan 24 uur per dag mail, internet en social media dat we niet meer denken zonder te kunnen.

@Ruud
Ik zie niet zo waar ons beider reacties verschillen.
Allez - tis te zeggen - ik heb het nog nooit meegemaakt dat een netwerk bloedsnel is en tegelijk toch niet beschikbaar... als jij die ervaring wel hebt ben ik benieuwd hoe zoiets in de praktijk eruit kan zien... ;-)

On topic: Het gaat mij vooral om de volgorde ter dingen.
De SLA’s op beschikbaarheid en oplostijd is iets wat achteraf bepaald wordt. Toch lijken deze elementen de meeste aandacht te krijgen bij contract besprekingen e.d. - voelt een beetje als mosterd na de maaltijd.

Het aspect performance komt pas veel later aan bod - als het al aan bod komt. Terwijl de impact eigenlijk veel groter is omdat dit een blijvende factor is waar iedereen elke minuut van de (werk)dag de vruchten van plukt. Waarom dit niet op de eerste plaats gezet? Of toch op zijn minst gelijk gesteld aan het aspect SLA en beschikbaarheid.

En tot slot - in reactie op je "kleine toevoeging":
Als het gaat om de gehele keten, dan wordt het een heel ander verhaal. Wil je die vangen in eenvoudige, meetbare KPI’s (SLA's?), dan ken ik eigenlijk maar één goed referentie kader. En dat zijn de dingen die zich afspelen op het scherm van een gebruiker!
Even los van de technische aspecten van een dergelijke meting - wat het dan weer lastig maakt is het terugvertalen naar afgeleiden voor de verschillende domeinen zijnde (bijvoorbeeld) netwerk, servers, applicatie(s) en storage. Vrij vertaald - als een gebruiker X seconden moet wachten op het antwoord van een actie, hoeveel tijd gaat er dan verloren in elk van die domeinen? Oftewel, als ik daar iets aan wil verbeteren, in welk beheer domein valt dan de meeste tijdswinst te boeken?

Okay, het netwerk is belangrijk en je wilt daar enige garanties over hebben maar de aangehaalde 'force majeur' laat al zien dat er nog wel wat ontsnappingsclausules in SLA zitten. En 99,999% beschikbaarheid is uiteindelijk nog steeds 6 seconden downtime per week wat een enorme impact kan hebben op de end-to-end service. Maar dat alles wordt al aangehaald in reacties waarbij ik net als PaVaKe ook een blinde vlek aangaande SLA constateer omdat we afhankelijk worden van dingen waarover geen controle meer is.

Nu lees ik ook meetbare KPI's en SLA's en dan denk ik aan al die processen die volledig aan het zicht van de gebruiker onttrokken in datacentra plaats vinden zoals allerlei batch processen. Sorry Will, maar end-point gebruiker klinkt me als incident management in de oren wat dus 99,999% reactief is. Maar eigenlijk verwoorde NumoQuest dat al subliem met het meten van de hitte in je pizzadoos, it's all about event monitoring!

Een anekdote:
Een klant had keurig netjes SLM aan de bovenkant ingericht door met een interval van een uur (3600 seconden) de service te pollen. Dashboard stond dus op groen toen netwerk er 1 seconde uitlag en er 1600 transacties faalden. Servicedesk kreeg verschillende incidenten maar hoewel al deze 'missers' keurig door systeem gelogd waren keek niemand hier naar en werden alle incidenten na een paar testen als opgelost gesloten.

Na halfjaar escaleerde dit en werd eindelijk eens wat dieper gekeken toen duidelijk werd dat de KPI's die gemeten werden eigenlijk nietszeggend waren. Toen de logs gecorreleerd werden bleek de loadbalancer zich te verslikken als een bepaalde batch ingeschoten werd waardoor alle klanten een verstoringen constateerden welke SLM telkens miste.

Die loadbalancer was trouwens keurig gesized op een gemiddelde belasting, het breekpunt was nooit bepaald omdat capaciteitstesten van keten niet meer uitgevoerd worden. Bij event monitoring gaat het om 'Management by Exception' waarbij routes omgelegd worden voordat het tot incidenten leidt. Dat kan in milliseconden waardoor je met 99,999% beschikbaarheid dus 6000 correctieve acties per week kunt nemen om niet alleen aan SLA te voldoen maar ook de gebruikerservaring te verbeteren.

Where to put your money?

Als klant krijg je in deze waar je voor betaalt, niet wat er in de SLA staat want dat is en blijft een intentieverklaring.

@ Will,

Ik blijf het apart vinden dat je performance belangrijker vindt dan beschikbaarheid. Ik maak daar zelf geen onderscheid in. Maar ik refereer altijd naar bedrijfskritische omgevingen.

Aan een redundant uitgevoerde verbinding die niet voor uit te branden is heb je niets. En aan een super snelle verbinding die steeds op zijn gat ligt idem dito. Het is dus zo als ik al eerder zei een kip en het ei discussie.

Over bandbreedte heb ik in het verleden al eens wat geroepen:

http://www.computable.nl/artikel/opinie/cloud_computing/4463114/2333364/bandbreedte-nog-te-vaak-ondergeschoven-kindje.html

Ik kies altijd vanuit de SLA ( mits beschikbaar) de juiste technologie er bij. Uit een goede SLA zijn vaak ook de eisen qua performance, RPO en RTO te halen. Vandaar uit maak ik de technologie keuzes. Als je dit pas aan het einde tijdens de contractbesprekingen doet, dan ben je in mijn optiek niet slim bezig. Dit levert gegarandeerd teleurstelling en vaak ook nog eens een hogere prijs op.

@ Ruud
De achtergrond van mijn redenering zat enigszins verborgen in de passage:
"Allez - tis te zeggen - ik heb het nog nooit meegemaakt dat een netwerk bloedsnel is en tegelijk toch niet beschikbaar..."

Was eigenlijk bedoeld als een indirecte boodschap voor een uitgangspunt als: een netwerk met een vertraging van (bijvoorbeeld!) meer dan 100 ms equals "niet beschikbaar".

Laat je gedachte eens gaan over de volgende (voorbeeld-)SLA: de snelheid van het netwerk dient in 99,99% van de gevallen 100 ms of beter te zijn => uitval van een verbinding staat gelijk aan een vertraging van meer dan 100 ms.

:-)

@ Ewout
Wel bijzonder dat termen als SLA’s en KPI’s vrijwel altijd geïnterpreteerd worden als iets wat hoort bij processen. Om vervolgens gekwalificeerd te worden tot een vorm van re-actief zijn.
Waarom eigenlijk? Die termen zijn toch ook valide voor technische, infrastructurele & applicatieve parameters?

Misschien wat zwart/wit - maar toch - een van de wetmatigheden van IT beheer is dat wat je ook doet, het is per definitie re-actief! In het beste geval kun je iets van een early-warning systematiek in regelen op grond waarvan ingegrepen kan worden voordat het helemaal mis gaat.

Tot slot je anekdote: ik begrijp niet goed wat voor punt je hier probeert te maken. Anders dan een bevestiging van het concept “garbage-in-garbage-out”... ;-)
Als er geen capaciteitstesten uitgevoerd worden om te bepalen waar het breekpunt ligt, dan gaat event monitoring en management-by-exception ook niet helpen. Er is immers geen norm (een SLA?!) vastgesteld voor de maximale verwerkingscapaciteit van een keten. Met als logisch gevolg dat er maar één soort exception/event is: de zwakste schakel in de keten zegt “krak”!

:-)

@Will
Beheer is inderdaad uiteindelijk reactief, ook bij event management. Verschil zit echter in 'warning system' omdat een incident meestal het signaal vanuit de gebruiker is terwijl een event een signaal vanuit het systeem is. De tijdsfactor is hier van grote impact zoals ik al stelde in mijn reactie.

Verder stelde ik al dat je een capaciteitstest moet doen om te weten waar breekpunt ligt, wanneer moet je bijschalen of switchen is echter niet altijd op de juiste manier bepaald. Betreffende SLA (norm) heb je inderdaad gelijk maar daar heb ik al eens wat over geschreven naar aanleiding van ervaringen uit het veld. En naast een tekort aan resources komt ook het tegenovergestelde nog vaak voor doordat alles gewoon dubbel of nog vaker uitgevoerd word. En ondanks dat zit er vaak toch nog SPoF in de keten want betreffende SLA's en KPI's is vaak de 'value chain' niet bekend maar dat was mijn cliffhanger, where to put your money?

Aangaande de anekdote was er bij ontwerp nooit rekening gehouden met ongewenst gedrag vanuit de gebruikerskant met batch belastingen, zat er nog wat fout in de applicatie en werd duidelijk dat SLM systeem meer miste dan constateerde. Hetzelfde zie je nog weleens als er iets 'viral' gaat waardoor een enorm piek voor downtime zorgt. En schaalbare infrastructuur in combinatie met uiteindelijk statische applicaties is gewoon een verspilling van geld, de ToC gaat hier nog weleens op omdat als het netwerk sneller wordt de bottleneck dus gewoon verschuift.

P.S.
Dit is trouwens ook weer zo'n expert die nergens op reageert, hopelijk wel op incidenten maar je vreest het ergste;-)

Ik zie hier weer een klassiek voorbeeld van conventioneel denken. Alles dubbel (redundant) uitvoeren, 5 negens beschikbaarheid, SLA's met providers, boete clausules, etc...

Heel veel netwerk apparatuur moet nog rebooten na een update en bij sommige updates moeten alle apparaten die zijn aangesloten in een keer worden opgewaardeerd. Daar zit je dan met je dubbel uitgevoerde netwerk, moeten beide componenten in een keer door het donker.
Ook zie je dat men apparatuur dubbel uitvoert op 1 lokatie, het datacenter. Wel redundant stroomvoorzieningen, maar wel van 1 stroomprovider. 1 storing bij de nutsprovider en je bent alsnog weg.
Datacenter moet je zo ontwerpen dat bij uitval van een deel van de voorzieningen het geheel blijft doorwerken, misschien zelfs op halve capaciteit. Redundantie alleen waar het moet op basis van risico analyses. Verder meerdere Netwerkproviders met geografische gescheiden verbindingen, waarbij mogelijkheden om per provider de bandbreedte op te schalen binnen 24 uur bij ernstige calamiteiten.
En natuurlijk kan je ook nadenken over de cloud als back-up. Bij uitval van verbindingen is het datacenter niet meer bruikbaar, maar je ontsluit de applicaties vervolgens via een andere provider in de cloud.
Nieuw tijden, nieuwe mogelijkheden, lagere kosten.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×