Efficiëntere beheerprocessen door orkestratie & automatisering

Taken automatiseren

In het huidige SURFnet-netwerk worden nog veel acties handmatig geconfigureerd, zoals oplevering en management van nieuwe verbindingen. Hier gaat veel tijd in zitten, net als in het proces. Het is namelijk nodig om met een flink aantal schijven te schakelen waardoor het opleverproces soms vertraging kan oplopen. Hoewel het proces nog steeds snel is en er hard gewerkt wordt om de klantbeleving te optimaliseren, sluipen er soms fouten in de administratie van diensten. In het ergste geval heeft dit voor SURFnet gevolgen voor de facturatie van diensten, en voor klanten betekent het dat zij langer moeten wachten op de oplevering van hun dienst. Door vol in te zetten op automatisering verwachten we veel van de vaak voorkomende fouten uit te sluiten en het opleverproces te versnellen.

Het doel van mijn opdracht is om vóór de oplevering van de SURFnet8-servicelaag een proof-of-concept uit te werken dat in staat is om zoveel mogelijk taken van het opleveren van diensten op zich te nemen. Door gebruik te maken van zogenaamde ‘workers’ die ‘jobs’ uitvoeren en programma’s die met elkaar informatie uitwisselen door gebruik te maken van `RESTful interfaces’, hopen we de registratie van gegevens en de oplevering van netwerkdiensten te verbeteren.

Huidige traject voor oplevering is lang

Een typische (technische) oplevering van een redundante BGP-verbinding bestaat nu uit 31 stappen. Dit zijn alleen de stappen voor de engineer van het SURFnet NOC. Daar gaat een traject aan vooraf waarin SURFnet informatie verzamelt om te zorgen dat de dienst goed aan de klant wordt opgeleverd. Als we alleen al een deel van al deze werkzaamheden kunnen automatiseren, zal het risico op menselijke fouten afnemen.

Typische acties die een engineer moet uitvoeren zijn: registratie van diensten in de Configuratie Management Database (CMDB), registratie van point-to-point-verbindingen in de IP Adress Management (IPAM) database, configuratie van laag 2-verbindingen in het Netwerk Management Systeem (NMS), configuratie van interfaces op de core routers van SURFnet, configuratie van ‘routing policies’ op de corerouters, enzovoort. Dit zijn allemaal relatief eenvoudige, maar bewerkelijke handmatige acties.

Veel procedures in collectief geheugen van medewerkers

Naast het technische aspect, kijken we ook naar het administratieve aspect. Op dit moment zijn er binnen onze netwerkafdeling 7 tot 8 verschillende tools waar zaken worden geadministreerd over een verbinding, maar het is nog niet gelukt om alle details over die verbindingen op te slaan. Veel informatie staat opgeslagen in het collectieve geheugen van de medewerkers en wordt bepaald door de methodiek van werken.

Een goed voorbeeld hiervan is hoe het VLAN van een klant wordt toegewezen wanneer hij een verbinding nodig heeft op een van de core routers. Afhankelijk van of de verbinding primair of secundair is, wordt een VLAN ID in de 1000- of 2000-reeks gekozen en geconfigureerd. De laatste 3 cijfers van het VLAN zijn afgeleid van het service ID. Het service ID begint met het cijfer 3 in het geval van een IP-verbinding en 2 in het geval van een laag 2-verbinding. Dit betekent dat wanneer het service ID 3125 is, het VLAN op de primaire router 1125 en op de secundaire 2125 is.

Omgaan met uitzonderingen is lastig

Wat ik hier beschrijf zijn eigenlijk heel logische procedures die organisch zijn ontstaan gedurende de groei van SURFnet over de afgelopen 30 jaar. Het is voor het menselijk denkproces heel natuurlijk om op deze manier dwarsverbanden te leggen tussen systemen, zodat de configuratie van een klant eenvoudig kan worden afgeleid van een simpel getal, namelijk het service ID. Uit een getal van 4 cijfers kan de engineer allerlei informatie afleiden over hoe de verbinding is opgebouwd, wat helpt bij het troubleshooten en beheer. Echter, hoe ga je in deze situatie om met uitzonderingen? De bovenstaande methode van administreren kan alleen bij een klant met twee verbindingen. Wat als hij er vier of acht wil? Wat ga je doen als je meer core routers krijgt?

Doordat het menselijk brein zo efficiënt is in het vastleggen van al deze dwarsverbanden is het heel lang mogelijk geweest om door te groeien met deze manier van werken. Door de groeiende complexiteit van diensten, en de toenemende vraag naar dynamische aanpassingen in het netwerk is het echter niet meer mogelijk om op deze manier verder te gaan, want hoe passen uitzonderlijke configuraties in deze informatie-architectuur?

Orkestratie & automatisering

Het doel is van het netwerkautomatiseringsproject is om het beheer van diensten mogelijk te maken vanuit één dashboard: het SURFnet-netwerk Dashboard, en door middel van een gestandaardiseerde REST-api. Dit dashboard maakt gebruik van een orkestratielaag, die de businesslogica en processen vastlegt en via een automation-laag daadwerkelijke acties op de apparatuur uitvoert.

Mijn voornaamste taak in deze opdracht is het ontwikkelen van een proof-of-concept voor de orkestratie- en automation-laag. Onderstaande afbeelding geeft de onderdelen van deze architectuur weer.

De voorgestelde architectuur bestaat uit een aantal belangrijke onderdelen:

• Activiti BPMN orchestration engine: deze tool definieert business flows in de BPMN standaard en zorgt ervoor dat stappen in het proces automatisch worden uitgevoerd. Voorbeelden zijn een REST api call of het sturen van een e-mail.
• ActiveMQ: dit onderdeel van de orkestratielaag is verantwoordelijk voor de routering van berichten richting de diverse automation tools. Het zorgt ervoor dat taken één voor één worden uitgevoerd, in de juiste volgorde en dat ze bij de juiste worker terecht komen.
• Database: dit onderdeel van de architectuur is het koppelvlak tussen alle systemen. Hier is de audittrail te vinden van alle interacties tussen systemen. Daarnaast zijn alle producten hier gedefinieerd en worden verwijzingen naar andere systemen zoals het CMDB, het CRM, en het NMS gekoppeld aan een klant en het product dat hij afneemt.
• De workers zijn verantwoordelijk voor het daadwerkelijk uitvoeren van acties op het netwerk en diverse apparaten. Zij implementeren een REST-client en sturen een REST-wrapper interface aan die is gebouwd voor het systeem dat moet worden aangestuurd.

Workers bouwen

Een groot onderdeel van het project is het bouwen van workers. Deze simpele systemen zijn bedoeld om 1 specifieke functie uit te voeren, namelijk de client-functionaliteit van een REST-api. Door gebruik te maken van open standaarden zoals de open API-standaard en swagger is het mogelijk om interfaces in zeer korte tijd te definiëren. Swagger kan servers en clients genereren voor allerlei programmeer- en scripttalen zoals, C, JAVA, C#, PHP, go, Python etc. Dit maakt het ontwikkelen van een worker een dynamisch en snel proces. Er is slechts kennis nodig van yaml/JSON om een interface te declareren.

Toekomst: snellere en transparantere oplevering van producten

Als de proof-of-concept een succes blijkt en klaar is voor productie, zal er veel veranderen voor onze klanten, maar ook voor SURFnet. Aanvragen en simpele configuratiewijzigingen kunnen dan eenvoudig geregeld worden via het SURFnet-netwerk Dashboard. Om dit voor elkaar te krijgen zijn we nu hard bezig met het bouwen van de onderliggende infrastructuur, zoals deployment pipelines met automatische tests voor de uitrol van nieuwe versies van de software en tools die gebouwd worden. Binnen de afdeling werken we aan agile werkmethodes zodat we snel en effectief veranderingen door en functionaliteiten toe kunnen voegen aan de architectuur. Het doel hierbij is snellere en transparantere oplevering van producten.

In de laatste paar maanden van mijn Jong Talent-opdracht is het doel zoveel mogelijk functionaliteiten toe te voegen aan de architectuur, zodat de informatiebronnen zijn voorzien van een REST-interface en klaar zijn om gebruikt te worden, binnen de architectuur. Daarnaast zal ik met collega’s veel aandacht besteden aan het vastleggen van informatie om de afdeling klaar te stomen voor het nieuwe systeem.