Na mijn meeting met Jan en meerdere gesprekken met Wouter vorige week was het duidelijk geworden dat er binnen het BeLux DC sales team eigenlijk niemand echt de onderliggende werking van de ACI-CNI plugin snapt. We weten allemaal wel wat het doet, maar welke componenten er aan te pas komen en hoe deze allemaal tezamen werken is een voor iedereen een groot vraagteken.
De documentatie van Cisco rond deze integratie is ook redelijk schaars dus ik nam initiatief om de plugin in ons lab volledig te ontleden. Na de vele uren rondneuzen in zowel de kubernetes cluster als ACI spine&leaf switches en apics begon ik de plugin te snappen. Ik vroeg aan Wouter de beste manier om dit te documenteren en voor distributie en onafhankelijkheidsredenen was het best een tekstdocument te schrijven. Ik zal dit document ook toevoegen in mijn bachelorproef als bijlage.
Naast het vele onderzoek rond ACI-CNI en studie voor mijn CCNP blijft mijn sollicitatie voor het CSAP (Cisco Sales Associate Program) ook niet stil staan. Aangezien ik door de CV screening (stap 1) geraakt ben werd ik opgedragen om een on-demand video interview te doen. In een online platform werden er mij enkele vragen gesteld waar ik per video op moest antwoorden. De opnames namen een hele middag in beslag maar ik was toch tevreden met het resultaat. Nu is het geduldig wachten op feedback…
Na vorige week waren alle vooropgestelde milestones eigenlijk bereikt. Na een aantal gesprekken met collega’s besloot ik deze week om te beginnen studeren voor mijn CCNP in datacenter. In februari wijzigt het hele Cisco certificaten curriculum waardoor men niet langer een CCNA nodig heeft om een CCNP te behalen. Daarnaast bestaat de CCNP vanaf februari ook uit een core examen en een specialiteit.
Aangezien ik de afgelopen weken erg veel bezig ben geweest met ACI dachten zowel ik als mijn stagebegeleider dat het examen “Implementing Cisco Application Centric Infrastructure” een niet al te grote challenge meer zal zijn.
Verder werd er op donderdag in samenwerking met AWS een hybrid cloud dag georganiseerd in het Cisco kantoor te Diegem. Ik woonde deze voor het grootste deel van de dag bij maar rond 14u had ik een meeting met Jan (de ACI specialist van het team) om hem een introductie te geven in containers en kubernetes. Hij had vrijdag een afspraak met een klant en wou die klant graag een demo van ACI in samenwerking met CCP laten zien. Aangezien ik mij extensief met beide technologieën bezig hield de afgelopen weken kon ik hem daar goed in assisteren en had hij tegen het einde van de dag een mooi te presenteren demo.
In de feedback van mijn mentor stond er dat exposure belangrijk is binnen Cisco, en dat dat een werkpuntje voor mij was. Daarom maakte ik deze week een nieuwe blog (https://dcexplained.com/) waar ik (in het Engels) wat technischere content op kan gooien.
Mijn twee eerste blogposts waren duidelijk: de vorige twee documentjes die ik over Cloudcenter geschreven had.
De achtste week van mijn stage bestond voornamelijk uit het schrijven en documenteren van de migratieprocedure in cloudcenter. Stel dat we een applicatie draaiende hebben in AWS maar de prijzen gaan plots met 50% omhoog, dan wilt een gebruiker snel kunnen migreren naar een ander platform.
Cloudcenter heeft een mogelijkheid ingebouwd om het bovenstaande te doen. Een bash scriptje laat ons toe om een statefull applicatie te backuppen en te restoren op een ander platform. Aangezien de database de enige statefull component is in mijn eerder ontwikkelde applicatie was het enkel nodig deze component in het migratiescript te verwerken.
Verder hielp ik deze week een teamlid met het migreren van zijn wordpress applicatie naar containers.
Deze week ging verder met waar ik vorige week mee geëindigd was. Het modelleren van een éénlaagsapplicatie was slechts het begin. De echte challenge zit hem in het verbinden van verschillende tiers met elkaar.
Op het einde van de week had ik een 3-tier applicatie (load balancer, web, database) up-and-running met de load balancer en web in AWS en de database in GCP. Daarnaast documenteerde ik de hele opstelling zodat de collega’s er in de toekomst ook iets aan hebben.
Deze week ging mijn aandacht voornamelijk naar het ontdekken van een nieuw cloud product van Cisco: Cloudcenter Suite. Cloudcenter bestaat uit 3 componenten:
Workload manager
Action orchestrator
Cost optimizer
Tijdens mijn stage is het de bedoeling vooral met het workload manager gedeelte bezig te zijn. Deze tool laat gebruikers toe applicaties te modelleren en uit te rollen over verschillende clouds, wat de gebruiker toelaat volledige platform onafhankelijk te werken.
Tegen het einde van de week was het mij gelukt een één-laags applicatie te modelleren (web frontend) en deze uit te rollen op zowel GCP als AWS.
Om security tussen EPGs te voorzien heeft ACI contracts. Dit is een snelle en goedkope oplossing om security tussen (micro)services te voorzien. Contracts bieden echter niet het aantal functionaliteiten zoals antivirus, IPS/IDS, … die NGFWs wel hebben. Om die reden bracht ACI Policy Based Redirect (PBR) uit.
PBR is een key selling point van ACI. In traditionele datacentra wordt vaak al het verkeer dat het datacenter binnenkomt door een firewall gestuurd. Het probleem hiermee is dat NGFWs vaak verkocht worden op basis van hun throughput. Wanneer al het verkeer door een firewall gaat ligt de throughput veel hoger dan wanneer dat verkeer eerst gefilterd wordt. Daarnaast is het in een traditionele DC omgeving niet mogelijk inter-subnet verkeer door een firewall te sturen.
De configuratie van PBR is niet eenvoudig. Zo moet er eerst een firewall aangemaakt worden (ik maakte een vASA) en moet er daar routing op ingesteld worden. Vervolgens moet dat apparaat aangemaakt worden in de APIC en moet er een service graph aangemaakt worden (model van hoe de PBR er zal uitzien). Tot slot wordt deze service graph toegepast en kan er getest worden.
Al het bovenstaande uitzoeken en configureren nam het grootste deel van de week in beslag.
Het datacenter sales team heeft elke week wel een aantal events waarop ze worden verwacht. Deze week moesten we een sessie geven aan partners over hybrid cloud. Op dinsdag zakte ik dus af naar Zemst en om het nuttige aan het aangename te koppelen zorgde de organisatie ervoor dat we na de workshop een initiatie curling kregen.
De week sloot ik samen met Hugues af op donderdag waar we carrièremogelijkheden bij Cisco bespraken.
Elk jaar organiseert Cisco een drie-daagse technische training voor partners genaamd PVT (Partner Virtual Teams). De PVT van EMEAR ging dit jaar door in Amsterdam. Grotere Belgische partners waren welkom in het hoofdkantoor van Cisco Belux om het evenement mee te volgen. Ook ik volgde de livesteam van de 3-daagse PVT op groot scherm.
Dag 1 was een soort introductiedag. Het grootste deel van de dag werd er gesproken over datacenter roadmap en productintro’s gevolgd door enkele lichte demo’s.
Op dag 2 werden de tracks gesplitst. In één kamer was er een infrastructure track, de andere kamer ging over compute. Ik ben de hele dag in de infrastructure track blijven zitten en kreeg daardoor een beter zicht op ACI; meer bepaald automatisatie, innovatie en troubleshooting van de SDN oplossing.
Op donderdag, dag 3, werd het compute track omgeschakeld door een multicloud track. Onder andere CCP en Cisco Cloudcenter Suite kwamen aan bod. Donderdagmiddag gaf een collega van het Belux DC sales team een Techtorial over ACI anywhere. Jammer genoeg kon ik maar een klein stuk meevolgen door een global internal DNS outage (https://www.techrepublic.com/article/ciscos-internal-network-outage-maybe-you-should-use-the-cloud-more/).
Het nadeel aan de meeste private cloud oplossingen is het gebrek aan autoscaling. Ook CCP heeft dit probleem. Dat probleem loste ik deze week op door een klein python programmaatje te schrijven om, door middel van de CCP APIs, het aantal nodes bij te schalen op basis van hun gebruik. De sourcecode en extra uitleg over de werking van dit programma is beschikbaar op mijn GitHub repo (https://github.com/robinverstraelen/ccp-autoscaler).
In 2014 lanceerde Cisco een nieuwe community: DevNet. Een plaats waar software en netwerkoplossingen tezamen komen. Op de website (https://developer.cisco.com/) kan men opleidingen volgen, code publiceren en experimenteren met nieuwe Cisco producten. Alle producten die op DevNet beschikbaar zijn hebben APIs die bedoeld zijn voor automatisatie. Op het einde van week 3 experimenteerde ik met het ACI gedeelte op de website.
Vorige week was de blogpost maar wat mager dus heb ik mij voorgenomen er deze week wat meer ‘volume’ aan te geven. Maandag startte ik met waar ik vorige week mee geëindigd was: CCP.
Om een CCP cluster op te bouwen heb je twee componenten nodig: een infrastructure provider en een ACI-CNI profile. Aangezien we bij Cisco een eigen labo omgeving, met VMWare vSphere als hypervisor, hebben kunnen we gebruik maken van de vSphere infrastructure provider. Het instellen is behoorlijk straight-forward: je specificeert gewoon de vCenter hostname, de poort, gebruikersnaam en wachtwoord.
Elke Kubernetes cluster heeft een CNI (Container Network Interface) nodig om zijn componenten met elkaar, en de buitenwereld te doen communiceren. Cisco heeft zijn eigen CNI om Kubernetes clusters te integreren met ACI. CCP maakt het gemakkelijk om deze CNI op elke cluster te installeren, maar dan moet er wel op voorhand wat configuratie gebeuren.
Wanneer je een nieuw ACI-CNI profile maakt moet je een aantal parameters meegeven. Het IP adres, gebruikersnaam en wachtwoord van de APIC (Application Policy Interface Controller – controller van ACI) spreken voor zich. Vervolgens selecteren we een tenant (meestal is dat de reeds gedefinieerde ‘common’ tenant), geven we de nameservers mee en selecteren we het VMM (Virtual Machine Manager) domain dat overeen komt met het vSphere datacenter dat we zullen gebruiken.
Eens de algemene instellingen gedaan zijn moeten we wat netwerk specifieke beslissingen gaan maken. Zo selecteren we de VRF (Virtual Routing and Forwarding) instantie. Een VRF in zijn essentie is een route tabel. Omdat je meerdere VRF’s, en dus meerdere route tabellen per ACI fabric kan hebben, kan een bepaald subnet meerdere keren voorkomen. Bij het kiezen van een VRF is het belangrijk om rekening te houden met het feit dat de toekomstige cluster het IP van CCP kan bereiken.
Naast de VRF specificeren we een een aantal instellingen om toegang naar buiten te voorzien (L3OUT), kiezen we een AAEP (Attachable Access Entity Profile – specificeert welke fysieke poorten aangepast moeten worden bij aanpassingen) en stellen we een infrastructure VLAN van de fabric in. De andere instellingen mogen leeg gelaten worden. CCP zal die zelf invullen.
Nu dit alles ingesteld is kan de cluster aangemaakt worden. De instellingen die we nu nog moeten invullen zijn vrij basic.
Na het afwerken van de laatste instellingen wordt zowel de infrastructuur als het netwerk van de cluster automatisch geprovisioneerd. We moeten er wel rekening mee houden dat de onderliggende L2-infrastructuur overeenkomt met de instellingen in CCP. Om dit na te gaan kijken we in vCenter naar de port group die het VMM-domain aangemaakt heeft. Daar zien we 3 vlans. Die vlans moeten ook onderliggend getrunkt worden op onze servers. In het lab worden er Cisco HyperFlex servers gebruikt die via Fabric Interconnects geconnecteerd zijn aan de leaf switches van ACI.
Om onze vlans correct in te stellen moeten we deze dus gewoon toevoegen aan een VLAN group in UCS manager.
Daarnaast ondervond ik nog dat de DNS server die we in de ACI-CNI instelde (in mijn geval 8.8.8.8) een bepaald intern Cisco adres niet kon resolven en daardoor bepaalde containers niet kon pullen van de image repository. De nameservers aanpassen naar interne resolvers loste het probleem op.
Cisco werkt nauw samen met verschillende hogescholen om het verschil tussen de schoolbanken en het werkveld zo klein mogelijk te houden. In de PXL hogeschool werken ze in het laatste jaar met verschillende tracks (zoals blockchain en cloud) waar studenten zich voor kunnen inschrijven. Om deze tracks in te vullen vragen ze gastsprekers. Cisco was uitgenodigd om hun productportfolio rond cloud toe te lichten. Mijn stagementor, Wouter, zou deze presentatie geven en vroeg of ik ook een stuk wou voorbrengen.
Omdat ik het afgelopen jaar toch wel wat kennis over Kubernetes verworven heb besloten we dat ik het deel rond container orchestration zou brengen. Zo gezegd, zo gedaan. Na een autorit van twee uur stond ik donderdag voor een klas van ongeveer 20 leeftijdsgenoten.
Na nog eens een uur in de auto richting Diegem te zitten had ik mijn eerste 121 met Hugues. In dit gesprek bespraken we waar ik mee bezig was, hoe ik me voel, … Een leuk concept om de grens tussen manager en werknemer toch wat te verkleinen.
