Kā Uma.Tech infrastruktūru attīstīja

Mēs esam uzsākuši jaunus pakalpojumus, datplūsma ir augusi, nomainījuši serverus, pieslēguši jaunas vietnes un pārveidojuši datu centrus – tagad pastāstīsim šo stāstu, ar kura sākumu jūs iepazīstinājām pirms pieciem gadiem..

Pieci gadi – raksturīgs laiks starpposma rezultātu apkopošanai. Tāpēc mēs nolēmām pastāstīt par mūsu infrastruktūras attīstību, kas piecu gadu laikā ir gājusi pārsteidzoši interesantu attīstības ceļu, ar kuru mēs lepojamies. Realizētās kvantitatīvās izmaiņas pārvērtās kvalitatīvās, tagad infrastruktūra var darboties režīmos, kas pagājušā gadsimta vidū šķita fantastiski.

Mēs nodrošinām sarežģītu projektu darbību ar visstingrākajām uzticamības un slodzes prasībām, starp kuriem ir PREMIER un Match TV. Sporta pārraides un populāro seriālu pirmizrādēm nepieciešams datplūsmas izsniegums terabitos/s, ko mēs viegli realizējam, un pat tik bieži, ka darbs ar šādām ātrām tempēm jau sen ir kļuvis par mums ierastu lietu. Bet pirms pieciem gadiem vissmagākais projekts, kas darbojās mūsu sistēmās, bija Rutube, kas kopš tā laika ir attīstījies, palielinājis apjomus un datplūsmu, ko bija jāņem vērā plānojot slodzes.

Mēs esam stāstījuši par to, kā attīstījām mūsu infrastruktūras „dzelzi“ („Rutube 2009-2015: mūsu dzelzs vēsture“) un attīstījām sistēmu, kas atbild par video piegādi („No nulles līdz 700 gigabitām sekundē – kā piegādā video viens no lielākajiem video mitinātājiem Krievijā“), bet kopš šo tekstu rakstīšanas ir pagājis daudz laika, ir izveidoti un ieviesti daudzi citi risinājumi, kuru rezultāti ļauj mums atbildēt uz mūsdienu prasībām un būt pietiekami elastīgiem, lai pārstrukturētos jaunām uzdevumiem.

Mūsu tīkla kods pastāvīgi attīstās. Mēs pārgājām uz Cisco aparatūru 2015. gadā, par ko mēs jau pieminējām iepriekšējā rakstā. Toreiz tas bija tas pats 10/40G, bet saprotamu iemeslu dēļ jau pēc dažiem gadiem modernizējām esošās šasijas, un tagad aktīvi izmantojam arī 25/100G.

100G savienojumi jau sen vairs nav ne greznība (drīzāk tā ir steidzama prasība mūsu segmentā), ne arī retums (arvien vairāk operatoru piedāvā pieslēgumu pie šādām ātrumiem). Tomēr 10/40G joprojām ir aktuāli: caur šiem savienojumiem mēs turpinām pieslēgt operatorus ar nelielu datu plūsmu, kur šobrīd nav izdevīgi izmantot jaudīgāku portu.

Mūsu veidotais tīkla kodols pelnījis atsevišķu apskatu un drīz kļūs par atsevišķas raksta tēmu. Tur mēs padziļināti aplūkosim tehniskās detaļas un izvērtēsim loģiku mūsu rīcībā tā veidošanā. Bet šobrīd turpināsim zīmēt infrastruktūru vairāk shēmiski, jo jūsu uzmanība, cienījamie lasītāji, nav bezgalīga.

Video serveri attīstās ātri, un mēs piedāvājam daudz pūļu. Ja agrāk mēs vairāk izmantojām 2U serverus ar 4-5 tīkla kartēm, katrā no kurām bija divi 10G porti, tad tagad lielākā daļa datu plūsmas tiek nodrošināta ar 1U serveriem, kuros ir 2-3 kartes, katrā no kurām ir divi 25G porti. 10G un 25G kartes praktiski ir sasniegušas vienādu cenu, un ātrāki risinājumi ļauj nodrošināt savienojumu gan ar 10G, gan ar 25G. Rezultāts ir acīmredzama ekonomija: mazāk servera komponentu un pieslēguma kabeļu – mazākas izmaksas (un augstāka uzticamība), komponenti aizņem mazāk vietas skapī – ir kļuvusi iespējama lielāka serveru izvietošana uz vienu platību un, līdz ar to, samazinātas nomas izmaksas.

Bet svarīgāka ir uzvarētā ātrumā! Tagad mēs ar 1U varam nodrošināt vairāk par 100G! Un tas ir fona apstākļos, kad daži lielie Krievijas projekti sauc par "sasniegumu" 40G sniegšanu ar 2U. Mums tās būtu viņu problēmas!

Piezīmēsim, ka tīkla karšu paaudze, kas spēj strādāt tikai uz 10G, mēs joprojām izmantojam. Šī iekārta stabilā darbībā saglabājas un ir labi pazīstama, tāpēc mēs to neesam izmetuši, bet esam atraduši tai jaunu pielietojumu. Šos komponentus mēs instalējām video glabāšanas serveros, kuriem efektīvai darbībai noteikti nepietiek ar vienu vai diviem 1G saskarsmēm, šeit 10G kartes izrādījās aktuālas.

Datu glabāšanas sistēmas arī pieaug. Pēdējo piecu gadu laikā tās no divpadsmit disku (12x HDD 2U) ir kļuvušas par trīsdesmit sešu disku (36х HDD 4U). Šādi ietilpīgi „šasijas” daži baidās izmantot, jo gadījumā, ja viena šāda šasija izgāžas, var rasties draudi veiktspējai – vai pat sistēmas darbspējai! – visai sistēmai. Bet pie mums tā nenotiks: mēs nodrošinājām datu ģeoredundanci. Mēs saplokām šasijas dažādos datu centros – kopā mēs izmantojam trīs – un tas izslēdz problēmu rašanos, gan izslēdzot šasijas, gan straujās vietas kritumu.

Protams, šāda pieeja padarīja aparatūras RAID nevajadzīgu, no kura mēs atteicāmies. Atbrīvojoties no liekām komponentēm, mēs vienlaikus palielinājām sistēmas uzticamību, atvieglojot risinājumu un noņemot vienu potenciālo kļūmes punktu. Atgādinām, ka mūsu uzglabāšanas sistēma ir „pašu ražots”. Mēs pieņēmām šo lēmumu pilnīgi apzināti, un rezultāts mūs pilnībā apmierināja.

Datu centri pēdējo piecu gadu laikā mēs mainījām vairākas reizes. Kopš iepriekšējā raksta uzrakstīšanas mēs nemainījām tikai vienu datu centru – DataLine – pārējie prasīja nomaiņu mūsu infrastruktūras attīstības gaitā. Visi pārvietojumi starp vietām bija plānoti.

Pirms diviem gadiem mēs migrējām iekšpusē MMTS-9, pārejot uz vietu ar kvalitatīvu remontu, labu dzesēšanas sistēmu, stabilu elektroapgādi un bez putekļiem, kas iepriekš bieza slānī klāja visas virsmas un pilnībā aizpildīja mūsu iekārtu iekšējo daļu. Izvēle par labu augstākajām pakalpojumu kvalitātēm – un putekļu trūkumam! – bija iemesls mūsu pārvietošanai.

Gandrīz vienmēr „viens pārvietojums ir divas katastrofas”, bet problēmas migrācijas laikā katru reizi ir atšķirīgas. Šoreiz galvenā grūtība pārvietošanā vienā datu centrā radās no optiskām krustojumiem – to pārpilnība starp stāviem, neapvienojoties vienā kopīgā krustojumā no sakaru operatoriem. Krustojumu aktuālizācijas un pārklāšanas process (kurā mums palīdzēja MMTS-9 inženieri), bija, iespējams, visgrūtākais migrācijas posms.

Otrā migrācija notika pirms gada, 2019. gadā, pārvācāmies no ne pārāk labas datu centra uz O2xygen. Pārvākšanās iemesli bija līdzīgi iepriekš minētajiem, taču tiem pievienojās problēma ar sākotnējā datu centra nepievilcību sakaru operatoriem – daudziem pakalpojumu sniedzējiem nācās „noķert” līdz šai vietai pašiem.

Migrācija 13 stendiem uz kvalitatīvu vietu MMTS-9 ļāva attīstīt šo lokāciju ne tikai kā operatoru (dažas stendi un operatoru „pārnēsāšana”), bet arī izmantot kā vienu no galvenajām. Tas nedaudz atviegloja pārvākšanos no ne pārāk labā datu centra – lielāko daļu aprīkojuma mēs pārvācām uz citu vietu, bet O2xygen ieguva attīstības lomu, nosūtot tur 5 stendus ar aprīkojumu.

Šodien O2xygen jau ir pilnvērtīga vieta, kur „ieradās” nepieciešamie operātori un turpina pieslēgties jauni. O2xygen operatoriem izrādījās arī pievilcīgs no stratēģiskā attīstības viedokļa.

Mēs noteikti veicam galveno pārvākšanās posmu vienā naktī, un migrācijas laikā gan MMTS-9, gan uz O2xygen mēs ievērojam šo noteikumu. Uzsveram, ka noteikums „pārvākšanās vienā naktī” ir stingri jāievēro neatkarīgi no stendu skaita! Bija pat precedents, kad mēs pārvācām 20 stendus un to izdarījām arī vienā naktī. Migrācija ir diezgan viegls process, kas prasa precizitāti un secību, taču arī šeit ir dažas nianses gan sagatavošanās procesā, gan pārvākšanās laikā, un jaunu lokāciju izvēršanā. Par migrāciju detaļās mēs esam gatavi detalizēti pastāstīt, ja jūs interesē.

Rezultāti Mums patīk piecu gadu attīstība. Mēs pabeidzām jaunās nepārtrauktas infrastruktūras izveidi, kas sadalīta trīs datu apstrādes centros. Strauji palielinājām datu plūsmas blīvumu – ja nesen priecājāmies par 40–80G ar 2U, tad tagad ir norma nodot 100G ar 1U. Tagad arī terabitu datu plūsma mums šķiet parasta. Mēs esam gatavi turpināt attīstīt mūsu infrastruktūru, kas ir iznākusi elastīga un mērogojama.

Jautājums: Par ko mēs stāstīsim nākamajos tekstos, cienījamie lasītāji? Par to, kāpēc mēs sākām izstrādāt pašmāju datu glabāšanas sistēmas? Par tīkla kodolu un tā īpatnībām? Par viltībām un niansēm migrācijā starp datu centriem? Par risinājumu optimizāciju, izvēloties komponentes un precīzi iestatot parametrus? Par izturīgu risinājumu radīšanu, pateicoties vairākkārtējai dublēšanai un horizontālajām mērogošanas iespējām datu centrā, kas realizētas trīs datu centru struktūrā?

Autors: Pēteris Vinogradovs — Tehniskais direktors Uma.Tech Žurkas

Avots: habr.com