Med denne magiske stykke Cisco ACI script kan du hurtigt konfigurere netværket.
Netværksfabrikken til datacenteret Cisco ACI har eksisteret i fem år, men der er ikke rigtig blevet talt om den på Habr, så jeg besluttede mig for at rette lidt op på det. Jeg vil fortælle fra min erfaring, hvad det er, hvilken fordel den har, og hvor dens fælder ligger.
Hvad er det, og hvor kommer det fra?
Ved annonceringen af ACI (Application Centric Infrastructure) i 2013 blev de traditionelle tilgange til datacenter-netværk udfordret fra tre sider.
På den ene side lovede SDN-løsninger "første generation" baseret på OpenFlow at gøre netværk både mere fleksible og billigere på samme tid. Ideen var at flytte beslutningstagningen, der traditionelt blev udført af den proprietære software i switchene, til en central controller.
Denne controller ville have et samlet overblik over alt, hvad der foregår, og ud fra dette ville den programere udstyret i alle switchene på niveauet for regler til behandling af specifikke strømme.
På den anden side gav overlay-netværksløsninger mulighed for at implementere den nødvendige forbindelse og sikkerhedspolitikker uden at ændre den fysiske netværk, ved at opbygge software tunneler mellem virtualiserede værter. Det mest kendte eksempel på en sådan tilgang var løsningen fra Nicira, som på det tidspunkt allerede var blevet erhvervet af VMWare for 1,26 milliarder dollars og gav start til det nuværende VMWare NSX. En smule picant tilføjede situationen det faktum, at medstifterne af Nicira var de samme personer, der tidligere havde været med til at udvikle OpenFlow, og nu sagde, at for at bygge en datacenterfabrik var OpenFlow ikke det rette valg. .
Og endelig havde switch-chips tilgængelige på det åbne marked (det, der kaldes merchant silicon), nået et modenhedsniveau, hvor de udgjorde en reel trussel mod de traditionelle switch-producenter. Tidligere udviklede hver leverandør chips til deres switch, men over tid begyndte chips fra tredjepartsproducenter, især fra Broadcom, at indhente leverandørernes chips med hensyn til funktioner og at overgå dem i pris/præstation forhold. Derfor mente mange, at dagene for switchene med egenudviklede chips var tællende.
ACI blev Cisco's "asymmetrisk svar" (mere præcist, et svar fra det opkøbte firma Insieme, grundlagt af tidligere ansatte) på alt det nævnte.
Hvad er forskellen til OpenFlow?
Set fra et funktionsfordelingsperspektiv er ACI faktisk det modsatte af OpenFlow.
I OpenFlow-arkitekturen er controlleren ansvarlig for at specificere detaljerede regler (flows)
i hardwareen af alle switchene, hvilket betyder, at i et stort netværk kan den have ansvaret for at vedligeholde og, vigtigst af alt, ændre titusinder af millioner poster på hundreder af steder i netværket, derfor bliver dens ydeevne og pålidelighed i store implementeringer et flaskehals.
I ACI anvendes der en omvendt tilgang: der findes selvfølgelig også en controller, men switchene modtager fra den høj-niveau deklarative politikker, og deres rendering til detaljerede specifikationer i hardware udføres af selve switchen. Controlleren kan genstartes eller helt slukkes, og med netværket vil der ikke ske noget dårligt, bortset fra selvfølgelig, at der ikke er mulighed for at administrere i det øjeblik. Interessant nok er der i ACI situationer, hvor OpenFlow alligevel bruges, men lokalt inden for værten til programmering af Open vSwitch.
ACI er helt bygget på overlay-transport baseret på VXLAN, men inkluderer samtidig i rammerne af en samlet løsning det underliggende IP-transport. Cisco har kaldt dette for 'integreret overlay'. Som terminering af overlayne bruges switchene i fabrikken (gør det ved kanalens hastighed) i de fleste tilfælde. Værter behøver ikke at vide noget om fabrikken, indkapslinger osv., men i nogle tilfælde (for eksempel for at forbinde OpenStack-værter) kan VXLAN-trafik også sendes til dem.
Overlayne anvendes i ACI ikke kun til at sikre fleksibel forbindelse gennem transportsnetværket, men også til at overføre metaoplysninger (som for eksempel anvendes til at anvende sikkerhedspolitikker).
Broadcoms chips have previously been used by Cisco in the Nexus 3000 series switches. In the Nexus 9000 family, specifically released to support ACI, a hybrid model called Merchant+ was initially implemented. The switch simultaneously used a new Broadcom Trident 2 chip alongside a complementary chip developed by Cisco, which executed all the ACI magic. Apparently, this allowed for a quicker product release and reduced the switch price to a level close to models relying solely on Trident 2. This approach was sufficient for the first two to three years of ACI deliveries. During this time, Cisco developed and released the next generation of Nexus 9000, now utilizing its own chips with greater performance and feature sets, but at the same price point. The external specifications regarding interaction in the fabric remained completely unchanged. However, the internal components changed entirely: something akin to refactoring, but for hardware.
Hvordan er arkitekturen i Cisco ACI
I sin simpleste form bygges ACI ud fra Clos-netværkstopologien, eller, som det også ofte omtales, Spine-Leaf. Der kan være fra to (eller én, hvis vi ikke er bekymrede for fejltolerance) til seks Spine-niveau switches. Jo flere der er, desto højere er fejltolerancen (mindre nedgang i båndbredde og pålidelighed ved en fejl eller vedligeholdelse af en enkelt Spine) og den samlede ydeevne. Alle eksterne forbindelser går til Leaf-niveau switches: dette inkluderer servere, forbindelser til eksterne netværk via L2 eller L3, samt tilslutning af APIC controllere. Generelt med ACI er ikke kun konfigurationen, men også indsamling af statistik, overvågning af fejl og andre ting – alt dette gøres gennem controllerens interface, hvor der i installationer af almindelig størrelse – er tre enheder.
Du skal aldrig tilslutte konsollen til switches, heller ikke for at starte netværket: controllere opdager selv switches og samler dem til en fabrik, inklusive indstillinger for alle serviceprotokoller, så det er meget vigtigt at notere serienumrene på det installerede udstyr under montage, så man ikke skal gætte, hvilken switch der er i hvilken rack. Til fejlsøgning kan man ved behov tilslutte sig switches via SSH: de har grundigt gengivet de almindelige show-kommandoer fra Cisco.
Inden for fabrikken benytter man IP-transport, så der er ingen Spanning Tree og andre rædsler fra fortiden: alle forbindelser er aktive, og konvergens ved fejl er meget hurtig. Trafikken i fabrikken overføres via tunneler baseret på VXLAN. Mere præcist kalder Cisco selve inkapslingen iVXLAN, og den adskiller sig fra almindelig VXLAN ved, at de reserverede felter i netværkshovedet bruges til at overføre kontrolinformation, primært om forholdet mellem trafikken og EPG-gruppen. Dette muliggør at implementere interaktionsregler mellem grupperne i hardwaren, ved at bruge deres numre ligesom adresser i almindelige adgangslister.
Tunnelene gør det muligt at strække både L2-segmenter og L3 (det vil sige VRF) gennem intern IP-transport. Her er standardgatewayen distribueret. Det betyder, at hver switch håndterer routing af den indgående trafik til fabrikken. Med hensyn til trafikoverførselslogik ligner ACI en fabrik baseret på VXLAN/EVPN.
Hvis det er tilfældet, hvad er forskellene så? I alt andet!
Den første forskel, man støder på i ACI, er, hvordan servere tilsluttes netværket. I traditionelle netværk tilsluttes både fysiske servere og virtuelle maskiner VLAN'er, og alt andet følger derfra: sammenkobling, sikkerhed osv. I ACI anvendes en struktur, som Cisco kalder EPG (End-point Group), som man ikke kan komme udenom. Kan man ligestille det med VLAN? Ja, men i så fald er der en risiko for at miste meget af det, som ACI tilbyder.
Alle adgangsregler formuleres i forhold til EPG, og i ACI anvendes som standard princippet om "hvid liste", hvilket betyder, at kun trafik, der er tilladt eksplicit, er tilladt. Det vil sige, at vi kan oprette EPG-grupperne "Web" og "MySQL" og definere en regel, der tillader interaktion mellem dem kun på port 3306. Dette vil fungere uden at være knyttet til netværksadresser, og endda inden for samme subnet!
Vi har kunder, der har valgt ACI netop på grund af denne funktion, da den muliggør restriktioner for adgangen mellem servere (virtuelle eller fysiske — underordnet), uden at skulle flytte dem mellem subnets, og dermed ikke røre ved adresseringen. Ja, vi ved det, ingen skriver det manuelt IP-adresser i applikationernes konfigurationer, vel?
Reglerne for trafikgennemgang i ACI kaldes kontrakter. I en sådan kontrakt bliver en eller flere grupper eller niveauer i en multi-tier-applikation leverandør af en tjeneste (lad os sige, en database-tjeneste), mens andre bliver forbrugere. Kontrakten kan blot tillade trafik at passere, eller den kan gøre noget mere avanceret, som at lede trafikken til en firewall eller belastningsbalancer og også ændre QoS-værdien.
Hvordan kommer serverne ind i disse grupper? Hvis det er fysiske servere eller noget, der er forbundet til et eksisterende netværk, hvor vi har oprettet en VLAN-trunk, så kræver det at angive porten på switchen og den VLAN, der anvendes på den. Som vi kan se, optræder VLAN'er der, hvor de er nødvendige.
Hvis serverne derimod er virtuelle, er det tilstrækkeligt at henvise til den tilknyttede virtualiseringsmiljø, og så sker alt automatisk: der oprettes en portgruppe (hvis vi taler i termer - VMWare) til tilslutning af VM'er, nødvendige VLAN'er eller VXLAN'er tildeles, og de skrivs ind på de relevante switch-porte osv. Så selvom ACI er bygget op omkring det fysiske netværk, ser forbindelserne til virtuelle servere meget enklere ud end til fysiske. ACI har allerede indbygget integration med VMWare og MS Hyper-V samt support for OpenStack og RedHat Virtualization. Fra et tidspunkt er der også indbygget support for containerplatforme: Kubernetes, OpenShift, Cloud Foundry, hvilket gælder både anvendelse af politikker og overvågning, så netværksadministratoren straks kan se, hvilke pods der kører på hvilke værter, og i hvilke grupper de er blevet placeret.
Udover at blive inkluderet i en eller anden portgruppe har virtuelle servere yderligere egenskaber: navn, attributter osv., som kan bruges som kriterier for deres flytning til en anden gruppe, for eksempel ved omdøbning af VM eller ved tilføjelse af et ekstra tag. Cisco kalder dette mikrosementeringsgrupper, selvom selve konstruktionen med muligheden for at oprette mange sikkerhedssegmenter i form af EPG i det samme subnet også er en form for mikrosementering. Nå, det ved leverandøren bedre.
EPG'er er i bund og grund rent logiske konstruktioner, der ikke er knyttet til specifikke switcher, servere osv., så man kan udføre operationer med dem og konstruktioner baseret på dem (applikationer og lejere), som er vanskelige i almindelige netværk, eksempelvis kloning. Det er derfor meget let at oprette en klon af produktionsmiljøet for at få et testmiljø, der er identisk med produktionen. Det kan gøres manuelt, men det er bedre (og lettere) at gøre det via API.
Generelt er logikken for styring i ACI slet ikke som det, man normalt møder
i traditionelle netværk fra den samme Cisco: det programmerbare interface er primært, mens GUI eller CLI er sekundære, da de arbejder via det samme API. Derfor begynder næsten alle, der arbejder med ACI, at navigere i den objektmodel, der bruges til administration, og at automatisere noget til deres behov. Det er nemmest at gøre det fra Python: der er gode, færdige værktøjer til det.
De lovede frustrationer
Hovedproblemet er, at mange ting i ACI er gjort anderledes. For at arbejde ordentligt med det, skal man genlæres. Dette gælder især for netværksdrifts teams hos store kunder, hvor ingeniører i årevis har beskæftiget sig med at 'skriv VLANs' efter ansøgninger. Det, at VLAN nu ikke længere er VLAN, og at man overhovedet ikke behøver at oprette VLAN'er manuelt for at anbringe nye netværk i virtualiserede værter, fuldstændig 'nedbryder' de traditionelle netværksfolk og tvinger dem til at hænge fast i de vante metoder. Det skal bemærkes, at Cisco har forsøgt at gøre pillen lidt sødere ved at tilføje en 'NXOS-lignende' CLI til kontrolleren, som muliggør opsætning fra et interface, der ligner traditionelle switcher. Men alligevel, for at kunne bruge ACI ordentligt, skal man forstå, hvordan det fungerer.
Set med hensyn til prisniveauet for store og mellemstore ACI-netværk adskiller det sig ikke væsentligt fra traditionelle netværk på Cisco-udstyr, da de samme switche anvendes til deres opbygning (Nexus 9000 kan fungere både i ACI og i traditionel tilstand og er nu blevet en vigtig "arbejdshest" for nye datacenterprojekter). For datacentre med to switche giver tilstedeværelsen af controllere og Spine-Leaf-arkitektur naturligvis en betydelig forskel. For nylig er der blevet lanceret en Mini ACI-fabrik, hvor to af de tre controllere er blevet erstattet af virtuelle maskiner. Dette hjælper med at reducere prisforskellen, men den er stadig til stede. Så for kunden dikteres valget af, hvor meget han er interesseret i sikkerhedsfunktioner, integrationsmuligheder med virtualisering, centraliseret styring og lignende.
Kilde: habr.com
