Het verhaal van één schakelaar

In onze lokale netwerkaggregatie hadden we zes paar Arista DCS-7050CX3-32S-switches en één paar Brocade VDX 6940-36Q-switches. Het is niet zo dat we overdreven gespannen waren door de Brocade-switches in dit netwerk, ze werken en voeren hun functies uit, maar we waren de volledige automatisering van sommige acties aan het voorbereiden, en we hadden deze mogelijkheden niet op deze switches. Ik wilde ook overstappen van 40GE-interfaces naar de mogelijkheid om 100GE te gebruiken om een ​​reserve te maken voor de komende 2-3 jaar. Daarom hebben we besloten om Brocade te veranderen in Arista.

Deze switches zijn LAN-aggregatieswitches voor elk datacenter. Hierop zijn distributieschakelaars (het tweede aggregatieniveau) rechtstreeks aangesloten, die al Top-of-Rack lokale netwerkschakelaars in racks met servers assembleren.

Elke server is verbonden met één of twee toegangsschakelaars. Toegangsschakelaars zijn verbonden met een paar distributieschakelaars (twee distributieschakelaars en twee fysieke verbindingen van de toegangsschakelaar naar verschillende distributieschakelaars worden gebruikt voor redundantie).

Elke server kan door een eigen client worden gebruikt, zodat de client een apart VLAN krijgt toegewezen. Hetzelfde VLAN wordt vervolgens geregistreerd op een andere server van deze client in een willekeurig rack. Het datacenter bestaat uit meerdere van dergelijke rijen (POD's), elke rij racks heeft zijn eigen distributieschakelaars. Vervolgens worden deze distributieschakelaars verbonden met aggregatieschakelaars.

Klanten kunnen een server in elke rij bestellen; het is onmogelijk om vooraf te voorspellen dat de server in een specifieke rij in een specifiek rack zal worden toegewezen of geïnstalleerd. Daarom staan ​​er in elk datacenter ongeveer 2500 VLAN's op aggregatieswitches.

Apparatuur voor DCI (Data-Center Interconnect) is aangesloten op aggregatieschakelaars. Het kan bedoeld zijn voor L2-connectiviteit (een paar switches die een VXLAN-tunnel vormen naar een ander datacenter) of voor L3-connectiviteit (twee MPLS-routers).

Zoals ik al schreef, was het noodzakelijk om de centrale aggregatieschakelaars te vervangen om de processen van het automatiseren van de configuratie van services op apparatuur in één datacenter te verenigen. We installeerden nieuwe schakelaars naast de bestaande, combineerden ze tot een MLAG-paar en begonnen ons voor te bereiden op het werk. Ze werden onmiddellijk verbonden met bestaande aggregatieswitches, zodat ze over een gemeenschappelijk L2-domein beschikten voor alle client-VLAN's.

Circuitdetails

Laten we voor meer informatie de oude aggregatieschakelaars een naam geven A1 и A2, nieuw - N1 и N2. Laten we ons dat voorstellen POD1 и POD4 servers van één client worden gehost С1,Het client-VLAN wordt blauw aangegeven. Deze client gebruikt de L2-connectiviteitsservice met een ander datacenter, dus het VLAN wordt naar een paar VXLAN-switches gevoerd.

klant С2 host servers in POD2 и POD3,Het client-VLAN wordt aangegeven in donkergroen. Deze client gebruikt ook een connectiviteitsservice met een ander datacenter, maar L3, dus het VLAN wordt gevoed naar een paar L3VPN-routers.

We hebben client-VLAN's nodig om te begrijpen in welke fasen van de vervangingswerkzaamheden wat er gebeurt, waar de communicatieonderbreking plaatsvindt en wat de duur ervan kan zijn. Het STP-protocol wordt in dit schema niet gebruikt, omdat de breedte van de boom daarvoor in dit geval groot is en de convergentie van het protocol exponentieel groeit met het aantal apparaten en de verbindingen daartussen.

Alle apparaten die via dubbele links zijn verbonden, vormen een stack, MLAG-paar of VCS Ethernet-fabric. Voor een paar L3VPN-routers worden dergelijke technologieën niet gebruikt, omdat er geen behoefte is aan L2-redundantie; het is voldoende dat ze L2-connectiviteit met elkaar hebben via aggregatieschakelaars.

Implementatiemogelijkheden

Bij het analyseren van opties voor verdere evenementen realiseerden we ons dat er verschillende manieren zijn om dit werk uit te voeren. Van een wereldwijde pauze op het hele lokale netwerk, tot kleine pauzes van letterlijk 1-2 seconden in delen van het netwerk.

Netwerk, stop! Schakelaars, vervang ze!

De eenvoudigste manier is natuurlijk om een ​​wereldwijde communicatieonderbreking op alle POD's en alle DCI-services aan te kondigen en alle links van de switches te verwisselen А naar schakelaars N.

Afgezien van de onderbreking, waarvan we het tijdstip niet betrouwbaar kunnen voorspellen (ja, we kennen het aantal links, maar we weten niet hoe vaak er iets mis zal gaan - van een kapotte patchkabel of beschadigde connector tot een defecte poort of transceiver ), kunnen we nog steeds niet op voorhand voorspellen of de lengte van de patchkabels, DAC, AOC, aangesloten op de oude schakelaars A, voldoende zal zijn om ze te bereiken naar de nieuwe schakelaars N, hoewel ze ernaast staan, maar nog steeds een beetje te de zijkant, en of dezelfde transceivers /DAC/AOC van Brocade-switches naar Arista-switches zullen werken.

En dit alles onder zware druk van klanten en technische ondersteuning (“Natasha, sta op! Natasha, alles werkt daar niet! Natasha, we hebben de technische ondersteuning al aangeschreven, eerlijk gezegd! Natasha, ze hebben alles al laten vallen ! Natasha, hoeveel meer hebben we niet, zal het werken? Natasha, wanneer zal het werken?!"). Zelfs ondanks de vooraf aangekondigde pauze en kennisgeving aan klanten is een toestroom van verzoeken op zo'n moment gegarandeerd.

Stop, 1-2-3-4!

Wat als we geen wereldwijde doorbraak aankondigen, maar eerder een reeks kleine communicatie-onderbrekingen voor POD- en DCI-diensten? Schakel tijdens de eerste pauze over op schakelaars N alleen POD1, in de tweede - over een paar dagen - POD2, dan nog een paar dagen POD3Verder POD 4…[N], vervolgens VXLAN-switches en vervolgens L3VPN-routers.

Met deze organisatie van schakelwerkzaamheden verminderen we de complexiteit van eenmalige werkzaamheden en vergroten we onze tijd om problemen op te lossen als er plotseling iets misgaat. POD 1 blijft na het schakelen verbonden met andere POD's en DCI's. Maar het werk zelf duurt lang; tijdens dit werk in het datacenter is een ingenieur nodig om de omschakeling fysiek uit te voeren, en tijdens het werk (en dergelijke werkzaamheden worden in de regel 's nachts uitgevoerd vanaf 2 uur) tot 5 uur) is de aanwezigheid van een online netwerkingenieur met een redelijk hoog kwalificatieniveau vereist. Maar dan krijgen we korte communicatieonderbrekingen; in de regel kan er worden gewerkt in een interval van een half uur met een pauze van maximaal 2 minuten (in de praktijk vaak 20-30 seconden met het verwachte gedrag van de apparatuur).

In de voorbeeldklant С1 of cliënt С2 u zult minstens drie keer moeten waarschuwen voor werk met een communicatieonderbreking - de eerste keer om werkzaamheden uit te voeren aan één POD, waarin een van zijn servers zich bevindt, de tweede keer - voor de tweede en de derde keer - wanneer schakelapparatuur voor DCI-diensten.

Schakelen tussen geaggregeerde communicatiekanalen

Waarom hebben we het over het verwachte gedrag van apparatuur, en hoe geaggregeerde kanalen kunnen worden geschakeld terwijl de communicatieonderbreking wordt geminimaliseerd? Laten we ons het volgende beeld voorstellen:

Aan de ene kant van de link bevinden zich POD-distributieschakelaars - D1 и D2, ze vormen een MLAG-paar met elkaar (stack, VCS-fabriek, vPC-paar), aan de andere kant zijn er twee links - Link 1 и Link 2 - opgenomen in het MLAG-paar oude aggregatieschakelaars А. Aan de schakelzijde D een geaggregeerde interface met de naam Havenkanaal A, aan de kant van aggregatieschakelaars А - geaggregeerde interface met de naam Havenkanaal D.

Geaggregeerde interfaces gebruiken LACP bij hun werking, dat wil zeggen dat schakelaars aan beide kanten regelmatig LACPDU-pakketten op beide links uitwisselen om ervoor te zorgen dat de links:

• werken;
• inbegrepen in één paar apparaten aan de externe kant.

Bij het uitwisselen van pakketten draagt ​​het pakket de waarde systeem-id, waarbij het apparaat wordt aangegeven waarop deze links zijn opgenomen. Voor een MLAG-paar (stack, fabriek, enz.) is de systeem-ID-waarde voor de apparaten die de geaggregeerde interface vormen hetzelfde. Schakelaar D1 stuurt naar Link 1 betekenis systeem-ID D, en schakel D2 stuurt naar Link 2 betekenis systeem-ID D.

schakelaars A1 и A2 analyseer LACPDU-pakketten die via één Po D-interface zijn ontvangen en controleer of de systeem-ID daarin overeenkomt. Als het systeem-ID dat via een link wordt ontvangen plotseling verschilt van de huidige bedrijfswaarde, dan wordt deze link uit de geaggregeerde interface verwijderd totdat de situatie is gecorrigeerd. Nu aan onze schakelkant D huidige systeem-ID-waarde van de LACP-partner - Aen aan de schakelaarzijde А — huidige systeem-ID-waarde van de LACP-partner — D.

Als we de geaggregeerde interface moeten wijzigen, kunnen we dit op twee verschillende manieren doen:

Methode 1 - Eenvoudig
Schakel beide koppelingen van schakelaars A uit. In dit geval werkt het geaggregeerde kanaal niet.

Sluit beide links één voor één aan op de schakelaars N, dan zullen de LACP-bedrijfsparameters opnieuw worden onderhandeld en zal de interface worden gevormd Peul op schakelaars N en overdracht van waarden op links systeem-id N.

Methode 2 - Minimaliseer onderbrekingen
Koppel verbinding 2 los van schakelaar A2. Tegelijkertijd verkeer tussen А и D zal gewoon via een van de links worden verzonden, die deel blijft uitmaken van de geaggregeerde interface.

Sluit Link 2 aan op schakelaar N2. Op de schakelaar N de geaggregeerde interface is al geconfigureerd Po DN, en schakel N2 zal beginnen met zenden naar LACPDU systeem-id N. In dit stadium kunnen we al controleren of de schakelaar N2 werkt correct met de zendontvanger waarvoor gebruikt wordt Link 2, dat de verbindingspoort de status heeft bereikt Up, en dat er geen fouten optreden op de verbindingspoort bij het verzenden van LACPDU's.

Maar het feit dat de schakelaar D2 voor geaggregeerde interface Po A van de zijkant Link 2 ontvangt een systeem-id N-waarde die afwijkt van de huidige besturingssysteem-id A-waarde, staat geen schakelaars toe D invoeren Link 2 onderdeel van de geaggregeerde interface Po A. Schakelaar N kan niet binnenkomen Link 2 in gebruik wordt genomen, omdat het geen bevestiging van de werking ontvangt van de LACP-partner van de switch D2. Het resulterende verkeer is Link 2 er niet doorheen komen.

En nu schakelen we Link 1 uit van schakelaar A1, waardoor de schakelaars worden beroofd А и D werkende geaggregeerde interface. Aan de schakelkant dus D de huidige werkende systeem-ID-waarde voor de interface verdwijnt Po A.

Hierdoor zijn schakelaars mogelijk D и N ga akkoord met het uitwisselen van systeem-ID EEN op interfaces Po A и Po DN, zodat het verkeer langs de link begint te worden verzonden Link 2. De pauze bedraagt ​​in dit geval in de praktijk maximaal 2 seconden.

En nu kunnen we eenvoudig Link 1 omschakelen naar N1, waardoor de capaciteit en het niveau van interfaceredundantie worden hersteld Po A и Po DN. Omdat wanneer deze link wordt aangesloten, de huidige systeem-ID-waarde aan geen van beide kanten verandert, is er geen onderbreking.

Extra koppelingen

Maar de overstap kan worden uitgevoerd zonder de aanwezigheid van een monteur op het moment van de overstap. Om dit te doen, zullen we vooraf extra koppelingen tussen distributieschakelaars moeten leggen D en nieuwe aggregatieschakelaars N.

We leggen nieuwe verbindingen tussen aggregatieschakelaars N en distributieschakelaars voor alle POD's. Dit vereist het bestellen en aanleggen van extra patchkabels, en het installeren van extra transceivers zoals in Nen D. We kunnen dit doen omdat in onze schakelaars D Elke POD heeft vrije poorten (of we maken ze vooraf vrij). Hierdoor is elke POD fysiek via twee links verbonden met de oude schakelaars A en met de nieuwe schakelaars N.

Op de schakelaar D er zijn twee samengevoegde interfaces gevormd - Po A met koppelingen Link 1 и Link 2En Po N - met koppelingen Verbinding N1 и Verbinding N2. In dit stadium controleren we de juiste aansluiting van interfaces en links, de niveaus van optische signalen aan beide uiteinden van de links (via DDM-informatie van de schakelaars), we kunnen zelfs de prestaties van de link onder belasting controleren of de status van de link controleren optische signalen en transceivertemperaturen gedurende een paar dagen.

Verkeer wordt nog steeds via de interface verzonden Po Aen de interface Po N kost geen verkeer. 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 none

D-switches ondersteunen in de regel sessiegebaseerde configuratiewijzigingen; er worden switchmodellen gebruikt die deze functionaliteit hebben. We kunnen dus de instellingen van de Po A- en Po N-interfaces in één stap wijzigen:

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

Dan zal de configuratiewijziging snel genoeg plaatsvinden en zal de pauze in de praktijk niet langer dan 5 seconden duren.

Met deze methode kunnen we al het voorbereidende werk vooraf voltooien, alle noodzakelijke controles uitvoeren, het werk coördineren met de deelnemers aan het proces, in detail de acties voor de productie van werk voorspellen, zonder creatieve vluchten als “alles fout ging ”, en een plan bij de hand hebben om terug te keren naar de vorige configuratie. Werkzaamheden volgens dit plan worden uitgevoerd door een netwerkengineer zonder dat er ter plaatse een datacenterengineer aanwezig is die fysiek de schakelingen uitvoert.

Wat ook belangrijk is bij deze manier van schakelen is dat alle nieuwe koppelingen vooraf al worden gemonitord. Fouten, opname van links in het apparaat, laden van links - alle benodigde informatie staat al in het monitoringsysteem en dit is al op de kaarten getekend.

D-Day

POD

We kozen voor het minst pijnlijke overstappad voor klanten en het minst risicovolle ‘er ging iets mis’-scenario’s met extra koppelingen. Daarom hebben we binnen een paar nachten alle POD's overgezet naar nieuwe aggregatieschakelaars.

Maar het enige dat overblijft is het omschakelen van de apparatuur die DCI-diensten levert.

L2

In het geval van apparatuur die L2-connectiviteit biedt, konden we soortgelijk werk niet uitvoeren met extra links. Daar zijn minstens twee redenen voor:

• Gebrek aan vrije poorten met de vereiste snelheid op VXLAN-switches.
• Gebrek aan functionaliteit voor het wijzigen van sessieconfiguratie op VXLAN-switches.

We hebben de koppelingen niet “één voor één” gewisseld met alleen een pauze terwijl we het eens waren over een nieuw systeem-ID-paar, omdat we er niet 100% zeker van waren dat de procedure correct zou plaatsvinden, en een test in het laboratorium toonde aan dat in Als er ‘iets misgaat’, krijgen we nog steeds een verbindingsonderbreking, en het ergste is niet alleen voor klanten die L2-connectiviteit hebben met andere datacenters, maar in het algemeen voor alle klanten van dit datacenter.

We hebben van tevoren propagandawerk uitgevoerd over de overgang van L2-kanalen, dus het aantal klanten dat werd getroffen door werkzaamheden aan VXLAN-switches was al meerdere malen minder dan een jaar geleden. Als gevolg hiervan hebben we besloten de communicatie via de L2-verbindingsdienst te onderbreken, op voorwaarde dat we de normale werking van lokale netwerkdiensten in één datacenter behouden. Daarnaast voorziet de SLA voor deze dienst in de mogelijkheid om geplande werkzaamheden met onderbrekingen uit te voeren.

L3

Waarom hebben we iedereen aangeraden om over te stappen op L3VPN bij het organiseren van DCI-diensten? Een van de redenen is de mogelijkheid om werkzaamheden uit te voeren op een van de routers die deze dienst leveren, door simpelweg het redundantieniveau terug te brengen naar N+0, zonder de communicatie te onderbreken.

Laten we het dienstverleningsschema eens nader bekijken. In deze service gaat het L2-segment van alleen clientservers naar L3VPN Selectel-routers. Het clientnetwerk wordt afgesloten op routers.

Elke clientserver, b.v. S2 и S3 in het bovenstaande diagram hebben hun eigen privé-IP-adressen - 10.0.0.2/24 op server S2 и 10.0.0.3/24 op server S3. Adressen 10.0.0.252/24 и 10.0.0.253/24 toegewezen door Selectel aan routers L3VPN-1 и L3VPN-2respectievelijk. IP adres 10.0.0.254/24 is een VRRP VIP-adres op Selectel-routers.

U kunt meer leren over de L3VPN-service lezen op onze blog.

Vóór de overstap zag alles er ongeveer uit zoals in het diagram:

Twee routers L3VPN-1 и L3VPN-2 waren aangesloten op de oude aggregatieschakelaar А. De master voor VRRP VIP-adres 10.0.0.254 is de router L3VPN-1. Het heeft een hogere prioriteit voor dit adres dan de router 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;
            }
        }
    }
}

De S2-server gebruikt gateway 10.0.0.254 om te communiceren met servers op andere locaties. Het loskoppelen van de L3VPN-2-router van het netwerk (uiteraard als deze eerst wordt losgekoppeld van het MPLS-domein) heeft dus geen invloed op de connectiviteit van de servers van de klant. Op dit punt wordt het redundantieniveau van het circuit eenvoudigweg verlaagd.

Hierna kunnen we de router veilig opnieuw aansluiten L3VPN-2 naar een paar schakelaars N. Leg verbindingen, verander zendontvangers. De logische interfaces van de router, waarvan de werking van clientservices afhankelijk is, worden uitgeschakeld totdat wordt bevestigd dat alles naar behoren functioneert.

Na controle van de links, transceivers, signaalniveaus en foutniveaus op de interfaces wordt de router in gebruik genomen, maar al verbonden met een nieuw paar switches.

Vervolgens verlagen we de VRRP-prioriteit van de L3VPN-1-router en wordt het VIP-adres 10.0.0.254 verplaatst naar de L3VPN-2-router. Ook deze werkzaamheden worden uitgevoerd zonder onderbreking van de communicatie.

VIP-adres 10.0.0.254 overbrengen naar de router L3VPN-2 Hiermee kunt u de router uitschakelen L3VPN-1 zonder onderbreking van de communicatie voor de klant en verbind deze met een nieuw paar aggregatieschakelaars N.

Of VRRP VIP al dan niet moet worden teruggestuurd naar de L3VPN-1-router is een andere vraag, en zelfs als het wordt geretourneerd, gebeurt dit zonder de verbinding te onderbreken.

In totaal

Na al deze stappen hebben we feitelijk de aggregatieschakelaars in een van onze datacenters vervangen, terwijl we de verstoring voor onze klanten tot een minimum hebben beperkt.

Het enige dat overblijft is demontage. Demontage van oude schakelaars, demontage van oude verbindingen tussen schakelaars A en D, demontage van transceivers van deze verbindingen, correctie van monitoring, correctie van netwerkdiagrammen in documentatie en monitoring.

We kunnen schakelaars, transceivers, patchkabels, AOC en DAC gebruiken die overblijven na het schakelen in andere projecten of voor andere soortgelijke schakelingen.

"Natasha, we hebben alles verwisseld!"

Bron: www.habr.com