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

В этой статье на примере эволюции сети 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.

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

Перенастройка legacy-сети

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

• Подняли и настроили на всех устройствах TACACS для централизованного контроля доступа, убрав локальную авторизацию.

• RANCID для сохранения конфигурации и ведения версионности.

• RSYSLOG — для аудита действий на устройствах.

• Отдельный ZABBIX 7 для мониторинга всего парка сетевых устройств.

Оптимизация настроек MikroTik 

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

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

1. обратились за аудитом, консультацией и обучением инженеров к внешним экспертам из компании, которая более 10 лет занимается внедрением проектов на оборудовании MikroTik;

2. перенастроили все firewall-правила на MikroTik;

3. закрыли везде доступы, повесили ACL — потому что до этого внутри сети был полный доступ;

4. перевели все стыки с интернет-провайдерами со статики на BGP;

5. проапгрейдили 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, и дело стало совсем плохо. 

Мы приняли решение обновиться до 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.

Как же работает 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:

1. Кардинальное улучшение производительности сети — устранение «тромбонного» эффекта. В традиционной архитектуре трафик между разными VLAN должен проходить через централизованный шлюз, создавая неоптимальные пути. С распределенным шлюзом каждый Leaf-коммутатор выполняет межсетевую маршрутизацию локально, направляя трафик по кратчайшему пути.

2. Максимальное использование пропускной способности. Поскольку маршрутизация происходит на каждом Leaf-коммутаторе, нагрузка равномерно распределяется по всей фабрике, а не концентрируется на одном устройстве.

3. Беспрецедентная отказоустойчивость и отсутствие единой точки отказа. Если один Leaf-коммутатор выйдет из строя, это повлияет только на устройства, непосредственно к нему подключенные. Все остальные хосты продолжают использовать свои локальные шлюзы без какого-либо влияния на производительность или доступность.

4. Мгновенное переключение при отказах. При миграции виртуальной машины с одного сервера на другой — подключенный к другому Leaf- коммутатору — IP и MAC-адрес шлюза остаются неизменными. Виртуальная машина даже не подозревает о том, что теперь использует другой физический шлюз.

5. Упрощение управления и конфигурации, единообразная настройка. Все Leaf-коммутаторы настраиваются абсолютно одинаково в части конфигурации шлюзов. Это значительно упрощает развертывание, обслуживание и устранение неисправностей в больших сетях дата-центров.

6. Автоматическая синхронизация — коммутаторы автоматически синхронизирует информацию о MAC и IP-адресах хостов между всеми коммутаторами через BGP EVPN.

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

8. Операционные преимущества, масштабируемость. Добавление новых Leaf-коммутаторов не создает дополнительной нагрузки на существующие шлюзы, поскольку каждый новый коммутатор становится независимым шлюзом для своих хостов.

9. Упрощенное планирование ресурсов. Не нужно беспокоиться о том, что централизованный шлюз станет узким местом при росте трафика — каждый 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. При строительстве сетей в ЦОДах мы тоже консультировались с подрядчиками и в результате смогли быстро,оптимальным образом построить сеть и сэкономить на оборудовании.

Подписывайтесь на этот блог и канал Смотри за IT, если хотите знать больше о создании медиасервисов. Там рассказываем об инженерных тонкостях, продуктовых находках и полезных мероприятиях, делимся видео выступлений и кадрами из жизни команд Цифровых активов «Газпром-Медиа Холдинга» таких, как RUTUBE, PREMIER, Yappy.