Evaluați legăturile din mijlocul schemei. Ne vom întoarce la ele mai jos.
La un moment dat, este posibil să vă confruntați cu rețele mari și complexe bazate pe L2 care sunt iremediabil bolnave. În primul rând, problemele sunt legate de gestionarea traficului BUM și de funcționarea protocolului STP. În al doilea rând, arhitectura este, în general, moral învechită. Acest lucru provoacă probleme neplăcute sub formă de timp de nefuncționare și dificultăți de gestionare.
Am avut două proiecte paralele, unde clienții au evaluat realist toate avantajele și dezavantajele opțiunilor și au ales două soluții diferite de overlay, iar noi le-am implementat.
A fost posibila compararea implementării precise. Nu utilizarea, despre care ar trebui să discutăm peste doi-trei ani.
Deci, ce este o fabrică de rețea cu rețele suprapuse și SDN?
Ce să facem cu problemele acute ale arhitecturii clasice a rețelei?
În fiecare an apar tehnologii și idei noi. În practică, necesitatea urgentă de a reconstrui rețelele nu a fost simțită de mult timp, deoarece se poate lucra tot manual, folosind vechile metode tradiționale. Și ce dacă suntem în secolul XXI? În cele din urmă, administratorul trebuie să lucreze, nu să stea în birou.
Apoi a început boom-ul construcției de centre de date la scară largă. Atunci a devenit clar că s-a atins limita dezvoltării arhitecturii clasice nu doar în ceea ce privește funcționarea, fiabilitatea sau scalabilitatea. Una dintre soluțiile acestor probleme a fost ideea construirii de rețele suprapuse peste un backbone rutabil.
Pe lângă aceasta, pe măsură ce dimensiunea rețelelor a crescut, problema gestionării acestor fabrici a devenit acută, ceea ce a condus la apariția soluțiilor de rețele definite prin software care permit gestionarea întregii infrastructuri de rețea ca un întreg. Atunci când rețeaua este gestionată dintr-un singur punct, celelalte componente ale infrastructurii IT pot interacționa mai ușor cu aceasta, iar astfel de procese de interacțiune sunt mai ușor de automatizat.
Practic, fiecare mare producător nu doar de echipamente de rețea, ci și de virtualizare, are în portofoliul său opțiuni pentru astfel de soluții.
Rămâne doar să înțelegem ce se potrivește pentru diferitele nevoi. De exemplu, pentru companiile foarte mari, care dispun de o echipă bună de dezvoltatori și operare, soluțiile standard de la furnizori nu satisfac întotdeauna toate cerințele, astfel că acestea recurg la dezvoltarea propriilor soluții SD (software defined). De exemplu, aceștia sunt furnizorii de cloud care își extind constant gama de servicii oferite clienților lor, iar soluțiile standard pur și simplu nu sunt capabile să țină pasul cu nevoile lor.
Pentru companiile de dimensiuni medii, funcționalitățile oferite de furnizor sub formă de soluție standard sunt suficiente în 99% din cazuri.
Ce sunt rețelele overlay
Care este ideea rețelelor overlay. Practic, iei o rețea rutabilă clasică și construiești deasupra ei o altă rețea pentru a obține mai multe funcționalități. Cel mai adesea, se discută despre distribuția eficientă a încărcăturii pe echipamente și linii de comunicație, creșterea semnificativă a limitelor de scalabilitate, îmbunătățirea fiabilității și o mulțime de beneficii în ceea ce privește securitatea (prin segmentare). Iar soluțiile SDN, pe deasupra, oferă o administrare foarte, foarte, foarte flexibilă și fac rețeaua mai transparentă pentru utilizatorii săi.
În general, dacă rețelele locale ar fi fost inventate în anii 2010, acestea nu ar fi arătat deloc ca ceea ce ne-a fost lăsat ca moștenire de militarii din anii 1970.
Din perspectiva tehnologiilor de construire a fabricilor utilizând rețele overlay, în prezent există numeroase implementări de la furnizori și proiecte internet RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve și altele). Da, există standarde, dar implementarea acestor standarde de către diferiți furnizori poate varia, astfel încât, la crearea acestor fabrici, renunțarea completă la vendor-lock poate fi realizată teoretic doar pe hârtie.
În cazul soluției SD, lucrurile sunt și mai complicate, fiecare furnizor are propria viziune. Există soluții complet deschise, care teoretic pot fi personalizate de tine, și soluții complet închise.
Cisco oferă propria variantă de SDN pentru centrele de date - ACI. Desigur, aceasta este o soluție 100% vendor-lock din punctul de vedere al alegerii echipamentului de rețea, dar se integrează complet cu sistemele de virtualizare, containerizare, securitate, orchestrare, balance de încărcare și altele. Totuși, prin esență, este în continuare un fel de cutie neagră, fără acces complet la toate procesele interne. Nu toate companiile sunt de acord cu o astfel de variantă, deoarece ești complet dependent de calitatea codului soluției și de implementarea acesteia, dar, pe de altă parte, producătorul dispune de unul dintre cele mai bune suporturi tehnice din lume și are o echipă dedicată care se ocupă exclusiv de această soluție. Ca soluție pentru primul proiect, a fost ales tocmai Cisco ACI.
Pentru al doilea proiect a fost aleasă o soluție de la Juniper. Producătorul dispune de asemenea de propriul său SDN pentru centrele de date, dar clientul a decis să renunțe la implementarea SDN. Ca tehnologie de construcție a rețelei, a fost aleasă o fabrică EVPN VXLAN fără utilizarea controllerelor centralizate.
De ce este necesar
Crearea unei fabrici permite construirea unei rețele ușor scalabile, reziliente și fiabile. Arhitectura (leaf-spine) ține cont de particularitățile centrelor de date (căile de trecere a traficului, minimizarea întârzierilor și a bottleneck-urilor în rețea). Soluțiile SD în centrele de date permit gestionarea foarte convenabilă, rapidă și flexibilă a unei astfel de fabrici, integrând-o în ecosistemul centrului de date.
Ambele companii au avut nevoie să construiască centre de date de rezervă pentru a asigura reziliența, pe lângă aceasta, traficul între centrele de date trebuia să fie criptat.
Primul client deja lua în considerare soluții fără fabrică ca standard posibil pentru rețelele sale, dar în teste au avut probleme de compatibilitate STP între mai mulți furnizori de hardware. Au existat downtime-uri, care au dus la căderi de servicii. Iar pentru client, acest lucru a fost critic.
Cisco a fost deja standardul corporativ pentru client, s-au uitat la ACI și alte opțiuni și au decis că merită să opteze pentru această soluție. Le-a plăcut automatizarea gestionării cu un singur buton printr-un controler unic. Serviciile se configurează mai repede, se gestionează mai repede. Au decis să asigure criptarea traficului prin activarea MACSec între comutatoarele IPN și SPINE. Astfel, au reușit să evite sfoara de restricție a criptografului, să economisească pe acestea și să folosească la maximum lățimea de bandă.
Al doilea client a ales o soluție fără controler de la Juniper, deoarece în datacenterul lor existent aveau deja o mică instalare cu implementarea fabricii EVPN VXLAN. Dar acolo nu era rezistentă la defecte (era utilizat un singur comutator). Au decis să extindă infrastructura datacenterului principal și să construiască o fabrică în datacenterul de rezervă. EVPN existent nu era folosit pe deplin: encapsularea VXLAN nu era practic aplicată, deoarece toate gazdele erau conectate la un singur comutator, iar toate adresele MAC și /32 ale gazdelor erau locale, iar comutatorul era și gateway-ul pentru acestea, nu existau alte dispozitive unde era necesar să se construiască tuneluri VXLAN. Au decis să asigure criptarea traficului folosind tehnologia IPSEC între firewall-uri (performanțele MSE erau suficiente).
De asemenea, au evaluat ACI, dar au decis că din cauza vendor-lock-ului vor trebui să cumpere prea mult hardware, inclusiv să înlocuiească echipamente noi recent achiziționate, iar acest lucru pur și simplu nu are sens economic. Da, fabrica Cisco se integrează cu totul, dar în interiorul propriei fabrici sunt posibile doar aparatele acesteia.
Pe de altă parte, așa cum s-a spus anterior, nu poți amesteca o fabrică EVPN VXLAN cu orice vendor vecin pur și simplu, pentru că implementările protocolului diferă. Este ca și cum ai combina Cisco cu Huawei într-o rețea — pare că standardele sunt comune, dar va trebui să dansezi cu tamburina. Deoarece este o bancă, iar testele de compatibilitate ar fi foarte lungi, au decis că mai bine să cumpere același vendor acum, și să nu se preocupe prea mult de funcționalitatea dincolo de bază.
Planul de migrație
Două datacentere pe baza ACI:
Organizarea interacțiunii între centrele de date. A fost alesă soluția Multi-Pod — fiecare centru de date este un pod. Au fost luate în considerare cerințele de scalabilitate referitoare la numărul de comutatoare și la întârzierile dintre poduri (RTT sub 50 ms). S-a decis să nu se construiască o soluție Multi-Site pentru a facilita gestionarea (pentru soluția Multi-Pod se folosește o interfață unică de management, în vreme ce pentru Multi-Site ar fi fost necesare două interfețe sau ar fi fost necesar un orchestrator Multi-Site), și deoarece nu era necesară reziliența geografică a locațiilor.
Din perspectiva migrației serviciilor din rețeaua Legacy, s-a ales cea mai transparentă variantă, aceea de a muta treptat VLAN-urile corespunzătoare anumitor servicii.
Pentru migrare, fiecare VLAN avea un EPG (End-point-group) corespunzător creat pe fabrică. La început, rețeaua se întindea între rețeaua veche și fabrică pe L2, apoi, după migrarea tuturor gazdelor, gateway-ul a fost mutat pe fabrică, iar interacțiunea EPG cu rețeaua existentă se realiza prin L3OUT, interacțiunea dintre L3OUT și EPG fiind descrisă utilizând contracte. Schema aproximativă:
Structura aproximativă a majorității politicilor fabricii ACI este ilustrată în imaginea de mai jos. Toată configurarea se bazează pe politici, încorporate în alte politici și așa mai departe. Inițial, este foarte greu de înțeles, dar treptat, așa cum arată practica, administratorii de rețea se obișnuiesc cu această structură în aproximativ o lună, iar apoi vine doar înțelegerea cât de convenabilă este.
Comparare
În soluția Cisco ACI este necesar să achiziționați mai mult echipament (comutatoare separate pentru interacțiunea Inter-Pod și controlere APIC), ceea ce a făcut ca aceasta să fie mai costisitoare. Soluția Juniper nu a necesitat achiziția de controlere și echipamente auxiliare; a fost posibil să se utilizeze parțial echipamentele existente ale clientului.
Iată arhitectura EVPN VXLAN a fabricii pentru două centre de date din cel de-al doilea proiect:
În ACI primești o soluție gata pregătită — nu trebuie să te complici, nu trebuie să optimizezi. În timpul întâlnirii inițiale cu clientul, nu sunt necesari dezvoltatori sau oameni de suport pentru cod și automatizare. E suficient doar să exploatezi, multe setări pot fi realizate printr-un wizard, ceea ce nu este întotdeauna un avantaj, mai ales pentru cei obișnuiți cu linia de comandă. În orice caz, este nevoie de timp pentru a-ți adapta gândirea la noile reguli, la particularitățile setărilor prin politici și la operarea cu numeroase politici înfrățite. Este foarte util, în plus, să ai o structură clară de denumire pentru politici și obiecte. Orice problemă apărută în logica de lucru a controller-ului poate fi rezolvată doar prin suport tehnic.
În EVPN — consola. Suferi sau te bucuri. O interfață familiară pentru vechea gardă. Da, există configurații tipice și ghiduri. Va trebui să rasfoiești documentația. Diverse construcții, totul este clar și detaliat.
Desigur, în ambele cazuri este mai bine să migrezi mai întâi serviciile care nu sunt critice, de exemplu, medii de testare, și abia apoi, după rezolvarea tuturor bug-urilor, să treci la producție. Și să nu configurezi vineri seara. Nu trebuie să ai încredere în furnizor că totul va fi în regulă, este întotdeauna mai bine să fii precaut.
La ACI plătești mai mult, deși în prezent Cisco promovează activ această soluție și de multe ori oferă reduceri bune pentru ea, dar economisești la întreținere. Managementul și orice automatizare a fabricii EVPN fără controller necesită investiții și costuri regulate — monitorizare, automatizare, implementare de noi servicii. Totuși, lansarea inițială la ACI se face mai lent cu 30-40%. Acest lucru se datorează faptului că durează mai mult să creezi întreaga suită de profiluri și politici necesare care vor fi folosite ulterior. Dar pe măsură ce rețeaua crește, numărul configurațiilor necesare scade. Folosești deja politici, profile și obiecte precreate. Poți ajusta flexibil segmentarea și securitatea, gestionând centralizat contractele care sunt responsabile pentru permite sau nu anumite interacțiuni între EPG, - volum de muncă scade brusc.
În EVPN trebuie să configurezi fiecare dispozitiv din fabrică, există o probabilitate mai mare de greșeală.
Dacă ACI se implementează mai lent, atunci EVPN s-a dovedit a fi aproape de două ori mai greu de configurat. În cazul Cisco, întotdeauna poți apela la un inginer de suport și întreba despre rețea în ansamblu (deoarece acest lucru este acoperit ca soluție), în timp ce la Juniper Networks cumperi doar hardware, și este doar acel hardware acoperit. Pachetele au ieșit de pe dispozitiv? Bine, acum sunt problemele tale. Dar poți deschide o întrebare despre alegerea soluției sau designul rețelei – și atunci ți se va recomanda achiziționarea unui serviciu profesional, contra cost.
Suportul ACI este foarte bun, deoarece este separat: o echipă distinctă se ocupă exclusiv de asta. Există, de asemenea, specialiști vorbitori de rusă. Ghidul este detaliat, soluțiile sunt predefinite. Se uită și oferă sfaturi. Validarea designului se face rapid, ceea ce este adesea important. Juniper Networks face același lucru, dar mult mai lent (la noi a fost așa, acum se spune că ar trebui să fie mai bine), ceea ce te obligă să faci totul pe cont propriu, acolo unde un inginer de soluții ar fi putut oferi sfaturi.
Cisco ACI suportă integrarea cu sistemele de virtualizare și containerizare (VMware, Kubernetes, Hyper-V) și gestionarea centralizată. Este compatibil cu serviciile de rețea și cele de securitate - balansare, firewall-uri, WAF, IPS și altele... Osegmentează bine din cutie. În a doua soluție, integrarea cu serviciile de rețea se face cu dificultate și este mai bine să consulți forumuri cu cei care au făcut asta.
Rezultatul
Pentru fiecare caz specific, trebuie ales un model nu doar în funcție de costul echipamentului, ci este necesar să se ia în considerare și cheltuielile viitoare pentru operare, precum și problemele principale cu care se confruntă clientul acum, și care sunt planurile pentru dezvoltarea infrastructurii IT.
ACI, datorită echipamentului suplimentar, a ieșit mai scump, dar este o soluție gata, fără a necesita ajustări, în timp ce a doua soluție este mai complicată și costisitoare din punct de vedere operațional, dar mai ieftină.
Dacă doriți să discutăm despre cât ar putea costa implementarea unei fabrici de rețea pe diferiți furnizori și ce arhitectură este necesară, putem să ne întâlnim pentru a discuta. Până la un schiț bazic al arhitecturii (cu care se pot considera bugetele) oferim sfaturi gratuit, dar detalierea acestora, desigur, va fi cu plată.
Vladimir Klepcie, rețele corporative.
Sursa: habr.com
