Selle imekauni Cisco ACI skripti abil on võimalik kiiresti võrku seadistada.
Cisco ACI andmete keskuse võrgutootmine on eksisteerinud juba viis aastat, kuid selle kohta ei ole Habras just suurt midagi räägitud, seega otsustasin seda natuke parandada. Jagan enda kogemust, et mida see endast kujutab, milline on selle kasu ja kus võivad olla probleemid.
Mis see on ja kust see tuli?
Aasta 2013 ACI (Rakendusele Keskendatud Infra) esitamise hetkel ründasid traditsioonilisi andmete keskuse võrgulahendusi kolme erineva poolelt konkurendid.
Ühelt poolt lubasid avatud voolu põhised „esimese põlvkonna“ SDN-lahendused võrke samal ajal paindlikumaks ja odavamaks muuta. Idee oli viia üle otsustamine, mis tavaliselt toimus kommutaatorite patenteeritud tarkvara kaudu, keskse juhtimise kohale.
See juhtimisseade omaks ühtset ülevaadet kõigest, mis toimub, ja selle põhjal programmeeriks see kõigi lülitite riistvara konkreetsete voogude töötlemise reeglite tasemel.
Teiselt poolt võimaldas overlay võrgulahendused saavutada vajaliku ühenduvuse ja turvapoliitikad ilma füüsilise võrgu muudatusteta, luues tarkvaralisi tunnelid virtualiseeritud hostide vahel. Sellise lähenemise kõige tuntum näide oli Nicira lahendus, mis selleks ajaks oli juba ostetud VMWare'ile 1,26 miljardi dollari eest ja andis alust tänapäeva VMWare NSX-ile. Situatsiooni andis mingitki vürtsi see, et Nicira kaasasutajad olid samad inimesed, kes olid varem olnud OpenFlow'i alguses, nüüd rääkisid nad, et andmesalvestustsee on üles ehitada. .
Lõpuks on kommutaatorite kiibid, mis on saadaval avaturul (nii-öelda merchant silicon), saavutanud küpsuse taseme, mille tõttu nad on saanud tõeliseks ohuks traditsioonilistele kommutaatorite tootjatele. Kui varem arendas iga tootja oma kommutaatorite jaoks kiibid, siis aja jooksul hakkasid kolmandate osapoolte, peamiselt Broadcomi, kiibid funktsionaalsuses lähenema tootja kiipidele ja nende hinna/efektiivsuse suhe ületas need. Seetõttu arvas paljusid, et oma arenduse kiipidega kommutaatorite päevad on loetud.
ACI on Cisco "asümmeetriline vastus" (täpsemalt Insieme'i, endiste töötajate poolt loodud ettevõtte, mis on nüüd osa Cisco'st) kõigile eelnevale.
Mis vahe on OpenFlow'ga?
Funktsioonide jaotuse seisukohalt on ACI tegelikult OpenFlow' vastand.
OpenFlow'i arhitektuuris vastutab kontroller detailsete reeglite (voogude) määratlemise eest.
suurem võrgus võib see vastutada kümnete miljonite kirje haldamise ja, mis kõige tähtsam, muutmise eest sadades punktides, seega on selle jõudlus ja usaldusväärsus suurte rakenduste puhul kitsaskohaks.
ACIs kasutatakse vastupidist lähenemist: kontrollereid on muidugi olemas, kuid lülitid saavad neist kõrgetasemelisi deklareerivaid poliitikaid, mille detailide renderdamise konkreetsete seadistuste järgi teostab lüliti ise. Kontrollerit saab taaskäivitada või hoopis välja lülitada, ja võrgus ei toimu midagi halba, välja arvatud, muidugi, selle ajavahemiku jooksul puuduv haldusvõime. Huvitav on see, et ACIs on olukordi, kus OpenFlow'd siiski kasutatakse, kuid kohalikult hosti piires Open vSwitch'i programmeerimiseks.
ACI põhineb täielikult VXLAN-i põhjal ehitatud ülevõtte transportimisel, kuid see hõlmab ka aluseks olevat IP-transpordilahendust ühes ja ainsas lahenduses. Cisco nimetab seda terminit "integreeritud ülevõte". Ülevõttete lõpp-punktina kasutatakse ACI-s enamikul juhtudel tehase lüliteid (teevad seda kanali kiirusel). Võõrustajad ei pea fabrika, kapseldamisest jne midagi teadma, kuid mõnel juhul (näiteks OpenStacki võõrustajate ühendamiseks) võib VXLAN-i liiklus ulatuda ka nende poole.
Ülevõtteid kasutatakse ACI-s mitte ainult paindliku sidususe tagamiseks üle transpordivõrgu, vaid ka metaandmete edastamiseks (mida kasutatakse näiteks turvapoliitikate rakendamiseks).
Broadcomi kiibid on varem olnud Cisco kasutuses Nexus 3000 seeria lülitites. Nexus 9000 peres, mis on spetsiaalselt välja töötatud ACI toe osas, rakendati esialgu hübriidmudelit nimega Merchant+. Lülitites kasutati samaaegselt nii uut Broadcom Trident 2 kiipi kui ka Cisco välja töötatud täiendavat kiipi, mis realiseeris kogu ACI maagia. Tundub, et see kiirusis võimaldas toote kiiret turule toomist ja lüliti hinda langetada tasemele, mis on lähedane pelgalt Trident 2 mudelite hindadele. Seda lähenemist piisas esimeseks kaheks-kolmeks aastaks ACI tarnitest. Selle aja jooksul töötas Cisco välja ja tõi turule järgmise põlvkonna Nexus 9000, mis põhineb juba nende enda kiipidel, millel on suurem jõudlus ja funktsioonide komplekt, kuid samas hinnataset. Välimised spetsifikatsioonid suhtlemise osas tehases on täielikult säilinud. Samas on sisemised koostisosad täielikult muutunud: midagi nagu refaktoreerimine, kuid rauas.
Kuidas on üles ehitatud Cisco ACI arhitektuur
Lihtsamas vormis põhineb ACI Clos'i võrgu topoloogial, tuntud ka kui Spine-Leaf. Spine-taseme lüliteid võib olla kahest (või ühest, kui me ei hooli tõrke taluvusest) kuni kuue. Seega, mida rohkem neid on, seda parem on tõrke taluvus (väiksem ribalaiuse ja usaldusväärsuse vähenemine ühe Spine'i rikkest või hooldusest) ja üldine jõudlus. Kõik välised ühendused lähevad Leaf-taseme lülititesse: need on serverid, ühendused väliste võrkudega L2 või L3 kaudu, ja APIC kontrollerite ühendamine. ACI-ga ei ole mitte ainult seadistus, vaid ka statistika kogumine, tõrgete jälgimine ja muu — kõik toimub kontrollerite liidese kaudu, mida tavaliselt on kolme.
Lülititega ei pea kunagi konsooli ühendama, isegi võrgu käivitamiseks: kontroller tuvastab ise lülitid ja kogub neist tehase, sealhulgas kõigi teenusprotokollide seaded. Seetõttu on väga oluline, et paigaldamise käigus kirja panna paigaldatud seadmete seerianumbrid, et hiljem ei peaks ära arvama, milline lüliti missuguses riiulis asub. Probleemide lahendamiseks saab lülititele vajadusel SSH kaudu sisse logida: neid on piisavalt hoolikalt kopeeritud tavalised Cisco show-käsud.
Sisemine kasutab IP-transporti, nii et sissetulekute puudumine Spanning Tree ja muid mineviku õudusi: kõik lingid on aktiivsed ja tõrgete korral on kokkuvõte väga kiire. Tehases edastatakse liiklus tunnelite kaudu, mis põhinevad VXLAN-il. Kui olla täpsem, nimetab Cisco kapseldamist iVXLAN, mis erineb tavalisest VXLAN-ist selle poolest, et võrgupealkirja reserveeritud väljad kasutatakse teenusteabe edastamiseks, peamiselt — info edastamiseks liikluse seostest EPG-grupiga. See võimaldab rakendada suhtlemisreegleid gruppide vahel riistvaras, kasutades nende numbreid sama moodi, nagu tavalistes ligipääsuloendites kasutatakse aadresse.
Tunnelid võimaldavad venitada läbi sisemise IP-transporti nii L2-segmente kui ka L3 (st VRF). Samal ajal on vaikimisi lüüs jaotatud. See tähendab, et igasse tehasesse sissetuleva liikluse marsruutimist teostab iga lüliti. Liiklusülekande loogikas sarnaneb ACI VXLAN/EVPN baasil tehasele.
Kui nii, siis millised on erinevused? Kõiges muus!
Peamine erinevus, millega ACI-s silmitsi seisate, on serverite võrku ühendamise viis. Traditsioonilistes võrkudes ühendatakse nii füüsilised kui ka virtuaalserverid VLAN-idesse, mistõttu kõik muu, nagu ühenduvus ja turvalisus, sõltub neist. ACI-s kasutatakse aga konstruktsiooni, mida Cisco nimetab EPG-ks (End-point Group), millest pole pääsu. Kas seda saab võrrelda VLAN-iga? Jah, kuid sel juhul on oht kaotada suur osa eeliseid, mida ACI pakub.
EPG-d defineeritakse kõik pääsureeglid, ja ACI-s kehtib vaikimisi "valge nimekirja" põhimõte, st lubatud on ainult see liiklus, mille edastamine on selgesõnaliselt lubatud. Saame luua EPG-gruppe "Web" ja "MySQL" ning määrata reegli, mis lubab nende vahelise suhtluse ainult pordil 3306. See töötab ilma sidumata võrguaadressidega ja isegi ühe alamsuure piires!
Meil on kliente, kes valisid ACI just selle funktsiooni tõttu, kuna see võimaldab piirata juurdepääse serverite (olgu need virtuaalsed või füüsilised — ei ole vahet) vahel, ilma et neid alamsuurtest liigutataks, ja seega ei muudeta aadresse. Jah, me teame, et keegi ei kirjuta ju käsitsi. IP-aadressid rakenduste konfiguratsioonides, eks?
ACI-s liiklusreegleid nimetatakse lepinguteks. Sellises lepingus muutuvad üks või mitu rühma või taset mitmetasandilises rakenduses teenuse pakkujaks (ütleme, andmebaasi teenus), teised aga tarbijaks. Leping võib lihtsalt liiklust edastada või teha midagi keerulisemat, näiteks suunata tulemüürile või koormuse tasakaalustajale ning samuti muuta QoS-i väärtust.
Kuidas serverid nende gruppidesse satuvad? Kui need on füüsilised serverid või midagi, mis on ühendatud olemasolevasse võrku, kuhu oleme loonud VLAN-i trunki, siis EPG-sse paigutamiseks tuleb näidata lüliti port ja seal kasutatav VLAN. Nagu näeme, ilmuvad VLAN-id sinna, kus ilma nendeta ei saa.
Kui serverid on virtuaalsed masinad, piisab, kui viidata ühendatud virtualiseerimiskeskkonnale, ja seejärel juhtub kõik iseenesest: luuakse portigrupp (kui rääkida termini VMWare keeles) VM-ed ühendamiseks, määratakse vajalikud VLAN-id või VXLAN-id, ja need seadistatakse vajalikesse lülitite portidesse jne. Nii et kuigi ACI on loodud füüsilise võrgu ümber, näevad virtuaalserverite ühendused välja palju lihtsamad kui füüsiliste jaoks. ACI-s on juba sisse ehitatud koostöö VMWare'i ja MS Hyper-V-ga ning tugi OpenStackile ja RedHat Virtualizationile. Teatud hetkel lisandus ka konteineriplatvormide sisseehitatud tugi: Kubernetes, OpenShift, Cloud Foundry, samas puudutab see nii poliitikate rakendamist kui ka jälgimist, mis tähendab, et võrguhaldur saab kohe näha, millistel hostidel millised podid töötavad ja millistesse gruppidesse nad kuuluvad.
Lisaks sellele, et virtuaalserverid kuuluvad teatud portgruppidesse, on neil ka täiendavad omadused: nimi, atribuudid jne, mida saab kasutada nende teisaldamise kriteeriumidena teise gruppi, näiteks VM ümbernimetamise või uue sildi ilmumise korral. Cisco nimetab seda mikrosementeerimisrühmadeks, kuigi tegelikult on laste moodustamine turvalisuse jaoks mitmesugust tüüpi EPG-d samas alamvõrgus samuti piisav mikrosementeerimine. Ometi teab tootja paremini.
EPG-d ise on puhtalt loogilised konstruktsioonid, mis ei ole seotud konkreetsete lülititega, serverite jne. Seetõttu saab nende ja nende põhjal (rakenduste ja tenantide) luua asju, mida tavavõrkudes on keeruline teha, näiteks kloonimine. Tulemuseks on see, et on väga lihtne luua kloon tootmisest, et saada testkeskkond, mis on tootmisega kindlalt identne. Seda on võimalik teha käsitsi, kuid parem (ja lihtsam) on seda teha API kaudu.
Üldiselt ei sarnane ACI haldamise loogika üldse sellega, millega tavaliselt kokku puututakse.
tavapõhistes võrkudes, nagu Cisco: programmiliides on esmane ja GUI või CLI sekundaarne, kuna need töötavad sama API kaudu. Seetõttu hakkab peaaegu igaüks, kes tegeleb ACI-ga, mingil hetkel orienteeruma haldusprotsesside objekti mudelis ja automatiseerima midagi vastavalt oma vajadustele. Kõige lihtsam on seda teha Pythonis: selle jaoks on olemas mugavad valmistooted.
Lubatud takistused
Peamine probleem on see, et paljusid asju ACI-s on tehtud teistmoodi. Selleks, et alustada normaalselt töötamist, tuleb ümber õppida. See kehtib eriti suure klientide võrgu opereerimise meeskondade kohta, kus insenerid on aastaid tegelenud VLAN-ide "registreerimisega" päringute alusel. See, et nüüd VLAN ei ole enam VLAN, ning uute võrkude loomiseks virtualiseeritud hostides VLAN-e käsitsi luua ei olegi enam vajalik, tekitab traditsiooniliste võrguspetsialistide seas täieliku segaduse ja sunnib neid hoidma kinni harjunud lähenemistest. Tuleb märkida, et Cisco on proovinud veidi pillimehe meeleolu muuta ja lisanud kontrollerisse „NXOS-i taolise“ CLI, mis võimaldab seadistada liidese kaudu, mis sarnaneb traditsioonilistele switch'idele. Kuid siiski, et hakata ACI-d normaalselt kasutama, tuleb mõista, kuidas see töötab.
Suure ja keskmise mastaabi ACI võrgu hind ei erine oluliselt traditsioonilistest Cisco seadmetel põhinevatest võrkudest, kuna nende rajamiseks kasutatakse samu lüliteid (Nexus 9000 saab töötada nii ACI kui ka traditsioonilises režiimis ja on praegu uute andmekeskuse projektide peamine "tööloom"). Kuid andmekeskustes, kus on kaks lülitit, on kontrollerite ja Spine-Leaf arhitektuuri olemasolu kindlasti tunda. Hiljuti ilmus Mini ACI tehas, kus kaks kolmest kontrollerist on asendatud virtuaalmasinatega. See võimaldab vähendada hinnavahet, kuid see jääb siiski alles. Seega dikteerib kliendi valik, kuivõrd ta on huvitatud turvafunktsioonidest, virtuaalsusega integreerimisest, ühest halduspinnast ja muust.
Allikas: habr.com
