Historien om én switch

Historien om én switch
I vores lokale netværksaggregering havde vi seks par Arista DCS-7050CX3-32S switche og et par Brocade VDX 6940-36Q switche. Det er ikke, at vi var alt for anstrengte af Brocade-switcherne i dette netværk, de fungerer og udfører deres funktioner, men vi forberedte fuld automatisering af nogle handlinger, og vi havde ikke disse muligheder på disse switche. Jeg ønskede også at skifte fra 40GE interfaces til muligheden for at bruge 100GE for at lave en reserve for de næste 2-3 år. Så vi besluttede at ændre Brocade til Arista.

Disse switches er LAN-aggregationsswitche for hvert datacenter. Distributionsswitches (det andet aggregeringsniveau) er direkte forbundet til dem, som allerede samler Top-of-Rack lokale netværksswitches i racks med servere.

Historien om én switch
Hver server er forbundet til en eller to adgangsswitche. Adgangskontakter er forbundet til et par distributionsafbrydere (to distributionsafbrydere og to fysiske links fra adgangsafbryderen til forskellige distributionsafbrydere bruges til redundans).

Hver server kan bruges af sin egen klient, så klienten får tildelt et separat VLAN. Det samme VLAN registreres derefter på en anden server på denne klient i et hvilket som helst rack. Datacentret består af flere sådanne rækker (POD'er), hver række af racks har sine egne distributionskontakter. Så er disse distributionsafbrydere forbundet til aggregeringsafbrydere.

Historien om én switch
Klienter kan bestille en server i en hvilken som helst række; det er umuligt på forhånd at forudsige, at serveren vil blive allokeret eller installeret i en bestemt række i et specifikt rack, hvorfor der er omkring 2500 VLAN'er på aggregeringsswitche i hvert datacenter.

Udstyr til DCI (Data-Center Interconnect) er forbundet til aggregeringsswitche. Den kan være beregnet til L2-forbindelse (et par switche, der danner en VXLAN-tunnel til et andet datacenter) eller til L3-forbindelse (to MPLS-routere).

Historien om én switch
Som jeg allerede skrev, for at forene processerne til at automatisere konfigurationen af ​​tjenester på udstyr i et datacenter, var det nødvendigt at erstatte de centrale aggregeringsswitche. Vi installerede nye switches ved siden af ​​de eksisterende, kombinerede dem til et MLAG-par og begyndte at forberede os til arbejdet. De blev straks forbundet til eksisterende aggregeringsswitche, så de havde et fælles L2-domæne på tværs af alle klient-VLAN'er.

Kredsløbsdetaljer

For detaljer, lad os navngive de gamle aggregeringskontakter A1 и A2, ny - N1 и N2. Lad os forestille os det POD 1 и POD 4 servere for én klient hostes С1, Klient-VLAN er angivet med blåt. Denne klient bruger L2-forbindelsestjeneste med et andet datacenter, så dens VLAN føres til et par VXLAN-switche.

Kunde С2 hoster servere i POD 2 и POD 3Klient-VLAN er markeret med mørkegrøn. Denne klient bruger også en forbindelsestjeneste med et andet datacenter, men L3, så dens VLAN føres til et par L3VPN-routere.

Historien om én switch
Vi har brug for klient-VLAN'er for at forstå, på hvilke stadier af udskiftningsarbejdet, hvad der sker, hvor kommunikationsafbrydelsen opstår, og hvad dens varighed kan være. STP-protokollen bruges ikke i denne ordning, da bredden af ​​træet for den i dette tilfælde er stor, og konvergensen af ​​protokollen vokser eksponentielt med antallet af enheder og forbindelser mellem dem.

Alle enheder forbundet med dobbeltforbindelser danner en stak, MLAG-par eller VCS Ethernet-stof. For et par L3VPN-routere bruges sådanne teknologier ikke, da der ikke er behov for L2-redundans; det er nok, at de har L2-forbindelse til hinanden via aggregeringsswitches.

Implementeringsmuligheder

Da vi analyserede muligheder for yderligere arrangementer, indså vi, at der er flere måder at udføre dette arbejde på. Fra en global pause på hele det lokale netværk, til små bogstaveligt talt 1-2 sekunders pauser i dele af netværket.

Netværk, stop! Afbrydere, udskift dem!

Den nemmeste måde er selvfølgelig at erklære et globalt kommunikationsbrud på alle POD'er og alle DCI-tjenester og skifte alle links fra switchene А til kontakter N.

Historien om én switch
Bortset fra afbrydelsen, hvis tidspunkt vi ikke kan forudsige pålideligt (ja, vi kender antallet af links, men vi ved ikke, hvor mange gange noget vil gå galt - fra en knækket patchledning eller beskadiget stik til en defekt port eller transceiver ), vi kan stadig ikke forudsige på forhånd, om længden af ​​patch-ledningerne, DAC, AOC, forbundet til de gamle switche A, vil være nok til at nå dem til de nye switches N, selvom de står ved siden af ​​dem, men stadig lidt til siden, og om de samme transceivere vil fungere /DAC/AOC fra Brocade switches til Arista switches.

Og alt dette under forhold med hårdt pres fra kunder og teknisk support ("Natasha, stå op! Natasha, alt fungerer ikke der! Natasha, vi har allerede skrevet til teknisk support, ærligt talt! Natasha, de har allerede droppet alting ! Natasha, hvor mange flere har vi ikke, vil det virke? Natasha, hvornår vil det virke?!"). Selv på trods af den på forhånd annoncerede pause og meddelelse til kunderne, er en tilstrømning af anmodninger garanteret på et sådant tidspunkt.

Stop, 1-2-3-4!

Hvad hvis vi ikke erklærer en global pause, men i stedet annoncerer en række små kommunikationsafbrydelser for POD- og DCI-tjenester. I den første pause skiftes til afbrydere N kun POD 1, i den anden - om et par dage - POD 2, så et par dage mere POD 3Yderligere POD 4…[N], derefter VXLAN-switche og derefter L3VPN-routere.

Historien om én switch
Med denne organisering af skiftearbejde reducerer vi kompleksiteten af ​​engangsarbejde og øger vores tid til at løse problemer, hvis noget pludselig går galt. POD 1 forbliver forbundet til andre POD'er og DCI'er efter skift. Men selve arbejdet trækker ud i lang tid; under dette arbejde i datacentret skal en ingeniør fysisk udføre skiftet, og under arbejdet (og sådant arbejde udføres som regel om natten fra 2. til kl. 5 om morgenen), er tilstedeværelsen af ​​en online netværksingeniør påkrævet på et ret højt niveau kvalifikationer. Men så får vi korte kommunikationsafbrydelser, som regel kan arbejdet udføres i et interval på en halv time med en pause på op til 2 minutter (i praksis ofte 20-30 sekunder med udstyrets forventede opførsel).

I eksemplet klient С1 eller klient С2 du bliver nødt til at advare om arbejde med en kommunikationsafbrydelse mindst tre gange - første gang for at udføre arbejde på en POD, hvor en af ​​dens servere er placeret, anden gang - på anden og tredje gang - når koblingsudstyr til DCI-tjenester.

Skift af aggregerede kommunikationskanaler

Hvorfor taler vi om udstyrets forventede adfærd, og hvordan aggregerede kanaler kan skiftes, mens kommunikationsafbrydelser minimeres? Lad os forestille os følgende billede:

Historien om én switch
På den ene side af linket er der POD-distributionskontakter - D1 и D2, de danner et MLAG-par med hinanden (stak, VCS-fabrik, vPC-par), på den anden side er der to links - Link 1 и Link 2 - inkluderet i MLAG-parret af gamle aggregeringsafbrydere А. På kontaktsiden D en aggregeret grænseflade med navnet Port-kanal A, på siden af ​​aggregeringskontakter А - aggregeret grænseflade med navnet Port-kanal D.

Aggregerede grænseflader bruger LACP i deres drift, det vil sige, at switche på begge sider regelmæssigt udveksler LACPDU-pakker på begge links for at sikre, at linkene:

  • arbejder;
  • inkluderet i et par enheder på fjernsiden.

Ved udveksling af pakker bærer pakken værdien system-id, der angiver den enhed, hvor disse links er inkluderet. For et MLAG-par (stak, fabrik osv.) er system-id-værdien for de enheder, der udgør den aggregerede grænseflade, den samme. Kontakt D1 sender til Link 1 значение system-id D, og skift D2 sender til Link 2 значение system-id D.

Afbrydere A1 и A2 analysere LACPDU-pakker modtaget over en Po D-grænseflade og kontrollere, om system-id'et i dem matcher. Hvis system-id'et modtaget via et eller andet link pludselig afviger fra den aktuelle driftsværdi, så fjernes dette link fra den aggregerede grænseflade, indtil situationen er rettet. Nu på vores skifte side D nuværende system-id-værdi fra LACP-partneren - A, og på kontaktsiden А — nuværende system-id-værdi fra LACP-partneren — D.

Hvis vi skal skifte den aggregerede grænseflade, kan vi gøre det på to forskellige måder:

Metode 1 - Simpel
Deaktiver begge links fra switches A. I dette tilfælde virker den aggregerede kanal ikke.

Historien om én switch
Forbind begge led en efter en til switchene N, så vil LACP-driftsparametrene blive forhandlet igen, og grænsefladen vil blive dannet PoD på kontakter N og transmission af værdier på links system-id N.

Historien om én switch

Metode 2 - Minimer afbrydelse
Frakobl Link 2 fra switch A2. Samtidig er der trafik mellem А и D vil fortsat blive transmitteret blot over et af linkene, som forbliver en del af den aggregerede grænseflade.

Historien om én switch
Tilslut Link 2 til switch N2. På kontakten N den aggregerede grænseflade er allerede konfigureret Po DN, og skift N2 vil begynde at sende til LACPDU system-id N. På dette stadium kan vi allerede kontrollere, at kontakten N2 fungerer korrekt med den transceiver, der bruges til Link 2, at forbindelsesporten er gået ind i tilstanden Up, og at der ikke opstår fejl på forbindelsesporten ved transmission af LACPDU'er.

Historien om én switch
Men det faktum, at skiftet D2 til aggregeret grænseflade Po A af Link 2 modtager en system-id N-værdi, der er forskellig fra den aktuelle operativsystem-id A-værdi, tillader ikke kontakter D indtaste Link 2 del af den aggregerede grænseflade Po A. Kontakt N kan ikke komme ind Link 2 i drift, da den ikke modtager bekræftelse af funktionsdygtighed fra switchens LACP-partner D2. Den resulterende trafik er Link 2 ikke kommer igennem.

Og nu slukker vi Link 1 fra kontakt A1, og derved fratage kontakterne А и D fungerende aggregatgrænseflade. Altså på skiftesiden D den aktuelle fungerende system-id værdi for grænsefladen forsvinder Po A.

Historien om én switch
Dette tillader kontakter D и N acceptere at udveksle system-id AN på grænseflader Po A и Po DN, så trafik begynder at blive transmitteret langs forbindelsen Link 2. Pausen er i dette tilfælde i praksis op til 2 sekunder.

Historien om én switch
Og nu kan vi nemt skifte Link 1 til switch N1, gendannelse af kapaciteten og niveauet af grænsefladeredundans Po A и Po DN. Da når dette link er tilsluttet, ændres den aktuelle system-id-værdi ikke på nogen af ​​siderne, og der er ingen afbrydelse.

Historien om én switch

Yderligere links

Men skiftet kan udføres uden tilstedeværelse af en ingeniør på tidspunktet for skiftet. For at gøre dette skal vi lægge yderligere forbindelser mellem distributionskontakter på forhånd D og nye aggregeringsafbrydere N.

Historien om én switch
Vi lægger nye forbindelser mellem aggregeringsafbrydere N og distributionsafbrydere til alle POD'er. Dette kræver bestilling og lægning af yderligere patch-ledninger og installation af yderligere transceivere som i N, og i D. Vi kan gøre dette, fordi i vores switches D Hver POD har frie porte (eller vi forhåndsfrigør dem). Som et resultat er hver POD fysisk forbundet med to links til de gamle switche A og til de nye switche N.

Historien om én switch
På kontakten D to aggregerede grænseflader er blevet dannet - Po A med links Link 1 и Link 2Og Po N - med links Link N1 и Link N2. På dette trin kontrollerer vi den korrekte forbindelse af grænseflader og links, niveauerne af optiske signaler i begge ender af linkene (via DDM-information fra switchene), vi kan endda kontrollere ydelsen af ​​linket under belastning eller overvåge tilstandene af optiske signaler og transceivertemperaturer i et par dage.

Trafik sendes stadig gennem grænsefladen Po A, og grænsefladen Po N koster ingen trafik. Indstillingerne på interfaces er noget som dette:

Interface Port-channel A
Switchport mode trunk
Switchport allowed vlan C1, C2

Interface Port-channel N
Switchport mode trunk
Switchport allowed vlan none

D-switches understøtter som regel sessionsbaserede konfigurationsændringer; switch-modeller, der har denne funktionalitet, bruges. Så vi kan ændre indstillingerne for Po A- og Po N-grænseflader i ét trin:

Configure session
Interface Port-channel A
Switchport allowed vlan none
Interface Port-channel N
Switchport allowed vlan C1, C2
Commit

Så vil konfigurationsændringen ske hurtigt nok, og pausen vil i praksis ikke være mere end 5 sekunder.

Denne metode giver os mulighed for at fuldføre alt det forberedende arbejde på forhånd, udføre alle nødvendige kontroller, koordinere arbejdet med deltagerne i processen, forudsige detaljeret handlingerne til produktion af arbejde uden kreativitetsflyvninger, når "alt gik galt ,” og har en plan ved hånden for at vende tilbage til den tidligere konfiguration. Arbejdet efter denne plan udføres af en netværksingeniør uden tilstedeværelse af en datacenteringeniør på stedet, som fysisk udfører skiftet.

Hvad der også er vigtigt med denne metode til at skifte er, at alle nye links allerede er overvåget på forhånd. Fejl, medtagelse af links i enheden, indlæsning af links - alle nødvendige oplysninger er allerede i overvågningssystemet, og dette er allerede tegnet på kortene.

D-Day

POD

Vi valgte den mindst smertefulde skiftvej for klienter og den mindst tilbøjelige til at "noget gik galt" scenarier med yderligere links. Så vi skiftede alle POD'er til nye aggregeringskontakter på et par nætter.

Historien om én switch
Men det eneste, der er tilbage, er at skifte det udstyr, der leverer DCI-tjenester.

L2

I tilfælde af udstyr, der giver L2-forbindelse, var vi ikke i stand til at udføre lignende arbejde med yderligere links. Der er mindst to grunde til dette:

  • Mangel på ledige porte med den nødvendige hastighed på VXLAN-switches.
  • Manglende sessionskonfigurationsændringsfunktionalitet på VXLAN-switches.

Vi skiftede ikke links "en ad gangen" med en pause kun, mens vi blev enige om et nyt system-id-par, da vi ikke havde 100 % tiltro til, at proceduren ville forløbe korrekt, og en test i laboratoriet viste, at i Hvis "noget går galt", får vi stadig en forbindelsesafbrydelse, og det værste er ikke kun for klienter, der har L2-forbindelse med andre datacentre, men generelt for alle klienter i dette datacenter.

Vi udførte propagandaarbejde før tid på overgangen fra L2-kanaler, så antallet af klienter, der blev berørt af arbejde på VXLAN-switches, var allerede flere gange mindre end et år siden. Som et resultat besluttede vi at afbryde kommunikationen via L2-forbindelsestjenesten, forudsat at vi opretholder den normale drift af lokale netværkstjenester i ét datacenter. Derudover giver SLA'en for denne service mulighed for at udføre planlagt arbejde med afbrydelser.

L3

Hvorfor anbefalede vi, at alle skiftede til L3VPN, når de organiserede DCI-tjenester? En af grundene er muligheden for at udføre arbejde på en af ​​de routere, der leverer denne service, ved blot at reducere redundansniveauet til N+0 uden at afbryde kommunikationen.

Lad os se nærmere på serviceleveringsordningen. I denne tjeneste går L2-segmentet fra kun klientservere til L3VPN Selectel-routere. Klientnetværket afsluttes på routere.

Hver klientserver, f.eks. S2 и S3 i ovenstående diagram, har deres egne private IP-adresser - 10.0.0.2/24 på server S2 и 10.0.0.3/24 på server S3. Adresser 10.0.0.252/24 и 10.0.0.253/24 tildelt af Selectel til routere L3VPN-1 и L3VPN-2, henholdsvis. IP-adresse 10.0.0.254/24 er en VRRP VIP-adresse på Selectel-routere.

Du kan lære mere om L3VPN-tjenesten læse i vores blog.

Før skiftet så alt cirka ud som i diagrammet:

Historien om én switch
To routere L3VPN-1 и L3VPN-2 var tilsluttet den gamle aggregeringsafbryder А. Masteren for VRRP VIP-adresse 10.0.0.254 er routeren L3VPN-1. Den har en højere prioritet for denne adresse end routeren 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;
            }
        }
    }
}

S2-serveren bruger gateway 10.0.0.254 til at kommunikere med servere andre steder. Afbrydelse af L3VPN-2-routeren fra netværket (selvfølgelig, hvis den først afbrydes fra MPLS-domænet) påvirker således ikke forbindelsen til klientens servere. På dette tidspunkt er kredsløbets redundansniveau simpelthen reduceret.

Historien om én switch
Herefter kan vi sikkert tilslutte routeren igen L3VPN-2 til et par afbrydere N. Læg links, skift transceivere. Routerens logiske grænseflader, som driften af ​​klienttjenester afhænger af, er deaktiveret, indtil det er bekræftet, at alt fungerer, som det skal.

Efter at have kontrolleret links, transceivere, signalniveauer og fejlniveauer på grænsefladerne, er routeren sat i drift, men allerede forbundet til et nyt par switche.

Historien om én switch
Dernæst sænker vi VRRP-prioriteten for L3VPN-1-routeren, og VIP-adressen 10.0.0.254 flyttes til L3VPN-2-routeren. Disse arbejder udføres også uden afbrydelse af kommunikationen.

Historien om én switch
Overførsel af VIP-adresse 10.0.0.254 til routeren L3VPN-2 giver dig mulighed for at deaktivere routeren L3VPN-1 uden afbrydelse af kommunikationen for klienten og tilslut den til et nyt par aggregeringsswitche N.

Historien om én switch
Hvorvidt VRRP VIP skal returneres til L3VPN-1 routeren er et andet spørgsmål, og selvom det returneres, sker det uden at afbryde forbindelsen.

I alt

Efter alle disse trin udskiftede vi faktisk aggregeringsswitcherne i et af vores datacentre, mens vi minimerede forstyrrelser for vores kunder.

Historien om én switch
Det eneste, der er tilbage, er demontering. Demontering af gamle switche, afmontering af gamle links mellem switche A og D, afmontering af transceivere fra disse links, rettelse af overvågning, rettelse af netværksdiagrammer i dokumentation og overvågning.

Vi kan bruge switche, transceivere, patch ledninger, AOC, DAC tilbage efter omskiftning i andre projekter eller til anden lignende omstilling.

"Natasha, vi skiftede alt!"

Kilde: www.habr.com

Tilføj en kommentar