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!
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.