Каждый квартал Drive Stats предоставляет нам цифры. В этом квартале мы столкнулись с кризисом смысла. Что на самом деле означает отказ жёсткого диска? Это происходит в момент, когда гаснет свет, или в момент, когда мы сами решаем, что он вышел из строя? Философы могли бы назвать это онтологической серой зоной. Мы просто называем это Q3.

По состоянию на 30 июня 2025 года у нас под управлением находилось 332 915 дисков. Из них 3970 были загрузочными, а 328 348 — дисками с данными. Давайте разберёмся в статистике, а затем поговорим о том, что такое сбой.

Статистика привода: дайджест-версия


Показатели отказов жестких дисков в третьем квартале 2025 года
В третьем квартале 2025 года мы отслеживали 328 348 накопителей. Вот цифры:
Показатели отказов жестких дисков Backblaze в третьем квартале 2025 года
Отчетный период с 1 июля 2025 г. по 30 сентября 2025 г. включительно.
Модели автомобилей с количеством поездок > 100 по состоянию на 1 июля 2025 г. и количеством дней поездок > 10 000 в третьем квартале 2025 г.


Заметки и наблюдения
Уровень отказов увеличился: Уровень отказов изменился, причём весьма существенно. Напомним, что в прошлом квартале среднегодовой процент отказов (AFR) составил 1,36% по сравнению с 1,55% в этом квартале. (Интересно, что годовой AFR за 2024 год составил 1,57%).
Новая энергия накопителя: встречайте Toshiba MG11ACA24TE ёмкостью 24 ТБ, присоединившийся к общему парку накопителей с 2400 накопителями и 24 148 днями автономной работы. Это означает, что мы достигли пороговых значений для квартальной статистики, но не для срока службы.
Клуб нулевых отказов: Для клуба нулевых отказов это был важный месяц, в который вошли четыре автомобиля:

• Seagate HMS5C4040BLE640 (4 ТБ)
• Seagate ST8000NM000A (8 ТБ)
• Toshiba MG09ACA16TE (16 ТБ)
• Toshiba MG11ACA24TE (24 ТБ) — и да, это новый диск.

Те из вас, кто внимательно следит за статистикой, наверняка заметят, что Seagate ST8000NM000A (8 ТБ) — частый гость в этом списке. Последний раз он сломался в третьем квартале 2024 года — и это был всего один сбой за весь квартал!

Самые высокие значения AFR были действительно высокими: верхний предел был настолько высоким, что в этом месяце это побудило нас провести анализ выбросов с использованием стандартного квартильного анализа (метод Тьюки). Исходя из этой информации, любой автомобиль с квартальным значением AFR выше 5,88% является выбросом, и таких выбросов три:

• Seagate ST10000NM0086 (10 ТБ): 7,97%
• Seagate ST14000NM0138 (14 ТБ): 6,86%
• Toshiba MG08ACA16TEY (16 ТБ): 16,95%

Что там происходит? Отличный вопрос, и мы поговорим об этом после того, как рассмотрим показатели отказов за весь срок службы.

Показатели отказов жесткого диска за весь срок службы
Для рассмотрения на предмет оценки жизненного цикла модели накопителя требовалось наличие 500 или более накопителей по состоянию на конец второго квартала 2025 года и более 100 000 дней эксплуатации за весь срок службы. После исключения моделей накопителей, не соответствующих критериям оценки жизненного цикла, для анализа остались 27 накопителей, как показано в таблице ниже.

Показатели отказов жестких дисков Backblaze во втором квартале 2025 года
Отчетный период заканчивается 30 сентября 2025 г.
Модели приводов > 500 приводов и > 100 000 дней эксплуатации приводов за весь срок службы


Заметки и наблюдения

• Этот показатель годовых процентных ставок (AFR) за весь срок службы довольно стабилен, не правда ли? Он составляет 1,31%. В прошлом квартале мы сообщали, что он составлял 1,30%, а в предыдущем квартале — 1,31%.
• Средний возраст накопителей объёмом 4 ТБ не изменился: как мы уже сообщали ранее, накопители объёмом 4 ТБ постепенно выводятся из эксплуатации. Сейчас их осталось совсем немного — всего 11 моделей ALE и 187 моделей BLE. Но, поскольку их жизненный цикл сравнительно велик, дополнительных дней эксплуатации накопителей недостаточно, чтобы изменить средний возраст в месяцах. Таким образом, никаких «призраков» в машине нет, и вывод из эксплуатации идёт по плану.
• Стабильный рост числа накопителей большей ёмкости: с прошлого квартала мы добавили 7936 накопителей ёмкостью 20 ТБ и более, соответствующих нашим параметрам по сроку службы. И не забывайте, что наш новый участник этой группы, Toshiba MG11ACA24TE (24 ТБ), пока не попал в эту таблицу — это добавляет ещё 2400 моделей накопителей. В общей сложности, ёмкостью 20 ТБ и более владеют 67 939 накопителями, что составляет около 21% от общего числа накопителей.

Определение отказа — с технической точки зрения
Вопрос, который мы несколько раз поднимали во время вебинаров или в комментариях, — как мы определяем отказ. Хотя это может показаться очевидным, на самом деле это довольно сложная головоломка, к которой мы не обращались с самого начала этой серии. Поиск ответа на этот вопрос затрагивает внутренние инструменты мониторинга парка накопителей (через статистику SMART), саму программу сбора статистики накопителей и наш уровень обработки данных. Я подробно рассмотрю каждый из этих вопросов, а затем мы рассмотрим выбросы за этот квартал.

Отчетность по статистике SMART
Мы используем Smartmontools для сбора SMART-атрибутов дисков и другой инструмент мониторинга, называемый Drive Sentinel, для маркировки ошибок чтения/записи, превышающих определенный порог, а также некоторых других аномалий.

Основным показателем, по которому мы определяем необходимость замены диска, является его реакция на чтение с неисправимыми ошибками носителя. Когда диск считывает данные с диска, но данные не проходят проверку целостности, он пытается восстановить данные, используя внутренние коды коррекции ошибок. Если восстановить данные не удаётся, он уведомляет хост, сообщая об этом как о неисправимой ошибке и помечая соответствующую часть диска как ожидающую перераспределения, что отображается в SMART с атрибутом Current_Pending_Sector.

В модулях хранения данных (Storage Pod), управляющих дисками через каналы SATA, функция Drive Sentinel подсчитывает количество неисправимых ошибок, обнаруженных диском, и, если оно превышает пороговое значение, доступ к диску будет закрыт. Это важно для классических модулей хранения данных Backblaze, где пять дисков совместно используют один канал SATA, и ошибки одного диска влияют на все диски в канале.

На модулях Dell и SMCI, использующих топологию SAS для подключения дисков, функция Drive Sentinel не закрывает доступ к дискам, поскольку сообщения об ошибках выдаются по-разному. Однако это не так критично, поскольку SAS сводит к минимуму влияние проблемного диска на другие.

Программа Drive Stats
Ранее мы уже рассказывали о специальной программе, которую мы используем для сбора статистики поездок, и вот краткий обзор:

Генератор podstats запускается на каждом модуле хранения (Storage Pod), то есть на любом хосте, где хранятся данные клиентов, каждые несколько минут. Это программа на C++, которая собирает статистику SMART и ряд других атрибутов, а затем преобразует их в XML-файл («podstats»). Затем данные отправляются на центральный хост в каждом центре обработки данных и объединяются в пакет. Покидая эти центральные хосты, данные попадают в область, которую мы будем называть Drive Stats.

Логика этой программы относительно проста: сбой в Drive Stats происходит, когда диск исчезает из отчётной совокупности. Он считается «неисправным» до тех пор, пока не появится снова. Диски отслеживаются по серийным номерам, и мы ежедневно отправляем журналы по каждому диску, так что, по сути, мы можем получить довольно подробную информацию.

Уровень инженерии данных
Итак, мы собрали статистику SMART и скомпилировали её с помощью программы podstats. Теперь у нас есть вся информация, и аналитике данных необходимо добавить контекст. Диск может отключиться примерно на день (не вернув ответа тем инструментам, которые ежедневно собирают логи статистики SMART), но это может быть что-то простое, например, отсоединение кабеля. Итак, если диск снова появляется через день или 30, в какой момент этого периода мы классифицируем его как официальный отказ?

Раньше мы вручную создавали перекрёстные ссылки на рабочие тикеты центров обработки данных, но теперь мы автоматизировали этот процесс. На бэкенде это SQL-запрос, но, выражаясь человеческим языком, это выглядит следующим образом:

• Если накопитель регистрирует данные в последний день выбранного периода (в данном случае квартала), то он не вышел из строя.
• Запрос ссылается на три таблицы, созданные пользователем. Если в одной из них есть серийный номер диска, это указывает на наличие неисправности (в зависимости от назначения таблицы).
• Если серийный номер диска является основным серийным номером в тикете Jira на замену диска, то замена не удалась. (Jira — это место, где мы отслеживаем рабочие тикеты нашего центра обработки данных.)
• Если серийный номер накопителя является целевым серийным номером в тикете клонирования Jira или в (временном) заменяющем тикете, то он не является сбоем.
• По сути, когда мы составляем отчеты по статистике накопителей в конце квартала, если накопитель появился в одном из наших различных рабочих трекеров или не был повторно введен в совокупность, то он считается невыполненным.

В редких случаях это может означать, что у нас случаются так называемые «косметические» сбои, когда мы работаем с моделью накопителя, которая служит дольше квартального срока службы. И, спойлер, один из таких случаев отразился в данных этого месяца — наш выдающийся диск Toshiba с показателем отказов 16,9%. Мы расскажем об этом буквально через минуту, но сначала немного контекста.

Связь отказа диска с общей картиной парка дисков
Как мы уже упоминали выше, у некоторых приводов в пуле наблюдались настолько сильные колебания показателя AFR, что нам пришлось провести анализ выбросов с использованием метода квартилей. (Стоит также отметить, что кластерный анализ потенциально может быть более точным, но мы оставим это на другой раз.) Согласно этому анализу, всё, что имеет показатель отказов выше 5,88%, является выбросом.

Основная мотивация была навеяна попыткой визуализировать взаимосвязь между возрастом поездки в месяцах и показателями AFR в этом квартале.

И да, мы прекрасно понимаем, что это… совершенно нечитаемая диаграмма рассеяния. Если убрать подписи, то выглядит она немного лучше:


Нас действительно интересует форма этой зависимости. Если предположить, что чем старше диски, тем выше частота их отказов, можно было бы ожидать большей концентрации в правом верхнем квадранте. Но наши данные следуют гораздо более интересной закономерности: большинство точек данных сосредоточено в нижних областях графика независимо от возраста — чего и следовало ожидать от набора данных, отражающего деятельность группы умных людей, активно работающих над достижением цели поддержания здорового парка дисков. И всё же, у нас есть некоторые данные, которые ломают стереотипы.

Как интуитивно понятно моим коллегам из отдела бизнес-аналитики, процесс выявления выбросов — это тоже практические данные. Как и любая пресса — это хорошая пресса; в нашем мире больше данных — значит лучше. Итак, давайте подробнее рассмотрим эти выбросы. Напоминаю, вот эти три модели мотивации:

• Seagate ST10000NM0086 (10 ТБ): 7,97%
• Seagate ST14000NM0138 (14 ТБ): 6,86%
• Toshiba MG08ACA16TEY (16 ТБ): 16,95%

Seagate ST10000NM0086 (10 ТБ)
Высокая частота отказов этого накопителя вполне объяснима. Ему уже более семи лет (92,35 месяца). Кроме того, поскольку в эксплуатации находится всего 1018 моделей накопителей, отдельные отказы имеют большое значение по сравнению со средним количеством накопителей каждой модели, которое составляет 10 952, если использовать среднее значение этих квартальных данных, и 6177, если использовать медианное значение.
И вы можете увидеть, что это подтверждается тенденцией за последний год:

Seagate ST14000NM0138 (14 ТБ)
Этому накопителю почти пять лет (56,57 месяцев), и, опять же, количество накопителей меньше — 1286. Что ещё важнее, эта модель накопителя исторически имела высокие показатели отказов. В дополнение к вышесказанному, вот квартальные показатели отказов за последний год:

Toshiba MG08ACA16TEY (16 ТБ)
Наконец, наша модель Toshiba — самая интересная из всех. Ей меньше четырёх лет (44,61 месяца), и в её пуле 5145 накопителей. И этот квартал явно отличается от её обычных, приличных показателей годовых отказов (AFR).


Когда мы видим подобные отклонения, это обычно признак того, что что-то происходит.

Не волнуйтесь, поклонники Drive Stats: этот показатель был известен ещё до того, как мы приступили к этому делу. В прошлом квартале, работая с Toshiba, мы внедрили несколько обновлений прошивки, предоставленных компанией для оптимизации производительности этих дисков. Поскольку в некоторых случаях для этого приходилось извлекать диски, в этой группе накопителей оказалось аномально большое количество «сбойных» дисков.

Для этого накопителя это означает, что он на самом деле неплохая модель; и, учитывая нашу совместную работу с Toshiba над решением проблемы, мы должны увидеть нормализацию показателей отказов в ближайшем будущем. И это также возвращает нас к нашему разговору об определении отказа: в данном случае, хотя диски и «вышли из строя», отказ не был механическим, а был связан с чем-то, что мы сможем исправить без замены дисков. Короче говоря, не переживайте из-за скачка производительности и обратите внимание на динамику производительности в этой группе. Мы ожидаем, что эти накопители будут исправно работать долгие годы (и с более высокой производительностью).

❕ Самая масштабная акция этого года стартовала. Не пропусти!

Мы знаем, как сложно найти идеальный сервер:
в одном месте — качество, но кусаются цены,
в другом — дешево, но все лагает.

Хостинг SpaceCore запускает самую большую акцию в этом году: скидки до 45%, вау!

Для заказа серверов VPS/VDS (Low/Hi-CPU)
Скидка 10%, даже на год.

Закажите любой готовый тариф VPN со скидкой 45%
Всего лишь за €2.6 /мес €4.8 /мес

Хочешь максимум выгоды?
Оплачивай сразу за год и ЭКОНОМЬ ПО-КРУПНОМУ.

Акция действует только 48 часов, после чего завершится.

Больше такого в этом году не будет. Это последний шанс.

Закажи прямо сейчас, пока остальные думают

Время пришло! Распродажа года стартует!

Друзья, вот и настал тот самый день, которого все ждали!

Стартует главная распродажа года — 11.11

А чтобы праздник был по-настоящему крутым, мы подготовили для вас специальный подарок:

Только сегодня, 11 ноября, пополняйте баланс и получайте бонус +11% к любой сумме!

Пополнили на 1000 рублей? На вашем счету уже 1110!

Нужно больше мощностей?
Сейчас — самое время!

Успейте использовать шанс:

• Пополнить баланс с +11%

Не упустите главную выгоду осени!
Акция действует до 23:59 11 ноября.

4vps.su

UFO.Hosting запускает распродажу 11.11 — в честь Всемирного дня шоппинга!
Здравствуйте!

С 11 по 16 ноября в UFO.Hosting действует акция 11.11 — это отличный повод обновить серверную инфраструктуру и сэкономить:

• VPS «12 за цену 6» — арендуйте на год, платите как за 6 месяцев (–50%);
• –10% на продление VPS — продлевайте без простоев и по выгодной цене;
• SSL –70% — переходите на HTTPS или замените действующий сертификат;
• FTP-хранилище –20% — удобно для бэкапов и крупных файлов вне продакшена.
• Чтобы применить скидку, просто введите промокод UFOSALE в корзине — цена обновится автоматически.

Сроки: до 16 ноября 23:59 (MSK), 2025. Если понадобятся рекомендации по выбору — поможем.
https://ufo.hosting

Большинство скидок в День холостяков больше похожи на маркетинговые уловки, чем на реальную экономию. Вы знаете эту закономерность: разовые скидки, которые сгорают, как только вы перестаёте обращать на них внимание.

Мы делаем это по-другому, предлагая пожизненную скидку 11% на любой новый VPS.
contabo.com/en/vps/

Скидка 11%. Навсегда.
В День холостяков мы предлагаем скидку 11% на любой новый VPS, пока вы его используете. Не только первый месяц. Не только первый год. Навсегда.

Это относится ко всем тарифным планам VPS в нашей линейке: от начального VPS 10, идеально подходящего для тестирования идей, до мощного VPS 60, подходящего для производственных задач. Выберите нужные характеристики, получите скидку и приступайте к реализации своего проекта.

Почему 11%? Потому что День холостяков — 11 ноября. Некоторые вещи просто имеют смысл.

Почему пожизненная скидка так важна
Послушайте, мы не будем притворяться, что это что-то революционное. Это просто честная скидка, которая действует постоянно. Но она может существенно повлиять на ваш бюджет. Вы экономите на каждом счёте, месяц за месяцем, в течение всего срока службы вашего сервера.

Независимо от того, разворачиваете ли вы среду разработки, запускаете сторонний проект или расширяете свою инфраструктуру, математика проста: меньше расходов на хостинг — больше денег на все остальное.

Это предложение ко Дню холостяков действует только один день (видите, что мы там сделали?) — не упустите!

Ваша команда Contabo

-30% скидка на первый платеж — WS2025



lite.host/discount

Пять лет назад мы запустили аукцион серверов  — площадку, где можно выгодно приобрести выделенный сервер.

За это время наши клиенты сэкономили больше 57 000 000 рублей! И вы тоже можете приобрести сервер по приятной цене >> 1dedic.ru/auction

За 5 лет у аукциона появились свои достижения:

• Минимальная цена сервера — всего 1975 р.
• Самая популярная конфигурация — Intel Core i7-7700 / 16 GB RAM / SSD 240 + 240 GB;
•  Рекордная скорость активации сервера — 6 минут

Когда мы говорим о большом сервисе с десятками миллионов пользователей по всей стране, надёжно и эффективно должен работать каждый уровень: и приложения, и инфраструктура, и сеть. Если в уравнение добавляются петабайты видеоконтента, сеть становится ещё более критичным элементом.

В этой статье на примере эволюции сети RUTUBE разберём: с чего начинать ревизию legacy-сети; какие оптимизации помогут пережить резкий рост нагрузки и выиграть время для масштабного обновления; и наконец, что учесть при проектировании новой современной сети, подходящей для актуальных архитектурных подходов и стека технологий.

Меня зовут Олег Аралбаев, я более 20 лет в IT и телекоме, работал в операторах связи, вендоре оборудования и нескольких интеграторах. С 2022 года занимаю позицию руководителя отдела развития и эксплуатации сети в RUTUBE. Расскажу, как мы строим и эксплуатируем сеть видеохостинга. Надеюсь, что-то из этого поможет вам в вашей ежедневной работе.

Сейчас сеть RUTUBE состоит более чем из 7 тысяч серверов в 7 центрах обработки данных. У нас в эксплуатации 380 CDN-серверов, которые ежемесячно обслуживают около 80 млн пользователей. Всё это результаты работы команды за последние несколько лет — большая часть действующих сейчас кода и инфраструктуры RUTUBE была разработана и внедрена после 2020-го. В том числе и сеть, которая ещё в 2021-м году представляла из себя следующее:

• 31 коммутатор и маршрутизатор;
• 5 ЦОДов с каналами между ними по 20 Гбит/с и офисная сеть;
• Border router’ы MikroTik CCR1072;
• отдельные DMZ-сети, NAT на каждом BR и отсутствие резервирования;
• статическая маршрутизация на всех вышестоящих провайдерах без BGP.

Схема сети RUTUBE в 2021 году


В таком виде моя команда приняла в эксплуатацию сеть — на тот момент она уже не удовлетворяла потребностям растущего сервиса и требовала обновления. Первым шагом мырешили всё упорядочить и перенастроить сеть так, чтобы иметь возможность без ущерба для бизнеса проектировать и переходить на новую.

Перенастройка legacy-сети
Первое, что мы сделали, это взяли нашу сеть под контроль — настроили мониторинг и централизованную авторизацию на всех устройствах:

• Подняли и настроили на всех устройствах TACACS для централизованного контроля доступа, убрав локальную авторизацию.
• RANCID для сохранения конфигурации и ведения версионности.
• RSYSLOG — для аудита действий на устройствах.
• Отдельный ZABBIX 7 для мониторинга всего парка сетевых устройств.

Оптимизация настроек MikroTik
Следующее, за что мы взялись, — оптимизация сети и настройка роутеров MikroTik. Нагрузка на платформу начала быстро расти, при этом параллельно шла разработка архитектуры новой сети, закупочные процедуры, поставка и пусконаладка. Но это небыстрый процесс, который растянулся почти на год, который нам нужно было постараться прожить на текущем оборудовании и выжать из него максимальную производительность, при этом обеспечить стабильную работу платформы.

Что мы предприняли, чтобы увеличить производительность имеющегося оборудования:

• обратились за аудитом, консультацией и обучением инженеров к внешним экспертам из компании, которая более 10 лет занимается внедрением проектов на оборудовании MikroTik;
• перенастроили все firewall-правила на MikroTik;
• закрыли везде доступы, повесили ACL — потому что до этого внутри сети был полный доступ;
• перевели все стыки с интернет-провайдерами со статики на BGP;
• проапгрейдили DCI-каналы между ЦОДами: 20 Гбит/с -> 40 Гбит/с -> 100 Гбит/с -> и в 2024 перешли уже на 400 Гбит/с.

Казалось бы, сеть и роутеры перенастроили, DCI расширили. Но не тут-то было. Из-за возросшего количества фаервольных правил и из-за нескольких BGP-сессий с новыми провайдерами в часы наибольшей нагрузки роутеры стали просто дропать BGP-сессии и регулярно перезагружаться по причине 100% загрузки CPU.


Для понимания конфигурация каждого роутера Mikrotik была примерно следующая:

• ~1500 IP-адресов и подсетей в адрес-листах;
• ~500 фаервольных правил;
• ~20−30 Гбит/с общего трафика на роутер.

Чтобы снизить нагрузку на CPU и увеличить скорость обработки пакетов, мы решили перевести все правила фаерволла на работу с цепочками.

По умолчанию, если мы не используем цепочки, traffic flow в MikroTik проходит последовательно: входящий пакет (chain forward) проверяется подряд по всем правилам из списка с самого начала до первого совпадения. То есть может понадобиться проверить все наши 500-700 правил, и только в конце, если пакет не подпадает ни под одно правило, он будет дропнут.

Цепочки, в отличие от последовательной проверки, позволяют на уровне входящих интерфейсов сразу распределить пакет на правила, которые предназначены именно ему, то есть соответствуют определенному признаку (в нашем случае совпадение по входящему/исходящему интерфейсу и src/dst ip). Следовательно, роутеру не нужно последовательно обрабатывать все фаервольные правила, а можно перескочить сразу на узкую цепочку правил, под которую точно подпадает наш пакет.

Рассмотрим организацию цепочек на примере. Ниже список фаервольных правил, относящихся к сети 10.80.222.0/30.


Сейчас они обрабатываются последовательно в порядке нумерации, переделаем их на цепочки.

Шаг 1. Разделить все физические и логические интерфейсы роутера на зоны. В нашем случае это DMZ, LAN и WAN:


Шаг 2. Настроить правила jump в цепочке forward: как обычно идём в IP → Firewall и создаем новое firewall-правило, выбираем Chain = forward, входящий и исходящий интерфейс, из тех, которые мы разметили на предыдущем шаге, — в примере это DMZ и LAN. На вкладке Action делаем Action = jump, вводим имя нашей новой цепочки в поле Jump target — здесь это DMZ_to_LAN (оно нам дальше понадобится для создания правил внутри данной цепочки).

Шаг 3. Подобным образом создаём jump-цепочки для трафика между всеми размеченными интерфейсами на шаге 1 с учётом необходимой связности:


Шаг 4. Так как роутеры Mikrotik обрабатывают правила начиная с первого и далее по порядку, приоритизируем их порядок и по возможности помещаем наверх те, по которым фильтруется наибольший объем трафика. Это позволит снизить нагрузку на CPU роутера.

Для примера в созданной ранее цепочке DMZ_to_LAN сделаем правило для конкретного сервиса HAProxy:

• выбираем цепочку, созданную нами ранее — Chain = DMZ_to_LAN;
• Src. Address — подсеть 10.8.222.0/30, в которой у нас живет HAProxy;
• на вкладке Action — Action = jump;
• и там же — Jump Target = HAProxy_DMZ_to_LAN — вписываем название нашей новой цепочки для этого сервиса.

Далее уже внутри созданной цепочки HAProxy_DMZ_to_LAN мы можем создать ещё одно правило для разрешения пакетов от сервиса HAProxy до конечных хостов: Chain = HAProxy_DMZ_to_LAN. В качестве адреса назначения мы привязали адрес-лист сервиса pdns с его destination IP — адресами, протокол UDP, Destination port = 53, Action = accept.


Теперь, когда HAProxy обратится к этому сервису, он пойдет не по всему списку файрвольных правил, а только по относящейся к нему цепочке из трёх правил: DMZ_to_LAN → HAProxy_DMZ_to_LAN → FW Rule — PDNS, UDP:53.


В конце цепочки — обязательно правило drop. Если совпадение не найдено, значит, этот пакет не должен никуда передаваться.

Routing
С переходом на цепочки правил нагрузка на процессор действительно снизилась, но дропы BGP-сессий в часы наибольшей нагрузки не прекратились. Для снижения нагрузки на CPU роутеров MikroTik мы настроили на прероутинге правила дропать всё, что не попадает в исключения. На глубокую обработку CPU действительно стало попадать гораздо меньше пакетов, но, оказалось, что в часы наибольшей нагрузки одно ядро роутера на 100% занимается обработкой процесса ROUTING. Дело в том, что наши маршрутизаторы работали на RouterOS 6, которая просто не умеет распределять по ядрам процесс ROUTING. А как мы помним, для лучшего резервирования, мы добавили внешние стыки, работающие по BGP, и дело стало совсем плохо.

Примерно так нейросеть представляет наши роутеры Mikrotik в часы наибольшей нагрузки


Мы приняли решение обновиться до RouterOS 7, несмотря на то, что на тот момент она ещё была довольно сырая. Пришлось пожертвовать протоколом BFD, потому что тогда в RouterOS 7 он не поддерживался.

После обновления MikroTik на RouterOS 7 мы взглянули на наши роутеры новыми глазами — они стали адекватно справляться с текущей нагрузкой. Это дало нам время на то, чтобы спроектировать, построить и запустить новую сеть.



Выше на графике каждое ядро загружено не более, чем на 15%, при конфигурации:

• ~450 firewall-правил;
• ~2100 IP в address list;
• ~25 Гбит/с трафика и 7 млн пакетов в секунду в пиковые часы.

Бонусом апгрейда на RouterOS 7 стала дополнительная функция — мониторинг BGP-пиров по SNMP, которая ранее не поддерживалась. Теперь мы смогли вывести в Zabbix статус по всем BGP-peer’ам каждого роутера и настроить алерты.



Проектирование новой сети
Оптимизировав старую сеть, мы смогли выиграть время на проектирование и строительство новой сети под новую IT-инфраструктуру, которая значительно превосходила текущую.

Есть проверенная годами трёхуровневая схема построения сети: доступ, агрегация, ядро. Всё просто и отработано годами: понятное оборудование, понятная связность, известные протоколы маршрутизации и схемы резервирования.


Однако такие сети предназначены в основном для трафика «Север—юг», то есть трафика со стороны пользователя/сервера во вне или наоборот. В любом случае, предполагается, что каждый пакет проходит уровень ядра, маршрутизируется и уходит далее на какой-то внешний интерфейс. В нашем же случае требовалось построить сети для эффективной работы с трафиком внутри ЦОДов — то есть «Запад—восток».

Мы выбрали архитектуру сетей Клоза и коммутаторы Leaf и Spine.

Один из вопросов, который я задаю всем сетевым инженерам на собеседовании, касается сетей Клоза. Изучите, если не знакомы с этой темой, потому что сетевая инфраструктура в большинстве современных IT-компаний построена именно по этой топологии, так как она лучше всего подходит для микросервисной архитектуры и систем виртуализации.

Мы построили Leaf-Spine фабрику с полносвязной топологией, где коммутаторы доступа Leaf связаны со всеми коммутаторами агрегации Spine.


Эта топология имеет ряд преимуществ по сравнению с обычной трёхуровневой: минимальное количество хопов, минимальные, прогнозируемые задержки между серверами в пределах фабрики одного ЦОДа, легкое масштабирование и гибкость. Дале рассмотрим, за счёт чего это достигается.

В нашей новой сети мы выбрали технологию VxLAN для создания наложенной сети поверх L3 инфраструктуры, так как она даёт нам довольно весомые преимущества по сравнению с обычными VLAN:

• решает проблему ограничения в 4096 VLAN — идентификатор (VNI) 24-битный;
• позволяет растягивать L2-домены поверх опорной сети (underlay);
• у вас появляется «наложенная» или overlay-сеть, которая позволяет развертывать и перемещать виртуальные машины в любое место дата-центра (или даже между дата-центрами) независимо от их физического расположения.

А также BGP EVPN — эта технология отвечает за распространение информации о MAC/IP-адресах и использует следующие типы маршрутов: Route Type 2, Route Type 3, Route Type 5.

Route Type 2 (MAC/IP Advertisement) — указывают, за каким сегментом подключено устройство с MAC/IP. Эти маршруты будут использоваться для передачи трафика к или от устройств, подключенных к VTEP коммутаторам (далее я расскажу, что это). Этот тип маршрута направлен на оптимальную маршрутизацию трафика внутри фабрики, основные этапы его работы:

• MAC Learning — Leaf-коммутатор изучает MAC-адрес хоста.
• BGP Advertisement — анонсирует RT-2 маршрут в BGP с: MAC-адресом хоста, IP-адресом (если известен), VNI, Route Target для указания VPN принадлежности.


• Remote Learning — другие Leaf получают RT-2 и записывают к себе: MAC-запись в bridge table, VTEP-назначение для удаленного MAC, ARP/ND-запись (если IP присутствует).

Route Type 3 (Inclusive Multicast Route) — используется для распространения репликации BUM-трафика (Broadcast, Unknown unicast, Multicast) по каждому сегменту L2. В рамках работы наложенной СПД данный тип маршрутов используется для работы механизма Ingress Replication.

• Функция: анонс принадлежности к BUM-группе.
• Механизм: каждый Leaf анонсирует свой VTEP IP через RT-3.
• Результат: построение multicast distribution tree для BUM-трафика.

Route Type 5 (IP Prefix Route) — предназначен для передачи информации об IP-сетях и используется коммутатором VTEP, в том числе для маршрутизации пакетов внутри наложенной сети в случае отсутствия для заданного IP-адреса назначения маршрута type 2.

• Назначение: межсегментная L3 маршрутизация
• Использование: анонс IP-префиксов между различными VNI/VLAN

Как же работает BGP EVPN:

• Изучение MAC-адресов: когда хост отправляет кадр, Leaf-коммутатор изучает его MAC/IP и анонсирует эту информацию через BGP EVPN Type 2 маршрут всем остальным Leaf'ам.
• Передача unicast-трафика: при получении кадра для известного MAC-адреса, Leaf инкапсулирует его в VXLAN и отправляет напрямую к целевому Leaf'у, используя информацию из BGP EVPN.
• Обработка BUM-трафика: для широковещательного трафика используются Type 3 маршруты, которые создают дерево доставки или используют ingress replication.

Отказоустойчивость мы усилили, реализовав механизмы IP Anycast Gateway и Anycast VTEP для резервирования шлюзов и работы ECMP.

При работе технологии MLAG совместно с технологией ECMP образуется логический экземпляр Anycast VTEP. В качестве IP-адреса логического коммутатора Anycast VTEP используется IP-адрес интерфейса Loopback1, одинаковый для пары коммутаторов, формирующих домен MLAG (см. схему ниже).


В дополнение к этому мы используем концепцию распределенного шлюза по умолчанию (IP Anycast Gateway), это убирает необходимость поднимать трафик на уровень ядра. При такой конфигурации, как только на ближайший Leaf-коммутатор попадает трафик со стороны одного из серверов, он здесь же маршрутизируется и отправляется на Leaf-коммутатор и подключенный к нему сервер назначения (IRB маршрутизация). Это даёт понятное количество хопов до любого хоста в пределах ЦОДа и, соответственно, минимальные, прогнозируемые задержки.

Концепция IP Anycast Gateway схематично показана ниже (IP/MAC-адреса и идентификаторы сегментов VLAN ID приведены в качестве примера). Использование данной технологии опирается на конфигурацию интерфейса VBDIF на каждом из коммутаторов Leaf c одним и тем же IP-адресом и MAC-адресом.



Ключевые преимущества концепции Anycast IP Gateway:

• Кардинальное улучшение производительности сети — устранение «тромбонного» эффекта. В традиционной архитектуре трафик между разными VLAN должен проходить через централизованный шлюз, создавая неоптимальные пути. С распределенным шлюзом каждый Leaf-коммутатор выполняет межсетевую маршрутизацию локально, направляя трафик по кратчайшему пути.
• Максимальное использование пропускной способности. Поскольку маршрутизация происходит на каждом Leaf-коммутаторе, нагрузка равномерно распределяется по всей фабрике, а не концентрируется на одном устройстве.
• Беспрецедентная отказоустойчивость и отсутствие единой точки отказа. Если один Leaf-коммутатор выйдет из строя, это повлияет только на устройства, непосредственно к нему подключенные. Все остальные хосты продолжают использовать свои локальные шлюзы без какого-либо влияния на производительность или доступность.
• Мгновенное переключение при отказах. При миграции виртуальной машины с одного сервера на другой — подключенный к другому Leaf- коммутатору — IP и MAC-адрес шлюза остаются неизменными. Виртуальная машина даже не подозревает о том, что теперь использует другой физический шлюз.
• Упрощение управления и конфигурации, единообразная настройка. Все Leaf-коммутаторы настраиваются абсолютно одинаково в части конфигурации шлюзов. Это значительно упрощает развертывание, обслуживание и устранение неисправностей в больших сетях дата-центров.
• Автоматическая синхронизация — коммутаторы автоматически синхронизирует информацию о MAC и IP-адресах хостов между всеми коммутаторами через BGP EVPN.
• Поддержка современных рабочих нагрузок, бесшовная мобильность виртуальных машин. При живой миграции виртуальных машин между физическими серверами в пределах ЦОДа, сетевая конфигурация остается полностью прозрачной. Виртуальная машина сохраняет свой IP-адрес и продолжает использовать тот же IP-адрес шлюза, хотя физически теперь обслуживается другим коммутатором.
• Операционные преимущества, масштабируемость. Добавление новых Leaf-коммутаторов не создает дополнительной нагрузки на существующие шлюзы, поскольку каждый новый коммутатор становится независимым шлюзом для своих хостов.
• Упрощенное планирование ресурсов. Не нужно беспокоиться о том, что централизованный шлюз станет узким местом при росте трафика — каждый Leaf-коммутатор обрабатывает только трафик своих локальных хостов.

В итоге использование IP Anycast gateway вместе с IRB (Integrated Routing and Bridging) позволяет создавать виртуальные L3-интерфейсы на коммутаторах, избавляет от необходимости поднимать трафик на уровень ядра сети и делает возможным маршрутизацию пакетов прямо на уровне Leaf.

Организация наложенной сети передачи данных
Кратко о логической схеме организации нашей сети:

• Маршрутизация опорной сети (Underlay) внутри ЦОДа реализована по протоколу OSPF.
• На основе опорной сети работает наложенная сеть (Overlay), которая маршрутизируется по протоколу iBGP (Internal BGP).
• Каждый ЦОД — это отдельная автономная система. Между ЦОДами настроен eBGP EVPN (External BGP).

А так выглядит схема реально действующей сети в одном из ЦОДов:


Разберём роли каждого устройства сверху вниз.

BR — border router, в каждом ЦОДе их два, через них ЦОД получает доступ в интернет, а также на него приходит трафик платформы и запросы пользователей:

BGW (Border Gateway) — пограничный шлюз, на котором терминируются линки с других ЦОДов (DC Interconnect, DCI), к ним же подключаются BR, SPINE-коммутаторы и NGFW:

NGFW — Firewall — обеспечивает инспекцию и фильтрацию трафика, туда в том числе переехали все правила, которые мы ранее держали на MikroTik:

SP-SW — коммутаторы агрегации Spine, ядро фабрики:

LF-SW — коммутаторы Leaf. Каждый коммутатор Leaf подключается к каждому Spine, а все хосты подключаются уже непосредственно к Leaf:

OOB на схеме — коммутаторы управления серверными IPMI интерфейсами, которые также подключаются к Leaf по M-LAG:

В качестве протокола, отвечающего за туннелирование/инкапсуляцию трафика, мы используем протокол VxLAN. VxLAN подразумевает инкапсуляцию Ethernet-кадров при входе в наложенную сеть и их декапсуляцию при выходе в классическую сеть передачи данных. За выполнение этой процедуры отвечают коммутаторы, называемые VxLAN Tunnel Endpoint или кратко — VTEP. В нашем случае роль VTEP внутри фабрики выполняют коммутаторы уровня доступа — Leaf (LF-SW) и пограничные шлюзы Border Gateway (BGW):

Коммутаторы агрегации Spine внутри фабрики настраиваются в качестве route reflector, чтобы не создавать полносвязную топологию и сократить количество iBGP-сессий для каждого VTEP-коммутатора, которые являются их iBGP-соседями:

Мы уже построили 4 ЦОДа по такой топологии, реальная схема одного из них представлена ниже.


В каждом из четырёх ЦОДов, в которых мы уже построили сети, установлены коммутаторы:

• 8 BGW
• 4 Super SPINE
• 8 SPINE
• 170 LEAF
• 75 IPMI

Казалось бы, теперь можно смело эксплуатировать новую сеть и просто заниматься ее расширением. Однако в момент очередного этапа расширения сети, нам подкинула сюрприз одна из моделей коммутатора известного китайского вендора.

Расширение новой сети
В августе 2024-го вследствие резкого роста трафика нам начало не хватать 100-гигабитных каналов между ЦОДами. Но для их апгрейда на существующих Border Gateway коммутаторах уже просто не было свободных 100-гигабитных портов. На замену в срочном порядке были найдены из наличия коммутаторы с 64 портами по 100 Гбит/с. Поставили — и при переключении начались проблемы.

Напомню, что Border Gateway выполняет роль VTEP’а, инкапсулирует и декапсулирует Ethernet-кадры в рамках протокола VXLAN при входе и выходе из наложенной сети передачи данных (со стороны фабрики и со стороны соседних ЦОДов):

Поменяв коммутаторы, мы обнаружили, что VXLAN-трафик полностью перестал проходить через BGW. Отвалилась связь с соседними ЦОДами, развалилось кольцо и т.д.

В ходе чтения мануалов, тестирования, обращения к вендору, выяснилось: данные коммутаторы на аппаратном уровне не поддерживает технологию VXLAN.

Тем не менее для работы с VXLAN есть обходной путь — нужно создать виртуальный интерфейс service type tunnel, привязать к нему свободные физические порты х2 пропускной способностью, с которой, вы предполагаете, должен проходить VXLAN-трафик (так как он 2 раза проходит инкапсуляцию/декапсуляцию). Например, если через устройство должно проходить 100 Гбит/с VXLAN-трафика, нужно зарезервировать 2 пустых интерфейса по 100 Гбит/с. В нашем случае получается, что мы можем использовать только 32 порта вместо 64 и это будет 100% утилизация портов этого устройства.


Мы планируем заменить эти устройства на модульные коммутаторы того же производителя с 4 картами расширения, по 32х100G, они сделаны на других чипсетах, построены на новой ОС и не имеет подобных ограничений. А также продолжим масштабировать сеть, так как нагрузка на RUTUBE продолжает стабильно возрастать.

Итого

• MikroTik — топ за свои деньги. Наш пример показывает, что при необходимости их можно хорошо оптимизировать, но придётся сильно заморочиться.
• Новая IT-инфраструктура требует построения новых сетей ЦОД. Если вы строите инфраструктуру под микросервисы, использование облаков и других современных архитектурных решений, то старые подходы не подойдут. Есть много новых классных технологий, направленных на оптимизацию работы с этими сервисами, — используйте их.
• Консалтинг и сторонние подрядчики могут быть полезны, не стоит их бояться. Например, нам очень помогли специалисты по оптимизации MikroTik. При строительстве сетей в ЦОДах мы тоже консультировались с подрядчиками и в результате смогли быстро, оптимальным образом построить сеть и сэкономить на оборудовании.

Команда — главный актив любой компании, а наша сила — в опыте и синергии. Теперь команды разработки RUTUBE, PREMIER, Yappy объединяются под брендом RUTUBE TECH. Мы долго шли к этому моменту, это важный этап нашего развития.

Объединение наших tech-команд под брендом RUTUBE TECH — это стратегическое решение, которое выведет наши продукты и сервисы на качественно новый уровень. Мы верим, что смелые идеи — это двигатель личного роста. Поэтому мы создаём среду, где талант становится сильнее, воплощаясь в реальные проекты

отметил CEO RUTUBE TECH Данила Овчаров.

Это важный шаг на пути к построению передовой big-tech компании. Вместе с объединением команд разработки в RUTUBE TECH мы делаем оргструктуру более прозрачной и эффективной, внутри единого юр. лица упростятся ротации между проектами. Мы также переходим к общей матрице должностей и performance review. Cильная и организованная команда — необходимая составляющая нашего успеха

CTO RUTUBE TECH Дмитрий Егоров.

Мы уверены, что это начало новой главы в нашей общей истории.

Хранилище — один из базовых и важнейших элементов видеохостинга. Пользовательские фичи накладываются поверх библиотеки контента, которую нужно надёжно хранить и обеспечивать быстрый и бесперебойный к ней доступ.

В этой статье расскажем, как устроено файловое хранилище RUTUBE с точки зрения SRE, как мы пришли к именно такой конфигурации и как она работает на наших объемах — сейчас это порядка 400 Пбайт или 2 млрд объектов.

Начнём с требований к хранилищу, которые учитывают специфику видеоконтента и архитектуру RUTUBE (кстати, подробнее о ней рассказывается в отдельной статье):

• Надёжность — базовое требование к любому хранилищу.
• Низкая стоимость хранения контента — имеет большое значение, когда речь идёт о таких объемах контента, как у нас.
• Высокое быстродействие — так как обращение к хранилищу может внести существенный вклад в скорость отклика сервиса, а мы хотим, чтобы пользователь не ощущал задержек, когда выбирает просмотр интересного ему видеофайла.
• Горизонтальная масштабируемость тоже очень важна на таком объеме хранения. Так как объемы заливаемого видео постоянно растут, нам нужно регулярно вводить в эксплуатацию новые серверы. Когда вы систематически запускаете по 200-250 серверов файлового хранилища за раз, нужно делать это так, чтобы это занимало минимальное количество времени и требовалось как можно меньше ручного труда инженеров.

Далее подробно разберём, как мы обеспечиваем каждый из пунктов, с фокусом на эффективность хранения.

RUTUBE — видеохостинг, а не банк. Мы не закладываем требование стопроцентной сохранности данных при любых катаклизмах, которое подразумевает обязательно три реплики данных. Мы минимизируем риски потери пользовательского видео, используем две реплики, делаем резервные копии и на практике имели возможность убедиться, что этого достаточно. Когда мы на 10 часов потеряли целиком дата-центр с хранилищем видео, ни один из дисков реплик не вышел из строя и никакие пользовательские данные не были утрачены. Несмотря на очень большие количества жёстких дисков и серверов, в среднем мы теряем примерно от 3 до 10 дисков в месяц, что совсем немного. Поэтому для нас держать три реплики не целесообразно с точки зрения стоимости владения — цена вырастет кардинально.

Серверы видеохранилища
Какие серверы мы используем для файлового хранилища, как балансируем стоимость хранения и производительность на уровне железа?

HDD vs SSD
Как только появились SSD диски, аналитики начали «хоронить» HDD. Первые успехи в массовом производстве и, как следствие, удешевление SSD давали ощущение, что пройдет несколько лет и жесткие диски вымрут, останутся только SSD. Однако мы все всё ещё в той ситуации, когда стоимость хранения на SSD в 10 и более раз превышает стоимость хранения на традиционных жёстких дисках. Развиваются не только SSD, но и в HDD внедряют новые технологии.



Если нужно хранить очень большие объемы данных и при этом нет критичных требований к скорости доступа, конкурентов по стоимости у HDD нет. Типичная комплектация сервера хранилища RUTUBE выглядит следующим образом:



Мы отказались от RAID-массивов и любых СХД на серверах видеохранилища. Используем железо любого вендора, но предъявляем два важных требования:

• возможность полной настройки, от BIOS и IPMI до установки ОС, с помощью утилит, таких как Redfish, для полностью автоматического ввода в эксплуатацию любого количества серверов;
• плотность жестких дисков в сервере не менее 36, а по возможности больше.

Объясню на примере, какое значение на наших объемах имеет плотность дисков в сервере. Рассмотрим современный хороший сервер Supermicro, ёмкость которого 90 жестких дисков на 4 юнита.


Если использовать диски по 18 Тбайт, то ёмкость одного сервера будет 1,62 Пбайт.

Соответственно, в обычную стойку на 10 серверов войдет 16 Пбайт. Это почти в 2,5 раза большая плотность по сравнению с более старой конфигураций на 36 дисков, где максимально в одну стойку можно впихнуть 6,5 Пбайт.


Мы сейчас используем в основном диски на 18 Тбайт, но Seagate уже выпустил в продажу 36-терабайтные серверные диски. С ними в одну стойку уже можно уместить 32 Пбайта — то есть всё видеохранилище, накопленное RUTUBE к лету 2025-го, без учёта репликации можно уместить всего в 15 стоек! А раньше это было бы несколько машинных залов.

Почему мы здесь вообще считаем стойки? Во-первых, их аренда тоже стоит денег: средняя цена по рынку где-то 140 тысяч рублей в месяц. В нашем примере при хранении 16 Пбайт на серверах по 90 дисков вместо 36 экономия получится 210 тысяч рублей в месяц. Не столь заметно для большой компании, но это ещё не всё.

Во-вторых, давайте рассчитаем стоимость железа на примере тех же серверов Supermicro 12-го поколения. С одной стороны, сама платформа на 90 дисков почти в два раза дороже, с другой — требуется 10 серверов, а не 25 (для ориентира используем цены европейского поставщика, потому что в России логистические факторы вносят существенные коррективы).


Даже при более дорогой платформе разница на эту ёмкость составит 34% или 36755 €.

Ниже расчёт для полной комплектации серверов со всем железом на платформе одного поколения — здесь разница составляет 21% и больше 128870 €.


Серверное ПО
На серверах видеохранилища RUTUBE стоит:

• Rocky Linux — дистрибутив, который появился как форк Red Hat Enterprise Linux и должен быть на 100% с ним совместимым.
• Angie — nginx-совместимый форк, который имеет дополнительные плюшки, например, в виде возможности получения конфигурации сервера и статистики по API и большого набора уже собранных сторонних модулей.
• Модуль Kaltura для адаптивного видеостриминга.
• FileHeap — самописное ПО, о котором поговорим дальше.

Указанные характеристики позволяют нам не испытывать каких-либо проблем с производительностью на серверах видеохранилища. Пиковый трафик отдачи RUTUBE составляет примерно 7 Тбит/с, однако он распределяется по CDN (подробнее о CDN RUTUBE читайте в отдельной статье), а нагрузка по сети на один сервер весьма разумная.

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


Нагрузка на процессор (старого сервера с однопроцессорной конфигурацией) в пике составляет 40%, обычно меньше.



FileHeap
RUTUBE создавался в 2006 году. Тогда ещё не существовало хороших общепринятых готовых решений для файлового хранилища, Amazon S3 и Ceph появились позже. Поэтому видеохранилище создавалось логичным и доступным тогда способом — с нуля самостоятельно, ориентируясь на основную задачу, то есть хранение видео для видеохостинга.


Наше ПО управления хранилищем называется FileHeap. Оно написано на Python, для хранения всех объектов используется RabbitMQ и PostgreSQL, для кеша — Redis. Это хранилище разработано специально для хранения видео, оптимизировано под него и ни для чего другого не используется.

Рассмотрим основные задачи FileHeap.

• Управление хранилищем контента — стандартный необходимый набор админских функций: добавлять и удалять серверы, регулировать количество репликаций, добавлять и удалять пользователей и так далее.
• Загрузка/удаление контента в хранилище. Основная функция для любого файлового хранилища — загрузка файлов и их удаление.
• Получение сведений о контенте в хранилище — его хэш-суммы, даты и всей информации о файле, которая нам необходима.
• Раздача контента клиентам. FileHeap на самом деле ничего не раздаёт пользователям, он лишь сообщает сервису балансировки, где находится видео, на каком сервере его необходимо найти: в основном видеохранилище или в реплике на CDN-серверах. На основании чего уже балансер генерирует манифест для потока и отдаёт его на клиент.
• Актуализация storage — постоянный процесс поддержания необходимого количества активных актуальных реплик (напомним, у нас их две).
• Валидация storage — постоянный процесс проверки на ошибки доступности жестких дисков непосредственно на сервере. Если что-то выходит из строя, FileHeap сразу же узнаёт об этом через RabbitMQ, автоматически запускается система создания активных реплик на других дисках или серверах.
• Балансировка storage — процесс перемещения реплик по серверам хранения для равномерного распределения нагрузки на них. Обычно мы добавляем сервера большими пачками, например, по 200 новых за раз. Чтобы не влиять на производительность хранилища, переносим данные в фоновом режиме, когда нагрузка на существующие серверы минимальна. Так постепенно контент размазывается по серверам, что позволяет равномерно балансировать нагрузку между ними.
• Check online storage — процесс проверки реплики на доступность. Сервер хранилища может даже быть жив, но потерять сетевую связность с CDN — мы это тут же увидим на мониторинге, а балансировщик будет создавать манифест с живыми серверами, чтобы пользователи ничего не заметили.

Ниже схема взаимодействия видеосервисов. В рамках этой статьи не будем углубляться во все элементы (напишите в комментариях, что стоит раскрыть подробнее в следующих материалах), здесь нас интересует хранилище, в том числе то, как видео в него попадает.



Как видео попадает в видеохранилище
Пользователь может залить видео практически в любом формате и любом качестве. Мы поддерживаем upload для: MP4, AVI, WMV, MOV, FLV, MPEG-1, MPEG-2, MPEG-4, MPG, MPEGPS, 3GPP, WebM, DNxHR, ProRes, CineForm, HEVC (H.265). Загруженное видео нам нужно преобразовать в формат, который мы потом сможем показать на всём многообразии пользовательских устройств. Соответственно, перед тем как положить видео в основное видеохранилище, нужно его перекодировать (у нас основной кодек H.264) и нарезать в разные качества для адаптивного стриминга (поддерживаем от 144p до 8К).

Разберём этот процесс по шагам.

• Данные от пользователя загружаются на upload-серверы, которые представляют из себя, по сути дела, просто серверы временного хранения, но с очень быстрыми NVMe-дисками. Их не очень много и их основная цель — максимально быстро получить контент от пользователя и начать обработку.
• Как только видео заливается на upload, оно отдаётся на сервер транскодирования, который у нас называется WatchDuck.
• Каждое видео нарезается во все поддерживаемые качества (ниже исходного) и в нужном кодеке отправляется в FileHeap.
• FileHeap раскладывает все экземпляры видео во всех качествах по двум серверам видеохранения обязательно в двух разных дата-центрах.

Особенности хранения очень большого количества файлов
Как мы видим, видео хранится во многих качествах, то есть 400 млн единиц контента превращается примерно в 2 миллиарда объектов хранилища. Это может стать проблемой, если не учесть одну особенность устройства файловых систем, про которую нередко забывают в современной разработке. Возможно, потому что люди всё реже работают на низком уровне, а всё чаще оперируют абстракциями типа контейнеров.

Представьте: проект тестировали на dev, всё было хорошо, всё работало быстро. Отдали на прод, и через какое-то время производительность очень деградировала или и вовсе проект перестал работать. Что случилось?

Дело в том, что для хранения всех, скажем, пользовательских картинок разработчикам выдали один бакет. Однако в большинстве случаев, в частности в случае популярной реализации S3 MinIO, бакет — это просто отдельная папка в файловой системе (больше о работе с MinIO читайте в другой статье из нашего блога).


На 10-20 тысяч файлов — а dev за эти рамки обычно не выходит — всё замечательно работает. Далее проект выходит в продакшен, несколько недель нормально функционирует, бакет заполняется, и начинается резкая деградация скорости ответа MinIO. По достижении примерно 100 тысяч файлов (зависит от файловой системы на серверах) система полностью выходит из строя и уже не отдает ничего. Причем быстро это исправить проблематично.

Чтобы предотвратить подобное поведение, давно придумали хеш-структурированное хранение. Работает следующим образом: берётся, например, хеш-сумма файлов (мы вместо хеш-суммы используем UUID), создаются папки и подпапки по значениям последних символов хеш-суммы, файлы раскладываются в соответствующие подпапки — ни одна директория не переполняется.


Глубина вложенности может быть 2 или 3, при этом используется 4 или 6 последних символов хеш-сумм (или UUID, как в нашем случае). При вложенности 2 получается, что будет создано (16*16) ² = 65536 поддиректорий. При вложенности 3 получится уже ≈16 млн поддиректорий.

Для наглядности рассчитаем подходящую глубину вложенности в случае видеохранилища RUTUBE. На диски по 18/36 Тбайт, которые мы используем, помещается порядка 100 000 файлов — видео тяжелые и в среднем занимают несколько сотен мегабайт. При глубине вложенности 2 получится по 5-10 файлов в директории — это нам подходит. Если сделать глубину вложенности 3, то можно разложить 1 млрд файлов (примерно по 60 файлов в каждой директории). Таким образом можно в тот же самый бакет заливать сколько угодно файлов, просто регулируя глубину вложенности по папкам.

Хеш-структурированное хранение даёт не столько ускорение, сколько просто возможность создать рабочую масштабируемую конфигурацию и хранить миллиарды файлов без потери производительности. Потому что иначе, если в одном каталоге будет слишком много объектов, файловая система в Unix-системах будет отвечать очень медленно вплоть до полной невозможности с ней работать.

Раздача видеоконтента
Контент, который мы складываем в видеохранилище, мы храним не просто так, а чтобы наши зрители в любой момент могли посмотреть что-то интересное для себя — сделать это без задержки и с любого устройства. За минимизацию задержки отвечает двухуровневый CDN, где на первом уровне кешируется холодный контент, а на втором — расположенном как можно ближе к зрителям — горячий, то есть наиболее популярный в данном регионе.


А для того, чтобы видео воспроизводилось на самых разных устройствах — от компьютеров до бюджетных телефонов и Smart TV — мы как раз и перекодируем исходное видео и используем алгоритмы адаптивного стриминга.

Существует два основных протокола адаптивного видеостриминга: HLS (HTTP Live Streaming, разработан Apple в 2009) и DASH (Dynamic Adaptive Streaming over HTTP, разработан рабочей группой MPEG в 2011 году). Они отличаются способами организации манифеста, но базово устроены похоже и вы точно сталкивались с их работой. Именно они отвечают за то, чтобы, если у пользователя ухудшилось качество связи, воспроизведение не прервалось, а просто уменьшить разрешение видео.

Протокол адаптивного стриминга позволяет переключаться между фрагментами подходящего разрешение. Однако, естественно, заранее заготовить всевозможное разбиение на фрагменты невозможно и нерационально, поэтому используется переупаковка на лету.

Чтобы на лету нарезать нужные фрагменты, мы используем nginx-модуль vod от компании Kaltura. Он читает исходный mp4-файл и динамически его сегментирует в нужный протокол: HLS (.m3u8 + .ts) или DASH (.mpd + .mp4).

Ниже короткие примеры конфигурации:

location /hls-vod/ {
    alias /media/;
    vod hls;
    vod_bootstrap_segment_durations 2000;
    vod_bootstrap_segment_durations 2000;
    vod_segment_duration 4000;
    vod_base_url "$video_id.mp4/";
    vod_mode local;
    hls_metadata_cache 16m;
    vod_align_segments_to_key_frames   on;
    vod_hls_segment_file_name_prefix   "segment";
    vod_manifest_segment_durations_mode accurate;
}
location /dash-vod/ {
    alias /media/;
    vod dash;
    vod_bootstrap_segment_durations 2000;
    vod_bootstrap_segment_durations 2000;
    vod_segment_duration 4000;
    vod_align_segments_to_key_frames on;
    vod_manifest_duration_policy min;
    vod_dash_manifest_format segmenttemplate;
    vod_dash_profiles urn:mpeg:dash:profile isoff-live:2011;
    vod_base_url "$video_id.mp4/";
}

Здесь созданы две локации, где в качестве root мы указываем одну и ту же папку с одними и теми же видеофайлами. При обращении к одной пользователь будет получать манифест DASH, к другой — HLS. Из основных параметров — длина чанков, и для разных форматов стриминга она может быть задана по-разному.

Получается, что с одним сервером хранения может работать два плеера. Выбор между DASH и HLS зависит от того, что поддерживает устройство пользователя и что в данном случае будет эффективнее.

Пример запроса от плеера за HLS:

/hls-vod/0x5000c500c32ab248/77/ec/a8ae0fb363484dc180705b8a5dbc77ec.mp4/index.m3u8

Пример запроса от плеера за DASH:

/dash-vod/0x5000c500c32ab248/77/ec/a8ae0fb363484dc180705b8a5dbc77ec.mp4/manifest.mpd

А ещё vod-модуль позволяет на лету генерировать превью (thumbnails) — то есть картинку из видеофайла как стоп-кадр по временной метке в миллисекундах. Зачем это нужно? Во-первых, для перемотки по таймлайну, чтобы пользователь на миниатюрах видел, куда перетаскивает курсор. Во-вторых, для создания обложек. Авторы, которые заливают видео на RUTUBE, могут загрузить свою обложку, а могут использовать любой стоп-кадр, который и будет показываться на главной странице.

Надо заметить, что подход переупаковки на лету, кроме того что помогает экономить место в хранилище и обеспечивает скорость доступа к видео, еще и не вычислительно затратный. Единственную нагрузку создаёт генерация превью, нарезка чанков фактически не использует CPU, потому что это просто сегментирование MP4, никакой сложной обработки видео для этого не требуется.

Выше на графике скорость раздачи со всех вместе взятых серверов файлового хранилища. Пик нагрузки составляет ≈525 Гбит/с при общем трафике нашей платформы около 7Тбит/с. Это значит, что большая часть раздачи происходит с CDN-серверов, из хранилища забирается только незакешированое по CDN видео.

Это как раз и есть одна их главных особенностей хранилища в видеосервисе. Когда новое классное видео только появляется на платформе, его много смотрят и соответственно оно отдаётся с горячих CDN. Однако через какое-то время его уже смотрят единицы раз — с CDN оно вымывается, остаётся в основном видеохранилище, но так как интерес к нему уже не очень большой, то это не генерирует большую нагрузку. Не для всех видов контента, но для многих категорий деление на горячий и холодный контент ярко выражено.


Также для экспериментов и резервного копирования мы используем S3 у разных партнеров. Но, как показала практика, производительность S3 в холодной конфигурации оставляет желать лучшего. Мало у кого из партнеров её в принципе достаточно для того, чтобы раздавать видео. В некоторых случаях, максимум, на что можно рассчитывать, это положить бэкап и забыть. Всё остальное — непозволительная роскошь, использовать что-либо кроме холодной конфигурации слишком дорого. Поэтому мы и остановились на использование собственных обычных серверов без СХД и RAID-массивов.

Итоги
Спроектированная еще в 2006 году система хранения видео RUTUBE, конечно, многократно дорабатывалась, в неё добавлялись новые функциональные элементы, но на уровне базовой архитектуры она сохранила свою простоту, которая сейчас позволяет нам легко масштабироваться под любые нагрузки.

Подход, описанный в этой статье, обеспечивает:

• Производительность, которая позволяет обрабатывать миллионы запросов без деградации скорости.
• Отказоустойчивость — данные дублируются на уровне целых серверов и дата-центров, а не отдельных дисков. Отказ целого дата-центра не приводит к потере данных.
• Масштабируемость — новые серверы и диски легко конфигурируются и автоматически раскатываются по системе управляющей хранилищем, что позволяет на лету перестраивать топологию и гибко масштабироваться под растущие нагрузки.
• Гибкость и полный контроль — можно настраивать репликацию под конкретные требования и ситуацию.
• Оптимизацию стоимости хранения, благодаря контролю всех слоёв.

Поэтому, если перед вами сейчас стоит задача проектирования хранилища для большого количества тяжелых данных и вы уделяете большое внимание стоимости хранения, то, возможно, готовые сторонние решения для вас тоже неоптимальны и какие-то из наших подходов окажутся вам полезны.