Med hjälp av denna magiska del av Cisco ACI-skriptet kan du snabbt sätta upp ett nätverk.
Nätverksfabriken för Cisco ACI-datacentret har funnits i fem år, men Habré sa egentligen ingenting om det, så jag bestämde mig för att fixa det lite. Jag ska berätta för dig av min egen erfarenhet vad det är, vad det är för användning och var det har en rake.
Vad är det och var kom det ifrån?
När ACI (Application Centric Infrastructure) tillkännagavs 2013, gick konkurrenterna framåt på traditionella metoder för datacenternätverk från tre sidor samtidigt.
Å ena sidan lovade "första generationens" SDN-lösningar baserade på OpenFlow att göra nätverk mer flexibla och billigare på samma gång. Tanken var att flytta beslutsfattandet som traditionellt görs av proprietär switchprogramvara till en central styrenhet.
Denna styrenhet skulle ha en enda vision av allt som händer och baserat på detta skulle den programmera hårdvaran för alla switchar på nivån av regler för bearbetning av specifika flöden.
Å andra sidan gjorde överlagringsnätverkslösningar det möjligt att implementera nödvändiga anslutnings- och säkerhetspolicyer utan några förändringar i det fysiska nätverket alls, och byggde mjukvarutunnlar mellan virtualiserade värdar. Det mest kända exemplet på detta tillvägagångssätt var Nicira, som då redan hade förvärvats av VMWare för 1,26 miljarder dollar och gav upphov till den nuvarande VMWare NSX. En viss pikantitet av situationen lades till av det faktum att medgrundarna av Nicira var samma personer som tidigare stod vid ursprunget till OpenFlow, och nu sa att för att bygga en datacenterfabrik .
Och slutligen har växlingschips som finns tillgängliga på den öppna marknaden (det som kallas handelskisel) nått ett mognadsstadium där de har blivit ett verkligt hot mot traditionella switchtillverkare. Om varje leverantör tidigare självständigt utvecklade chips för sina switchar, började chips från tredjepartstillverkare, främst från Broadcom, med tiden att minska avståndet till leverantörschips när det gäller funktioner och överträffade dem när det gäller pris/prestandaförhållande. Därför trodde många att dagarna med strömbrytare på chips av sin egen design var räknade.
ACI har blivit Ciscos "asymmetriska svar" (närmare bestämt dess Insieme-företag, grundat av dess tidigare anställda) på allt ovanstående.
Vad är skillnaden med OpenFlow?
När det gäller distribution av funktioner är ACI faktiskt motsatsen till OpenFlow.
I OpenFlow-arkitekturen är regulatorn ansvarig för att skriva detaljerade regler (flöden)
i hårdvaran för alla switchar, det vill säga i ett stort nätverk, kan det vara ansvarigt för att underhålla och, viktigast av allt, ändra tiotals miljoner poster på hundratals punkter i nätverket, så dess prestanda och tillförlitlighet blir en flaskhals i en stort genomförande.
ACI använder det omvända tillvägagångssättet: naturligtvis finns det också en kontroller, men switcharna får deklarativa policyer på hög nivå från den, och switchen själv utför sin återgivning till detaljer om specifika inställningar i hårdvaran. Styrenheten kan startas om eller stängas av helt och hållet, och inget dåligt kommer att hända med nätverket, förutom, naturligtvis, bristen på kontroll för närvarande. Intressant nog finns det situationer i ACI där OpenFlow fortfarande används, men lokalt inom värden för Open vSwitch-programmering.
ACI bygger helt på VXLAN-baserad överlagringstransport, men inkluderar den underliggande IP-transporten som en del av en enda lösning. Cisco kallade detta termen "integrerad överlagring". Som avslutningspunkt för överlägg i ACI används i de flesta fall fabriksbrytare (de gör detta med länkhastighet). Värdar behöver inte veta något om fabriken, inkapsling etc., men i vissa fall (till exempel för att ansluta OpenStack-värdar) kan VXLAN-trafik föras till dem.
Överlagringar används i ACI inte bara för att tillhandahålla flexibel anslutning via transportnätverket, utan också för att överföra metainformation (den används till exempel för att tillämpa säkerhetspolicyer).
Chips från Broadcom användes tidigare av Cisco i switcharna i Nexus 3000. I familjen Nexus 9000, speciellt släppt för att stödja ACI, implementerades ursprungligen en hybridmodell som kallades Merchant +. Switchen använde samtidigt både det nya Broadcom Trident 2-chippet och ett kompletterande chip utvecklat av Cisco, som implementerar all magin med ACI. Uppenbarligen gjorde detta det möjligt att påskynda lanseringen av produkten och sänka prislappen för växeln till en nivå nära modeller helt enkelt baserade på Trident 2. Detta tillvägagångssätt räckte för de första två eller tre åren av ACI-leveranser. Under denna tid har Cisco utvecklat och lanserat nästa generations Nexus 9000 på egna marker med mer prestanda och funktionsuppsättning, men till samma prisnivå. Externa specifikationer vad gäller interaktion i fabriken är helt bevarade. Samtidigt har den interna fyllningen helt förändrats: ungefär som refactoring, men för hårdvara.
Hur Cisco ACI-arkitekturen fungerar
I det enklaste fallet är ACI byggt på topologin i Klose-nätverket, eller, som de ofta säger, Spine-Leaf. Omkopplare på ryggradsnivå kan vara från två (eller en, om vi inte bryr oss om feltolerans) till sex. Följaktligen, ju fler av dem, desto högre feltolerans (desto lägre bandbredd och tillförlitlighetsminskning i händelse av en olycka eller underhåll av en Spine) och den totala prestandan. Alla externa anslutningar går till switchar på lövnivå: dessa är servrar och dockning med externa nätverk via L2 eller L3 och anslutande APIC-kontroller. I allmänhet, med ACI, inte bara konfiguration, utan också statistikinsamling, felövervakning och så vidare - allt görs genom gränssnittet för kontroller, av vilka det finns tre i standardstorlekar.
Du behöver aldrig ansluta till switcharna med konsolen, inte ens för att starta nätverket: styrenheten upptäcker själv switcharna och sätter ihop en fabrik från dem, inklusive inställningarna för alla serviceprotokoll, därför är det förresten mycket viktigt att skriv ner serienumren på utrustningen som installeras under installationen, så att du senare inte behöver gissa vilken strömbrytare som sitter i vilket rack. För felsökning kan du vid behov ansluta till switcharna via SSH: de återger de vanliga Cisco-showkommandona ganska noggrant.
Internt använder fabriken IP-transport, så det finns inget Spanning Tree och andra fasor från det förflutna i den: alla länkar är inblandade, och konvergensen i händelse av misslyckanden är mycket snabb. Trafiken i väven överförs genom tunnlar baserade på VXLAN. Närmare bestämt kallar Cisco själv iVXLAN-inkapsling, och det skiljer sig från vanligt VXLAN genom att de reserverade fälten i nätverkshuvudet används för att överföra tjänstinformation, i första hand om trafikens förhållande till EPG-gruppen. Detta gör att du kan implementera reglerna för interaktion mellan grupper i utrustningen genom att använda deras nummer på samma sätt som adresser används i vanliga åtkomstlistor.
Tunnlar tillåter både L2-segment och L3-segment (dvs. VRF) att sträckas genom den interna IP-transporten. I det här fallet distribueras standardgatewayen. Detta innebär att varje switch är ansvarig för att dirigera trafiken som kommer in i väven. När det gäller trafikflödeslogik liknar ACI ett VXLAN/EVPN-tyg.
Om så är fallet, vilka är skillnaderna? Allt annat!
Den största skillnaden du stöter på med ACI är hur servrar är anslutna till nätverket. I traditionella nätverk går inkluderingen av både fysiska servrar och virtuella maskiner till VLAN och allt annat dansar av dem: uppkoppling, säkerhet etc. I ACI används en design som Cisco kallar EPG (End-point Group), varifrån det finns ingenstans att komma undan. Om det är möjligt att likställa det med VLAN? Ja, men i det här fallet finns det en chans att förlora det mesta av vad ACI ger.
När det gäller EPG är alla åtkomstregler formulerade, och i ACI används principen "vit lista" som standard, det vill säga endast trafik är tillåten, vars passage är uttryckligen tillåten. Det vill säga, vi kan skapa EPG-grupperna "Web" och "MySQL" och definiera en regel som tillåter kommunikation mellan dem endast på port 3306. Detta kommer att fungera utan att vara bunden till nätverksadresser och till och med inom samma subnät!
Vi har kunder som har valt ACI just på grund av den här funktionen, eftersom den låter dig begränsa åtkomsten mellan servrar (virtuell eller fysisk - det spelar ingen roll) utan att dra dem mellan undernät, vilket innebär utan att röra adresseringen. Ja, ja, vi vet att ingen skriver ut IP-adresser i applikationskonfigurationer för hand, eller hur?
Trafikregler i ACI kallas kontrakt. I ett sådant kontrakt blir en eller flera grupper eller nivåer i en flerskiktsapplikation en tjänsteleverantör (säg en databastjänst), andra blir en konsument. Kontraktet kan helt enkelt skicka trafik, eller så kan det göra något mer knepigt, till exempel dirigera det till en brandvägg eller balanserare, och även ändra QoS-värdet.
Hur kommer servrar in i dessa grupper? Om dessa är fysiska servrar eller något som ingår i ett befintligt nätverk där vi skapade en VLAN-trunk, måste du för att placera dem i EPG:n peka på switchporten och VLAN som används på den. Som du kan se visas VLAN där du inte klarar dig utan dem.
Om servrarna är virtuella maskiner räcker det att hänvisa till den anslutna virtualiseringsmiljön, och då kommer allt att hända av sig självt: en portgrupp kommer att skapas (i termer av VMWare) för att ansluta den virtuella datorn, de nödvändiga VLAN eller VXLAN kommer att skapas tilldelas kommer de att registreras på nödvändiga switchportar etc. Så även om ACI är uppbyggt kring ett fysiskt nätverk ser anslutningar för virtuella servrar mycket enklare ut än för fysiska. ACI har redan inbyggd anslutning med VMWare och MS Hyper-V, samt stöd för OpenStack och RedHat Virtualization. Från någon tidpunkt har även inbyggt stöd för containerplattformar dykt upp: Kubernetes, OpenShift, Cloud Foundry, samtidigt som det handlar om både tillämpning av policyer och övervakning, det vill säga att nätverksadministratören direkt kan se vilka värdar vilka pods arbetar på och vilka grupper de faller i.
Förutom att vara inkluderade i en viss portgrupp har virtuella servrar ytterligare egenskaper: namn, attribut etc., som kan användas som kriterier för att överföra dem till en annan grupp, t.ex. när en virtuell dator byter namn eller en extra tagg visas i Det. Cisco kallar detta för mikrosegmenteringsgrupper, även om själva designen i stort med möjligheten att skapa många säkerhetssegment i form av EPG:er på samma subnät också är en ganska mikrosegmentering. Tja, säljaren vet bättre.
EPG:er i sig är rent logiska konstruktioner, inte knutna till specifika switchar, servrar etc., så du kan göra saker med dem och konstruktioner utifrån dem (applikationer och hyresgäster) som är svåra att göra i vanliga nätverk, såsom kloning. Som ett resultat, låt oss säga att det är väldigt enkelt att klona en produktionsmiljö för att få en testmiljö som garanterat är identisk med produktionsmiljön. Du kan göra det manuellt, men det är bättre (och enklare) genom API:et.
Generellt sett är kontrolllogiken i ACI inte alls lik den man brukar möta
i traditionella nätverk från samma Cisco: mjukvarugränssnittet är primärt, och GUI eller CLI är sekundära, eftersom de fungerar genom samma API. Därför börjar nästan alla inblandade i ACI, efter ett tag, att navigera i objektmodellen som används för hantering och automatisera något för att passa deras behov. Det enklaste sättet att göra detta är från Python: det finns praktiska färdiga verktyg för det.
Utlovad rake
Huvudproblemet är att många saker i ACI görs annorlunda. För att börja arbeta med det normalt måste du träna om. Detta gäller särskilt för nätverksdriftsteam hos stora kunder, där ingenjörer har "föreskrivit VLAN" i flera år på begäran. Det faktum att nu VLAN inte längre är VLAN, och du inte behöver skapa VLAN för hand för att skapa nya nätverk i virtualiserade värdar, blåser helt taket av traditionella nätverkare och får dem att hålla fast vid välbekanta tillvägagångssätt. Det bör noteras att Cisco försökte söta p-pillret lite och la till en "NXOS-liknande" CLI till kontrollern, vilket låter dig göra konfiguration från ett gränssnitt som liknar traditionella switchar. Men ändå, för att börja använda ACI normalt måste du förstå hur det fungerar.
När det gäller pris, på stora och medelstora skalor, skiljer sig ACI-nätverk inte från traditionella nätverk på Cisco-utrustning, eftersom samma switchar används för att bygga dem (Nexus 9000 kan fungera i ACI och i traditionellt läge och har nu blivit det viktigaste "arbetshäst" för nya datacenterprojekt). Men för datacenter med två switchar gör sig självklart närvaron av kontroller och Spine-Leaf-arkitektur. Nyligen har det dykt upp en Mini ACI-fabrik, där två av de tre kontrollerna är ersatta av virtuella maskiner. Detta minskar skillnaden i kostnad, men det finns fortfarande kvar. Så för kunden dikteras valet av hur mycket han är intresserad av säkerhetsfunktioner, integration med virtualisering, en enda kontrollpunkt och så vidare.
Källa: will.com