Fase 2: het verplaatsen van een router

Dit is de derde blogpost in een reeks die beschrijft hoe wij uitbreiden naar een tweede datacenter. Het doel is om je een zo goed mogelijke kijk te geven op hoe wij deze complexe werkzaamheden uitvoeren. Vragen en feedback zijn van harte welkom!

De afgelopen twee weken hebben we ons gefocust op het opbouwen van een redundante ring tussen datacenter ENS1 in Enschede en datacenter HNG1 in Hengelo. Sinds vorige week maandag is de ring actief en gekoppeld aan ons productienetwerk. Inmiddels worden alle backups van servers in ENS1 al rechtstreeks naar backupservers in HNG1 getransporteerd.

Daarnaast zijn er nog andere tests uitgevoerd om de redundantie en algemene betrouwbaardheid/performance te testen. Deze tests zijn allemaal succesvol en volgens verwachting doorlopen. Dat betekent dat we nu klaar zijn voor de volgende fase!

Verplaatsen van router
In de ochtend van vrijdag 19 augustus voeren wij fase 2 uit: het verplaatsen van een router. Bij vorige blogposts kregen we de vraag of het niet raar is dat we één van onze core-routers naar HNG1 verplaatsen. Een te verwachten vraag, omdat het lijkt alsof de redundantie permanent verbroken wordt. Dat is echter niet het geval. Om dat inzichtelijk te maken zullen we kort de huidige en de nieuwe situatie beschrijven. Het zal blijken dat ons netwerk hetzelfde service-level kan bieden, met nog het toegevoegde voordeel dat het netwerk zelfs online blijft als één van de twee datacenters offline gaat.

De oude situatie
Op dit moment opereren we volledig vanuit ENS1. In dit datacenter hebben we twee core-routers die ieder op één van onze leveranciers is aangesloten. Een vereenvoudigd schematisch overzicht:

De redundantie is hier eenvoudig te begrijpen: als een core-router of leverancier uitvalt, kan de andere core-router binnen ENS1 het automatisch overnemen.

De nieuwe situatie
In de nieuwe situatie zou je dus kunnen denken dat de redundantie in ENS1 weg is nadat we een core-router verplaatst hebben naar HNG1. Dat is echter niet het geval. Nogmaals een vereenvoudigd schematisch overzicht, maar dan van de nieuwe situatie:

Zoals je in bovenstaande tekening ziet sluiten we leverancier 2 aan in HNG1. Bovendien zijn de twee netwerken in ENS1 en HNG1 rechtstreeks op elkaar aangesloten. Mocht nu bijvoorbeeld de router in ENS1 het begeven, dan kan het verkeer automatisch via de redundante ring naar HNG1 getransporteerd worden. Vervolgens kan de router in HNG1 het verkeer routeren naar het internet.

In feite werkt het dus exact hetzelfde als in de oude situatie, met als enige verschil dat de geografische afstand tussen de twee core-routers wat groter is. Als je abstract naar de nieuwe architectuur van het netwerk kijkt is er eigenlijk alleen een aantal kabels wat langer geworden. Een andere bijkomstigheid: mocht bijvoorbeeld ENS1 volledig uitvallen, dan blijft het verkeer in HNG1 gewoon normaal doorlopen.

Tot slot
We hebben met opzet de schematische tekeningen zo eenvoudig mogelijk gehouden, met zo weinig mogelijk lijntjes. Middels deze blogpost hebben we geprobeerd twee zaken inzichtelijk te maken:

• Ons netwerk gaat er qua redundantie niet op achteruit door de uitbreiding naar een tweede datacenter. Sterker nog: ons netwerk blijft nu zelfs online als een heel datacenter uitvalt.
• Als één van de twee core-routers uitvalt, wordt het verkeer naar het andere datacenter getransporteerd, alwaar de desbetreffende core-router het verkeer gewoon kan routeren.

Laat je stem horen! Gaat deze blogpost diep genoeg voor jou, of misschien juist te diep? Heb je vragen of verzoekjes voor een volgende post, laat het ons weten!