Kuidas me Moskva kontoris Huawei uue võrgu kavandasime ja juurutasime, 1. osa

Täna räägin teile sellest, kuidas tekkis ja ellu viidi idee luua meie ettevõttele uus sisevõrk. Juhtkonna seisukoht on, et enda jaoks tuleb teha sama täisväärtuslik projekt kui kliendi jaoks. Kui teeme seda enda jaoks hästi, saame kliendi kutsuda ja näidata, kui hästi meie pakutav talle toimib ja toimib. Seetõttu lähenesime Moskva kontori uue võrgu kontseptsiooni väljatöötamisele väga põhjalikult, kasutades kogu tootmistsüklit: osakondade vajaduste analüüs → tehnilise lahenduse valik → projekteerimine → teostus → testimine. Nii et alustame.

Tehnilise lahenduse valimine: Mutant Sanctuary

Keerulise automatiseeritud süsteemiga töötamise protseduuri kirjeldab praegu kõige paremini GOST 34.601-90 “Automatiseeritud süsteemid. Loomise etapid”, nii et selle järgi töötasimegi. Ja juba nõuete kujundamise ja kontseptsiooni väljatöötamise etapis puutusime kokku esimeste raskustega. Erineva profiiliga organisatsioonid - pangad, kindlustusfirmad, tarkvaraarendajad jne - vajavad oma ülesannete ja standardite jaoks teatud tüüpi võrke, mille spetsiifika on selge ja standardiseeritud. Meiega see aga ei tööta.

Miks?

Jet Infosystems on suur mitmekesine IT-ettevõte. Samas on meie sisemine tugiosakond väike (aga uhke), tagab põhiteenuste ja süsteemide funktsionaalsuse. Ettevõttes on palju erinevaid funktsioone täitvaid divisjone: need on mitmed võimsad allhankemeeskonnad ning ettevõttesisesed ärisüsteemide ja infoturbe arendajad ning arvutussüsteemide arhitektid – üldiselt, kes iganes see ka poleks. Sellest lähtuvalt on erinevad ka nende ülesanded, süsteemid ja turvapoliitika. Mis ootuspäraselt tekitas raskusi vajaduste analüüsi ja standardimise protsessis.

Siin on näiteks arendusosakond: selle töötajad kirjutavad ja testivad koodi suure hulga klientide jaoks. Tihtipeale on vaja testikeskkondi kiiresti korrastada ning ausalt öeldes ei ole alati võimalik iga projekti jaoks nõudeid sõnastada, ressursse nõuda ja kõikidele siseregulatsioonidele vastavat eraldi testkeskkonda ehitada. See tekitab kurioosseid olukordi: ühel päeval vaatas teie alandlik teenija arendajate tuppa ja leidis laua alt korralikult töötava 20 lauaarvutist koosneva Hadoopi klastri, mis oli seletamatult ühendatud ühisesse võrku. Ma arvan, et pole mõtet selgitada, et ettevõtte IT-osakond ei teadnud selle olemasolust. See asjaolu, nagu paljud teised, põhjustas asjaolu, et projekti väljatöötamise käigus sündis termin "mutantreserv", mis kirjeldab kaua kannatanud kontoritaristu seisukorda.

Või siin on veel üks näide. Perioodiliselt luuakse osakonna sees katsestend. See oli nii Jira ja Confluence'i puhul, mida Tarkvaraarenduskeskus kasutas mõne projekti puhul piiratud määral. Mõne aja pärast said teised osakonnad nendest kasulikest ressurssidest teada, hindasid neid ning 2018. aasta lõpus läksid Jira ja Confluence staatusest „kohalike programmeerijate mänguasi” staatusesse „ettevõtte ressursid”. Nüüd tuleb nendele süsteemidele määrata omanik, määratleda SLA-d, juurdepääsu/teabeturbe poliitikad, varunduspoliitikad, monitooring, probleemide lahendamise päringute marsruutimise reeglid - üldiselt peavad olemas olema kõik täisväärtusliku infosüsteemi atribuudid. .
Iga meie divisjon on ka inkubaator, mis kasvatab oma tooteid. Mõned neist surevad välja arendusetapis, mõnda me kasutame projektide kallal töötades, teised aga juurduvad ja muutuvad replitseeritud lahendusteks, mida hakkame ise kasutama ja klientidele müüma. Iga sellise süsteemi jaoks on soovitav oma võrgukeskkond, kus see areneb teisi süsteeme segamata ja on ühel hetkel integreeritav ettevõtte infrastruktuuri.

Lisaks arengule on meil väga suur Teeninduskeskus rohkem kui 500 töötajaga, moodustatud iga kliendi jaoks meeskondadeks. Nad on seotud võrkude ja muude süsteemide hooldamise, kaugjälgimise, pretensioonide lahendamise jms. See tähendab, et SC infrastruktuur on tegelikult selle kliendi infrastruktuur, kellega nad praegu koostööd teevad. Selle võrgulõiguga töötamise eripära on see, et meie ettevõtte tööjaamad on osaliselt välised ja osaliselt sisemised. Seetõttu rakendasime SC puhul järgmist lähenemist - ettevõte varustab vastavat osakonda võrgu- ja muude ressurssidega, pidades nende osakondade tööjaamu välisühendusteks (analoogiliselt filiaalide ja kaugkasutajatega).

Kiirtee projekteerimine: oleme operaator (üllatus)

Pärast kõigi lõksude hindamist saime aru, et saame sideoperaatori võrgu ühe kontori sisse ja hakkasime vastavalt tegutsema.

Lõime tuumikvõrgu, mille abil tagatakse igale sise- ja edaspidi ka välistarbijale vajalik teenus: L2 VPN, L3 VPN või tavaline L3 marsruutimine. Mõned osakonnad vajavad turvalist Interneti-juurdepääsu, teised aga puhast juurdepääsu ilma tulemüürideta, kuid samal ajal kaitstes meie ettevõtte ressursse ja põhivõrku nende liikluse eest.

Sõlmisime mitteametlikult iga divisjoniga SLA. Selle kohaselt tuleb kõik ettetulevad vahejuhtumid likvideerida teatud, eelnevalt kokkulepitud aja jooksul. Ettevõtte nõuded oma võrgule osutusid karmiks. Maksimaalne reageerimisaeg intsidendile telefoni ja e-posti tõrgete korral oli 5 minutit. Tüüpiliste rikete ajal võrgu funktsionaalsuse taastamiseks kuluv aeg ei ületa minut.

Kuna meil on operaatoritaseme võrk, saate sellega ühenduse luua ainult rangelt reeglite järgi. Teenindusüksused määravad poliitikad ja pakuvad teenuseid. Nad ei vaja isegi teavet konkreetsete serverite, virtuaalmasinate ja tööjaamade ühenduste kohta. Kuid samal ajal on vaja kaitsemehhanisme, sest ükski ühendus ei tohiks võrku keelata. Kui silmus kogemata luuakse, ei tohiks teised kasutajad seda märgata, see tähendab, et võrgult on vaja adekvaatset vastust. Iga sideoperaator lahendab oma põhivõrgus pidevalt sarnaseid näiliselt keerukaid probleeme. See pakub teenust paljudele erinevate vajaduste ja liiklusega klientidele. Samal ajal ei tohiks erinevad abonendid kogeda ebamugavusi teiste liiklusest.
Kodus lahendasime selle probleemi järgmiselt: ehitasime IS-IS protokolli kasutades täisliidesega L3 magistraalvõrgu. Tuuma peale ehitati tehnoloogial põhinev kattevõrk EVPN/VXLAN, kasutades marsruutimisprotokolli MP-BGP. Marsruutimisprotokollide lähenemise kiirendamiseks kasutati BFD tehnoloogiat.

Võrgu struktuur

Testides osutus see skeem end suurepäraseks - kui mis tahes kanal või lüliti on lahti ühendatud, ei ületa lähenemisaeg 0.1-0.2 s, kaob minimaalselt pakette (sageli mitte ühtegi), TCP seansse ei rebene, telefonivestlused ei katkestata.

Aluskattekiht – marsruutimine

Ülekattekiht – marsruutimine

Jaotuslülititena kasutati VXLAN-litsentsiga Huawei CE6870 lüliteid. Sellel seadmel on optimaalne hinna ja kvaliteedi suhe, mis võimaldab ühendada abonereid kiirusega 10 Gbit/s ja magistraalühendust kiirusega 40–100 Gbit/s, olenevalt kasutatavatest transiiveritest.

Huawei CE6870 lülitid

Tuumlülititena kasutati Huawei CE8850 lüliteid. Eesmärk on liiklust kiiresti ja usaldusväärselt edastada. Nendega pole ühendatud ühtegi seadet peale jaotuslülitite, nad ei tea VXLANist midagi, seega valiti 32 40/100 Gbps pordiga mudel, millel on põhilitsents, mis pakub L3 marsruutimist ja tuge IS-IS ja MP-BGP jaoks. protokollid .

Alumine on Huawei CE8850 tuumalüliti

Projekteerimisetapis puhkes meeskonnas arutelu tehnoloogiate üle, mida saaks kasutada tõrketaluva ühenduse juurutamiseks põhivõrgu sõlmedega. Meie Moskva kontor asub kolmes majas, meil on 7 jaotusruumi, millest igasse paigaldati kaks Huawei CE6870 jaotuslülitit (mitmesse jaotusruumi paigaldati ainult juurdepääsulülitid). Võrgukontseptsiooni väljatöötamisel kaaluti kahte koondamisvõimalust:

• Jaotuslülitite koondamine tõrketaluvusse korstnasse igas ristühendusruumis. Plussid: lihtsus ja seadistamise lihtsus. Puudused: kogu virna rikke tõenäosus on suurem, kui võrguseadmete püsivaras ilmnevad vead (“mälu lekked” jms).
• Rakendage M-LAG-i ja Anycasti lüüsitehnoloogiaid seadmete ühendamiseks jaotuslülititega.

Lõpuks leppisime teise variandiga. Seda on mõnevõrra keerulisem konfigureerida, kuid see on praktikas näidanud selle jõudlust ja kõrget töökindlust.
Esmalt kaalume lõppseadmete ühendamist jaotuslülititega:

Rist

Juurdepääsulüliti, server või mis tahes muu seade, mis nõuab tõrketaluvusega ühendust, sisaldub kahes jaotuslülitis. M-LAG-tehnoloogia tagab liiasuse andmesideühenduse tasemel. Eeldatakse, et kaks jaotuslülitit ilmuvad ühendatud seadmele ühe seadmena. Koondamine ja koormuse tasakaalustamine toimub LACP-protokolli abil.

Anycasti lüüsi tehnoloogia tagab koondamise võrgu tasemel. Igas jaotuslülitis on konfigureeritud üsna suur hulk VRF-e (iga VRF on mõeldud oma otstarbeks - eraldi "tavakasutajatele", eraldi telefonikõnede jaoks, eraldi erinevate test- ja arenduskeskkondade jaoks jne) ja igas. VRF-il on konfigureeritud mitu VLAN-i. Meie võrgus on jaotuslülitid kõigi nendega ühendatud seadmete vaikelüüsid. VLAN-liidestele vastavad IP-aadressid on mõlema jaotuslüliti jaoks samad. Liiklus juhitakse lähima pöörme kaudu.

Vaatame nüüd jaotuslülitite ühendamist tuumaga:
Rikketaluvus on tagatud võrgu tasemel IS-IS protokolli abil. Pange tähele, et lülitite vahel on eraldi L3 sideliin kiirusega 100G. Füüsiliselt on see sideliin otsejuurdepääsukaabel, mis on näha Huawei CE6870 lülitite fotol paremal.

Alternatiiviks oleks korraldada “aus” täielikult ühendatud topelttähe topoloogia, kuid nagu eespool mainitud, on meil 7 ristühendusega ruumi kolmes hoones. Seega, kui oleksime valinud topoloogia topoloogia, oleksime vajanud täpselt kaks korda rohkem pikamaa 40G transiivereid. Siin on kokkuhoid väga märkimisväärne.

VXLAN-i ja Anycasti lüüsitehnoloogiate koostöö kohta tuleb öelda paar sõna. VXLAN on detailidesse laskumata tunnel Etherneti kaadrite transportimiseks UDP-pakettides. Jaotuslülitite tagasisilmusliideseid kasutatakse VXLAN-tunneli sihtkoha IP-aadressina. Igal ristühendusel on kaks samade loopback-liidese aadressidega lülitit, nii et pakett võib jõuda ükskõik millisesse neist ja sellest saab eraldada Etherneti raami.

Kui lüliti teab allalaaditud kaadri sihtkoha MAC-aadressi, toimetatakse kaader sihtkohta õigesti. Tagamaks, et mõlemal samasse ristühendusse paigaldatud jaotuslülititel oleks ajakohane teave kõigi juurdepääsulülititest saabuvate MAC-aadresside kohta, vastutab M-LAG mehhanism MAC-aadresside tabelite (ja ka ARP-i) sünkroonimise eest. tabelid) mõlemal lülitil M-LAG paarid.

Liikluse tasakaalustamine saavutatakse tänu sellele, et alusvõrgus on mitu marsruuti jaotuslülitite tagasisilmusliidesteni.

Selle asemel, et järeldus

Nagu eespool mainitud, näitas võrk testimise ja töötamise ajal kõrget töökindlust (tavaliste rikete taastumisaeg ei ületa sadu millisekundeid) ja head jõudlust - iga ristühendus on tuumaga ühendatud kahe 40 Gbit/s kanaliga. Meie võrgu juurdepääsulülitid on virnastatud ja ühendatud jaotuslülititega läbi LACP/M-LAG kahe 10 Gbit/s kanaliga. Pinn sisaldab tavaliselt 5 lülitit, millest igaüks on 48 pordiga, ja igas ristühenduses on jaotusega ühendatud kuni 10 juurdepääsupinu. Seega tagab magistraal isegi maksimaalse teoreetilise koormuse juures umbes 30 Mbit/s kasutaja kohta, mis on kirjutamise hetkel piisav kõigi meie praktiliste rakenduste jaoks.

Võrk võimaldab sujuvalt korraldada suvaliste ühendatud seadmete sidumist nii L2 kui ka L3 kaudu, pakkudes täielikku liikluse isoleerimist (mis meeldib infoturbeteenusele) ja veadomeene (mis operatiivmeeskonnale meeldib).

Järgmises osas räägime teile, kuidas me uude võrku üle läksime. Püsige lainel!

Maksim Klochkov
Võrguauditi ja kompleksprojektide grupi vanemkonsultant
Võrgulahenduste keskus
"Jet Infosüsteemid"

Allikas: www.habr.com