Vi havde seks par Arista DCS-7050CX3-32S switches i vores lokale netværksaggregation og et par Brocade VDX 6940-36Q switches. Det var ikke, fordi Brocade switches gav os store problemer i dette netværk, de fungerer, og de opfylder deres funktioner, men vi forberedte en fuld automatisering af nogle handlinger, og disse muligheder havde vi ikke på disse switches. Vi ønskede også at gå fra 40GE-interfaces til at kunne bruge 100GE, for at gøre plads til de næste 2-3 år. Så vi besluttede at skifte Brocade ud med Arista.
Disse switches fungerer som aggregation switches for hver datacenter. De tilsluttes direkte til distributionsswitchene (andet niveau af aggregation), som allerede samler Top-of-Rack switches i serverrackene.
Hver server er tilsluttet en eller to adgangsswitches. Adgangsswitchene er tilsluttet et par distributionsswitches (to distributionsswitches og to fysiske links fra adgangsswitch til forskellige distributionsswitches bruges til redundans).
Hver server kan bruges af sin klient, så der tildeles en separat VLAN til klienten. Denne VLAN bliver derefter konfigureret på en anden server for denne klient i enhver rack. Datacenteret består af flere sådanne rækker (POD'er), hvor hver række har sine egne distributionsswitches. Disse distributionsswitches tilsluttes derefter til aggregation switches.
Klienterne kan bestille en server i enhver række, det er ikke muligt at forudsige, at serveren vil blive tildelt eller installeret i en bestemt række i et bestemt rack, derfor er der omkring 2500 VLAN til stede på aggregation switches i hvert datacenter.
Udstyret til DCI (Data-Center Interconnect) tilsluttes aggregation switches. Det kan være beregnet til L2-forbindelse (et par switches, der danner VXLAN-tunnel til et andet datacenter), såvel som til L3-forbindelse (to MPLS-routere).
Som jeg tidligere har nævnt, krævede det for at ensarte automatiseringsprocesserne for konfigurationen af tjenester på udstyret i et enkelt datacenter at udskifte de centrale aggregationsswitches. Vi installerede nye switches ved siden af de eksisterende, sammenkoblede dem i et MLAG-par og begyndte at forberede arbejdet. De blev straks forbundet med de eksisterende aggregationsswitches, så de nu havde et fælles L2-domæne på tværs af alle kundevlaner.
Detaljer om diagrammet
For konkrethedens skyld vil vi kalde de gamle aggregationsswitches A1 og A2, de nye — N1 og N2. Lad os forestille os, at i POD 1 og POD 4 er serverne placeret for en kunde C1, kundevlanen er markeret med blåt. Denne kunde bruger en L2-forbindelsestjeneste til et andet datacenter, så hans VLAN er forbundet til et par VXLAN-switches.
Kunde C2 har servere placeret i POD 2 og POD 3, kundevlanen er markeret med mørkegrøn farve. Denne kunde bruger også en forbindelsestjeneste til et andet datacenter, men L3, så hans VLAN er forbundet til et par L3VPN-rutere.
Kundevlaner er nødvendige for at forstå, på hvilke stadier af arbejdet med udskiftning, hvad der sker, hvor forbindelsen brydes, og hvad varigheden af denne pause kan være. STP-protokollen anvendes ikke i dette diagram, da bredden af træet i sådanne tilfælde bliver stor, og konvergensen af protokollen stiger geometrisk med antallet af enheder og forbindelser imellem dem.
Alle enheder, der er forbundet med dobbelte forbindelser, danner et stack, et MLAG-par eller en VCS-Ethernet-fabrik. For et par L3VPN-rutere anvendes sådanne teknologier ikke, da der ikke er behov for L2-redundans; det er tilstrækkeligt, at de har L2-forbindelse indbyrdes via aggregationsswitches.
Implementeringsmuligheder
Ved analysen af mulighederne for fremtidige hændelser forstod vi, at der er flere måder at udføre disse arbejder på. Fra en global afbrydelse af hele det lokale netværk til små, bogstaveligt talt 1-2 sekunders afbrydelser i dele af netværket.
Netværk, stop! Switches, skift ud!
Den nemmeste måde er selvfølgelig at erklære en global afbrydelse af forbindelsen på tværs af alle POD'er og alle DCI-tjenester og skifte alle links fra switches A til switches N.
Udover pausen, som vi ikke kan forudsige med sikkerhed (ja, vi kender antallet af links, men vi ved ikke, hvor mange gange noget vil gå galt — fra en brudt patchkabel eller beskadiget connector til en defekt port eller transceiver), kan vi heller ikke på forhånd forudsige, om længden af patchkablerne, DAC, AOC, der er tilsluttet de gamle switcher A, er tilstrækkelige til at nå til de nye switcher N, der står lige ved siden af, men stadig lidt væk, og om de samme transceivere/DAC/AOC fra Brocade-switcher vil fungere i Arista-switcher.
Og alt dette under hårdt pres fra kunder og support («Natasha, kom op! Natasha, alt fungerer ikke! Natasha, vi har allerede skrevet til support, ærligt, ærligt! Natasha, alt er allerede faldet ned! Natasha, hvor lang tid vil det være nede? Natasha, hvornår virker det igen?!»). Selvom der var meldt ud om den planlagte pause og varslet kunderne, er der altid et stort antal henvendelser i denne periode.
Stop, 1-2-3-4!
Og hvis man ikke annoncerer en global pause, men annoncerer en serie af små pauser i forbindelse med POD og DCI tjenester. I den første pause skifter man over til switcherne N kun POD 1, i den anden — om et par dage — POD 2, derefter om et par dage POD 3, så POD 4…[N], så VXLAN-switcher og derefter L3VPN-routere.
Med denne organisering af omkoblingsarbejdet reducerer vi kompleksiteten af samtidige opgaver og giver os selv mere tid til at løse problemer, hvis noget skulle gå galt. Forbindelsen mellem POD 1 og de andre POD og DCI går ikke tabt efter omkoblingen. Men arbejdet trækker ud over længere tid, og under denne periode kræves der en ingeniør i datacenteret til at udføre fysiske omkoblinger, og under arbejdet (som regel udføres om natten mellem 2 og 5 om morgenen) kræves der en online netværksingeniør med en høj kompetence. Men til gengæld får vi korte forbindelsespauser, arbejdet kan typisk udføres inden for et halvt time med en pause på op til 2 minutter (i praksis er det ofte 20-30 sekunder med det forventede udstyr).
I det givne eksempel for kunden C1 eller kunden C2 Vi skal advare om arbejdet med forbindelsesafbrydelse mindst tre gange — første gang for at udføre arbejdet på en POD, der indeholder en af dens servere, anden gang — for den anden, og tredje gang — ved skift af udstyr til DCI-services.
Skift af aggregerede kommunikationskanaler
Hvorfor vi taler om det forventede udstyr i drift, og hvordan aggregerede kanaler kan skifte med en minimumsforbindelseafbrydelse. Forestil dig følgende billede:
På den ene side af linket — POD-distributionsswitche — D1 og D2, de danner et MLAG-par (stak, VCS-fabrik, vPC-par), på den anden side to links — Link 1 og Link 2 — tilsluttet et MLAG-par af ældre aggregerede switche A. På switchene D er der dannet et aggregeret interface med navnet Port-channel A, på siden af de aggregerede switche A — et aggregeret interface med navnet Port-channel D.
Aggregerede interfaces anvender LACP i deres drift, hvilket betyder, at switchene på begge sider regelmæssigt udveksler LACPDU-pakker over begge links for at sikre, at links:
- er aktive;
- er tilsluttet et par enheder på den fjerne side.
Ved udveksling af pakker sendes værdien system-id, der angiver den enhed, som disse links er tilsluttet. For MLAG-paret (stakken, fabrikken osv.) er værdien af system-id for enhederne, der danner det aggregerede interface, den samme. Switche D1 sender Link 1 værdien system-id D, og switchen D2 sender Link 2 værdien system-id D.
Switchene A1 og A2 analyserer LACPDU-pakker, der modtages via et interface Po D, og kontrollerer, at system-id stemmer overens med dem. Hvis system-id, der modtages via et link, pludselig adskiller sig fra den nuværende aktive værdi, vil dette link blive fjernet fra det aggregerede interface, indtil situationen er korrigeret. Nu har vi på switchsiden D den nuværende værdi af system-id fra LACP-partneren — A, og på switchenes side A — den nuværende værdi af system-id fra LACP-partneren — D.
Ved behov for at skifte det aggregerede interface kan vi gøre det på to forskellige måder:
Metode 1 — Simpel
Afbryd begge links fra switchene A. I dette tilfælde vil det aggregerede link ikke fungere.
Tilslut begge links skiftevis til switchene N, så parametrene for LACP-workflowet genforhandles, og interfacet Po D på switchene N og overførslen af værdien på linksene. system-id N.
Metode 2 — Minimere nedetid
Afbryd fra switch A2 link Link 2. Trafikken mellem A og D vil fortsætte med at blive sendt gennem en af de links, der forbliver i den aggregerede grænseflade.
Tilslut Link 2 til switch N2. På switchen N er den aggregerede grænseflade allerede konfigureret Po DN, og switchen N2 begynder at sende i LACPDU system-id N. På dette tidspunkt kan vi allerede kontrollere, at switchen N2 fungerer korrekt med transceiveren, der bruges til Link 2, at tilslutningsporten er gået til tilstanden Op, og at der ikke opstår fejl på tilslutningsporten ved overførsel af LACPDU.
Men det faktum, at switchen D2 for den aggregerede grænseflade Po A fra Link 2 modtager en system-id N-værdi, der er forskellig fra den nuværende arbejdsværdi system-id A, forhindrer switchene D i at inkludere Link 2 i den aggregerede grænseflade. Po ASwitchen N kan ikke inkludere Link 2 i drift, da den ikke modtager bekræftelse om funktionalitet fra LACP-partneren på switchen. D2Trafikken sendes i sidste ende ikke via Link 2 .
Og nu afbryder vi Link 1 fra switch A1, hvilket fjerner switchene A og D for den fungerende aggregerede grænseflade. Dermed forsvinder den nuværende arbejdsværdi af system-id for grænsefladen D Dette gør det muligt for switchene Po A.
at blive enige om udvekslingen af system-id D og N A-N på grænsefladerne , så trafikken begynder at blive sendt via linket Po A og Po DN. Nedetiden i dette tilfælde udgør i praksis op til 2 sekunder. Link 2Og nu kan vi roligt skifte Link 1 til switch N1
, hvilket genopretter kapaciteten og niveauet af redundans for grænsefladerne.Da der ikke ændres på den nuværende værdi af system-id fra nogen side ved tilslutning af dette link, opstår der ikke nedetid. Po A og Po DNYderligere links
Men skiftet kan udføres uden tilstedeværelse af en ingeniør på tidspunktet for skiftet. Til dette vil vi have brug for at have forberedt yderligere links mellem distributionsswitchene
og de nye aggregationsswitches. D Vi lægger nye links mellem aggregationsswitchene N.
og distributionsswitchene for alle PODs. Dette kræver bestilling og installation af yderligere patchkabler og yderligere transceivere i både N , samt i N. Vi kan gøre dette, da vi har ledige porte (eller vi frigør dem på forhånd) i switchene Di hver POD. D hver POD har ledige porte (eller vi frigiver dem på forhånd). I sidste ende er hver POD fysisk tilsluttet med to links til de gamle switches A og de nye switches N.
På switchen D er der dannet to aggregerede interfaces — Po A med links Link 1 og Link 2, og Po N — med links Link N1 og Link N2. På dette stadium kontrollerer vi korrektheden af tilslutningen af interfaces og links, niveauerne af optiske signaler i begge ender af links (via DDM-information fra switches), vi kan endda kontrollere linkets funktionalitet under belastning eller overvåge tilstandene af de optiske signaler og temperaturerne af transceivere i et par dage.
Traffic overføres stadig via interface Po A, mens interface Po N står uden trafik. Indstillingerne på interfaces er cirka sådan her:
Interface Port-channel A
Switchport mode trunk
Switchport allowed vlan C1, C2
Interface Port-channel N
Switchport mode trunk
Switchport allowed vlan noneSwitchene D understøtter normalt sessionbaseret konfigurationsændring, der anvendes sådanne switch-modeller, der har denne funktionalitet. Så vi kan ændre indstillingerne på interfaces Po A og Po N i én enkelt handling:
Configure session
Interface Port-channel A
Switchport allowed vlan none
Interface Port-channel N
Switchport allowed vlan C1, C2
CommitSå vil konfigurationsændringen finde sted hurtigt, og pausen vil i praksis ikke vare mere end 5 sekunder.
Denne metode gør det muligt for os at udføre alle forberedende opgaver på forhånd, udføre alle nødvendige kontroller, koordinere arbejdet med deltagerne i processen, detaljeret forudsige handlinger til udførelsen af arbejdet, uden kreativ flyvning, når 'alt gik ikke som planlagt', og have en plan for at vende tilbage til den tidligere konfiguration. Arbejdet efter denne plan udføres af netværksingeniøren uden tilstedeværelse af datacenteringeniøren, som fysisk foretager omkoblinger.
Hvad der også er vigtigt ved denne metode til omkoblinger — alle nye links er allerede tidligere sat til overvågning. Fejl, tilslutning af links til aggregatet, belastning af links — alle nødvendige oplysninger er allerede i overvågningssystemet, og dette er allerede afbildet på kort.
D-Day
POD
Vi har valgt den mindst smertefulde vej for kunderne og den mindst tilbøjelige til situationer med 'noget gik galt' med omkoblinger med ekstra links. På denne måde har vi på et par nætter omkoblet alle POD til de nye aggregeringsswitches.
Men det er stadig nødvendigt at omkoblet udstyret, der leverer DCI-tjenester.
L2
Når det gælder udstyr, der sikrer L2-forbindelse, kunne vi ikke udføre lignende arbejde med de ekstra links. Der er mindst to grunde til dette:
- Manglende ledige porte med den nødvendige hastighed på VXLAN-switchene.
- Manglende funktionalitet til sessionbaseret ændring af konfigurationen på VXLAN-switchene.
Vi besluttede ikke at skifte links "én ad gangen" med kun et kort ophold mellem ensystem-id par, da vi ikke havde 100% sikkerhed for, at proceduren ville forløbe korrekt, og et test i laboratoriet viste, at hvis "noget går galt", vil vi stadig opleve nedbrud i forbindelsen, og det værste er, at det ikke kun påvirker kunder med L2-forbindelser til andre datacentre, men også generelt alle kunder i dette datacenter.
Vi havde i god tid udført oplysningsarbejde for overgangen fra L2-kanaler, så antallet af kunder, der blev berørt af arbejdet på VXLAN-switchene, var allerede flere gange mindre end for et år siden. I sidste ende besluttede vi os for at have en nedbrud i L2-forbindelsestjenesten under forudsætning af, at vi opretholder normal drift af tjenesterne i det lokale netværk i ét datacenter. Desuden dækker SLA'en for denne tjeneste mulighed for at udføre planlagte arbejder med nedbrud.
L3
Hvorfor anbefalede vi alle at overgå til brugen af L3VPN ved oprettelse af DCI-tjenester? En af grundene er muligheden for at udføre arbejde på en af routerne, der leverer denne tjeneste, blot med et reduceret niveau af redundans til N+0, uden nedbrud i forbindelsen.
Lad os se nærmere på skemaet for leveringen af tjenesten. I denne tjeneste går L2-segmentet fra kundeserverne kun til L3VPN-routerne hos Selectel. På routerne termineres kundens netværk.
Hver kundeserver, for eksempel, S2 og S3 i det viste skema har deres egne private IP-adresser — 10.0.0.2/24 for server S2 og 10.0.0.3/24 for server S3. Adresserne 10.0.0.252/24 og 10.0.0.253/24 er tildelt fra Selectel til routerne L3VPN-1 og L3VPN-2, henholdsvis. IP-adressen 10.0.0.254/24 er VRRP VIP-adressen på routerne hos Selectel.
Du kan læse mere om L3VPN-tjenesten på vores blog.
Indtil skiftet så alt ud som på skemaet:
To routere L3VPN-1 og L3VPN-2 var tilsluttet den gamle aggregationsswitch A. Masteren for VRRP VIP-adressen 10.0.0.254 er routeren L3VPN-1Han har prioriteret denne adresse højere 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;
}
}
}
}Server S2 bruger gateway 10.0.0.254 for at kommunikere med servere i andre lokationer. Således påvirker frakoblingen fra L3VPN-2 routeren (naturligvis efter at have frakoblet den fra MPLS-domenet) ikke forbindelsen mellem klientens servere. Niveauet for redundans i opsætningen falder blot på det tidspunkt.
Efter dette kan vi trygt genoprette forbindelsen til routeren. L3VPN-2 til et par switch. N. Lægge forbindelser, skifte transceivere. De logiske grænseflader på routeren, som er afhængige af klienttjenesterne, forbliver slukket indtil bekræftelse på, at alt fungerer som det skal.
Efter at have kontrolleret forbindelser, transceivere, signalniveauer og fejlniveauer på grænsefladerne, tændes routeren igen, men nu tilsluttet det nye par switch.
Dernæst sænker vi VRRP-prioriteten på routeren L3VPN-1, og VIP-adressen 10.0.0.254 flyttes til routeren L3VPN-2. Dette arbejde udføres også uden afbrydelse af forbindelsen.
Flytning af VIP-adressen 10.0.0.254 til routeren L3VPN-2 gør det muligt at slukke routeren L3VPN-1 uden at afbryde forbindelsen for klienten og tilslutte den til det nye par aggregationsswitch. N.
Om vi skal returnere VRRP VIP til routeren L3VPN-1 eller ej, er et andet spørgsmål, og hvis vi skal returnere det, gøres det uden afbrydelse af forbindelsen.
I alt
Efter alle disse handlinger har vi faktisk udskiftet aggregationsswitchene i et af vores datacentre, mens vi minimerede afbrydelser for vores kunder.
Dernæst er der kun demontering tilbage. Demontering af de gamle switch, demontering af de gamle forbindelser mellem switch A og D, demontering af transceiverne fra disse forbindelser, reparation af overvågningen, reparation af netværksdiagrammet i dokumentationen og overvågningen.
Switchene, transceiverne, patch-kablerne, AOC, DAC, der er tilbage efter omstillingerne, kan vi bruge i andre projekter eller ved andre lignende omstillinger.
"Natasha, vi har omstillet alt!"
Kilde: habr.com
