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!
@ 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:
https://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.