Evaluați conexiunile din partea din mijloc a diagramei. Vom reveni la ele mai jos
La un moment dat, este posibil să descoperiți că rețelele mari și complexe bazate pe L2 sunt bolnave terminal. În primul rând, problemele asociate cu procesarea traficului BUM și funcționarea protocolului STP. În al doilea rând, arhitectura este în general învechită. Acest lucru provoacă probleme neplăcute sub formă de timpi de nefuncționare și de manipulare incomodă.
Am avut două proiecte paralele, în care clienții au evaluat cu seriozitate toate avantajele și dezavantajele opțiunilor și au ales două soluții diferite de suprapunere și le-am implementat.
A existat o oportunitate de a compara implementarea. Nu exploatare, ar trebui să vorbim despre asta în doi sau trei ani.
Deci, ce este o țesătură de rețea cu rețele suprapuse și SDN?
Ce să faci cu problemele stringente ale arhitecturii clasice de rețea?
În fiecare an apar noi tehnologii și idei. În practică, nevoia urgentă de a reconstrui rețelele nu a apărut de mult timp, deoarece este posibil să faceți totul manual, folosind metodele bune de modă veche. Și dacă este secolul XXI? La urma urmei, un administrator ar trebui să lucreze și să nu stea în biroul său.
Apoi a început un boom în construcția de centre de date la scară largă. Apoi a devenit clar că limita de dezvoltare a arhitecturii clasice a fost atinsă, nu numai în ceea ce privește performanța, toleranța la erori și scalabilitatea. Iar una dintre opțiunile pentru rezolvarea acestor probleme a fost ideea de a construi rețele suprapuse pe o coloană vertebrală direcționată.
În plus, odată cu creșterea dimensiunii rețelelor, problema administrării unor astfel de fabrici a devenit acută, în urma căreia au început să apară soluții de rețea definite de software cu capacitatea de a gestiona întreaga infrastructură de rețea ca un întreg. Și atunci când rețeaua este gestionată dintr-un singur punct, este mai ușor pentru alte componente ale infrastructurii IT să interacționeze cu ea, iar astfel de procese de interacțiune sunt mai ușor de automatizat.
Aproape fiecare producător important nu numai de echipamente de rețea, ci și de virtualizare, are opțiuni pentru astfel de soluții în portofoliu.
Tot ce rămâne este să vă dați seama ce este potrivit pentru ce necesități. De exemplu, pentru companiile deosebit de mari, cu o echipă bună de dezvoltare și operare, soluțiile ambalate de la furnizori nu satisfac întotdeauna toate nevoile și recurg la dezvoltarea propriilor soluții SD (definite de software). De exemplu, aceștia sunt furnizori de cloud care își extind în mod constant gama de servicii furnizate clienților lor, iar soluțiile ambalate pur și simplu nu sunt capabile să țină pasul cu nevoile lor.
Pentru companiile mijlocii, funcționalitatea oferită de vânzător sub forma unei soluții în cutie este suficientă în 99 la sută din cazuri.
Ce sunt rețelele suprapuse?
Care este ideea din spatele rețelelor de suprapunere? În esență, luați o rețea clasică direcționată și construiți o altă rețea pe deasupra pentru a obține mai multe funcții. Cel mai adesea, vorbim despre distribuirea eficientă a sarcinii pe echipamente și linii de comunicație, creșterea semnificativă a limitei de scalabilitate, creșterea fiabilității și o grămadă de bunătăți de securitate (datorită segmentării). Iar soluțiile SDN, pe lângă aceasta, oferă oportunitatea unei administrări flexibile foarte, foarte, foarte convenabile și fac rețeaua mai transparentă pentru consumatorii săi.
În general, dacă rețelele locale ar fi fost inventate în anii 2010, ele ar fi arătat mult diferit de ceea ce am moștenit de la armată în anii 1970.
În ceea ce privește tehnologiile de construire a țesăturilor folosind rețele suprapuse, în prezent există multe implementări ale furnizorilor ș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 producători poate diferi, așa că atunci când se creează astfel de fabrici, este încă posibil să se abandoneze complet blocarea vânzătorului doar teoretic pe hârtie.
Cu o soluție SD, lucrurile sunt și mai confuze; fiecare furnizor are propria sa viziune. Există soluții complet deschise pe care, teoretic, le poți completa singur, și sunt complet închise.
Cisco oferă versiunea sa de SDN pentru centre de date - ACI. Desigur, aceasta este o soluție 100% blocată de furnizor în ceea ce privește alegerea echipamentelor de rețea, dar în același timp este complet integrată cu sistemele de virtualizare, containerizare, securitate, orchestrare, echilibrare de încărcare etc. Dar, în esență, este încă un un fel de cutie neagră, fără posibilitatea de acces complet la toate procesele interne. Nu toți clienții sunt de acord cu această opțiune, deoarece sunteți complet dependent de calitatea codului de soluție scris și de implementarea acestuia, dar, pe de altă parte, producătorul are unul dintre cele mai bune suporturi tehnice din lume și are o echipă dedicată dedicată doar la aceasta solutie. Cisco ACI a fost ales ca soluție pentru primul proiect.
Pentru al doilea proiect s-a ales o soluție Juniper. Producătorul are și propriul SDN pentru centrul de date, dar clientul a decis să nu implementeze SDN. O țesătură EVPN VXLAN fără utilizarea controlerelor centralizate a fost aleasă ca tehnologie de construcție a rețelei.
Pentru ce este
Crearea unei fabrici vă permite să construiți o rețea ușor scalabilă, tolerantă la erori și fiabilă. Arhitectura (leaf-spine) ține cont de caracteristicile centrelor de date (cai de trafic, minimizarea întârzierilor și blocajelor în rețea). Soluțiile SD din centrele de date vă permit să gestionați foarte convenabil, rapid și flexibil o astfel de fabrică și să o integrați în ecosistemul centrului de date.
Ambii clienți trebuiau să construiască centre de date redundante pentru a asigura toleranța la erori și, în plus, traficul dintre centrele de date trebuia criptat.
Primul client considera deja soluții fără fabrică ca un posibil standard pentru rețelele lor, dar în teste au avut probleme cu compatibilitatea STP între mai mulți furnizori de hardware. Au existat perioade de nefuncționare care au cauzat blocarea serviciilor. Și pentru client acest lucru a fost critic.
Cisco era deja standardul corporativ al clientului, s-au uitat la ACI și la alte opțiuni și au decis că merită să ia această soluție. Mi-a plăcut automatizarea controlului de la un buton printr-un singur controler. Serviciile sunt configurate mai rapid și gestionate mai rapid. Am decis să asigurăm criptarea traficului rulând MACSec între comutatoarele IPN și SPINE. Astfel, am reușit să evităm blocajul sub forma unui gateway cripto, să economisim pe ele și să folosim lățimea de bandă maximă.
Al doilea client a ales o soluție fără controler de la Juniper, deoarece centrul lor de date existent avea deja o mică instalare care implementează o țesătură EVPN VXLAN. Dar acolo nu a fost tolerant la erori (a fost folosit un comutator). Am decis să extindem infrastructura centrului de date principal și să construim o fabrică în centrul de date de rezervă. EVPN existent nu a fost utilizat pe deplin: încapsularea VXLAN nu a fost folosită de fapt, deoarece toate gazdele erau conectate la un comutator și toate adresele MAC și adresele gazdei /32 erau locale, gateway-ul pentru ele era același comutator, nu existau alte dispozitive , unde a fost necesar să se construiască tuneluri VXLAN. Au decis să asigure criptarea traficului folosind tehnologia IPSEC între firewall-uri (performanța firewall-ului a fost suficientă).
Au încercat și ACI, dar au decis că, din cauza blocării furnizorului, ar trebui să cumpere prea mult hardware, inclusiv înlocuirea echipamentelor noi achiziționate recent și pur și simplu nu avea sens economic. Da, țesătura Cisco se integrează cu totul, dar numai dispozitivele sale sunt posibile în cadrul țesăturii în sine.
Pe de altă parte, așa cum am spus mai devreme, nu puteți combina o țesătură EVPN VXLAN cu orice furnizor vecin, deoarece implementările protocolului sunt diferite. Este ca și cum ai încrucișa Cisco și Huawei într-o singură rețea - se pare că standardele sunt comune, dar va trebui să dansezi cu o tamburină. Deoarece aceasta este o bancă, iar testele de compatibilitate ar fi foarte lungi, am decis că este mai bine să cumpărăm de la același furnizor acum și să nu ne lăsăm prea duși de funcționalități dincolo de cele de bază.
Plan de migrare
Două centre de date bazate pe ACI:
Organizarea interacțiunii dintre centrele de date. A fost aleasă soluția Multi-Pod - fiecare centru de date este un pod. Sunt luate în considerare cerințele pentru scalarea în funcție de numărul de comutatoare și întârzierile între poduri (RTT mai mică de 50 ms). S-a decis să nu se construiască o soluție Multi-Site pentru ușurința administrării (o soluție Multi-Pod utilizează o singură interfață de management, un Multi-Site ar avea două interfețe sau ar necesita un Multi-Site Orchestrator) și, deoarece nu există o interfață geografică a fost necesară rezervarea site-urilor.
Din punctul de vedere al migrării serviciilor din rețeaua Legacy, s-a ales varianta cea mai transparentă, transferând treptat VLAN-uri corespunzătoare anumitor servicii.
Pentru migrare, a fost creat un EPG (End-point-group) corespunzător pentru fiecare VLAN din fabrică. Mai întâi, rețeaua a fost întinsă între vechea rețea și fabrică peste L2, apoi după ce toate gazdele au fost migrate, gateway-ul a fost mutat în fabrică, iar EPG-ul a interacționat cu rețeaua existentă prin L3OUT, în timp ce interacțiunea dintre L3OUT și EPG a fost descris folosind contracte. Diagrama aproximativa:
O structură eșantion a majorității politicilor de fabrică ACI este prezentată în figura de mai jos. Întreaga configurare se bazează pe politici imbricate în alte politici și așa mai departe. La început este foarte dificil să-ți dai seama, dar treptat, așa cum arată practica, administratorii de rețea se obișnuiesc cu această structură în aproximativ o lună, iar apoi încep să înțeleagă abia cât de convenabil este.
comparație
În soluția Cisco ACI, trebuie să cumpărați mai multe echipamente (comutatoare separate pentru interacțiunea Inter-Pod și controlere APIC), ceea ce o face mai scumpă. Soluția Juniper nu a necesitat achiziționarea de controlere sau accesorii; A fost posibilă utilizarea parțială a echipamentului existent al clientului.
Iată arhitectura fabrică EVPN VXLAN pentru două centre de date ale celui de-al doilea proiect:
Cu ACI obțineți o soluție gata făcută - nu este nevoie să reparați, nu este nevoie să optimizați. În timpul cunoașterii inițiale a clientului cu fabrica, nu sunt necesari dezvoltatori, nu sunt necesare persoane de sprijin pentru cod și automatizare. Este destul de ușor de utilizat; multe setări pot fi făcute prin intermediul vrăjitorului, ceea ce nu este întotdeauna un plus, mai ales pentru persoanele obișnuite cu linia de comandă. În orice caz, este nevoie de timp pentru a reconstrui creierul pe noi piste, la particularitățile setărilor prin politici și operarea cu multe politici imbricate. În plus, este foarte de dorit să existe o structură clară pentru denumirea politicilor și obiectelor. Dacă apare vreo problemă în logica controlerului, aceasta poate fi rezolvată doar prin suport tehnic.
În EVPN - consolă. Suferi sau bucură-te. O interfață familiară pentru vechea gardă. Da, există o configurație standard și ghiduri. Va trebui să fumezi mana. Modele diferite, totul este clar și detaliat.
Desigur, în ambele cazuri, la migrare, este mai bine să migrați mai întâi nu cele mai critice servicii, de exemplu mediile de testare, și abia apoi, după ce ați detectat toate erorile, treceți la producție. Și nu vă conectați vineri seara. Nu ar trebui să aveți încredere în furnizor că totul va fi în regulă, este întotdeauna mai bine să fiți în siguranță.
Plătiți mai mult pentru ACI, deși Cisco promovează în mod activ această soluție și oferă adesea reduceri bune la ea, dar economisiți la întreținere. Managementul și orice automatizare a unei fabrici EVPN fără controler necesită investiții și costuri regulate - monitorizare, automatizare, implementare de noi servicii. În același timp, lansarea inițială la ACI durează cu 30-40% mai mult. Acest lucru se întâmplă deoarece este nevoie de mai mult timp pentru a crea întregul set de profiluri și politici necesare care vor fi apoi utilizate. Dar pe măsură ce rețeaua crește, numărul de configurații necesare scade. Folosești politici, profiluri, obiecte pre-create. Puteți configura în mod flexibil segmentarea și securitatea, gestionați la nivel central contractele care sunt responsabile pentru a permite anumite interacțiuni între EPG-uri - cantitatea de muncă scade brusc.
În EVPN, trebuie să configurați fiecare dispozitiv din fabrică, probabilitatea de erori este mai mare.
În timp ce ACI a fost mai lent de implementat, EVPN a durat aproape de două ori mai mult pentru depanare. Dacă în cazul Cisco puteți apela oricând un inginer de asistență și întrebați despre rețea în ansamblu (pentru că este acoperită ca soluție), atunci de la Juniper Networks cumpărați doar hardware și asta este acoperit. Pachetele au părăsit dispozitivul? Ei bine, atunci problemele tale. Dar puteți deschide o întrebare cu privire la alegerea soluției sau a designului rețelei - și apoi vă vor sfătui să achiziționați un serviciu profesional, contra cost.
Suportul ACI este foarte cool, pentru că este separat: o echipă separată stă doar pentru asta. Există și specialiști vorbitori de limbă rusă. Ghidul este detaliat, soluțiile sunt prestabilite. Ei se uită și sfătuiesc. Ei validează rapid designul, care este adesea important. Juniper Networks face același lucru, dar mult mai lent (aveam asta, acum ar trebui să fie mai bine conform zvonurilor), ceea ce te obligă să faci totul singur acolo unde te-ar putea sfătui un inginer de soluții.
Cisco ACI acceptă integrarea cu sisteme de virtualizare și containerizare (VMware, Kubernetes, Hyper-V) și management centralizat. Disponibil cu servicii de rețea și securitate - echilibrare, firewall-uri, WAF, IPS etc... Micro-segmentare bună din cutie. În a doua soluție, integrarea cu serviciile de rețea este ușoară și este mai bine să discutați forumurile în avans cu cei care au făcut acest lucru.
Total
Pentru fiecare caz specific, este necesar să se selecteze o soluție, nu numai pe baza costului echipamentului, dar este și necesar să se ia în considerare costurile de operare ulterioare și principalele probleme cu care se confruntă în prezent clientul și ce planuri acolo sunt pentru dezvoltarea infrastructurii IT.
ACI, datorită echipamentului suplimentar, a fost mai scump, dar soluția este gata făcută fără a fi nevoie de finisare suplimentară; a doua soluție este mai complexă și costisitoare din punct de vedere al funcționării, dar mai ieftină.
Dacă doriți să discutați cât ar putea costa implementarea unei fabrici de rețea la diferiți furnizori și ce fel de arhitectură este necesară, vă puteți întâlni și discuta. Vă vom sfătui gratuit până când veți obține o schiță grosieră a arhitecturii (cu care puteți calcula bugete), elaborarea detaliată, desigur, este deja plătită.
Vladimir Klepche, rețele corporative.
Sursa: www.habr.com