S pomočjo tega čarobnega dela skripta Cisco ACI lahko hitro nastavite omrežje.
Omrežna tovarna za podatkovni center Cisco ACI obstaja že pet let, vendar Habré o tem ni povedal ničesar, zato sem se odločil, da jo malo popravim. Iz lastnih izkušenj vam povem, kaj je to, čemu služi in kje ima grablje.
Kaj je to in od kod prihaja?
Do napovedi ACI (Application Centric Infrastructure) leta 2013 so konkurenti napredovali pri tradicionalnih pristopih k omrežjem podatkovnih centrov s treh strani hkrati.
Po eni strani so rešitve SDN "prve generacije", ki temeljijo na OpenFlow, obljubljale, da bodo omrežja naredila bolj prilagodljiva in hkrati cenejša. Zamisel je bila prenesti odločanje, ki ga tradicionalno izvaja lastniška programska oprema stikala, na centralni krmilnik.
Ta krmilnik bi imel enotno vizijo vsega dogajanja in bi na podlagi tega programiral strojno opremo vseh stikal na ravni pravil za obdelavo določenih tokov.
Po drugi strani pa so prekrivne omrežne rešitve omogočile implementacijo potrebnih politik povezljivosti in varnosti brez kakršnih koli sprememb v fizičnem omrežju, gradnjo programskih tunelov med virtualiziranimi gostitelji. Najbolj znan primer tega pristopa je bila Nicira, ki jo je do takrat že kupil VMWare za 1,26 milijarde USD in je povzročila sedanji VMWare NSX. Nekaj pikantnosti je situaciji dodalo dejstvo, da so bili soustanovitelji Nicire isti ljudje, ki so pred tem stali ob nastanku OpenFlow, zdaj pravijo, da je za izgradnjo tovarne podatkovnega centra .
In končno, stikalni čipi, ki so na voljo na prostem trgu (kar se imenuje trgovski silicij), so dosegli stopnjo zrelosti, ko so postali resnična grožnja tradicionalnim proizvajalcem stikal. Če je prej vsak prodajalec samostojno razvijal čipe za svoja stikala, so sčasoma čipi tretjih proizvajalcev, predvsem Broadcoma, začeli zmanjševati razdaljo s čipi prodajalcev v smislu funkcij in jih presegli v razmerju med ceno in zmogljivostjo. Zato so mnogi verjeli, da so stikalom na čipih lastne zasnove šteti dnevi.
ACI je postal "asimetrični odgovor" Cisca (natančneje njegovega podjetja Insieme, ki so ga ustanovili njegovi bivši zaposleni) na vse našteto.
Kakšna je razlika z OpenFlow?
Kar zadeva porazdelitev funkcij, je ACI pravzaprav nasprotje OpenFlow.
V arhitekturi OpenFlow je krmilnik odgovoren za pisanje podrobnih pravil (tokov)
v strojni opremi vseh stikal, torej v velikem omrežju, je lahko odgovoren za vzdrževanje in, kar je najpomembnejše, spreminjanje več deset milijonov zapisov na stotinah točk v omrežju, zato njegovo delovanje in zanesljivost postaneta ozko grlo v velika izvedba.
ACI uporablja obratni pristop: seveda obstaja tudi krmilnik, vendar stikala od njega prejmejo deklarativne pravilnike na visoki ravni, stikalo pa samo izvaja njihovo upodabljanje v podrobnosti posebnih nastavitev v strojni opremi. Krmilnik lahko znova zaženete ali popolnoma izklopite in omrežju se ne bo zgodilo nič slabega, razen seveda pomanjkanja nadzora v tem trenutku. Zanimivo je, da obstajajo situacije v ACI, v katerih se OpenFlow še vedno uporablja, vendar lokalno znotraj gostitelja za programiranje Open vSwitch.
ACI je v celoti zgrajen na prekrivnem transportu, ki temelji na VXLAN, vendar vključuje osnovni IP transport kot del ene rešitve. Cisco je to imenoval izraz "integrirano prekrivanje". Kot zaključna točka za prekrivanja v ACI se v večini primerov uporabljajo tovarniška stikala (to počnejo s hitrostjo povezave). Gostiteljem ni treba vedeti ničesar o tovarni, enkapsulaciji itd., vendar se lahko v nekaterih primerih (na primer za povezavo gostiteljev OpenStack) do njih prenese promet VXLAN.
Prekrivanja se v ACI uporabljajo ne le za zagotavljanje prilagodljive povezljivosti prek transportnega omrežja, temveč tudi za prenos metainformacij (uporabljajo se na primer za uporabo varnostnih politik).
Čipe iz Broadcoma je prej uporabljal Cisco v stikalih serije Nexus 3000. V družini Nexus 9000, posebej izdani za podporo ACI, je bil prvotno implementiran hibridni model, ki se je imenoval Merchant +. Stikalo je istočasno uporabljalo tako novi čip Broadcom Trident 2 kot komplementarni čip, ki ga je razvil Cisco, ki udejanja vse čare ACI. Očitno je to omogočilo pospešitev izdaje izdelka in znižanje cene stikala na raven, ki je blizu modelom, ki preprosto temeljijo na Trident 2. Ta pristop je bil dovolj za prvi dve ali tri leta dobave ACI. V tem času je Cisco razvil in lansiral naslednjo generacijo Nexusa 9000 na lastnih čipih z večjo zmogljivostjo in naborom funkcij, vendar na enaki cenovni ravni. Zunanje specifikacije glede interakcije v tovarni so popolnoma ohranjene. Hkrati se je notranje polnjenje popolnoma spremenilo: nekaj podobnega preoblikovanju, vendar za strojno opremo.
Kako deluje arhitektura Cisco ACI
V najpreprostejšem primeru je ACI zgrajen na topologiji omrežja Klose ali, kot pogosto pravijo, Spine-Leaf. Spinelevel stikala so lahko od dveh (ali enega, če nam ni pomembna toleranca napak) do šestih. Skladno s tem, več kot jih je, večja je toleranca napak (nižja je pasovna širina in zmanjšanje zanesljivosti v primeru nesreče ali vzdrževanja ene hrbtenice) in splošna zmogljivost. Vse zunanje povezave gredo na leaf-level stikala: to so strežniki in povezovanje z zunanjimi omrežji prek L2 ali L3 ter povezovanje APIC krmilnikov. Na splošno pri ACI ni samo konfiguracija, ampak tudi zbiranje statističnih podatkov, spremljanje napak in tako naprej - vse poteka prek vmesnika krmilnikov, ki so v izvedbah standardne velikosti trije.
Nikoli se vam ni treba povezati s stikali s konzolo, niti za zagon omrežja: krmilnik sam zazna stikala in iz njih sestavi tovarno, vključno z nastavitvami vseh servisnih protokolov, zato je mimogrede zelo pomembno, Zapišite si serijske številke opreme, ki se vgrajuje med namestitvijo, da vam kasneje ne bo treba ugibati, katero stikalo je v kateri omarici. Za odpravljanje težav se lahko po potrebi povežete s stikali prek SSH: običajne ukaze Cisco show precej natančno reproducirajo.
Interno tovarna uporablja IP transport, zato v njej ni Spanning Treeja in drugih grozljivk preteklosti: vključene so vse povezave, konvergenca v primeru okvar je zelo hitra. Promet v tkanini se prenaša skozi tunele, ki temeljijo na VXLAN. Natančneje, Cisco sam imenuje iVXLAN encapsulation, od običajnega VXLAN pa se razlikuje po tem, da se rezervirana polja v omrežni glavi uporabljajo za prenos servisnih informacij, predvsem o razmerju prometa do skupine EPG. To vam omogoča izvajanje pravil interakcije med skupinami v opremi z uporabo njihovih številk na enak način, kot se uporabljajo naslovi v običajnih dostopnih seznamih.
Tuneli omogočajo, da se tako segmenti L2 kot segmenti L3 (tj. VRF) raztegnejo skozi notranji IP transport. V tem primeru je privzeti prehod porazdeljen. To pomeni, da je vsako stikalo odgovorno za usmerjanje prometa, ki vstopa v tkanino. Kar zadeva logiko prometnega toka, je ACI podoben strukturi VXLAN/EVPN.
Če da, kakšne so razlike? Vse ostalo!
Glavna razlika, na katero naletite pri ACI, je, kako so strežniki povezani v omrežje. V tradicionalnih omrežjih gre vključitev fizičnih strežnikov in virtualnih strojev v omrežja VLAN, vse ostalo pa pleše iz njih: povezljivost, varnost itd. V ACI se uporablja zasnova, ki jo Cisco imenuje EPG (End-point Group), iz katerega ni nikamor stran. Ali ga je mogoče enačiti z VLAN? Da, vendar v tem primeru obstaja možnost, da izgubite večino tega, kar daje ACI.
V zvezi z EPG so oblikovana vsa pravila dostopa, v ACI pa je privzeto uporabljen princip "belega seznama", kar pomeni, da je dovoljen samo promet, katerega prehod je izrecno dovoljen. To pomeni, da lahko ustvarimo skupini EPG "Web" in "MySQL" in določimo pravilo, ki omogoča komunikacijo med njima le na vratih 3306. To bo delovalo brez vezave na omrežne naslove in celo znotraj istega podomrežja!
Imamo stranke, ki so izbrale ACI ravno zaradi te funkcije, saj omogoča omejitev dostopa med strežniki (virtualnimi ali fizičnimi - ni pomembno) brez vlečenja med podomrežji, kar pomeni brez dotikanja naslavljanja. Da, da, saj vemo, da nihče ne predpisuje IP naslovov v konfiguracijah aplikacij ročno, kajne?
Prometna pravila v ACI imenujemo pogodbe. V takšni pogodbi postane ena ali več skupin ali ravni v večnivojski aplikaciji ponudnik storitev (recimo storitev baze podatkov), drugi postanejo potrošniki. Pogodba lahko preprosto prenese promet ali pa naredi nekaj bolj zapletenega, na primer, usmeri ga na požarni zid ali izravnalnik in spremeni tudi vrednost QoS.
Kako pridejo strežniki v te skupine? Če so to fizični strežniki ali nekaj, kar je vključeno v obstoječe omrežje, v katerega smo ustvarili VLAN trunk, boste morali, da jih postavite v EPG, pokazati na vrata stikala in VLAN, ki se na njem uporablja. Kot lahko vidite, se VLAN pojavljajo tam, kjer brez njih ne morete.
Če so strežniki virtualni stroji, je dovolj, da se sklicujete na povezano virtualizacijsko okolje, nato pa se bo vse zgodilo samo: ustvarjena bo skupina vrat (v smislu VMWare) za povezavo VM, potrebni VLAN ali VXLAN bodo dodeljeni, bodo registrirani na potrebnih stikalnih vratih itd. Torej, čeprav je ACI zgrajen okoli fizičnega omrežja, so povezave za virtualne strežnike videti veliko enostavnejše kot za fizične. ACI že ima vgrajeno povezljivost z VMWare in MS Hyper-V ter podporo za OpenStack in RedHat Virtualization. Od nekega trenutka naprej se je pojavila tudi vgrajena podpora za kontejnerske platforme: Kubernetes, OpenShift, Cloud Foundry, pri čemer gre tako za uporabo politik kot za spremljanje, torej skrbnik omrežja lahko takoj vidi, na katerih gostiteljih kateri podi delujejo in v katere skupine spadajo.
Poleg tega, da so vključeni v določeno skupino vrat, imajo navidezni strežniki dodatne lastnosti: ime, atribute itd., ki jih je mogoče uporabiti kot merilo za njihov prenos v drugo skupino, na primer, ko se VM preimenuje ali se pojavi dodatna oznaka v to. Cisco to imenuje skupine mikrosegmentacije, čeprav je na splošno tudi sama zasnova z zmožnostjo ustvarjanja številnih varnostnih segmentov v obliki EPG v istem podomrežju precejšnja mikrosegmentacija. No, prodajalec ve bolje.
Sami EPG so čisto logični konstrukti, ki niso vezani na določena stikala, strežnike ipd., tako da lahko z njimi in konstrukti, ki temeljijo na njih (aplikacije in najemniki), počnete stvari, ki jih je v običajnih omrežjih težko narediti, na primer kloniranje. Kot rezultat, recimo, da je zelo enostavno klonirati produkcijsko okolje, da bi dobili testno okolje, ki je zajamčeno identično produkcijskemu okolju. To lahko storite ročno, vendar je bolje (in lažje) prek API-ja.
Na splošno logika nadzora v ACI sploh ni podobna tisti, ki jo običajno srečate
v tradicionalnih omrežjih istega Cisca: programski vmesnik je primarni, GUI ali CLI pa sekundarna, saj delujeta prek istega API-ja. Zato skoraj vsi, ki so vključeni v ACI, čez nekaj časa začnejo krmariti po objektnem modelu, ki se uporablja za upravljanje, in nekaj avtomatizirajo, da ustrezajo njihovim potrebam. Najlažji način za to je iz Pythona: za to obstajajo priročna že pripravljena orodja.
Obljubljene grablje
Glavna težava je, da se marsikaj v ACI dela drugače. Če želite z njim normalno delati, se morate prekvalificirati. To še posebej velja za ekipe za omrežne operacije pri velikih strankah, kjer inženirji že leta "predpisujejo VLAN" na zahtevo. Dejstvo, da zdaj omrežja VLAN niso več omrežja VLAN in vam ni treba ustvarjati omrežij VLAN ročno, da bi postavili nova omrežja v virtualizirane gostitelje, popolnoma odnese streho tradicionalnim omrežnikom in jih prisili, da se oprimejo znanih pristopov. Opozoriti je treba, da je Cisco poskušal tableto nekoliko posladkati in je krmilniku dodal CLI, podoben NXOS-u, ki omogoča konfiguracijo iz vmesnika, podobnega tradicionalnim stikalom. Toda kljub temu, da začnete normalno uporabljati ACI, morate razumeti, kako deluje.
Cenovno se omrežja ACI v velikem in srednjem obsegu dejansko ne razlikujejo od tradicionalnih omrežij na opremi Cisco, saj se za njihovo izgradnjo uporabljajo enaka stikala (Nexus 9000 lahko deluje v ACI in v tradicionalnem načinu in je zdaj postal glavni »delovnega konja« za nove projekte podatkovnih centrov). Toda pri podatkovnih centrih z dvema stikaloma se prisotnost krmilnikov in arhitekture Spine-Leaf seveda čutita. Pred kratkim se je pojavila tovarna Mini ACI, v kateri sta dva od treh krmilnikov nadomeščena z virtualnimi stroji. To zmanjša razliko v stroških, vendar še vedno ostaja. Za stranko torej izbiro narekuje to, koliko jo zanimajo varnostne funkcije, integracija z virtualizacijo, enotna točka nadzora ipd.
Vir: www.habr.com