Astăzi vă voi spune despre cum a apărut și a fost implementată ideea creării unei noi rețele interne pentru compania noastră. Poziția conducerii este că trebuie să faci același proiect cu drepturi depline pentru tine ca și pentru client. Dacă o facem bine pentru noi înșine, putem să invităm clientul și să arătăm cât de bine funcționează și funcționează ceea ce îi oferim. Prin urmare, am abordat foarte amănunțit dezvoltarea conceptului unei noi rețele pentru biroul din Moscova, folosind întregul ciclu de producție: analiza nevoilor departamentelor → selectarea unei soluții tehnice → proiectare → implementare → testare. Deci să începem.
Selectarea unei soluții tehnice: Mutant Sanctuary
Procedura de lucru la un sistem automat complex este cel mai bine descrisă în prezent în GOST 34.601-90 „Sisteme automatizate. Etapele Creației”, așa că am lucrat conform acesteia. Și deja în etapele formării cerințelor și dezvoltării conceptului, am întâmpinat primele dificultăți. Organizațiile de diverse profiluri - bănci, companii de asigurări, dezvoltatori de software etc. - pentru sarcinile și standardele lor au nevoie de anumite tipuri de rețele, ale căror specificuri sunt clare și standardizate. Cu toate acestea, acest lucru nu va funcționa cu noi.
De ce?
Jet Infosystems este o mare companie IT diversificată. În același timp, departamentul nostru de suport intern este mic (dar mândru), asigură funcționalitatea serviciilor și sistemelor de bază. Compania conține multe divizii care îndeplinesc diferite funcții: acestea sunt mai multe echipe puternice de externalizare și dezvoltatori interni de sisteme de afaceri și securitate a informațiilor și arhitecți de sisteme de calcul - în general, oricine ar fi acesta. În consecință, sarcinile, sistemele și politicile de securitate ale acestora sunt, de asemenea, diferite. Ceea ce, așa cum era de așteptat, a creat dificultăți în procesul de analiză și standardizare a nevoilor.
Iată, de exemplu, departamentul de dezvoltare: angajații săi scriu și testează cod pentru un număr mare de clienți. Adesea este nevoie să se organizeze rapid mediile de testare și, sincer vorbind, nu este întotdeauna posibil să se formuleze cerințe pentru fiecare proiect, să se solicite resurse și să se construiască un mediu de testare separat în conformitate cu toate reglementările interne. Acest lucru dă naștere unor situații curioase: într-o zi, umilul tău servitor s-a uitat în camera dezvoltatorilor și a găsit sub masă un cluster Hadoop de 20 de desktop-uri funcțional corespunzător, care era conectat în mod inexplicabil la o rețea comună. Nu cred că merită să clarificăm că departamentul IT al companiei nu știa despre existența sa. Această împrejurare, la fel ca multe altele, a fost responsabilă pentru faptul că în timpul dezvoltării proiectului a luat naștere termenul de „rezervă mutantă”, descriind starea infrastructurii de birouri îndelungate.
Sau iată un alt exemplu. Periodic, în cadrul unui departament este amenajat un banc de testare. Acesta a fost cazul Jira și Confluence, care au fost folosite într-o măsură limitată de Centrul de Dezvoltare Software în unele proiecte. După ceva timp, alte departamente au aflat despre aceste resurse utile, le-au evaluat, iar la sfârșitul anului 2018, Jira și Confluence au trecut de la statutul de „jucărie a programatorilor locali” la statutul de „resurse ale companiei”. Acum, un proprietar trebuie să fie alocat acestor sisteme, SLA-uri, politici de acces/securitate a informațiilor, politici de backup, monitorizare, reguli de rutare a cererilor de remediere a problemelor trebuie definite - în general, toate atributele unui sistem informatic cu drepturi depline trebuie să fie prezente .
Fiecare dintre diviziile noastre este, de asemenea, un incubator care își dezvoltă propriile produse. Unele dintre ele mor în stadiul de dezvoltare, altele le folosim în timp ce lucrăm la proiecte, în timp ce altele prind rădăcini și devin soluții replicate pe care începem să le folosim noi înșine și să le vindem clienților. Pentru fiecare astfel de sistem, este de dorit să aibă propriul mediu de rețea, unde se va dezvolta fără a interfera cu alte sisteme și, la un moment dat, poate fi integrat în infrastructura companiei.
În plus față de dezvoltare, avem o foarte mare cu peste 500 de angajați, formați în echipe pentru fiecare client. Aceștia sunt implicați în întreținerea rețelelor și a altor sisteme, în monitorizarea de la distanță, în rezolvarea reclamațiilor și așa mai departe. Adică infrastructura SC este, de fapt, infrastructura clientului cu care lucrează în prezent. Particularitatea lucrului cu această secțiune a rețelei este că stațiile lor de lucru pentru compania noastră sunt parțial externe și parțial interne. Prin urmare, pentru SC am implementat următoarea abordare - compania asigură departamentului corespunzător rețea și alte resurse, considerând stațiile de lucru ale acestor departamente ca conexiuni externe (prin analogie cu sucursalele și utilizatorii la distanță).
Proiectarea autostrăzii: noi suntem operatorul (surpriză)
După ce am evaluat toate capcanele, ne-am dat seama că obținem o rețea a unui operator de telecomunicații într-un singur birou și am început să acționăm în consecință.
Am creat o rețea de bază cu ajutorul căreia oricărui consumator intern, și în viitor și extern, i se asigură serviciul necesar: VPN L2, VPN L3 sau rutare L3 obișnuită. Unele departamente au nevoie de acces securizat la Internet, în timp ce altele au nevoie de acces curat, fără firewall, dar în același timp protejând resursele corporative și rețeaua centrală de traficul lor.
Am „încheiat un SLA” în mod informal cu fiecare divizie. În conformitate cu acesta, toate incidentele care apar trebuie eliminate într-o anumită perioadă de timp prestabilită. Cerințele companiei pentru rețeaua sa s-au dovedit a fi stricte. Timpul maxim de răspuns la un incident în cazul erorilor de telefon și e-mail a fost de 5 minute. Timpul de restabilire a funcționalității rețelei în timpul defecțiunilor tipice nu este mai mare de un minut.
Deoarece avem o rețea de calitate operator, vă puteți conecta la ea numai în strictă conformitate cu regulile. Unitățile de servicii stabilesc politici și oferă servicii. Nici măcar nu au nevoie de informații despre conexiunile anumitor servere, mașini virtuale și stații de lucru. Dar, în același timp, sunt necesare mecanisme de protecție, deoarece nici o singură conexiune nu ar trebui să dezactiveze rețeaua. Dacă o buclă este creată accidental, alți utilizatori nu ar trebui să observe acest lucru, adică este necesar un răspuns adecvat din partea rețelei. Orice operator de telecomunicații rezolvă în mod constant probleme similare, aparent complexe, în cadrul rețelei sale de bază. Oferă servicii pentru mulți clienți cu nevoi și trafic diferite. În același timp, diferiți abonați nu ar trebui să experimenteze neplăceri din cauza traficului altora.
Acasă, am rezolvat această problemă în felul următor: am construit o rețea backbone L3 cu redundanță completă, folosind protocolul IS-IS. O rețea suprapusă a fost construită deasupra nucleului bazată pe tehnologie /, folosind un protocol de rutare . Pentru a accelera convergența protocoalelor de rutare, a fost utilizată tehnologia BFD.
Structura rețelei
În teste, această schemă s-a dovedit a fi excelentă - atunci când orice canal sau comutator este deconectat, timpul de convergență nu este mai mare de 0.1-0.2 s, se pierd un minim de pachete (adesea niciunul), sesiunile TCP nu sunt rupte, conversațiile telefonice nu sunt întrerupte.
Strat de bază - Rutare
Strat de suprapunere - Rutare
Switch-urile Huawei CE6870 cu licențe VXLAN au fost folosite ca comutatoare de distribuție. Acest dispozitiv are un raport optim preț/calitate, permițându-vă să conectați abonații la o viteză de 10 Gbit/s și să vă conectați la backbone la viteze de 40–100 Gbit/s, în funcție de transceiver-urile utilizate.
Comutatoare Huawei CE6870
Switch-urile Huawei CE8850 au fost folosite ca comutatoare de bază. Scopul este de a transmite traficul rapid și fiabil. Nu sunt conectate dispozitive la ele cu excepția switch-urilor de distribuție, nu știu nimic despre VXLAN, așa că s-a ales un model cu 32 de porturi 40/100 Gbps, cu o licență de bază care oferă rutare L3 și suport pentru IS-IS și MP-BGP protocoale .
Cel de jos este comutatorul de bază Huawei CE8850
În etapa de proiectare, în cadrul echipei a izbucnit o discuție despre tehnologiile care ar putea fi utilizate pentru a implementa o conexiune tolerantă la erori la nodurile rețelei centrale. Biroul nostru din Moscova este situat în trei clădiri, avem 7 săli de distribuție, în fiecare dintre acestea au fost instalate două întrerupătoare de distribuție Huawei CE6870 (în mai multe săli de distribuție au fost instalate doar întrerupătoare de acces). La dezvoltarea conceptului de rețea au fost luate în considerare două opțiuni de redundanță:
- Consolidarea comutatoarelor de distribuție într-o stivă tolerantă la erori în fiecare cameră de conexiune încrucișată. Pro: simplitate și ușurință de configurare. Dezavantaje: există o probabilitate mai mare de eșec a întregii stive atunci când apar erori în firmware-ul dispozitivelor de rețea („scurgeri de memorie” și altele asemenea).
- Aplicați tehnologiile M-LAG și Anycast gateway pentru a conecta dispozitivele la comutatoarele de distribuție.
Până la urmă, ne-am hotărât pe a doua variantă. Este ceva mai dificil de configurat, dar și-a demonstrat în practică performanța și fiabilitatea ridicată.
Să luăm în considerare mai întâi conectarea dispozitivelor finale la comutatoarele de distribuție:
Cruce
Un comutator de acces, un server sau orice alt dispozitiv care necesită o conexiune tolerantă la erori este inclus în două comutatoare de distribuție. Tehnologia M-LAG oferă redundanță la nivelul legăturii de date. Se presupune că două comutatoare de distribuție apar la echipamentul conectat ca un singur dispozitiv. Redundanța și echilibrarea sarcinii sunt realizate folosind protocolul LACP.
Tehnologia gateway Anycast oferă redundanță la nivel de rețea. Un număr destul de mare de VRF-uri sunt configurate pe fiecare dintre comutatoarele de distribuție (fiecare VRF este destinat propriilor scopuri - separat pentru utilizatorii „obișnuiți”, separat pentru telefonie, separat pentru diferite medii de testare și dezvoltare etc.), și în fiecare VRF are mai multe VLAN-uri configurate. În rețeaua noastră, comutatoarele de distribuție sunt gateway-urile implicite pentru toate dispozitivele conectate la acestea. Adresele IP corespunzătoare interfețelor VLAN sunt aceleași pentru ambele switch-uri de distribuție. Traficul este direcționat prin cel mai apropiat comutator.
Acum să ne uităm la conectarea comutatoarelor de distribuție la kernel:
Toleranța la erori este furnizată la nivel de rețea folosind protocolul IS-IS. Vă rugăm să rețineți că o linie de comunicație L3 separată este prevăzută între comutatoare, la o viteză de 100G. Din punct de vedere fizic, această linie de comunicare este un cablu de Acces Direct se vede în dreapta în fotografia switch-urilor Huawei CE6870.
O alternativă ar fi organizarea unei topologii „cinstite” complet conectate în stea dublă, dar, așa cum am menționat mai sus, avem 7 camere interconectate în trei clădiri. În consecință, dacă am fi ales topologia „stea dublă”, am fi avut nevoie de exact de două ori mai multe transceiver-uri 40G „cu rază lungă”. Economiile aici sunt foarte semnificative.
Trebuie spus câteva cuvinte despre modul în care tehnologiile de gateway VXLAN și Anycast funcționează împreună. VXLAN, fără a intra în detalii, este un tunel pentru transportul cadrelor Ethernet în interiorul pachetelor UDP. Interfețele loopback ale comutatoarelor de distribuție sunt utilizate ca adresă IP de destinație a tunelului VXLAN. Fiecare conexiune încrucișată are două comutatoare cu aceleași adrese de interfață loopback, astfel încât un pachet poate ajunge la oricare dintre ele și un cadru Ethernet poate fi extras din acesta.
Dacă comutatorul știe despre adresa MAC de destinație a cadrului preluat, cadrul va fi livrat corect la destinație. Pentru a se asigura că ambele comutatoare de distribuție instalate în aceeași conexiune încrucișată au informații actualizate despre toate adresele MAC „care sosesc” de la comutatoarele de acces, mecanismul M-LAG este responsabil pentru sincronizarea tabelelor de adrese MAC (precum și ARP). tabele) pe ambele comutatoare perechi M-LAG.
Echilibrarea traficului se realizează datorită prezenței în rețeaua de bază a mai multor rute către interfețele loopback ale comutatoarelor de distribuție.
În loc de concluzie
După cum s-a menționat mai sus, în timpul testării și funcționării rețeaua a arătat fiabilitate ridicată (timpul de recuperare pentru defecțiuni tipice nu este mai mare de sute de milisecunde) și performanță bună - fiecare conexiune încrucișată este conectată la nucleu prin două canale de 40 Gbit/s. Switch-urile de acces din rețeaua noastră sunt stivuite și conectate la comutatoarele de distribuție prin LACP/M-LAG cu două canale de 10 Gbit/s. O stivă conține de obicei 5 comutatoare cu 48 de porturi fiecare și până la 10 stive de acces sunt conectate la distribuție în fiecare interconectare. Astfel, coloana vertebrală oferă aproximativ 30 Mbit/s per utilizator chiar și la sarcina teoretică maximă, ceea ce la momentul scrierii este suficientă pentru toate aplicațiile noastre practice.
Rețeaua vă permite să organizați fără probleme împerecherea oricăror dispozitive conectate arbitrare atât prin L2, cât și prin L3, oferind izolarea completă a traficului (care îi place serviciului de securitate a informațiilor) și a domeniilor de eroare (care îi plac echipei de operațiuni).
În partea următoare vă vom spune cum am migrat la noua rețea. Rămâneţi aproape!
Maxim Klochkov
Consultant senior al grupului de audit de rețea și proiecte complexe
Centrul de soluții de rețea
„Jet Infosystems”
Sursa: www.habr.com