S temle čarobnim skriptom Cisco ACI je mogoče hitro nastaviti mrežo.
Mrežna tovarna za podatkovne centre Cisco ACI obstaja že pet let, a o njej ni bilo veliko povedanega na Habru, zato sem se odločil to nekoliko popraviti. Na svoji izkušnji bom razložil, kaj to je, kakšne koristi prinaša in kje so njeni izzivi.
Kaj to je in od kod izvira?
Ob času napovedi ACI (Application Centric Infrastructure) leta 2013 so tradicionalnim pristopom k mrežam podatkovnih centrov konkurirali trije glavne sile.
Z enim vidika so SDN-rešitve prve generacije na osnovi OpenFlow obljubljale, da bodo mreže postale bolj fleksibilne in poceni. Ideja je bila, da se proces odločanja, ki ga tradicionalno izvaja lastniška programska oprema stikala, prenese na osrednji nadzorni sistem.
Ta nadzorni sistem bi imel enotno vizijo vsega, kar se dogaja, in bi na podlagi tega programiral strojno opremo vseh stikal na nivoju pravil obdelave točno določenih tokov.
Z druge strani so rešitve za overlejne mreže omogočile uresničevanje potrebne povezanosti in varnostnih politik brez sprememb v fizični mreži, kar je omogočilo gradnjo programske predore med virtualiziranimi gosti. Najbolj znan primer takega pristopa je rešitev od Nicira, ki je bila ob tistem času že kupljena s strani VMWare za 1,26 milijarde dolarjev in je dala začetek današnjemu VMWare NSX. Nekaj pikantnosti situaciji dodaja dejstvo, da so bili soavtorji Nicire isti ljudje, ki so prej stali pri začetkih OpenFlow in so sedaj trdili, da OpenFlow ni primeren za izgradnjo mrežne tovarne podatkovnega centra. .
In nazadnje, komunikacijski čipi, dostopni na odprtem trgu (t.i. merchant silicon), so dosegli stopnjo zrelosti, pri kateri so postali resna grožnja za tradicionalne proizvajalce stikal. Medtem ko je vsak ponudnik prej razvijal čipe za svoja stikala, so čipi zunanjih proizvajalcev, predvsem od Broadcom, sčasoma postali primerljivi s lastniškimi čipi po funkcionalnosti, po razmerju cena/prednost pa so jih presegali. Zato so mnogi menili, da so dnevi stikal na čipih lastne izdelave minili.
ACI je postala 'asimetrični odgovor' Cisco (natančneje, podjetja Insieme, ki je bilo sestavljeno iz njenih nekdanjih zaposlenih) na vse našteto.
Kakšna je razlika z OpenFlow?
Z vidika razporeditve funkcij je ACI dejansko nasprotje OpenFlow.
V arhitekturi OpenFlow nadzornik odgovarja za zapisovanje podrobnih pravil (tokov)
v strojni opremi vseh preklopnikov, kar pomeni, da lahko v veliki mreži leži odgovornost za vzdrževanje in, kar je najpomembneje, spremembo deset milijonov zapisov na stotinah točk v omrežju, zato njegova zmogljivost in zanesljivost pri velikih uvedbah postaneta ozka grla.
V ACI se uporablja obratni pristop: nadzornik je seveda prisoten, vendar preklopniki prejemajo visoko nivojske deklarativne politike od njega, medtem ko preklopnik sam izvaja podrobnosti specifičnih nastavitev v strojni opremi. Nadzornik se lahko ponovno zažene ali pa popolnoma izklopi, mreža pa ne bo utrpela nič slabega, razen seveda, da v tem trenutku ne bo možno upravljati. Zanimivo je, da v ACI obstajajo situacije, v katerih se OpenFlow vseeno uporablja, vendar lokalno v okviru gostitelja za programiranje Open vSwitch.
ACI je v celoti zgrajena na ovijalnem transportu na osnovi VXLAN, vključuje pa tudi spodnji IP transport znotraj enega samega rešitve. Cisco je to poimenoval "integriran ovitek". Kot točka zaključitve ovitkov v ACI se v večini primerov uporabljajo preklopniki tovarne (to opravljajo z vlaknotno hitrostjo). Gostitelji ne smejo vedeti ničesar o tovarni, ovijanju itd., vendar v nekaterih primerih (na primer za povezovanje gostiteljev OpenStack) lahko VXLAN promet prispe tudi do njih.
Ovitki se v ACI uporabljajo ne le za zagotavljanje prilagodljive povezljivosti prek transportnega omrežja, temveč tudi za prenos meta informacij (te se uporabljajo, na primer, za uveljavljanje varnostnih politik).
Čipi Broadcom so že prej uporabljali Cisco v stikalih serije Nexus 3000. V družini Nexus 9000, ki je bila posebej izdana za podporo ACI, je bila sprva implementirana hibridna različica, imenovana Merchant+. V stikalih so istočasno uporabljali nov čip Broadcom Trident 2 in čip, ki ga je razvila Cisco, kar je omogočilo uresničitev vse 'magije' ACI. Zdi se, da je to omogočilo hitrejšo dostavo izdelka in znižanje cene stikala na raven, blizu modelom, ki so temeljila le na Trident 2. Ta pristop je zadoščal za prvih dve ali tri leti dobav ACI. V tem času je Cisco razvila in trgu ponudila naslednjo generacijo Nexus 9000, ki je bila že na njihovih lastnih čipih z višjo zmogljivostjo in funkcijami, vendar po isti ceni. Zunanje specifikacije z vidika interakcije v tovarni so se popolnoma ohranile. Po drugi strani pa se je notranja zasnova popolnoma spremenila: nekaj podobnega refaktoringu, vendar za strojno opremo.
Kako je zasnovana arhitektura Cisco ACI
V najpreprostejšem primeru ACI gradi na topologiji omrežja Clos, ali, kot pogosto pravijo, Spine-Leaf. Število Spine stikal se lahko giblje od dveh (ali enega, če nas ne skrbi odpoved) do šestih. Posledično, več kot jih je, večja je odpornost na napake (manjša izguba pasovne širine in zanesljivosti pri napaki ali vzdrževanju enega Spine) in skupna zmogljivost. Vse zunanje povezave gredo v Leaf stikala: to so strežniki, povezava z zunanjimi omrežji prek L2 ali L3, in povezava s kontrolerji APIC. Pri ACI ne gre le za konfiguracijo, ampak tudi zbiranje statistike, nadzor napak in drugo — vse se izvaja prek vmesnika kontrolerjev, katerih običajno število pri implementacijah je tri.
Stikala nikoli ni treba povezovati prek konzole, niti za zagon omrežja: kontroler sam odkrije stikala in iz njih sestavi tovarno, vključno z nastavitvami vseh službenih protokolov. Zato je pri montaži zelo pomembno, da zapišete serijske številke nameščenih naprav, da ne bi kasneje ugibali, katero stikalo se nahaja v katerem omarici. Za odpravo težav se lahko po potrebi povežete s stikali prek SSH: na njih so dovolj natančno uresničene običajne show-ukaze Cisco.
Znotraj tovarne se uporablja IP-transport, tako da ni nobenega Spanning Tree in drugih grozot preteklosti: vsi povezave so vključene, hitro izgubljanje povezave pa je zelo hitro. Promet v tovarni se prenaša preko tunelov na osnovi VXLAN. Natančneje, Cisco imenuje kapsulacijo iVXLAN, ki se razlikuje od običajnega VXLAN po tem, da se rezervirana polja v omrežnem naslovu uporabljajo za prenos podatkovnih informacij, predvsem o razmerju prometa do skupine EPG. To omogoča izvajanje pravil med skupinami na opremi, pri čemer se uporabljajo njihovi identifikatorji na enak način, kot se naslovi uporabljajo v običajnih dostopnih seznamih.
Tuneli omogočajo razširitev skozi notranji IP-transport ter L2-sekvence in L3 (tj. VRF). Pri tem je privzeti prehod porazdeljen. To pomeni, da vsak preklopnik upravlja usmerjanje prihajajočega prometa v tovarno. Po logiki prenosa prometa je ACI podoben tovarni, ki temelji na VXLAN/EVPN.
Če je tako, kakšne so razlike? V vsem drugem!
Prva razlika, s katero se srečate v ACI, je način vključitve strežnikov v omrežje. V tradicionalnih omrežjih povezava tako fizičnih strežnikov kot virtualk poteka preko VLAN, od katerih temelji vse ostalo: povezljivost, varnost itd. V ACI pa se uporablja konstrukcija, ki jo Cisco imenuje EPG (End-point Group), katere se ni mogoče izogniti. Ali jo lahko enačimo z VLAN? Da, vendar v tem primeru obstaja tveganje, da izgubite večino tistega, kar nudi ACI.
V zvezi z EPG se oblikujejo vsa pravila dostopa, v ACI pa se po privzetku uporablja načelo 'belega seznama', kar pomeni, da je dovoljen samo promet, ki je izrecno dovoljen. To pomeni, da lahko ustvarimo EPG-skupine 'Web' in 'MySQL' ter določimo pravilo, ki dovoljuje interakcijo med njima samo preko vrata 3306. To bo delovalo brez vezave na omrežne naslove in celo znotraj iste podmreže!
Imamo stranke, ki so izbrale ACI prav zaradi te funkcionalnosti, saj omogoča omejevanje dostopov med strežniki (virtualnimi ali fizičnimi — ni pomembno), brez premikanja med podmrežami, kar pomeni, da se naslovitev ne dotika. Da, vemo, nihče ne vpisuje ročno IP-naslove v konfiguracijah aplikacij, kajne?
Pravila usmeravanja saobraćaja u ACI nazivaju se ugovorima. U takvom ugovoru jedna ili više grupa ili nivoa u višeslojnoj aplikaciji postaju provajder usluge (recimo, usluge baze podataka), dok su druge potrošači. Ugovor može jednostavno propuštati saobraćaj ili može uraditi nešto složenije, na primer, usmeriti ga na firewall ili balansirnik, kao i promeniti vrednost QoS.
Kako serveri ulaze u ove grupe? Ako su to fizički serveri ili nešto uključeno u postojeću mrežu, koju smo kreirali kao VLAN-trunk, onda da bi ih stavili u EPG, potrebno je ukazati na port prekidača i korišćeni VLAN. Kao što vidimo, VLAN-ovi se javljaju tamo gde bez njih ne može.
Ako su, međutim, serveri virtuelne mašine, dovoljno je pozvati se na povezano virtuelizacijsko okruženje i sve će se dogoditi samo od sebe: kreiraće se port-grupa (govoreći u terminima - VMWare) za povezivanje VM, dodeliće se potrebni VLAN-ovi ili VXLAN-ovi, upisaće se na potrebnim portovima prekidača itd. Dakle, iako je ACI izgrađena oko fizičke mreže, povezivanje za virtuelne servere izgleda mnogo jednostavnije nego za fizičke. ACI već ima integraciju sa VMWare i MS Hyper-V, kao i podršku za OpenStack i RedHat Virtualization. Od nekog trenutka dostupna je i podrška za platforme kontejnera: Kubernetes, OpenShift, Cloud Foundry, pri čemu se to odnosi i na primenu pravila i monitoring, što znači da mrežni administrator može odmah videti na kojim hostovima koji podovi rade i u koje su grupe uključeni.
Pored uključivanja u određenu port-grupu, virtuelni serveri imaju dodatna svojstva: ime, atribute itd., koje se mogu koristiti kao kriterijumi za njihovo prebacivanje u drugu grupu, recimo, prilikom preimenovanja VM ili pojavljivanja dodatne oznake. Cisco to naziva mikrosegmentacionim grupama, iako sama konstrukcija koja omogućava kreiranje više bezbednosnih segmenata u okviru iste podmreže - takođe predstavlja mikrosegmentation. Pa, dobavljaču je jasnije.
EPG je čisto logična konstrukcija, koja nije vezana za određene preklopnike, servere itd., što omogućava rad s njima i konstrukcijama na njihovoj osnovi (aplikacijama i tenantima) na načine koji su teško ostvarivi u tradicionalnim mrežama, poput kloniranja. Zbog toga je, recimo, vrlo lako stvoriti klon produkcijskog okruženja kako bi se dobilo testno okruženje identično produkcijskom. Može se uraditi ručno, ali je bolje (i jednostavnije) to učiniti putem API-ja.
Općenito, logika upravljanja u ACI-u se značajno razlikuje od onoga s čim se obično susrećete
u klasičnim mrežama iste Cisco kompanije: programski interfejs je primaran, dok je GUI ili CLI sekundaran, jer rade putem istog API-ja. Stoga skoro svako ko se bavi ACI-em, vremenom počinje da se orijentiše u objektnoj strukturi korišćenoj za upravljanje i da automatizuje nešto prema svojim potrebama. Najlakše se to radi iz Pythona: postoje prikladni alati koji su već dostupni.
Obećane zamke
Glavni problem je u tome što su mnoge stvari u ACI-u napravljene na drugačiji način. Da biste normalno počeli raditi s njom, potrebno je preobučiti se. To se posebno odnosi na timove za mrežnu operativnu podršku kod velikih klijenata, gde inženjeri godinama rade na "konfigurisanju VLAN-ova" prema zahtevima. Ono što je sada VLAN — više nije VLAN, a za postavljanje novih mreža u virtualizovane hostove, ručno pravljenje VLAN-ova više uopšte nije neophodno, potpuno zbunjuje tradicionalne mrežne inženjere i tera ih da se drže svojih uobičajenih pristupa. Treba napomenuti da se Cisco potrudila da malo ublaži situaciju i dodala "NXOS-sličan" CLI u kontroler, koji omogućava podešavanje iz interfejsa, sličnog tradicionalnim preklopnicima. No, za normalno korišćenje ACI-ja, moraćete da razumete kako funkcioniše.
Z vidika cen na velikih i srednjih razmerah, ACI mreže se od tradicionalnih mreža na Cisco opremi zapravo ne razlikuju, jer se za njihovo postavljanje koriste isti prekidači (Nexus 9000 može raditi i u ACI i u tradicionalnom režimu i postao je glavna 'radna konjica' za nove projekte u centru podataka). Međutim, za centre podataka sa dva prekidača, prisustvo kontrolera i Spine-Leaf arhitekture ima značajnu ulogu. Nedavno je predstavljena Mini ACI fabrika, u kojoj su dva kontrolera od tri zamenjena virtualnim mašinama. To smanjuje razliku u ceni, ali ona i dalje ostaje. Dakle, izbor za naručitelja zavisi od toga koliko je zainteresovan za funkcije sigurnosti, integraciju sa virtualizacijom, jedinstvenu tačku upravljanja i ostalo.
Izvor: habr.com
