Beheer en onderhoud van netwerken is een tijdrovende en complexe activiteit. Met name de configuratie van netwerkcomponenten vraagt veel aandacht en precisie. Vaak moeten diverse scripts uitgevoerd worden of is handmatige configuratie op de componenten zelf nodig om de gevraagde functionaliteit te krijgen. Dit heeft de nodige nadelen zoals een vergroot risico op het maken van fouten, is arbeidsintensief en het beheer van grotere netwerken is complex.
Netwerkbeheertools kunnen hier een oplossing bieden maar misschien wordt het tijd om netwerkbeheer eens van een totaal andere kant te bezien. Op dit moment ligt de focus van netwerkbeheer op het beheer van de componenten en niet op het aanbieden van de dienst. Software defined networking (sdn) geeft een totaal andere kijk op netwerkbeheer. Met sdn wordt het netwerk geconfigureerd op basis van de requirements van een client. Nevenstaand figuur geeft een overzicht van de architectuur van sdn.
Deze architectuur lijkt veel op de architectuur van virtuele machines (vm’s) waarbij de controller vergeleken kan worden met de hypervisor en de sdn met de virtuele machines.
Bij sdn wordt de complexiteit van de cli (command-line-interface) vervangen door het aanbieden van netwerkprofielen. Deze profielen bevatten de informatie en configuratie die nodig is om die dienst aan te kunnen bieden aan een client. De controller bevat alle informatie van de netwerkcomponenten en zorgt voor de provisioning van de configuratie. Op de management/provisioninglaag worden de sdn-profielen geconfigureerd en beheerd, dit is een grafische schil waar geen cli meer aan te pas komt.
Met deze architectuur wordt het eenvoudig om snel diensten uit te rollen in grote, complexe netwerkomgevingen. Met sdn is het niet meer noodzakelijk om kennis te hebben van de fysieke hardware. Dit wordt verzorgd door de controller.
Men kan beweren dat het nog steeds nodig is om de cli te kennen, omdat er afwijkende configuraties nodig zijn, met andere woorden; intelligentie in de netwerkcomponenten is nog steeds noodzakelijk.
OpenFlow is een veelbelovend initiatief die de intelligentie van de netwerkcomponenten verplaatst naar de controller. OpenFlow past perfect in de sdn-architectuur omdat deze gebruik maakt van dezelfde componenten.
Het principe van OpenFlow is zeer eenvoudig. Het eerste packet van een client wordt naar de controller gestuurd. De controller inspecteert het packet en probeert een match te vinden (sdn). Op basis van de match wordt de route door de controller bepaald en deze route informatie wordt teruggestuurd naar de netwerkcomponent. Nu weet de netwerkcomponent welke route het packet moet volgen en zal de flow verder afhandelen zonder tussenkomst van de controller.
OpenFlow wordt door vele netwerkleveranciers gezien als de volgende generatie networking, de technologie wordt zelfs al ondersteund (OpenFlow Agent) door een aantal leveranciers. Sdn en OpenFlow zullen in grote mate de toekomst van networking bepalen en een enorme vooruitgang boeken in de vereenvoudiging van netwerkbeheer.
De titel van dit artikel is niet representatief voor de inhoud ervan.
Zekers is het zo dat er nieuwe technieken mogelijk zijn waardoor het configureren van een netwerk op een gebruikersvriendelijkere manier zal kunnen geschieden, maar het inrichten van systemen houd meer in dan het inregelen van een netwerk.
Ik ervaar dagelijks dat een paar aan elkaar geknoopte instructies of een snel inelkaar geknutseld scriptje werk van uren in een paar minuten kan regelen.
Ik vind het inhoudelijk een goed stuk, iig (in ieder geval) goed onderbouwd! 😉
Nieuwe releases van MS windows worden steeds meer CLI based.
Unix/Linux pogingen om zoveel mogelijk grafisch te doen, blijken ook niet alles.
GUI is vaak prettig, maark sommige taken lenen zich nu eenmaal meer voor scripting en dus voor CLI. Pascal hierboven ervaart waarom. 10 jaar geleden allerlei verhalen dat programmeren in dotNET alleen nog maar met muisclick zou gaan.
Tegenwoordig is er tekort aan scripters en C++/java programmeurs. Perl/CGI/PHP is al 10 jaar zo’n beetje een web program standaard. IDE’s zijn nog steeds schilletjes om scripts. Python en Ruby worden steeds populairder.
Netwerkbeheer is geen development of OS beheer. Zal echter toch ook wel veel raakvlakken hebben..
Ik ben het met Pascal eens dat de titel van het artikel de inhoud niet dekt.
Maar, wat is er nu zo complex aan een CLI?
Nu ben ik wat van de oude stempel; aantal jaar IBM mainframe, veel ervaring in scripting, Cisco routers leren configureren met CLI en dergelijke. Overeenkomst tussen dit alles: je moet weten wat je aan het doen bent, en nadenken voordat je begint.
En dat is, wat ik de laatste jaren gemerkt heb, iets wat de hedendaagse ICT-er steeds minder kan: begrijpen wat er nu precies gebeurt als hij een button klikt in de GUI om iets te configureren of te programmeren.
Mijn (wellicht ouderwetse) mening is dat je eerst moet leren programmeren/configureren zonder gui of andere hulpmiddelen, maar met een CLI, zodat je leert hoe het systeem zich gedraagt, en hoe dingen nu echt werken.
Dat je daarna voor het gemak de CLI gaat vervangen door scripting of een gui die het je makkelijk maakt juich ik overigens alleen maar toe.
Ik heb echter teveel “rare” en ondoordachte infrastructuren gezien omdat men maar wat raak klikte en invulde wat men dacht dat goed was.
Deze, veelal jonge, onervaren, gebruikers staan dan vervolgens raar te kijken als je een command shell opstart en van daar uit gaat debuggen.
PaVake, je bevestigd eigenlijk gewoon mijn visie dat een GUI niet moet dienen om gebrek aan kennis van zaken te verdoezelen maar om standaard taken snel te kunnen doorvoeren.
Precies jou opmerkingen hierboven geven aan waarom er zo veel mis gaat in de ICT.
Zoals PaVeKe, Mauwerd en Pascal al naar voren brengen lijkt vervangen van CLI door een grafische schil vaak indirect te leiden tot foutieve configuraties omdat gedacht wordt dat iedereen het dan wel kan. Dat zie je bij het veelvuldig gebruik van TOAD bij beheer van Oracle databases en het gemak van de GUI (lijkend op Windows 7) bij serverbeheer.
Nadeel van deze schilletjes is dat vaak beheer 1-op-1 gedaan moet worden terwijl je met scripts dit kunt automatiseren. En de grafische toevoeging zorgt ook voor meer resourcebelasting, Windows 2008 server core met Powershell en VBS heeft zo zijn voordelen.
Jammer dat de titel de lading van het artikel niet dekt. Openflow en SDN zijn nieuwe mogelijkhedenom netwerken te virtualiseren, waarbij de fysieke infrastructuur wordt ontkoppeld van de besturing. Dit is nuttig in een wereld waar virtuele machines een standaard worden.
Als de schrijver Ich meer in de techniek had verdiept dan was duidelijk geworden dat er nodig steeds een fysieke netwerk infrastructuur nodig blijft, dus kabels, poorten en concentraties van deze onderdelen. Het fysieke netwerk wordt nog steeds bediend door de CLI, ondersteund door GUI’s. Openflow en SDN borduren voort op MPlS, waarbij binnen netwerken virtuele netwerken met een profiel worden gebouwd. MPLS wordt naast een GUI bediend door een CLI.
CLI zullen in mijn opinie altijd blijven bestaan. GUI’s zijn vaak een overlay van de CLI als het gaat om technische componenten, dit zie je bij Microsoft, VMware en andere grote partijen. Dat het dadelijk eenvoudiger wordt om netwerken te configureren is een belofte die al 25 jaar bestaat en voorlopig nog wel even zal blijven bestaan.
De titel is misschien enigszins gechargeerd, en de bedoeling van de titel is dan ook om de lezer ervan aan te sporen om het artikel te lezen. Ik beweer niet dat het einde van de CLI in zicht is. Wat wel als een paal boven water staat is dat met SDN het aantal repetitieve taken drastisch naar beneden gebracht kan worden. Als je kijkt naar een configuratie van een switch/router dan zie je veel terugkerende configuratieregels. Door middel van scripting kan dit inderdaad vereenvoudigd worden. Het aansturen van deze scripts (dus de GUI) kan netwerkdeployment vereenvoudigen. Daarnaast kijkt SDN niet alleen naar netwerk switch configuratie, maar ook naar de netwerkconfiguratie op de servers. Serverbeheer ligt doorgaans niet het domein van de netwerkbeheerder, en dit geldt ook vice versa voor het beheer van netwerken. Met SDN worden deze twee werelden nader tot elkaar gebracht.
Indien SDN goed uitgerold is, kan een dienst in minuten beschikbaar gemaakt worden door middel van SDN software (ondersteund door Open Flow based networks). In legacy netwerken dienen de netwerk, server en storage componenten door verschillende beheersgroepen ingeregeld en uitgerold te worden. Dit komt niet ten goede aan de serviceverwachtingen van de gebruiker (lees klant).
En voor wat betreft die belofte, het is zeer goed mogelijk dat die belofte sneller ingelost wordt dan men denkt. Jarenlang is de netwerkmarkt beheerst door een enkele vendor (met focus op voornamelijk CLI), maar de tijden zijn veranderd door de komst van alternatieve networking oplossingen.