Біз жаңа қызметтерді іске қостық, трафик өсті, серверлерді ауыстырдық, жаңа сайттарды қостық және деректер орталықтарын қайта құрдық - енді біз осы оқиғаны баяндаймыз, оның басын бес жыл бұрын таныстырдық..
Бес жыл - аралық нәтижелерді шығарудың әдеттегі уақыты. Сондықтан біз соңғы бес жыл ішінде біз мақтан тұтатын таңғаларлық қызықты даму жолынан өткен инфрақұрылымымыздың дамуы туралы айтуды жөн көрдік. Біз енгізген сандық өзгерістер сапалы өзгерістерге айналды, енді инфрақұрылым соңғы онжылдықтың ортасында фантастикалық болып көрінген режимдерде жұмыс істей алады.
Біз PREMIER және Match TV қоса алғанда, сенімділік пен жүктемелерге ең қатаң талаптары бар ең күрделі жобалардың жұмысын қамтамасыз етеміз. Спорттық хабарлар мен танымал телехикаялардың премьерасы терабит/с трафикті қажет етеді, біз мұны оңай жүзеге асырамыз, сондықтан мұндай жылдамдықпен жұмыс істеу біз үшін бұрыннан үйреншікті нәрсеге айналды. Ал бес жыл бұрын біздің жүйелерімізде жұмыс істейтін ең ауыр жоба Rutube болды, ол содан бері дамыды, жүктерді жоспарлау кезінде ескерілуі керек көлемдер мен трафикті арттырды.
Біз инфрақұрылымымыздың аппараттық құралдарын қалай дамытқанымыз туралы айттық () және бейнелерді жүктеп салуға жауапты жүйені әзірледі (), бірақ бұл мәтіндер жазылғаннан бері көп уақыт өтті, көптеген басқа шешімдер жасалды және жүзеге асырылды, олардың нәтижелері заманауи талаптарға жауап беруге және жаңа міндеттерге бейімделуге жеткілікті икемді болуға мүмкіндік береді.
Желілік ядро Біз үнемі дамып келеміз. Біз алдыңғы мақалада айтқан Cisco жабдығына 2015 жылы ауыстық. Ол кезде бұрынғыдай 10/40G болды, бірақ белгілі себептермен бірнеше жылдан кейін олар бар шассиді жаңартты, ал қазір біз 25/100G белсенді түрде қолданамыз.
100G сілтемелері әлдеқашан сән-салтанат емес (дәлірек айтсақ, бұл біздің сегменттегі уақыттың өзекті талабы), сирек те (мұндай жылдамдықпен байланыстарды көбірек операторлар қамтамасыз етеді). Дегенмен, 10/40G өзекті болып қала береді: осы сілтемелер арқылы біз трафиктің аз мөлшері бар операторларды қосуды жалғастырамыз, бұл үшін қазіргі уақытта неғұрлым сыйымды портты пайдалану орынсыз.
Біз жасаған желілік ядро бөлек қарастыруға лайық және сәл кейінірек бөлек мақаланың тақырыбы болады. Онда біз техникалық мәліметтерді қарастырамыз және оны жасау кезінде өз әрекеттеріміздің логикасын қарастырамыз. Бірақ енді біз инфрақұрылымды схемалық түрде салуды жалғастырамыз, өйткені сіздердің назарларыңыз, құрметті оқырмандар, шексіз емес.
Бейне шығыс серверлері тез дамиды, ол үшін біз көп күш салуды ұсынамыз. Егер бұрын біз әрқайсысында екі 2G порты бар 4-5 желілік картасы бар 10U серверлерін пайдаланатын болсақ, қазір трафиктің көп бөлігі әрқайсысында екі 1G порты бар 2-3 картадан тұратын 25U серверлерінен жіберіледі. 10G және 25G карталары құны бойынша дерлік бірдей және жылдамырақ шешімдер 10G және 25G арқылы жіберуге мүмкіндік береді. Нәтиже айқын үнемдеу болды: қосылуға арналған серверлік құрамдас бөліктер мен кабельдердің аздығы – төмен баға (және жоғары сенімділік), құрамдас бөліктер сөреде аз орын алады – аудан бірлігіне көбірек серверлерді орналастыру және, демек, жалға алу құнын төмендету мүмкін болды.
Бірақ одан да маңыздысы - жылдамдықты арттыру! Енді біз 1U арқылы 100G-ден астам жібере аламыз! Бұл кейбір ірі ресейлік жобалар 40U-дан 2G шығысын «жетістік» деп атайтын жағдайдың фонында. Біз олардың проблемаларын қалаймыз!
Біз әлі де тек 10G-де жұмыс істей алатын желілік карталардың генерациясын қолданатынымызды ескеріңіз. Бұл жабдық тұрақты жұмыс істейді және бізге өте таныс, сондықтан біз оны тастамадық, бірақ оның жаңа қолданылуын таптық. Біз бұл компоненттерді бейне сақтау серверлеріне орнаттық, олар үшін бір немесе екі 1G интерфейсі тиімді жұмыс істеу үшін жеткіліксіз; мұнда 10G карталары өзекті болып шықты.
Сақтау жүйелері да өсіп келеді. Соңғы бес жылда олар он екі дискіден (12x HDD 2U) отыз алты дискіге (36x HDD 4U) өзгерді. Кейбіреулер мұндай сыйымды «ұшаларды» пайдаланудан қорқады, өйткені егер мұндай шассидің біреуі істен шықса, өнімділікке, тіпті жұмысқа қабілеттілікке қауіп төнуі мүмкін! – бүкіл жүйе үшін. Бірақ бұл бізде болмайды: біз деректердің гео-таратылған көшірмелері деңгейінде сақтық көшірме жасадық. Біз шассиді әртүрлі деректер орталықтарына тараттық - біз барлығы үшеуін қолданамыз - бұл шассидегі ақаулар кезінде де, сайт құлаған кезде де проблемалардың пайда болуын болдырмайды.
Әрине, бұл тәсіл RAID аппараттық құралдарын артық етті, біз оны тастадық. Артықшылықты жою арқылы біз бір уақытта шешімді жеңілдету және сәтсіздіктің ықтимал нүктелерінің бірін жою арқылы жүйенің сенімділігін арттырдық. Естеріңізге сала кетейік, біздің сақтау жүйелеріміз «үйде жасалған». Біз мұны әдейі жасадық және нәтижеге толықтай қанағаттандық.
Деректер орталықтары Соңғы бес жылда біз бірнеше рет өзгердік. Алдыңғы мақаланы жазғаннан бері біз бір ғана деректер орталығын өзгерткен жоқпыз - DataLine - инфрақұрылым дамыған сайын қалғанын ауыстыру қажет. Сайттар арасындағы барлық тасымалдаулар жоспарланған болатын.
Екі жыл бұрын біз MMTS-9 ішіне көшіп келдік, ол жоғары сапалы жөндеуден өткен, жақсы салқындату жүйесі, тұрақты қуат көзі және шаңсыз, бұрын барлық беттерде қалың қабаттарда жатқан, сонымен қатар біздің жабдықтың ішін бітеп тастаған. . Сапалы қызметтерді таңдаңыз – шаңсыз! – көшуімізге себеп болды.
Әрқашан дерлік «бір қозғалыс екі отқа тең», бірақ көші-қон кезіндегі мәселелер әр уақытта әртүрлі. Бұл жолы бір деректер орталығының ішінде қозғалудың негізгі қиындығы оптикалық кросс-байланыстармен «қамтамасыз етілді» - олардың байланыс операторлары бір кросс-коннектке біріктірілместен қабаттар арасындағы көптігі. Көлденең қосылымдарды жаңарту және қайта бағыттау процесі (мұмен MMTS-9 инженерлері бізге көмектесті) көші-қонның ең қиын кезеңі болды.
Екінші көші-қон бір жыл бұрын болды; 2019 жылы біз өте жақсы емес деректер орталығынан O2xygen-ге көштік. Қозғалу себептері жоғарыда талқыланғандарға ұқсас болды, бірақ олар байланыс операторлары үшін бастапқы деректер орталығының тартымсыздығы мәселесімен толықтырылды - көптеген провайдерлер осы уақытқа дейін «қуып жетуге» мәжбүр болды.
MMTS-13-да 9 тіректерді сапалы сайтқа көшіру бұл орынды оператордың орналасқан жері ретінде ғана емес (операторлардың бірнеше тіректері мен «алғалары»), сонымен қатар оны пайдаланудың бірі ретінде пайдалануға мүмкіндік берді. негізгілері. Бұл өте жақсы емес деректер орталығынан көшіруді біршама жеңілдетті - біз одан жабдықтың көп бөлігін басқа сайтқа тасымалдадық, ал O2xygen-ге жабдықпен бірге 5 тірек жіберіп, дамушы рөлі берілді.
Бүгінгі күні O2xygen қазірдің өзінде толыққанды платформа болып табылады, мұнда бізге қажет операторлар «келді» және жаңалары қосылуды жалғастыруда. Операторлар үшін O2xygen стратегиялық даму тұрғысынан да тартымды болып шықты.
Біз жылжудың негізгі кезеңін әрқашан бір түнде орындаймыз және MMTS-9 шегінде және O2оксигенге көшкен кезде біз осы ережені ұстандық. Біз сөрелердің санына қарамастан «түнде көшу» ережесін қатаң сақтайтынымызды атап өтеміз! Тіпті 20 сөрені жылжытып, оны бір түнде аяқтаған кездегі жағдай болды. Көшіру - бұл дәлдік пен жүйелілікті талап ететін өте қарапайым процесс, бірақ мұнда дайындық процесінде де, жылжытқанда да, жаңа орынға орналастыру кезінде де кейбір амалдар бар. Егер сізді қызықтырса, біз көші-қон туралы егжей-тегжейлі сөйлесуге дайынбыз.
нәтижелері Бізге бес жылдық даму жоспарлары ұнайды. Біз үш деректер орталығына бөлінген ақауларға төзімді жаңа инфрақұрылымның құрылысын аяқтадық. Біз трафиктің тығыздығын күрт арттырдық - егер жақында біз 40U-мен 80-2G-ге риза болсақ, қазір біз үшін норма - 100U-мен 1G. Қазір тіпті терабит трафикті біз үйреншікті құбылыс ретінде қабылдаймыз. Біз икемді және ауқымды болып шыққан инфрақұрылымымызды одан әрі дамытуға дайынбыз.
Сұрақ: Келесі мәтіндерде мен сізге не туралы айтуым керек, құрметті оқырмандар? Неліктен біз қолдан жасалған деректерді сақтау жүйелерін жасай бастадық? Желінің өзегі және оның мүмкіндіктері туралы? Деректер орталықтары арасындағы көші-қонның амалдары мен нәзіктіктері туралы? Құрамдас бөліктерді таңдау және параметрлерді дәл баптау арқылы жеткізу шешімдерін оңтайландыру туралы ма? Үш деректер орталығының құрылымында жүзеге асырылатын деректер орталығындағы бірнеше резервтік және көлденең масштабтау мүмкіндіктерінің арқасында тұрақты шешімдерді жасау туралы ма?
Авторы: Петр Виноградов – Uma.Tech техникалық директоры
Ақпарат көзі: www.habr.com