Как Uma.Tech разработи инфраструктура

Пуснахме нови услуги, трафикът нарасна, сменихме сървъри, свързахме нови сайтове и реконструирахме центрове за данни - и сега ще разкажем тази история, с чието начало ви запознахме преди пет години.

Пет години е типично време за обобщаване на междинни резултати. Затова решихме да поговорим за развитието на нашата инфраструктура, която през последните пет години премина през изненадващо интересен път на развитие, с което се гордеем. Количествените промени, които направихме, се превърнаха в качествени, сега инфраструктурата може да работи в режими, които изглеждаха фантастични в средата на миналото десетилетие.

Осигуряваме експлоатацията на най-сложните обекти с най-строги изисквания за надеждност и натоварвания, включително PREMIER и Match TV. Спортните предавания и премиерите на популярни телевизионни сериали изискват трафик в терабита/сек, ние лесно прилагаме това и толкова често, че работата с такива скорости отдавна е станала обичайна за нас. А преди пет години най-тежкият проект, изпълняван на нашите системи, беше Rutube, който оттогава се разви, увеличи обемите и трафика, което трябваше да се вземе предвид при планирането на натоварванията.

Говорихме за това как разработихме хардуера на нашата инфраструктура („Rutube 2009-2015: историята на нашия хардуер“) и разработи система, отговорна за качването на видеоклипове („От нула до 700 гигабита в секунда - как един от най-големите сайтове за видео хостинг в Русия качва видео“), но измина много време от написването на тези текстове, бяха създадени и внедрени много други решения, резултатите от които ни позволяват да отговаряме на съвременните изисквания и да бъдем достатъчно гъвкави, за да се адаптираме към нови задачи.

Мрежово ядро Постоянно се развиваме. Преминахме към оборудване на Cisco през 2015 г., за което споменахме в предишната статия. Тогава все още беше същото 10/40G, но по очевидни причини след няколко години надстроиха съществуващото шаси и сега активно използваме 25/100G.

100G връзките отдавна не са нито лукс (по-скоро това е спешно изискване на времето в нашия сегмент), нито рядкост (все повече оператори предоставят връзки с такива скорости). Въпреки това 10/40G остава актуален: чрез тези връзки ние продължаваме да свързваме оператори с малко количество трафик, за които в момента е неподходящо да се използва по-голям порт.

Мрежовото ядро, което създадохме, заслужава отделно разглеждане и ще стане тема на отделна статия малко по-късно. Там ще се задълбочим в техническите подробности и ще разгледаме логиката на нашите действия при създаването му. Но сега ще продължим да рисуваме инфраструктурата по-схематично, тъй като вашето внимание, скъпи читатели, не е неограничено.

Сървъри за видео изход се развиват бързо, за което предлагаме много усилия. Ако по-рано използвахме предимно 2U сървъри с 4-5 мрежови карти с по два 10G порта, сега по-голямата част от трафика се изпраща от 1U сървъри, които имат 2-3 карти с по два 25G порта. Картите с 10G и 25G са почти еднакви по цена, а по-бързите решения ви позволяват да предавате както през 10G, така и през 25G. Резултатът беше очевидна икономия: по-малко сървърни компоненти и кабели за връзка - по-ниска цена (и по-висока надеждност), компонентите заемат по-малко място в шкафа - стана възможно да се поставят повече сървъри на единица площ и следователно по-ниски разходи за наем.

Но по-важното е печалбата в скоростта! Сега можем да изпратим повече от 1G с 100U! И това е на фона на ситуация, при която някои големи руски проекти наричат ​​40G изход от 2U „постижение“. Бихме искали техните проблеми!

Обърнете внимание, че все още използваме поколение мрежови карти, които могат да работят само на 10G. Това оборудване работи стабилно и ни е много познато, така че не го изхвърлихме, а намерихме ново приложение за него. Инсталирахме тези компоненти в сървъри за съхранение на видео, за които един или два 1G интерфейса очевидно не са достатъчни, за да работят ефективно; тук 10G картите се оказаха подходящи.

Системи за съхранение също нарастват. През последните пет години те се промениха от дванадесет диска (12x HDD 2U) на тридесет и шест диска (36x HDD 4U). Някои се страхуват да използват такива обемисти „трупове“, тъй като ако едно такова шаси се повреди, може да има заплаха за производителността - или дори за оперативността! – за цялата система. Но това няма да се случи с нас: ние сме осигурили резервно копие на ниво гео-разпространени копия на данни. Разпределихме шасито в различни центрове за данни - използваме общо три - и това елиминира възникването на проблеми както при повреди в шасито, така и при падане на сайта.

Разбира се, този подход направи хардуерния RAID излишен, който ние изоставихме. Чрез елиминиране на излишъка, ние едновременно увеличихме надеждността на системата, като опростихме решението и премахнахме една от потенциалните точки на повреда. Нека ви напомним, че нашите системи за съхранение са „самоделни“. Направихме това съвсем съзнателно и бяхме напълно доволни от резултата.

Центрове за данни През последните пет години се променихме няколко пъти. От написването на предишната статия не сме променили само един център за данни - DataLine - останалите изискват подмяна с развитието на нашата инфраструктура. Всички трансфери между обекти бяха планирани.

Преди две години мигрирахме вътре в MMTS-9, като се преместихме на място с висококачествени ремонти, добра охладителна система, стабилно захранване и липса на прах, който преди това лежеше на дебели слоеве върху всички повърхности и също така запушваше вътрешността на нашето оборудване . Изберете качествени услуги – и без прах! – стана причината за преместването ни.

Почти винаги „едно движение се равнява на два пожара“, но проблемите по време на миграцията са различни всеки път. Този път основната трудност при движение в рамките на един център за данни беше „осигурена“ от оптични кръстосани връзки - изобилието им между етажите, без да се комбинират в единична кръстосана връзка от телеком операторите. Процесът на актуализиране и пренасочване на кръстосани връзки (с който инженерите на MMTS-9 ни помогнаха) беше може би най-трудният етап от миграцията.

Втората миграция се проведе преди година; през 2019 г. се преместихме от не много добър център за данни към O2xygen. Причините за преместването бяха подобни на тези, обсъдени по-горе, но те бяха допълнени от проблема с непривлекателността на първоначалния център за данни за телекомуникационните оператори - много доставчици трябваше да „наваксат“ до този момент сами.

Миграцията на 13 стелажа към висококачествен сайт в MMTS-9 направи възможно това местоположение да се развие не само като местоположение на оператор (няколко стелажа и „напред“ на операторите), но и да се използва като един от главните. Това донякъде опрости миграцията от не много добър център за данни - транспортирахме по-голямата част от оборудването от него на друг сайт, а O2xygen получи ролята на развиващ се, като изпрати там 5 стелажа с оборудване.

Днес O2xygen вече е пълноценна платформа, където операторите, от които се нуждаем, са „пристигнали“ и нови продължават да се свързват. За операторите O2xygen се оказа привлекателен и от гледна точка на стратегическо развитие.

Винаги извършваме основната фаза на преместването за една нощ и при мигриране в рамките на MMTS-9 и към O2xygen се придържахме към това правило. Подчертаваме, че спазваме стриктно правилото за преместване за една нощ, независимо от броя на стелажите! Дори имаше прецедент, когато преместихме 20 стелажа и завършихме това също за една нощ. Миграцията е доста прост процес, който изисква точност и последователност, но тук има някои трикове, както в процеса на подготовка, така и при преместване и при разполагане на ново място. Готови сме да говорим подробно за миграцията, ако проявявате интерес.

резултати Харесваме петгодишните планове за развитие. Завършихме изграждането на нова устойчива на грешки инфраструктура, разпределена в три центъра за данни. Рязко увеличихме плътността на трафика - ако наскоро бяхме доволни от 40-80G с 2U, сега нормата за нас е 100G с 1U. Сега дори терабит трафик се възприема от нас като нещо обичайно. Готови сме да доразвием нашата инфраструктура, която се оказа гъвкава и мащабируема.

Въпрос: За какво да ви разкажа в следващите текстове, уважаеми читатели? Защо започнахме да създаваме домашни системи за съхранение на данни? За ядрото на мрежата и неговите характеристики? За триковете и тънкостите на миграцията между центрове за данни? Относно оптимизирането на решенията за доставка чрез избиране на компоненти и фина настройка на параметрите? Относно създаването на устойчиви решения благодарение на множество резервирания и възможности за хоризонтално мащабиране в рамките на център за данни, които са внедрени в структура от три центъра за данни?

Автор: Петър Виноградов – технически директор на Uma.Tech Хамстерите

Източник: www.habr.com