Стартирахме нови услуги, трафикът нарастваше, заменявахме сървъри, свързвахме нови платформи и преосновавахме ЦОД-овете – а сега ще разкажем тази история, с която ви запознахме преди пет години..
Пет години – типичен период за обобщение на междинни резултати. Затова решихме да разкажем за развитието на нашата инфраструктура, която през последните пет години премина през изключително интересен път на развитие, от който сме горди. Реализираните от нас количествени промени прераснаха в качествени, сега инфраструктурата може да работи в режими, които в средата на миналото десетилетие изглеждаха като фантастика.
Ние осигуряваме работа на сложни проекти с изключително високи изисквания за надеждност и натоварване, сред които PREMIER и Матч ТВ. За спортните предавания и премиерите на популярни сериали е необходима отдача на трафика в терaбити/с, което лесно реализираме, и то толкова често, че работата с такива скорости отдавна стана за нас обичайна. А преди пет години най-тежкият проект, работещ в нашите системи, беше Rutube, който оттогава се разви, увеличи обемите и трафика, което трябваше да се отчита при планирането на натоварвания.
Разказвахме как развивахме „железото“ на нашата инфраструктура () и развивахме системата, отговорна за отдаванията на видео (), но от написването на тези текстове е минало много време, създадени и внедрени са множество други решения, чиито резултати ни позволяват да отговаряме на съвременните изисквания и да бъдем достатъчно еластични, за да се пренастройваме за нови задачи.
Мрежовото ядро постоянно се развива. Преминахме на оборудване Cisco през 2015 година, за което споменахме и в предишната статия. Тогава това бяха 10/40G, но по разбираема причина, след няколко години модернизирахме съществуващите шаси и сега активно използваме и 25/100G.
100G линковете отдавна не са нито лукс (по-скоро, те представляват спешно изискване на времето в нашия сектор), нито рядкост (все повече оператори предлагат свързаност с такива скорости). Въпреки това, 10/40G остава актуално: през тези линкове продължаваме да свързваме оператори с малък обем трафик, за които в момента не е целесъобразно да се използва по-емко порт.
Създаденото от нас мрежово ядро заслужава отделно разглеждане и по-късно ще стане тема на отделна статия. Там ще задълбочим техническите детайли и ще разгледаме логиката на нашите действия при неговото създаване. Но сега ще продължим да рисуваме инфраструктурата по-скоро схематично, тъй като вашето внимание, уважаеми читатели, не е безкрайно.
Сервери за видеостриминг еволюират бързо, за което полагаме много усилия. Ако преди използвахме предимно 2U сървъри с 4-5 мрежови карти, всяка с два 10G порта, то сега по-голямата част от трафика се предава от 1U сървъри, в които има 2-3 карти с по два 25G порта на всяка. Картите с 10G и 25G почти достигнаха равнина в цената, а по-бързите решения позволяват предаване както на 10G, така и на 25G. Резултатът е очевидна икономия: по-малко компоненти на сървъра и кабели за свързване – по-ниска цена (и по-висока надеждност), компонентите заемат по-малко място в шкафа – стана възможно разполагането на по-голям брой сървъри на единица площ и следователно цената за наем е по-ниска.
Но по-важна е печалбата в скоростта! Сега можем от 1U да предаваме повече от 100G! И това на фона на ситуация, в която някои големи руски проекти наричат "достижение" отдаването на 40G с 2U. На нас ни трябваха техните проблеми!
Забелязваме, че поколението мрежови карти, които могат да работят само на 10G, все още използваме. Това оборудване стабилно работи и ни е отлично познато, затова не го изхвърлихме, а намерихме ново приложение за него. Тези компоненти инсталирахме в сървъри за съхранение на видео, на които вече за ефективна работа явно не им стигат един или два 1G интерфейса, тук 10G картите се оказаха актуални.
Системи за съхранение на данни също растат. През изминалите пет години те преминаха от дванадесетдискови (12x HDD 2U) на тридесет и шестидискови (36x HDD 4U). Някои се страхуват да използват такива обемни "кучешки", тъй като при повреда на едно такова шаси може да възникне заплаха за производителността – а дори и за работоспособността! – на цялата система. Но това няма да ни се случи: осигурихме резервиране на ниво геораспределени копия на данни. Разнесохме шаситата в различни дата центрове – използваме общо три – и това елиминира възможността за възникване на проблеми както при повреди на шасито, така и при срив на площадката.
Разбира се, този подход направи хардуерния RAID излишен, от който се отказахме. Освобождавайки се от излишъка, ние едновременно повишихме надеждността на системата, опростявайки решението и премахвайки една от потенциалните точки на отказ. Напомняме, че нашата СХД е „самоделна“. Постъпихме така напълно съзнателно и резултатът ни удовлетворява напълно.
ЦОД-ове през последните пет години сменяхме няколко пъти. От момента на написването на предишната статия не сме сменили само един ЦОД – DataLine – останалите изискваха замяна в процеса на развитие на нашата инфраструктура. Всички премествания между площадките бяха планирани.
Преди две години мигрирахме вътре в ММТС-9, преминавайки на площадка с качествен ремонт, добра система на охлаждане, стабилно електропитание и без прах, който преди лежеше на дебели слоеве по всички повърхности и обилно запълваше вътрешностите на нашето оборудване. Изборът в полза на качеството на услугите – и отсъствието на прах! – стана причина за нашето преместване.
Почти винаги "едно преместване е равно на два пожара", но проблемите при миграцията всеки път са различни. Този път основната трудност при преместването вътре в един ЦОД "осигуриха" оптичните кросировки – количеството им на различните етажи без свързване в единна кросова точка от страна на операторите. Процесът на актуализация и пренареждане на кросировките (в което ни помогнаха инженерите на ММТС-9) беше, може би, най-трудният етап от миграцията.
Втората миграция се проведе преди година, през 2019 година се преместихме от не особено добър ЦОД в O2xygen. Причините за прехода бяха подобни на обсъдените по-горе, но се добави проблемът с неатрактивността на изходния ЦОД за операторите на свързаност – много доставчици трябваше да бъдат „догонявани“ до тази точка със собствени усилия.
Миграцията на 13 стелажa в качествена площадка в ММТС-9 позволи да развиваме това местоположение не само като операторско (пара-тройка стелажа и „проброси“ на оператори), но и да го използваме като един от основните. Това леко опрости миграцията от не особено добър ЦОД – повечето оборудване от него преместихме на друга площадка, а O2xygen пое ролята на развиваща се, изпращайки и там 5 стелажа с оборудване.
Днес O2xygen вече е пълноценна площадка, където „дойдоха“ нужните ни оператори и продължават да се присъединяват нови. За операторите O2xygen се оказа също атрактивен от гледна точка на стратегическото развитие.
Основната фаза на преминаване задължително провеждаме за една нощ, и при миграцията в ММТС-9 и на O2xygen се придържахме към това правило. Подчертаваме, че правилото „преместване за нощ“ строго спазваме, независимо от броя на стелажите! Имаше даже прецедент, когато преместихме 20 стелажа и изпълнихме това също за една нощ. Миграцията е сравнително прост процес, изискващ аккуратност и последователност, но и тук има някои трикове както в процеса на подготовка, така и при преминаването, и при разгръщането на новото местоположение. Готови сме да разкажем в детайли за миграцията, ако проявите интерес.
Резултати Петилетки на развитие ни допадат. Завършихме изграждането на нова отказоустойчива инфраструктура, разпределена между три центрове за данни. Рязко увеличихме плътността на отдаване на трафик – ако наскоро се радвахме на 40-80G с 2U, то сега за нас е нормално да отдадем 100G с 1U. Сега дори терабитовият трафик се възприема от нас като нещо обичайно. Готови сме да развиваме допълнително инфраструктурата ни, която се оказа гъвкава и мащабируема.
Въпрос: За какво да ви разкажем в следващите текстове, уважаеми читатели? За това, защо започнахме да създаваме самостоятелни системи за съхранение на данни? За мрежовото ядро и неговите особености? За триковете и тънкостите на миграцията между дата центровете? За оптимизацията на решенията при предоставяне чрез подбор на компоненти и фина настройка на параметрите? За създаването на устойчиви решения благодарение на многократното резервиране и хоризонталните възможности за мащабиране в дата центъра, реализирани в структура от три ЦОД-а?
Автор: Петър Виноградов — Технически директор на Uma.Tech
Източник: habr.com
