Toevallig viel deze eerste stap in de NetherLightmigratie precies samen met het begin van de COVID-19-crisis. Achteraf gezien kwam dit voor het project niet slecht uit. Omdat veel instellingen de deuren sloten en iedereen zich moest aanpassen aan de nieuwe situatie, waren onze fysieke werkzaamheden in de eerste twee maanden van de crisis voor een groot deel beperkt tot onze corelocaties/datacenters. Dat was een goede reden om er nu stevig de schouders onder te zetten. Zogezegd, zo gedaan. Nog geen drie maanden later migreerden we de laatste NetherLightpoort en kijken we terug op een geslaagd (deel)project.
De NetherLightmigratie, een complex project
Vraag 10 experts wat de beste oplossing is voor een complex probleem en de kans is groot dat je 10 verschillende antwoorden krijgt. Dat was bij de ontwikkeling van een migratieplan voor NetherLight niet anders.
Op het eerste gezicht lijkt de migratie niet ingewikkeld. Het knooppunt bestaat uit ongeveer 75 aangesloten poorten (van 10G en 100G). De migratie naar SURFnet8 betekende in grote lijnen dat we deze poorten moesten verhuizen van 4 verschillende SURFnet7-switches naar 2 nieuwe SURFnet8-routers. In de basis geen ingewikkelde opgave. De complexiteit schuilt in het feit dat tussen vrijwel elke poort op het NetherLightplatform diensten bestaan naar veel andere poorten. Als je dus één patchkabel lostrekt om een poort te migreren, dan verliezen misschien 10 aangesloten instellingen en Nationale onderwijs- en onderzoeksnetwerken (NREN’s) hun (backup)connectiviteit. En als je dan één van die services weer wilt herstellen door een tweede poort te migreren, dan verliezen weer 10 andere instellingen mogelijk (backup)connectiviteit naar een bepaalde dienst. Een goede voorbereiding is dus essentieel om dit sterk vervlochten web van internationale verbindingen te migreren.
Drie vragen bij de keuze van een migratiestrategie
Bij het ontwikkelen van een migratieplan moesten we de beste balans vinden tussen de antwoorden op de volgende 3 vragen:
- Hoe migreren we het NetherLightplatform met de minimale hoeveelheid werk voor onze netwerk engineers?
- En met minimale overlast voor de aangesloten instellingen, NREN’s en partners?
- Hoe beperken we de risico’s en houden we maximale controle bij elke migratiestap?
Deze vragen vormden de leidraad bij de discussie over de beste strategie. Het resultaat van deze discussie kun je het beste samenvatten als het antwoord op de vraag: ‘Hoe eet je een olifant?’.
Hoe eet je een olifant?
Als je de risico’s zoveel mogelijk wilt beperken en maximale controle wilt houden dan kun je het beste elke poort afzonderlijk naar SURFnet8 migreren. En elke service ombouwen naar een tijdelijke situatie als de andere poorten nog in het SURFnet7-domein zitten. Op die manier kun je na elke migratiestap controleren of alle services weer naar behoren werken. Als je zeker weet dat alles werkt, kun je beginnen aan de volgende poort.
- Dus: Hoe eet je een olifant?
- Antwoord: Snij de olifant in zoveel mogelijk kleine stukjes en eet hem vervolgens hapje voor hapje op.
Het nadeel van deze methode is dat het zeer arbeidsintensief is en dat elke service meerdere malen onderbroken wordt. Dat is niet fijn voor de netwerk engineers, maar ook niet voor de gebruikers van diensten.
Als je het probleem benadert vanuit het perspectief dat de netwerk engineers zo min mogelijk werk hoeven te verzetten dan is het antwoord ook eenvoudig. Dan wordt het een big bang migratie. Je onderbreekt alle services in het SURFnet7-domein en bouwt ze vervolgens één voor één weer op in het SURFnet8-domein. Op die manier hoef je elke service maar één keer te migreren, dus dit kost veruit het minste werk.
- Dus: Hoe eet je een olifant?
- Antwoord: Je slikt de olifant in één keer door.
Het nadeel van deze methode is dat het veel risico met zich meebrengt en dat services soms lang niet beschikbaar zijn (het duurt even voordat je de olifant verteerd hebt). Bovendien is het NetherLightplatform met 75 poorten en 300 services veel te groot om in 1 arbeidsgang te migreren, dus deze olifant is eigenlijk te groot om in één keer door te slikken.
De strategie die we hebben gekozen ligt ergens tussen deze twee uitersten. Uiteindelijk hebben we besloten om het project in een aantal grote, maar redelijk overzichtelijke brokken op te hakken. Op die manier hielden we voldoende controle en konden we toch redelijk snel voortgang boeken met relatief weinig overlast voor de gebruikers.
- Dus: Hoe eet je een olifant?
- Antwoord: Je hakt de olifant in grote stukken en eet in verschillende gangen.
Op die manier hebben we het NetherLightproject ook opgehakt in drie grote maar overzichtelijke brokken. Eerst de service providers, vervolgens het LOFAR-netwerk en ten slotte de overige NetherLightpoorten.
Voorgerecht: service providers
De service providers waren het eerst aan de beurt. Dit zijn partijen als Microsoft, Vancis, NL-ix, KPN en T-Mobile. Deze partijen leveren diensten aan instellingen binnen het landelijke SURF-netwerk. Hun poorten hebben vaak veel services, maar kunnen vrij gemakkelijk per poort afzonderlijk gemigreerd worden.
Omdat deze diensten vaak cruciaal zijn voor de dagelijkse operatie van instellingen hebben we deze poorten in de vroege morgen (5:00 - 7:00 uur) of in de avonduren (19:00 - 21:00 uur) gemigreerd. Het eerste service window was op 16 maart en het vijfde en laatste window op 13 mei. Op deze manier migreerden we de A-zijde van ongeveer 120 services in 6 stappen. De B-zijde volgt in de komende maanden wanneer we de accesslocaties waar deze services gebruikt worden, van SURFnet7 naar SURFnet8 migreren.
Hoofdgerecht: LOFAR- en JIVE-netwerk
Het LOFAR-netwerk is een mooi voorbeeld van de internationale samenwerking waarvoor netwerkexchange NetherLight is opgericht. Binnen het LOFAR-netwerk zijn ASTRON in Dwingeloo (het Nederlands Instituut voor Radio Astronomie) en het rekencentrum van de Rijksuniversiteit Groningen (RUG) via diverse internationale verbindingen op het NetherLightplatform verbonden met radiotelescopen in Engeland, Frankrijk, Duitsland, Zweden en Polen. Op deze manier ontstaat er een soort supertelescoop die zich tegelijkertijd op hetzelfde deel van de ruimte kan richten. De enorme hoeveelheden data die deze telescopen verzamelen, worden in Groningen ontcijferd om te proberen de geheimen van ons heelal te ontrafelen.
Het JIVE-netwerk overlapt voor een deel met het LOFAR-netwerk omdat ze soms dezelfde meetstations gebruiken. Samen vormen deze netwerken een samenhangend geheel dat met enige inspanning in één keer gemigreerd kan worden. De migratie hebben we op 14 mei uitgevoerd zodat dit in het onderhoudsregime van beide netwerken past.
Dit was een behoorlijk complexe operatie. Zo waren er field engineers in Amsterdam en Groningen die onder controle van de netwerk engineer van het Network Operations Center (NOC) van SURF de fysieke patches omstaken naar SURFnet8-apparatuur. Verder engineers bij JIVE, GÉANT en het Team Expert Netwerkbeheer (TEN) van SURF die verantwoordelijk waren voor de configuratie van enkele specifieke verbindingen. Projectleiders bij SURF, ASTRON en de RUG bewaakten en begeleidden het werk. En ten slotte hield de projectleider bij ASTRON contact met alle radiotelescopen in het LOFAR-netwerk om te controleren of alle services weer naar behoren functioneerden. Een goede voorbereiding is het halve werk. We hadden anderhalve dag uitgetrokken voor de migratie (just in case), maar de gehele migratie was al binnen 5 uur afgerond. ’s Middags kon LOFAR al melden dat de SURFnet8-verbindingen met alle telescopen naar volle tevredenheid werkten.
Nagerecht: het leeuwendeel
De laatste fase van het project was minder ingewikkeld dan de LOFAR-migratie. Er waren minder mensen bij betrokken, met minder afhankelijkheden. Maar tijdens deze operatie verspreid over 3 verschillende dagen migreerden we wel het leeuwendeel van de verbindingen op het NetherLightplatform met geografisch gezien de meeste impact. Tijdens deze fase werden de grote jongens gemigreerd, zoals de trans-Atlantische verbinding naar Canada (en van daaruit naar de Verenigde Staten), onze verbindingen naar CERN in Geneve, de links naar Europese NREN’s zoals NORDUnet, PSNC en de overkoepelende organisatie GÉANT, en vele andere internationale NREN’s zoals AARNet (Australië), Tenet (Zuid-Afrika), SINET (Japan), KISTI (Korea) en ESnet (Verenigde Staten). Ook hier bleek weer dat een goede voorbereiding meer dan het halve werk is. Op 15 juni was onze laatste migratiedag. Die dag stond de migratie van de poorten met het grootste aantal services gepland, in totaal ongeveer 140. Vanwege het grote aantal hielden we er rekening mee dat we tot in de avond aan het werk zouden zijn, maar rond de lunch konden we de vlag al uitsteken. De migratie van het NetherLightplatform naar SURFnet8 was gereed.
Conclusie
Je kunt ontzettend lang nadenken over de beste strategie en dat is zeker niet onbelangrijk. Maar als je eenmaal hebt gekozen voor een plan, gaat het vooral om de zorgvuldigheid waarmee dit wordt uitgevoerd. De belangrijkste succesfactoren van een migratie zitten in de ervaring en betrokkenheid van de engineers die het werk moeten uitvoeren en de ruimte en vrijheid die ze krijgen om dit werk zo goed mogelijk voor te bereiden. De inbreng van het ondersteunde team is daarbij ook belangrijk. Zij hebben aandacht voor alle details en zorgen dat de engineers zich kunnen focussen op hun hoofdtaak. Daarbij blijven ze goed opletten wat er gebeurt in het veld, zodat ze behulpzaam kunnen zijn op het moment dat dit nodig is. Ten slotte kan in een opsomming van succesfactoren onze zelf ontwikkelde orchestrator tooling natuurlijk niet ontbreken. Dat heeft het opbouwen en steeds herconfigeren van zo’n 300 services namelijk een stuk eenvoudiger gemaakt.
Bij deze wil ik graag alle field engineers, netwerk engineers, productmanagers, netwerkarchitecten, softwareontwikkelaars, projectmanagers en planners bedanken voor hun bijdrage aan dit succes.
0 Praat mee