Присоединяйтесь к митапу для продактов
Ждем вас 20 ноября в 18:00 на митапе «Selectel x Продакты СПб». Встретимся, чтобы узнать, как погрузиться в специфику сложного B2B-продукта и разбираться в технических вопросах. Будем не просто слушать доклады, но и находить полезные знакомства.



selectel.ru/blog/events/product-meetup-2025/

Современные кибератаки все чаще нацелены не просто на кражу данных, а на их полное уничтожение. В таких условиях эффективность резервного копирования определяется не количеством копий, а их защитой и недоступностью. Именно поэтому ведущие стандарты информационной безопасности — от NIST до рекомендаций ФСТЭК — настоятельно рекомендуют внедрять многоуровневую модель резервного копирования, в которой последний, самый надежный слой должен быть физически изолирован и аппаратно неизменяем.

Такой подход получил название «3-2-1-1»: когда создаются 3 копии данных (оригинал + 2 резерва), которые сохраняются с использованием 2 различных типов носителей. При этом 1 копия хранится вне основного места размещения в неизменяемом формате на носителе однократной записи и, что особенно важно, 1 копия — в офлайн-режиме, без подключения к сети.

Именно на этом, решающем этапе стратегии применяется архивный оптический накопитель ЭЛАРобот НСМ, использующий оптические диски Blu-ray XL ArchivalGrade — диски однократной записи, полностью исключающие возможность удаления или модификации данных.

Роль ЭЛАРобот НСМ в архитектуре резервного копирования
В типовой схеме ИТ-инфраструктуры резервные копии проходят несколько этапов.

• Первичное резервирование — выполняется ежедневно на локальные СХД или виртуальные машины. Эти копии «горячие»: быстро доступны, но уязвимы.
• Репликация и снапшоты — обеспечивают краткосрочное восстановление, но также остаются в пределах корпоративной сети.
• Долгосрочный архив — данные, редко используемые, но критически важные (например, «золотые» бэкапы баз данных, архивы информационных систем, документы и технические проекты) выносятся в «холодное» хранилище.

Именно на третьем уровне и размещается ЭЛАРобот НСМ — как доверенное хранилище, завершающее цепочку защиты. После того как данные записаны на оптические диски, они становятся аппаратно неизменяемыми. Затем картриджи с дисками извлекаются из роботизированной библиотеки и помещаются в специализированные модули офлайн-хранения, где полностью отключены от любой вычислительной среды.


Такой подход реализует принцип «воздушного зазора» с неизменяемостью на аппаратном уровне. Даже в случае взлома основной ИТ-инфраструктуры и проникновения в корпоративную среду вредоносных шифровальщиков, данные на оптических дисках остаются нетронутыми. Это единственный способ гарантировать возможность восстановления после различных видов атак, в том числе, когда злоумышленники угрожают удалить и уничтожить все сохраненные резервы.

Процесс интеграции ЭЛАРобот НСМ в существующую систему резервного копирования выполняется с помощью стандартных протоколов (NFS/SMB) и программных систем резервного копирования.

Встроенная в программно-аппаратный комплекс система администрирования автоматически распределяет данные по оптическим дискам и формирует индексную базу. После завершения записи картриджи могут быть переведены в статус «офлайн» — физически извлечены и помещены в шкафы с RFID-учетом.

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



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

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

Накопители ЭЛАРобот НСМ используют Blu-ray диски формата BDXL уровня ArchivalGrade, при производстве которых на поверхность дисков наносится специальное покрытие, защищающее диски от износа и деградации. Это гарантирует долговечность хранения данных, отсутствие деградации носителей и повышенную устойчивость к условиям окружающей среды (влажность, температура, электромагнитное излучение).

За счет физических свойств носителя технология обеспечивает аппаратную защиту информации и неизменность данных на период свыше 50 лет. В процессе эксплуатации не требуется замена оптических дисков и миграция данных.


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

ЭЛАРобот НСМ предназначен не для замены систем резервного копирования, а для расширения их возможностей. Комплекс дополняет традиционные системы, создавая последний рубеж обороны, за которым сохраняется возможность восстановления данных даже в самых экстремальных сценариях.

Принцип работы ЭЛАРобот НСМ
ЭЛАРобот НСМ — отечественный высокотехнологичный программно-аппаратный комплекс для реализации процессов информационной безопасности, долговременного хранения и защиты информации. Комплекс представляет собой роботизированный накопитель на базе архивных оптических носителей, сочетающий в себе функции автоматизированного резервного копирования и доверенного хранения.



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

Диски помещаются в защитные картриджи, оснащенные RFID-метками для автоматической идентификации. Роботизированный манипулятор при поступлении команды на чтение или запись автоматически извлекает диски из картриджей и загружает в оптические приводы. В зависимости от конфигурации система может содержать от 2 до 36 приводов, что обеспечивает параллельную запись и высокую пропускную способность при резервном копировании. После завершения операций диски автоматически возвращаются в картриджи.

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



Оптические накопители ЭЛАРобот НСМ зарегистрированы в Едином реестре российской радиоэлектронной продукции Минпромторга РФ и поставляются в рамках 44-ФЗ, 223-ФЗ и ГОЗ. Они являются идеальным выбором для отказоустойчивого хранения, защиты информации и резервного копирования в государственных и коммерческих дата-центрах, на объектах критической информационной инфраструктуры и оборонной промышленности, в банках, российских госучреждениях и компаниях из различных отраслей.

elar.ru/skanery-i-proizvodstvo/nsm/

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

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

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

Стартует главная распродажа года — 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 Дмитрий Егоров.

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