I dag vil jeg fortælle dig om, hvordan ideen om at skabe et nyt internt netværk for vores virksomhed opstod og blev implementeret. Ledelsens holdning er, at du skal lave det samme fuldgyldige projekt for dig selv som for kunden. Gør vi det godt for os selv, kan vi invitere kunden og vise, hvor godt det, vi tilbyder ham, virker og virker. Derfor greb vi udviklingen af konceptet med et nyt netværk til Moskva-kontoret meget grundigt an ved at bruge hele produktionscyklussen: analyse af afdelingsbehov → valg af en teknisk løsning → design → implementering → test. Så lad os begynde.
Valg af en teknisk løsning: Mutant Sanctuary
Proceduren for at arbejde på et komplekst automatiseret system er i øjeblikket bedst beskrevet i GOST 34.601-90 "Automatiserede systemer. Stages of Creation”, så vi arbejdede efter det. Og allerede i stadierne af kravdannelse og konceptudvikling stødte vi på de første vanskeligheder. Organisationer med forskellige profiler - banker, forsikringsselskaber, softwareudviklere osv. - til deres opgaver og standarder har de brug for visse typer netværk, hvis detaljer er klare og standardiserede. Dette vil dog ikke fungere hos os.
Hvorfor?
Jet Infosystems er en stor diversificeret it-virksomhed. Samtidig er vores interne supportafdeling lille (men stolt), den sikrer funktionaliteten af grundlæggende tjenester og systemer. Virksomheden indeholder mange divisioner, der udfører forskellige funktioner: Det er flere stærke outsourcing-teams, og interne udviklere af forretningssystemer og informationssikkerhed og arkitekter af computersystemer - generelt, hvem det er. Derfor er deres opgaver, systemer og sikkerhedspolitikker også forskellige. Hvilket som forventet skabte vanskeligheder i processen med behovsanalyse og standardisering.
Her er for eksempel udviklingsafdelingen: dens medarbejdere skriver og tester kode for et stort antal kunder. Ofte er der behov for hurtigt at organisere testmiljøer, og ærligt talt er det ikke altid muligt at formulere krav til hvert projekt, efterspørge ressourcer og bygge et separat testmiljø i overensstemmelse med alle interne regler. Dette giver anledning til nysgerrige situationer: En dag kiggede din ydmyge tjener ind i udviklerværelset og fandt under bordet en ordentligt fungerende Hadoop-klynge med 20 desktops, som på uforklarlig vis var forbundet med et fælles netværk. Jeg synes ikke, det er værd at præcisere, at virksomhedens it-afdeling ikke kendte til dens eksistens. Denne omstændighed, ligesom mange andre, var ansvarlig for, at under udviklingen af projektet blev udtrykket "mutant reserve" født, der beskriver tilstanden af den langlidende kontorinfrastruktur.
Eller her er et andet eksempel. Med jævne mellemrum opstilles en testbænk i en afdeling. Dette var tilfældet med Jira og Confluence, som blev brugt i begrænset omfang af Software Development Center i nogle projekter. Efter nogen tid lærte andre afdelinger om disse nyttige ressourcer, evaluerede dem, og i slutningen af 2018 flyttede Jira og Confluence fra status som "lokale programmørers legetøj" til status som "virksomhedsressourcer." Nu skal der tildeles en ejer til disse systemer, SLA'er, adgangs-/informationssikkerhedspolitikker, backup-politikker, overvågning, regler for routing-anmodninger for at løse problemer skal defineres - generelt skal alle attributter for et fuldgyldigt informationssystem være til stede .
Hver af vores divisioner er også en inkubator, der dyrker sine egne produkter. Nogle af dem dør på udviklingsstadiet, nogle bruger vi, mens vi arbejder på projekter, mens andre slår rod og bliver til replikerede løsninger, som vi selv begynder at bruge og sælger til kunder. For hvert sådant system er det ønskeligt at have sit eget netværksmiljø, hvor det vil udvikle sig uden at forstyrre andre systemer, og på et tidspunkt kan integreres i virksomhedens infrastruktur.
Udover udvikling har vi en meget stor med mere end 500 ansatte, dannet i teams for hver kunde. De er involveret i vedligeholdelse af netværk og andre systemer, fjernovervågning, løsning af krav og så videre. Det vil sige, at SC's infrastruktur i virkeligheden er infrastrukturen for den kunde, som de arbejder med i øjeblikket. Det særlige ved at arbejde med denne del af netværket er, at deres arbejdsstationer for vores virksomhed dels er eksterne, dels interne. Derfor implementerede vi følgende tilgang til SC - virksomheden forsyner den tilsvarende afdeling med netværk og andre ressourcer, idet de betragter disse afdelingers arbejdsstationer som eksterne forbindelser (i analogi med filialer og fjernbrugere).
Motorvejsdesign: vi er operatøren (overraskelse)
Efter at have vurderet alle faldgruberne indså vi, at vi fik en teleoperatørs netværk inden for ét kontor, og vi begyndte at handle derefter.
Vi skabte et kernenetværk, ved hjælp af hvilket enhver intern, og i fremtiden også ekstern, forbruger får den nødvendige service: L2 VPN, L3 VPN eller almindelig L3 routing. Nogle afdelinger har brug for sikker internetadgang, mens andre har brug for ren adgang uden firewalls, men samtidig beskytte vores virksomhedsressourcer og kernenetværk mod deres trafik.
Vi "indgik uformelt en SLA" med hver division. I overensstemmelse hermed skal alle hændelser, der opstår, elimineres inden for en vis, på forhånd aftalt tid. Virksomhedens krav til sit netværk viste sig at være strenge. Den maksimale responstid på en hændelse i tilfælde af telefon- og e-mailfejl var 5 minutter. Tiden til at genoprette netværksfunktionaliteten under typiske fejl er ikke mere end et minut.
Da vi har et netværk af carrier-grade, kan du kun oprette forbindelse til det i nøje overensstemmelse med reglerne. Serviceenheder fastsætter politikker og leverer tjenester. De har ikke engang brug for information om forbindelserne til specifikke servere, virtuelle maskiner og arbejdsstationer. Men samtidig er der behov for beskyttelsesmekanismer, fordi ikke en enkelt forbindelse bør deaktivere netværket. Hvis der ved et uheld oprettes en sløjfe, bør andre brugere ikke bemærke dette, det vil sige, at et tilstrækkeligt svar fra netværket er nødvendigt. Enhver teleoperatør løser konstant lignende tilsyneladende komplekse problemer inden for sit kernenetværk. Det giver service til mange kunder med forskellige behov og trafik. Samtidig bør forskellige abonnenter ikke opleve gener fra andres trafik.
Derhjemme løste vi dette problem på følgende måde: vi byggede et backbone L3-netværk med fuld redundans ved hjælp af IS-IS-protokollen. Et overlejringsnetværk blev bygget oven på kernen baseret på teknologi /, ved hjælp af en routingprotokol . For at fremskynde konvergensen af routingprotokoller blev BFD-teknologi brugt.
Netværksstruktur
I test viste denne ordning sig at være fremragende - når enhver kanal eller switch er afbrudt, er konvergenstiden ikke mere end 0.1-0.2 s, et minimum af pakker går tabt (ofte ingen), TCP-sessioner rives ikke, telefonsamtaler bliver ikke afbrudt.
Underlagslag - Routing
Overlay Layer - Routing
Huawei CE6870 switches med VXLAN licenser blev brugt som distribution switches. Denne enhed har et optimalt pris/kvalitetsforhold, så du kan forbinde abonnenter med en hastighed på 10 Gbit/s og oprette forbindelse til backbone med hastigheder på 40-100 Gbit/s, afhængigt af de anvendte transceivere.
Huawei CE6870 switches
Huawei CE8850 switche blev brugt som kerne switche. Målet er at overføre trafik hurtigt og pålideligt. Ingen enheder er tilsluttet dem undtagen distributionsswitches, de ved ikke noget om VXLAN, så en model med 32 40/100 Gbps porte blev valgt, med en basislicens, der giver L3 routing og understøttelse af IS-IS og MP-BGP protokoller.
Den nederste er Huawei CE8850 kernekontakten
På designstadiet brød en diskussion ud i teamet om teknologier, der kunne bruges til at implementere en fejltolerant forbindelse til kernenetværksknudepunkter. Vores Moskva-kontor er placeret i tre bygninger, vi har 7 distributionsrum, i hver af dem blev der installeret to Huawei CE6870 distributionsafbrydere (kun adgangsafbrydere blev installeret i flere distributionsrum). Ved udviklingen af netværkskonceptet blev to redundansmuligheder overvejet:
- Konsolidering af distributionsafbrydere til en fejltolerant stak i hvert krydsforbindelsesrum. Fordele: enkelhed og nem opsætning. Ulemper: Der er en højere sandsynlighed for fejl i hele stakken, når der opstår fejl i firmwaren på netværksenheder ("hukommelseslækager" og lignende).
- Anvend M-LAG og Anycast gateway-teknologier til at forbinde enheder til distributionsswitches.
Til sidst besluttede vi os for den anden mulighed. Den er noget sværere at konfigurere, men har i praksis vist sin ydeevne og høje pålidelighed.
Lad os først overveje at tilslutte slutenheder til distributionskontakter:
Kryds
En adgangsswitch, server eller enhver anden enhed, der kræver en fejltolerant forbindelse, er inkluderet i to distributionskontakter. M-LAG-teknologi giver redundans på datalink-niveau. Det antages, at to distributionsafbrydere fremstår til det tilsluttede udstyr som én enhed. Redundans og belastningsbalancering udføres ved hjælp af LACP-protokollen.
Anycast gateway-teknologi giver redundans på netværksniveau. Et ret stort antal VRF'er er konfigureret på hver af distributionsswitcherne (hver VRF er beregnet til sine egne formål - separat for "almindelige" brugere, separat til telefoni, separat til forskellige test- og udviklingsmiljøer osv.), og i hver VRF har flere VLAN'er konfigureret. I vores netværk er distributionskontakter standardgateways for alle enheder, der er tilsluttet dem. IP-adresserne, der svarer til VLAN-grænsefladerne, er de samme for begge distributionskontakter. Trafikken ledes gennem nærmeste sporskifte.
Lad os nu se på at forbinde distributionsswitche til kernen:
Fejltolerance er tilvejebragt på netværksniveau ved hjælp af IS-IS-protokollen. Bemærk venligst, at der er en separat L3-kommunikationslinje mellem switchene med en hastighed på 100G. Fysisk er denne kommunikationslinje et direkte adgangskabel; den kan ses til højre på billedet af Huawei CE6870-switche.
Et alternativ ville være at organisere en "ærlig" fuldt tilsluttet dobbeltstjernetopologi, men som nævnt ovenfor har vi 7 krydsforbindelsesrum i tre bygninger. Hvis vi havde valgt "dobbeltstjerne"-topologien, ville vi derfor have brug for præcis dobbelt så mange "langrækkende" 40G-transceivere. Besparelserne her er meget betydelige.
Et par ord skal siges om, hvordan VXLAN og Anycast gateway-teknologier arbejder sammen. VXLAN, uden at gå i detaljer, er en tunnel til transport af Ethernet-rammer inde i UDP-pakker. Loopback-grænsefladerne på distributionsswitches bruges som destinations-IP-adressen for VXLAN-tunnelen. Hver crossover har to switches med de samme loopback-grænsefladeadresser, så en pakke kan ankomme til enhver af dem, og en Ethernet-ramme kan udtrækkes fra den.
Hvis switchen kender til destinations-MAC-adressen for den hentede ramme, vil rammen blive leveret korrekt til sin destination. For at sikre, at begge distributionskontakter installeret i samme krydsforbindelse har opdateret information om alle MAC-adresser, der "ankommer" fra adgangsswitcherne, er M-LAG-mekanismen ansvarlig for at synkronisere MAC-adressetabellerne (såvel som ARP). tabeller) på begge switches M-LAG-par.
Trafikafbalancering opnås på grund af tilstedeværelsen i underlagsnetværket af flere ruter til loopback-grænseflader af distributionsafbrydere.
I stedet for en konklusion
Som nævnt ovenfor viste netværket under test og drift høj pålidelighed (gendannelsestid for typiske fejl er ikke mere end hundreder af millisekunder) og god ydeevne - hver krydsforbindelse er forbundet til kernen med to 40 Gbit/s kanaler. Adgangsswitches i vores netværk stables og forbindes til distributionsswitches via LACP/M-LAG med to 10 Gbit/s kanaler. En stack indeholder normalt 5 switche med hver 48 porte, og op til 10 adgangsstakke er forbundet til fordelingen i hver krydsforbindelse. Således yder backbone omkring 30 Mbit/s pr. bruger selv ved den maksimale teoretiske belastning, hvilket i skrivende stund er tilstrækkeligt til alle vores praktiske applikationer.
Netværket giver dig mulighed for problemfrit at organisere parringen af alle vilkårlige tilsluttede enheder via både L2 og L3, hvilket giver fuldstændig isolering af trafik (som informationssikkerhedstjenesten kan lide) og fejldomæner (som driftsteamet kan lide).
I næste del vil vi fortælle dig, hvordan vi migrerede til det nye netværk. Bliv hængende!
Maxim Klochkov
Seniorkonsulent, Network Audit og Complex Projects Group
Network Solutions Center
"Jet infosystemer"
Kilde: www.habr.com