Ni lanĉis novajn servojn, trafiko kreskis, anstataŭigis servilojn, konektis novajn retejojn kaj restrukturitajn datumcentrojn - kaj nun ni rakontos ĉi tiun historion, kies komencon ni prezentis al vi antaŭ kvin jaroj..
Kvin jaroj estas tipa tempo por resumi provizorajn rezultojn. Tial ni decidis paroli pri la evoluo de nia infrastrukturo, kiu dum la lastaj kvin jaroj trairis surprize interesan vojon de evoluo, pri kiu ni fieras. La kvantaj ŝanĝoj, kiujn ni efektivigis, fariĝis kvalitaj; nun la infrastrukturo povas funkcii en reĝimoj kiuj ŝajnis mirindaj en la mezo de la lasta jardeko.
Ni certigas la funkciadon de la plej kompleksaj projektoj kun la plej striktaj postuloj por fidindeco kaj ŝarĝoj, inkluzive de PREMIER kaj Match TV. Sportaj elsendoj kaj la premiero de popularaj televidserioj postulas trafikon en terabit/s, ni facile efektivigas tion, kaj tiel ofte ke labori kun tiaj rapidoj jam delonge fariĝis ordinara por ni. Kaj antaŭ kvin jaroj, la plej peza projekto funkcianta sur niaj sistemoj estis Rutube, kiu ekde tiam disvolviĝis, pliigis volumojn kaj trafikon, kiujn oni devis konsideri dum planado de ŝarĝoj.
Ni parolis pri kiel ni evoluigis la aparataron de nia infrastrukturo () kaj evoluigis sistemon respondecan por alŝutado de videoj (), sed multe da tempo pasis de kiam tiuj tekstoj estis verkitaj, multaj aliaj solvoj estis kreitaj kaj efektivigitaj, kies rezultoj ebligas al ni plenumi modernajn postulojn kaj esti sufiĉe flekseblaj por adaptiĝi al novaj taskoj.
Reta kerno Ni konstante evoluas. Ni ŝanĝis al Cisco-ekipaĵo en 2015, kiun ni menciis en la antaŭa artikolo. Tiam ĝi ankoraŭ estis la sama 10/40G, sed pro evidentaj kialoj, post kelkaj jaroj ili ĝisdatigis la ekzistantan ĉasion, kaj nun ni aktive uzas 25/100G.
100G-ligoj longe estas nek lukso (prefere, ĉi tio estas urĝa postulo de la tempo en nia segmento), nek maloftaĵo (pli kaj pli da telefonistoj provizas konektojn kun tiaj rapidecoj). Tamen, 10/40G restas grava: per ĉi tiuj ligiloj ni daŭre ligas telefonistojn kun malgranda kvanto da trafiko, por kiu nuntempe estas netaŭge uzi pli ampleksan havenon.
La retkerno, kiun ni kreis, meritas apartan konsideron kaj fariĝos temo de aparta artikolo iom poste. Tie ni enprofundiĝos en teknikajn detalojn kaj konsideros la logikon de niaj agoj kreante ĝin. Sed nun ni daŭre desegnos la infrastrukturon pli skeme, ĉar via atento, karaj legantoj, ne estas senlima.
Serviloj de eligo de video evoluas rapide, por kio ni proponas multe da penado. Se pli frue ni uzis ĉefe 2U-servilojn kun 4-5 retkartoj kun po du 10G-havenoj, nun la plej granda parto de la trafiko estas sendita de 1U-serviloj, kiuj havas 2-3-kartojn kun po du 25G-havenoj. Kartoj kun 10G kaj 25G estas preskaŭ egalaj en kosto, kaj pli rapidaj solvoj permesas vin transdoni super ambaŭ 10G kaj 25G. La rezulto estis evidenta ŝparado: malpli da servilkomponentoj kaj kabloj por konekto - pli malalta kosto (kaj pli alta fidindeco), komponantoj okupas malpli da spaco en la rako - eblis meti pli da serviloj por unuopa areo kaj, do, pli malaltaj lukostoj.
Sed pli grava estas la gajno en rapideco! Nun ni povas sendi pli ol 1G kun 100U! Kaj ĉi tio estas kontraŭ la fono de situacio kie iuj grandaj rusaj projektoj nomas 40G-produktadon de 2U "atingo". Ni ŝatus iliajn problemojn!
Notu, ke ni ankoraŭ uzas la generacion de retaj kartoj, kiuj povas funkcii nur per 10G. Ĉi tiu ekipaĵo funkcias stabile kaj estas tre konata al ni, do ni ne forĵetis ĝin, sed trovis novan uzon por ĝi. Ni instalis ĉi tiujn komponantojn en serviloj de video-stokado, por kiuj unu aŭ du 1G-interfacoj klare ne sufiĉas por funkcii efike; ĉi tie 10G-kartoj montriĝis gravaj.
Stoksistemoj ankaŭ kreskas. Dum la lastaj kvin jaroj, ili ŝanĝiĝis de dekdu-disko (12x HDD 2U) al tridek ses-disko (36x HDD 4U). Iuj timas uzi tiajn ampleksajn "kadavrojn", ĉar se unu tia ĉasio malsukcesas, povas esti minaco al produktiveco - aŭ eĉ funkciigo! – por la tuta sistemo. Sed ĉi tio ne okazos ĉe ni: ni disponigis sekurkopion je la nivelo de geo-distribuitaj kopioj de datumoj. Ni disdonis la ĉasion al malsamaj datumcentroj - ni uzas tri entute - kaj ĉi tio forigas la aperon de problemoj kaj en kazo de misfunkciadoj en la ĉasio kaj kiam la retejo falas.
Kompreneble, ĉi tiu aliro igis aparataron RAID redunda, kiun ni forlasis. Forigante redundon, ni samtempe pliigis sisteman fidindecon simpligante la solvon kaj forigante unu el la eblaj punktoj de fiasko. Ni memorigu vin, ke niaj stokaj sistemoj estas "memfaritaj". Ni faris tion tute intence kaj ni estis tute kontentaj pri la rezulto.
Datumcentroj Dum la pasintaj kvin jaroj ni ŝanĝiĝis plurfoje. Ekde la verkado de la antaŭa artikolo, ni ne ŝanĝis nur unu datumcentron - DataLine - la resto postulis anstataŭaĵon dum nia infrastrukturo disvolviĝis. Ĉiuj translokigoj inter ejoj estis planitaj.
Antaŭ du jaroj, ni migris enen de MMTS-9, moviĝante al loko kun altkvalitaj riparoj, bona malvarmiga sistemo, stabila elektroprovizo kaj neniu polvo, kiu antaŭe kuŝis en dikaj tavoloj sur ĉiuj surfacoj kaj ankaŭ ŝtopis la internojn de nia ekipaĵo. . Elektu kvalitajn servojn - kaj sen polvo! – fariĝis la kialo de nia movo.
Preskaŭ ĉiam "unu movo egalas al du fajroj", sed la problemoj dum migrado estas malsamaj ĉiufoje. Ĉi-foje, la ĉefa malfacilaĵo moviĝi ene de unu datumcentro estis "provizita" de optikaj kruckonektoj - ilia abundo inter etaĝoj sen esti kombinita en ununuran kruckonekton fare de telekomunikaj funkciigistoj. La procezo de ĝisdatigo kaj revojigo de kruckonektoj (kun kiu MMTS-9-inĝenieroj helpis nin) estis eble la plej malfacila etapo de migrado.
La dua migrado okazis antaŭ jaro; en 2019, ni translokiĝis de ne tre bona datumcentro al O2xygen. La kialoj de la movo estis similaj al tiuj supre diskutitaj, sed ili estis kompletigitaj per la problemo de la neallogaĵo de la originala datumcentro por telekomunikaj telefonistoj - multaj provizantoj devis "kapti" ĝis ĉi tiu punkto memstare.
La migrado de 13 rakoj al altkvalita retejo en MMTS-9 ebligis disvolvi ĉi tiun lokon ne nur kiel loko de operaciisto (paro da rakoj kaj "antaŭuloj" de funkciigistoj), sed ankaŭ uzi ĝin kiel unu el la. ĉefaj. Ĉi tio iom simpligis la migradon de ne tre bona datumcentro - ni transportis la plej grandan parton de la ekipaĵo de ĝi al alia retejo, kaj O2xygen ricevis la rolon de evoluiga, sendante 5-rakojn kun ekipaĵo tie.
Hodiaŭ O2xygen jam estas plentaŭga platformo, kie la telefonistoj, kiujn ni bezonas, "alvenis" kaj novaj daŭre konektiĝas. Por funkciigistoj, O2xygen ankaŭ montriĝis alloga el la vidpunkto de strategia disvolviĝo.
Ni ĉiam efektivigas la ĉefan fazon de la movado en unu nokto, kaj migrante ene de MMTS-9 kaj al O2xygen, ni aliĝis al ĉi tiu regulo. Ni emfazas, ke ni strikte sekvas la regulon "movu subite", sendepende de la nombro da rakoj! Ekzistis eĉ precedenco kiam ni movis 20 rakojn kaj kompletigis ĉi tion ankaŭ en unu nokto. Migrado estas sufiĉe simpla procezo, kiu postulas precizecon kaj konsistencon, sed ekzistas iuj lertaĵoj ĉi tie, kaj en la preparprocezo, kaj kiam moviĝas, kaj kiam deplojiĝas al nova loko. Ni pretas detale paroli pri migrado, se vi interesiĝas.
Результаты Ni ŝatas kvinjarajn disvolvajn planojn. Ni finis la konstruadon de nova mistolerema infrastrukturo distribuita tra tri datumcentroj. Ni akre pliigis la trafikan densecon - se lastatempe ni estis feliĉaj kun 40-80G kun 2U, nun la normo por ni estas 100G kun 1U. Nun eĉ terabito da trafiko estas perceptata de ni kiel ordinara. Ni pretas plu evoluigi nian infrastrukturon, kiu montriĝis fleksebla kaj skalebla.
Demando: Pri kio mi diru al vi en la sekvaj tekstoj, karaj legantoj? Pri kial ni komencis krei memfaritajn datumservsistemojn? Pri la reto-kerno kaj ĝiaj trajtoj? Pri la lertaĵoj kaj subtilecoj de migrado inter datumcentroj? Pri optimumigo de liveraj decidoj per elekto de komponantoj kaj fajnagordado de parametroj? Pri kreado de daŭrigeblaj solvoj danke al multoblaj redundoj kaj horizontalaj skalaj kapabloj ene de datumcentro, kiuj estas efektivigitaj en strukturo de tri datumcentroj?
Aŭtoro: Petr Vinogradov - Teknika Direktoro de Uma.Tech
fonto: www.habr.com