Technote

Så bygger du en pålitlig ACI-miljö

Cisco ACI kan vara motorn som driver ditt datacenter med stabilitet och hastighet. Men bara om du konfigurerar det rätt. Många små misstag leder till stora problem, från nätverksstörningar till driftstopp. Här får du praktiska tips och insikter som hjälper dig undvika fallgropar och skapa en robust ACI-miljö från start.

Cisco ACI (Application Centric Infrastructure) har snabbt blivit en pålitlig hörnsten i många datacenter. Men trots den höga graden av automatisering och smarta funktioner kan felkonfigurationer leda till allt från sporadiska nätverksproblem till omfattande driftstopp. Med rätt kunskap och planering går det att undvika de flesta fallgropar.

Här är några av de viktigaste insikterna – och tipsen som hjälper dig bygga en robust och pålitlig ACI-miljö.

Grunderna i Cisco ACI: Roller, pods och multisitestöd

Cisco ACI bygger på ett leaf-spine-arkitektur med Nexus 9000-switchar. Leaf-noder ansluter servrar, brandväggar och annan infrastruktur, medan spine-noder hanterar trafiken mellan dem. Allt styrs centralt via APIC-kontroller som definierar policys för kommunikation.

När du designar din miljö bör du känna till skillnaden mellan Single Pod, Multi-Pod och Multisite. Multi-Pod används idag istället för äldre Stretched Fabric, då det minskar risken för resurskonflikter i nätet. Multisite innebär två separata ACI-fabriker som styrs av Nexus Dashboard Orchestrator, vilket ger bättre flexibilitet över långa avstånd.

En viktig rekommendation är att alltid kontrollera round-trip-tiderna: Multi-Pod klarar max 150 ms, medan Multisite tillåter upp till 1 sekund.

3 vanliga konfigurationsmissar och hur du undviker dem

1. Felaktig APIC-anslutning

Ett vanligt problem är att APIC-controllers får felkopplade portar. Alla APIC-enheter har CIMC (för out-of-band management), management-portar och SFP-portar mot leaf-switchar. Det är avgörande att koppla rätt kombination av SFP-portar (t.ex. port 1 och 3) eftersom vissa par bildar logiska bondar. Kopplar du fel kan APIC tappa kontakten med nätet.

Tips: Dokumentera alltid vilka portar som är anslutna, och sprid APIC-anslutningarna över olika leaf-switchar för redundans.

2. Endpoint Learning och loophantering

ACI:s standardläge tillåter dynamisk inlärning av IP och MAC-adresser. Det kan skapa problem om exempelvis en virtuell maskin plötsligt börjar agera brygga mellan nät. Då lär sig ACI alla IP-adresser bakom samma MAC, vilket snabbt överbelastar kontrollplanet.

Så löser du det:

• Aktivera Limit Local IP Learning eller Enforce Subnet Check för att förhindra inlärning av IP-adresser som inte tillhör rätt subnet.
• Slå på Endpoint IP Aging så IP-adresser tidsstämplas separat från MAC-adresser.

3. Spanning Tree och BPDU-hantering

När du kopplar in switchar med Spanning Tree måste du välja strategi. ACI deltar inte själv i Spanning Tree utan vidarebefordrar bara BPDUs. Två alternativ finns:

• BPDU Guard, som blockerar portar vid BPDU-detektion.
• BPDU Filtering, som helt stoppar BPDUs.

BPDU Filtering anses ofta vara bästa valet för att undvika oavsiktliga blockeringar. Detta implementeras i switcharna som inte är med i ACI.

Fem vanliga driftproblem och hur du löser dem

I praktiken uppstår ofta återkommande problem i ACI-miljöer som påverkar hur pålitlig den ör, men de går att förebygga med tydliga rutiner och rätt konfiguration. Här är några av de vanligaste scenarierna och lösningarna.

1. APIC i oändlig boot-loop

Ett exempel är APIC-enheter som fastnar i en oändlig boot-loop, vilket ofta orsakas av inkompatibla CIMC-versioner. För att undvika detta bör CIMC alltid uppgraderas i samband med att ACI-programvaran på APIC uppgraderas. Om felet redan inträffat kan det ibland räcka att koppla ur strömmen från APIC i ett par minuter, starta om enheten och sedan uppgradera till den senaste rekommenderade CIMC-versionen.

2. Felaktig inlärning av IP-adresser

Ett annat problem är att virtuella servrar eller load balancers börjar lära ut ett stort antal IP-adresser bakom samma MAC-adress. Då kan trafiken mot övriga endpoints i nätet sluta fungera eller upplevas som mycket långsam. Genom att aktivera Limit Local IP Learning eller Enforce Subnet Check kan man tvinga ACI att bara lära sig IP-adresser som faktiskt tillhör det lokala nätverket och därmed undvika störningar.

3. Trafik från fel nätverkskort

Virtuella Linuxservrar som har flera nätverkskort kan också skapa problem om trafiken kommer in på ett interface och går ut på ett annat. I sådana fall ser ACI felaktiga kombinationer av IP- och MAC-adresser, vilket leder till paketförluster på uppemot 20–25 procent. Det bästa är att införa striktare routingpolicies i servern. Så att svar alltid går ut via samma nätverkskort som trafiken kom in på. Men om det inte är möjligt kan samma funktionalitet uppnås genom att begränsa IP-inlärningen i ACI.

4. Problem med Spanning Tree

En annan fallgrop är när ACI kopplas till switchar som kör Spanning Tree. Om Topology Change Notifications skickas kan hela endpoint-databasen för ett VLAN rensas, vilket leder till kortare eller längre avbrott. Undvik detta genom att aktivera BPDU Filtering på portarna mot ACI i Spanning Tree-nätet, så att ACI ignorerar BPDUs utan att blockera anslutningarna.

5. Störningar vid uppgraderingar

Slutligen är det vanligt att uppgraderingar av miljön leder till driftstörningar, särskilt om ordningen mellan CIMC, APIC-programvaran och Nexus-switcharnas mjukvara inte följs.

Sida

Cisco ACI

Läs

Uppgradering – steg för steg

Att uppgradera Cisco ACI kräver noggrann planering. Men du behöver bara hantera tre komponenter: Nexus-switcharnas mjukvara, APIC-programvaran och CIMC-firmware. Ett tydligt steg-för-steg-flöde är avgörande:

1. Uppgradera CIMC på APICarna till en version som stöds av både nuvarande och nya APIC-programvaran.
2. Uppgradera APIC-programvaran.
3. Uppgradera CIMC till den senaste versionen som stöds av den ny ACI versionen.
4. Uppgradera Nexus-switcharna i omgångar.

Uppgradering av APIC’s tar ca 45 minuter och utförs på 1 APIC i taget. Då varje APIC är en del i ett kluster innebär detta att denna uppgradering kan utföras utan servicefönster

Uppgraderingen av Nexus switcharna görs i grupper, alla switchar i gruppen uppgraderas samtidigt. Uppgraderingen tar ca 30-45 minuter, så planera servicefönster därefter.

Planering och dokumentation grunden för pålitlig ACI

Cisco ACI är kraftfullt, men komplexiteten gör det lätt att gå fel. Avslutningsvis, några grundtips för en stabil drift är att kontrollera alla kompatibiliteter inför uppgraderingar, dokumentera anslutningar noggrant, begränsa inlärning av endpoints och använda BPDU Filtering vid integration med Spanning Tree. Men med ett strukturerat arbetssätt går det att undvika de flesta störningar och bygga en stabil och flexibel plattform.

Om författaren