Cu ajutorul acestui script magic Cisco ACI, rețeaua poate fi configurată rapid.
Fabrica de rețea pentru centrele de date Cisco ACI există deja de cinci ani, dar nu s-a spus nimic concret despre ea pe Habră, așa că am decis să rectific acest lucru. Voi povesti din experiența mea ce este, care este avantajul ei și unde sunt capcanele.
Ce este și de unde provine?
La momentul anunțului ACI (Application Centric Infrastructure) în 2013, abordările tradiționale privind rețelele de centre de date erau sub atac din trei direcții simultan.
Pe de o parte, soluțiile SDN de „prima generație” bazate pe OpenFlow promiteau să facă rețelele mai flexibile și mai ieftine în același timp. Ideea era de a muta luarea deciziilor, executată în mod tradițional de software-ul proprietar al comutatoarelor, pe un controler central.
Acest controler ar avea o viziune unificată asupra tuturor evenimentelor și, pe baza acesteia, ar programa hardware-ul tuturor switch-urilor la nivelul regulilor de procesare a fluxurilor specifice.
Pe de altă parte, soluțiile de rețea overlay ofereau posibilitatea de a realiza conectivitatea și politicile de securitate fără modificări în rețeaua fizică, construind tuneluri software între gazdele virtualizate. Cel mai cunoscut exemplu al acestui concept a fost soluția de la Nicira, care fusese deja achiziționată de VMWare pentru 1,26 miliarde dolari și a dat naștere actualului VMWare NSX. O oarecare savoare situației era că cofondatorii Nicira erau aceleași persoane care mai devreme stăteau la originea OpenFlow, acum afirmând că pentru a construi o fabrică de centre de date .
În cele din urmă, cipurile de comutare disponibile pe piața liberă (ceea ce se numește silicon de comercianți) au atins un grad de maturitate la care au devenit o amenințare reală pentru producătorii tradiționali de comutatoare. Dacă înainte fiecare furnizor își dezvolta cipurile pentru comutatoarele sale, în timp, cipurile de la producători terți, în special cele de la Broadcom, au început să reducă distanța față de cipurile furnizorilor în funcții, iar în ceea ce privește raportul preț/performanță, le-au depășit. De aceea, mulți credeau că zilele comutatoarelor cu cipuri proprii sunt numărate.
ACI a devenit un „răspuns asimetric” al Cisco (mai precis, al companiei Insieme, integrată în Cisco și fondată de foștii săi angajați) la toate cele enumerate.
Care este diferența față de OpenFlow?
Din punctul de vedere al distribuției funcțiilor, ACI este practic opusul OpenFlow.
În arhitectura OpenFlow, controlerul este responsabil pentru scrierea regulilor detaliate (fluxurilor)
în hardware-ul tuturor switch-urilor, adică într-o rețea mare, poate fi responsabil pentru menținerea și, cel mai important, modificarea zecilor de milioane de înregistrări în sute de puncte din rețea, de aceea performanța și fiabilitatea acestuia într-o implementare mare devin un factor limitativ.
În ACI se folosește o abordare inversă: există, desigur, un controler, dar switch-urile primesc de la el politici declarative de nivel înalt, iar randarea detaliilor configurațiilor specifice în hardware este efectuată de switch. Controlerul poate fi repornit sau chiar oprit, iar rețeaua nu va suferi nicio daună, cu excepția, desigur, absenței posibilității de gestionare în acel moment. Este interesant că în ACI există situații în care OpenFlow este folosit totuși, dar local în interiorul gazdei pentru programarea Open vSwitch.
ACI este construită complet pe transportul overlay bazat pe VXLAN, dar include, de asemenea, în cadrul unei soluții unice și transportul IP de bază. Cisco a denumit acest lucru termenul „overlay integrat”. Ca punct de terminare a overlay-urilor în ACI, în majoritatea cazurilor se folosesc switch-uri de fabrică (leagă acest lucru la viteza canalului). Gazdele nu trebuie să știe nimic despre fabrică, encapsulare etc., dar în anumite cazuri (de exemplu, pentru conectarea gazdelor OpenStack) traficul VXLAN poate fi condus și către ele.
Overlay-urile sunt utilizate în ACI nu doar pentru a asigura conectivitate flexibilă prin rețeaua de transport, ci și pentru a transmite metainformații (care sunt folosite, de exemplu, pentru aplicarea politicilor de securitate).
Chipurile de la Broadcom au fost folosite anterior de Cisco în switch-urile din seria Nexus 3000. În familia Nexus 9000, creată special pentru a suporta ACI, a fost implementat inițial un model hibrid numit Merchant+. În switch a fost folosit atât noul chip Broadcom Trident 2, cât și un chip complementar dezvoltat de Cisco, care realiza toată magia ACI. Se pare că acest lucru a permis accelerarea lansării produsului și reducerea prețului switch-ului la un nivel apropiat de modelele care foloseau doar Trident 2. Această abordare a fost suficientă pentru primii doi-trei ani de livrări ACI. În această perioadă, Cisco a dezvoltat și a lansat pe piață următoarea generație Nexus 9000 bazată pe propriile sale cipuri, cu o performanță mai mare și un set mai bogat de funcții, dar la același nivel de preț. Specificațiile externe din perspectiva interacțiunii în fabrică au rămas în totalitate neschimbate. Însă, intervenția internă s-a schimbat complet: ceva asemănător cu un refactoring, dar pentru hardware.
Cum este organizată arhitectura Cisco ACI
În cel mai simplu caz, ACI este construit pe o topologie de rețea Clos, sau, cum se mai spune adesea, Spine-Leaf. Numărul de switch-uri de nivel Spine poate varia între două (sau unul, dacă nu ne interesează rezistența la defecțiuni) și șase. Cu cât sunt mai multe, cu atât rezistența la defecțiuni este mai mare (o scădere mai mică a lățimii de bandă și a fiabilității în cazul unei defecțiuni sau service a unui Spine) și performanța globală. Toate conexiunile externe se efectuează prin switch-uri de nivel Leaf: acestea includ servere, conectarea la rețele externe prin L2 sau L3 și conectarea controlerilor APIC. În general, cu ACI nu doar configurarea, ci și colectarea statisticilor, monitorizarea defecțiunilor și altele — totul se face prin intermediul interfeței controlerelor, iar în implementările de dimensiuni obișnuite sunt trei.
La switch-uri nu este necesar să ne conectăm vreodată prin consolă, nici măcar pentru a lansa rețeaua: controlerul descoperă singur switch-urile și le adună într-o fabrică, inclusiv setările tuturor protocoalelor de serviciu, prin urmare, este foarte important să notăm, la montaj, numerele de serie ale echipamentului instalat, pentru a nu ne întreba ulterior care switch se află în care rack. Pentru depanare, la switch-uri se poate conecta prin SSH, deoarece acestea replică cu grijă comenzile obișnuite de tip show ale Cisco.
În interior, fabrica utilizează transport IP, așa că nu există Spanning Tree și alte grozăvii ale trecutului: toate linkurile sunt folosite, iar conștientizarea în cazul de eșecuri este foarte rapidă. Traficul din fabrică este transmis prin tuneluri bazate pe VXLAN. Mai precis, Cisco numește incapsularea iVXLAN, și se deosebește de VXLAN obișnuit prin faptul că câmpurile rezervate din headerul de rețea sunt utilizate pentru a transporta informații de control, în principal – despre relația traficului cu grupul EPG. Acest lucru permite implementarea regulilor de interacțiune între grupuri în hardware, utilizând numerele acestora așa cum se folosesc adresele în listele de acces obișnuite.
Tunelurile permit extinderea atât a segmentelor L2, cât și a celor L3 (adică VRF) prin transportul IP intern. În acest caz, gateway-ul implicit este distribuit. Aceasta înseamnă că fiecare switch se ocupă de rutarea traficului care intră în fabrică. În ceea ce privește logica de transmitere a traficului, ACI este similar cu o fabrică bazată pe VXLAN/EVPN.
Dacă da, atunci care sunt diferențele? În tot restul!
Diferența numărul unu, cu care te confrunți în ACI, este modul în care serverele sunt conectate în rețea. În rețelele tradiționale, conectarea atât a serverelor fizice, cât și a celor virtuale se face în VLAN-uri, iar de la acestea se deosebesc toate celelalte aspecte: conectivitatea, securitatea etc. În ACI, se utilizează o construcție pe care Cisco o numește EPG (End-point Group), de la care nu poți scăpa. Poate fi echivalent cu VLAN? Da, dar în acest caz există șansa să pierzi o mare parte din ceea ce oferă ACI.
În raport cu EPG se formulează toate regulile de acces, iar în ACI, din default, se folosește principiul „listei albe”, adică este permis doar traficul a cărui transmitere este autorizată în mod explicit. Cu alte cuvinte, putem crea grupuri EPG „Web” și „MySQL” și putem defini o regulă care permite interacțiunea dintre ele doar pe portul 3306. Aceasta va funcționa fără a depinde de adresele de rețea, chiar și în interiorul aceleași subrețele!
Avem clienți care au ales ACI tocmai din cauza acestei funcții, deoarece permite limitarea accesului între servere (virtuale sau fizice – nu contează) fără a le muta între subrețele, ceea ce înseamnă că nu afectează adresarea. Da, știm, nimeni nu scrie manual adrese IP în configurațiile aplicațiilor, nu-i așa?
Regulile de trafic în ACI se numesc contracte. Într-un astfel de contract, unul sau mai multe grupuri sau niveluri dintr-o aplicație multi-tier devin furnizori de servicii (de exemplu, un serviciu de bază de date), iar altele devin consumatori. Contractul poate pur și simplu să permită trecerea traficului, sau poate face ceva mai sofisticat, de exemplu, să direcționeze către un firewall sau un echilibrator de sarcină, precum și să schimbe valoarea QoS.
Cum ajung serverele în aceste grupuri? Dacă sunt servere fizice sau ceva integrat într-o rețea existentă, în care am creat un trunk VLAN, atunci pentru a le integra în EPG trebuie să se specifice portul comutatorului și VLAN-ul utilizat pe acesta. Observăm că VLAN-urile apar acolo unde nu se poate face fără ele.
Dacă serverele sunt mașini virtuale, este suficient să facem referire la mediul de virtualizare conectat, iar apoi totul se va întâmpla de la sine: se va crea un grup de porturi (dacă ne referim la termeni — VMWare) pentru conectarea VM-urilor, vor fi atribuite VLAN-urile sau VXLAN-urile necesare, se vor modifica pe porturile comutatoarelor necesare etc. Astfel, deși ACI este construit în jurul unei rețele fizice, conectările pentru serverele virtuale par mult mai simple decât pentru cele fizice. ACI deja include integrarea cu VMWare și MS Hyper-V, precum și suport pentru OpenStack și RedHat Virtualization. De ceva vreme, există și suport încorporat pentru platformele de containere: Kubernetes, OpenShift, Cloud Foundry, iar acest lucru se referă atât la aplicarea politicilor, cât și la monitorizare, adică administratorul de rețea poate vedea imediat pe ce gazde funcționează ce poduri și în ce grupuri s-au inclus.
Pe lângă includerea într-un anumit grup de porturi, serverele virtuale au proprietăți suplimentare: nume, atribute etc., care pot fi folosite ca criterii pentru transferul lor într-un alt grup, de exemplu, în cazul redenumirii VM-ului sau apariției unei etichete suplimentare. Cisco numește aceste grupuri microsegmentate, deși, în esență, însăși construcția care permite crearea a mai multor segmente de securitate sub formă de EPG în aceeași subrețea este, de asemenea, o formă de microsegmentare. Dar, desigur, furnizorului îi revine să decidă.
EPG-urile sunt structuri pur logice, nelegate de switch-uri specifice, servere etc., astfel încât cu ele și cu structurile bazate pe ele (aplicații și chiriași) se pot realiza lucruri care sunt greu de realizat în rețelele obișnuite, de exemplu, clonarea. Ca urmare, este foarte ușor să creezi o clonă a unui mediu de producție pentru a obține un mediu de testare, garantat identic cu cel de producție. Poate fi realizat manual, dar este mai bine (și mai simplu) prin API.
În general, logica de gestionare în ACI este complet diferită de ceea ce întâlnești de obicei
în rețelele tradiționale de la Cisco: interfața programatică este primară, iar GUI sau CLI sunt secundare, deoarece funcționează prin aceeași API. Prin urmare, aproape toți cei care se ocupă de ACI încep să se familiarizeze cu modelul de obiecte utilizat pentru gestionare și să automatizeze anumite lucruri în funcție de nevoile lor. Cel mai simplu este să faci acest lucru din Python: există unelte convenabile deja disponibile pentru el.
Gardurile promise
Problema principală este că multe lucruri în ACI sunt realizate diferit. Pentru a începe să lucrezi normal cu ea, trebuie să îți reînvăț comportamentul. Acest lucru este deosebit de adevărat pentru echipele de operare a rețelei din clienți mari, unde inginerii au ani de zile se ocupă cu «înregistrarea VLAN-urilor» după cereri. Ceea ce acum este VLAN nu mai este VLAN, iar pentru a crea noi rețele în gazdele virtualizate, nu mai este nevoie să creezi VLAN-uri manual, ceea ce
Din punct de vedere al prețului, rețeaua ACI la scară mare și mijlocie nu se deosebește de rețelele tradiționale pe echipamente Cisco, deoarece pentru construcția lor se folosesc aceleași switch-uri (Nexus 9000 pot funcționa atât în modul ACI, cât și în cel tradițional și s-au dovedit a fi acum "caii de muncă" principali pentru noi proiecte de datacenter). Însă pentru datacentere, prezența controlerelor și arhitectura Spine-Leaf se simt cu siguranță când se utilizează două switch-uri. Recent a apărut Mini ACI-fabrica, în care două dintre cele trei controlere au fost înlocuite cu mașini virtuale. Aceasta permite reducerea diferenței de cost, dar ea rămâne totuși. Așadar, pentru clienți, alegerea este dictată de nivelul de interes în funcțiile de securitate, integrarea cu virtualizarea, punctul unic de gestionare și alte aspecte.
Sursa: habr.com
