Nätverksfabriken för datacenter Cisco ACI - till hjälp för administratören

Med hjälp av detta magiska stycke skript kan Cisco ACI snabbt ställa in nätverket.

Nätverksfabriken för datacenter Cisco ACI har funnits i fem år, men på Habr har det knappt skrivits något om den, så jag beslutade mig för att rätta till detta lite. Jag kommer att berätta utifrån min egen erfarenhet vad det handlar om, vilken nytta den har och vilka problem den kan medföra.

Vad är det och varifrån kom det?

Vid tillkännagivandet av ACI (Application Centric Infrastructure) 2013 trängde konkurrenter mot de traditionella nätverksmetoderna för datacenter på tre fronter.

Å ena sidan lovade SDN-lösningar "första generationen" baserade på OpenFlow att göra nätverken både mer flexibla och billigare samtidigt. Idén var att flytta beslutsfattande, som traditionellt utfördes av proprietär mjukvara på switcharna, till en central kontroller.

Denna kontroller skulle ha en gemensam syn på allt som händer och, baserat på detta, programmera hårdvaran för alla switchar på nivå av regler för behandling av specifika flöden.
Å andra sidan gav överlagrade nätverkslösningar möjlighet att implementera önskad anslutning och säkerhetspolicy helt utan förändringar i det fysiska nätverket, genom att bygga programvarutunnlar mellan virtualiserade värdar. Det mest kända exemplet på en sådan lösning var Nicira, som vid den tiden redan hade förvärvats av VMWare för 1,26 miljarder dollar och gav upphov till det nuvarande VMWare NSX. En viss krydda till situationen tillfördes av att medgrundarna av Nicira var samma personer som tidigare stod bakom OpenFlow, som nu sa att för att bygga datacenterfabriken är OpenFlow olämpligt..

Slutligen har switchchip som är tillgängliga på den öppna marknaden (det som kallas merchant silicon) nått en mognadsgrad där de utgör ett verkligt hot mot traditionella switchtillverkare. Tidigare designade varje tillverkare sina egna chip för sina switchar, men med tiden har chip från tredjepartsleverantörer, framför allt från Brоadcom, successivt kommit ikapp tillverkarens chip när det gäller funktioner, och i pris/prestandaförhållande överträffat dem. Därför ansåg många att dagarna för switchar med egenutvecklade chip var räknade.

ACI blev Cisco's "asymmetriska svar" (eller snarare, företaget Insieme som gick in i Cisco, grundat av tidigare anställda) på allt detta.

Vad är skillnaden med OpenFlow?

Ur ett funktionellt fördelningsperspektiv är ACI faktiskt motsatsen till OpenFlow.
I OpenFlow-arkitekturen ansvarar controllern för att skriva detaljerade regler (flöden)
till hårdvaran i alla switchar, vilket innebär att i ett stort nätverk kan den ha ansvar för att upprätthålla och, viktigast av allt, ändra tiotals miljoner poster på hundratals punkter i nätverket, så dess prestanda och tillförlitlighet i stora implementationer blir en flaskhals.

I ACI används en omvänd metod: det finns också en controller, men switcharna får hög-nivå deklarativa policyer från den, och rendering av detaljerade inställningar i hårdvaran utförs av själva switchen. Controllern kan startas om eller stängas av helt, och inget dåligt kommer hända med nätverket, förutom att det för tillfället inte går att styra. Intressant nog finns det situationer i ACI där OpenFlow ändå används, men lokalt inom värden för programmering av Open vSwitch.

ACI är helt byggd på overlay-transport baserat på VXLAN, men inkluderar också underliggande IP-transport inom en enda lösning. Cisco har kallat detta begrepp "integrerad overlay". Som terminationspunkt för overlay i ACI används oftast fabriks-switchar (de gör detta med kanalens hastighet). Värdar behöver inte veta något om fabriken, inkapsling och så vidare, men i vissa fall (till exempel för att ansluta OpenStack-värdar) kan VXLAN-trafik gå ända till dem.

Overlay används i ACI inte bara för att säkerställa flexibel konnektivitet via transportnätet, utan också för att överföra metainformation (den används till exempel för att tillämpa säkerhetspolicyer).

Broadcoms chippar har tidigare använts av Cisco i Nexus 3000-switchar. Familjen Nexus 9000, som särskilt släpptes för att stödja ACI, implementerade ursprungligen en hybridmodell som kallades Merchant+. I switchen användes både den nya Broadcom Trident 2-chippet och ett komplementerande chip från Cisco som gjorde hela ACI-magin möjlig. Detta tycks ha gjort det möjligt att snabba upp produktlanseringen och sänka switchens pris till en nivå nära modeller med endast Trident 2. Denna strategi räckte i de första två till tre åren av ACI-leveranser. Under denna tid utvecklade och släppte Cisco nästa generations Nexus 9000 med sina egna chipp som hade högre prestanda och funktioner, men på samma prisklass. De externa specifikationerna för fabrikens interaktion förblev helt intakta. Dessutom ändrades den interna hårdvaran helt: något som liknar refaktorisering, men för hårdvara.

Hur Cisco ACI:s arkitektur fungerar

I sin enklaste form byggs ACI upp enligt Clos-nätverks topologi, eller som det ofta kallas, Spine-Leaf. Antalet Spine-switchar kan vara från två (eller en, om vi inte är bekymrade över redundans) till sex. Ju fler Spine-switchar, desto högre redundans (mindre bandbreddsnedgång och tillförlitlighet vid fel eller underhåll av en Spine) och total prestanda. Alla externa anslutningar går till Leaf-switcharna: detta inkluderar både servrar, anslutningar till externa nätverk via L2 eller L3, samt kopplingar till APIC-kontroller. Generellt sett sker inte bara konfigurationen av ACI utan även insamling av statistik, övervakning av fel och andra uppgifter - allt görs via kontrollerarnas gränssnitt, där det i vanliga implementeringar finns tre stycken.

Du behöver aldrig ansluta en konsol till switcharna, inte ens för att starta nätverket: kontrollerna upptäckter själv switcharna och bygger fabriken med hjälp av inställningarna för alla tjänsteprotokoll, vilket är anledningen till att det är viktigt att notera serienumren på den installerade utrustningen vid installationen, så att man inte behöver gissa vilken switch som finns i vilken rack. För felsökning kan du vid behov ansluta till switcharna via SSH: på dem återges de vanliga Cisco show-kommandona med stor noggrannhet.

Inuti fabriken används IP-transport, så det finns inga Spanning Tree och andra skräckhistorier från det förflutna: alla länkar är aktiva, och konvergens vid fel är mycket snabb. Trafiken i fabriken överförs via tunnlar baserade på VXLAN. Mer specifikt kallar Cisco själva inkapslingen iVXLAN, och det som skiljer den från vanlig VXLAN är att reserverade fält i det nätverksövergripande huvudet används för att överföra informationsdata, framför allt om trafikens förhållande till EPG-gruppen. Detta möjliggör implementering av interaktionsregler mellan grupper i hårdvaran, vilket använder deras nummer på samma sätt som adresser används i vanliga åtkomstlistor.

Tunnlar möjliggör att sträcka både L2-segment och L3 (dvs. VRF) över intern IP-transport. Här är standardgatewayen distribuerad. Det betyder att varje switch ansvarar för routingen av den inkommande trafiken i fabriken. När det gäller logiken för trafiköverföring liknar ACI en fabrik baserad på VXLAN/EVPN.

Om så är fallet, vad är skillnaderna? I allt annat!

Den första skillnaden man stöter på i ACI är hur servrar kopplas till nätverket. I traditionella nätverk ansluts både fysiska servrar och virtuella maskiner till VLAN, och allt annat härstammar därifrån: anslutning, säkerhet etc. I ACI används en konstruktion som Cisco kallar EPG (End-point Group), som man inte kan undkomma. Kan man likställa den med VLAN? Ja, men i så fall finns det risk att mycket av det som ACI erbjuder går förlorat.

När det gäller EPG formuleras alla åtkomstregler, och i ACI används som standard principen om 'vitlista', vilket innebär att endast trafik vars genomsläpptande är uttryckligen tillåtet får passera. Det betyder att vi kan skapa EPG-grupper 'Web' och 'MySQL' och definiera en regel som tillåter interaktion mellan dem endast via port 3306. Detta kommer att fungera utan koppling till nätverksadresser, även inom samma subnät!

Vi har kunder som valt ACI just på grund av denna funktion, eftersom den tillåter att begränsa åtkomsten mellan servrar (virtuella eller fysiska – spelar ingen roll) utan att flytta dem mellan subnät, vilket innebär att adresseringen inte berörs. Ja, vi vet, ingen skriver ju ner det för hand IP-adresser i applikationskonfigurationer, eller hur?

Regler för trafikflöden i ACI kallas kontrakt. I ett sådant kontrakt blir en eller flera grupper eller nivåer i en mångskiktad applikation tjänsteleverantörer (som en databas-tjänst), medan andra blir konsumenter. Kontraktet kan helt enkelt släppa igenom trafiken, eller göra något mer avancerat, till exempel dirigera den till en brandvägg eller lastbalanserare, samt ändra QoS-värdet.

Hur hamnar servrar i dessa grupper? Om det handlar om fysiska servrar eller något som ingår i ett existerande nätverk där vi har skapat en VLAN-trunk, så måste vi peka på switchporten och den använda VLAN för att sätta dem i EPG. Som vi ser dyker VLAN upp där de är nödvändiga.

Om servrarna är virtuella maskiner räcker det att hänvisa till den anslutna virtualiseringsmiljön, och sedan händer allt automatiskt: en portgrupp (om vi pratar i termer av VMWare) skapas för att ansluta VM, nödvändiga VLAN eller VXLAN tilldelas, och skrivs in på de nödvändiga switchportarna, och så vidare. Så även om ACI är byggd kring ett fysiskt nätverk är kopplingarna för virtuella servrar mycket enklare än för fysiska. ACI har redan inbyggd integration med VMWare och MS Hyper-V, samt stöd för OpenStack och RedHat Virtualization. Från en viss punkt har det även tillkommit inbyggt stöd för containerplattformar: Kubernetes, OpenShift, Cloud Foundry, vilket även omfattar tillämpning av policys och övervakning, så nätverksadministratören kan direkt se vilka pods som körs på vilka värdar och i vilka grupper de tillhör.

Förutom att ingå i en eller annan portgrupp har virtuella servrar även extra egenskaper: namn, attribut osv., som kan användas som kriterier för att flytta dem till en annan grupp, till exempel vid omdöpning av VM eller om den får en extra tagg. Cisco kallar detta mikrosektionsgrupper, även om själva konstruktionen som möjliggör att skapa flera säkerhetssegment i form av EPG i samma subnet också kan betraktas som mikrosegregering. Nåväl, leverantören vet nog bäst.

Själva EPG:erna är helt logiska konstruktioner, som inte är kopplade till specifika switchar, servrar, etc., så man kan göra saker med dem och konstruktioner baserade på dem (applikationer och tenants) som är svåra att göra i vanliga nätverk, till exempel kloning. Som ett resultat är det ganska enkelt att skapa en klon av en produktionsmiljö för att få en testmiljö som garanterat är identisk med produktionen. Det kan göras manuellt, men det är bättre (och enklare) via API.

Generellt sett är logiken för hantering i ACI inte alls lik den man vanligtvis stöter på
i traditionella nätverk från samma Cisco: det programvarubaserade gränssnittet är primärt, medan GUI eller CLI är sekundära, eftersom de arbetar via samma API. Därför börjar nästan alla som arbetar med ACI att efter en tid orientera sig i den objektmodellen som används för hantering och automatisera något efter sina behov. Det är enklast att göra detta från Python: det finns praktiska färdiga verktyg för det.

De lovade fallgroparna

Huvudproblemet är att många saker i ACI är gjorda på ett annat sätt. För att börja arbeta normalt med det behöver man lära om. Detta gäller särskilt nätverksdriftsteam hos stora kunder, där ingenjörer i åratal har sysslat med "att registrera VLAN:er" efter begäran. Det att VLAN nu inte längre är VLAN, och att man inte behöver skapa VLAN:er för att lägga nya nätverk i virtualiserade värdar, "slår helt ut" traditionella nätverksarbetare och tvingar dem att hålla sig kvar vid sina vanliga metoder. Det bör noteras att Cisco har försökt att göra det lite lättare genom att lägga till en "NXOS-liknande" CLI i kontrollern, vilket gör det möjligt att göra inställningar från ett gränssnitt som liknar traditionella switchar. Men för att börja använda ACI på ett bra sätt kommer man fortfarande att behöva förstå hur det fungerar.

Ur ett kostnadsperspektiv skiljer sig nätverket ACI från traditionella nätverk baserade på Cisco-utrustning i stort sett inte, eftersom de använder samma switchar för att byggas upp (Nexus 9000 kan fungera både i ACI- och traditionellt läge och har nu blivit den främsta "arbetshästen" för nya datacenterprojekt). Men för datacenter innebär närvaron av kontroller och Spine-Leaf-arkitektur förstås en skillnad mellan de två switcharna. Nyligen lanserades Mini ACI-fabriken, där två av tre kontroller har ersatts av virtuella maskiner. Detta gör det möjligt att minska kostnadsskillnaden, men den kvarstår ändå. Så för kunden bestäms valet av hur intresserad han är av säkerhetsfunktioner, integration med virtualisering, enhetlig kontrollpunkt och annat.

Källa: habr.com