Selle maagilise Cisco ACI skripti abil saate kiiresti võrgu seadistada.
Cisco ACI andmekeskuse võrgutehas on eksisteerinud viis aastat, kuid Habré ei öelnud selle kohta midagi, nii et otsustasin seda veidi parandada. Ma räägin teile omast kogemusest, mis see on, mis kasu sellest on ja kus sellel reha on.
Mis see on ja kust see tuli?
Selleks ajaks, kui 2013. aastal välja kuulutati ACI (Application Centric Infrastructure), edenesid konkurendid andmekeskuste võrkude traditsiooniliste lähenemisviiside poole korraga kolmest küljest.
Ühest küljest lubasid OpenFlow-l põhinevad "esimese põlvkonna" SDN-lahendused muuta võrgud paindlikumaks ja samal ajal odavamaks. Idee oli viia traditsiooniliselt patenteeritud lülititarkvaraga tehtud otsuste tegemine keskkontrollerile.
Sellel kontrolleril oleks ühtne nägemus kõigest, mis juhtub ja selle põhjal programmeeriks kõigi lülitite riistvara konkreetsete voogude töötlemise reeglite tasemel.
Teisest küljest võimaldasid ülekattega võrgulahendused rakendada vajalikke ühenduvus- ja turvapoliitikaid ilma füüsilises võrgus üldse muutmata, ehitades tarkvaratunneleid virtualiseeritud hostide vahele. Tuntuim näide sellest lähenemisest oli Nicira, mille VMWare oli selleks ajaks juba 1,26 miljardi dollari eest omandanud ja millest sai alguse praeguse VMWare NSX. Olukorrale lisas omajagu pikantsust asjaolu, et Nicira kaasasutajateks olid samad inimesed, kes varem seisid OpenFlow alge juures, öeldes nüüd, et andmekeskuse tehase ehitamiseks. .
Ja lõpuks, avatud turul saadaolevad lülituskiibid (mida nimetatakse kaubanduslikuks räniks) on jõudnud küpsusastmesse, kus neist on saanud tõeline oht traditsioonilistele lülitite tootjatele. Kui varem töötas iga müüja oma lülitite jaoks iseseisvalt välja kiibid, siis aja jooksul hakkasid kolmandate osapoolte tootjate, peamiselt Broadcomi kiibid funktsioonide osas kaugust tarnijakiipidega vähendama ja ületasid neid hinna ja jõudluse suhte poolest. Seetõttu uskusid paljud, et nende enda disainitud kiipide sisselülitamise päevad on nummerdatud.
ACI-st on saanud Cisco "asümmeetriline vastus" (täpsemalt tema endiste töötajate poolt asutatud Insieme'i ettevõte) kõigele eelnevale.
Mis vahe on OpenFlow'st?
Funktsioonide jaotuse osas on ACI tegelikult OpenFlow vastand.
OpenFlow arhitektuuris vastutab kontroller üksikasjalike reeglite (voogude) kirjutamise eest.
kõigi lülitite riistvaras, st suures võrgus, võib see vastutada kümnete miljonite kirjete säilitamise ja, mis kõige tähtsam, muutmise eest sadades võrgupunktides, nii et selle jõudlus ja töökindlus muutuvad võrgus kitsaskohaks. suur teostus.
ACI kasutab vastupidist lähenemist: loomulikult on olemas ka kontroller, kuid lülitid saavad sellelt kõrgetasemelised deklaratiivsed poliitikad ja lüliti ise teostab nende renderdamise riistvara konkreetsete seadete üksikasjadesse. Kontrolleri saab taaskäivitada või üldse välja lülitada ja võrguga ei juhtu midagi hullu, välja arvatud muidugi hetkel kontrolli puudumine. Huvitaval kombel on ACI-s olukordi, kus OpenFlow'd kasutatakse endiselt, kuid Open vSwitchi programmeerimiseks hostis kohapeal.
ACI on üles ehitatud täielikult VXLAN-põhisele ülekattetranspordile, kuid sisaldab ka aluseks olevat IP-transporti ühe lahenduse osana. Cisco nimetas seda "integreeritud ülekatte" terminiks. ACI ülekatete lõpp-punktina kasutatakse enamikul juhtudel tehaselüliteid (need teevad seda lingikiirusel). Hostid ei pea midagi tehase, kapseldamise jms kohta teadma, kuid teatud juhtudel (näiteks OpenStacki hostide ühendamiseks) saab neile tuua VXLAN-i liikluse.
Ülekatteid kasutatakse ACI-s mitte ainult transpordivõrgu kaudu paindliku ühenduvuse pakkumiseks, vaid ka metateabe edastamiseks (kasutatakse näiteks turvapoliitikate rakendamiseks).
Broadcomi kiipe kasutas Cisco varem Nexus 3000 seeria lülitites. Spetsiaalselt ACI toetamiseks välja antud Nexus 9000 perekonnas rakendati algselt hübriidmudel, mille nimi oli Merchant +. Lüliti kasutas samaaegselt nii uut Broadcom Trident 2 kiipi kui ka Cisco välja töötatud täiendavat kiipi, mis rakendab kogu ACI võlu. Ilmselt võimaldas see kiirendada toote väljalaskmist ja vähendada lüliti hinnasilti lihtsalt Trident 2-l põhinevate mudelite lähedasele tasemele. Sellest lähenemisest piisas ACI tarnete esimeseks kaheks-kolmeks aastaks. Selle aja jooksul on Cisco välja töötanud ja turule toonud järgmise põlvkonna Nexus 9000 oma kiipidel, millel on suurem jõudlus ja funktsioonide komplekt, kuid samal hinnatasemel. Välised spetsifikatsioonid koostoime osas tehases on täielikult säilinud. Samal ajal on sisemine täitmine täielikult muutunud: midagi refaktoreerimise sarnast, kuid riistvara jaoks.
Kuidas Cisco ACI arhitektuur töötab
Lihtsamal juhul on ACI üles ehitatud Klose võrgu topoloogiale või, nagu sageli öeldakse, Spine-Leafile. Lülisamba taseme lülitid võivad olla kahest (või ühest, kui me tõrketaluvusest ei hooli) kuni kuueni. Seega, mida rohkem neid, seda suurem on veataluvus (väiksem on ribalaius ja töökindluse vähenemine õnnetuse või ühe Spine hoolduse korral) ja üldine jõudlus. Kõik välised ühendused lähevad lehetaseme lülititele: need on serverid ja välisvõrkudega dokkimine L2 või L3 kaudu ning APIC-kontrollerite ühendamine. Üldiselt pole ACI-ga mitte ainult konfigureerimine, vaid ka statistika kogumine, rikete jälgimine ja nii edasi - kõik toimub kontrollerite liidese kaudu, mida standardsuuruses rakendustes on kolm.
Te ei pea kunagi konsooliga lülititega ühendust looma, isegi võrgu käivitamiseks: kontroller tuvastab ise lülitid ja koostab neist tehase, sealhulgas kõigi teenindusprotokollide seaded, seetõttu on muide väga oluline Paigaldamisel kirjutage üles paigaldatavate seadmete seerianumbrid, et hiljem ei peaks arvama, milline lüliti millises nagis asub. Veaotsinguks saab vajadusel lülititega ühenduse luua SSH kaudu: need reprodutseerivad tavapäraseid Cisco show-käske üsna hoolikalt.
Sisemiselt kasutab tehas IP-transporti, seega pole selles Spanning Tree'i ja muid mineviku jubedusi: kaasatud on kõik lingid ning rikete korral konvergents väga kiire. Liiklus kangas edastatakse VXLAN-il põhinevate tunnelite kaudu. Täpsemalt nimetab Cisco ise iVXLAN-i kapseldamiseks ja see erineb tavalisest VXLAN-ist selle poolest, et võrgu päises olevaid reserveeritud välju kasutatakse teenuseteabe edastamiseks, eelkõige liikluse seose kohta EPG grupiga. See võimaldab teil rakendada seadmes olevate rühmade vahelise suhtluse reegleid, kasutades nende numbreid samamoodi nagu aadresse kasutatakse tavalistes juurdepääsuloendites.
Tunnelid võimaldavad sisemise IP-transpordi kaudu venitada nii L2 segmente kui ka L3 segmente (st VRF). Sel juhul levitatakse vaikelüüsi. See tähendab, et iga lüliti vastutab kangasse siseneva liikluse suunamise eest. Liiklusvoo loogika poolest sarnaneb ACI VXLAN/EVPN kangale.
Kui jah, siis millised on erinevused? Kõik muu!
Esimene erinevus, mida ACI-ga kohtab, on see, kuidas serverid on võrguga ühendatud. Traditsioonilistes võrkudes läheb nii füüsiliste serverite kui ka virtuaalmasinate kaasamine VLAN-idesse ja sealt tantsib kõik muu: ühenduvus, turvalisus jne. ACI-s kasutatakse disaini, mida Cisco nimetab EPG-ks (End-point Group), millest alates pole kuhugi pääseda. Kas seda on võimalik võrdsustada VLAN-iga? Jah, aga sel juhul on võimalus kaotada suurem osa sellest, mida ACI annab.
Seoses EPG-ga on kõik juurdepääsureeglid sõnastatud ja ACI-s kasutatakse vaikimisi “valge nimekirja” põhimõtet, st lubatud on ainult liiklus, mille läbimine on selgesõnaliselt lubatud. See tähendab, et saame luua EPG rühmad "Web" ja "MySQL" ning määratleda reegli, mis võimaldab nende vahel suhelda ainult pordis 3306. See toimib ilma võrguaadressidega sidumata ja isegi samas alamvõrgus!
Meil on kliente, kes on valinud ACI just selle funktsiooni tõttu, kuna see võimaldab piirata juurdepääsu serverite vahel (virtuaalne või füüsiline – vahet pole) ilma neid alamvõrkude vahel lohistamata, mis tähendab aadressi puudutamata. Jah, jah, me teame, et keegi ei kirjuta rakenduste konfiguratsioonides käsitsi IP-aadresse, eks?
Liikluseeskirju ACI-s nimetatakse lepinguteks. Sellise lepingu puhul saab mitmetasandilise rakenduse üks või mitu rühma või taset teenusepakkujaks (näiteks andmebaasiteenuseks), teistest tarbijad. Leping võib lihtsalt liiklust läbi viia või teha midagi keerukamat, näiteks suunata selle tulemüüri või tasakaalustajasse ja muuta ka QoS väärtust.
Kuidas serverid neisse rühmadesse satuvad? Kui need on füüsilised serverid või midagi, mis sisaldub olemasolevas võrgus, millesse me VLAN-i magistraalvõrgu loosime, siis nende EPG-sse paigutamiseks peate osutama kommutaatori pordile ja sellel kasutatavale VLAN-ile. Nagu näete, ilmuvad VLAN-id seal, kus te ei saa ilma nendeta hakkama.
Kui serveriteks on virtuaalmasinad, siis piisab ühendatud virtualiseerimiskeskkonnale viidamisest ja siis toimub kõik iseenesest: VM-i ühendamiseks luuakse pordigrupp (VMWare'i mõttes), vajalikud VLAN-id või VXLAN-id. Kui need on määratud, registreeritakse need vajalikesse kommutaatoriportidesse jne. Ehkki ACI on üles ehitatud füüsilise võrgu ümber, näevad virtuaalserverite ühendused palju lihtsamad kui füüsiliste serverite jaoks. ACI-l on juba sisseehitatud ühenduvus VMWare'i ja MS Hyper-V-ga, samuti OpenStacki ja RedHati virtualiseerimise tugi. Mingist hetkest on ilmunud ka sisseehitatud tugi konteinerplatvormidele: Kubernetes, OpenShift, Cloud Foundry, kusjuures see puudutab nii poliitikate rakendamist kui ka jälgimist ehk võrguadministraator näeb kohe, millistel hostidel millised podid töötavad ja millistesse rühmadesse nad kuuluvad.
Lisaks kindlasse pordirühma kuulumisele on virtuaalserveritel täiendavad atribuudid: nimi, atribuudid jne, mida saab kasutada kriteeriumidena nende teise rühma ülekandmisel, näiteks kui virtuaalmasin on ümbernimetatud või lisamärgend ilmub seda. Cisco nimetab seda mikrosegmenteerimisrühmadeks, kuigi üldiselt on kujundus ise, mis võimaldab luua samas alamvõrgus palju turvasegmente EPG-de kujul, üsna mikrosegmentatsioon. Noh, müüja teab paremini.
EPG-d ise on puhtalt loogilised konstruktsioonid, mis ei ole seotud kindlate lülitite, serverite vms külge, nii et saate nendega ja nendel põhinevate konstruktsioonidega (rakendused ja rentnikud) teha asju, mida on tavavõrkudes keeruline teha, näiteks kloonida. Selle tulemusena oletame, et tootmiskeskkonda on väga lihtne kloonida, et saada testkeskkond, mis on garanteeritult tootmiskeskkonnaga identne. Saate seda teha käsitsi, kuid see on parem (ja lihtsam) API kaudu.
Üldiselt pole ACI juhtimisloogika üldse sarnane sellega, mida tavaliselt kohtate
sama Cisco traditsioonilistes võrkudes: tarkvaraliides on esmane ja GUI või CLI on sekundaarsed, kuna need töötavad sama API kaudu. Seetõttu hakkavad peaaegu kõik ACI-ga seotud inimesed mõne aja pärast haldamiseks kasutatavas objektimudelis navigeerima ja midagi oma vajadustele vastavaks automatiseerima. Lihtsaim viis seda teha on Pythonist: selleks on mugavad valmistööriistad.
Lubatud reha
Peamine probleem on see, et ACI-s tehakse paljusid asju erinevalt. Sellega tavapäraseks töötamiseks peate end ümber koolitama. See kehtib eriti suurklientide võrguoperatsioonimeeskondade kohta, kus insenerid on aastaid nõudmisel VLAN-e välja kirjutanud. Asjaolu, et nüüd pole VLAN-id enam VLAN-id ja te ei pea VLAN-e käsitsi looma, et luua uusi võrke virtualiseeritud hostidesse, lööb traditsioonilised võrgutootjad täielikult katuse alla ja paneb nad tuttavate lähenemisviiside külge klammerduma. Olgu öeldud, et Cisco püüdis pille pisut maiustada ja lisas kontrollerile “NXOS-i-laadse” CLI, mis võimaldab konfigureerimist teha traditsiooniliste lülititega sarnaselt liideselt. Kuid siiski, selleks, et ACI-d normaalselt kasutada, peate mõistma, kuidas see töötab.
Hinna poolest ei erine ACI võrgud suurel ja keskmisel skaalal tegelikult tavapärastest Cisco seadmete võrkudest, kuna nende ehitamiseks kasutatakse samu lüliteid (Nexus 9000 võib töötada ACI-s ja traditsioonilises režiimis ning on nüüdseks saanud peamiseks "tööhobune" uute andmekeskuse projektide jaoks). Kuid kahe lülitiga andmekeskuste puhul annavad kontrollerite olemasolu ja Spine-Leaf arhitektuuri loomulikult tunda. Hiljuti on ilmunud Mini ACI tehas, milles kolmest kontrollerist kaks on asendatud virtuaalmasinatega. See vähendab kulude erinevust, kuid see jääb siiski alles. Nii et kliendi jaoks määrab valiku see, kui palju ta on huvitatud turvaelementidest, integratsioonist virtualiseerimisega, ühest juhtimispunktist jne.
Allikas: www.habr.com