In onze lokale netwerkintegratie hadden we zes paren Arista DCS-7050CX3-32S switches en één paar Brocade VDX 6940-36Q switches. Het is niet dat de Brocade switches ons echt storen in dit netwerk, ze functioneren en vervullen hun taken, maar we waren bezig met een volledige automatisering van bepaalde acties en die mogelijkheden hadden we niet met deze switches. Daarnaast wilden we overschakelen van 40GE interfaces naar de mogelijkheid om 100GE te gebruiken, zodat we een reserve hadden voor de komende 2-3 jaar. Dus besloten we Brocade te vervangen door Arista.
Deze switches fungeren als aggregatie switches voor elk datacenter. Ze zijn direct aangesloten op de distributie switches (de tweede aggregatielaag), die op hun beurt de Top-of-Rack switches in de serverrekken verzamelen.
Elke server is aangesloten op één of twee toegangsswitches. De toegangsswitches zijn verbonden met een paar distributie switches (twee distributie switches en twee fysieke verbindingen van de toegangsswitch naar verschillende distributie switches worden gebruikt voor redundantie).
Elke server kan door zijn klant worden gebruikt, zodat aan de klant een aparte VLAN wordt toegewezen. Deze VLAN wordt later ook toegewezen aan een andere server van deze klant in elk rek. Het datacenter bestaat uit verschillende rijen (POD's), waarbij elke rij eigen distributie switches heeft. Deze distributie switches worden op hun beurt aangesloten op de aggregatie switches.
Klanten kunnen een server in elke rij bestellen; het is van tevoren niet te voorspellen dat de server aan een bepaalde rij of in een specifiek rek wordt toegewezen, daarom zijn er op de aggregatie switches ongeveer 2500 VLAN's in elk datacenter.
De apparatuur voor DCI (Data-Center Interconnect) is aangesloten op de aggregatie switches. Deze kan zijn bedoeld voor L2-connectiviteit (een paar switches die een VXLAN-tunnel naar een ander datacenter vormen), of voor L3-connectiviteit (twee MPLS-routers).
Zoals ik eerder schreef, was het noodzakelijk om de centrale aggregatieswitches te vervangen om de processen van configuratieautomatisering van diensten op apparatuur in één datacenter te uniformiseren. We hebben nieuwe switches naast de bestaande geïnstalleerd, ze samen gevoegd in een MLAG-paar en begonnen ons voor te bereiden op de werkzaamheden. Deze zijn meteen verbonden met de bestaande aggregatieswitches, zodat ze een gezamenlijke L2-domein hebben over alle klant-VLAN's.
Details van het schema
Om specifieker te zijn, noemen we de oude aggregatieswitches A1 en A2, de nieuwe — N1 en N2. Laten we zeggen dat in POD 1 en POD 4 servers van één klant zijn geplaatst C1, het VLAN van de klant is weergegeven in het blauw. Deze klant maakt gebruik van een L2-connectiviteitservice met een ander datacenter, dus zijn VLAN is aangesloten op een paar VXLAN-switches.
Klant C2 plaatst servers in POD 2 en POD 3, het VLAN van de klant is in donker groen weergegeven. Deze klant gebruikt ook een connectiviteitservice met een ander datacenter, maar dan L3, dus zijn VLAN is aangesloten op een paar L3VPN-routers.
Klanten-VLAN's zijn nodig om te begrijpen welke stappen er bij de vervangingswerkzaamheden plaatsvinden, waar er onderbrekingen in de verbinding optreden, en wat de duur daarvan kan zijn. Het STP-protocol wordt in dit schema niet gebruikt, omdat de diepte van de boom anders groot wordt, en de convergentietijd van het protocol exponentieel toeneemt met het aantal apparaten en verbindingen tussen hen.
Alle apparaten die met dubbele verbindingen zijn verbonden, vormen een stapel, MLAG-paar of VCS-Ethernet-fabriek. Voor een paar L3VPN-routers worden dergelijke technologieën niet gebruikt, omdat er geen noodzaak is voor L2-redundantie, het is voldoende dat ze L2-connectiviteit met elkaar hebben via de aggregatieswitches.
Implementatieopties
Bij het analyseren van de verschillende mogelijkheden, realiseerden we ons dat er verschillende manieren zijn om deze werkzaamheden uit te voeren. Van een wereldwijde onderbreking in het gehele lokale netwerk, tot kleine onderbrekingen van letterlijk 1-2 seconden in delen van het netwerk.
Netwerk, halt! Switches, vervang jezelf!
De eenvoudigste manier is natuurlijk om een wereldwijde verbindingonderbreking aan te kondigen voor alle POD's en voor alle DCI-diensten en alle verbindingen van de switches A naar de switches over te schakelen. N.
Naast de onderbreking, de tijd waarvan we niet gegarandeerd kunnen voorspellen (ja, we kennen het aantal kabels, maar we weten niet hoe vaak er iets misgaat - van een gebroken patchkabel of een beschadigde connector tot een defecte poort of transceiver), kunnen we ook niet van tevoren voorspellen of de lengte van de patchkabels, DAC, AOC, aangesloten op oude switches A, genoeg is om ze naar de nieuwe switches N te trekken, die al dichtbij staan, maar toch net iets verder weg, en of dezelfde transceivers/DAC/AOC van Brocade-switches in Arista-switches zullen werken.
En dat alles onder druk van klanten en de technische ondersteuning (‘Natasja, kom op! Natasja, niets werkt! Natasja, we hebben al contact opgenomen met technische ondersteuning, echt waar! Natasja, alles is al gevallen! Natasja, hoe lang zal het nog niet werken? Natasja, wanneer werkt het?!’). Zelfs met de vooraf aangekondigde onderbreking en de kennisgeving aan de klanten, is er gegarandeerd een stortvloed aan aanvragen in zo'n tijd.
Wacht, 1-2-3-4!
En als we geen globale onderbreking aankondigen, maar een reeks kleine verbindingsonderbrekingen per POD en DCI aankondigen. Bij de eerste onderbreking om te schakelen naar de switches N van POD 1, bij de tweede - over een paar dagen - POD 2, vervolgens weer over een paar dagen POD 3, daarna POD 4…[N], daarna de VXLAN-switches en vervolgens de L3VPN-routers.
Met deze organisatie van de overschakelingswerkzaamheden verkleinen we de complexiteit van gelijktijdige werkzaamheden en vergroten we onze tijd om problemen op te lossen als er iets misgaat. De connectiviteit van POD 1 blijft na de overschakeling met andere POD en DCI intact. Maar de werkzaamheden zelf duren lang, gedurende deze werkzaamheden is er behoefte aan een ingenieur in het datacenter voor de fysieke uitvoering van de overschakelingen, en tijdens de werkzaamheden (die meestal 's nachts worden uitgevoerd, van 2 tot 5 uur 's ochtends) is er een online netwerkingenieur van vrij hoge kwalificatie vereist. Maar zo krijgen we korte verbindingsonderbrekingen, de werkzaamheden kunnen meestal binnen een half uur worden uitgevoerd met een pauze van maximaal 2 minuten (in de praktijk vaak 20-30 seconden bij verwacht gedrag van de apparatuur).
In het gegeven voorbeeld van de klant C1 of klant C2 U moet minimaal drie keer een waarschuwing geven over werkzaamheden die een onderbreking in de verbinding met zich meebrengen — de eerste keer voor werkzaamheden aan een POD waarin één van zijn servers zich bevindt, de tweede keer voor de tweede en de derde keer bij het overschakelen van apparatuur voor DCI-diensten.
Overschakeling van geaggregeerde verbindingen
Waarom we het hebben over het verwachte gedrag van de apparatuur, en hoe geaggregeerde verbindingen kunnen worden omgeschakeld met minimaal verbindingonderbreking. Stel je het volgende voor:
Aan de ene kant van de link — distributieswitches van de POD — D1 en D2, ze vormen een MLAG-paar (stack, VCS-fabriek, vPC-paar), aan de andere kant twee links — Link 1 en Link 2 — zijn verbonden in een MLAG-paar van oude aggregatieswitches. AAan de kant van de switches D is een geaggregeerde interface met de naam Port-channel A, aan de kant van de aggregatieswitches A — een geaggregeerde interface met de naam Port-channel D.
Geaggregeerde interfaces gebruiken LACP in hun werking, dat wil zeggen, de switches aan beide zijden wisselen regelmatig LACPDU-pakketten uit over beide links om te controleren of de links:
- operationeel;
- verbonden zijn in hetzelfde paar apparaten aan de andere kant.
Bij het uitwisselen van pakketten wordt een waarde verzonden in het pakket, system-id, die het apparaat aangeeft waar deze links zijn aangesloten. Voor een MLAG-paar (stack, fabriek, enz.) is de system-id waarde voor de apparaten die de geaggregeerde interface vormen hetzelfde. De switch D1 stuurt naar Link 1 de waarde system-id D, en de switch D2 stuurt naar Link 2 de waarde system-id D.
Switches A1 en A2 analyseren de LACPDU-pakketten, ontvangen via een van de Po D-interfaces, en controleren op overeenstemming van de system-id daarin. Als de ontvangen system-id via een bepaalde link ineens verschilt van de huidige werkende waarde, dan wordt deze link verwijderd uit de geaggregeerde interface totdat de situatie is hersteld. Op dit moment hebben we aan de kant van de switches D de huidige waarde van system-id van de LACP-partner — A, en aan de kant van de switches A — de huidige waarde van system-id van de LACP-partner — D.
Indien nodig kunnen we de geaggregeerde interface op twee verschillende manieren overschakelen:
Methode 1 — Eenvoudig
Beide links uitschakelen op switches A.Op dat moment werkt de geaggregeerde verbinding niet.
Beide links om de beurt inschakelen op de switches N, dan zal de parameterovereenkomst van LACP opnieuw plaatsvinden, het vormen van de interface Po D op de switches N en het doorgeven van de waarde op de links system-id N.
Methode 2 — Minimalisatie van de onderbreking
Ontkoppel Link 2 van switch A2. Het verkeer tussen A en D zal gewoon doorgaan via een van de links die in de geaggregeerde interface blijven.
Sluit Link 2 aan op switch N2. Op de switch N is de geaggregeerde interface Po DN, en de switch N2 begint te verzenden in LACPDU system-id N. Op dit punt kunnen we al controleren of de switch N2 correct werkt met de transceiver die wordt gebruikt voor Link 2, dat de aansluitpoort in de status Up, en dat er geen fouten optreden op de aansluitpoort bij het verzenden van LACPDU.
Maar het feit dat de switch D2 voor de geaggregeerde interface Po A aan de kant van Link 2 een andere system-id N ontvangt dan de huidige werkende system-id A, voorkomt dat de switches D toevoegen Link 2 aan de geaggregeerde interface. Po ADe switch N kan niet aan de slag Link 2 omdat hij geen bevestiging van werkbaarheid van de LACP-partner van de switch ontvangt. D2Het verkeer wordt dus niet verzonden via Link 2 .
En nu schakelen we Link 1 uit van switch A1, waardoor we de switches A en D van de werkende geaggregeerde interface beroven. Zo verdwijnt er aan de kant van de switch D de huidige werkende waarde van de system-id voor de interface. Po A.
Dit stelt de switches in staat D en N om te onderhandelen over de uitwisseling van system-id A-N op de interfaces Po A en Po DN, zodat verkeer via de link begint te stromen Link 2. De onderbreking bedraagt in dit geval, in de praktijk, tot 2 seconden.
En nu schakelen we Link 1 weer naar switch N1, waardoor de capaciteit en het niveau van reservering voor de interfaces hersteld worden. Po A en Po DN. Aangezien bij het aansluiten van deze link de huidige waarde van de system-id aan geen van beide zijden verandert, is er geen onderbreking.
Extra links
Maar de overschakeling kan worden uitgevoerd zonder de aanwezigheid van een ingenieur op het moment van overschakeling. Hiervoor moeten we van tevoren extra links tussen de distributieswitches D en de nieuwe aggregatieswitches aanleggen. N.
We leggen nieuwe links aan tussen de aggregatieswitches N en de distributieswitches van alle POD's. Dit vereist het bestellen en aanleggen van extra patchkabels en de installatie van extra transceivers zowel in N, alsook in D. We kunnen dit doen, omdat we in de switches D van elke POD vrije poorten hebben (of we maken ze vooraf vrij). Uiteindelijk is elke POD fysiek verbonden met twee links naar de oude switches A en de nieuwe switches N.
Op de switch D zijn twee geaggregeerde interfaces gevormd — Po A met links Link 1 en Link 2, en Po N — met links Link N1 en Link N2. In dit stadium controleren we de juistheid van de aansluiting van de interfaces en links, de niveaus van de optische signalen aan beide uiteinden van de links (door middel van DDM-informatie van de switches), we kunnen zelfs de werking van de link onder belasting controleren of de status van de optische signalen en de temperatuur van de transceivers gedurende een paar dagen monitoren.
Het verkeer wordt nog steeds via de interface verzonden Po A, terwijl de interface Po N geen verkeer heeft. De instellingen op de interfaces zijn ongeveer als volgt:
Interface Port-channel A
Switchport mode trunk
Switchport allowed vlan C1, C2
Interface Port-channel N
Switchport mode trunk
Switchport allowed vlan noneSwitches D ondersteunen doorgaans sessiegewijze configuratiewijzigingen, en er worden switchmodellen gebruikt die deze functionaliteit hebben. Zodoende kunnen we de instellingen van de interfaces Po A en Po N in één keer wijzigen:
Configure session
Interface Port-channel A
Switchport allowed vlan none
Interface Port-channel N
Switchport allowed vlan C1, C2
CommitDan zal de configuratiewijziging vrij snel plaatsvinden, en de onderbreking zal in de praktijk niet meer dan 5 seconden bedragen.
Deze methode stelt ons in staat om alle voorbereidende werkzaamheden vooraf uit te voeren, alle nodige controles uit te voeren, werkzaamheden met de betrokken partijen af te stemmen, acties voor de uitvoering van het werk gedetailleerd te voorspellen, zonder creatief te hoeven zijn, wanneer 'alles niet gaat zoals gepland', en om een terugkeer naar de vorige configuratie in de hand te hebben. Het werk volgens dit plan wordt uitgevoerd door de netingenieur zonder dat de data center engineer, die fysiek de schakelingen uitvoert, aanwezig is.
Wat ook belangrijk is bij deze methode van schakelen — alle nieuwe links zijn al van tevoren in de monitoring geplaatst. Fouten, het aansluiten van links in de aggregatie, de belasting van links — alle noodzakelijke informatie is al in het monitoringsysteem ingevoerd, en dit is al op de kaarten weergegeven.
D-Day
POD
We hebben de minst pijnlijke en het minst kwetsbare pad gekozen voor de klanten met de minste kans op 'iets is misgelopen' bij de schakelingen met extra links. Op deze manier hebben we alle POD's binnen een paar nachten op de nieuwe aggregatie switches omgezet.
Maar het resteert om de apparatuur die DCI-diensten biedt om te schakelen.
L2
In het geval van apparatuur die L2-connectiviteit biedt, konden we geen soortgelijke werkzaamheden uitvoeren met aanvullende links. Daar zijn minimaal twee redenen voor:
- De afwezigheid van vrije poorten met de benodigde snelheid op de VXLAN-switches.
- Het ontbreken van functionaliteit voor sessieconfiguratie-wijzigingen op de VXLAN-switches.
We hebben ervoor gekozen om de links 'één voor één' om te schakelen met alleen een onderbreking voor de tijd die nodig is om de nieuwe paar system-id af te stemmen, omdat we 100% zekerheid dat de procedure correct zou verlopen niet hadden, en de test in het laboratorium toonde aan dat, als 'er iets misgaat', we nog steeds verbinding onderbrekingen krijgen, wat het ergste is — niet alleen voor klanten die L2-connectiviteit hebben met andere datacenters, maar voor alle klanten van dit datacenter.
We hebben van tevoren wervingswerkzaamheden uitgevoerd voor de overstap van L2-kanalen, daarom was het aantal klanten dat door de werkzaamheden op de VXLAN-switches werd getroffen al enkele malen kleiner dan een jaar geleden. Uiteindelijk hebben we besloten om een verbinding onderbreking voor de L2-connectiviteitsdienst te accepteren, op voorwaarde dat we de normale werking van lokale netwerkdiensten in één datacenter behouden. Bovendien voorziet de SLA voor deze dienst in de mogelijkheid om geplande werkzaamheden met onderbreking uit te voeren.
L3
Waarom hebben we iedereen aanbevolen over te stappen op L3VPN bij het aanbieden van DCI-diensten? Een van de redenen is de mogelijkheid om werkzaamheden aan een van de routers die deze dienst bieden uit te voeren door het niveau van reserve tot N+0 te verlagen, zonder verbindingonderbreking.
Laten we de diagram van de dienstverlening nader bekijken. In deze dienst gaat het L2-segment van de klantservers alleen naar de L3VPN-routers van Selectel. Op de routers wordt het klantnetwerk beëindigd.
Elke server van de klant, bijvoorbeeld, S2 en S3 in het bovenstaande schema, heeft zijn eigen privé- IP-adressen — 10.0.0.2/24 voor server S2 en 10.0.0.3/24 voor server S3. De adressen 10.0.0.252/24 en 10.0.0.253/24 zijn toegewezen vanuit Selectel aan de routers L3VPN-1 en L3VPN-2, respectievelijk. Het IP-adres 10.0.0.254/24 is het VRRP VIP-adres op de routers van Selectel.
Meer informatie over de L3VPN-dienst kan worden op onze blog.
Tot het moment van overschakelen zag alles er ongeveer uit zoals in het schema:
Twee routers L3VPN-1 en L3VPN-2 waren verbonden met de oude aggregatieswitch A. De master voor het VRRP VIP-adres 10.0.0.254 is de router L3VPN-1. Hij heeft een hogere prioriteit ingesteld voor dit adres dan de router. L3VPN-2.
eenheid 1006 {
beschrijving C2;
vlan-id 1006;
gezin inet {
adres 10.0.0.252/24 {
vrrp-groep 1 {
prioriteit 200;
virtueel-adres 10.100.0.254;
preempt {
hold-tijd 120;
}
accept-data;
}
}
}
}Server S2 voor verbinding met servers op andere locaties gebruikt gateway 10.0.0.254. Hierdoor heeft het loskoppelen van de L3VPN-2 router (natuurlijk na deze eerst uit het MPLS-domein te ontkoppelen) geen invloed op de connectiviteit van de servers van de klant. Op dat moment daalt gewoon het niveau van de redundantie van de configuratie.
Daarna kunnen we de router opnieuw aansluiten. L3VPN-2 aan een paar switches. N. Verbind de links, verwissel de transceivers. De logische interfaces van de router, waarvan de werking van de klantdiensten afhankelijk is, zijn uitgeschakeld totdat we bevestigen dat alles naar behoren functioneert.
Na de controles van de links, transceivers, signaalniveaus en foutniveaus op de interfaces wordt de router in gebruik genomen, maar nu verbonden met een nieuw paar switches.
Daarna verlagen we de VRRP-prioriteit van de L3VPN-1 router, en het VIP-adres 10.0.0.254 wordt overgedragen aan de L3VPN-2 router. Deze werkzaamheden worden ook uitgevoerd zonder onderbreking van de verbinding.
Het verplaatsen van het VIP-adres 10.0.0.254 naar de router L3VPN-2 maakt het mogelijk om de router L3VPN-1 zonder onderbreking van de verbinding voor de klant uit te schakelen en deze al aan te sluiten op een nieuwe paar aggregatie switches. N.
Of we de VRRP VIP terugkeren naar de L3VPN-1 router is een andere vraag, en zelfs als we dat doen, gebeurt dit zonder onderbreking van de verbinding.
Total
Na al deze acties hebben we daadwerkelijk de aggregatie switches in een van onze datacenters vervangen, waarbij we de onderbrekingen voor onze klanten tot een minimum hebben beperkt.
Daarna blijft er alleen nog de demontage over. Demontage van de oude switches, demontage van de oude links tussen de switches A en D, demontage van de transceivers van deze links, correctie van de monitoring, correctie van het netwerkschema in de documentatie en monitoring.
Switches, transceivers, patchkabels, AOC, DAC die na de schakelingen overblijven, kunnen we gebruiken in andere projecten of bij andere soortgelijke schakelingen.
‘Natasja, we hebben alles overgeschakeld!’
Bron: habr.com
