🥇Historien om en omkoppling

I vår lokala nätverksaggregator hade vi sex par Arista DCS-7050CX3-32S switchar och ett par Brocade VDX 6940-36Q switchar. Det var inte så att Brocade switcharna belastade oss i nätverket, de fungerar och uppfyller sina syften, men vi förberedde full automatisering av vissa uppgifter, och de möjligheterna hade vi inte med dessa switchar. Vi ville också gå från 40GE-gränssnitt till möjlighet att använda 100GE, för att göra ett överskott inför de kommande 2-3 åren. Så vi beslutade att byta ut Brocade mot Arista.

Dessa switchar fungerar som lokala nätverksaggregationsswitchar för varje datacenter. De är direkt anslutna till distributionsswitchar (andra nivån av aggregation), som i sin tur samlar Top-of-Rack-switchar i serverrack.

Varje server är ansluten till en eller två åtkomstswitchar. Åtkomstswitcharna är kopplade till ett par distributionsswitchar (två distributionsswitchar och två fysiska länkar från åtkomstswitcharna till olika distributionsswitchar används för redundans).

Varje server kan användas av sin kund, så varje kund tilldelas en egen VLAN. Denna VLAN konfigureras sedan på en annan server för den kunden i vilket rack som helst. Datacentret består av flera sådana rader (POD:s), och varje rad har sina egna distributionsswitchar. Dessa distributionsswitchar ansluts sedan till aggregationsswitcharna.

Kunder kan beställa server i valfri rad, det går inte att förutsäga i förväg att en server kommer att tilldelas eller installeras i en viss rad i ett visst rack, därför finns det omkring 2500 VLAN i varje datacenter på aggregationsswitcharna.

Utrustning för DCI (Data-Center Interconnect) kopplas till aggregationsswitcharna. Den kan vara avsedd för L2-koppling (ett par switchar som skapar en VXLAN-tunnel till ett annat datacenter) eller L3-koppling (två MPLS-router).

Som jag redan har skrivit, krävdes det att byta ut de centrala aggregatorswitcharna för att standardisera processerna för automatisering av konfigurationen av tjänster på utrustningen i ett och samma datacenter. Vi installerade nya switchar bredvid de befintliga, kopplade dem i ett MLAG-par och började förbereda oss för arbetet. De kopplades genast till de befintliga aggregatorswitcharna, så de fick en gemensam L2-domän för alla kund-VLAN.

Schema Detaljer

För att vara specifik, låt oss kalla de gamla aggregatorswitcharna A1 och A2, de nya — N1 och N2. Låt oss föreställa oss att i POD 1 och POD 4 är servrar från en och samma kund C1, kundens VLAN är markerat med blå färg. Denna kund använder L2-anslutningstjänsten med ett annat datacenter, så deras VLAN är kopplad till ett par VXLAN-switchar.

Klient C2 placeras servrar i POD 2 och POD 3, kundens VLAN markeras med mörkgrön färg. Denna kund använder också anslutningstjänsten med ett annat datacenter, men L3, så deras VLAN är kopplad till ett par L3VPN-router.

Kund-VLAN behövs för att förstå vilka steg i arbetet med bytet som pågår, var det kan uppstå avbrott i kommunikationen och hur länge de kan vara. STP-protokollet används inte i detta schema, eftersom bredden på trädet i så fall blir stor, och konvergensen av protokollet ökar i geometrisk progression i förhållande till antalet enheter och länkar mellan dem.

Alla enheter som är kopplade med dubbla länkar bildar ett stack, MLAG-par eller VCS-Ethernet-fabrik. För ett par L3VPN-router används liknande teknologier inte, eftersom det inte finns något behov av L2-redundans, det räcker med att de har L2-anslutning till varandra genom aggregatorswitcharna.

Implementeringsalternativ

Vid analys av alternativ för framtida händelser insåg vi att det finns flera sätt att genomföra detta arbete. Från ett globalt avbrott i hela det lokala nätverket, till små kortvariga avbrott på bokstavligen 1-2 sekunder i delar av nätverket.

Nätverket, stanna! Switcharna, byt ut er!

Det enklaste sättet är förstås att tillkännage ett globalt avbrott i kommunikationen över alla POD och alla DCI-tjänster och omkoppla alla länkar från switcharna A till switcharna N.

Förutom avbrottet, vars tid vi inte kan garantera att förutsäga (ja, vi vet antalet länkar, men vi vet inte hur många gånger något kan gå fel – från en trasig patchkabel eller en skadad kontakt till fel på porten eller transceivern), kan vi inte heller förutse i förväg om längden på patchkablar, DAC, AOC, som är kopplade till gamla switchar A, kommer att räcka för att nå de nya switcharna N, som trots att de står nära ändå är lite åt sidan, och om exakt samma transceivrar/DAC/AOC från Brocade-switcharna kommer att fungera i Arista-switcharna.

Och allt detta under ett hårt tryck från kunder och teknisk support ("Natasha, gå upp! Natasha, där fungerar ingenting! Natasha, vi har redan skrivit till supporten, ärligt, ärligt! Natasha, allt har redan kraschat! Natasha, hur länge kommer det att vara ur funktion? Natasha, när kommer det att fungera?!"). Trots det förutskickade avbrottet och meddelandet till kunderna är en ökning av ärenden under denna tid garanterad.

Stanna, 1-2-3-4!

Och om vi inte tillkännager ett globalt avbrott, utan tillkännager en serie små kommunikationsavbrott enligt POD och DCI-tjänster. Under det första avbrottet ska vi byta i switcharna N bara POD 1, under det andra – om ett par dagar – POD 2, sedan efter ytterligare ett par dagar POD 3, och därefter POD 4…[N], sedan VXLAN-switcharna och därefter L3VPN-router.

Genom att organisera arbetet med omkoppling på detta sätt minskar vi komplexiteten i de samtidigt utförda arbetena och ger oss mer tid att lösa problem om något skulle gå fel. Kopplingen av POD 1 efter omkopplingen med andra POD och DCI förloras inte. Men själva arbetet tar lång tid, under dessa arbeten krävs en ingenjör i datacentret för fysiska omkopplingar, och under arbetet (som vanligtvis utförs på natten, mellan 2 och 5 på morgonen) krävs en online-nätverksingenjör med hög kompetens. Men vi får i gengäld korta kommunikationsavbrott, som regel kan arbetena utföras inom en halvtimme med avbrott på upp till 2 minuter (i praktiken, ofta 20-30 sekunder med förväntat beteende hos utrustningen).

I det angivna exemplet från kunden C1 eller kunden C2 Det kommer att krävas att vi varnar om arbeten med avbrott i kommunikationen minst tre gånger — första gången för att utföra arbeten på en POD där en av dess servrar finns, andra gången — för den andra, och tredje gången — vid omkoppling av utrustningen för DCI-tjänster.

Omkoppling av aggregerade kommunikationskanaler

Varför pratar vi om det förväntade beteendet hos utrustningen, och hur aggregerade kanaler kan växla med minimerad kommunikationsavbrott. Låt oss föreställa oss följande bild:

På ena sidan av länken — distributionsswitchar i POD — D1 och D2, de bildar en MLAG-par (stack, VCS-fabrik, vPC-par), på andra sidan två länkar — Länk 1 och Länk 2 — anslutna till MLAG-par av gamla aggregeringsswitchar A. På sidan av switcharna D bildas en aggregerad gränssnitt med namnet Port-channel A, på sidan av aggregeringsswitcharna A — aggregerad gränssnitt med namnet Port-channel D.

Aggregerade gränssnitt använder LACP i sin verksamhet, vilket innebär att switcharna på båda sidor regelbundet utbyter LACPDU-paket över båda länkarna för att säkerställa att länkarna:

är aktiva;
är anslutna till ett par enheter på den avlägsna sidan.

Vid paketutbyte överförs ett värde system-id, som betecknar enheten där dessa länkar är anslutna. För en MLAG-par (stack, fabrik etc.) är värdet av system-id för enheter som bildar det aggregerade gränssnittet samma. Switch D1 skickar till Länk 1 värdet system-id D, och switch D2 skickar till Länk 2 värdet system-id D.

Switchar A1 och A2 analyserar LACPDU-paket, mottagna via ett Po D-gränssnitt, och kontrollerar överensstämmelse av system-id i dem. Om det mottagna system-id som kommer via någon länk plötsligt skiljer sig från det aktuella arbetande värdet, så tas den länken ut från det aggregerade gränssnittet tills situationen åtgärdas. Just nu har vi på sidan av switcharna D det aktuella system-id-värdet från LACP-partnern — A, och på sidan av switcharna A — det aktuella system-id-värdet från LACP-partnern — D.

Vid behov av att växla det aggregerade gränssnittet kan vi agera på två olika sätt:

Metod 1 — Enkel
Koppla bort båda länkarna från switcharna A.Då fungerar inte den aggregerade kanalen.

Anslut båda länkarna i tur och ordning till switcharna N, då kommer en ny förhandling om LACPs funktionsparametrar att ske, gränssnittet Po D på switcharna N och överföringen på länkarna av värdet system-id N.

Metod 2 - Minimera avbrottet
Stäng av från switch A2 länk Link 2. Under tiden kommer trafiken mellan A och D att fortsätta överföras enkelriktat genom en av länkarna som förblir en del av det aggregerade gränssnittet.

Anslut Link 2 till switch N2. På switchen N är det redan inställt ett aggregerat gränssnitt Po DN, och switch N2 börjar överföra i LACPDU system-id N. Vid detta stadium kan vi redan kontrollera att switchen N2 korrekt fungerar med transceivern som används för Länk 2, att anslutningsporten har gått över till tillståndet Up, och att ingen fel uppstår vid överföringen av LACPDU på anslutningsporten.

Men faktumet att switchen D2 för det aggregerade gränssnittet Po A från Link 2 får ett system-id N, som skiljer sig från det nuvarande aktiva värdet system-id A, gör att switcharna D inte kan lägga till Länk 2 i det aggregerade gränssnittet. Po ASwitchen N kan inte läggas till Länk 2 i drift eftersom den inte får bekräftelse av funktionsstatus från LACP-partnern i switchen. D2I slutändan överförs inte trafiken genom Länk 2 .

Nu stänger vi av Link 1 från switch A1, vilket berövar switcharna A och D ett fungerande aggregerat gränssnitt. Således försvinner det nuvarande aktiva värdet system-id för gränssnittet D Det gör att switcharna Po A.

kan enas om att byta system-id D och N A-N på gränssnitten, så att trafiken börjar överföras genom länken. Po A och Po DN. Avbrottet i detta fall är i praktiken upp till 2 sekunder. Länk 2Och nu kan vi lugnt koppla Link 1 till switch N1

, vilket återställer kapaciteten och nivån av redundans för gränssnitten.Eftersom inget aktuellt värde av system-id ändras från någon sida vid anslutning av denna länk, uppstår inget avbrott. Po A och Po DNExtra länkar

Men bytet kan utföras utan närvaro av en ingenjör vid tidpunkten för bytet. För detta behöver vi i förväg dra ytterligare länkar mellan distributionsswitcharna

och de nya aggregator switcharna. D Vi drar nya länkar mellan aggregator switcharna N.

och distributionsswitcharna i alla POD:ar. Detta kräver beställning och dragning av ytterligare patchkablage, samt installation av fler transceivrar som i N . Vi kan göra detta eftersom vi har lediga portar i switcharna N.ts Di varje POD (eller vi frigör dem i förväg). D Varje POD har lediga portar (eller så frigör vi dem i förväg). I slutändan är varje POD fysiskt ansluten med två länkar till de gamla switcharna A och de nya switcharna N.

På switchen D har två aggregerade gränssnitt skapats — Po A med länkarna Länk 1 och Länk 2, och Po N — med länkarna Link N1 och Link N2. I detta skede kontrollerar vi korrektheten av anslutningen av gränssnitten och länkarna, nivåerna av optiska signaler i båda ändarna av länkarna (genom DDM-information från switcharna), vi kan till och med kontrollera funktionaliteten av länken under belastning eller övervaka tillståndet för de optiska signalerna och temperaturerna på transceivrarna under några dagar.

Trafiken fortsätter att överföras genom gränssnittet Po A, medan gränssnittet Po N står utan trafik. Inställningarna på gränssnitten är ungefär som följer:

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

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

Switchar D stödjer vanligtvis sessionsbaserad konfigurationsändring, sådana switchmodeller används som har denna funktion. Så vi kan göra ändringar i inställningarna för gränssnitten Po A och Po N i ett enda steg:

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

Då kommer konfigurationsändringen att ske ganska snabbt, och avbrottet kommer i praktiken att vara högst 5 sekunder.

Denna metod gör det möjligt för oss att utföra allt förberedande arbete i förväg, genomföra alla nödvändiga kontroller, samordna arbetet med deltagarna i processen, noggrant förutspå åtgärder för att utföra arbetet, utan några kreativa inslag där "allt gick fel", och ha en plan för att återgå till den tidigare konfigurationen. Arbetet enligt denna plan utförs av nätverksingenjören utan att en datahallingenjör fysiskt är närvarande för att göra omkopplingarna.

Vad som också är viktigt vid en sådan omkoppling — alla nya länkar har redan installerats för övervakning. Fel, aktivering av länkar i aggregatet, belastning på länkarna — all nödvändig information finns redan i övervakningssystemet, och detta är redan ritad på kartorna.

D-Dag

POD

Vi har valt den minst smärtsamma vägen för kunderna och den som minst troligt leder till "något gick fel" när vi gör omkopplingar med extra länkar. Så vi har under några nätter kopplat om alla POD till de nya aggregationsswitcharna.

Men det återstår att koppla om utrustningen som tillhandahåller DCI-tjänster.

L2

När det gäller utrustning som tillhandahåller L2-koppling, kunde vi inte utföra liknande arbete med ytterligare länkar. Orsaken är minst två:

Brist på lediga portar med rätt hastighet på VXLAN-switchar.
Avsaknaden av funktionalitet för sessionell konfigurationsändring på VXLAN-switchar.

Vi genomförde inte bytet av länkar "en i taget" med avbrott endast under tiden för att samordna det nya system-ID:t, eftersom vi inte hade 100% trygghet i att proceduren skulle gå korrekt. Ett labbtest visade att om "något går fel", får vi ändå ett avbrott i kommunikationen, och det värsta av allt — inte bara för kunder som har L2-koppling med andra datacenter, utan för alla kunder i detta datacenter.

Vi genomförde på förhand propagandaarbete för att övergå från L2-kanaler, så antalet kunder som påverkades av arbetet på VXLAN-switcharna var redan flera gånger färre än för ett år sedan. I slutändan beslutade vi oss för ett avbrott i kommunikationen gällande L2-koppling, förutsatt att vi upprätthöll normal drift av lokala nätverkstjänster i ett datacenter. Dessutom föreskriver SLA för denna tjänst möjlighet till planerade arbeten med avbrott.

L3

Varför rekommenderade vi alla att övergå till användning av L3VPN vid organisering av DCI-tjänster? En av anledningarna är möjligheten att utföra arbete på en av routrarna som tillhandahåller denna tjänst, helt enkelt genom att sänka nivåerna för redundans till N+0, utan avbrott i kommunikationen.

Låt oss titta närmare på schemat för tillhandahållande av tjänsten. I denna tjänst går L2-segmentet endast från kundens servrar till L3VPN-router från Selectel. Kundenätet termineras vid routrarna.

Varje kundserver, till exempel, S2 och S3 i det givna schemat, har sina privata IP-adresser — 10.0.0.2/24 för server S2 och 10.0.0.3/24 för server S3. Adresserna 10.0.0.252/24 och 10.0.0.253/24 är tilldelade av Selectel till routrarna L3VPN-1 och L3VPN-2, respektive. IP-adressen 10.0.0.254/24 är VRRP VIP-adressen på routrarna från Selectel.

Mer information om L3VPN-tjänsten kan läsa finnas i vår blogg.

Före bytet såg allt ut som i schemat:

Två routrar L3VPN-1 och L3VPN-2 var anslutna till den gamla aggregationsswitchen A. Master för VRRP VIP-adressen 10.0.0.254 är routern L3VPN-1Den har ett högre prioritet för denna adress än router L3VPN-2.

enhet 1006 {
    beskrivning C2;
    vlan-id 1006;
    familj inet {       
        adress 10.0.0.252/24 {
            vrrp-grupp 1 {
                prioritet 200;
                virtuell-adress 10.100.0.254;
                förhindra {
                    håll-tid 120;
                }
                acceptera-data;
            }
        }
    }
}

Server S2 använder gateway 10.0.0.254 för att kommunicera med servrar på andra platser. Därmed påverkar avstängningen av L3VPN-2-routern (naturligtvis efter att den har stängts av från MPLS-domänen) inte servernas kommunikation. Just då minskar bara redundansnivån i systemet.

Efter det kan vi lugnt återansluta routern L3VPN-2 till ett par switchar N. Dra kablar, byta transceivers. De logiska gränssnitten på routern som är avgörande för kundens tjänster är avstängda tills vi bekräftar att allt fungerar som det ska.

Efter att linjer, transceivers, signalnivåer och felnivåer kontrolleras sätts routern i drift, men redan ansluten till det nya paret switchar.

Därefter sänker vi VRRP-prioriteten på L3VPN-1-routern, och VIP-adressen 10.0.0.254 flyttas till L3VPN-2-routern. Dessa arbete utförs också utan att bryta kommunikationen.

Flyttning av VIP-adressen 10.0.0.254 till routern L3VPN-2 möjliggör avstängning av routern L3VPN-1 utan att bryta kommunikationen för kunden och koppla den till det nya paret av aggregeringsswitchar N.

Att återföra VRRP VIP till L3VPN-1-routern eller inte — det är en annan fråga, och om man återför, så görs det utan att bryta kommunikationen.

Sammanfattningsvis

Efter alla dessa åtgärder har vi faktiskt bytt ut aggregeringsswitcharna i ett av våra datacenter, och därmed minimerat avbrott för våra kunder.

Sedan kvarstår bara demontering. Demontering av de gamla switcharna, demontering av de gamla kablarna mellan switcharna A och D, demontering av transceivers från dessa kablar, korrigering av övervakningen, ändring av nätverksscheman i dokumentationen och övervakningen.