Het belang van de bandbreedte wordt nog steeds niet onderkent bij het ontwerpen van een enterprise infrastructuur. Er worden regelmatig de verkeerde keuzes gemaakt. Als je te laag instapt, heeft dit gevolgen voor de prestatie en de beschikbaarheid. En stap je te hoog in dan betaal je voor iets waar je toch geen gebruik van maakt.
Het ontwerpen van een nieuwe enterprise-infrastructuur is een lastige en tijdrovende klus. Als je er eenmaal mee begint wordt je geconfronteerd met een overvloed aan terminologie en keuzes die je dient te maken. En uiteindelijk zie je hierdoor vaak door de bomen het bos niet meer. Het is daarom van groot belang om vooraf de juiste keuzes te maken. In dit artikel wil ik het hebben over één van de meest ondergeschoven kindjes van een enterprise-infrastructuur: ‘bandbreedte'.
Op het gebied van bandbreedte worden regelmatig de verkeerde keuzes gemaakt. Als je te laag instapt, zal dit gevolgen hebben voor de prestatie en de beschikbaarheid. En stap je te hoog in dan betaal je voor iets waar je toch geen gebruik van maakt. Breng daarom vooraf goed in kaart wat voor soort bandbreedte er nodig is. Ik ga hier uit van twee typen bandbreedte, te weten bandbreedte tussen twee locaties en bandbreedte naar het internet.
Het is van belang om vooraf het verwachte dataverkeer goed in kaart te brengen. Nu weet ik als geen ander dat dit een uitdaging kan zijn. Helaas kunnen we nog steeds niet in een glazen bol kijken en voorspellen wat we daadwerkelijk nodig hebben. Maak daarom zoveel mogelijk gebruik van de best practices die er in de markt op dit gebied zijn. En houdt rekening met de eisen van de leverancier van het platform of de applicatie . Zij hebben vaak meer van dit soort trajecten gedaan en kunnen je voorzien van praktische tips.
Tussen twee locaties
Bandbreedte tussen twee locaties wordt vaak ingezet bij connectiviteit naar de hoofdlocatie en connectiviteit tussen twee locaties/datacenters ten behoeve van disaster recovery. Voor dit scenario is het van belang om vooraf de data goed in kaart brengen en te kwalificeren. Dit is niets meer dan het indelen van de data in een aantal categorieën. Het meest eenvoudig is om in het begin drie categorieën op te stellen. Denk aan brons, zilver en goud. Niet alle data dient namelijk met dezelfde frequentie gerepliceerd of naar de andere locatie verzonden te worden.
Als de randvoorwaarden per categorie zijn vastgelegd kan er gekeken worden naar de welbekende rpo ( recovery point objective ) en rto ( recovery time objective ) discussie. Twee veel gebruikte termen en ook in deze weer van zeer groot belang. De bandbreedte dient namelijk over voldoende capaciteit te beschikken om aan de gestelde rpo en rto te voldoen. Hiervoor is het van belang om de verwachte ‘changerate' per categorie duidelijk te hebben.
Is dit vooraf nog niet duidelijk, werk dan met de best practices die er op dit gebied gelden. Verkeerde keuzes op dit gebied kunnen desastreuze gevolgen hebben als het gaat om prestatie en beschikbaarheid.
Naar het internet
Aangezien cloud een grote hype is verwacht ik dat de uitdagingen op dit vlak alleen maar zullen toenemen. Als je bijvoorbeeld kiest voor een SaaS oplossing dan is het ‘touwtje' er naar toe plotseling heel erg belangrijk. De snelheid, latency en beschikbaarheid zijn factoren om rekening mee te houden. Deze factoren zijn in het eerder geschetste scenario ook erg belangrijk.
Het is daarom van belang om ook hier de juiste keuzes te maken. Op het gebied van SaaS kan de desbetreffende leverancier je vaak al een behoorlijk stuk op weg helpen door middel van best practices.
Maar kijk wel verder dan alleen dat. Deze best-practices bevatten de laatste jaren steeds meer marketinginformatie en niet alle getallen die je daar in kan terug vinden zijn even reëel. Spieken bij organisaties die er al gebruik van maken levert meestal veel concretere informatie op. Door schade en schande is er veel praktijkervaring beschikbaar die zeer nuttig kan zijn.
In nevenstaand schema enkele voorbeelden die ik zelf geregeld gebruik. Ze zijn wat aan de voorzichtige kant, maar schetsen wel een reëel beeld over welke bandbreedte benodigd is voor de connectiviteit tussen twee datacenters/locaties.
Steeds vaker bieden leveranciers op gebied van bandbreedte een ‘burstable' variant aan (flexibel schaalbare variant). Voor regulier dataverkeer heb je over het algemeen niet die 1 GbE verbinding nodig. Deze is alleen nodig in geval van een escalatie. Met deze variant is het wel van belang om vooraf de kosten en sla's duidelijk met de desbetreffende leverancier te bespreken. Buiten de burstable variant kan men er ook voor kiezen om gebruik te maken van ‘wan-optimalisatie'. Deze wan-optimalisatietechnologieën maken gebruik van appliances met daar in een cache. Deze cache wordt ingezet om het dataverkeer te analyseren en daarna te optimaliseren.
Al met al is brandbreedte van groot belang voor de enterprise-omgeving. Maar vergeet in beide gevallen niet de beschikbaarheid. Het eerder genoemde ‘touwtje' kan natuurlijk wel super snel en fancy zijn, maar als het niet hoog redundant uitgevoerd is heb je in het geval van een escalatie nog steeds niets.
IP heeft ICT afstandsonafhankelijk gemaakt, het beheer via IP maakt daarbij de centralisatie van het beheer mogelijk. In ruil daarvoor wordt er een tol betaald en dat zijn de “nukken” van een WAN. Nu is in Nederland elk WAN bijna vergelijkbaar met de performance van een LAN. Dat maakt de opkomst van cloud, hosting en andere ICT-synoniemequivalenten ervan sterk in de aandacht staan. Maar de essentie is, en dat wordt gelukkig goed aangegeven, dat er een doordacht ontwerp nodig is, tegen vooraf vastgestelde criteria.
Beste Maarten,
Je hebt helemaal gelijk dat de WAN-verbindingen in Nederland vaak meer dan afdoende performance bieden. Echter kiezen veel organisaties er voor om juist op dit onderdeel geld te besparen. Verkeerde ( goedkope ) keuzes leiden nog wel eens tot grote problemen. Of wordt er gekozen voor 1 leverancier. En als die partij een probleem heeft ben je als organisatie direct de pineut. Over de beschikbaarheid van de verbindingen dient goed nagedacht worden. Want zonder dat “touwtje” ben je tegenwoordig nergens.
Breng eerst vooraf goed in kaart wat je denkt nodig te hebben. En laat je goed adviseren als dit niet je expertisegebied is. Dit voorkomt veel teleurstelling. En kies waar het kan voor een burstable variant. Hier mee wordt nog genoeg flexibiliteit geboden om later nog naar boven of naar beneden bij te schalen.
Ook voor dit geldt weer dat een goede voorbereiding het halve werk is.
Wat veelal vergeten wordt, is dat de data-infrastructuur het fundament van ICT-toepassingen vormt. Zonder goed fundament is de kans groot dat applicaties niet presteren zoals gewenst en achteraf is dat slecht bij te sturen. Door goed inzicht te krijgen in de huidige behoefte en de te verwachten groei van dataverkeer voor de komende 3-5 jaar, kan een data-infrastructuur op basis van een doordachte architectuur ontworpen worden. Een architectuur maakt het mogelijk te beginnen met een basisbehoefte en door te groeien naar meer bandbreedte, QoS, security, redundancy, enz. Ontwerpen op basis van een architectuur voorkomt dat er bij iedere uitbreiding opnieuw een netwerk neergelegd moet worden of dat het geheel een onbeheer(s)bare lappendeken wordt. De extra inzet en geld om tot een architectuur van het netwerk te komen, verdient zich zeer snel terug. En de ICT-afdeling blust minder brandjes, krijgt meer tijd om ICT-innovaties uit te rollen en kan zijn relevantie voor de organisatie vergroten.
In WAN verbindingen gaat het niet alleen om de bandbreedte, maar ook nadrukkelijk om de doorlooptijden (latency). Het effect van latency kan hel groot zijn afhankelijk van het gehanteerde protocol. Wanneer in de communicatie heel veel berichten heen en weer gaan (chatty karakter) kan een latency van meer dan 20mSec zelfs een onwerkbare situatie opleveren, onafhankelijk van de bandbreedte. niemand zit te wachten op gigabit bandbreedte met wachttijden van minuten.
Beste Rob,
Zeer herkenbaar wat je schrijft. Een goede voorbereiding is het halve werk en levert uiteindelijk alleen maar tijd en geld op. Doe je dit niet dan is de kans op te laag of te hoog instappen groot. Een burstable oplossing kan je ook nog extra flexibiliteit geven. Daar mee kan je eventueel te hoog of te laag instappen afvangen. Echter zijn hier wel altijd kosten mee gemoeid.
Beste Gast,
Latency is zeer belangrijk. Het is handig om vooraf te weten met welke max. latency je platform/infrastructuur kan omgaan. Aan de hand daar van kan je de juiste keuzes maken. En is het risico een stuk kleiner.
Wat simpele hulpmiddelen:
– Bandbreedte behoefte groeit met 50 à 60% per jaar. Dat is een vertienvoudiging in 5 jaar. Absoluut niet te onderschatten dus.
– WAN-optimalisatie technieken, zoals Riverbed of Cisco-WAAS leveren een virtuele bandbreedtegroei op van 150 à 200%, d.w.z. de inzet van dit middel komt overeen met zo’n uitbreiding (er is daarnaast ook winst in latency). Bij secure protocollen (b.v. HTTPS) is die winst een stuk kleiner en ook veel lastiger te bereiken en dat is belangrijk bij de overgang naar SAAS.
– Er zijn goede tools om in de ‘glazen bol’ te kijken en trends zichtbaar te maken. NetQoS bijvoorbeeld. Het vereist wel een degelijke “bemanning” die in staat is de gegevens op de juiste manier te interpreteren anders is het weggegooid geld.
– Naast bandbreedte, latency, beschikbaarheid en jitter is het aantal concurrent sessions een vaak vergeten grootheid. Met name firewalls en WAN-optimalisatie devices lopen daar snel tegen een grens aan. 1 doorsnee gebruiker kan al snel 15 of meer sessions opsouperen.
– Dat Internet goedkoper zou zijn als een private WAN is een mythe. Beide netwerken zijn precies even duur als je de zelfde quality parameters vraagt (beschikbaarheid, bandbreedte, over-subscription etc.). Goedkoper betekent dus gewoon minder kwaliteit.
– Bij bandbreedte speelt doorgaans een Access capaciteit en een Circuit capaciteit. de laatste is snel (denk in dagen) en zonder veel kosten up- of down te graden. Up- of downgrading van de eerste is relatief duur, heeft een lange (denk in maanden) doorlooptijd en is vaak voor minimaal een jaar gecontracteerd. Beginnen met een wat grotere Access kan op termijn geld besparen ondanks de hogere initiele kosten.
@ Rob,
Allereerst bedankt voor je voorbeelden. Ik wil even kort op WAN-optimalisatie in gaan.
Ik ben zelf ook een groot fan van WAN-optimalisatie technologie. In sommige gevallen is dit gewoon een must als er met beperkte bandbreedte gewerkt wordt.
Niet alle data moet tig keer over het lijntje heen en met WAN-optimalisatie dmv caching is hier vaak een grote slag te maken.
Ook voor WAN-optimalisatie geldt weer het bekende kosten en baten verhaal. WAN-optimalisatie begint steeds betaalbaarder te worden, maar nog steeds is en blijft het een flinke investering.