Ved hjelp av denne magiske delen av Cisco ACI-skriptet kan du raskt sette opp et nettverk.
Nettverksfabrikken for Cisco ACI-datasenteret har eksistert i fem år, men Habré sa egentlig ikke noe om det, så jeg bestemte meg for å fikse det litt. Jeg vil fortelle deg fra min egen erfaring hva det er, hva er bruken av det og hvor det har en rake.
Hva er det og hvor kom det fra?
Da ACI (Application Centric Infrastructure) ble annonsert i 2013, gikk konkurrentene videre med tradisjonelle tilnærminger til datasenternettverk fra tre sider samtidig.
På den ene siden lovet «førstegenerasjons» SDN-løsninger basert på OpenFlow å gjøre nettverk mer fleksible og billigere på samme tid. Ideen var å flytte beslutningstakingen som tradisjonelt gjøres av proprietær svitsjprogramvare til en sentral kontroller.
Denne kontrolleren vil ha en enkelt visjon av alt som skjer og, basert på dette, programmere maskinvaren til alle brytere på nivå med regler for behandling av spesifikke flyter.
På den annen side gjorde overliggende nettverksløsninger det mulig å implementere nødvendige tilkoblings- og sikkerhetspolicyer uten endringer i det fysiske nettverket i det hele tatt, og bygge programvaretunneler mellom virtualiserte verter. Det mest kjente eksemplet på denne tilnærmingen var Nicira, som da allerede var kjøpt opp av VMWare for 1,26 milliarder dollar og ga opphav til den nåværende VMWare NSX. Litt pikanthet av situasjonen ble lagt til av det faktum at medgründerne av Nicira var de samme menneskene som tidligere sto ved opprinnelsen til OpenFlow, og sa nå at for å bygge en datasenterfabrikk .
Og til slutt, byttebrikker som er tilgjengelige på det åpne markedet (det som kalles handelssilisium) har nådd et modenhetsstadium hvor de har blitt en reell trussel mot tradisjonelle bryterprodusenter. Hvis tidligere hver leverandør uavhengig utviklet brikker for sine brytere, begynte brikker fra tredjepartsprodusenter, først og fremst fra Broadcom, over tid å redusere avstanden med leverandørbrikker når det gjelder funksjoner, og overgikk dem når det gjelder pris / ytelsesforhold. Derfor trodde mange at dagene med brytere på brikker av eget design var talte.
ACI har blitt Ciscos "asymmetriske svar" (nærmere bestemt Insieme-selskapet, grunnlagt av dets tidligere ansatte) på alt det ovennevnte.
Hva er forskjellen med OpenFlow?
Når det gjelder distribusjon av funksjoner, er ACI faktisk det motsatte av OpenFlow.
I OpenFlow-arkitekturen er kontrolleren ansvarlig for å skrive detaljerte regler (flyter)
i maskinvaren til alle svitsjer, det vil si i et stort nettverk, kan den være ansvarlig for å vedlikeholde og, viktigst av alt, endre titalls millioner poster på hundrevis av punkter i nettverket, slik at ytelsen og påliteligheten blir en flaskehals i en stor gjennomføring.
ACI bruker den omvendte tilnærmingen: selvfølgelig er det også en kontroller, men bryterne mottar deklarative retningslinjer på høyt nivå fra den, og bryteren selv utfører sin gjengivelse til detaljer om spesifikke innstillinger i maskinvaren. Kontrolleren kan startes på nytt eller slås av helt, og ingenting dårlig vil skje med nettverket, bortsett fra selvfølgelig mangelen på kontroll i dette øyeblikket. Interessant nok er det situasjoner i ACI der OpenFlow fortsatt brukes, men lokalt innenfor verten for Open vSwitch-programmering.
ACI er bygget utelukkende på VXLAN-basert overleggstransport, men inkluderer den underliggende IP-transporten som en del av en enkelt løsning. Cisco kalte dette "integrert overlegg"-begrepet. Som et termineringspunkt for overlegg i ACI, brukes i de fleste tilfeller fabrikkbrytere (de gjør dette med koblingshastighet). Verter er ikke pålagt å vite noe om fabrikken, innkapsling osv., men i noen tilfeller (for eksempel for å koble til OpenStack-verter), kan VXLAN-trafikk bringes til dem.
Overlegg brukes i ACI ikke bare for å gi fleksibel tilkobling gjennom transportnettverket, men også for å overføre metainformasjon (den brukes for eksempel til å bruke sikkerhetspolicyer).
Chips fra Broadcom ble tidligere brukt av Cisco i bryterne i Nexus 3000-serien. I Nexus 9000-familien, spesielt utgitt for å støtte ACI, ble det opprinnelig implementert en hybridmodell, som ble kalt Merchant +. Switchen brukte samtidig både den nye Broadcom Trident 2-brikken og en komplementær brikke utviklet av Cisco, som implementerer all magien til ACI. Tilsynelatende gjorde dette det mulig å fremskynde utgivelsen av produktet og redusere prislappen på bryteren til et nivå nær modeller som bare var basert på Trident 2. Denne tilnærmingen var nok for de første to eller tre årene med ACI-leveranser. I løpet av denne tiden utviklet og lanserte Cisco neste generasjon Nexus 9000 på egne brikker med mer ytelse og funksjonssett, men til samme prisnivå. Eksterne spesifikasjoner når det gjelder samhandling i fabrikken er fullstendig bevart. Samtidig har den interne fyllingen endret seg fullstendig: noe sånt som refactoring, men for maskinvare.
Hvordan Cisco ACI-arkitekturen fungerer
I det enkleste tilfellet er ACI bygget på topologien til Klose-nettverket, eller, som de ofte sier, Spine-Leaf. Brytere på ryggnivå kan være fra to (eller én, hvis vi ikke bryr oss om feiltoleranse) til seks. Følgelig, jo flere av dem, jo høyere er feiltoleransen (jo lavere båndbredde og reduksjon av pålitelighet i tilfelle en ulykke eller vedlikehold av en Spine) og den generelle ytelsen. Alle eksterne tilkoblinger går til brytere på bladnivå: disse er servere, og dokking med eksterne nettverk via L2 eller L3, og koblende APIC-kontrollere. Generelt, med ACI, ikke bare konfigurasjon, men også innsamling av statistikk, feilovervåking og så videre - alt gjøres gjennom grensesnittet til kontrollere, hvorav det er tre i standardstørrelser.
Du trenger aldri å koble til bryterne med konsollen, selv for å starte nettverket: kontrolleren selv oppdager bryterne og setter sammen en fabrikk fra dem, inkludert innstillingene for alle tjenesteprotokoller, derfor er det forresten veldig viktig å skriv ned serienumrene til utstyret som installeres under installasjonen, slik at du senere slipper å gjette hvilken bryter som er i hvilket stativ som er plassert. For feilsøking, om nødvendig, kan du koble til bryterne via SSH: de gjengir de vanlige Cisco-showkommandoene ganske nøye.
Internt bruker fabrikken IP-transport, så det er ingen Spanning Tree og andre grusomheter fra fortiden i den: alle koblinger er involvert, og konvergens i tilfelle feil er veldig rask. Trafikken i stoffet overføres gjennom tunneler basert på VXLAN. Mer presist kaller Cisco selv iVXLAN-innkapsling, og det skiller seg fra vanlig VXLAN ved at de reserverte feltene i nettverkshodet brukes til å overføre tjenesteinformasjon, først og fremst om trafikkforholdet til EPG-gruppen. Dette lar deg implementere reglene for samhandling mellom grupper i utstyret, ved å bruke deres numre på samme måte som adresser brukes i vanlige tilgangslister.
Tunneler gjør at både L2-segmenter og L3-segmenter (dvs. VRF) kan strekkes gjennom den interne IP-transporten. I dette tilfellet er standard gateway distribuert. Dette betyr at hver svitsj er ansvarlig for å dirigere trafikken som kommer inn i stoffet. Når det gjelder trafikkflytlogikk, ligner ACI på et VXLAN/EVPN-stoff.
Hvis ja, hva er forskjellene? Alt annet!
Den største forskjellen du møter med ACI er hvordan servere er koblet til nettverket. I tradisjonelle nettverk går inkluderingen av både fysiske servere og virtuelle maskiner til VLAN, og alt annet danser fra dem: tilkobling, sikkerhet osv. I ACI brukes et design som Cisco kaller EPG (End-point Group), hvorfra det er ingen steder å komme unna. Om det er mulig å sidestille det med VLAN? Ja, men i dette tilfellet er det en sjanse for å miste det meste av det ACI gir.
Med hensyn til EPG er alle tilgangsregler formulert, og i ACI brukes "hviteliste"-prinsippet som standard, det vil si at bare trafikk er tillatt, hvis passasje er eksplisitt tillatt. Det vil si at vi kan lage "Web" og "MySQL" EPG-gruppene og definere en regel som tillater kommunikasjon mellom dem kun på port 3306. Dette vil fungere uten å være knyttet til nettverksadresser og til og med innenfor samme subnett!
Vi har kunder som har valgt ACI nettopp på grunn av denne funksjonen, siden den lar deg begrense tilgangen mellom servere (virtuell eller fysisk - det spiller ingen rolle) uten å dra dem mellom subnett, som betyr uten å berøre adresseringen. Ja, ja, vi vet at ingen foreskriver IP-adresser i applikasjonskonfigurasjoner for hånd, ikke sant?
Trafikkregler i ACI kalles kontrakter. I en slik kontrakt blir en eller flere grupper eller nivåer i en flerlagsapplikasjon en tjenesteleverandør (for eksempel en databasetjeneste), andre blir en forbruker. Kontrakten kan ganske enkelt sende trafikk, eller den kan gjøre noe mer vanskelig, for eksempel dirigere den til en brannmur eller balanserer, og også endre QoS-verdien.
Hvordan kommer servere inn i disse gruppene? Hvis dette er fysiske servere eller noe som er inkludert i et eksisterende nettverk som vi opprettet en VLAN-trunk til, må du peke på svitsjporten og VLAN-en som brukes på den for å plassere dem i EPG. Som du kan se, vises VLAN der du ikke kan klare deg uten dem.
Hvis serverne er virtuelle maskiner, er det nok å referere til det tilkoblede virtualiseringsmiljøet, og da vil alt skje av seg selv: en portgruppe vil bli opprettet (i form av VMWare) for å koble til VM-en, de nødvendige VLAN-ene eller VXLAN-ene vil blir tildelt, vil de bli registrert på de nødvendige svitsjportene osv. Så selv om ACI er bygget rundt et fysisk nettverk, ser tilkoblinger for virtuelle servere mye enklere ut enn for fysiske. ACI har allerede innebygd tilkobling med VMWare og MS Hyper-V, samt støtte for OpenStack og RedHat Virtualization. Fra et tidspunkt av har det også dukket opp innebygd støtte for containerplattformer: Kubernetes, OpenShift, Cloud Foundry, mens det gjelder både anvendelse av policyer og overvåking, det vil si at nettverksadministratoren umiddelbart kan se hvilke verter hvilke poder fungerer på og hvilke grupper de faller inn i.
I tillegg til å være inkludert i en bestemt portgruppe, har virtuelle servere tilleggsegenskaper: navn, attributter osv., som kan brukes som kriterier for å overføre dem til en annen gruppe, for eksempel når en VM får nytt navn eller en ekstra kode vises i den. Cisco kaller dette mikrosegmenteringsgrupper, selv om selve designet med muligheten til å lage mange sikkerhetssegmenter i form av EPG-er på samme subnett stort sett også er en ganske mikrosegmentering. Vel, selgeren vet bedre.
EPG-er i seg selv er rene logiske konstruksjoner, ikke knyttet til spesifikke switcher, servere osv., så du kan gjøre ting med dem og konstruksjoner basert på dem (applikasjoner og leietakere) som er vanskelige å gjøre i vanlige nettverk, som for eksempel kloning. Som et resultat, la oss si at det er veldig enkelt å klone et produksjonsmiljø for å få et testmiljø som garantert er identisk med produksjonsmiljøet. Du kan gjøre det manuelt, men det er bedre (og enklere) gjennom API.
Generelt er kontrolllogikken i ACI slett ikke lik det du vanligvis møter
i tradisjonelle nettverk fra samme Cisco: programvaregrensesnittet er primært, og GUI eller CLI er sekundære, siden de fungerer gjennom samme API. Derfor begynner nesten alle som er involvert i ACI, etter en stund, å navigere i objektmodellen som brukes til administrasjon og automatisere noe som passer deres behov. Den enkleste måten å gjøre dette på er fra Python: det er praktiske ferdige verktøy for det.
Lovet rake
Hovedproblemet er at mange ting i ACI gjøres annerledes. For å begynne å jobbe med det normalt, må du omskolere deg. Dette gjelder spesielt for nettverksdriftsteam hos store kunder, der ingeniører har "foreskrevet VLAN" i årevis på forespørsel. Det faktum at VLAN nå ikke lenger er VLAN, og du ikke trenger å lage VLAN for hånd for å legge nye nettverk i virtualiserte verter, blåser fullstendig taket av tradisjonelle nettverksbrukere og får dem til å klamre seg til kjente tilnærminger. Det skal bemerkes at Cisco prøvde å blidgjøre pillen litt og la til en "NXOS-lignende" CLI til kontrolleren, som lar deg gjøre konfigurasjon fra et grensesnitt som ligner på tradisjonelle brytere. Men likevel, for å begynne å bruke ACI normalt, må du forstå hvordan det fungerer.
Når det gjelder pris, på store og mellomstore skalaer, skiller ikke ACI-nettverk seg faktisk fra tradisjonelle nettverk på Cisco-utstyr, siden de samme svitsjene brukes til å bygge dem (Nexus 9000 kan fungere i ACI og i tradisjonell modus og har nå blitt den viktigste "arbeidshest" for nye datasenterprosjekter). Men for datasentre med to brytere, gjør tilstedeværelsen av kontrollere og Spine-Leaf-arkitektur seg selvfølgelig. Nylig har det dukket opp en Mini ACI-fabrikk, der to av de tre kontrollerene er erstattet av virtuelle maskiner. Dette reduserer forskjellen i kostnad, men den består fortsatt. Så for kunden er valget diktert av hvor mye han er interessert i sikkerhetsfunksjoner, integrasjon med virtualisering, et enkelt kontrollpunkt, og så videre.
Kilde: www.habr.com