“Er wordt gepraat over Policies, Application Profiles en EPGs, maar ik heb een bestaand datacenter; hoe kunnen deze omgevingen met elkaar communiceren?” Dit is een vraag die ik vaak krijg op het moment dat klanten overtuigd zijn van de kracht van een ACI-netwerk. Weinig omgevingen zijn namelijk greenfield.
Theoretisch is het mogelijk om vooraf het gehele applicatielandschap te inventariseren, modeleren en vervolgens te segmenteren in diverse applicatie-tiers en zogenaamde End Point Groups (EPGs). Het is toch immers een ‘application centric’-netwerk? Toch blijkt in de praktijk dat dit voor veel klanten een brug te ver is. In dit blog leg ik in vijf eenvoudige stappen uit hoe je een network-centric migratie van een bestaand netwerk naar Cisco ACI kunt doen.
Stap 1: bouw een ACI fabric op naast het bestaande netwerk
De eerste stap is het opbouwen van een ACI fabric. Dit hoeft niet direct enorm uitgebreid te zijn. Sommige klanten beginnen met een kleine fabric van twee spines en twee leafs, soms in maar één rack, om zo stapsgewijs een migratie van workloads te doen naar ACI. De ACI fabric kan eenvoudig worden uitgebreid, mocht er later extra capaciteit nodig zijn.
Stap 2: verbind de omgevingen met L2
Zodra de ACI fabric operationeel is, kan er bijvoorbeeld een L2-trunk (back-to-back) vPC tussen de aggregatielaag van het bestaande netwerk en de border leafs van het ACI-netwerk worden gemaakt. Zoals je waarschijnlijk weet, classificeert ACI netwerkverkeer in EPGs. Dit kan op basis van een dot1q-tag. De meest eenvoudige manier ter voorbereiding van een migratie is om een één-op-één-mapping te maken van één VLAN-tag per EPG. Per EPG wordt er een apart Bridge Domain (BD) gebruikt. Het is van belang dat in de instellingen van het BD flooding van BUM-verkeer wordt toegestaan. Op deze manier kun je VLANs die leven in het bestaande netwerk één op één doorzetten naar de ACI fabric.
Om een voorbeeld te geven: VLAN 1950 in het bestaande netwerk wordt bijvoorbeeld EPG-1950 in ACI.
Optioneel bij stap 2: automatisering van de ACI fabric
Bij grote hoeveelheden VLANs kan het snel een tijdrovende taak worden om dit handmatig met de APIC GUI te configureren. Aangezien een ACI fabric programmeerbaar is, is het uiteraard ook mogelijk om dit hele proces te automatiseren. Voor een Proof of Concept heb ik een script geschreven dat dit proces met behulp van een wizard doorloopt. Het is wel een vereiste om de ACI-toolkit op je systeem te hebben. De input van het script is een csv-file met input “show vlan” command op een switch in het bestaande netwerk. Link naar een voorbeeld csv-bestand en het script kun je hier vinden: https://github.com/robvand/ACI-Migration.
Stap 3: migreer de virtuele en fysieke workloads
Er is nu end-to-end L2-connectiviteit. Zo kan er compute capaciteit aan de fabric worden gekoppeld om een vDS te stretchen over beide omgevingen. Door het stretchen van de netwerken kunnen VM’s, maar ook fysieke workloads, eenvoudig worden opgepakt en verplaatst naar de ACI fabric, zonder dat er IP-adres- of VLAN-wijzigingen nodig zijn. De default gateway voor alle gekoppelde VLANs leeft immers nog in het bestaande netwerk.
Stap 4: sluit nieuwe workloads aan op de fabric
Voor nieuwe workloads kun je nu policies bedenken in ACI. Wellicht al op een ‘application centric’ manier. Zo kan de ACI fabric een distributed anycast gateway bieden voor alle nieuwe workloads, terwijl de gemigreerde workloads nog steeds communiceren via het bestaande netwerk. In het voorbeeld is de distributed switch vDS-02 alleen beschikbaar in de ACI fabric. Voor externe communicatie wordt er een L3 routed link naar de core of edge van het oude netwerk opgezet.
Stap 5: faseer het bestaande netwerk uit
Zodra alle workloads verplaatst zijn naar Cisco ACI, kan de edge van het netwerk aan ACI worden gekoppeld en de ACI fabric de default gateway worden voor alle één-op-één-doorgezette VLANs.
Authors
