Uz pomoć ovog čarobnog skripta, Cisco ACI možete brzo postaviti mrežu.
Mrežna fabrika za podatkovne centre Cisco ACI postoji već pet godina, ali se na Habr-u o njoj baš i nije pričalo, pa sam odlučio to malo popraviti. Ispričat ću iz vlastitog iskustva što je to, koja je njena korist i koje su joj mane.
Što je to i odakle dolazi?
U vrijeme najave ACI (Application Centric Infrastructure) 2013. godine, tradicionalnim pristupima mrežama podatkovnih centara napadali su konkurenti s tri različite strane.
S jedne strane, SDN rješenja "prve generacije" temeljena na OpenFlow-u obećavala su da će učiniti mreže fleksibilnijima i jeftinijima u isto vrijeme. Ideja je bila da se odlučivanje, koje je tradicionalno obavljalo proprietary softver na prekidačima, preda centralnom kontroleru.
Ovaj kontroler bi imao jedinstveni pregled svega što se događa i na temelju toga programirao bi opremu svih switcheva na razini pravila obrade određenih tokova.
S druge strane, overlay mrežna rješenja pružila su mogućnost ostvarivanja potrebne povezanosti i sigurnosnih politika bez promjena u fizičkoj mreži, gradeći softverske tunele između virtualiziranih hostova. Najpoznatiji primjer ovog pristupa bilo je rješenje od Nicira, koja je u tom trenutku već kupljena od strane VMWare za 1,26 milijardi dolara i dala je početak današnjem VMWare NSX-u. Dodatnu pikantnost situaciji davali su osnivači Nicira, koji su bili iste osobe koje su ranije stajale na čelu OpenFlow-a, a sada su govorili da je za izgradnju fabrike podatkovnog centra .
Na kraju, čipovi za prebacivanje dostupni na otvorenom tržištu (ono što se naziva merchant silicon) postigli su razinu zrelosti koja je postala stvarna prijetnja tradicionalnim proizvođačima prekidača. Dok je ranije svaki dobavljač sam razvijao čipove za svoje prekidače, s vremenom su čipovi trećih proizvođača, prvenstveno od Brоadcom-a, počeli smanjivati razliku s dobavljačskim čipovima po funkcionalnosti, a prema omjeru cijena/performance, bili su bolji. Stoga su mnogi smatrali da su dani prekidača baziranih na vlastitim čipovima prošli.
ACI je postala "asimetričan odgovor" Cisco-a (točnije, kompanije Insieme koja je postala dio Cisco-a, osnovali su je bivši zaposlenici) na sve navedeno.
Koja je razlika s OpenFlow-om?
S aspekta raspodjele funkcija, ACI je zapravo suprotnost OpenFlow-u.
U OpenFlow arhitekturi, kontroler je odgovoran za definiranje detaljnih pravila (tokova)
u hardveru svih prekidača, to jest, u velikoj mreži može nositi odgovornost za održavanje i, što je još važnije, promjenu desetaka milijuna unosa na stotinama točaka u mreži, zbog čega njegova izvedba i pouzdanost kod velikih implementacija postaju usko grlo.
U ACI se koristi suprotan pristup: kontroler također postoji, ali prekidači od njega primaju visoko razine deklarativnih politika, a njihovo renderiranje u detalje konkretnih postavki u hardveru obavlja sam prekidač. Kontroler se može ponovo pokrenuti ili potpuno isključiti, a s mrežom se neće dogoditi ništa loše, osim, naravno, trenutačne nemogućnosti upravljanja. Zanimljivo je da u ACI postoje situacije u kojima se OpenFlow ipak koristi, ali lokalno unutar hosta za programiranje Open vSwitch-a.
ACI je u cijelosti izgrađena na overlay transportu temeljenom na VXLAN-u, ali uključuje i donji IP transport unutar jednog rješenja. Cisco je to nazvao 'integriranim overlay-om'. Kao točka terminacije overlay-a u ACI-u najčešće se koriste fabrikantski prekidači (to čine brzinom kanala). Hostovi ne moraju znati ništa o fabrici, enkapsulaciji itd., ali u određenim slučajevima (recimo, za povezivanje OpenStack hostova) VXLAN promet može stizati i do njih.
Overlayi se u ACI koriste ne samo za osiguravanje fleksibilne povezanosti kroz transportnu mrežu, već i za prijenos meta podataka (koji se koristi, na primjer, za primjenu politika sigurnosti).
Chips from Broadcom have previously been used by Cisco in the Nexus 3000 series switches. In the Nexus 9000 family, specifically released to support ACI, a hybrid model was initially implemented, referred to as Merchant+. In this switch, both the new Broadcom Trident 2 chip and a complementary chip developed by Cisco were used simultaneously, executing all the magic of ACI. This, apparently, allowed for a faster product launch and reduced the switch's price to a level close to models purely based on Trident 2. This approach was sufficient for the first two to three years of ACI deliveries. During that time, Cisco developed and released the next generation of Nexus 9000 based on their own chips with greater performance and feature sets, but at the same price level. The external specifications in terms of factory interaction remained completely intact. However, the internal components changed entirely: something akin to refactoring, but for hardware.
Kako je arhitektura Cisco ACI
U najjednostavnijem slučaju, ACI se gradi prema topologiji Clos mreže, ili, kako se često naziva, Spine-Leaf. Broj preklopnika razine Spine može biti od dva (ili jednog, ako nas ne brine otpornost na provale) do šest. Shodno tome, što ih je više, to je veća otpornost na provale (manje smanjenje propusnosti i pouzdanosti u slučaju kvara ili održavanja jednog Spine) i ukupna izvedba. Sve vanjske veze idu na Leaf razinu preklopnika: to su i poslužitelji, te povezivanje s vanjskim mrežama putem L2 ili L3, kao i povezivanje s APIC kontrolerima. U načelu, ne samo da je postavka ACI-a jednostavna, nego i prikupljanje statistike, praćenje kvarova i drugo — sve se obavlja putem sučelja kontrolera, kojih u standardnim implementacijama obično ima tri.
Preklopnicima se nikada ne treba priključivati putem konzole, čak ni za pokretanje mreže: kontroler sam otkriva preklopnike i sastavlja iz njih fabriku, uključujući postavke svih servisnih protokola. Zbog toga je, usput, vrlo važno prilikom montaže zabilježiti serijske brojeve ugrađenih uređaja, kako se kasnije ne bi pogađalo koji je preklopnik u kojem okviru. Za rješavanje problema može se, po potrebi, priključiti na preklopnike putem SSH: na njima su dovoljno vjerno reproducirane uobičajene show-komande Cisco.
Unutar fabrike koristi se IP-transport, tako da nema Spanning Tree i drugih užasnih stvari iz prošlosti: svi linkovi su aktivni, a konvergencija u slučaju kvarova je vrlo brza. Promet unutar fabrike prenosi se putem tunela baziranih na VXLAN-u. Konkretno, sama Cisco označava inkapsulaciju kao iVXLAN, koja se razlikuje od običnog VXLAN-a po tome što rezervisana polja u mrežnom zaglavlju služe za prenošenje servisnih informacija, prvenstveno o odnosu prometa s grupom EPG. To omogućava implementaciju pravila interakcije između grupa u hardveru, koristeći njihove brojeve baš kao što se u običnim pristupnim listama koriste adrese.
Tuneli omogućavaju proširenje kako L2-segmenta tako i L3 (tj. VRF) putem unutrašnjeg IP-transporta. Pri tome, podrazumevani gateway je distribuiran. To znači da svaka preklopna jedinica upravlja usmeravanjem dolaznog prometa u fabriku. U delu logike prenošenja prometa, ACI je sličan fabrici koja se oslanja na VXLAN/EVPN.
Ako je to tako, koja su razlikovna obeležja? U svemu ostalom!
Razlika broj jedan sa kojom se susrećemo u ACI-u je način na koji se serveri uključuju u mrežu. U tradicionalnim mrežama, uključivanje fizičkih servera i virtuelnih mašina ide u VLAN-ove, i od njih zavisi sve ostalo: povezanost, bezbednost itd. U ACI-u se koristi konstrukcija koju Cisco naziva EPG (End-point Group), od koje se ne može pobeći. Može li se to izjednačiti sa VLAN-om? Da, ali u tom slučaju postoji rizik da se izgubi velika većina onoga što ACI nudi.
U vezi sa EPG-om formulišu se sve pravila pristupa, a u ACI-u se po default-u koristi princip „belog spiska“, što znači da je dozvoljen samo promet čije je propuštanje eksplicitno odobreno. Drugim rečima, možemo kreirati EPG grupe „Web“ i „MySQL“ i definisati pravilo koje dozvoljava interakciju između njih samo putem porta 3306. To će funkcionisati bez obzira na mrežne adrese, čak i unutar iste podmreže!
Imamo klijente koji su odabrali ACI upravo zbog ove funkcionalnosti, jer omogućava ograničavanje pristupa između servera (bilo virtuelnih ili fizičkih — nije važno), bez premeštanja između podmreža, čime se ne dira adresacija. Da, znamo, niko ne postavlja ručno IP adrese u konfiguracijama aplikacija, zar ne?
Pravila prometa u ACI nazivaju se ugovorima. U takvom ugovoru jedna ili više grupa ili razina u višeslojnoj aplikaciji postaju pružatelji usluga (recimo, usluga baze podataka), dok su drugi potrošači. Ugovor može jednostavno proslijediti promet, ili može učiniti nešto složenije, na primjer, usmjeriti na vatrozid ili opterećenje, kao i promijeniti vrijednost QoS.
Kako serveri ulaze u te grupe? Ako su to fizički serveri ili nešto uključeno u postojeću mrežu u koju smo stvorili VLAN-trunk, tada je za njihovo stavljanje u EPG potrebno navesti port na prekidaču i korišteni VLAN. Kao što vidimo, VLAN-ovi se pojavljuju tamo gdje bez njih ne možemo.
Ako su serveri virtualne mašine, dovoljno je pozvati se na povezano okruženje virtualizacije, a dalje će se sve odvijati samo od sebe: stvorit će se portna grupa (govoreći terminima - VMWare) za povezivanje VM-a, odredit će se potrebni VLAN-ovi ili VXLAN-ovi, upisat će se na potrebne portove prekidača itd. Tako da, iako je ACI izgrađena oko fizičke mreže, povezivanje za virtualne servere izgleda znatno jednostavnije nego za fizičke. ACI već integrira vezu s VMWare i MS Hyper-V, kao i podršku za OpenStack i RedHat Virtualization. Od nekog trenutka postoji i ugrađena podrška za platforme kontejnera: Kubernetes, OpenShift, Cloud Foundry, pri čemu se to odnosi i na primjenu politika i nadzor, tj. mrežni administrator može odmah vidjeti na kojim hostovima koje podovi rade i u koje su grupe ušli.
Pored uključivanja u određenu port grupu, virtualni serveri imaju dodatna svojstva: ime, atribute itd., koje se mogu koristiti kao kriteriji za njihov prijenos u drugu grupu, recimo, pri preimenovanju VM-a ili pojavom dodatne oznake. Cisco ovo naziva mikrosegmentacijskim grupama, iako je, u velikoj mjeri, sama struktura koja omogućava stvaranje mnogo sigurnosnih segmenata u obliku EPG-a u istoj podmreži - također prilično mikrosegmentacija. Pa, vendor svakako zna.
EPG-ovi su isključivo logičke konstrukcije, koje nisu vezane za određene preklopnike, servere itd., tako da se s njima i konstrukcijama na njihovoj bazi (aplikacijama i tenantima) mogu raditi stvari koje su teške za ostvariti u običnim mrežama, poput kloniranja. Kao rezultat, lako je stvoriti klon proizvodnog okruženja kako bi se dobilo testno okruženje koje je garantirano identično proizvodu. Može se to uraditi ručno, ali je bolje (i jednostavnije) putem API-a.
Općenito, logika upravljanja u ACI-u potpuno se razlikuje od onoga s čim se obično susrećete
u tradicionalnim mrežama iste Cisco-e: programsko sučelje je primarno, dok je GUI ili CLI sekundaran, jer rade putem istog API-ja. Stoga gotovo svatko tko se bavi ACI-jem kroz neko vrijeme počinje orijentirati se u objektnoj modelu koja se koristi za upravljanje i automatizirati nešto prema svojim potrebama. Najlakše je to raditi iz Pythona: postoji mnogo korisnih gotovih alata za njega.
Obećane zamke
Glavni problem je to što su mnoge stvari u ACI-u napravljene drugačije. Da biste normalno radili s njime, treba se ponovo učiti. To se posebno odnosi na timove mrežne operacije kod velikih klijenata, gdje inženjeri godinama rade na "definiranju VLAN-ova" prema zahtjevima. Ono što je sada VLAN više nije VLAN, a za postavljanje novih mreža u virtualizirane hostove nije potrebna ručna izrada VLAN-ova, što potpuno zbunjuje tradicionalne mrežne tehničare i prisiljava ih da se drže svojih uobičajenih pristupa. Treba napomenuti da je Cisco pokušala malo olakšati situaciju dodavanjem "NXOS-sličnog" CLI-a u kontroler, što omogućuje konfiguraciju iz sučelja sličnog tradicionalnim preklopnicima. No, ipak, da biste normalno koristili ACI, morat ćete razumjeti kako to funkcionira.
S aspekta cijene, ACI mreže na velikim i srednjim razmjerima zapravo se ne razlikuju od tradicionalnih mreža na Cisco opremi, jer se za njihovu izgradnju koriste isti prekidači (Nexus 9000 mogu raditi i u ACI i u tradicionalnom režimu, postali su glavna „radna konja“ za nove projekte u DC-u). Međutim, za DC-ove, prisutnost kontrolera i Spine-Leaf arhitekture od dva prekidača naravno se osjeća. Nedavno je predstavljena Mini ACI fabrika, u kojoj su dva od tri kontrolera zamijenjena virtualnim strojevima. To smanjuje razliku u cijeni, ali ona i dalje ostaje. Dakle, izbor za kupca ovisi o tome koliko je zainteresiran za funkcije sigurnosti, integracije s virtualizacijom, jedinstvene točke upravljanja i slično.
Izvor: habr.com
