I vår lokala nätverksaggregation hade vi sex par Arista DCS-7050CX3-32S-switchar och ett par Brocade VDX 6940-36Q-switchar. Det är inte så att vi var alltför ansträngda av Brocade-switcharna i det här nätverket, de fungerar och utför sina funktioner, men vi förberedde full automatisering av vissa åtgärder, och vi hade inte dessa möjligheter på dessa switchar. Jag ville också byta från 40GE-gränssnitt till möjligheten att använda 100GE för att göra en reserv för de kommande 2-3 åren. Så vi bestämde oss för att byta Brocade till Arista.
Dessa switchar är LAN-aggregationsväxlar för varje datacenter. Distributionsväxlar (den andra nivån av aggregering) är direkt anslutna till dem, som redan monterar Top-of-Rack lokala nätverksväxlar i rack med servrar.
Varje server är ansluten till en eller två åtkomstväxlar. Accessväxlar är anslutna till ett par distributionsväxlar (två distributionsväxlar och två fysiska länkar från accessväxeln till olika distributionsväxlar används för redundans).
Varje server kan användas av sin egen klient, så klienten tilldelas ett separat VLAN. Samma VLAN registreras sedan på en annan server hos denna klient i vilket rack som helst. Datacentret består av flera sådana rader (PODs), varje rad med rack har sina egna distributionsväxlar. Sedan kopplas dessa distributionsväxlar till aggregeringsväxlar.
Klienter kan beställa en server i valfri rad, det är omöjligt att i förväg förutse att servern kommer att tilldelas eller installeras i en specifik rad i ett specifikt rack, varför det finns cirka 2500 VLAN på aggregeringsswitchar i varje datacenter.
Utrustning för DCI (Data-Center Interconnect) är ansluten till aggregationsswitchar. Den kan vara avsedd för L2-anslutning (ett par switchar som bildar en VXLAN-tunnel till ett annat datacenter) eller för L3-anslutning (två MPLS-routrar).
Som jag redan skrev, för att förena processerna för att automatisera konfigurationen av tjänster på utrustning i ett datacenter, var det nödvändigt att ersätta de centrala aggregeringsväxlarna. Vi installerade nya switchar bredvid de befintliga, kombinerade dem till ett MLAG-par och började förbereda oss för arbetet. De kopplades omedelbart till befintliga aggregeringsväxlar, så att de hade en gemensam L2-domän över alla klient-VLAN.
Kretsdetaljer
För detaljer, låt oss namnge de gamla aggregationsväxlarna A1 и A2, ny - N1 и N2. Låt oss föreställa oss det POD 1 и POD 4 servrar för en klient är värd С1, Klientens VLAN indikeras i blått. Den här klienten använder L2-anslutningstjänsten med ett annat datacenter, så dess VLAN matas till ett par VXLAN-switchar.
kund С2 värdar servrar i POD 2 и POD 3, Klient-VLAN betecknas med mörkgrönt. Den här klienten använder också en anslutningstjänst med ett annat datacenter, men L3, så dess VLAN matas till ett par L3VPN-routrar.
Vi behöver klient-VLAN för att förstå i vilka skeden av ersättningsarbetet vad som händer, var kommunikationsavbrottet inträffar och vad dess varaktighet kan vara. STP-protokollet används inte i detta schema, eftersom bredden på trädet för det i det här fallet är stor, och protokollets konvergens växer exponentiellt med antalet enheter och länkar mellan dem.
Alla enheter anslutna med dubbla länkar bildar en stack, MLAG-par eller VCS Ethernet-tyg. För ett par L3VPN-routrar används inte sådana tekniker, eftersom det inte finns något behov av L2-redundans; det räcker att de har L2-anslutning med varandra genom aggregeringsswitchar.
Genomförandealternativ
När vi analyserade alternativ för ytterligare evenemang insåg vi att det finns flera sätt att utföra detta arbete. Från ett globalt avbrott på hela det lokala nätverket, till små bokstavligen 1-2 sekunders pauser i delar av nätverket.
Nätverk, sluta! Switchar, byt ut dem!
Det enklaste sättet är naturligtvis att deklarera ett globalt kommunikationsavbrott på alla POD:er och alla DCI-tjänster och byta alla länkar från switcharna А till växlar N.
Bortsett från avbrottet, vars tid vi inte kan förutsäga på ett tillförlitligt sätt (ja, vi vet antalet länkar, men vi vet inte hur många gånger något kommer att gå fel - från en trasig patchkabel eller skadad kontakt till en felaktig port eller transceiver ), vi kan fortfarande inte förutsäga i förväg om längden på patchsladdarna, DAC, AOC, anslutna till de gamla switcharna A, kommer att räcka för att nå dem till de nya switcharna N, även om de står bredvid dem, men fortfarande lite till sidan, och om samma sändtagare kommer att fungera /DAC/AOC från Brocade-switchar till Arista-switchar.
Och allt detta under förhållanden av hårt tryck från kunder och teknisk support ("Natasha, res dig! Natasha, allt fungerar inte där! Natasha, vi har redan skrivit till teknisk support, ärligt talat! Natasha, de har redan släppt allting ! Natasha, hur många fler har inte kommer det att fungera? Natasha, när kommer det att fungera?!"). Även trots det förutannonserade avbrottet och meddelanden till kunderna, garanteras ett tillflöde av förfrågningar vid en sådan tidpunkt.
Stopp, 1-2-3-4!
Tänk om vi inte tillkännager ett globalt avbrott, utan snarare en serie små kommunikationsavbrott för POD- och DCI-tjänster. Under den första pausen, byt till switchar N endast POD 1, i den andra - om ett par dagar - POD 2, sedan ett par dagar till POD 3, Ytterligare POD 4…[N], sedan VXLAN-switchar och sedan L3VPN-routrar.
Med denna organisation av växlingsarbetet minskar vi komplexiteten i engångsarbetet och ökar vår tid för att lösa problem om något plötsligt går fel. POD 1 förblir ansluten till andra POD:er och DCI:er efter bytet. Men själva arbetet drar ut på tiden; under detta arbete i datacentret krävs en ingenjör för att fysiskt utföra omkopplingen och under arbetet (och sådant arbete utförs som regel på natten från 2. till 5 på morgonen), krävs närvaron av en online-nätverksingenjör med en ganska hög kvalifikationsnivå. Men då får vi korta kommunikationsavbrott, som regel kan arbetet utföras i ett intervall på en halvtimme med en paus på upp till 2 minuter (i praktiken ofta 20-30 sekunder med utrustningens förväntade beteende).
I exemplet klient С1 eller klient С2 du måste varna för arbete med ett kommunikationsavbrott minst tre gånger - första gången för att utföra arbete på en POD, där en av dess servrar finns, andra gången - på andra och tredje gången - när omkopplingsutrustning för DCI-tjänster.
Byte av aggregerade kommunikationskanaler
Varför pratar vi om utrustningens förväntade beteende och hur aggregerade kanaler kan bytas samtidigt som kommunikationsavbrott minimeras? Låt oss föreställa oss följande bild:
På ena sidan av länken finns POD-distributionsbrytare - D1 и D2, de bildar ett MLAG-par med varandra (stack, VCS-fabrik, vPC-par), å andra sidan finns det två länkar - Länk 1 и Länk 2 - ingår i MLAG-paret av gamla aggregationsväxlar А. På växelsidan D ett aggregerat gränssnitt med namnet Port-kanal A, på sidan av aggregeringsbrytare А - aggregerat gränssnitt med namnet Port-kanal D.
Aggregerade gränssnitt använder LACP i sin verksamhet, det vill säga switchar på båda sidor utbyter regelbundet LACPDU-paket på båda länkarna för att säkerställa att länkarna:
- arbetar;
- ingår i ett par enheter på fjärrsidan.
Vid utbyte av paket bär paketet värdet system-id, som anger enheten där dessa länkar ingår. För ett MLAG-par (stack, fabrik, etc.) är system-id-värdet för enheterna som bildar det aggregerade gränssnittet detsamma. Växla D1 skickar till Länk 1 betyder system-id D, och växla D2 skickar till Länk 2 betyder system-id D.
Växlar A1 и A2 analysera LACPDU-paket som tas emot över ett Po D-gränssnitt och kontrollera om system-id:t i dem matchar. Om system-id som tas emot via någon länk plötsligt skiljer sig från det aktuella driftsvärdet, sedan tas denna länk bort från det aggregerade gränssnittet tills situationen har rättats till. Nu på vår växlingssida D nuvarande system-id-värde från LACP-partnern - A, och på omkopplarsidan А — nuvarande system-id-värde från LACP-partnern — D.
Om vi behöver byta det aggregerade gränssnittet kan vi göra det på två olika sätt:
Metod 1 - Enkel
Inaktivera båda länkarna från switcharna A. I det här fallet fungerar inte den aggregerade kanalen.
Anslut båda länkarna en efter en till switcharna N, då kommer LACP-driftparametrarna att förhandlas igen och gränssnittet bildas PoD på strömbrytare N och överföring av värden på länkar system-id N.
Metod 2 - Minimera avbrott
Koppla bort Link 2 från switch A2. Samtidigt trafik mellan А и D kommer att fortsätta att överföras helt enkelt över en av länkarna, som kommer att förbli en del av det aggregerade gränssnittet.
Anslut Link 2 till switch N2. På strömbrytaren N det aggregerade gränssnittet är redan konfigurerat Po DN, och växla N2 kommer att börja sända till LACPDU system-id N. I detta skede kan vi redan kontrollera att omkopplaren N2 fungerar korrekt med den transceiver som används för Länk 2, att anslutningsporten har gått in i tillståndet Up, och att inga fel uppstår på anslutningsporten vid överföring av LACPDU:er.
Men det faktum att bytet D2 för aggregerat gränssnitt Po A från sidan Länk 2 får ett system-id N-värde som skiljer sig från det nuvarande operativsystem-id A-värdet, tillåter inte omkopplare D ange Länk 2 en del av det aggregerade gränssnittet Po A. Växla N kan inte komma in Länk 2 i drift, eftersom den inte får någon bekräftelse på funktionsduglighet från switchens LACP-partner D2. Den resulterande trafiken är Länk 2 kommer inte igenom.
Och nu stänger vi av Link 1 från switch A1, och därigenom berövar omkopplarna А и D fungerande aggregatgränssnitt. Alltså på växelsidan D det nuvarande fungerande system-id-värdet för gränssnittet försvinner Po A.
Detta tillåter växlar D и N acceptera att byta system-id EN på gränssnitt Po A и Po DN, så att trafik börjar överföras längs länken Länk 2. Pausen i detta fall är i praktiken upp till 2 sekunder.
Och nu kan vi enkelt byta länk 1 till byte N1, återställande av kapacitet och nivå av gränssnittsredundans Po A и Po DN. Eftersom när denna länk är ansluten ändras det aktuella system-id-värdet inte på någon sida, det finns inget avbrott.
Ytterligare länkar
Men bytet kan utföras utan närvaro av en ingenjör vid tidpunkten för bytet. För att göra detta måste vi lägga ytterligare länkar mellan distributionsväxlar i förväg D och nya aggregationsväxlar N.
Vi lägger nya länkar mellan aggregeringsväxlar N och distributionsomkopplare för alla POD:er. Detta kräver att man beställer och lägger ytterligare patch-kablar och installerar ytterligare transceivrar som i N, och i D. Vi kan göra detta eftersom i våra switchar D Varje POD har lediga portar (eller så förfrigör vi dem). Som ett resultat är varje POD fysiskt ansluten med två länkar till de gamla switcharna A och till de nya switcharna N.
På strömbrytaren D två aggregerade gränssnitt har bildats - Po A med länkar Länk 1 и Länk 2Och Po N - med länkar Länk N1 и Länk N2. I detta skede kontrollerar vi den korrekta anslutningen av gränssnitt och länkar, nivåerna av optiska signaler i båda ändarna av länkarna (via DDM-information från switcharna), vi kan till och med kontrollera prestanda för länken under belastning eller övervaka tillstånden för optiska signaler och transceivertemperaturer under ett par dagar.
Trafik skickas fortfarande via gränssnittet Po Aoch gränssnittet Po N kostar ingen trafik. Inställningarna på gränssnitten är ungefär så här:
Interface Port-channel A
Switchport mode trunk
Switchport allowed vlan C1, C2
Interface Port-channel N
Switchport mode trunk
Switchport allowed vlan noneD-switchar stöder som regel sessionsbaserade konfigurationsändringar, switchmodeller som har denna funktionalitet används. Så vi kan ändra inställningarna för Po A- och Po N-gränssnitten i ett steg:
Configure session
Interface Port-channel A
Switchport allowed vlan none
Interface Port-channel N
Switchport allowed vlan C1, C2
CommitDå kommer konfigurationsändringen att ske tillräckligt snabbt och pausen kommer i praktiken inte att vara mer än 5 sekunder.
Denna metod tillåter oss att slutföra allt förberedande arbete i förväg, utföra alla nödvändiga kontroller, samordna arbetet med deltagarna i processen, förutsäga i detalj åtgärderna för produktion av arbete, utan kreativitetsflyg när "allt gick fel ,” och har en plan till hands för att återgå till den tidigare konfigurationen. Arbete enligt denna plan utförs av en nätverksingenjör utan närvaro av en datacenteringenjör på plats som fysiskt utför växlingen.
Vad som också är viktigt med denna metod att byta är att alla nya länkar redan är övervakade i förväg. Fel, inkludering av länkar i enheten, laddning av länkar - all nödvändig information finns redan i övervakningssystemet, och detta är redan ritat på kartorna.
D-dagen
Leveransbekräftelser (POD)
Vi valde den minst smärtsamma bytesvägen för klienter och de minst benägna att "något gick fel" med ytterligare länkar. Så vi bytte alla PODs till nya aggregationsväxlar på ett par nätter.
Men allt som återstår är att byta utrustning som tillhandahåller DCI-tjänster.
L2
När det gäller utrustning som ger L2-anslutning, kunde vi inte utföra liknande arbete med ytterligare länkar. Det finns åtminstone två anledningar till detta:
- Brist på lediga portar med erforderlig hastighet på VXLAN-switchar.
- Avsaknad av sessionskonfigurationsändringsfunktionalitet på VXLAN-switchar.
Vi bytte inte länkar "en i taget" med en paus bara när vi kom överens om ett nytt system-id-par, eftersom vi inte hade 100 % förtroende för att proceduren skulle gå korrekt, och ett test i laboratoriet visade att i Om "något går fel" får vi fortfarande ett anslutningsavbrott, och det värsta är inte bara för klienter som har L2-anslutning med andra datacenter, utan i allmänhet för alla klienter i detta datacenter.
Vi genomförde propagandaarbete i förväg med övergången från L2-kanaler, så antalet klienter som påverkades av arbete med VXLAN-switchar var redan flera gånger för mindre än ett år sedan. Som ett resultat beslutade vi att avbryta kommunikationen via L2-anslutningstjänsten, förutsatt att vi upprätthåller normal drift av lokala nätverkstjänster i ett datacenter. Dessutom ger SLA för denna tjänst möjlighet att utföra schemalagda arbeten med paus.
L3
Varför rekommenderade vi att alla byter till L3VPN när de organiserar DCI-tjänster? En av anledningarna är möjligheten att utföra arbete på en av routrarna som tillhandahåller denna tjänst, genom att helt enkelt minska redundansnivån till N+0, utan att avbryta kommunikationen.
Låt oss ta en närmare titt på tjänsteleveransschemat. I denna tjänst går L2-segmentet från endast klientservrar till L3VPN Selectel-routrar. Klientnätverket avslutas på routrar.
Varje klientserver, t.ex. S2 и S3 i diagrammet ovan, ha sina egna privata IP-adresser - 10.0.0.2/24 på S2-servern и 10.0.0.3/24 på S3-servern. Adresser 10.0.0.252/24 и 10.0.0.253/24 tilldelas av Selectel till routrar L3VPN-1 и L3VPN-2, respektive. IP-adress 10.0.0.254/24 är en VRRP VIP-adress på Selectel-routrar.
Du kan lära dig mer om L3VPN-tjänsten i vår blogg.
Före bytet såg allt ungefär ut som i diagrammet:
Två routrar L3VPN-1 и L3VPN-2 var anslutna till den gamla aggregationsbrytaren А. Mastern för VRRP VIP-adress 10.0.0.254 är routern L3VPN-1. Den har högre prioritet för den här adressen än routern 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-servern använder gateway 10.0.0.254 för att kommunicera med servrar på andra platser. Att koppla bort L3VPN-2-routern från nätverket (naturligtvis, om den först kopplas från MPLS-domänen) påverkar således inte anslutningen till klientens servrar. Vid denna tidpunkt reduceras helt enkelt kretsens redundansnivå.
Efter detta kan vi säkert återansluta routern L3VPN-2 till ett par strömbrytare N. Lägg länkar, byt sändare/mottagare. Routerns logiska gränssnitt, som driften av klienttjänster beror på, är inaktiverade tills det bekräftas att allt fungerar som det ska.
Efter att ha kontrollerat länkarna, transceivrarna, signalnivåerna och felnivåerna på gränssnitten, sätts routern i drift, men är redan ansluten till ett nytt par switchar.
Därefter sänker vi VRRP-prioriteten för L3VPN-1-routern, och VIP-adressen 10.0.0.254 flyttas till L3VPN-2-routern. Dessa arbeten utförs också utan avbrott i kommunikationen.
Överför VIP-adress 10.0.0.254 till routern L3VPN-2 låter dig inaktivera routern L3VPN-1 utan avbrott i kommunikationen för klienten och koppla den till ett nytt par aggregeringsväxlar N.
Huruvida VRRP VIP ska returneras till L3VPN-1-routern är en annan fråga, och även om den returneras görs det utan att avbryta anslutningen.
Totalt
Efter alla dessa steg bytte vi faktiskt ut aggregeringsväxlarna i ett av våra datacenter, samtidigt som vi minimerade störningar för våra kunder.
Allt som återstår är demontering. Demontering av gamla switchar, demontering av gamla länkar mellan switchar A och D, demontering av transceivrar från dessa länkar, korrigering av övervakning, korrigering av nätverksdiagram i dokumentation och övervakning.
Vi kan använda switchar, transceivers, patch-kablar, AOC, DAC kvar efter byte i andra projekt eller för andra liknande switchar.
"Natasha, vi bytte allt!"
Källa: will.com