Наша почта:
В Москве:
РФ (звонок бесплатный):
Как мы строим сеть национального видеохостинга Rutube
{ Руководитель отдела развития и эксплуатации сети в Rutube }
Олег Аралбаев
Видео доклада
Презентация спикера
Rutube:
Rutube - национальный видеохостинг, крупнейшая российская видеоплатформа. С 2020 года Rutube входит в холдинг «Газпром-Медиа», и именно с этого момента начинается бурное развитие видеосервиса. Если открыть сайт сегодня, то на 90% всё, что на нём есть, разработано и внедрено за последние 3–4 года. Помимо Rutube в «Газпром-Медиа» входит множество медиаактивов — телеканалы, радиостанции и большое количество других проектов, занимающихся производством или распространением медиаконтента.
Сегодняшние показатели: более 17 миллионов ежедневных уникальных пользователей заходят на видеоплатформу. Их обслуживают более 4000 серверов в пяти центрах обработки данных.
Сегодняшние показатели: более 17 миллионов ежедневных уникальных пользователей заходят на видеоплатформу. Их обслуживают более 4000 серверов в пяти центрах обработки данных.
Наследие: legacy-сеть
Сеть досталась «по наследству». Команда, эксплуатировавшая её ранее, переключилась на другие задачи, оставив минимальные инструкции о том, как она работает и где что находится, — по большей части на уровне схем.
Оборудование оказалось не от вендора первого эшелона: не Huawei, не Cisco и не кто-либо подобный. По всей сети в качестве бордер-роутеров стояли MikroTik CCR1072.
На тот момент сеть выглядела так: 31 сетевое устройство, пять ЦОД плюс офисная сеть. В роли бордер-роутеров — CCR1072, причём на каждом была отдельная DMZ-сеть, отдельный NAT без резервирования. Все стыки с интернет-провайдерами были подняты на статике, без BGP. Между ЦОД работали 20-гигабитные каналы.
Это был серьёзный стресс. Было непонятно, с чего начинать и за что хвататься: где-то есть проблема, но неясно, это неверная настройка или неверно выбранная архитектура. И это несмотря на то, что у команды более 10 лет опыта работы с Cisco, Huawei, Juniper и любыми подобными устройствами.
Оборудование оказалось не от вендора первого эшелона: не Huawei, не Cisco и не кто-либо подобный. По всей сети в качестве бордер-роутеров стояли MikroTik CCR1072.
На тот момент сеть выглядела так: 31 сетевое устройство, пять ЦОД плюс офисная сеть. В роли бордер-роутеров — CCR1072, причём на каждом была отдельная DMZ-сеть, отдельный NAT без резервирования. Все стыки с интернет-провайдерами были подняты на статике, без BGP. Между ЦОД работали 20-гигабитные каналы.
Это был серьёзный стресс. Было непонятно, с чего начинать и за что хвататься: где-то есть проблема, но неясно, это неверная настройка или неверно выбранная архитектура. И это несмотря на то, что у команды более 10 лет опыта работы с Cisco, Huawei, Juniper и любыми подобными устройствами.
Взятие сети под контроль
Первым шагом стало взятие сети под контроль. Для этого:
- 1.Развернули TACACS+ сервер для централизованной авторизации на всех устройствах;
- 2.Внедрили RANCID для сохранения конфигураций и ведения версионности;
- 3.Настроили syslog для аудита на всех сетевых устройствах;
- 4.Выделили Zabbix 7-й версии для мониторинга всего парка сетевых устройств.
Перенастройка MikroTik
Самым сложным этапом стала перенастройка роутеров MikroTik. Чтобы сделать это быстро и правильно, обратились в компанию, которая более 10 лет занимается внедрением проектов на оборудовании MikroTik. Она провела аудит и обучила инженеров базовому курсу, чтобы понимать, как устроена работа этих устройств.
Были перенастроены все правила firewall на MikroTik. Закрыли доступы, повесили ACL — до этого внутри сети доступ был полностью открыт. Все стыки с интернет-провайдерами перевели на BGP. Постепенно апгрейдили каналы между ЦОД: сначала с 20 до 40, затем до 100, а в прошлом году перешли на 400-гигабитные каналы.
Были перенастроены все правила firewall на MikroTik. Закрыли доступы, повесили ACL — до этого внутри сети доступ был полностью открыт. Все стыки с интернет-провайдерами перевели на BGP. Постепенно апгрейдили каналы между ЦОД: сначала с 20 до 40, затем до 100, а в прошлом году перешли на 400-гигабитные каналы.
Казалось бы, сеть настроена, MikroTik в порядке — можно выдохнуть. Но не тут-то было.
Оптимизация нагрузки на CPU: переход на цепочки
Из-за большого количества правил firewall и BGP-сессий с новыми провайдерами (а значит, из-за возросшей нагрузки) роутеры начали дропать все подряд BGP-сессии и регулярно перезагружаться из-за 100% загрузки CPU.
Масштаб был такой:
Порядка 1500 IP-адресов и подсетей в address-list, около 500 правил firewall и 20–30 Гбит/с общего трафика на роутер в часы наибольшей нагрузки. Было решено «полечить» их переходом на цепочки — чтобы снизить нагрузку на CPU и увеличить скорость обработки пакетов.
- Если цепочки не используются:трафик проходит так: входящий пакет (речь про chain forward) с какого-то интерфейса, уходящий на какой-то интерфейс, последовательно проходит по всему списку правил до первого совпадения. Если сработало правило с drop — пакет отбрасывается.
- Цепочки же позволяютуже на уровне входящих интерфейсов сразу распределять пакет на правила, предназначенные именно ему, по определённому признаку. MikroTik не приходится обрабатывать всю «портянку» правил — он обрабатывает лишь небольшой набор, относящийся к конкретному сервису.
Переход на RouterOS 7
Дропы BGP-сессий в часы наибольшей нагрузки не прекратились. Причина в том, что в RouterOS 6 процесс routing не умеет распределяться по ядрам — за него отвечает единственное ядро на каждом MikroTik. А поскольку были добавлены ещё и внешние BGP-провайдеры, ситуация ухудшилась.
В итоге приняли решение обновиться до 7-й версии. На тот момент она была довольно сырой, но выбора не было. Пришлось пожертвовать протоколом BFD — в RouterOS 7 он тогда ещё не поддерживался. Сейчас установлена версия 7.13.3 — не последняя, но большинство сервисов
(практически всё) уже переехало с MikroTik.
После апгрейда MikroTik стали держать нагрузку прекрасно: в среднем каждое ядро загружено не более чем на 15%, BGP-сессии перестали дропаться, процесс routing распределился по ядрам. Стало ясно, что с этим оборудованием можно жить. Это действительно классная железка, если правильно её настроить — в несколько этапов на протяжении нескольких месяцев. Бонусом апгрейда на 7-ю версию стала дополнительная функция мониторинга BGP-пиров, которой в 6-й версии по какой-то причине не было и которая очень пригодилась.
В итоге приняли решение обновиться до 7-й версии. На тот момент она была довольно сырой, но выбора не было. Пришлось пожертвовать протоколом BFD — в RouterOS 7 он тогда ещё не поддерживался. Сейчас установлена версия 7.13.3 — не последняя, но большинство сервисов
(практически всё) уже переехало с MikroTik.
После апгрейда MikroTik стали держать нагрузку прекрасно: в среднем каждое ядро загружено не более чем на 15%, BGP-сессии перестали дропаться, процесс routing распределился по ядрам. Стало ясно, что с этим оборудованием можно жить. Это действительно классная железка, если правильно её настроить — в несколько этапов на протяжении нескольких месяцев. Бонусом апгрейда на 7-ю версию стала дополнительная функция мониторинга BGP-пиров, которой в 6-й версии по какой-то причине не было и которая очень пригодилась.
Проектирование новой сети под новую IT-инфраструктуру
Помимо оптимизации старой сети команде поручили проектирование новой — под новую IT-инфраструктуру, которая значительно превосходила текущую.
Есть стандартная схема, известная многим: доступ — агрегация — ядро, понятный протокол маршрутизации, понятное оборудование, схема резервирования и всё остальное. Но такие сети предназначены в основном для трафика «север — юг»: трафик идёт на уровень ядра, там маршрутизируется, выходит и приходит на какой-то хост. В случае ЦОД требуется построить сети, где превалирует трафик «запад — восток».
Есть стандартная схема, известная многим: доступ — агрегация — ядро, понятный протокол маршрутизации, понятное оборудование, схема резервирования и всё остальное. Но такие сети предназначены в основном для трафика «север — юг»: трафик идёт на уровень ядра, там маршрутизируется, выходит и приходит на какой-то хост. В случае ЦОД требуется построить сети, где превалирует трафик «запад — восток».
Архитектура Clos и коммутаторы Leaf-Spine
- Была выбрана архитектура Clos и коммутаторы Leaf-Spine. Технологию стоит изучить каждому сетевому инженеру: если в современной IT-компании есть сетевая инфраструктура (а там обычно микросервисы и виртуализация), то примерно в 90% случаев она построена именно на сетях Clos.
- Была построена Leaf-Spine фабрика, где коммутаторы доступа Leaf связаны со всеми коммутаторами агрегации Spine. В качестве технологии наложенной (overlay) сети выбран VXLAN, а для автоматизации распространения маршрутной информации и MAC-адресов — BGP EVPN.
Проектирование новой сети под новую IT-инфраструктуру
Помимо оптимизации старой сети команде поручили проектирование новой — под новую IT-инфраструктуру, которая значительно превосходила текущую.
Есть стандартная схема, известная многим: доступ — агрегация — ядро, понятный протокол маршрутизации, понятное оборудование, схема резервирования и всё остальное. Но такие сети предназначены в основном для трафика «север — юг»: трафик идёт на уровень ядра, там маршрутизируется, выходит и приходит на какой-то хост. В случае ЦОД требуется построить сети, где превалирует трафик «запад — восток».
Есть стандартная схема, известная многим: доступ — агрегация — ядро, понятный протокол маршрутизации, понятное оборудование, схема резервирования и всё остальное. Но такие сети предназначены в основном для трафика «север — юг»: трафик идёт на уровень ядра, там маршрутизируется, выходит и приходит на какой-то хост. В случае ЦОД требуется построить сети, где превалирует трафик «запад — восток».
- Классический бонус таких сетей — лёгкое масштабирование:чтобы подключить новую фабрику хостов, достаточно добавить ещё одну пару Leaf-коммутаторов и связать её со Spine — и появляются новые условные 48–96 портов. Кроме того, в этой топологии отсутствует STP, поэтому используются все линки и вся пропускная способность сети.
- Ещё один реализованный механизмодин из стандартных — распределённый шлюз и симметричная маршрутизация. На каждой паре коммутаторов настраивается распределённый шлюз, и поднимать трафик на уровень ядра не требуется: как только трафик попадает на ближайший Leaf, он тут же маршрутизируется на следующий Leaf. В результате — понятное количество хопов до любого хоста в пределах ЦОД и минимальные задержки.
- Подключение по MLAGк каждой паре коммутаторов сервер либо коммутатор управления подключается двумя интерфейсами, образуя MLAG-пару. Это даёт резервирование (если один линк упал, работает второй) и удвоение пропускной способности. Обычно используются интерфейсы 10 или 25 Гбит/с.
Логически сеть построена так:
в качестве протокола опорной сети используется OSPF, на наложенной сети — iBGP и EVPN. Каждый ЦОД — это отдельная автономная система, а между ЦОД настроен iBGP.
в качестве протокола опорной сети используется OSPF, на наложенной сети — iBGP и EVPN. Каждый ЦОД — это отдельная автономная система, а между ЦОД настроен iBGP.
Функционал устройств в схеме одного из реализованных ЦОД:
- 1.Бордер-роутеры — по два в каждом ЦОД.
- 2.Border Gateway (BGW) — пограничный шлюз, на котором терминируются линки с других ЦОД.
- 3.Firewall — куда же без них: сюда переехали все те правила, что раньше существовали на MikroTik.
- 4.Коммутаторы агрегации Spine — ядро фабрики.
- 5.Коммутаторы Leaf — к ним непосредственно подключаются все хосты, а также по MLAG подключаются коммутаторы управления серверами (IPMI).
VXLAN
В качестве технологии наложенной сети выбран VXLAN. VXLAN подразумевает инкапсуляцию Ethernet-пакетов при входе в наложенную сеть и их декапсуляцию при выходе в классическую сеть передачи данных. За это отвечают коммутаторы VXLAN Tunnel Endpoint (VTEP) — их роль выполняют BGW и коммутаторы Leaf. Spine-коммутаторы настраиваются как route reflector, чтобы не создавать полносвязную топологию и уменьшить количество iBGP-сессий для VTEP-коммутаторов, являющихся их iBGP-соседями.
По такой топологии уже построено четыре ЦОД, причём в двух из них реализована трёхуровневая топология: super-spine, spine и leaf.
По такой топологии уже построено четыре ЦОД, причём в двух из них реализована трёхуровневая топология: super-spine, spine и leaf.
Проблема масштабирования: BGW и аппаратная поддержка VXLAN
В августе прошлого года резко уперлись в 100-гигабитные каналы между ЦОД, а портов для их апгрейда на существующих коммутаторах уже не было. В срочном порядке начали искать оборудование на замену коммутаторам Border Gateway. Нашли решение известного китайского вендора: 64 порта 100 Гбит/с, два коммутатора. Их поставили — и начались проблемы.
Задача Border Gateway — принимать VXLAN-трафик со стороны другого ЦОД и декапсулировать его, принимать VXLAN-трафик со стороны фабрики и тоже декапсулировать, гоняя его туда-сюда. После запуска новых коммутаторов VXLAN-трафик не пошёл вообще: пропала связь с соседними ЦОД, развалилось кольцо.
В ходе чтения мануалов, тестирования и обращения к вендору выяснилось, что этот коммутатор на аппаратном уровне не поддерживает технологию VXLAN. Чтобы всё заработало (а времени на замену не было), нужно — прямо по мануалу — создать виртуальный интерфейс типа tunnel (service-type tunnel) и привязать к нему физически не занятые порты с той пропускной способностью, с которой предполагается пропускать VXLAN-трафик. То есть если через устройство должно проходить 200 Гбит/с VXLAN-трафика, нужно зарезервировать два пустых 100-гигабитных интерфейса. В результате при 100% утилизации устройства 32 порта по 100 Гбит/с просто не используются.
Поэтому на следующий год запланирована замена этих устройств на модель 9865, сделанную на другом ASIC, где такой проблемы нет.
Сетевая часть CDN
BGP Anycast
Технология BGP Anycast подразумевает, что из нескольких точек присоединения к сети Интернет анонсируется одна и та же подсеть /24 с одной и той же автономной системой. Это даёт следующие эффекты. Во-первых, теоретически пользователь, исходя из таблицы маршрутизации своего провайдера, приходит на ближайший к нему кэш-сервер. Во-вторых, если этот ближайший кэш-сервер вышел из строя и его анонс пропал, провайдер пользователя, обновив таблицу форвардинга, отправляет пользователя на следующий по приоритету BGP-маршрут.
Так, пользователь условно из Барнаула запрашивает Anycast-адрес static.ru и попадает на ближайший сервер — новосибирский. В основном Anycast используется для анонсирования статического контента — картинок и превью. Если открыть сайт РУТУБ, все картинки и превью загружаются именно по Anycast.
Кроме того, Anycast используется для резервирования CDN. В манифесте (файл, который подгружается при старте просмотра видео и содержит ссылки на серверы, где хранится видео) прописан резервный адрес: если плеер по каким-то причинам не может достучаться до основного кэш-сервера, он автоматически пробует пойти на резервный. Этот резервный адрес анонсируется со всех кэш-серверов первого уровня по Unicast.
Технология BGP Anycast подразумевает, что из нескольких точек присоединения к сети Интернет анонсируется одна и та же подсеть /24 с одной и той же автономной системой. Это даёт следующие эффекты. Во-первых, теоретически пользователь, исходя из таблицы маршрутизации своего провайдера, приходит на ближайший к нему кэш-сервер. Во-вторых, если этот ближайший кэш-сервер вышел из строя и его анонс пропал, провайдер пользователя, обновив таблицу форвардинга, отправляет пользователя на следующий по приоритету BGP-маршрут.
Так, пользователь условно из Барнаула запрашивает Anycast-адрес static.ru и попадает на ближайший сервер — новосибирский. В основном Anycast используется для анонсирования статического контента — картинок и превью. Если открыть сайт РУТУБ, все картинки и превью загружаются именно по Anycast.
Кроме того, Anycast используется для резервирования CDN. В манифесте (файл, который подгружается при старте просмотра видео и содержит ссылки на серверы, где хранится видео) прописан резервный адрес: если плеер по каким-то причинам не может достучаться до основного кэш-сервера, он автоматически пробует пойти на резервный. Этот резервный адрес анонсируется со всех кэш-серверов первого уровня по Unicast.
Архитектура CDN
CDN построен по классической схеме и направлен на то, чтобы отдавать пользователю тяжёлый контент как можно ближе к нему:
- Серверы Originхранят видео и подключаются исключительно к внутренней сети.
- CDN первого уровняхранит холодный контент, подключается и к внутренней сети, и к внешним интернет-провайдерам.
- CDN второго уровняхранит горячий контент, подключается исключительно к сети Интернет и раздаёт горячий контент пользователям как можно ближе к ним.
Маркировка контента устроена так. Оригиналы лежат на Origin. Если видео набирает более 4 просмотров, оно помечается как холодное, и его начинает кэшировать CDN первого уровня. Если видео набирает более 100 просмотров в час или более 10 000 просмотров в сутки, оно помечается как горячее, и его начинает кэшировать CDN второго уровня.
Финал
MikroTik — топ за свои деньги, если уметь его готовить. В этом убедились на собственном опыте: возможности заменить оборудование на тот момент не было, поэтому его пришлось настолько оптимизировать, чтобы оно хорошо работало, — и это оказалось возможным. Старые подходы не работают для новой инфраструктуры. Если строится инфраструктура под микросервисы, облака и т. п., сети ЦОД работают иначе. Появилось много новых технологий, направленных на оптимизацию таких сервисов. Не стоит бояться консалтинга и аутсорсинговых подрядчиков. К консалтингу обращались и при оптимизации MikroTik, и при строительстве сетей ЦОД. Это экономит деньги на оборудовании и даёт оптимально построенную сеть. По возможности стоит тестировать в лаборатории. После 2022 года с этим стало сложнее, но выходы есть — например, что-то на определённых условиях могут предоставить интеграторы.
В Москве:
РФ (звонок бесплатный):
Наша почта:
GetNet
Остались вопросы?
Группа компаний VoxLink © 2011-2026