Hvordan vi designet og implementerte et nytt nettverk på Huawei på Moskva-kontoret, del 1

I dag skal jeg fortelle deg om hvordan ideen om å skape et nytt internt nettverk for selskapet vårt oppstod og ble implementert. Ledelsens holdning er at du må gjøre det samme fullverdige prosjektet for deg selv som for kunden. Gjør vi det bra for oss selv, kan vi invitere kunden og vise hvor godt det vi tilbyr ham fungerer og fungerer. Derfor nærmet vi oss utviklingen av konseptet med et nytt nettverk for Moskva-kontoret veldig grundig, ved å bruke hele produksjonssyklusen: analyse av avdelingsbehov → valg av en teknisk løsning → design → implementering → testing. Så la oss begynne.

Velge en teknisk løsning: Mutant Sanctuary

Prosedyren for å jobbe med et komplekst automatisert system er for tiden best beskrevet i GOST 34.601-90 "Automatiske systemer. Stages of Creation», så vi jobbet etter det. Og allerede på stadiene av kravdannelse og konseptutvikling møtte vi de første vanskelighetene. Organisasjoner med ulike profiler - banker, forsikringsselskaper, programvareutviklere, etc. - for sine oppgaver og standarder trenger de visse typer nettverk, hvis spesifikasjoner er klare og standardiserte. Dette vil imidlertid ikke fungere hos oss.

Hvorfor?

Jet Infosystems er et stort diversifisert IT-selskap. Samtidig er vår interne supportavdeling liten (men stolt), den sikrer funksjonaliteten til grunnleggende tjenester og systemer. Selskapet inneholder mange divisjoner som utfører ulike funksjoner: Dette er flere kraftige outsourcing-team, og interne utviklere av forretningssystemer, og informasjonssikkerhet, og arkitekter av datasystemer – generelt, hvem det enn er. Følgelig er deres oppgaver, systemer og sikkerhetspolicyer også forskjellige. Noe som som forventet skapte vanskeligheter i prosessen med behovsanalyse og standardisering.

Her er for eksempel utviklingsavdelingen: dens ansatte skriver og tester kode for et stort antall kunder. Ofte er det behov for å raskt organisere testmiljøer, og ærlig talt er det ikke alltid mulig å formulere krav til hvert prosjekt, etterspørre ressurser og bygge et eget testmiljø i henhold til alle interne forskrifter. Dette gir opphav til nysgjerrige situasjoner: En dag så den ydmyke tjeneren din inn i utviklerens rom og fant under bordet en skikkelig fungerende Hadoop-klynge med 20 stasjonære datamaskiner, som på uforklarlig vis var koblet til et felles nettverk. Jeg tror ikke det er verdt å presisere at selskapets IT-avdeling ikke visste om eksistensen. Denne omstendigheten, som mange andre, var ansvarlig for det faktum at under utviklingen av prosjektet ble begrepet "mutant reserve" født, som beskriver tilstanden til den langlidende kontorinfrastrukturen.

Eller her er et annet eksempel. Periodisk settes det opp en prøvebenk innenfor en avdeling. Dette var tilfellet med Jira og Confluence, som ble brukt i begrenset grad av Software Development Center i enkelte prosjekter. Etter en tid lærte andre avdelinger om disse nyttige ressursene, evaluerte dem, og på slutten av 2018 flyttet Jira og Confluence fra status som "lokale programmerers leketøy" til status som "selskapsressurser." Nå må en eier tildeles disse systemene, SLAer, tilgangs-/informasjonssikkerhetspolicyer, sikkerhetskopieringspolicyer, overvåking, regler for ruting av forespørsler for å fikse problemer må defineres - generelt må alle attributtene til et fullverdig informasjonssystem være tilstede .
Hver av våre divisjoner er også en inkubator som dyrker sine egne produkter. Noen av dem dør på utviklingsstadiet, noen bruker vi mens vi jobber med prosjekter, mens andre slår rot og blir replikerte løsninger som vi begynner å bruke selv og selger til kunder. For hvert slikt system er det ønskelig med et eget nettverksmiljø, hvor det vil utvikle seg uten å forstyrre andre systemer, og på et tidspunkt kan integreres i bedriftens infrastruktur.

I tillegg til utvikling har vi et veldig stort Service Senter med mer enn 500 ansatte, dannet i team for hver kunde. De er involvert i vedlikehold av nettverk og andre systemer, fjernovervåking, løsning av krav og så videre. Det vil si at infrastrukturen til SC faktisk er infrastrukturen til kunden som de jobber med for øyeblikket. Det særegne ved å jobbe med denne delen av nettverket er at deres arbeidsstasjoner for vårt selskap er delvis eksterne, og delvis interne. Derfor implementerte vi følgende tilnærming for SC - selskapet gir den tilsvarende avdelingen nettverk og andre ressurser, og vurderer arbeidsstasjonene til disse avdelingene som eksterne forbindelser (i analogi med filialer og eksterne brukere).

Motorveidesign: vi er operatøren (overraskelse)

Etter å ha vurdert alle fallgruvene, skjønte vi at vi fikk en teleoperatørs nettverk innenfor ett kontor, og vi begynte å handle deretter.

Vi opprettet et kjernenettverk ved hjelp av hvilket enhver intern, og i fremtiden også ekstern, forbruker får den nødvendige tjenesten: L2 VPN, L3 VPN eller vanlig L3-ruting. Noen avdelinger trenger sikker Internett-tilgang, mens andre trenger ren tilgang uten brannmurer, men samtidig beskytte bedriftens ressurser og kjernenettverk fra deres trafikk.

Vi inngikk uformelt en SLA med hver divisjon. I henhold til den skal alle hendelser som oppstår elimineres innen et visst forhåndsavtalt tidsrom. Selskapets krav til nettverket viste seg å være strenge. Maksimal responstid på en hendelse ved telefon- og e-postfeil var 5 minutter. Tiden for å gjenopprette nettverksfunksjonalitet under typiske feil er ikke mer enn ett minutt.

Siden vi har et nettverk av operatørgrad, kan du kun koble deg til det i strengt samsvar med reglene. Tjenesteenheter setter retningslinjer og tilbyr tjenester. De trenger ikke engang informasjon om tilkoblingene til spesifikke servere, virtuelle maskiner og arbeidsstasjoner. Men samtidig er det nødvendig med beskyttelsesmekanismer, fordi ikke en eneste tilkobling skal deaktivere nettverket. Hvis en sløyfe opprettes ved et uhell, bør ikke andre brukere legge merke til dette, det vil si at en tilstrekkelig respons fra nettverket er nødvendig. Enhver teleoperatør løser konstant lignende tilsynelatende komplekse problemer innenfor sitt kjernenettverk. Det gir service til mange kunder med ulike behov og trafikk. Samtidig skal ikke ulike abonnenter oppleve ulemper fra andres trafikk.
Hjemme løste vi dette problemet på følgende måte: vi bygde et L3-ryggradsnettverk med full redundans ved bruk av IS-IS-protokollen. Et overleggsnettverk ble bygget på toppen av kjernen basert på teknologi EVPN/VXLAN, ved å bruke en rutingprotokoll MP-BGP. For å få fart på konvergensen av rutingprotokoller ble BFD-teknologi brukt.

Nettverksstruktur

I tester viste dette opplegget seg å være utmerket - når en kanal eller svitsj er frakoblet, er konvergenstiden ikke mer enn 0.1-0.2 s, et minimum av pakker går tapt (ofte ingen), TCP-økter blir ikke revet, telefonsamtaler blir ikke avbrutt.

Underlagslag - Ruting

Overleggslag - Ruting

Huawei CE6870-svitsjer med VXLAN-lisenser ble brukt som distribusjonssvitsjer. Denne enheten har et optimalt pris/kvalitetsforhold, slik at du kan koble til abonnenter med en hastighet på 10 Gbit/s, og koble til ryggraden med hastigheter på 40–100 Gbit/s, avhengig av transceivere som brukes.

Huawei CE6870 brytere

Huawei CE8850-svitsjer ble brukt som kjernebrytere. Målet er å overføre trafikk raskt og pålitelig. Ingen enheter er koblet til dem bortsett fra distribusjonssvitsjer, de kan ikke noe om VXLAN, så en modell med 32 40/100 Gbps-porter ble valgt, med en grunnleggende lisens som gir L3-ruting og støtte for IS-IS og MP-BGP protokoller.

Den nederste er Huawei CE8850 kjernebryter

På designstadiet brøt det ut en diskusjon i teamet om teknologier som kunne brukes til å implementere en feiltolerant tilkobling til kjernenettverksnoder. Moskva-kontoret vårt ligger i tre bygninger, vi har 7 distribusjonsrom, i hver av disse ble det installert to Huawei CE6870 distribusjonsbrytere (kun tilgangsbrytere ble installert i flere distribusjonsrom). Ved utviklingen av nettverkskonseptet ble to redundansalternativer vurdert:

• Konsolidering av distribusjonsbrytere til en feiltolerant stabel i hvert tverrkoblingsrom. Fordeler: enkelhet og lett oppsett. Ulemper: det er større sannsynlighet for feil i hele stabelen når det oppstår feil i fastvaren til nettverksenheter ("minnelekkasjer" og lignende).
• Bruk M-LAG og Anycast gateway-teknologier for å koble enheter til distribusjonssvitsjer.

Til slutt bestemte vi oss for det andre alternativet. Den er noe vanskeligere å konfigurere, men har i praksis vist sin ytelse og høye pålitelighet.
La oss først vurdere å koble sluttenheter til distribusjonsbrytere:

Kryss

En tilgangssvitsj, server eller annen enhet som krever en feiltolerant tilkobling er inkludert i to distribusjonssvitsjer. M-LAG-teknologi gir redundans på datalinknivå. Det forutsettes at to distribusjonsbrytere vises til det tilkoblede utstyret som én enhet. Redundans og lastbalansering utføres ved hjelp av LACP-protokollen.

Anycast gateway-teknologi gir redundans på nettverksnivå. Et ganske stort antall VRF-er er konfigurert på hver av distribusjonssvitsjene (hver VRF er ment for sine egne formål - separat for "vanlige" brukere, separat for telefoni, separat for forskjellige test- og utviklingsmiljøer, etc.), og i hvert VRF har flere VLAN-er konfigurert. I vårt nettverk er distribusjonssvitsjer standard gatewayer for alle enheter som er koblet til dem. IP-adressene som tilsvarer VLAN-grensesnittene er de samme for begge distribusjonssvitsjene. Trafikken ledes gjennom nærmeste sporveksler.

La oss nå se på å koble distribusjonssvitsjer til kjernen:
Feiltoleranse er gitt på nettverksnivå ved bruk av IS-IS-protokollen. Vær oppmerksom på at det er en egen L3-kommunikasjonslinje mellom bryterne, med en hastighet på 100G. Fysisk er denne kommunikasjonslinjen en direkte tilgangskabel; den kan sees til høyre på bildet av Huawei CE6870-svitsjer.

Et alternativ ville være å organisere en "ærlig" fullt koblet dobbelstjernetopologi, men som nevnt ovenfor har vi 7 tverrforbindelsesrom fordelt på tre bygninger. Følgelig, hvis vi hadde valgt "dobbeltstjerne" -topologien, ville vi ha trengt nøyaktig dobbelt så mange "langdistanse" 40G-sendere. Besparelsene her er svært betydelige.

Noen få ord må sies om hvordan VXLAN og Anycast gateway-teknologier fungerer sammen. VXLAN, uten å gå i detaljer, er en tunnel for transport av Ethernet-rammer inne i UDP-pakker. Loopback-grensesnittene til distribusjonssvitsjer brukes som destinasjons-IP-adressen til VXLAN-tunnelen. Hver crossover har to svitsjer med samme loopback-grensesnittadresser, slik at en pakke kan ankomme hvilken som helst av dem, og en Ethernet-ramme kan trekkes ut fra den.

Hvis bryteren vet om destinasjons-MAC-adressen til den hentede rammen, vil rammen bli korrekt levert til destinasjonen. For å sikre at begge distribusjonssvitsjene installert i samme krysskobling har oppdatert informasjon om alle MAC-adresser som "kommer" fra tilgangssvitsjene, er M-LAG-mekanismen ansvarlig for å synkronisere MAC-adressetabellene (så vel som ARP). tabeller) på begge bryterne M-LAG-par.

Trafikkbalansering oppnås på grunn av tilstedeværelsen i underlagsnettverket av flere ruter til loopback-grensesnittene til distribusjonssvitsjer.

I stedet for en konklusjon

Som nevnt ovenfor, under testing og drift viste nettverket høy pålitelighet (gjenopprettingstid for typiske feil er ikke mer enn hundrevis av millisekunder) og god ytelse - hver krysskobling er koblet til kjernen med to 40 Gbit/s-kanaler. Tilgangssvitsjer i vårt nettverk er stablet og koblet til distribusjonssvitsjer via LACP/M-LAG med to 10 Gbit/s kanaler. En stack inneholder vanligvis 5 brytere med 48 porter hver, og opptil 10 aksessstabler er koblet til distribusjonen i hver krysskobling. Dermed gir ryggraden ca 30 Mbit/s per bruker selv ved maksimal teoretisk belastning, som i skrivende stund er tilstrekkelig for alle våre praktiske applikasjoner.

Nettverket lar deg sømløst organisere sammenkoblingen av alle vilkårlig tilkoblede enheter via både L2 og L3, og gir fullstendig isolasjon av trafikk (som informasjonssikkerhetstjenesten liker) og feildomener (som driftsteamet liker).

I neste del vil vi fortelle deg hvordan vi migrerte til det nye nettverket. Følg med!

Maxim Klochkov
Seniorkonsulent i nettverksrevisjons- og komplekse prosjektgruppen
Nettverksløsningssenter
"Jet infosystemer"

Kilde: www.habr.com