I vår lokale nettverksaggregering hadde vi seks par Arista DCS-7050CX3-32S-svitsjer og ett par Brocade VDX 6940-36Q-svitsjer. Det er ikke det at vi var altfor anstrengt av Brocade-svitsjene i dette nettverket, de fungerer og utfører funksjonene sine, men vi forberedte full automatisering av noen handlinger, og vi hadde ikke disse egenskapene på disse bryterne. Jeg ønsket også å bytte fra 40GE-grensesnitt til muligheten for å bruke 100GE for å gjøre en reserve for de neste 2-3 årene. Så vi bestemte oss for å endre Brocade til Arista.
Disse bryterne er LAN-aggregeringssvitsjer for hvert datasenter. Distribusjonssvitsjer (det andre aggregeringsnivået) er direkte koblet til dem, som allerede setter sammen Top-of-Rack lokale nettverkssvitsjer i rack med servere.
Hver server er koblet til en eller to tilgangssvitsjer. Tilgangssvitsjer er koblet til et par distribusjonssvitsjer (to distribusjonssvitsjer og to fysiske lenker fra tilgangssvitsjen til forskjellige distribusjonssvitsjer brukes for redundans).
Hver server kan brukes av sin egen klient, så klienten får tildelt et eget VLAN. Det samme VLAN blir deretter registrert på en annen server til denne klienten i et hvilket som helst rack. Datasenteret består av flere slike rader (PODs), hver rad med rack har sine egne distribusjonsbrytere. Deretter kobles disse distribusjonssvitsjene til aggregeringsbrytere.
Klienter kan bestille en server i hvilken som helst rad; det er umulig å forutsi på forhånd at serveren vil bli allokert eller installert i en bestemt rad i et spesifikt rack, og det er derfor det er omtrent 2500 VLAN på aggregeringssvitsjer i hvert datasenter.
Utstyr for DCI (Data-Center Interconnect) kobles til aggregeringssvitsjer. Den kan være beregnet på L2-tilkobling (et par brytere som danner en VXLAN-tunnel til et annet datasenter) eller for L3-tilkobling (to MPLS-rutere).
Som jeg allerede skrev, for å forene prosessene for å automatisere konfigurasjonen av tjenester på utstyr i ett datasenter, var det nødvendig å erstatte de sentrale aggregeringsbryterne. Vi installerte nye brytere ved siden av de eksisterende, kombinerte dem til et MLAG-par og begynte å forberede oss til arbeid. De ble umiddelbart koblet til eksisterende aggregeringssvitsjer, slik at de hadde et felles L2-domene på tvers av alle klient-VLAN.
Kretsdetaljer
For detaljer, la oss gi navn til de gamle aggregeringsbryterne A1 и A2, ny - N1 и N2. La oss forestille oss det POD 1 и POD 4 servere til én klient er vert S1, Klientens VLAN er indikert i blått. Denne klienten bruker L2-tilkoblingstjeneste med et annet datasenter, så dens VLAN mates til et par VXLAN-svitsjer.
kunde S2 vert servere i POD 2 и POD 3Klient-VLAN er merket med mørkegrønt. Denne klienten bruker også en tilkoblingstjeneste med et annet datasenter, men L3, så dens VLAN mates til et par L3VPN-rutere.
Vi trenger klient-VLAN for å forstå på hvilke stadier av erstatningsarbeidet hva som skjer, hvor kommunikasjonsavbruddet oppstår, og hva dens varighet kan være. STP-protokollen brukes ikke i denne ordningen, siden bredden på treet for den i dette tilfellet er stor, og konvergensen til protokollen vokser eksponentielt med antall enheter og koblinger mellom dem.
Alle enheter koblet sammen med doble lenker danner en stabel, MLAG-par eller VCS Ethernet-stoff. For et par L3VPN-rutere brukes ikke slike teknologier, siden det ikke er behov for L2-redundans; det er nok at de har L2-tilkobling til hverandre gjennom aggregeringssvitsjer.
Implementeringsmuligheter
Når vi analyserte alternativer for ytterligere arrangementer, innså vi at det er flere måter å utføre dette arbeidet på. Fra en global pause på hele lokalnettet, til små bokstavelig talt 1-2 sekunders pauser i deler av nettverket.
Nettverk, stopp! Brytere, bytt dem!
Den enkleste måten er selvfølgelig å erklære et globalt kommunikasjonsbrudd på alle POD-er og alle DCI-tjenester og bytte alle koblinger fra svitsjene А til brytere N.
Bortsett fra avbruddet, klokkeslettet som vi ikke kan forutsi pålitelig (ja, vi vet antall lenker, men vi vet ikke hvor mange ganger noe vil gå galt - fra en ødelagt patchledning eller skadet kontakt til en defekt port eller transceiver ), kan vi fortsatt ikke forutsi på forhånd om lengden på patchledningene, DAC, AOC, koblet til de gamle bryterne A, vil være nok til å nå dem til de nye bryterne N, selv om de står ved siden av dem, men fortsatt litt til siden, og om de samme transceiverne vil fungere /DAC/AOC fra Brocade-svitsjer til Arista-svitsjer.
Og alt dette under forhold med hardt press fra kunder og teknisk støtte ("Natasha, stå opp! Natasha, alt fungerer ikke der! Natasha, vi har allerede skrevet til teknisk støtte, ærlig talt! Natasha, de har allerede droppet alt ! Natasha, hvor mange flere har vi ikke vil det fungere? Natasha, når vil det fungere?!"). Selv til tross for forhåndsannonsert pause og varsling til klienter, er en tilstrømning av forespørsler på et slikt tidspunkt garantert.
Stopp, 1-2-3-4!
Hva om vi ikke kunngjør en global pause, men snarere en rekke små kommunikasjonsavbrudd for POD- og DCI-tjenester. Bytt til brytere i den første pausen N bare POD 1, i den andre - om et par dager - POD 2, så et par dager til POD 3Videre POD 4…[N], deretter VXLAN-svitsjer og deretter L3VPN-rutere.
Med denne organiseringen av byttearbeid reduserer vi kompleksiteten i engangsarbeid og øker tiden vår til å løse problemer hvis noe plutselig skulle gå galt. POD 1 forblir koblet til andre POD-er og DCI-er etter bytte. Men selve arbeidet trekker ut i lang tid; under dette arbeidet i datasenteret kreves det at en ingeniør fysisk utfører vekslingen, og under arbeidet (og slikt arbeid utføres som regel om natten fra 2. til kl. 5), er tilstedeværelsen av en online nettverksingeniør påkrevd på et ganske høyt kvalifikasjonsnivå. Men så får vi korte kommunikasjonsavbrudd, som regel kan arbeid utføres innen en halvtime med en pause på opptil 2 minutter (i praksis ofte 20-30 sekunder med forventet oppførsel av utstyret).
I eksempelet klient S1 eller klient S2 du må advare om arbeid med et kommunikasjonsavbrudd minst tre ganger - første gang for å utføre arbeid på en POD, der en av serverne er plassert, andre gang - på andre og tredje gang - når bytteutstyr for DCI-tjenester.
Bytte av aggregerte kommunikasjonskanaler
Hvorfor snakker vi om forventet oppførsel av utstyr, og hvordan aggregerte kanaler kan byttes samtidig som kommunikasjonsavbrudd minimeres? La oss forestille oss følgende bilde:
På den ene siden av lenken er det POD-distribusjonsbrytere - D1 и D2, de danner et MLAG-par med hverandre (stack, VCS-fabrikk, vPC-par), på den annen side er det to lenker - Link 1 и Link 2 - inkludert i MLAG-paret med gamle aggregeringsbrytere А. På brytersiden D et aggregert grensesnitt med navnet Port-kanal A, på siden av aggregeringsbrytere А - aggregert grensesnitt med navnet Port-kanal D.
Aggregerte grensesnitt bruker LACP i driften, det vil si at brytere på begge sider jevnlig utveksler LACPDU-pakker på begge koblingene for å sikre at koblingene:
- arbeidere;
- inkludert i ett par enheter på den eksterne siden.
Ved utveksling av pakker har pakken verdien system-id, som indikerer enheten der disse koblingene er inkludert. For et MLAG-par (stabel, fabrikk, etc.), er system-ID-verdien for enhetene som utgjør det aggregerte grensesnittet den samme. Bytte om D1 sender til Link 1 значение system-ID D, og bytt D2 sender til Link 2 значение system-ID D.
Brytere A1 и A2 analyser LACPDU-pakker mottatt over ett Po D-grensesnitt og sjekk om system-ID-en i dem stemmer overens. Hvis system-ID mottatt via en lenke plutselig avviker fra gjeldende driftsverdi, så fjernes denne koblingen fra det aggregerte grensesnittet til situasjonen er rettet. Nå på vår bytteside D gjeldende system-ID-verdi fra LACP-partneren - A, og på brytersiden А — gjeldende system-id-verdi fra LACP-partneren — D.
Hvis vi trenger å bytte det aggregerte grensesnittet, kan vi gjøre det på to forskjellige måter:
Metode 1 – Enkel
Deaktiver begge koblingene fra brytere A. I dette tilfellet fungerer ikke den aggregerte kanalen.
Koble begge koblingene en etter en til bryterne N, så vil LACP-driftsparameterne bli forhandlet igjen og grensesnittet dannes PoD på brytere N og overføring av verdier på lenker system-ID N.
Metode 2 - Minimer avbrudd
Koble Link 2 fra bryter A2. Samtidig er trafikk mellom А и D vil fortsette å bli overført ganske enkelt over en av koblingene, som vil forbli en del av det aggregerte grensesnittet.
Koble Link 2 til bryteren N2. På bryteren N det aggregerte grensesnittet er allerede konfigurert Po DN, og bytt N2 vil begynne å sende til LACPDU system-ID N. På dette stadiet kan vi allerede kontrollere at bryteren N2 fungerer korrekt med transceiveren som brukes til Link 2, at tilkoblingsporten har gått inn i tilstanden Up, og at det ikke oppstår feil på tilkoblingsporten ved overføring av LACPDUer.
Men det faktum at bryteren D2 for aggregert grensesnitt Po A fra siden Link 2 mottar en system-id N-verdi som er forskjellig fra gjeldende operativsystem-id A-verdi, tillater ikke brytere D skriv Link 2 del av det aggregerte grensesnittet Po A. Bytte om N kan ikke komme inn Link 2 i drift, siden den ikke mottar bekreftelse på drift fra LACP-partneren til bryteren D2. Den resulterende trafikken er Link 2 kommer ikke gjennom.
Og nå slår vi av Link 1 fra bryter A1, og dermed frata bryterne А и D fungerende aggregert grensesnitt. Altså på brytersiden D gjeldende system-id-verdi for grensesnittet forsvinner Po A.
Dette tillater brytere D и N godta å bytte system-ID AN på grensesnitt Po A и Po DN, slik at trafikken begynner å overføres langs lenken Link 2. Pausen i dette tilfellet er i praksis opptil 2 sekunder.
Og nå kan vi enkelt bytte Link 1 til bytte N1, gjenopprette kapasiteten og nivået av grensesnittredundans Po A и Po DN. Siden når denne linken er tilkoblet, endres ikke gjeldende system-id-verdi på noen av sidene, det er ingen avbrudd.
Ytterligere lenker
Men byttet kan utføres uten tilstedeværelse av en ingeniør på tidspunktet for bytte. For å gjøre dette, må vi legge ytterligere koblinger mellom distribusjonsbrytere på forhånd D og nye aggregeringsbrytere N.
Vi legger nye koblinger mellom aggregeringsbrytere N og distribusjonsbrytere for alle POD-er. Dette krever bestilling og legging av ekstra patchledninger, og installering av ekstra transceivere som i N, og i D. Vi kan gjøre dette fordi i våre brytere D Hver POD har ledige porter (eller vi forhåndsfrigjør dem). Som et resultat er hver POD fysisk koblet med to lenker til de gamle bryterne A og til de nye bryterne N.
På bryteren D to aggregerte grensesnitt har blitt dannet - Po A med lenker Link 1 и Link 2Og Po N - med lenker Link N1 и Link N2. På dette stadiet sjekker vi riktig tilkobling av grensesnitt og lenker, nivåene av optiske signaler i begge ender av koblingene (via DDM-informasjon fra bryterne), vi kan til og med sjekke ytelsen til koblingen under belastning eller overvåke tilstandene til optiske signaler og transceivertemperaturer i et par dager.
Trafikk sendes fortsatt gjennom grensesnittet Po A, og grensesnittet Po N koster ingen trafikk. Innstillingene på grensesnittene er omtrent slik:
Interface Port-channel A
Switchport mode trunk
Switchport allowed vlan C1, C2
Interface Port-channel N
Switchport mode trunk
Switchport allowed vlan noneD-svitsjer støtter som regel øktbaserte konfigurasjonsendringer; svitsjmodeller som har denne funksjonaliteten brukes. Så vi kan endre innstillingene til Po A- og Po N-grensesnittene i ett trinn:
Configure session
Interface Port-channel A
Switchport allowed vlan none
Interface Port-channel N
Switchport allowed vlan C1, C2
CommitDa vil konfigurasjonsendringen skje raskt nok, og pausen vil i praksis ikke være mer enn 5 sekunder.
Denne metoden lar oss fullføre alt det forberedende arbeidet på forhånd, utføre alle nødvendige kontroller, koordinere arbeidet med deltakerne i prosessen, forutsi i detalj handlingene for produksjon av arbeid, uten kreativitet når "alt gikk galt ,” og har en plan for å gå tilbake til forrige konfigurasjon. Arbeid i henhold til denne planen utføres av en nettverksingeniør uten tilstedeværelse av en datasenteringeniør på stedet som fysisk utfører vekslingen.
Det som også er viktig med denne byttemetoden er at alle nye lenker allerede er overvåket på forhånd. Feil, inkludering av lenker i enheten, lasting av lenker - all nødvendig informasjon er allerede i overvåkingssystemet, og dette er allerede tegnet på kartene.
D-Day
POD
Vi valgte den minst smertefulle bytteveien for klienter og de minst utsatte for "noe gikk galt" scenarier med tilleggskoblinger. Så vi byttet alle POD-er til nye aggregeringsbrytere i løpet av et par netter.
Men alt som gjenstår er å bytte utstyret som leverer DCI-tjenester.
L2
Når det gjelder utstyr som gir L2-tilkobling, var vi ikke i stand til å utføre lignende arbeid med tilleggskoblinger. Det er minst to grunner til dette:
- Mangel på ledige porter med nødvendig hastighet på VXLAN-svitsjer.
- Mangel på endringsfunksjonalitet for øktkonfigurasjon på VXLAN-svitsjer.
Vi byttet ikke lenker "en om gangen" med en pause bare mens vi ble enige om et nytt system-ID-par, siden vi ikke hadde 100 % tillit til at prosedyren ville gå riktig, og en test i laboratoriet viste at i Hvis "noe går galt", får vi fortsatt et tilkoblingsavbrudd, og det verste er ikke bare for klienter som har L2-tilkobling med andre datasentre, men generelt for alle klienter til dette datasenteret.
Vi utførte propagandaarbeid på forhånd med overgangen fra L2-kanaler, så antallet klienter som ble berørt av arbeid på VXLAN-svitsjer var allerede flere ganger for mindre enn et år siden. Som et resultat bestemte vi oss for å avbryte kommunikasjonen via L2-tilkoblingstjenesten, forutsatt at vi opprettholder normal drift av lokale nettverkstjenester i ett datasenter. I tillegg gir SLA for denne tjenesten muligheten for å utføre planlagt arbeid med avbrudd.
L3
Hvorfor anbefalte vi at alle bytte til L3VPN når de organiserer DCI-tjenester? En av grunnene er muligheten til å utføre arbeid på en av ruterne som tilbyr denne tjenesten, ganske enkelt redusere redundansnivået til N+0, uten å forstyrre kommunikasjonen.
La oss se nærmere på tjenesteleveringsordningen. I denne tjenesten går L2-segmentet fra kun klientservere til L3VPN Selectel-rutere. Klientnettverket termineres på rutere.
Hver klientserver, f.eks. S2 и S3 i diagrammet ovenfor, ha sine egne private IP-adresser - 10.0.0.2/24 på server S2 и 10.0.0.3/24 på server S3. Adresser 10.0.0.252/24 и 10.0.0.253/24 tilordnet av Selectel til rutere L3VPN-1 и L3VPN-2, henholdsvis. IP adresse 10.0.0.254/24 er en VRRP VIP-adresse på Selectel-rutere.
Du kan lære mer om L3VPN-tjenesten i bloggen vår.
Før byttet så alt omtrent ut som i diagrammet:
To rutere L3VPN-1 и L3VPN-2 ble koblet til den gamle aggregeringsbryteren А. Masteren for VRRP VIP-adresse 10.0.0.254 er ruteren L3VPN-1. Den har høyere prioritet for denne adressen enn ruteren 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-serveren bruker gateway 10.0.0.254 for å kommunisere med servere på andre steder. Å koble L3VPN-2-ruteren fra nettverket (selvfølgelig, hvis den først kobles fra MPLS-domenet) påvirker dermed ikke tilkoblingen til klientens servere. På dette tidspunktet er kretsens redundansnivå ganske enkelt redusert.
Etter dette kan vi trygt koble til ruteren igjen L3VPN-2 til et par brytere N. Legg lenker, bytt transceivere. Ruterens logiske grensesnitt, som driften av klienttjenester avhenger av, er deaktivert til det er bekreftet at alt fungerer som det skal.
Etter å ha sjekket koblingene, sender/mottakere, signalnivåer og feilnivåer på grensesnittene, settes ruteren i drift, men allerede koblet til et nytt par brytere.
Deretter senker vi VRRP-prioriteten til L3VPN-1-ruteren, og VIP-adressen 10.0.0.254 flyttes til L3VPN-2-ruteren. Disse arbeidene utføres også uten avbrudd i kommunikasjonen.
Overfører VIP-adresse 10.0.0.254 til ruteren L3VPN-2 lar deg deaktivere ruteren L3VPN-1 uten avbrudd i kommunikasjonen for klienten og koble den til et nytt par aggregeringssvitsjer N.
Hvorvidt VRRP VIP skal returneres til L3VPN-1-ruteren er et annet spørsmål, og selv om det returneres, gjøres det uten å avbryte forbindelsen.
Totalt
Etter alle disse trinnene byttet vi faktisk ut aggregeringsbryterne i et av datasentrene våre, samtidig som vi minimerte forstyrrelser for kundene våre.
Alt som gjenstår er demontering. Demontering av gamle brytere, demontering av gamle koblinger mellom brytere A og D, demontering av transceivere fra disse koblingene, korrigering av overvåking, korrigering av nettdiagrammer i dokumentasjon og overvåking.
Vi kan bruke brytere, transceivere, patch-ledninger, AOC, DAC igjen etter bytte i andre prosjekter eller for annen lignende bytting.
"Natasha, vi byttet alt!"
Kilde: www.habr.com