Ми запускали нові сервіси, трафік ріс, замінювали сервери, підключали нові майданчики та переробляли ЦОДи – а зараз розповімо цю історію, з початком якої знайомили вас п'ять років тому..
П'ять років – характерний час для підбиття проміжних підсумків. Тому ми вирішили розповісти про розвиток нашої інфраструктури, яка за п'ятирічку пройшла напрочуд цікавий шлях розвитку, яким ми пишаємося. Реалізовані нами кількісні зміни перейшли в якісні, тепер інфраструктура може працювати в режимах, які в середині десятиліття здавалися фантастикою.
Ми забезпечуємо роботу найскладніших проектів з найжорстокішими вимогами до надійності та навантажень, серед яких PREMIER та Матч ТБ. На спортивних трансляціях і на прем'єрі популярних серіалів потрібна віддача трафіку в терабіти/с, ми легко реалізуємо, причому так часто, що робота з такими швидкостями давно стала для нас буденністю. А п'ять років тому найважчим проектом, який працює на наших системах, був 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) стали тридцятишестидисковими (36х HDD 4U). Такі ємні «тушки» деякі бояться використовувати, тому що у разі виходу з ладу одного такого шасі може виникнути загроза для продуктивності – а то й працездатності! - Для всієї системи. Але у нас такого не станеться: ми забезпечили резервування на рівні георозподілених копій даних. Ми рознесли шасі різними дата-центрами – всього ми використовуємо три – і це виключає виникнення проблем як при збоях у шасі, так і при падінні майданчика.
Зрозуміло, такий підхід зробив надлишковим апаратним RAID, від якого ми відмовилися. Позбавившись надмірності, ми одночасно підвищили надійність системи, спростивши рішення і прибравши одну з потенційних точок відмови. Нагадаємо, що СГД у нас – «саморобні». На це ми пішли свідомо і результат нас повністю влаштував.
ЦОДи за минулі п'ять років ми змінювали кілька разів. З часу написання попередньої статті ми не змінювали лише один ЦОД – DataLine – інші вимагали заміни у міру розвитку нашої інфраструктури. Усі переїзди між майданчиками були планові.
Два роки тому ми мігрували всередині ММТС-9, перейшовши на майданчик з якісним ремонтом, гарною системою охолодження, стабільним електроживленням і без пилу, який раніше лежав товстими шарами на всіх поверхнях, а також рясно забивав нутрощі нашого обладнання. Вибір на користь якості послуг – і відсутність пилу! – став причиною нашого переїзду.
Майже завжди один переїзд дорівнює двом пожежам, але проблеми при міграції щоразу різні. Цього разу основна складність переїзду всередині одного ЦОДу «забезпечили» оптичні кросування – їхня міжповерхова велика кількість без зведення в єдину кросову з боку операторів зв'язку. Процес актуалізації та перепрокладання кросировок (у чому нам допомогли інженери ММТС-9), був, мабуть, найскладнішим етапом міграції.
Друга міграція відбулася рік тому, в 2019 році ми переїжджали з не дуже хорошого ЦОД в O2xygen. Причини переїзду були подібні до розглянутих вище, але до них додалася проблема з непривабливістю вихідного ЦОДу для операторів зв'язку – багатьох провайдерів доводилося «наздоганяти» до цієї точки самотужки.
Міграція 13 стійок на якісний майданчик у ММТС-9 дозволило розвивати цю локацію не тільки як операторську (пара-трійка стійок та «прокидання» операторів), а й задіяти як одну з основних. Це трохи спростило міграцію з не дуже хорошого ЦОД - більшість обладнання з нього ми перевезли на інший майданчик, а O2xygen відвели роль того, що розвивається, відправивши і туди 5 стійок з обладнанням.
Сьогодні O2xygen вже повноцінний майданчик, куди прийшли необхідні нам оператори і продовжують підключатися нові. Для операторів O2xygen виявився теж привабливим з погляду стратегічного розвитку.
Основну фазу переїзду ми обов'язково проводимо за одну ніч, і при міграції всередині ММТС-9 та на O2xygen дотримувалися цього правила. Підкреслимо, що правило «переїзд за ніч» ми виконуємо незалежно від кількості стійок! Був навіть прецедент, коли ми переміщали 20 стійок і виконали це за одну ніч. Міграція досить нехитрий процес, що вимагає акуратності та послідовності, але і тут є деякі хитрощі як у процесі підготовки, так і при переїзді, і при розгортанні нової локації. Про міграцію у деталях ми готові докладно розповісти, якщо у вас буде зацікавленість.
Результати п'ятирічки розвитку нам подобаються. Ми завершили побудову нової стійкої до відмови інфраструктури, розподіленої по трьох центрах обробки даних. Різко підвищили щільність віддачі трафіку - якщо нещодавно раділи 40-80G з 2U, то зараз нам норма віддавати 100G з 1U. Тепер і терабіт трафіку сприймається нами як буденність. Ми готові й надалі розвивати нашу інфраструктуру, яка вийшла гнучкою, що масштабується.
Питання: про що розповісти вам у наступних текстах, шановні читачі? Чому ми почали створювати саморобні системи зберігання даних? Про мережеве ядро та його особливості? Про хитрощі та тонкощі міграції між дата-центрами? Про оптимізацію рішень щодо видачі шляхом підбору компонентів та тонкого налаштування параметрів? Про створення стійких рішень завдяки багаторазовому резервуванню та горизонтальним можливостям масштабування всередині дата-центру, які реалізовані у структурі із трьох ЦОДів?
Автор: Петро Виноградов - Технічний директор Uma.Tech
Джерело: habr.com