Oleme käivitanud uusi teenuseid, liiklus on kasvanud, asendanud servereid, lukuavad uutest kohtadest ja ümber planeerinud andmekeskusi – nüüd jagame seda lugu, mille algusega tutvustasime teid viis aastat tagasi..
Viis aastat on iseloomulik aeg vahekokkuvõtete tegemiseks. Seetõttu otsustasime rääkida meie infrastruktuuri arengust, mis on viie aasta jooksul läbinud uskumatult huvitava arengu, millega me uhkustame. Meie teostatavad kvantitatiivsed muudatused on muutunud kvalitatiivseteks, nüüd suudab infrastruktuur töötada režiimides, mis kümnendi keskel tundusid fantastilised.
Tagame keeruliste projektide toimimise äärmiselt rangete usaldusväärsuse ja koormusnõudmistega, sealhulgas PREMIER ja Match TV. Spordisüžees ja populaarsete sari-de esialgetel on vajalik andmete edastamine terabittides/s, me saame seda kergesti teostada, ja meil on selliste kiirus nende jaoks tavapärane. Viis aastat tagasi oli meie süsteemides kõige keerulisem projekt Rutube, mis on sellest ajast alates arenenud, suurendanud mahtusid ja liiklust, mida oli vaja koormuste planeerimise juures arvesse võtta.
Oleme jutustanud, kuidas me arendasime meie infrastruktuuri "hardware'i" () ja arendasime välja süsteemi, mis vastutab video edastamise eest (), kuid sellest ajast on möödunud palju aega, on loodud ja kasutusele võetud palju muid lahendusi, mille tulemused võimaldavad meil vastata kaasaegsetele nõudmistele ja olla piisavalt paindlikud, et ümber kujundada uusi ülesandeid.
Võrgutsentrum areneb pidevalt. Siirdusime 2015. aastal Cisco seadmetele, millest mainisime juba eelnevas artiklis. Siis olid need endiselt 10/40G, kuid mõistlikel põhjustel moderniseerime olemasolevaid šasiisid ja nüüd kasutame aktiivselt ka 25/100G.
100G lingid ei ole ammu enam luksus (pigem on see meie valdkonnas tungiv nõudmine) ega haruldus (üha rohkem operaatorid pakuvad selliseid kiirusel ühendusi). Siiski on 10/40G endiselt asjakohane: nende linkide kaudu ühendame jätkuvalt operaatorid, kellel on väike liiklusmaht, mille jaoks ei ole hetkel mõistlik rakendada suuremat porti.
Meie loodud võrgu tuum väärib eraldi arutamist ja hiljem saab see teema iseseisva artikli jaoks. Seal süveneme tehnilistesse detailidesse ja vaatame lähemalt meie tegutsemise loogikat selle loomisel. Kuid jätkame praegu infrastruktuuri joonistamist pigem skeemiliselt, kuna teie tähelepanu, austatud lugejad, ei ole ilma piiranguteta.
Videote serverid areneb kiiresti, millele me panustame palju pingutusi. Kui varem kasutasime peamiselt 2U servereid, millel oli 4-5 võrgukaarti, millel igal oli kaks 10G-porti, siis nüüd enamiku liiklusest edastavad 1U serverid, milles on 2-3 kaarti, igal kahel on kaks 25G-porti. 10G ja 25G kaardid on oma hinnas praktiliselt võrdsed ning kiiremad lahendused võimaldavad edastada nii 10G kui 25G. Tulemuseks on selge kokkuhoid: vähem serveri komponente ja kaableid, seega madalam hind (ja suurem usaldusväärsus), komponendid võtavad vähem ruumi rackis – rohkem servereid saab paigutada ruutmeetri kohta, seega on rentimise hind madalam.
Aga olulisem on kiirusest saadud kasu! Nüüd suudame 1U-st edastada rohkem kui 100G! Ja see olukorras, kus mõned suured vene projektid nimetavad saavutuseks 40G edastamist 2U-st. Meie sooviksime, et neil oleks need probleemid!
Tähtis on märkida, et 10G ainult töötavatest võrgukaartide põlvkonda me kasutame endiselt. See varustus töötab stabiilselt ja on meile hästi tuttav, seetõttu ei ole me seda välja visanud, vaid leidnud sellele uue rakenduse. Need komponendid paigaldasime videode salvestusserveritesse, mille jaoks on juba tõhusaks tööks ilmselgelt liiga vähe ühte või kahte 1G liidest, siin 10G kaardid osutusid asjakohasteks.
Andmete salvestussüsteemid kasvavad. Viimase viie aasta jooksul on nad kaheteistkümne kõvakettaga (12x HDD 2U) muutunud kolmkümmend kuue kõvakettaga (36x HDD 4U). Sellised mahukad "korpused" tekitavad mõne kasutaja seas hirmu, kuna ühe sellise šassii riknemisel võib tekkida oht kogu süsteemi jõudlusele – isegi töövõimele! – Kuid meil seda ei juhtu: oleme taganud andmete geograafilise redigeerimise tasemel replikatsiooniga. Oleme jaotanud šassiid erinevatesse andmekeskustesse – kokku kasutame kolme – ja see välistab probleemide tekkimise nii šassiides rikete korral kui ka töökoha langemisel.
Muidugi on see lähenemine teinud riistvara RAID'i üleliigseks, millest oleme loobunud. Üksnes üleliigsuse eemaldamine on samal ajal suurendanud süsteemi usaldusväärsust, lihtsustades lahendust ja eemaldades ühe võimalikest rikkepunktidest. Tuletame meelde, et meie salvestuslahendus on "isetehtud". Selle lähenemise valisime täiesti teadlikult ja tulemus meie jaoks sobib täiesti.
Andmekeskused oleme viie aasta jooksul vahetanud mitu korda. Alates eelmine artikli kirjutamisest ei ole me vahetanud ainult ühte andmekeskust – DataLine – kõik teised nõudsid vahetamist meie infrastruktuuri arengu käigus. Kõik liikumised kohtade vahel olid planeeritud.
Kaks aastat tagasi migreerisime MMTs-9 sees, liikudes kohale, kus oli kvaliteetne remont, hea jahutussüsteem, stabiilne elektrivarustus ja ilma tolmuta, mis varem kattis kõiki pindu paksude kihtidena ja ummistas ulatuslikult meie seadmete sisu. Kvaliteeti teenuseid – ja tolmu puudumist! – eelistamine oli meie kolimise põhjus.
Peaaegu alati "üks kolimine on võrdsed kahe tulekahjuga", kuid migreerimise probleemid on iga kord erinevad. Seekord peamine raskus ühe andmekeskuse sees ülemisel tasemel "tagasid" optilised rististuskeemid – nende vahekorralduse rohkus ilma telekommunikatsiooni operaatorite poolt ühte ristumisse viimisega. Ristimiste ajakohastamine ja ümberplaaneerimine (milles aitasid meid MMTs-9 insenerid) oli ilmselt kolimise kõige keerulisem etapp.
Teine migratsioon toimus aast tagasi, 2019. aastal kolisime me mitte just parimast andmekeskusest O2xygenisse. Kolimise põhjused olid sarnased eespool käsitletud, kuid neile lisandus probleem, et lähteandmekeskus polnud teenusepakkujate jaoks piisavalt atraktiivne – paljusid teenusepakkujaid tuli „jõuda” oma jõududega sellele punktile.
13 rack'i migratsioon kvaliteetsesse asukohta MMTS-9-s võimaldas arendada seda asukohta mitte ainult operaatorina (paar rack'i ja operaatorite „ühendused”), vaid ka kasutada seda ühe peamise teenusena. See lihtsustas migratsiooni mitte just parimast andmekeskusest – enamus seadmetest, mis sealt, me kolisime teise kohta, ja O2xygenile määrasime areneva rolli, saates sinna 5 rack'i seadmetega.
Tänaseks on O2xygen juba täisväärtuslik asukoht, kuhu on „tulnud” vajalikud operaatorid ja uued jätkavad liitumist. O2xygen on operaatorite jaoks osutunud samuti atraktiivseks strateegilise arengu seisukohalt.
Peamise kolimise etapi viime kindlasti läbi ühe öö jooksul, ja MMTS-9 ja O2xygenisse migratsiooni ajal järgime seda reeglit. Rõhutame, et reegel „kolimine ühe öö jooksul” on meil rangelt täidetud olenemata rack'ide arvust! Oli isegi juhtum, kui kolisime 20 rack'i ja täitsime seda samuti ühe öö jooksul. Migratsioon on piisavalt lihtne protsess, mis nõuab täpsust ja järjekindlust, kuid siin on ka mõned nipid nii ettevalmistamise, kolimise kui ka uues asukohas kasutuselevõtu käigus. Migratsioonist detailides oleme valmis põhjalikult rääkima, kui teil on huvi.
tulemused näitasid ainult nelja ebaolulise koodibloki kattuvust, mis olid tingitud POSIX ja ANSI C nõuetest. Meile meeldivad viieaastased arengud. Oleme lõpetanud uue tõrgeteta infrastruktuuri ehitamise, mis on jaotatud kolme andmekeskuse vahel. Oleme dramaatiliselt suurendanud liikluse andmisvõimet - kui hiljuti nautisime 40-80G 2U-l, siis praegu on meil normaalseks anda 100G 1U-l. Nüüd tajume terabiti liiklust juba igapäevasena. Oleme valmis edasi arendama meie infrastruktuuri, mis on saadud paindlikuks ja skaleeritavaks.
Küsimus: Millest rääkida järgmistes tekstides, kallid lugejad? Miks me hakkasime looma kohandatud andmemagasi süsteeme? Võrgukihist ja selle omadustest? Nipid ja nurgad andmekeskuste vahel migreerimise osas? Lahenduste optimeerimisest komponentide valimise ja parameetrite peenhäälestamise kaudu? Jõuliste lahenduste loomine tänu mitmekordsele varundamisele ja horisontaalsetele skaleerimisvõimalustele andmekeskuses, mis on rakendatud kolme andmekeskuse struktuuris?
Autor: Peter Vinogradov — Uma.Tech tehniline direktor
Allikas: habr.com
