Kaip sukūrėme ir įdiegėme naują „Huawei“ tinklą Maskvos biure, 1 dalis

Kaip sukūrėme ir įdiegėme naują „Huawei“ tinklą Maskvos biure, 1 dalis

Šiandien papasakosiu apie tai, kaip kilo ir buvo įgyvendinta idėja sukurti naują mūsų įmonės vidinį tinklą. Vadovybės pozicija yra tokia, kad jūs turite padaryti tą patį visavertį projektą sau kaip ir klientui. Jei tai darome gerai sau, galime pasikviesti klientą ir parodyti, kaip tai, ką jam siūlome, veikia ir veikia. Todėl į naujo Maskvos biuro tinklo koncepcijos kūrimą priėjome labai kruopščiai, išnaudodami visą gamybos ciklą: padalinių poreikių analizė → techninio sprendimo parinkimas → projektavimas → įgyvendinimas → testavimas. Taigi pradėkime.

Techninio sprendimo pasirinkimas: Mutant Sanctuary

Darbo su sudėtinga automatizuota sistema procedūra šiuo metu geriausiai aprašyta GOST 34.601-90 „Automatinės sistemos. Kūrybos etapai“, todėl ir dirbome pagal ją. Ir jau reikalavimų formavimo ir koncepcijos kūrimo stadijose susidūrėme su pirmaisiais sunkumais. Įvairių profilių organizacijoms – bankams, draudimo bendrovėms, programinės įrangos kūrėjams ir kt. – savo užduotims ir standartams atlikti reikia tam tikro tipo tinklų, kurių specifika yra aiški ir standartizuota. Tačiau pas mus tai neveiks.

Kodėl?

Jet Infosystems yra didelė įvairi IT įmonė. Tuo pačiu mūsų vidinis palaikymo skyrius yra nedidelis (bet išdidus), užtikrina pagrindinių paslaugų ir sistemų funkcionalumą. Įmonėje yra daug padalinių, kurie atlieka skirtingas funkcijas: tai kelios galingos užsakomųjų paslaugų komandos, ir verslo sistemų, ir informacijos saugumo kūrėjai, ir kompiuterinių sistemų architektai – apskritai, kas tai bebūtų. Atitinkamai skiriasi ir jų užduotys, sistemos ir saugumo politika. Tai, kaip ir tikėtasi, sukėlė sunkumų poreikių analizės ir standartizavimo procese.

Štai, pavyzdžiui, plėtros skyrius: jo darbuotojai rašo ir išbando kodą daugeliui klientų. Dažnai reikia greitai organizuoti testavimo aplinkas, o atvirai kalbant, ne visada pavyksta suformuluoti reikalavimus kiekvienam projektui, paprašyti išteklių ir sukurti atskirą testavimo aplinką pagal visus vidinius reglamentus. Tai sukelia kurioziškų situacijų: vieną dieną jūsų nuolankus tarnas pažvelgė į kūrėjų kambarį ir po stalu rado tinkamai veikiantį 20 stalinių kompiuterių Hadoop klasterį, kuris buvo nepaaiškinamai prijungtas prie bendro tinklo. Nemanau, kad verta aiškinti, kad įmonės IT skyrius nežinojo apie jos egzistavimą. Ši aplinkybė, kaip ir daugelis kitų, lėmė tai, kad kuriant projektą gimė terminas „mutantinis rezervas“, apibūdinantis ilgai kenčiančios biurų infrastruktūros būklę.

Arba štai kitas pavyzdys. Periodiškai skyriuje įrengiamas bandymų stendas. Taip buvo su Jira ir Confluence, kurias kai kuriuose projektuose Programinės įrangos kūrimo centras naudojo ribotai. Po kurio laiko kiti skyriai sužinojo apie šiuos naudingus išteklius, juos įvertino, o 2018 m. pabaigoje Jira ir Confluence iš „vietinių programuotojų žaislo“ statuso perėjo į „įmonės išteklių“ statusą. Dabar šioms sistemoms turi būti priskirtas savininkas, SLA, prieigos/informacijos saugumo politika, atsarginės kopijos politika, stebėjimas, problemų sprendimo užklausų maršruto taisyklės – apskritai turi būti visi visavertės informacinės sistemos atributai. .
Kiekvienas mūsų padalinys taip pat yra inkubatorius, auginantis savo produkciją. Kai kurie jų miršta kūrimo stadijoje, kai kuriuos naudojame kurdami projektus, o kiti įsitvirtina ir tampa atkartojamais sprendimais, kuriuos pradedame naudoti patys ir parduoti klientams. Kiekvienai tokiai sistemai pageidautina turėti savo tinklo aplinką, kurioje ji vystysis netrukdydama kitoms sistemoms ir tam tikru momentu galėtų būti integruota į įmonės infrastruktūrą.

Be plėtros, mes turime labai didelę Paslaugų centras su daugiau nei 500 darbuotojų, suformuotų į komandas kiekvienam klientui. Jie užsiima tinklų ir kitų sistemų priežiūra, nuotoliniu stebėjimu, pretenzijų sprendimu ir pan. Tai yra, SC infrastruktūra iš tikrųjų yra kliento, su kuriuo jie šiuo metu dirba, infrastruktūra. Darbo su šia tinklo dalimi ypatumas yra tas, kad jų darbo vietos mūsų įmonei yra iš dalies išorinės, iš dalies vidinės. Todėl SC įgyvendinome tokį požiūrį – įmonė atitinkamą padalinį aprūpina tinklo ir kitais ištekliais, šių padalinių darbo vietas laikydama išoriniais ryšiais (analogiškai su filialais ir nuotoliniais vartotojais).

Greitkelio dizainas: mes esame operatoriai (siurprizas)

Įvertinę visas spąstus supratome, kad telekomunikacijų operatoriaus tinklą gauname viename biure, ir pradėjome atitinkamai elgtis.

Sukūrėme pagrindinį tinklą, kurio pagalba bet kuriam vidiniam, o ateityje ir išoriniam vartotojui suteikiama reikiama paslauga: L2 VPN, L3 VPN arba įprastas L3 maršrutizavimas. Kai kuriems skyriams reikalinga saugi interneto prieiga, o kitiems – švari prieiga be ugniasienės, tačiau kartu apsaugoti mūsų įmonės išteklius ir pagrindinį tinklą nuo srauto.

Mes neoficialiai „sudarėme SLA“ su kiekvienu padaliniu. Pagal jį visi kylantys incidentai turi būti pašalinti per tam tikrą iš anksto sutartą laikotarpį. Bendrovės reikalavimai savo tinklui pasirodė griežti. Maksimalus reagavimo laikas į incidentą telefono ir el. pašto gedimų atveju buvo 5 minutės. Tinklo funkcionalumo atkūrimo laikas tipinių gedimų metu yra ne daugiau kaip minutė.

Kadangi turime operatoriaus lygio tinklą, prie jo galite prisijungti tik griežtai laikydamiesi taisyklių. Paslaugų padaliniai nustato politiką ir teikia paslaugas. Jiems net nereikia informacijos apie konkrečių serverių, virtualių mašinų ir darbo stočių ryšius. Tačiau tuo pačiu metu reikalingi apsaugos mechanizmai, nes nė vienas ryšys neturėtų išjungti tinklo. Jei netyčia sukuriama kilpa, kiti vartotojai neturėtų to pastebėti, tai yra, reikalingas tinkamas tinklo atsakas. Bet kuris telekomunikacijų operatorius nuolat sprendžia panašias, atrodytų, sudėtingas problemas savo pagrindiniame tinkle. Jis teikia paslaugas daugeliui klientų, turinčių skirtingus poreikius ir srautą. Tuo pačiu metu skirtingi abonentai neturėtų patirti nepatogumų dėl kitų srauto.
Namuose šią problemą išsprendėme taip: sukūrėme pagrindinį L3 tinklą su visišku atleidimu, naudodami IS-IS protokolą. Virš šerdies, remiantis technologija, buvo sukurtas perdangos tinklas EVPN/VXLAN, naudojant maršruto parinkimo protokolą MP-BGP. Siekiant paspartinti maršruto parinkimo protokolų konvergenciją, buvo panaudota BFD technologija.

Kaip sukūrėme ir įdiegėme naują „Huawei“ tinklą Maskvos biure, 1 dalis
Tinklo struktūra

Testuose ši schema pasirodė puikiai - atjungus bet kurį kanalą ar jungiklį, konvergencijos laikas neviršija 0.1-0.2 s, prarandama mažiausiai paketų (dažnai jų nėra), TCP seansai nenutrūksta, pokalbiai telefonu nėra pertraukiami.

Kaip sukūrėme ir įdiegėme naują „Huawei“ tinklą Maskvos biure, 1 dalis
Pakloto sluoksnis – maršrutizavimas

Kaip sukūrėme ir įdiegėme naują „Huawei“ tinklą Maskvos biure, 1 dalis
Perdangos sluoksnis – maršruto parinkimas

Kaip paskirstymo jungikliai buvo naudojami Huawei CE6870 komutatoriai su VXLAN licencijomis. Šis įrenginys pasižymi optimaliu kainos ir kokybės santykiu, leidžiančiu jungti abonentus 10 Gbit/s greičiu, o prie magistralinio tinklo – 40–100 Gbit/s greičiu, priklausomai nuo naudojamų siųstuvų-imtuvų.

Kaip sukūrėme ir įdiegėme naują „Huawei“ tinklą Maskvos biure, 1 dalis
Huawei CE6870 jungikliai

Huawei CE8850 jungikliai buvo naudojami kaip pagrindiniai jungikliai. Tikslas – greitai ir patikimai perduoti srautą. Prie jų nėra prijungti jokie įrenginiai, išskyrus paskirstymo jungiklius, jie nieko nežino apie VXLAN, todėl buvo pasirinktas modelis su 32 40/100 Gbps prievadais, su bazine licencija, kuri suteikia L3 maršrutą ir palaikymą IS-IS ir MP-BGP. protokolai.

Kaip sukūrėme ir įdiegėme naują „Huawei“ tinklą Maskvos biure, 1 dalis
Apatinis yra Huawei CE8850 branduolio jungiklis

Projektavimo etape komandoje kilo diskusija apie technologijas, kurios galėtų būti naudojamos gedimams atspariam ryšiui su pagrindinio tinklo mazgais įdiegti. Mūsų biuras Maskvoje yra trijuose pastatuose, turime 7 paskirstymo patalpas, kurių kiekviename buvo sumontuoti po du Huawei CE6870 skirstomuosius jungiklius (keliuose paskirstymo kambariuose buvo įrengti tik prieigos jungikliai). Kuriant tinklo koncepciją buvo svarstomos dvi atleidimo galimybės:

  • Paskirstymo jungiklių sujungimas į gedimams atsparų krūvą kiekvienoje kryžminio sujungimo patalpoje. Argumentai "už": paprastumas ir lengvas nustatymas. Trūkumai: didesnė viso kamino gedimo tikimybė, kai atsiranda klaidų tinklo įrenginių programinėje įrangoje („atminties nutekėjimas“ ir panašiai).
  • Taikykite M-LAG ir Anycast šliuzo technologijas, kad prijungtumėte įrenginius prie paskirstymo jungiklių.

Galiausiai apsistojome prie antrojo varianto. Jį konfigūruoti yra šiek tiek sunkiau, tačiau praktiškai jis parodė savo našumą ir didelį patikimumą.
Pirmiausia apsvarstykime galinių įrenginių prijungimą prie paskirstymo jungiklių:
Kaip sukūrėme ir įdiegėme naują „Huawei“ tinklą Maskvos biure, 1 dalis
Kirsti

Prieigos jungiklis, serveris ar bet kuris kitas įrenginys, kuriam reikalingas gedimams atsparus ryšys, yra du paskirstymo jungikliai. M-LAG technologija užtikrina dubliavimą duomenų ryšio lygiu. Daroma prielaida, kad du paskirstymo jungikliai prijungtai įrangai atrodo kaip vienas įrenginys. Atleidimas ir apkrovos balansavimas atliekami naudojant LACP protokolą.

Anycast šliuzo technologija užtikrina atleidimą tinklo lygiu. Kiekviename paskirstymo jungiklyje sukonfigūruojama gana daug VRF (kiekvienas VRF skirtas savo tikslams - atskirai „paprastiems“ vartotojams, atskirai telefonui, atskirai įvairioms bandymų ir kūrimo aplinkoms ir kt.) VRF sukonfigūruoti keli VLAN. Mūsų tinkle paskirstymo jungikliai yra numatytieji visų prie jų prijungtų įrenginių šliuzai. Abiejų paskirstymo jungiklių IP adresai, atitinkantys VLAN sąsajas, yra vienodi. Eismas nukreipiamas per artimiausią iešmą.

Dabar pažiūrėkime, kaip prijungti paskirstymo jungiklius prie branduolio:
Gedimų tolerancija suteikiama tinklo lygiu naudojant IS-IS protokolą. Atkreipkite dėmesį, kad tarp jungiklių yra atskira L3 ryšio linija, kurios greitis yra 100G. Fiziškai ši ryšio linija yra tiesioginės prieigos kabelis, jis matomas dešinėje Huawei CE6870 jungiklių nuotraukoje.

Alternatyva būtų organizuoti „sąžiningą“ visiškai sujungtą dviejų žvaigždučių topologiją, tačiau, kaip minėta aukščiau, mes turime 7 kryžminius kambarius trijuose pastatuose. Atitinkamai, jei būtume pasirinkę „dvigubos žvaigždės“ topologiją, mums būtų reikėję lygiai dvigubai daugiau „ilgojo nuotolio“ 40G siųstuvų-imtuvų. Čia sutaupoma labai daug.

Reikia pasakyti keletą žodžių apie tai, kaip VXLAN ir Anycast šliuzo technologijos veikia kartu. VXLAN, nesileidžiant į smulkmenas, yra tunelis, skirtas Ethernet kadrams transportuoti UDP paketuose. Paskirstymo jungiklių atgalinės sąsajos naudojamos kaip VXLAN tunelio paskirties IP adresas. Kiekvienas kryžminis jungiklis turi du jungiklius su tais pačiais loopback sąsajos adresais, todėl paketas gali patekti į bet kurį iš jų, o iš jo galima išgauti eterneto rėmelį.

Jei jungiklis žino apie gauto kadro paskirties MAC adresą, kadras bus tinkamai pristatytas į paskirties vietą. Siekiant užtikrinti, kad abu paskirstymo jungikliai, sumontuoti tame pačiame kryžminiame jungtyje, turėtų naujausią informaciją apie visus MAC adresus, „gaunamus“ iš prieigos jungiklių, M-LAG mechanizmas yra atsakingas už MAC adresų lentelių (taip pat ir ARP) sinchronizavimą. lentelės) ant abiejų jungiklių M-LAG porų.

Srauto balansavimas pasiekiamas dėl to, kad apatiniame tinkle yra keli maršrutai į paskirstymo jungiklių atgalines sąsajas.

Vietoj išvados

Kaip minėta aukščiau, bandymų ir eksploatavimo metu tinklas parodė aukštą patikimumą (atkūrimo laikas tipiškų gedimų atveju yra ne daugiau nei šimtai milisekundžių) ir gerą našumą – kiekvienas kryžminis jungtis yra prijungtas prie šerdies dviem 40 Gbit/s kanalais. Prieigos jungikliai mūsų tinkle yra sukrauti ir prijungti prie paskirstymo jungiklių per LACP/M-LAG su dviem 10 Gbit/s kanalais. Stake paprastai yra 5 jungikliai su 48 prievadais, o iki 10 prieigos stekų yra prijungta prie paskirstymo kiekviename kryžminiame jungtyje. Taigi, stuburas suteikia apie 30 Mbit/s vienam vartotojui net esant maksimaliai teorinei apkrovai, kurios rašymo metu pakanka visiems mūsų praktiniams pritaikymams.

Tinklas leidžia sklandžiai organizuoti bet kokių savavališkai prijungtų įrenginių poravimą tiek per L2, tiek per L3, užtikrinant visišką srauto (kuris patinka informacijos saugos tarnybai) ir gedimų domenus (kuris patinka operacijų komandai).

Kitoje dalyje papasakosime, kaip persikėlėme į naują tinklą. Sekite naujienas!

Maksimas Kločkovas
Tinklo audito ir kompleksinių projektų grupės vyresnioji konsultantė
Tinklo sprendimų centras
„Jet Infosystems“


Šaltinis: www.habr.com

Добавить комментарий