Ved hjælp af dette magiske stykke Cisco ACI-script kan du hurtigt oprette et netværk.
Netværksfabrikken til Cisco ACI-datacentret har eksisteret i fem år, men Habré sagde ikke rigtig noget om det, så jeg besluttede at ordne det lidt. Jeg vil fortælle dig ud fra min egen erfaring, hvad det er, hvad det kan bruges til, og hvor det har en rive.
Hvad er det, og hvor kom det fra?
På det tidspunkt, hvor ACI (Application Centric Infrastructure) blev annonceret i 2013, var konkurrenterne fremme på traditionelle tilgange til datacenternetværk fra tre sider på én gang.
På den ene side lovede "første generations" SDN-løsninger baseret på OpenFlow at gøre netværk mere fleksible og billigere på samme tid. Ideen var at flytte beslutningstagningen, der traditionelt er foretaget af proprietær switch-software, til en central controller.
Denne controller ville have en enkelt vision af alt, hvad der sker, og på baggrund af dette vil den programmere alle switches hardware på niveau med regler for behandling af specifikke flows.
På den anden side gjorde overlay-netværksløsninger det muligt at implementere de nødvendige tilslutnings- og sikkerhedspolitikker uden ændringer i det fysiske netværk overhovedet, og bygge softwaretunneler mellem virtualiserede værter. Det mest kendte eksempel på denne tilgang var Nicira, som på det tidspunkt allerede var blevet opkøbt af VMWare for 1,26 milliarder dollar og gav anledning til den nuværende VMWare NSX. Noget pikanthed af situationen blev tilføjet af det faktum, at medstifterne af Nicira var de samme mennesker, som tidligere stod ved oprindelsen af OpenFlow, og nu sagde, at for at bygge en datacenterfabrik .
Og endelig har switching-chips, der er tilgængelige på det åbne marked (det, der kaldes handelssilicium) nået et modenhedsstadium, hvor de er blevet en reel trussel mod traditionelle switch-producenter. Hvis hver leverandør tidligere selvstændigt udviklede chips til sine switche, begyndte chips fra tredjepartsproducenter, primært fra Broadcom, over tid at reducere afstanden til leverandørchips med hensyn til funktioner og overgik dem med hensyn til pris/ydelsesforhold. Derfor troede mange, at dagene med kontakter på chips af deres eget design var talte.
ACI er blevet Ciscos "asymmetriske svar" (mere præcist, dets Insieme-virksomhed, grundlagt af dets tidligere ansatte) på alt ovenstående.
Hvad er forskellen med OpenFlow?
Med hensyn til fordeling af funktioner er ACI faktisk det modsatte af OpenFlow.
I OpenFlow-arkitekturen er controlleren ansvarlig for at skrive detaljerede regler (flows)
i hardwaren i alle switches, det vil sige i et stort netværk, kan det være ansvarligt for at vedligeholde og, vigtigst af alt, at ændre titusinder af registreringer på hundredvis af punkter i netværket, så dets ydeevne og pålidelighed bliver en flaskehals i en stor implementering.
ACI bruger den omvendte tilgang: selvfølgelig er der også en controller, men switchene modtager deklarative politikker på højt niveau fra den, og switchen selv udfører deres gengivelse til detaljer om specifikke indstillinger i hardwaren. Controlleren kan genstartes eller slukkes helt, og der vil ikke ske noget dårligt med netværket, bortset fra selvfølgelig manglen på kontrol i dette øjeblik. Interessant nok er der situationer i ACI, hvor OpenFlow stadig bruges, men lokalt inden for værten til Open vSwitch-programmering.
ACI er bygget udelukkende på VXLAN-baseret overlejringstransport, men inkluderer den underliggende IP-transport som en del af en enkelt løsning. Cisco kaldte dette "integreret overlay"-udtryk. Som termineringspunkt for overlejringer i ACI bruges i de fleste tilfælde fabrikskontakter (de gør dette ved linkhastighed). Værter er ikke forpligtet til at vide noget om fabrikken, indkapsling osv., men i nogle tilfælde (for eksempel for at forbinde OpenStack-værter), kan VXLAN-trafik bringes til dem.
Overlays bruges i ACI ikke kun til at give fleksibel forbindelse gennem transportnetværket, men også til at overføre metainformation (det bruges f.eks. til at anvende sikkerhedspolitikker).
Chips fra Broadcom blev tidligere brugt af Cisco i switchene i Nexus 3000-serien. I Nexus 9000-familien, der er specielt udgivet til at understøtte ACI, blev der oprindeligt implementeret en hybridmodel, som blev kaldt Merchant +. Switchen brugte samtidig både den nye Broadcom Trident 2-chip og en komplementær chip udviklet af Cisco, som implementerer al magien ved ACI. Tilsyneladende gjorde dette det muligt at fremskynde udgivelsen af produktet og reducere prisskiltet på switchen til et niveau tæt på modeller, der blot var baseret på Trident 2. Denne tilgang var nok til de første to eller tre år med ACI-leverancer. I løbet af denne tid udviklede og lancerede Cisco næste generation af Nexus 9000 på sine egne chips med mere ydeevne og funktionssæt, men til samme prisniveau. Eksterne specifikationer med hensyn til interaktion på fabrikken er fuldstændigt bevarede. Samtidig er den indvendige fyldning fuldstændig ændret: noget i retning af refactoring, men for hardware.
Sådan fungerer Cisco ACI-arkitekturen
I det enkleste tilfælde er ACI bygget på topologien af Klose-netværket, eller, som de ofte siger, Spine-Leaf. Kontakter på rygradsniveau kan være fra to (eller én, hvis vi er ligeglade med fejltolerance) til seks. Følgelig, jo flere af dem, jo højere er fejltolerancen (jo lavere båndbredde og reduktion af pålidelighed i tilfælde af en ulykke eller vedligeholdelse af en Spine) og den samlede ydeevne. Alle eksterne forbindelser går til switches på bladniveau: disse er servere og docking med eksterne netværk via L2 eller L3 og forbinder APIC-controllere. Generelt, med ACI, ikke kun konfiguration, men også statistikindsamling, fejlovervågning og så videre - alt foregår gennem grænsefladen af controllere, hvoraf der er tre i standardstørrelse implementeringer.
Du behøver aldrig at oprette forbindelse til switchene med konsollen, heller ikke for at starte netværket: controlleren selv registrerer switchene og samler en fabrik fra dem, inklusive indstillingerne for alle serviceprotokoller, derfor er det i øvrigt meget vigtigt at nedskriv serienumrene på det udstyr, der installeres under installationen, så du senere ikke skal gætte, hvilken afbryder der er i hvilket rack der er placeret. Til fejlfinding kan du om nødvendigt oprette forbindelse til switchene via SSH: de gengiver de sædvanlige Cisco show-kommandoer ret omhyggeligt.
Internt bruger fabrikken IP-transport, så der er intet Spanning Tree og andre rædsler fra fortiden i det: alle links er involveret, og konvergensen i tilfælde af fejl er meget hurtig. Trafikken i stoffet transmitteres gennem tunneler baseret på VXLAN. Mere præcist kalder Cisco selv for iVXLAN-indkapsling, og det adskiller sig fra almindeligt VXLAN ved, at de reserverede felter i netværksheaderen bruges til at transmittere serviceinformation, primært om trafikforholdet til EPG-gruppen. Dette giver dig mulighed for at implementere reglerne for interaktion mellem grupper i udstyret ved at bruge deres numre på samme måde som adresser bruges i almindelige adgangslister.
Tunneler gør det muligt at strække både L2-segmenter og L3-segmenter (dvs. VRF) gennem den interne IP-transport. I dette tilfælde er standardgatewayen distribueret. Det betyder, at hver switch er ansvarlig for at dirigere trafikken ind i stoffet. Med hensyn til trafikflowlogik ligner ACI et VXLAN/EVPN-stof.
Hvis ja, hvad er forskellene? Alt andet!
Den største forskel, du støder på med ACI, er, hvordan servere er forbundet til netværket. I traditionelle netværk går inddragelsen af både fysiske servere og virtuelle maskiner til VLAN, og alt andet danser af dem: forbindelse, sikkerhed osv. I ACI bruges et design, som Cisco kalder EPG (End-point Group), hvorfra der er ingen steder at komme væk. Om det er muligt at sidestille det med VLAN? Ja, men i dette tilfælde er der en chance for at miste det meste af det ACI giver.
Med hensyn til EPG er alle adgangsregler formuleret, og i ACI bruges "white list"-princippet som standard, det vil sige, at kun trafik er tilladt, hvis passage er eksplicit tilladt. Det vil sige, at vi kan oprette "Web" og "MySQL" EPG-grupperne og definere en regel, der kun tillader kommunikation mellem dem på port 3306. Dette vil fungere uden at være bundet til netværksadresser og endda inden for det samme undernet!
Vi har kunder, der har valgt ACI netop på grund af denne funktion, da den giver dig mulighed for at begrænse adgangen mellem servere (virtuel eller fysisk - det er lige meget) uden at trække dem mellem undernet, hvilket betyder uden at røre ved adresseringen. Ja, ja, vi ved, at ingen ordinerer IP-adresser i applikationskonfigurationer i hånden, ikke?
Trafikregler i ACI kaldes kontrakter. I en sådan kontrakt bliver en eller flere grupper eller niveauer i en flerlagsapplikation en tjenesteudbyder (f.eks. en databasetjeneste), andre bliver en forbruger. Kontrakten kan simpelthen sende trafik, eller den kan gøre noget mere tricky, for eksempel dirigere den til en firewall eller balancer, og også ændre QoS-værdien.
Hvordan kommer servere ind i disse grupper? Hvis disse er fysiske servere eller noget, der er inkluderet i et eksisterende netværk, hvor vi har oprettet en VLAN-trunk, skal du for at placere dem i EPG'en pege på switchporten og det VLAN, der bruges på den. Som du kan se, dukker VLAN'er op, hvor du ikke kan undvære dem.
Hvis serverne er virtuelle maskiner, er det nok at henvise til det tilsluttede virtualiseringsmiljø, og så vil alt ske af sig selv: der oprettes en portgruppe (i form af VMWare) til at forbinde VM'en, de nødvendige VLAN'er eller VXLAN'er vil bliver tildelt, vil de blive registreret på de nødvendige switch-porte osv. Så selvom ACI er bygget op omkring et fysisk netværk, ser forbindelser til virtuelle servere meget enklere ud end til fysiske. ACI har allerede indbygget forbindelse med VMWare og MS Hyper-V, samt understøttelse af OpenStack og RedHat Virtualization. Fra et tidspunkt af er der også dukket indbygget understøttelse af containerplatforme op: Kubernetes, OpenShift, Cloud Foundry, mens det både drejer sig om anvendelse af politikker og overvågning, det vil sige, at netværksadministratoren umiddelbart kan se, hvilke hosts hvilke pods arbejder på og hvilke grupper de falder ind i.
Ud over at være inkluderet i en bestemt portgruppe, har virtuelle servere yderligere egenskaber: navn, attributter osv., som kan bruges som kriterier for at overføre dem til en anden gruppe, f.eks. når en VM omdøbes eller et ekstra tag vises i det. Cisco kalder dette mikrosegmenteringsgrupper, selvom selve designet med muligheden for at skabe mange sikkerhedssegmenter i form af EPG'er på det samme undernet i det store og hele også er noget af en mikrosegmentering. Sælgeren ved bedre.
EPG'er er i sig selv rent logiske konstruktioner, ikke bundet til specifikke switche, servere osv., så du kan gøre ting med dem og konstruktioner baseret på dem (applikationer og lejere), som er svære at lave i almindelige netværk, såsom kloning. Som et resultat, lad os sige, at det er meget nemt at klone et produktionsmiljø for at få et testmiljø, der med garanti er identisk med produktionsmiljøet. Du kan gøre det manuelt, men det er bedre (og nemmere) gennem API'en.
Generelt er kontrollogikken i ACI slet ikke magen til det man normalt møder
i traditionelle netværk fra samme Cisco: softwaregrænsefladen er primær, og GUI'en eller CLI'en er sekundær, da de arbejder gennem den samme API. Derfor begynder næsten alle involveret i ACI efter et stykke tid at navigere i den objektmodel, der bruges til administration, og automatisere noget, der passer til deres behov. Den nemmeste måde at gøre dette på er fra Python: der er praktiske færdige værktøjer til det.
Lovet rive
Hovedproblemet er, at mange ting i ACI gøres anderledes. For at begynde at arbejde med det normalt, skal du genoptræne. Dette gælder især for netværksdriftsteams hos store kunder, hvor ingeniører har "ordineret VLAN'er" i årevis efter anmodning. Det faktum, at VLAN'er nu ikke længere er VLAN'er, og du ikke behøver at oprette VLAN'er i hånden for at lægge nye netværk i virtualiserede værter, blæser helt taget af traditionelle netværkere og får dem til at klamre sig til velkendte tilgange. Det skal bemærkes, at Cisco forsøgte at forsøde pillen lidt og tilføjede en "NXOS-lignende" CLI til controlleren, som giver dig mulighed for at lave konfiguration fra en grænseflade, der ligner traditionelle switches. Men stadig, for at begynde at bruge ACI normalt, skal du forstå, hvordan det fungerer.
Med hensyn til pris, på store og mellemstore skalaer, adskiller ACI-netværk sig faktisk ikke fra traditionelle netværk på Cisco-udstyr, da de samme switche bruges til at bygge dem (Nexus 9000 kan fungere i ACI og i traditionel tilstand og er nu blevet det vigtigste "arbejdshest" til nye datacenterprojekter). Men for datacentre med to switches gør tilstedeværelsen af controllere og Spine-Leaf-arkitektur sig selvfølgelig mærke. For nylig er der dukket en Mini ACI-fabrik op, hvor to af de tre controllere er erstattet af virtuelle maskiner. Dette reducerer forskellen i omkostninger, men det forbliver stadig. Så for kunden er valget dikteret af, hvor meget han er interesseret i sikkerhedsfunktioner, integration med virtualisering, et enkelt kontrolpunkt og så videre.
Kilde: www.habr.com