Kā mēs izstrādājām un ieviesām jaunu Huawei tīklu Maskavas birojā, 1. daļa

Kā mēs izstrādājām un ieviesām jaunu Huawei tīklu Maskavas birojā, 1. daļa

Šodien es jums pastāstīšu par to, kā radās un tika īstenota ideja par jauna iekšējā tīkla izveidi mūsu uzņēmumam. Vadības nostāja ir tāda, ka jums ir jāizdara tāds pats pilnvērtīgs projekts sev kā klientam. Ja mēs paši to darām labi, varam uzaicināt klientu un parādīt, cik labi viņam darbojas un darbojas mūsu piedāvātais. Tāpēc ļoti rūpīgi piegājām Maskavas biroja jaunā tīkla koncepcijas izstrādei, izmantojot pilnu ražošanas ciklu: departamentu vajadzību analīze → tehniskā risinājuma izvēle → projektēšana → ieviešana → testēšana. Tātad sāksim.

Tehniskā risinājuma izvēle: Mutantu rezervāts

Procedūra darbam ar sarežģītu automatizētu sistēmu pašlaik vislabāk ir aprakstīta GOST 34.601-90 “Automatizētās sistēmas. Radīšanas posmi”, tāpēc strādājām saskaņā ar to. Un jau prasību veidošanas un koncepcijas izstrādes stadijā mēs saskārāmies ar pirmajām grūtībām. Dažāda profila organizācijām - bankām, apdrošināšanas kompānijām, programmatūras izstrādātājiem u.c. - saviem uzdevumiem un standartiem ir nepieciešami noteikta veida tīkli, kuru specifika ir skaidra un standartizēta. Tomēr ar mums tas nedarbosies.

Kāpēc?

Jet Infosystems ir liels daudzveidīgs IT uzņēmums. Tajā pašā laikā mūsu iekšējā atbalsta nodaļa ir neliela (bet lepna), tā nodrošina pamatpakalpojumu un sistēmu funkcionalitāti. Uzņēmumā ir daudzas nodaļas, kas veic dažādas funkcijas: tās ir vairākas spēcīgas ārpakalpojumu komandas, gan biznesa sistēmu un informācijas drošības iekšējie izstrādātāji, gan skaitļošanas sistēmu arhitekti - vispār, lai kurš tas būtu. Attiecīgi atšķiras arī viņu uzdevumi, sistēmas un drošības politika. Kas, kā gaidīts, radīja grūtības vajadzību analīzes un standartizācijas procesā.

Šeit, piemēram, ir izstrādes nodaļa: tās darbinieki raksta un pārbauda kodu lielam skaitam klientu. Bieži vien ir nepieciešams ātri organizēt testa vides, un, atklāti sakot, ne vienmēr ir iespējams formulēt prasības katram projektam, pieprasīt resursus un izveidot atsevišķu testa vidi atbilstoši visiem iekšējiem noteikumiem. Tas rada dīvainas situācijas: kādu dienu jūsu pazemīgais kalps ieskatījās izstrādātāju istabā un zem galda atrada pareizi strādājošu Hadoop kopu ar 20 galddatoriem, kas bija neizskaidrojami savienots ar kopējo tīklu. Es domāju, ka nav vērts precizēt, ka uzņēmuma IT nodaļa nezināja par tā esamību. Šis apstāklis, tāpat kā daudzi citi, bija atbildīgs par to, ka projekta izstrādes gaitā radās termins “mutantu rezerve”, kas raksturo ilgi cietusī biroju infrastruktūras stāvokli.

Vai arī šeit ir vēl viens piemērs. Periodiski departamentā tiek izveidots testēšanas stends. Tā tas bija gadījumā ar Jira un Confluence, kuras dažos projektos Programmatūras izstrādes centrs izmantoja ierobežotā apjomā. Pēc kāda laika citas nodaļas uzzināja par šiem noderīgajiem resursiem, novērtēja tos, un 2018. gada beigās Jira un Confluence pārcēlās no statusa “vietējo programmētāju rotaļlieta” uz “uzņēmuma resursu” statusu. Tagad šīm sistēmām ir jāpiešķir īpašnieks, jādefinē SLA, piekļuves/informācijas drošības politikas, rezerves politikas, uzraudzība, noteikumi maršrutēšanas pieprasījumiem problēmu novēršanai - kopumā jābūt visiem pilnvērtīgas informācijas sistēmas atribūtiem. .
Katra mūsu nodaļa ir arī inkubators, kas audzē savus produktus. Daži no tiem mirst izstrādes stadijā, daži mēs izmantojam, strādājot pie projektiem, bet citi iesakņojas un kļūst par risinājumiem, kurus sākam lietot paši un pārdot klientiem. Katrai šādai sistēmai ir vēlama sava tīkla vide, kurā tā attīstīsies, netraucējot citām sistēmām, un kādā brīdī var tikt integrēta uzņēmuma infrastruktūrā.

Papildus attīstībai mums ir ļoti liela Servisa centrs ar vairāk nekā 500 darbiniekiem, kas izveidotas komandās katram klientam. Viņi ir iesaistīti tīklu un citu sistēmu uzturēšanā, attālinātā uzraudzībā, pretenziju risināšanā utt. Tas ir, SC infrastruktūra faktiski ir tā klienta infrastruktūra, ar kuru viņi šobrīd strādā. Darba ar šo tīkla sadaļu īpatnība ir tāda, ka viņu darbstacijas mūsu uzņēmumam ir daļēji ārējās un daļēji iekšējās. Tāpēc SC ieviesām šādu pieeju - uzņēmums nodrošina attiecīgo nodaļu ar tīkla un citiem resursiem, šo nodaļu darbstacijas uzskatot par ārējiem pieslēgumiem (pēc analoģijas ar filiālēm un attāliem lietotājiem).

Šosejas dizains: mēs esam operators (pārsteigums)

Izvērtējot visas nepilnības, sapratām, ka telekomunikāciju operatora tīklu iegūstam vienā birojā, un sākām attiecīgi rīkoties.

Mēs izveidojām pamattīklu, ar kura palīdzību jebkuram iekšējam un nākotnē arī ārējam patērētājam tiek nodrošināts nepieciešamais pakalpojums: L2 VPN, L3 VPN vai regulāra L3 maršrutēšana. Dažiem departamentiem ir nepieciešama droša piekļuve internetam, savukārt citiem ir nepieciešama tīra piekļuve bez ugunsmūriem, bet tajā pašā laikā aizsargājot mūsu korporatīvos resursus un pamattīklu no to trafika.

Mēs neoficiāli “noslēdzām SLA” ar katru nodaļu. Saskaņā ar to visi incidenti, kas rodas, ir jānovērš noteiktā, iepriekš saskaņotā termiņā. Uzņēmuma prasības savam tīklam izrādījās stingras. Maksimālais reaģēšanas laiks uz incidentu telefona un e-pasta kļūmju gadījumā bija 5 minūtes. Tīkla funkcionalitātes atjaunošanas laiks tipisku kļūmju laikā nav ilgāks par minūti.

Tā kā mums ir mobilo sakaru operatora līmeņa tīkls, jūs varat izveidot savienojumu ar to tikai stingri ievērojot noteikumus. Pakalpojumu vienības nosaka politikas un sniedz pakalpojumus. Viņiem pat nav vajadzīga informācija par konkrētu serveru, virtuālo mašīnu un darbstaciju savienojumiem. Bet tajā pašā laikā ir nepieciešami aizsardzības mehānismi, jo nevienam savienojumam nevajadzētu atspējot tīklu. Ja nejauši tiek izveidota cilpa, citiem lietotājiem to nevajadzētu pamanīt, tas ir, ir nepieciešama atbilstoša tīkla atbilde. Jebkurš telekomunikāciju operators savā pamattīklā pastāvīgi risina līdzīgas šķietami sarežģītas problēmas. Tas sniedz pakalpojumus daudziem klientiem ar dažādām vajadzībām un satiksmi. Tajā pašā laikā dažādiem abonentiem nevajadzētu piedzīvot neērtības no citu personu satiksmes.
Mājās mēs šo problēmu atrisinājām šādi: izveidojām mugurkaula L3 tīklu ar pilnu dublēšanu, izmantojot IS-IS protokolu. Pamatojoties uz tehnoloģiju, kodolam tika izveidots pārklājuma tīkls EVPN/VXLAN, izmantojot maršrutēšanas protokolu MP-BGP. Lai paātrinātu maršrutēšanas protokolu konverģenci, tika izmantota BFD tehnoloģija.

Kā mēs izstrādājām un ieviesām jaunu Huawei tīklu Maskavas birojā, 1. daļa
Tīkla struktūra

Testos šī shēma sevi parādīja izcili - atvienojot jebkuru kanālu vai slēdzi, konverģences laiks nav lielāks par 0.1-0.2 s, tiek pazaudēts minimums pakešu (bieži vien neviena), TCP sesijas netiek saplēstas, telefona sarunas netiek pārtraukti.

Kā mēs izstrādājām un ieviesām jaunu Huawei tīklu Maskavas birojā, 1. daļa
Apakšklājuma slānis — maršrutēšana

Kā mēs izstrādājām un ieviesām jaunu Huawei tīklu Maskavas birojā, 1. daļa
Pārklājuma slānis — maršrutēšana

Kā izplatīšanas slēdži tika izmantoti Huawei CE6870 slēdži ar VXLAN licencēm. Šai ierīcei ir optimāla cenas/kvalitātes attiecība, kas ļauj pieslēgt abonentus ar ātrumu 10 Gbit/s, bet mugurkaula savienojumu ar ātrumu 40–100 Gbit/s, atkarībā no izmantotajiem raiduztvērējiem.

Kā mēs izstrādājām un ieviesām jaunu Huawei tīklu Maskavas birojā, 1. daļa
Huawei CE6870 slēdži

Huawei CE8850 slēdži tika izmantoti kā galvenie slēdži. Mērķis ir ātri un uzticami pārraidīt satiksmi. Viņiem nav pievienotas ierīces, izņemot sadales slēdžus, viņi neko nezina par VXLAN, tāpēc tika izvēlēts modelis ar 32 40/100 Gbps pieslēgvietām, ar pamata licenci, kas nodrošina L3 maršrutēšanu un atbalstu IS-IS un MP-BGP. protokoli.

Kā mēs izstrādājām un ieviesām jaunu Huawei tīklu Maskavas birojā, 1. daļa
Apakšējais ir Huawei CE8850 kodola slēdzis

Projektēšanas stadijā komandas iekšienē izcēlās diskusija par tehnoloģijām, kuras varētu izmantot, lai ieviestu defektu izturīgu savienojumu ar pamattīkla mezgliem. Mūsu Maskavas birojs atrodas trīs ēkās, mums ir 7 sadales telpas, katrā no kurām tika uzstādīti divi Huawei CE6870 sadales slēdži (vairākās sadales telpās tika uzstādīti tikai piekļuves slēdži). Izstrādājot tīkla koncepciju, tika apsvērtas divas atlaišanas iespējas:

  • Sadales slēdžu apvienošana defektu izturīgā kaudzē katrā šķērssavienojuma telpā. Plusi: vienkāršība un viegla iestatīšana. Trūkumi: pastāv lielāka visa kaudzes kļūmes iespējamība, ja rodas kļūdas tīkla ierīču programmaparatūrā (“atmiņas noplūdes” un tamlīdzīgi).
  • Izmantojiet M-LAG un Anycast vārtejas tehnoloģijas, lai savienotu ierīces ar sadales slēdžiem.

Beigās izšķīrāmies pie otrā varianta. To ir nedaudz grūtāk konfigurēt, taču praksē tas ir pierādījis tā veiktspēju un augstu uzticamību.
Vispirms apsveriet gala ierīču pievienošanu sadales slēdžiem:
Kā mēs izstrādājām un ieviesām jaunu Huawei tīklu Maskavas birojā, 1. daļa
Krusts

Divos sadales slēdžos ir iekļauts piekļuves slēdzis, serveris vai jebkura cita ierīce, kurai nepieciešams kļūmju izturīgs savienojums. M-LAG tehnoloģija nodrošina dublēšanu datu saites līmenī. Tiek pieņemts, ka divi sadales slēdži pievienotajai iekārtai parādās kā viena ierīce. Redundance un slodzes līdzsvarošana tiek veikta, izmantojot LACP protokolu.

Anycast vārtejas tehnoloģija nodrošina dublēšanu tīkla līmenī. Katrā sadales slēdžā ir konfigurēts diezgan liels skaits VRF (katrs VRF ir paredzēts saviem mērķiem - atsevišķi “parastajiem” lietotājiem, atsevišķi telefonijai, atsevišķi dažādām testēšanas un izstrādes vidēm utt.), Un katrā. VRF ir konfigurēti vairāki VLAN. Mūsu tīklā sadales slēdži ir noklusējuma vārtejas visām ar tiem pievienotajām ierīcēm. IP adreses, kas atbilst VLAN saskarnēm, ir vienādas abiem sadales slēdžiem. Satiksme tiek virzīta caur tuvāko pārmiju.

Tagad apskatīsim sadales slēdžu savienošanu ar kodolu:
Kļūdu tolerance tiek nodrošināta tīkla līmenī, izmantojot IS-IS protokolu. Lūdzu, ņemiet vērā, ka starp slēdžiem tiek nodrošināta atsevišķa L3 sakaru līnija ar ātrumu 100G. Fiziski šī sakaru līnija ir tiešās piekļuves kabelis; to var redzēt labajā pusē Huawei CE6870 slēdžu fotoattēlā.

Alternatīva būtu organizēt “godīgu” pilnībā savienotu dubultzvaigžņu topoloģiju, taču, kā minēts iepriekš, mums ir 7 savstarpēji savienotas telpas trīs ēkās. Attiecīgi, ja mēs būtu izvēlējušies “dubultzvaigžņu” topoloģiju, mums būtu nepieciešams tieši divreiz vairāk “tāldarbības” 40G raiduztvērēju. Ietaupījumi šeit ir ļoti būtiski.

Daži vārdi jāsaka par to, kā VXLAN un Anycast vārtejas tehnoloģijas darbojas kopā. VXLAN, neiedziļinoties detaļās, ir tunelis Ethernet kadru transportēšanai UDP paketēs. Sadales slēdžu cilpas saskarnes tiek izmantotas kā VXLAN tuneļa galamērķa IP adrese. Katram krustojumam ir divi slēdži ar vienādām cilpas interfeisa adresēm, tāpēc pakete var nonākt jebkurā no tiem, un no tā var iegūt Ethernet rāmi.

Ja slēdzis zina par izgūtā kadra mērķa MAC adresi, rāmis tiks pareizi piegādāts galamērķim. Lai nodrošinātu, ka abiem sadales slēdžiem, kas uzstādīti vienā šķērssavienojumā, ir jaunākā informācija par visām MAC adresēm, kas “nāk” no piekļuves slēdžiem, M-LAG mehānisms ir atbildīgs par MAC adrešu tabulu (kā arī ARP) sinhronizāciju. tabulas) uz abiem slēdžiem M-LAG pāriem.

Satiksmes līdzsvarošana tiek panākta, pateicoties tam, ka apakšklāja tīklā ir vairāki maršruti uz sadales slēdžu atpakaļcilpas saskarnēm.

Tā vietā, lai noslēgtu

Kā minēts iepriekš, testēšanas un darbības laikā tīkls uzrādīja augstu uzticamību (atkopšanas laiks tipiskām kļūmēm ir ne vairāk kā simtiem milisekundes) un labu veiktspēju - katrs šķērssavienojums ir savienots ar kodolu ar diviem 40 Gbit/s kanāliem. Piekļuves slēdži mūsu tīklā ir sakrauti un savienoti ar sadales slēdžiem caur LACP/M-LAG ar diviem 10 Gbit/s kanāliem. Stackā parasti ir 5 slēdži ar 48 portiem katrā, un līdz 10 piekļuves skursteņiem ir pievienoti sadalei katrā šķērssavienojumā. Tādējādi mugurkauls nodrošina aptuveni 30 Mbit/s vienam lietotājam pat pie maksimālās teorētiskās slodzes, kas rakstīšanas brīdī ir pietiekama visiem mūsu praktiskiem pielietojumiem.

Tīkls ļauj nemanāmi organizēt jebkuru patvaļīgi savienotu ierīču savienošanu pārī gan caur L2, gan L3, nodrošinot pilnīgu trafika izolāciju (kas patīk informācijas drošības dienestam) un kļūdu domēnus (kas patīk operāciju komandai).

Nākamajā daļā mēs jums pastāstīsim, kā mēs migrējām uz jauno tīklu. Sekojiet līdzi!

Maksims Kločkovs
Tīkla audita un komplekso projektu grupas vecākais konsultants
Tīkla risinājumu centrs
"Reaktīvās informācijas sistēmas"


Avots: www.habr.com

Iegādājieties uzticamu mitināšanu vietnēm ar DDoS aizsardzību, VPS VDS serveriem 🔥 Iegādājieties uzticamu tīmekļa vietņu mitināšanu ar DDoS aizsardzību, VPS VDS serveriem | ProHoster