Uz pomoć ovog čarobnog dijela Cisco ACI skripte, možete brzo postaviti mrežu.
Tvornica mreže za Cisco ACI podatkovni centar postoji već pet godina, ali Habré zapravo nije ništa rekao o tome, pa sam odlučio to malo popraviti. Reći ću vam iz vlastitog iskustva što je to, čemu služi i gdje ima grablje.
Što je to i odakle je došlo?
U vrijeme kada je ACI (Application Centric Infrastructure) najavljen 2013., konkurenti su napredovali u tradicionalnim pristupima mrežama podatkovnih centara s tri strane odjednom.
S jedne strane, "prva generacija" SDN rješenja temeljena na OpenFlowu obećavala je da će mreže učiniti fleksibilnijima i jeftinijima u isto vrijeme. Ideja je bila premjestiti donošenje odluka koje se tradicionalno obavlja putem vlasničkog softvera prekidača na središnji upravljač.
Taj bi kontroler imao jedinstvenu viziju svega što se događa te bi na temelju toga programirao hardver svih switcheva na razini pravila za obradu određenih tokova.
S druge strane, preklapajuća mrežna rješenja omogućila su implementaciju potrebnih politika povezivanja i sigurnosti bez ikakvih promjena u fizičkoj mreži, gradeći softverske tunele između virtualiziranih hostova. Najpoznatiji primjer ovog pristupa bila je Nicira, koju je do tada već kupio VMWare za 1,26 milijardi dolara i iz koje je nastao trenutni VMWare NSX. Nešto pikanterije situaciji dodala je činjenica da su suosnivači Nicire bili isti oni ljudi koji su prethodno stajali u podrijetlu OpenFlowa, a sada kažu da je za izgradnju tvornice podatkovnog centra .
I konačno, preklopni čipovi dostupni na otvorenom tržištu (ono što se naziva trgovački silicij) dosegnuli su stupanj zrelosti u kojem su postali prava prijetnja tradicionalnim proizvođačima preklopnika. Ako je ranije svaki dobavljač samostalno razvijao čipove za svoje sklopke, s vremenom su čipovi trećih proizvođača, prvenstveno Broadcoma, počeli smanjivati udaljenost od čipova dobavljača u smislu funkcija i nadmašili su ih u pogledu omjera cijene i performansi. Stoga su mnogi vjerovali da su dani prekidača na čipovima vlastitog dizajna odbrojani.
ACI je postao "asimetrični odgovor" Cisca (točnije njegove tvrtke Insieme koju su osnovali njegovi bivši zaposlenici) na sve navedeno.
Koja je razlika s OpenFlowom?
Što se tiče distribucije funkcija, ACI je zapravo suprotnost OpenFlowu.
U OpenFlow arhitekturi, kontroler je odgovoran za pisanje detaljnih pravila (tijekova)
u hardveru svih preklopnika, odnosno u velikoj mreži, može biti odgovoran za održavanje i, što je najvažnije, mijenjanje desetaka milijuna zapisa na stotinama točaka u mreži, tako da njegova izvedba i pouzdanost postaju usko grlo u velika implementacija.
ACI koristi obrnuti pristup: naravno, postoji i kontroler, ali preklopnici od njega primaju deklarativne politike visoke razine, a sam preklopnik izvodi njihovo prikazivanje u detalje specifičnih postavki u hardveru. Upravljač se može ponovno pokrenuti ili potpuno isključiti, a mreži se neće dogoditi ništa loše, osim, naravno, nedostatka kontrole u ovom trenutku. Zanimljivo je da postoje situacije u ACI-ju u kojima se OpenFlow i dalje koristi, ali lokalno unutar hosta za programiranje Open vSwitch.
ACI je u potpunosti izgrađen na prijenosu preklapanja temeljenom na VXLAN-u, ali uključuje temeljni IP prijenos kao dio jedinstvenog rješenja. Cisco je to nazvao izrazom "integrirano preklapanje". Kao završna točka za slojeve u ACI-ju, u većini slučajeva koriste se tvornički preklopnici (oni to rade brzinom veze). Domaćini ne moraju znati ništa o tvornici, enkapsulaciji itd., međutim, u nekim slučajevima (na primjer, za povezivanje OpenStack hostova), VXLAN promet se može dovesti do njih.
Prekrivanja se u ACI-ju koriste ne samo za pružanje fleksibilne povezanosti kroz transportnu mrežu, već i za prijenos metainformacija (koristi se, na primjer, za primjenu sigurnosnih politika).
Čipove iz Broadcoma prethodno je koristio Cisco u sklopkama serije Nexus 3000. U obitelji Nexus 9000, posebno objavljenoj za podršku ACI-ju, izvorno je implementiran hibridni model koji se zvao Merchant +. Prekidač je istovremeno koristio i novi čip Broadcom Trident 2 i komplementarni čip koji je razvio Cisco, a koji implementira svu magiju ACI-ja. Očigledno, to je omogućilo ubrzanje izdavanja proizvoda i smanjenje cijene prekidača na razinu blisku modelima baziranim na Tridentu 2. Ovaj pristup je bio dovoljan za prve dvije ili tri godine isporuka ACI-ja. Tijekom tog vremena, Cisco je razvio i lansirao sljedeću generaciju Nexusa 9000 na vlastitim čipovima s više performansi i skupa značajki, ali na istoj razini cijene. Vanjske specifikacije u smislu interakcije u tvornici potpuno su sačuvane. U isto vrijeme, unutarnje punjenje se potpuno promijenilo: nešto poput refactoringa, ali za željezo.
Kako radi Cisco ACI arhitektura
U najjednostavnijem slučaju, ACI je izgrađen na topologiji Klose mreže ili, kako se često kaže, Spine-Leaf. Sklopke na razini kralježnice mogu biti od dvije (ili jedne, ako nam nije bitna tolerancija kvarova) do šest. U skladu s tim, što ih je više, to je veća tolerancija greške (manje je propusnost i smanjenje pouzdanosti u slučaju nezgode ili održavanja jedne kralježnice) i ukupna izvedba. Sve vanjske veze idu na leaf-level switcheve: to su serveri, i spajanje s vanjskim mrežama preko L2 ili L3, te povezivanje APIC kontrolera. Općenito, kod ACI-ja nije samo konfiguracija, već i prikupljanje statistike, praćenje kvarova i tako dalje - sve se radi preko sučelja kontrolera, kojih ima tri u implementacijama standardne veličine.
Nikada se ne morate spajati na preklopnike s konzolom, čak ni za pokretanje mreže: kontroler sam detektira preklopnike i od njih sastavlja tvornicu, uključujući postavke svih servisnih protokola, stoga je, usput, vrlo važno zapišite serijske brojeve opreme koja se ugrađuje tijekom instalacije, tako da kasnije ne morate pogađati koji je prekidač u kojem se stalku nalazi. Za rješavanje problema, ako je potrebno, možete se spojiti na preklopnike putem SSH-a: oni vrlo pažljivo reproduciraju uobičajene naredbe Cisco show.
Interno, tvornica koristi IP transport, tako da u njoj nema Spanning Treea i ostalih užasa prošlosti: uključene su sve veze, a konvergencija u slučaju kvarova je vrlo brza. Promet u tkanini prenosi se kroz tunele temeljene na VXLAN-u. Točnije, sam Cisco iVXLAN naziva enkapsulacija, a razlikuje se od običnog VXLAN-a po tome što se rezervirana polja u mrežnom zaglavlju koriste za prijenos servisnih informacija, prvenstveno o odnosu prometa prema EPG grupi. To vam omogućuje implementaciju pravila interakcije između grupa u opremi, koristeći njihove brojeve na isti način kao što se adrese koriste u običnim pristupnim listama.
Tuneli dopuštaju da se L2 segmenti i L3 segmenti (tj. VRF) protežu kroz interni IP transport. U ovom slučaju, zadani pristupnik je distribuiran. To znači da je svaki prekidač odgovoran za usmjeravanje prometa koji ulazi u tkaninu. U smislu logike protoka prometa, ACI je sličan VXLAN/EVPN fabric.
Ako je tako, koje su razlike? Sve ostalo!
Razlika broj jedan s kojom se susrećete kod ACI-ja je kako su poslužitelji povezani s mrežom. U tradicionalnim mrežama, uključivanje i fizičkih poslužitelja i virtualnih strojeva ide na VLAN-ove, a sve ostalo pleše iz njih: povezivost, sigurnost itd. U ACI-ju se koristi dizajn koji Cisco naziva EPG (End-point Group), iz kojeg nema kamo pobjeći. Je li to moguće izjednačiti s VLAN-om? Da, ali u ovom slučaju postoji mogućnost gubitka većine onoga što ACI daje.
Što se tiče EPG-a, sva pravila pristupa su formulirana, au ACI-ju se standardno koristi princip “bijele liste”, odnosno dopušten je samo promet čiji je prolaz izričito dopušten. Odnosno, možemo stvoriti EPG grupe "Web" i "MySQL" i definirati pravilo koje dopušta komunikaciju između njih samo na portu 3306. Ovo će raditi bez vezanja za mrežne adrese, pa čak i unutar iste podmreže!
Imamo klijente koji su odabrali ACI upravo zbog ove značajke, budući da vam omogućuje ograničavanje pristupa između poslužitelja (virtualnih ili fizičkih - svejedno) bez povlačenja između podmreža, što znači bez diranja u adresiranje. Da, da, znamo da nitko ne propisuje ručno IP adrese u konfiguracijama aplikacija, zar ne?
Prometna pravila u ACI-ju nazivaju se ugovorima. U takvom ugovoru, jedna ili više grupa ili razina u višeslojnoj aplikaciji postaju davatelji usluga (recimo, usluga baze podataka), ostali postaju potrošači. Ugovor može jednostavno propuštati promet ili može učiniti nešto složenije, na primjer, usmjeriti ga na vatrozid ili balanser, te također promijeniti QoS vrijednost.
Kako poslužitelji ulaze u te grupe? Ako su to fizički poslužitelji ili nešto što je uključeno u postojeću mrežu u koju smo kreirali VLAN trunk, tada da biste ih smjestili u EPG, morat ćete pokazati na port preklopnika i VLAN koji se na njemu koristi. Kao što vidite, VLAN-ovi se pojavljuju tamo gdje ne možete bez njih.
Ako su poslužitelji virtualni strojevi, tada je dovoljno pozvati se na povezano virtualizacijsko okruženje, a onda će se sve dogoditi samo od sebe: kreirat će se grupa priključaka (u smislu VMWare) za povezivanje VM-a, potrebni VLAN-ovi ili VXLAN-ovi će se budu dodijeljeni, bit će registrirani na potrebnim portovima preklopnika, itd. Dakle, iako je ACI izgrađen oko fizičke mreže, veze za virtualne poslužitelje izgledaju mnogo jednostavnije nego za fizičke. ACI već ima ugrađenu povezanost s VMWare i MS Hyper-V, kao i podršku za OpenStack i RedHat Virtualization. Od nekog trenutka pojavila se i ugrađena podrška za kontejnerske platforme: Kubernetes, OpenShift, Cloud Foundry, a tiče se i primjene politika i nadzora, odnosno mrežni administrator može odmah vidjeti na kojim hostovima koji podovi rade i u koje skupine spadaju.
Osim što su uključeni u određenu grupu portova, virtualni poslužitelji imaju dodatna svojstva: ime, atribute itd., koja se mogu koristiti kao kriteriji za njihov prijenos u drugu grupu, recimo, kada se VM preimenuje ili se dodatna oznaka pojavi u to. Cisco to naziva grupama mikrosegmentacije, iako je, uglavnom, sam dizajn s mogućnošću stvaranja mnogo sigurnosnih segmenata u obliku EPG-ova na istoj podmreži također prilično mikrosegmentacija. Pa, prodavač zna bolje.
Sami EPG-ovi su čisto logičke konstrukcije, nisu vezane za određene preklopnike, poslužitelje itd., tako da možete raditi stvari s njima i konstrukcijama temeljenim na njima (aplikacije i stanari) koje je teško učiniti u običnim mrežama, kao što je kloniranje. Kao rezultat toga, recimo da je vrlo lako klonirati proizvodno okruženje kako bi se dobilo testno okruženje koje je zajamčeno identično proizvodnom okruženju. Možete to učiniti ručno, ali je bolje (i lakše) putem API-ja.
Općenito, logika upravljanja u ACI-ju nije nimalo slična onome što obično susrećete
u tradicionalnim mrežama iz istog Cisca: softversko sučelje je primarno, a GUI ili CLI su sekundarni, budući da rade kroz isti API. Stoga se gotovo svi uključeni u ACI nakon nekog vremena počnu snalaziti u objektnom modelu koji se koristi za upravljanje i automatizirati nešto kako bi odgovaralo njihovim potrebama. Najlakši način da to učinite je iz Pythona: za to postoje zgodni gotovi alati.
Obećane grablje
Glavni problem je što se mnoge stvari u ACI-ju rade drugačije. Da biste s njim počeli normalno raditi, morate se prekvalificirati. To posebno vrijedi za timove za mrežne operacije u velikim korisnicima, gdje su inženjeri godinama "propisivali VLAN-ove" na zahtjev. Činjenica da sada VLAN-ovi više nisu VLAN-ovi i da ne morate ručno stvarati VLAN-ove kako biste postavili nove mreže u virtualizirane hostove, u potpunosti skida krov s tradicionalnih umrežavača i tjera ih da se drže poznatih pristupa. Valja napomenuti da je Cisco pokušao malo zasladiti pilulu i dodao CLI "poput NXOS-a" kontroleru, koji vam omogućuje konfiguraciju sa sučelja sličnog tradicionalnim prekidačima. Ali ipak, da biste počeli normalno koristiti ACI, morate razumjeti kako on funkcionira.
Što se tiče cijene, na velikim i srednjim razmjerima, ACI mreže se zapravo ne razlikuju od tradicionalnih mreža na Cisco opremi, budući da se za njihovu izgradnju koriste isti preklopnici (Nexus 9000 može raditi u ACI iu tradicionalnom načinu rada i sada su postali glavni "radni konj" za nove projekte podatkovnih centara). Ali za podatkovne centre s dva preklopnika, prisutnost kontrolera i Spine-Leaf arhitekture, naravno, daju se osjetiti. Nedavno se pojavila Mini ACI tvornica u kojoj su dva od tri kontrolera zamijenjena virtualnim strojevima. Time se smanjuje razlika u trošku, ali ona i dalje ostaje. Dakle, za kupca, izbor je diktiran time koliko su zainteresirani za sigurnosne značajke, integraciju s virtualizacijom, jedinstvenu točku kontrole, i tako dalje.
Izvor: www.habr.com