Klanten die door een netwerkstoring niet bij hun data en applicaties kunnen en de eigen infrastructuur die plat ligt: het is het schrikbeeld van veel hosters, cloud service providers en andere digitale dienstverleners. Redundantie staat daarom hoog op de agenda bij alle grootverbruikers van datacenter connectiviteit. Het is te risicovol om te vertrouwen op een enkele verbinding, zowel binnen de eigen infrastructuur als voor de dienstverlening naar klanten.
Toch is het niet altijd duidelijk hoe leveranciers redundantie aanbieden. Hoe redundant is redundant eigenlijk? Als het om connectiviteit gaat, zijn de verbindingen van locatie tot locatie dubbel uitgevoerd, tot in het datacenter. Maar het is belangrijk om te weten welke elementen in het netwerk ook redundant zijn uitgevoerd. Ook is de garantie dat er aan de achterkant toch geen infrastructuur gedeeld wordt belangrijk. Dit is zeker nog geen algemene praktijk. Wat ons betreft is het dan ook tijd om redundante connectiviteit slimmer uit te voeren en naar een hoger niveau te tillen.
Voorbereiden op het onvoorziene
De meeste (in naam) redundante verbindingen bestaan uit twee gescheiden glasvezels of kanalen die beide van A naar B gaan. Dit wordt vaak in de vorm van een kale glasvezel of wavelength ingekocht. De verbinding op deze niveaus inkopen roept de verwachting op om ook over de hoogste mate van controle te kunnen beschikken. In de praktijk is dit echter niet altijd zo en het is de vraag of dit de slimste manier is om redundantie te creëren.
Om dit te begrijpen moet we eerst inzoomen op de risico’s qua redundantie. Met name bij inhuur van wavelengths zien wij een verhoogd risico op ‘papieren redundantie’. Men huurt vaak in bij twee verschillende providers en deze kunnen gelijktijdig in onderhoud gaan of tegen een storing aanlopen, soms zelfs door dezelfde oorzaak. In theorie lijkt dit onwaarschijnlijk, maar er zijn duidelijke redenen dat dit regelmatig voorkomt.
Er zijn veel verschillende aanbieders van wavelength diensten, maar deze maken allemaal gebruik van een beperkt aantal glasvezelnetwerken (inhuur van dezelfde routes). Daardoor hebben verschillende aanbieders vaak te maken met onderhoud van hetzelfde netwerk. Daarnaast ontstaan er storingen aan verschillende netwerken omdat vezels vaak in dezelfde sleuf of mantelbuis liggen, of dezelfde route volgen. De vraag is of redundantie door twee aanbieders te selecteren wel leidt tot hogere zekerheid. Is 1 aanbieder niet beter? 1 aanbieder kan in ieder geval garanderen dat 2 redundante routes niet tegelijk in onderhoud zijn.
Daarnaast bestaan er risico’s in de datacenters, bijvoorbeeld in de netwerkapparatuur of de patch, door eigen toedoen of door iemand anders. Ook hier is het dus belangrijk om te weten hoe in het datacenter omgesprongen wordt met redundantie. En is het mogelijk om meerdere datacenters redundantie ten opzichte van elkaar te laten bieden?
Tot slot kan (gepland) onderhoud uitlopen, waardoor onvoorzien downtime moet worden geïncasseerd. We kunnen doen alsof dit bijna nooit voorkomt, maar uit de praktijk weten we dat ook onbedoeld fouten worden gemaakt of dat netwerkapparatuur het soms laat afweten.
Weg met de single points of failure
Kortom: zolang er single points of failure in de netwerkarchitectuur aanwezig zijn, is downtime door storingen of outages een reële mogelijkheid. Dit kan alleen ondervangen worden door de juiste fallback mogelijkheden in het netwerk in te bouwen en controle te hebben over de fysieke infrastructuur en apparatuur.
Werkelijk redundante connectiviteit is daarom standaard volledig end-to-end uitgevoerd. Fysieke verbindingen zijn geografisch gescheiden en er is volledig inzichtelijk welke routes worden gebruikt, wanneer deze te maken hebben met een storing en wanneer deze in onderhoud gaan. Latencies mogen maar beperkt van elkaar afwijken. Alle apparatuur is dubbel uitgevoerd, óók de entry points en patches in datacenters zijn redundant.
Idealiter is het hele netwerk ontworpen met volledige redundantie als uitgangspunt. Het netwerk is zo simpel en eenduidig mogelijk opgebouwd. Er is meer inzicht in de risico’s en bij storingen zijn er minder mogelijke oorzaken. Als het design vanaf het begin zo gemaakt is kan end-to-end redundante connectiviteit efficiënt worden aangeboden en is dit ook met kleinere budgetten een reële optie.
Technieken als Software Defined Networking zorgen er daarnaast voor dat doeltreffend wordt gereageerd op onverwachte veranderingen in het netwerk. Het biedt voordelen in het managen van het netwerk en de kans op fouten door menselijk handelen wordt verkleind. Daarnaast kunnen er slimmere algoritmes worden gebruikt voor detectie van problemen en een betere routering. Te denken valt aan routering op basis van prestaties van de route.
Het DCspine platform is volledig naar deze principes ontworpen. Wij vinden dat met name online service providers met minder geen genoegen moeten nemen: het is voor hen van strategisch belang om altijd hun diensten te kunnen leveren.
Wilt u weten hoe het DCspine platform werkt, of wilt u zelf ervaren hoe eenvoudig het is? Neem dan contact op of probeer vrijblijvend en gratis het portal uit.
