Cu ajutorul acestei piese magice de script Cisco ACI, puteți configura rapid o rețea.
Fabrica de rețea pentru centrul de date Cisco ACI există de cinci ani, dar Habré nu a spus nimic despre asta, așa că am decis să o repar puțin. Vă voi spune din propria mea experiență ce este, la ce folosește și unde are o greblă.
Ce este și de unde a venit?
Până la anunțarea ACI (Application Centric Infrastructure) în 2013, concurenții au avansat în abordările tradiționale ale rețelelor de centre de date din trei părți 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 a fost de a muta procesul de luare a deciziilor, realizat în mod tradițional de software-ul de comutare proprietar, la un controler central.
Acest controler ar avea o viziune unică asupra a tot ceea ce se întâmplă și, pe baza acesteia, ar programa hardware-ul tuturor comutatoarelor la nivelul regulilor de procesare a fluxurilor specifice.
Pe de altă parte, soluțiile de rețea suprapuse au făcut posibilă implementarea politicilor de conectivitate și securitate necesare fără nicio modificare a rețelei fizice, construind tuneluri software între gazdele virtualizate. Cel mai cunoscut exemplu al acestei abordări a fost Nicira, care până atunci fusese deja achiziționată de VMWare pentru 1,26 miliarde de dolari și a dat naștere actualului VMWare NSX. O oarecare picantitate a situației a fost adăugată de faptul că co-fondatorii Nicira au fost aceiași oameni care au stat anterior la originile OpenFlow, spunând acum că pentru a construi o fabrică de centre de date .
Și, în sfârșit, cipurile de comutare disponibile pe piața liberă (ceea ce se numește siliciu comercial) au atins un stadiu de maturitate în care au devenit o amenințare reală pentru producătorii tradiționali de comutatoare. Dacă mai devreme, fiecare furnizor a dezvoltat independent cipuri pentru comutatoarele sale, atunci, în timp, cipurile de la producători terți, în principal de la Broadcom, au început să reducă distanța cu cipurile furnizorului în ceea ce privește funcțiile și le-au depășit în ceea ce privește raportul preț/performanță. Prin urmare, mulți credeau că zilele comutărilor pe cipuri cu design propriu sunt numărate.
ACI a devenit „răspunsul asimetric” al Cisco (mai precis, compania sa Insieme, fondată de foștii săi angajați) la toate cele de mai sus.
Care este diferența cu OpenFlow?
În ceea ce privește distribuția funcțiilor, ACI este de fapt opusul OpenFlow.
În arhitectura OpenFlow, controlerul este responsabil pentru scrierea regulilor detaliate (fluxuri)
în hardware-ul tuturor comutatoarelor, adică într-o rețea mare, poate fi responsabil pentru menținerea și, cel mai important, schimbarea a zeci de milioane de înregistrări în sute de puncte din rețea, astfel încât performanța și fiabilitatea sa devin un blocaj într-un implementare mare.
ACI folosește abordarea inversă: desigur, există și un controler, dar comutatoarele primesc politici declarative de nivel înalt de la acesta, iar comutatorul însuși realizează redarea lor în detalii ale setărilor specifice din hardware. Controlerul poate fi repornit sau oprit cu totul și nimic rău nu se va întâmpla cu rețeaua, cu excepția, desigur, a lipsei de control în acest moment. Interesant este că există situații în ACI în care OpenFlow este încă folosit, dar local în gazdă pentru programarea Open vSwitch.
ACI este construit în întregime pe transportul suprapus bazat pe VXLAN, dar include transportul IP subiacent ca parte a unei singure soluții. Cisco a numit acest termen „suprapunere integrată”. Ca punct de terminare pentru suprapuneri în ACI, în cele mai multe cazuri, sunt utilizate comutatoare din fabrică (fac acest lucru la viteza conexiunii). Gazdele nu trebuie să știe nimic despre fabrică, încapsulare etc., cu toate acestea, în unele cazuri (de exemplu, pentru a conecta gazde OpenStack), traficul VXLAN le poate fi adus.
Suprapunerile sunt folosite în ACI nu numai pentru a oferi conectivitate flexibilă prin intermediul rețelei de transport, ci și pentru a transfera metainformații (este folosit, de exemplu, pentru a aplica politici de securitate).
Cipurile de la Broadcom au fost folosite anterior de Cisco în switch-urile din seria Nexus 3000. În familia Nexus 9000, lansată special pentru a suporta ACI, a fost implementat inițial un model hibrid, care s-a numit Merchant +. Comutatorul a folosit simultan atât noul cip Broadcom Trident 2, cât și un cip complementar dezvoltat de Cisco, care implementează toată magia ACI. Aparent, acest lucru a făcut posibilă accelerarea lansării produsului și reducerea prețului comutatorului la un nivel apropiat de modelele bazate pur și simplu pe Trident 2. Această abordare a fost suficientă pentru primii doi sau trei ani de livrări ACI. În acest timp, Cisco a dezvoltat și lansat următoarea generație Nexus 9000 pe propriile cipuri, cu mai multe performanțe și set de caracteristici, dar la același nivel de preț. Specificațiile externe în ceea ce privește interacțiunea în fabrică sunt complet păstrate. În același timp, umplutura internă s-a schimbat complet: ceva de genul refactorizării, dar pentru hardware.
Cum funcționează arhitectura Cisco ACI
În cel mai simplu caz, ACI este construit pe topologia rețelei Klose sau, așa cum se spune adesea, Spine-Leaf. Comutatoarele la nivelul coloanei vertebrale pot fi de la două (sau unul, dacă nu ne pasă de toleranța la erori) la șase. În consecință, cu cât sunt mai multe, cu atât este mai mare toleranța la erori (cu atât lățimea de bandă și reducerea fiabilității în caz de accident sau întreținerea unei coloane vertebrale) și performanța generală este mai mare. Toate conexiunile externe merg la comutatoare la nivel de frunză: acestea sunt servere și andocare cu rețele externe prin L2 sau L3 și conectarea controlerelor APIC. În general, cu ACI, nu numai configurația, ci și colectarea de statistici, monitorizarea defecțiunilor și așa mai departe - totul se face prin interfața controlerelor, dintre care există trei în implementări de dimensiuni standard.
Nu trebuie să vă conectați niciodată la comutatoare cu consola, chiar și pentru a porni rețeaua: controlerul însuși detectează comutatoarele și asambla o fabrică din ele, inclusiv setările tuturor protocoalelor de service, prin urmare, apropo, este foarte important să notează numerele de serie ale echipamentului care este instalat în timpul instalării, astfel încât mai târziu să nu fii nevoit să ghicești ce comutator se află în ce rack se află. Pentru depanare, dacă este necesar, vă puteți conecta la comutatoare prin SSH: acestea reproduc cu destulă atenție comenzile obișnuite Cisco show.
Pe plan intern, fabrica folosește transport IP, așa că nu există Spanning Tree și alte orori ale trecutului în ea: toate legăturile sunt implicate, iar convergența în caz de defecțiuni este foarte rapidă. Traficul din țesătură este transmis prin tuneluri bazate pe VXLAN. Mai precis, Cisco însuși numește încapsularea iVXLAN și diferă de VXLAN obișnuit prin faptul că câmpurile rezervate din antetul rețelei sunt folosite pentru a transmite informații de serviciu, în primul rând despre relația de trafic cu grupul EPG. Acest lucru vă permite să implementați regulile de interacțiune între grupuri din echipament, folosind numerele acestora în același mod în care adresele sunt utilizate în listele de acces obișnuite.
Tunelurile permit atât segmentele L2, cât și segmentele L3 (adică VRF) să fie întinse prin transportul IP intern. În acest caz, gateway-ul implicit este distribuit. Aceasta înseamnă că fiecare comutator este responsabil pentru rutarea traficului care intră în fabrică. În ceea ce privește logica traficului, ACI este similar cu o fabrică bazată pe VXLAN/EVPN.
Dacă da, care sunt diferențele? Orice altceva!
Diferența numărul unu pe care o întâlniți cu ACI este modul în care serverele sunt conectate la rețea. În rețelele tradiționale, includerea atât a serverelor fizice, cât și a mașinilor virtuale se îndreaptă către VLAN-uri, iar orice altceva dansează din ele: conectivitate, securitate etc. În ACI, este folosit un design pe care Cisco îl numește EPG (End-point Group), din care nu există nicăieri scăpare. Dacă este posibil să-l echivalăm cu VLAN? Da, dar în acest caz există șansa de a pierde cea mai mare parte din ceea ce oferă ACI.
În ceea ce privește EPG, sunt formulate toate regulile de acces, iar în ACI se folosește implicit principiul „listei albe”, adică este permis doar traficul, a cărui trecere este permisă în mod explicit. Adică putem crea grupurile EPG „Web” și „MySQL” și definim o regulă care să permită comunicarea între ele doar pe portul 3306. Acesta va funcționa fără a fi legat de adresele de rețea și chiar în cadrul aceleiași subrețele!
Avem clienți care au ales ACI tocmai din cauza acestei caracteristici, deoarece vă permite să restricționați accesul între servere (virtuale sau fizice - nu contează) fără a le trage între subrețele, ceea ce înseamnă fără a atinge adresarea. Da, da, știm că nimeni nu prescrie manual adrese IP în configurațiile aplicațiilor, nu?
Regulile de trafic din ACI se numesc contracte. Într-un astfel de contract, unul sau mai multe grupuri sau niveluri dintr-o aplicație cu mai multe niveluri devin furnizor de servicii (să zicem, un serviciu de bază de date), alții devin consumatori. Contractul poate pur și simplu să treacă traficul sau poate face ceva mai complicat, de exemplu, să îl direcționeze către un firewall sau un echilibrator și, de asemenea, să modifice valoarea QoS.
Cum intră serverele în aceste grupuri? Dacă acestea sunt servere fizice sau ceva inclus într-o rețea existentă în care am creat un trunk VLAN, atunci pentru a le plasa în EPG, va trebui să indicați portul de comutare și VLAN-ul utilizat pe acesta. După cum puteți vedea, VLAN-urile apar acolo unde nu puteți face fără ele.
Dacă serverele sunt mașini virtuale, atunci este suficient să facem referire la mediul de virtualizare conectat și atunci totul se va întâmpla de la sine: va fi creat un grup de porturi (în ceea ce privește VMWare) pentru a conecta VM-ul, VLAN-urile sau VXLAN-urile necesare fi alocate, acestea vor fi înregistrate pe porturile de comutare necesare etc. Deci, deși ACI este construit în jurul unei rețele fizice, conexiunile pentru serverele virtuale par mult mai simple decât pentru cele fizice. ACI are deja conectivitate încorporată cu VMWare și MS Hyper-V, precum și suport pentru OpenStack și RedHat Virtualization. De la un moment dat, a apărut și suportul încorporat pentru platformele container: Kubernetes, OpenShift, Cloud Foundry, în timp ce se referă atât la aplicarea politicilor, cât și la monitorizare, adică administratorul de rețea poate vedea imediat ce gazde pe care pod-uri funcționează și în care grupuri se încadrează.
Pe lângă faptul că sunt incluse î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, atunci când o VM este redenumită sau apare o etichetă suplimentară în aceasta. Cisco numește acest lucru grupuri de micro-segmentare, deși, în mare, designul în sine, cu capacitatea de a crea multe segmente de securitate sub formă de EPG-uri pe aceeași subrețea, este, de asemenea, o micro-segmentare. Ei bine, vânzătorul știe mai bine.
EPG-urile în sine sunt constructe pur logice, care nu sunt legate de anumite switch-uri, servere etc., așa că puteți face lucruri cu ele și constructii bazate pe ele (aplicații și chiriași) care sunt greu de realizat în rețelele obișnuite, cum ar fi clonarea. Ca rezultat, să presupunem că este foarte ușor să clonezi un mediu de producție pentru a obține un mediu de testare care este garantat a fi identic cu mediul de producție. O poți face manual, dar este mai bine (și mai ușor) prin intermediul API-ului.
În general, logica de control în ACI nu este deloc asemănătoare cu ceea ce întâlniți de obicei
în rețelele tradiționale din același Cisco: interfața software este primară, iar GUI sau CLI sunt secundare, deoarece funcționează prin același API. Prin urmare, aproape toți cei implicați în ACI, după un timp, încep să navigheze prin modelul obiect utilizat pentru management și să automatizeze ceva pentru a se potrivi nevoilor lor. Cel mai simplu mod de a face acest lucru este din Python: există instrumente convenabile gata făcute pentru aceasta.
Grebla promisă
Problema principală este că multe lucruri în ACI sunt făcute diferit. Pentru a începe să lucrați cu el în mod normal, trebuie să vă recalificați. Acest lucru este valabil mai ales pentru echipele de operațiuni de rețea din clienții mari, unde inginerii „prescriu VLAN-uri” de ani de zile la cerere. Faptul că acum VLAN-urile nu mai sunt VLAN-uri și că nu trebuie să creați VLAN-uri manual pentru a pune rețele noi în gazde virtualizate, zdrobește complet acoperișul celor tradiționali de rețele și îi face să se agațe de abordări familiare. Trebuie remarcat faptul că Cisco a încercat să îndulcească puțin pilula și a adăugat un CLI „NXOS-like” la controler, care vă permite să faceți configurarea dintr-o interfață similară cu comutatoarele tradiționale. Dar totuși, pentru a începe să utilizați ACI în mod normal, trebuie să înțelegeți cum funcționează.
În ceea ce privește prețul, la scară mare și medie, rețelele ACI nu diferă de fapt de rețelele tradiționale de pe echipamentele Cisco, deoarece aceleași switch-uri sunt folosite pentru a le construi (Nexus 9000 poate funcționa în ACI și în modul tradițional și au devenit acum principalul „cal de bătaie” pentru noi proiecte de centre de date). Dar pentru centrele de date cu două comutatoare, prezența controlerelor și arhitectura Spine-Leaf, desigur, se fac simțite. Recent, a apărut o fabrică Mini ACI, în care două dintre cele trei controlere sunt înlocuite cu mașini virtuale. Acest lucru reduce diferența de cost, dar rămâne. Deci, pentru client, alegerea este dictată de cât de mult este interesat de caracteristicile de securitate, integrarea cu virtualizarea, un singur punct de control și așa mai departe.
Sursa: www.habr.com