In een eerdere blog ging ik in op hoe je een routing stack van één leverancier kunt gebruiken op apparatuur van een andere. Daarvoor kun je onder meer de sai-interface van Sonic als hardware-abstractielaag gebruiken. Dit biedt veel voordelen en mogelijkheden voor organisaties die behoefte hebben aan vergaande flexibiliteit qua hardware en software. Je moet wel de kennis in huis hebben om dit te implementeren; support is (nog) lastig te krijgen.
In de praktijk is er vaak sprake van een enorm verschil tussen de kennis waarover het netwerk, de serverinfrastructuur en de applicaties beschikken. Zeker, omdat deze kennis niet gedeeld wordt en het netwerk dus niet weet wat de applicatie eigenlijk nodig heeft qua routing. Stel je voor wat er allemaal mogelijk zou zijn als we deze kennis wel kunnen delen! Daarmee zijn we aangekomen bij de volgende stap in datacenter-routering. Dat is om een routing stack op een server te installeren en daarmee de server en/of applicatie aan te laten geven welke route door het netwerk gevolgd moet worden naar een groep eindgebruikers, of zelfs naar één specifieke eindgebruiker.
Geen nieuw fenomeen
Dit wordt egress peering engineering genoemd, oftewel het bepalen waar dataverkeer het netwerk verlaat. Dit is op zich geen nieuw fenomeen. Egress peering engineering wordt al jarenlang gebruikt binnen service provider-netwerken, en meestal voor het optimaliseren van de verbindingen met transit providers en peers. Maar als we dus de mogelijkheid al hebben om te bepalen waar het verkeer het netwerk moet verlaten, waarom zouden we dan de servers niet mee laten beslissen over de routering?
Er zijn tientallen voorbeelden van scenario’s waarin het goed van pas zou komen als een server invloed uitoefent op de routeringsbeslissingen, zowel binnen als buiten het datacenter. Dit kan alles omvatten van sturing van het netwerkverkeer en het creëren van serviceketens, tot cdn-/edge-computing, multi-cloud gateways, het neutraliseren van ddos-aanvallen, high resiliency en verbeterde netwerkconvergentie voor servers in datacenters.
Laten we videostreaming als voorbeeld nemen. De software (streamer) die hiervoor wordt gebruikt krijgt veel feedback over de beeldkwaliteit van de videoplayer aan de gebruikerskant. Die informatie wordt onder meer gebruikt voor het optimaliseren van de resolutie en het aanpassen van het bandbreedteverbruik (bijvoorbeeld verlagen van de bandbreedte bij haperingen van de stream). In een aantal gevallen zal dit een oplossing bieden voor eindgebruikers die onder een slechte kijkervaring lijden. Dit proces oefent echter geen invloed uit op de transit provider of peers die moeten worden gebruikt, zelfs als er voor die ene gebruiker een betere route door het datacenter of over het internet beschikbaar is. Dit zou echter wel mogelijk zijn, als de applicatie en routering dichter bijeen worden gebracht op de server of host.
Stel nu dat we een routingstack op een host onderbrengen, dan biedt dat de mogelijkheid om de video streaming-applicatie de routering te laten dicteren. Het zou resulteren in een betere gebruikservaring en daarnaast een oplossing bieden voor diverse andere uitdagingen waaronder spanning tree-problemen door het elimineren van layer 2-verbindingen. Het enige dat we dan nog nodig hebben, is iemand om de integratiescripts daarvoor te schrijven…
