Hoe nieuw is Software Defined Networking?
Hoe nieuw is Software Defined Networking?
Er is steeds meer te doen over Software Defined Networking (SDN), maar een eenduidige definitie lijkt vooralsnog niet voorhanden te zijn. De een beschouwt het als concept, terwijl sommige leveranciers een concrete oplossing suggereren. Waar staat het voor, wat doet het en nog belangrijker, hebben we het nodig? De voordelen van SDN kunnen volgens sommigen ook anders bereikt worden. Is SDN slechts een nieuwe benadering voor bekende netwerkgerelateerde uitdagingen of meer dan dat?
Daar waar cloud computing een methode is om IT-dienstverlening slimmer te faciliteren en BYOD helemaal ingaat op hoe gebruikers gebruik kunnen maken van IT-dienstverlening met een ‘eigen’ (mobiel) apparaat naar keuze, gaat SDN vooral over de onderliggende architectuur om deze en toekomstige IT-dienstverlening sneller en mogelijk ook stabieler in te kunnen zetten. Dergelijke doelstellingen worden vaak aangeduid met agile of agility. Het onderscheidend vermogen is dat de onderliggende IT-laag van besturingssystemen en netwerken zich transparant gedragen.
Is de huidige setup dan niet goed? Het antwoord daarop is meestal: ”Nee!” De huidige inrichting om toepassingen of applicaties beschikbaar te stellen aan eindgebruikers vereist altijd een langlopend traject waarbij alle lagen die nodig zijn om de applicatie te faciliteren betrokken moeten worden. Anders gezegd: alle componenten inclusief besturingssysteem, netwerk en alle beveiligingsmaatregelen moeten worden aangepast voordat de IT-dienst kan worden gebruikt. Dit is een tijdrovend en terugkerend proces, want bij iedere nieuwe IT-toepassing begint de hele cyclus weer van voren af aan. De time-to-market loopt onnodig vertraging op. Bovendien leidt het versnipperde, veelal multi-vendor netwerk ertoe dat centraal management niet valt in te richten. Er is geen eenduidige inrichting van het netwerk, je hebt te maken met inconsequente uitvoering van beveiligingsmaatregelen en service automation om IT-dienstverlening geheel geautomatiseerd te laten verlopen is eigenlijk een utopie.
Scheiding data en controle
Software Defined Networking is geen vastomlijnde oplossing die alle bovengenoemde issues even oplost. Het is een framework, wat verklaart waarom definities per uitleg nog wel eens verschillen. De kern van dit framework wordt gevormd door het ontkoppelen van de controle en het transport van data in de netwerklaag. In de huidige opzet wordt de controle informatie als header of footer in frame of datagram meegezonden samen met de payload op het moment dat dit door een client of server wordt geïnitieerd. De onderliggende structuur van routers, switches en firewalls dient zich vervolgens on-demand te bemoeien met het afleveren van de data.
Problemen met het transporteren van data ontstaan vaak in multi-vendor omgevingen waar een netwerkapparaat zich net even anders gedraagt dan die van de concurrent. De netwerkintelligentie zit bij SDN niet meer in de netwerkapparatuur zelf, maar wordt gecentraliseerd in software-gebaseerde controllers. Door de netwerk controlebus te ontkoppelen en deze functionaliteit onder te brengen in centraal opgestelde SDN controller software, kan het transport sneller, flexibeler en optimaal worden afgestemd op de toepassing.
In de meeste gevallen wordt OpenFlow-protocol gebruikt voor om de Control Data Plane Interface te programmeren, maar er zijn alternatieven voorhanden zoals Extensible Messaging and Presence Protocol (XMPP) en OpenStack.
OpenFlow stelt routers en switches die dit protocol ondersteunen in staat om het controlepad te scheiden van het datapad waardoor het netwerkapparaat zich alleen nog maar hoeft te bemoeien met het transporteren van data. Dit betekent dat deze laag veel abstracter wordt en een multi-vendor omgeving tot minder problemen leidt. Daarnaast wordt het centraal programmeren van het controlepad ondergebracht in een centrale controller die alle hard- en software routers en switches kan bedienen met de juiste forward-informatie op laag 2, 3 en 4.
De API’s die nodig zijn om de applicaties en SDN controlelaag met elkaar te laten communiceren worden per applicatie ontwikkeld en deze zijn niet gestandaardiseerd.
Het centraliseren van de netwerkcontrolelaag betekent dat deze programmeerbaar en geschikt is om flexibel te configureren. Er is een consistente operationele beveiliging uit te voeren en het netwerk is te optimaliseren doordat automation of provisioning via de centrale aanpak wel te regelen valt.
Behoefte aan SDN groter
Ontwikkelingen zoals cloud computing, server virtualisatie, de overweldigende opkomst van smart-devices zijn typische SDN-aanjagers. De verandering naar een samenleving waarin iedereen altijd online is en iedereen wenst te beschikken over zijn of haar content, levert op dat de huidige infrastructuren plaats gaan maken voor SDN. Het netwerk levert dan niet meer dan een datapad, waarbij software de controle over de communicatie op zich neemt. De intelligentie wordt zo uit het netwerk gehaald en per applicatie of toepassing kan worden bepaald wat de best passende communicatieparameters zijn. Nieuwe toepassingen kunnen hierdoor vele malen sneller beschikbaar worden gesteld. Ze zijn niet meer afhankelijk van een tijdrovend project en het samenbundelen van allerlei losse objecten tot een samenwerkend geheel. Het concept achter SDN biedt de potentie om organisaties succesvol te laten zijn in het vlug of agile uitrollen van nieuwe toepassingen, natuurlijk hangt het eindresultaat af van de uitvoering in de praktijk.
Hoe nieuw is SDN?
SDN vertoont overeenkomsten met een al langer bestaande aanpak: Application Delivery Networking (ADN). SDN wil namelijk ook profiteren van een scheiding van controle- en datapad. Het zorgt er tevens voor dat intelligentie en status logisch wordt gecentraliseerd. En ten derde wordt de onderliggende netwerkinfrastructuur abstract gemaakt. Een full-proxy ADN hanteert exact dezelfde principes als SDN.
Voegt SDN dan niets toe? Zeker! Daar waar ADN een prachtige abstractielaag voor applicaties naar het netwerk vormt, kan SDN naadloos aansluiten door de transportinformatie te verwerken in plaats van deze ouderwets te stoppen in de IP headers. Dit betekent dat SDN zich gaat bemoeien met de downstream op laag 2 en 3 van het OSI model van een ADN waar protocollen als OpenFlow en VXLAN kunnen worden gebruikt om end-to-end het best denkbare netwerkpad te effenen.
Dus, daar waar op OSI laag 2 en 3 compatibiliteitsproblemen ontstaan, zorgt het SDN overlay protocol ervoor dat dit probleem niet ten koste gaat van een flexibele, snelle en schaalbare uitrol van een nieuwe applicatie.
Als toevoeging van SDN aan ADN is dit echt het enige, want bij ADN wordt de beslissing over de routing of service request genomen op basis van transport- (TCP/UDP) of applicatielaag- (HTTP) data. Hiervoor is het noodzakelijk meerdere packets samen te voegen, waardoor een ADN controller data moeten bufferen totdat er voldoende is ontvangen om de validiteit vast te stellen (voor de activatie van beveiligingsmaatregelen) en de bestemming. Het samenvoegen van packets en bijhouden van grote sessies state tabellen is niet in het ontwerp van SDN opgenomen. Het vereiste geheugen en rekenkracht zou de voordelen van het loskoppelen van de hardware tenietdoen. Bovendien is de prestatie van SDN sterk afhankelijk van de mogelijkheid grote hoeveelheden packets te matchen in een switch-element, zonder dat daarvoor een query richting de SDN controller voor nodig is. Hogere netwerklaagsessies zijn zonder meer uniek. Ze zijn gebaseerd op netwerk (IP) data, maar ook op data uit laag 4 en 7. Door een SDN-aanpak op dit verkeer toe te passen, is een query nodig naar de controller voor elk verzoek. Daar is de architectuur niet voor ontworpen.
SDN en ADN hand in hand
De verschillen in vereisten voor een netwerkgerichte en een applicatiegerichte aanpak, maken het lastig kiezen tussen de twee. Beide methodes pakken dezelfde uitdagingen aan in verschillende lagen. ADN bevindt zich op een strategische plek in het netwerk en speelt in op beschikbaarheid, optimalisatie en beveiliging van applicaties. Het heeft invloed op de manier waarop applicaties worden geleverd via netwerktechnologieën zoals SDN. SDN richt zich veel meer op hoe netwerkverkeer wordt geregeld over de verschillende elementen in de netwerkinfrastructuur. De ADN-controller vertaalt eindgebruiker-gegevens over verbindingen in gerichte, node-specifieke communicatie over de switch-principes. Wanneer dit gebeurt in sterk gevirtualiseerde en cloud computing omgevingen is SDN een uitkomst. De ADN moet dan in staat zijn de vertaalslag te maken van traditionele naar SDN-omgeving. En dat is precies waar de twee samenkomen. Waar requests uit de applicatielaag terechtkomen in een zeer dynamisch netwerk.
Kortom, ADN zal verantwoordelijk blijven voor het verbinden van eindgebruikers en applicaties, terwijl SDN bepaalt hoe packets worden getransporteerd. Ze zullen samenwerken om de complexiteit van netwerkbeheer en applicatieverkeer in de hele stack het hoofd te bieden en de agility te vergroten.