Povestea unei comutări

Povestea unei comutări
În agregarea rețelei locale aveam șase perechi de switch-uri Arista DCS-7050CX3-32S și o pereche de switch-uri Brocade VDX 6940-36Q. Nu că switch-urile Brocade ne-ar fi dat mari bătaie de cap în această rețea, ele funcționează și își îndeplinesc rolul, dar pregăteam o automatizare completă a unor acțiuni, iar aceste funcționalități nu le aveam pe aceste switch-uri. De asemenea, ne-am dorit să trecem de la interfețele de 40GE la posibilitatea de a folosi 100GE, pentru a avea un rezervor pentru următorii 2-3 ani. Așa că am decis să înlocuim Brocade cu Arista.

Aceste switch-uri sunt switch-uri de agregare a rețelei locale pentru fiecare centru de date. Ele sunt conectate direct la switch-urile de distribuție (al doilea nivel de agregare), care deja colectează switch-urile Top-of-Rack din rackurile cu servere.

Povestea unei comutări
Fiecare server este conectat la unul sau două switch-uri de acces. Switch-urile de acces sunt conectate la o pereche de switch-uri de distribuție (două switch-uri de distribuție și două linii fizice de la switch-ul de acces la diferite switch-uri de distribuție sunt folosite pentru redundanță).

Fiecare server poate fi utilizat de clientul său, astfel încât clientului îi este alocat un VLAN dedicat. Acest VLAN este apoi configurat pe un alt server al acestui client din orice rack. Centrul de date este format din mai multe astfel de rânduri (POD-uri), pentru fiecare rând de rackuri există propriile switch-uri de distribuție. Apoi, aceste switch-uri de distribuție sunt conectate la switch-urile de agregare.

Povestea unei comutări
Clienții pot comanda un server în orice rând, nu se poate prezice din timp că serverul va fi alocat sau instalat într-un anumit rând în vreun rack specific, de aceea pe switch-urile de agregare există aproximativ 2500 de VLAN-uri în fiecare centru de date.

Echipamentele pentru DCI (Interconectarea Centrelor de Date) sunt conectate la switch-urile de agregare. Acestea pot fi destinate pentru conectivitate L2 (o pereche de switch-uri care formează un tunel VXLAN către un alt centru de date) sau pentru conectivitate L3 (două rutere MPLS).

Povestea unei comutări
Așa cum am scris anterior, pentru unificarea proceselor de automatizare a configurării serviciilor pe echipamente într-un singur centru de date, a fost necesară înlocuirea comutatoarelor centrale de agregare. Am instalat noi comutatoare lângă cele existente, le-am unit într-o pereche MLAG și am început pregătirile pentru lucrări. Le-am conectat imediat la comutatoarele de agregare existente, astfel încât au avut un domeniu L2 comun pentru toate VLAN-urile clienților.

Detalii schemă

Pentru detalii, să numim vechile comutatoare de agregare A1 și A2, cele noi — N1 și N2. Să presupunem că în POD 1 și POD 4 sunt găzduite serverele unui client C1, VLAN-ul clientului este marcat cu culoarea albastră. Acest client folosește serviciul de conectivitate L2 cu un alt centru de date, așa că VLAN-ul său este conectat la o pereche de comutatoare VXLAN.

Clientului C2 găzduiește servere în POD 2 și POD 3, VLAN-ul clientului este marcat cu culoarea verde închis. Acest client folosește, de asemenea, un serviciu de conectivitate cu un alt centru de date, dar L3, așa că VLAN-ul său este conectat la o pereche de routere L3VPN.

Povestea unei comutări
VLAN-urile clienților ne sunt necesare pentru a înțelege în ce etape ale lucrărilor de înlocuire se întâmplă ceva, unde apare întreruperea conexiunii și care poate fi durata acesteia. Protocolul STP nu este folosit în această schemă, deoarece lățimea arborelui pentru el devine mare, iar convergența protocolului crește exponențial în funcție de numărul de dispozitive și legăturile dintre ele.

Toate dispozitivele conectate prin legături duble formează un stack, o pereche MLAG sau o fabrică Ethernet VCS. Pentru perechea de routere L3VPN, astfel de tehnologii nu sunt utilizate, deoarece nu este necesar un rezervare L2, fiind suficient să existe conectivitate L2 între ele prin comutatoarele de agregare.

Opțiuni de implementare

În analiza opțiunilor pentru evenimentele viitoare, am realizat că există mai multe modalități de a desfășura aceste lucrări. De la a opri întreaga rețea locală, până la mici întreruperi de doar 1-2 secunde în părțile rețelei.

Rețea, stați! Comutatoarele, schimbați-vă!

Cel mai simplu mod este, desigur, să anunțăm o întrerupere globală a conexiunii în toate POD-urile și pentru toate serviciile DCI și să comutăm toate legăturile din comutatoare Un în comutatoare N.

Povestea unei comutări
Pe lângă o întrerupere a cărei durată nu o putem prezice garantat (da, știm numărul de linkuri, dar nu știm de câte ori vor exista probleme — de la un cablu de patch rupt sau un conector deteriorat la o defecțiune a portului sau transceiver-ului), nu putem anticipa dinainte dacă lungimea cablurilor de patch, DAC, AOC conectate la vechile comutatoare A va fi suficientă pentru a le conecta la noile comutatoare N, care sunt aproape, dar totuși puțin mai departe, și dacă aceleași transceivere/DAC/AOC din comutatoarele Brocade vor funcționa în comutatoarele Arista.

Și toate acestea în condiții de presiune puternică din partea clienților și a suportului tehnic ("Natasha, trezește-te! Natasha, nu funcționează nimic! Natasha, deja am scris la suportul tehnic, foarte serios! Natasha, deja am căzut totul! Natasha, cât timp nu va mai funcționa? Natasha, când va începe să funcționeze?!"). Chiar și cu o întrerupere anunțată din timp și notificarea făcută clienților, o avalanșă de cereri în acele momente este garantată.

Stai, 1-2-3-4!

Și dacă nu anunțăm o întrerupere globală, ci anunțăm o serie de mici întreruperi de conexiune pe POD și serviciile DCI. În prima întrerupere, să comutăm în comutatoare N doar POD 1, în a doua — peste câteva zile — POD 2, apoi din nou peste câteva zile POD 3, mai departe POD 4…[N], apoi comutatoarele VXLAN și apoi routerele L3VPN.

Povestea unei comutări
Prin această organizare a muncii de comutare, reduceme complexitatea lucrărilor simultane și ne oferim mai mult timp pentru a rezolva problemele, dacă ceva a mers prost. Conexiunea POD 1 după comutare cu celelalte POD și DCI nu se pierde. Dar aceste lucrări se extind pe o perioadă lungă, necesitând alocarea unui inginer în centrul de date pentru a efectua fizic comutările, iar în timpul lucrărilor (care, de regulă, se desfășoară noaptea, între 2 și 5 dimineața), este necesară prezența unui inginer de rețea online de o calificare destul de înaltă. Dar, în schimb, obținem întreruperi de conexiune scurte, de regulă, lucrările pot fi efectuate în intervale de jumătate de oră cu o întrerupere de până la 2 minute (în practică, adesea 20-30 de secunde, în funcție de comportamentul de așteptat al echipamentului).

În exemplul dat al clientului C1 sau al clientului C2 Va trebui să avertizăm despre lucrările cu întreruperea conexiunii de cel puțin trei ori — prima dată pentru efectuarea lucrărilor pe un POD, în care se află un server, a doua dată — pentru al doilea, și a treia dată — la comutarea echipamentului pentru servicii DCI.

Comutarea canalelor agregate de comunicație

De ce vorbim despre comportamentul așteptat al echipamentului și cum pot fi comutate canalele agregate cu minimizarea întreruperii conexiunii. Să ne imaginăm următoarea situație:

Povestea unei comutări
Dintr-o parte a liniei — comutatoarele de distribuție POD — D1 și D2, ele formează între ele o pereche MLAG (stivă, fabrică VCS, pereche vPC), dincolo de aceasta — două linii — Link 1 și Link 2 — sunt incluse în perechea MLAG a vechilor comutatoare de agregare Un. Pe partea comutatoarelor D a fost format un interface agregat numit Port-channel A, pe partea comutatoarelor de agregare Un — un interface agregat numit Port-channel D.

Interfețele agregate în activitatea lor folosesc LACP, adică, comutatoarele din cele două părți schimbă regulat pachete LACPDU pe ambele linii pentru a se asigura că liniile sunt:

  • funcționale;
  • incluse într-o pereche de dispozitive de la capătul îndepărtat.

La schimbul de pachete, valoarea este transmisă în pachetul system-id, care indică dispozitivul la care sunt incluse aceste linii. Pentru perechea MLAG (stivă, fabrică etc.) valoarea system-id pentru dispozitivele care formează interfața agregată este identică. Comutatorul D1 trimite în Link 1 valoarea system-id D, iar comutatorul D2 trimite în Link 2 valoarea system-id D.

Comutatoare A1 și A2 analizează pachetele LACPDU primite printr-un interface Po D și verifică potrivirea valorii system-id în acestea. Dacă valoarea system-id primită printr-o linie diferă de valoarea curentă de lucru, atunci această linie este exclusă din interfața agregată până la remedierea situației. Acum, pe partea comutatoarelor D valoarea curentă a system-id de la partenerul LACP este — A, iar pe partea comutatoarelor Un — valoarea curentă a system-id de la partenerul LACP este — D.

În cazul în care este necesară comutarea interfeței agregate, putem proceda în două moduri diferite:

Metoda 1 — Simplă
Dezactivați ambele linii din comutatoarele A.În acest caz, canalul agregat nu funcționează.

Povestea unei comutări
Activați ambele linii pe rând în comutatoare, Natunci se va reîncerca acordul parametrilor de funcționare LACP, formarea interfeței Po D pe comutatoare N și transmiterea valorii pe linii system-id N.

Povestea unei comutări

Metoda 2 — Minimizarea întreruperii
Dezactivați din comutatorul A2 linkul Link 2. În acest timp, traficul între Un și D va continua să fie transmis pur și simplu prin unul dintre linkurile care vor rămâne în cadrul interfeței agregate.

Povestea unei comutări
Conectați Link 2 la comutatorul N2. La comutatorul N a fost deja configurată o interfață agregată Po DN, iar comutatorul N2 va începe să transmită în LACPDU system-id N. În acest stadiu, putem verifica deja că comutatorul N2 funcționează corect cu transceiverul utilizat pentru Link 2, că portul de conectare a trecut în starea Up, și că nu apar erori la portul de conectare în timpul transmisiei LACPDU.

Povestea unei comutări
Dar faptul că comutatorul D2 pentru interfața agregată Po A din partea Link 2 primește valoarea system-id N, diferită de valoarea de lucru actuală system-id A, nu permite comutatorilor D să introducă Link 2 în cadrul interfeței agregate. Po AComutatorul N nu poate introduce Link 2 în funcțiune, deoarece nu primește confirmarea funcționalității de la partenerul LACP al comutatorului D2. În cele din urmă, traficul prin Link 2 nu este transmis.

Acum dezactivăm Link 1 din comutatorul A1, privând astfel comutatorii Un și D de interfața agregată funcțională. Astfel, pe partea comutatorului D se pierde valoarea actuală de lucru system-id pentru interfață Po A.

Povestea unei comutări
Acest lucru permite comutatorilor D și N să convină asupra schimbului de system-id A-N pe interfețe, Po A și Po DNastfel încât traficul începe să fie transmis prin linkul Link 2. Între timp, întreruperea în acest caz este, în practică, de până la 2 secunde.

Povestea unei comutări
Acum, putem comuta Link 1 în comutatorul N1, restabilind capacitatea și nivelul de rezervare al interfețelor Po A și Po DN. Deoarece la conectarea acestui link nu se modifică valoarea actuală system-id pe niciuna dintre părți, nu are loc nicio întrerupere.

Povestea unei comutări

Linkuri suplimentare

Dar comutarea poate fi efectuată fără prezența unui inginer în momentul comutării. Pentru aceasta, va trebui să instalăm din timp linkuri suplimentare între comutatoarele de distribuție D și noile comutatoare de agregare N.

Povestea unei comutări
Instalăm noi linkuri între comutatoarele de agregare N și comutatoarele de distribuție ale tuturor POD-urilor. Acest lucru necesită comanda și instalarea de cabluri patch suplimentare, precum și instalarea de transceivere suplimentare atât în N, cât și în D. Putem face acest lucru, deoarece avem porți libere în comutatoarele noastre D fiecare POD (sau le eliberăm din timp). În final, fiecare POD este conectat fizic prin două linii la vechii comutatoare A și la noile comutatoare N.

Povestea unei comutări
Pe comutator D sunt formate două interfețe agregate — Po A cu linii Link 1 și Link 2, și Po N — cu linii Link N1 și Link N2. În acest stadiu, verificăm corectitudinea conexiunilor interfețelor și liniilor, nivelurile semnalelor optice la ambele capete ale liniilor (prin informațiile DDM de la comutatoare), putem chiar verifica funcționarea liniei sub sarcină sau monitoriza stările semnalelor optice și temperaturile transceverelor timp de câteva zile.

Traficul continuă să fie transmis prin interfața Po A, iar interfața Po N stă fără trafic. Setările de pe interfețe sunt aproximativ așa:

Interfață Port-channel A
Mod comutator trunk
VLAN-uri permise comutator C1, C2

Interfață Port-channel N
Mod comutator trunk
VLAN-uri permise comutator none

Comutatoarele D, de obicei, suportă modificarea de sesiune a configurației, sunt utilizate modele de comutatoare care au această funcționalitate. Așa că modificările setărilor pe interfețele Po A și Po N le putem face într-o singură sesiune:

Configure session
Interfață Port-channel A
VLAN-uri permise comutator none
Interfață Port-channel N
VLAN-uri permise comutator C1, C2
Commit

Atunci, modificarea configurației va avea loc destul de repede, iar întreruperea va fi, în practică, de cel mult 5 secunde.

Această metodă ne permite să efectuăm toate pregătirile în avans, să realizăm toate verificările necesare, să coordonăm lucrările cu participanții la proces, să prognozăm detaliat acțiunile pentru realizarea lucrărilor, fără improvizații, când „totul a mers prost”, și să avem la îndemână un plan de revenire la configurația anterioară. Lucrările conform acestui plan sunt realizate de inginerul de rețea fără a necesita prezența inginerului de centru de date, care efectuează fizic comutările.

Ce este și mai important în această metodă de comutare — toate noile linii sunt deja monitorizate. Erorile, activarea liniilor în agregat, sarcinile liniilor — toate informațiile necesare sunt deja în sistemul de monitorizare, iar acestea sunt deja reprezentate pe hărți.

D-Day

POD

Am ales cea mai puțin dureroasă opțiune pentru clienți și cea mai puțin predispusă la variantele „ceva a mers prost” pentru comutări cu linii suplimentare. Astfel, în câteva nopți, am comutat toate POD-urile pe noile comutatoare de agregare.

Povestea unei comutări
Dar rămâne de comutat echipamentul care asigură serviciile DCI.

L2

În cazul echipamentelor care asigură conectivitatea L2, nu am reușit să efectuăm lucrări similare cu link-uri suplimentare. Motivele sunt cel puțin două:

  • Lipsa porturilor libere cu viteza necesară pe comutatoarele VXLAN.
  • Lipsa funcționalității de modificare a configurației pe sesiune pe comutatoarele VXLAN.

Nu am efectuat comutarea link-urilor 'câte unul' cu o întrerupere doar pentru timpul necesar acordării unei noi perechi system-id, deoarece nu am avut 100% certitudine că procedura va decurge corect, iar testul în laborator a arătat că, în cazul în care 'ceva nu merge bine', oricum avem o întrerupere de conexiune, iar ceea ce este cel mai grav - nu doar pentru clienții care au conectivitate L2 cu alte centre de date, ci, în general, pentru toți clienții acestui centru de date.

Am desfășurat din timp o campanie de trecere de la canalele L2, astfel că numărul clienților afectați de lucrările de pe comutatoarele VXLAN a fost deja de câteva ori mai mic decât acum un an. În cele din urmă, ne-am decis să suspendăm conexiunea pentru serviciul de conectivitate L2, cu condiția să menținem funcționarea normală a serviciilor de rețea locală în cadrul aceleași centre de date. De asemenea, SLA pentru acest serviciu prevede posibilitatea desfășurării lucrărilor planificate cu întrerupere.

L3

De ce am recomandat tuturor să treacă la utilizarea L3VPN pentru organizarea serviciilor DCI? Unul dintre motive este posibilitatea desfășurării lucrărilor pe unul dintre routerele care oferă acest serviciu, pur și simplu prin scăderea nivelului de redundanță la N+0, fără întrerupere a conexiunii.

Să analizăm schema de furnizare a serviciului mai îndeaproape. În acest serviciu, segmentul L2 merge de la serverele clienților doar până la routerele L3VPN Selectel. Pe routere, rețeaua clientului este terminată.

Fiecare server al unui client, de exemplu, S2 și S3 în schema prezentată, are propriile adrese private adrese IP — 10.0.0.2/24 pentru serverul S2 și 10.0.0.3/24 pentru serverul S3. Adresele 10.0.0.252/24 și 10.0.0.253/24 sunt asignate de către Selectel către routere L3VPN-1 și L3VPN-2, respectiv. Adresa IP 10.0.0.254/24 este adresa VIP VRRP pe routerele Selectel.

Mai multe detalii despre serviciul L3VPN pot fi citi în blogul nostru.

Până la momentul comutării, totul arăta aproximativ ca în schemă:

Povestea unei comutări
Două routere L3VPN-1 și L3VPN-2 erau conectate la vechiul comutator de agregare Un. Routerul L3VPN-1este master pentru adresa VIP VRRP 10.0.0.254. Acesta are un prioritate pentru această adresă mai mare decât routerul. L3VPN-2.

unit 1006 {
    description C2;
    vlan-id 1006;
    family inet {       
        address 10.0.0.252/24 {
            vrrp-group 1 {
                priority 200;
                virtual-address 10.100.0.254;
                preempt {
                    hold-time 120;
                }
                accept-data;
            }
        }
    }
}

Serverul S2 pentru conectarea cu serverele din alte locații utilizează gateway-ul 10.0.0.254. Astfel, deconectarea de la reteaua routerului L3VPN-2 (desigur, după ce acesta a fost mai întâi deconectat din domeniul MPLS) nu afectează conectivitatea serverelor clientului. În acest moment, se reduce pur și simplu nivelul de redundanță al schemei.

Povestea unei comutări
După aceasta, putem reconecta liniștit routerul L3VPN-2 la o pereche de switch-uri N. Trasați cablurile, schimbați transceiverele. Interfețele logice ale routerului, de care depind serviciile clientului, rămân dezactivate până în momentul confirmării că totul funcționează corect.

După verificarea cablurilor, transceiverele, nivelurile semnalelor, nivelurile de erori pe interfețe, routerul este activat, dar deja conectat la noua pereche de switch-uri.

Povestea unei comutări
Apoi, scădem prioritatea VRRP a routerului L3VPN-1, iar adresa VIP 10.0.0.254 se mută pe routerul L3VPN-2. Aceste lucrări se efectuează de asemenea fără a întrerupe conexiunea.

Povestea unei comutări
Mutarea adresei VIP 10.0.0.254 pe routerul L3VPN-2 permit dezactivarea routerului L3VPN-1 fără a întrerupe conexiunea pentru client și a-l conecta deja la noua pereche de switch-uri de agregare N.

Povestea unei comutări
Dacă să returnăm VIP VRRP pe routerul L3VPN-1 sau nu — aceasta este o altă întrebare, iar dacă se face, acest lucru se face fără a întrerupe conexiunea.

În concluzie

După toate aceste acțiuni, am înlocuit cu adevărat switch-urile de agregare în unul dintre centrele noastre de date, minimizând astfel întreruperile pentru clienții noștri.

Povestea unei comutări
Apoi, rămâne doar demontarea. Demontarea switch-urilor vechi, demontarea cablurilor vechi între switch-urile A și D, demontarea transceiverele de la aceste cabluri, corectarea monitorizării, corectarea schemei rețelei în documentație și monitorizare.

Switch-urile, transceiverele, cordoanele de patch, AOC, DAC rămase după comutări pot fi folosite în alte proiecte sau la alte comutări similare.

„Natasha, am terminat totul!”

Sursa: habr.com

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster