Selle imelise Cisco ACI skripti abil saab võrku kiiresti seadistada.
Cisco ACI andmehalduse tehas on juba viis aastat olemas, kuid Habr's ei ole selle kohta tõeliselt midagi räägitud, seega otsustasin seda veidi parandada. Räägin oma kogemuse põhjal, mis see on, millist kasu sellest on ja millised on seal leitud mured.
Mis see on ja kust see tuli?
Aastal 2013 ACI (Rakendusele keskendatud infrastruktuur) välja kuulutamise hetkeks said andmehalduse traditsioonilised lähenemised samaaegselt kolme allika poolt konkurentsi.
Esiteks lubasid esimese põlvkonna SDN-lahendused OpenFlow baasil muuta võrgud samal ajal paindlikumaks ja odavamaks. Idee seisnes selles, et muudeti otsuste tegemise, mis tavaliselt toimus kommutaatorite omaniku tarkvara kaudu, keskseks kontrolleriks.
See kontroller omaks ühtset nägemust sellest, mis toimub, ja selle põhjal programmeeriks kõigi lülitite riistvara konkreetselt voogude töötlemise reeglite tasandil.
Teiselt poolt võimaldasid overlay võrgulahendused saavutada vajaliku ühenduvuse ja turvapoliitikad ilma füüsilises võrgus muutusteta, luues tarkvaralisi tunnelite vahel virtualiseeritud majutajate vahel. Kõige tuntum näide selle lähenemise kohta oli Nicira lahendus, mis oli juba ostetud VMWare poolt 1,26 miljardi dollari eest ja andis alguse tänapäeva VMWare NSX-ile. Kuna Nicira kaasasutajateks olid samad inimesed, kes olid eelnevalt OpenFlow alguses, tekkis olukorrale teatav soolakus. .
Lõpuks on avatud turul saadaval olevad kommutaatorite spetsiaalsetele kiipidele (mis nimetatakse merchant silicon) saavutanud küpsuse taseme, kus need kujutavad endast reaalselt ohtu traditsioonilistele kommutaatoritootjatele. Kui varem arendas iga tootja oma kommutaatorite kiipe, siis aja jooksul on kolmandate osapoolte, eelkõige Brоadcomi kiibid, hakanud funktsioonide poolest tootjate kiipidega taset tõstma, samas kui hinna ja jõudluse suhte poolest neist üle. Seetõttu arvas paljud, et nende päevad on loetud tosinkond aastat tagasi välja töötatud kiipidel.
ACI oli Cisco (täpsemalt tema koosseisu kuuluv Insieme, mille asutasid endised töötajad) «asümmeetriline vastus» kõikidele sellele.
Millis on OpenFlow'i erinevus?
Funktsioonide jaotamise vaatenurgast on ACI tegelikult OpenFlow'i vastand.
OpenFlow'i arhitektuuris vastutab kontrollsüsteem detailsete reeglite (voogude) määratlemise eest
kõikides lülitite riistvarades, mistõttu võib suurtes võrkudes lasuda temal vastutus hoida ja, mis kõige tähtsam, muuta kümneid miljoneid kirjeid sadades kohtades võrgus, mistõttu tema jõudlus ja usaldusväärsus suurel rakendusel saavad kitsaskohaks.
ACI kasutab vastupidist lähenemist: kontrollsüsteem on loomulikult olemas, kuid lülitid saavad temalt kõrgetasemelisi deklaratiivseid poliitikaid, samas kui nende konvertimine konkreetseteks seadistusteks riistvaras toimub lüliti enda poolt. Kontrollsüsteemi saab taaskäivitada või isegi välja lülitada ning võrguga ei juhtu midagi halba, välja arvatud loomulikult see, et sellel hetkel ei ole juhtimise võimalust. Huvi pakub, et ACI-s on olukordi, kus OpenFlow'i siiski kasutatakse, kuid kohapeal, hosti piires Open vSwitch'i programmeerimiseks.
ACI on täielikult üles ehitatud VXLANi põhjal ülekatte (overlay) transpordile, kuid sisaldab samas ainulaadses lahenduses ka aluseks olevat IP-transpordit. Cisco nimetas seda terminiks „integreeritud overlay”. ACI-s kasutatakse enamikul juhtudel overlay’ide lõpp-punkte tehase lülitid (teevad seda kanalikiirusel). Hostid ei ole kohustatud teadma tehase, kapseldamise jne kohta, kuid mõningatel juhtudel (näiteks OpenStacki hostide ühendamiseks) võib VXLAN-i liiklus jõuda ka nende juurde.
Overlaid kasutatakse ACI-s mitte ainult paindliku ühenduvuse tagamiseks transpordivõrgus, vaid ka metaandmete edastamiseks (mida kasutatakse näiteks turvapoliitikate rakendamiseks).
Broadcom'i kiipe hakati juba varem kasutama Cisco Nexus 3000 seeria lülitites. Nexus 9000 peres, mis on spetsiaalselt välja töötatud ACI toetamiseks, rakendati algselt hübriidmudeleid nimega Merchant+. Lülitites kasutati samaaegselt uut Broadcom Trident 2 kiipi ja Cisco arendatud lisakiipi, mis rakendas kogu ACI maagia. Tundub, et see võimaldas kiirendada toote turule viimist ja langetada lülitite hinda tasemele, mis oli lähedane mudelitele, mis kasutasid lihtsalt Trident 2. Seda lähenemist jätkus ACI tarnete esimeseks kaheks-kolmaks aastaks. Selle aja jooksul arendas Cisco välja ja tõi turule järgmise põlvkonna Nexus 9000, mis põhines omaenda kiipidel, millel oli suurem jõudlus ja funktsioonide komplekt, kuid sama hinnatasemega. Välised spetsifikatsioonid suhtlemiseks tehases jäävad täielikult muutumatuks. Sellegipoolest seestpoolt oli kogu sisu muutunud: midagi sellist nagu refaktooring, kuid riistvara jaoks.
Kuidas on üles ehitatud Cisco ACI arhitektuur
Lihtsaimal juhul ehitatakse ACI Kloosi võrgu topoloogiale, või nagu sageli öeldakse, Spine-Leaf. Spine-taseme lüliteid võib olla kahest (või ühest, kui me ei muretse tõrkevõime üle) kuue. Vastavalt sellele, mida rohkem lüliteid, seda suurem on tõrkevõime (vähem riba ja usaldusväärsuse langust, kui üks Spine on rikki läinud või hoolduses) ja kogu jõudlus. Kõik välistükid ühendatakse Leaf-taseme lülititega: need on nii serverid kui ka ühendused väliste võrkudega kas L2 või L3 kaudu ning APIC-i kontrollerite ühendamine. Üldiselt toimub ACI puhul mitte ainult seadistamine, vaid ka statistika kogumine, tõrgete jälgimine jm — kõik toimub kontrollerite liidese kaudu, mida tavapärastes rakendustes on kolm.
Lülititega ei pea kunagi konsoliga ühendama, isegi võrgu käivitamiseks: kontroller avastab ise lülitid ja kogub neist tehase, sealhulgas kõik teenindusprotokollide seadistused. Seetõttu on see väga oluline, et montaaži käigus üles kirjutada paigaldatava seadme seerianumbrid, et hiljem ei peaks mõtlema, milline lüliti mis kapis asub. Probleemide lahendamiseks on lülititega vajadusel võimalik liituda SSH kaudu: nende peal on põhjalikult taastatud tavalised Cisco show-käsud.
Sises kasutatakse IP-transpordi tehnikat, nii et Spanning Tree ja muud mineviku probleemid on seal kadunud: kõik lingid on aktiivsed, ja tõrgete korral on taastumine väga kiire. Tehases edastatakse liiklus tunnelite kaudu, mis põhinevad VXLAN-il. Täpsemalt öeldes nimetab Cisco kapseldust iVXLAN-iks, mis erineb tavalisest VXLAN-ist sellega, et võrgupealkirja reserveeritud väljad kasutatakse teenusinfo edastamiseks, eelkõige — liikluse seondumise kohta EPG rühmaga. See võimaldab rakendada suhtlemisreegleid rühmade vahel riistvara kaudu, kasutades nende numbreid, just nagu tavalistes juurdelasku loendites kasutatakse aadresse.
Tunnelid võimaldavad venitada nii L2-segmente kui ka L3 (st VRF) läbi sise IP-transpordi. Samuti on vaikimisi marsruuter jaotatud. See tähendab, et tehase sisse tuleva liikluse marsruuri määrab iga lüliti eraldi. Saadetava liikluse loogika osas sarnaneb ACI VXLAN/EVPN-tehasele.
Kui nii, siis milles on erinevused? Kõigis muudates!
Esimene erinevus, millega ACI-s kokku puututakse, on see, kuidas serverid võrku ühendatakse. Traditsioonilistes võrkudes ühendatakse nii füüsilised serverid kui ka virtuaalsed VLAN-idesse, ning kõik muu sõltub sellest: ühenduvus, turvalisus jne. ACI-s kasutatakse konstruktsiooni, mida Cisco nimetab EPG-ks (Lõpp-punkti grupp), millest ei pääse. Kas seda on võimalik võrdsustada VLAN-iga? Jah, kuid sel juhul on oht kaotada enamik ACI eeliseid.
EPG suhtes formuleeritakse kõik ligipääsureeglid, ja ACI-s kasutatakse vaikimisi 'valge nimekirja' lähenemist, st lubatud on ainult see liiklus, mille läbipääs on selgelt lubatud. Seega saame luua EPG rühmad 'Web' ja 'MySQL' ning määrata reegli, mis lubab nendevahelist suhtlemist ainult portaali 3306 kaudu. See töötab isegi ilma võrgu aadresside sidumiseta ja isegi ühes samas alamvõrgus!
Meil on kliente, kes valisid ACI just selle funktsiooni tõttu, kuna see võimaldab piirata ligipääse serverite (kas virtuaalsete või füüsiliste – pole vahet) vahel, ilma et oleks vaja neid alamvõrkudest ümber tõsta, mis tähendab, et aadressimist ei puudutata. Jah- jah, me teame, et keegi ei kirjuta neid käsitsi IP-aadressid rakenduste konfiguratsioonides, eks?
ACI-s liiklust läbimise reeglid on lepingud. Sellises lepingus muutuvad üks või mitu gruppi või taset mitmeastmelises rakenduses teenuse pakkujateks (öeldes, andmebaasi teenus), teised aga tarbijateks. Leping võib lihtsalt liiklust edastada või teha midagi keerukamat, näiteks suunata tulemüürile või tasakaalustajale ning samuti muuta QoS-i väärtust.
Kuidas serverid nendesse gruppidesse satuvad? Kui need on füüsilised serverid või midagi, mis on osa olemasolevast võrgust, kuhu oleme loonud VLAN-i trunk, tuleb need EPG-sse paigutamiseks viidata lüliti portile ja sellel kasutatavale VLAN-ile. Nagu näeme, ilmuvad VLAN-id sinna, kus ilma nendeta ei saa.
Kui aga serverid on virtuaalmasinad, piisab, kui viidata ühendatud virtualiseerimise keskkonnale ja edasi toimub kõik iseenesest: luuakse port-grupp (kui rääkida VMWare'i terminoloogiast) VM-ide ühendamiseks, määratakse vajalikud VLAN-id või VXLAN-id, kirjutatakse vajalikesse switchi portidesse jne. Nii et kuigi ACI on üles ehitatud füüsilise võrgu ümber, näevad virtuaalserverite ühendused oluliselt lihtsamad välja kui füüsiliste puhul. ACI-s on juba sisseehitatud ühendused VMWare'i ja MS Hyper-V-ga, samuti tugi OpenStackile ja RedHat Virtualization'ile. Teatud hetkest alates on lisaks sisseehitatud tugi konteinerite platvormidele: Kubernetes, OpenShift, Cloud Foundry, kusjuures see hõlmab nii poliitikate rakendamist kui ka jälgimist, see tähendab, et võrguadministraator näeb kohe, millistel hostidel töötavad millised podid ja millistesse gruppidesse nad kuuluvad.
Lisaks kuuluvusele ühte või teise port-gruppi on virtuaalserveritel ka täiendavad omadused: nimi, atribuudid jne, mida võib kasutada kriteeriumidena nende viimiseks teise gruppi, näiteks VM-i ümbernimetamisel või sellel lisateegi ilmumise korral. Cisco nimetab seda mikrosegmentide gruppideks, kuigi suuremas plaanis on see konstruktsioon, millega on võimalik luua palju turvasegmente EPG-de kujul samas alamvõrgus — samuti päris mikrosegmentatsioon. No, tootjale on selgem.
EPG-d on puhtalt loogilised konstruktsioonid, mis ei ole seotud konkreetsete lülitite, serverite jne, mistõttu on nendega ja nende baasil loodud konstruktsioonidega (rakendustega ja tenantidega) võimalik teha asju, mida tavapärastes võrkudes on raske teostada, näiteks kloonimine. Seeläbi on näiteks väga lihtne luua kloon tootmiskeskkonnast, et saada testkeskkond, mis on garanteeritult identne tootmisega. Seda saab teha käsitsi, kuid parem (ja lihtsam) on kasutada API-d.
Üldiselt ei sarnane ACI haldustegevuse loogika sellega, millega tavaliselt kokku puututakse
traditsioonilistes Cisco võrkudes: programmiline liides on esmase tähtsusega, samas kui GUI või CLI on sekundaarne, kuna need toimivad sama API kaudu. Seetõttu hakkab peaaegu igaüks, kes tegeleb ACI-ga, mõne aja pärast orienteeruma haldamiseks kasutatavas objekti mudelis ja automatiseerima midagi vastavalt oma vajadustele. Selleks on kõige lihtsam kasutada Pythonit: selle jaoks on olemas mugavad valmis tööriistad.
Lubatud karid
Peamine probleem on see, et paljusid asju ACI-s on tehtud teistmoodi. Et hakata sellega õigesti töötama, tuleb ümber õppida. Eriti kehtib see võrguhooldusmeeskondade kohta suurtes kundedes, kus insenerid on aastaid tegelenud VLAN-ide 'registreerimisega' taotlustes. See, et nüüd VLAN ei ole enam VLAN, ja uute võrkude loomine virtualiseeritud hostides ei nõua VLAN-ide käsitsi loomist, 'viib traditsioonilised võrgukonsolidatsiooni grave katuselt' ja sunnib neid kinni jääma harjumuspärastes lähenemisviisides. Tuleb märkida, et Cisco on püüdnud veidi magusamaks muuta ja lisanud kontrollerisse 'NXOS-sarnase' CLI, mis võimaldab seadistamist traditsiooniliste lülitite sarnases liideses. Siiski, et ACI-d korralikult kasutada, tuleb mõista, kuidas see töötab.
Hinnavaateid vaadates ei erine ACI võrgu kulud oluliselt traditsioonilistest Cisco seadmetega võrkudest, kuna nende ülesehituseks kasutatakse samu lülitajaid (Nexus 9000 töötab nii ACI kui ka traditsioonilises režiimis ja on nüüdseks saanud peamiseks "tööhobuseks" uutes andmekeskuse projektides). Ent andmekeskustes, kus on kaks lülitit, annavad kontrollerite ja Spine-Leaf arhitektuuri olemasolu kindlasti tunda. Hiljuti ilmus Mini ACI tehas, kus kahest kontrollerist kolm on asendatud virtuaalmasinatega. See aitab vähendada hinnaerinevust, kuid see jääb siiski olemas. Seega, kliendi valik sõltub sellest, kui suures osas ta on huvitatud turvafunktsioonidest, virtualiseerimise integreerimisest, ühest juhtimispunktist ja muudest omadustest.
Allikas: habr.com
