Привет, Хабр! Хотим поделиться интересной историей, которая требует не только приложения имеющихся навыков, но и переосмысления методик. Чем мы в РТК-Сервис часто занимаемся.
На ЦИПРе-2025 мы презентовали публике новое ядро мобильной сети EPC от НТЦ ПРОТЕЙ. Оно на 100% построено из отечественных компонентов. И, разумеется, у всех возникли вопросы, можем ли мы гарантировать, что это самое ядро будет достаточно производительным для того, чтобы взять на себя актуальные нагрузки мобильных сетей. В этой статье я, системный архитектор РТК-Сервис Куликовский Даниил, и мои коллеги Пермяков Константин и Талыпов Динар, расскажем, как мы тестировали разработку и какие доработки пришлось сделать, чтобы решение устраивало потенциальных заказчиков из «большой четверки».
В лабораторию РТК-Сервис на тестирование приходит большое количество различного отечественного оборудования. За последний год здесь воссоздали более 600 уникальных мультисервисных топологий, имитирующих сети крупнейших российских провайдеров, включая модернизацию и расширение сетей передачи данных, IP-фабрики и другие. Инженеры протестировали оборудование более чем 20 вендоров – от Т8, «РДП Инновации» и «Элтекса» до «ИнфоТеКС» и «Кода безопасности», всего более 400 устройств: от компактных коммутаторов до магистральных маршрутизаторов.
Для большинства решений мы прорабатываем вопросы интеграции и доработки вместе с вендорами, чтобы обеспечить миграцию с иностранного оборудования и сервисов в соответствии с требованиями:
1) техническими, со стороны заказчиков;
2) к критической информационной инфраструктуре, к которой относится ПО для тел��ком-оборудования.
Как раз одной из таких задач стала замена сердца сетей сотовой связи – пакетного ядра.
Что мы должны проверять?
Для реализации любого проекта требуется понимание того, что же необходимо получить на выходе. Мало просто протестировать какие-то синтетические параметры, необходимо смоделировать работу оборудования на реальной сети и проверить его на предмет соответствия критически важным критериям и условиям (а лучше – вообще всем пожеланиям заказчика).
Параметры тестирования и точки отсчёта в нашем случае задаёт модель трафика. В сочетании с техническим заданием, в котором учитываются текущая и будущая нагрузка, а также расчётом ее роста за счёт привлечения новых абонентов или роста потребностей существующих.
Мы учитывали текущую трафик-модель обслуживания абонентов «Ростелекома» для моделирования реалистичной загрузки оборудования и понимания, сколько забирает ресурсов та или иная процедура.
Из-за особенностей работы мобильных сетей трафик-модель оказывает прямое воздействие на показатели и требования к вычислительным мощностям сразу ряда сетевых элементов. Мы рассматривали конкретную задачу телеком-оператора. Поэтому в сферу интересов тестирования попали такие узлы как PGW, PCEF, PCRF.
PGW – это узел, который предоставляет точку входа абонента в IP-сеть. Именно PGW обеспечивает возможность работы в интернете, а также обращение к другим IP-сервисам для мобильного абонента.
PCEF – узел, обеспечивающий применение политик тарификации и правил обслуживания абонентов. Другими словами, это узел, который позволяет контролировать входящий и исходящий трафик каждого абонента в сети. Применяя к трафику абонента те или иные правила в зависимости от его тарифного плана и опций.
PCRF – узел обеспечивает хранение, управление и применение этих политик и правил. Именно этот узел сообщает PCEF, какие правила необходимо применить к тому или иному абоненту.
Каким должно быть ядро сети?
Итак, мы получили от ПАО «Ростелеком» запрос на проверку, будет ли ядро, созданное на базе ПО от НТЦ ПРОТЕЙ, соответствовать параметрам сети оператора:
· Способность пропуска трафика – 64 Gbps
· Активные биреры (Bearers) – 916 632
· Количество абонентов – 858 832
Модель трафика
С формированием модели трафика нам помогли коллеги из НТЦ ПРОТЕЙ, так как у них уже был опыт внедрения ядра сети 4G и его элементов на реальных мобильных сетях, правда, в основном за рубежом. Ниже представлена актуальная на момент разработки проекта схема распределения трафика.
Таким образом, на этапе моделирования мы получили количество абонентов, объём трафика, количество вызываемых событий. Также у нас были сценарии, которые будут применяться в с��ссии абонента в целом и при сочетании определённых условий, инициированные его регистрацией в определённых сетях и территориях (в данной статье они не приводятся).
Архитектура ядра
Структура решения состоит из нескольких слоев (уровней):
Лабораторное окружение
Чтобы собрать подходящий тестовый стенд, мы объединили ресурсы собственной лаборатории РТК-Сервис с лабораторией НТЦ ПРОТЕЙ через IPSec-туннель. Это позволило нам провести функциональное тестирование схемы мобильного ядра в полноценном окружении всех узлов передачи данных. См. Рисунок 1.
У нас в лаборатории на тот момент не было развёрнуто работоспособных узлов MME SGW HSS, мы распределили «железо» между площадками. На нашей стороне располагались все необходимы по проекту узлы (которые будут установлены заказчику). В лаборатории НТЦ ПРОТЕЙ находились остальные узлы, которые не относились к исследуемым характеристикам ядра MVNO (условно: остальная часть большого оператора).
Сервера
На основании уже имеющихся данных, а также некоторых нагрузочных тестов EPC ПРОТЕЙ, были сформулированы требования к конфигурации серверов, под три сервиса (PGW, PCEF, PCRF).
Вычислительный сервер GAGAR>N Оракул GEN2 тип Server 1
Вычислительный сервер GAGAR>N Оракул GEN2 тип Server 2
Вычислительный сервер GAGAR>N Оракул GEN2 тип Server 3
Этого было достаточно для проверки работы платформы. Разумеется, итоговая инсталляция у заказчика не будет ограничиваться 3 серверами, их количество можно наращивать в зависимости от требуемой производительности и условий резервирования, тем более что платформа GAGAR>N хорошо справляется с задачами масштабирования.
Будет ли работать?
Первым этапом стала проверка возможности установки программного обеспечения ПРОТЕЙ на сервера GAGAR>N.
А в дополнение, так как у нас в лаборатории были сетевые карты Mellanox ConnectX-5 (такие же, как на серверах заказчика), мы также рассмотрели возможность их использования.
И вот тут-то обнаружились нюансы. Если PGW после перенастройки прекрасно запускался и работал с Mellanox, то PCEF хоть и запускался, но не работал корректно и не пропускал трафик. Проблему впоследствии конечно же решили, за счет того, что НТЦ ПРОТЕЙ оперативно выпустил патч на PCEF.
В контексте работы PCRF никаких нюансов быть не могло, т.е. он работает полностью в качестве сервиса Linux, без каких-либо фреймворков и собственных драйверов.
Платформа виртуализации
В качестве платформы виртуализации было использовано решение KVM/Libvirt, а также механизмы Terraform (VNF onboarding) и Ansible для автоматизации конфигурирования.
Архитектура виртуализации
В качестве хоста был взят типовой Linux с гипервизором KVM. В качестве гостевой системы мы развернули Ubuntu 22.05 LTS (PGW/PCEF) и Oracle Linux 9.4 (PCRF).
Для обеспечения высокой производительности ВМ (Виртуальной Машины), выполняющей обработку трафика, осуществляется проброс сетевых карт внутрь гостевой операционной системы. Это обеспечивает прямой доступ к аппаратным ресурсам сетевой карты и позволяет использовать в работе фреймворк DPDK без потери производительности, вызванной пропуском трафика через внутренние механизмы сетевого стека гипервизора и хоста. Для этого на хосте и физическом сервере предварительно включается поддержка режима iommu.
Чтобы производительность была стабильной, мы перевели часть процессорных ядер на хосте в режим isolated. Это нужно, чтобы избежать переноса нагрузки хост-системой на данные ядра. Также производится биндинг виртуальной машины к изолированным ядрам из расчёта 1 поток на одно физическое ядро CPU.
А чтобы эффективно использовать внутренние шины сервера, машины, выполняющие обработку трафика, должны располагаться в рамках одной numa-ноды.
Подключение ВМ к менеджменту, а также к сервисным сетям при условии отсутствия большой трафиковой нагрузки происходит при помощи бриджа через хост машину KVM. При этом привязка машин, не обслуживающих трафик к numa-node, не предусматривается.
Сетевое железо
В качестве основы для сетевой инфраструктуры были выбраны решения «Бифорком Тек». Эти системы прошли серию тестов и справились с ними лучше, чем «альтер эго» производителя (ну, вы понимаете, о чем я).
Предлагаемое решение - 400G Ready.
В качестве Spine устройств используются высокопроизводительные коммутаторы ISW-7100, которые могут работать на скоростях 400G/100G.
На роль Leaf устройств выбраны традиционные коммутаторы CS4132 и CS4148 для подключения серверов, LBs, FWs на скоростях от 10G до 100G.
На роль DC-GW/Border Leaf для сопряжения с внешним сегментом был выбран высокопроизводительный 400G маршрутизатор MR570. Это устройство может обеспечивать стыковку VXLAN фабрик с внешними доменами, включая MPLS сети. Имея высокую емкость (до 10 млн маршрутов IPv4/IPv6), FIB может использоваться в высоконагруженных схемах, выполняя роль универсального шлюза.
Подключение серверов выполнялось к Leaf коммутаторам.
Для малых и крупных инсталляций решения использовались разные схемы сетевого оборудования:
Схема 1. Для малых инсталляций, при наличии достаточной портовой ёмкости подключение возможно производить непосредственно в DC-GW – эта схема использовалась в лаборатории.
Схема 2. Для крупных инсталляций, где портовой емкости DС-GW недостаточно. Полноценная схема IP-фабрики использовалась для функционального и нагрузочного тестирования, но это уже другая история (и статья).
В рамках тестирования vEPC решения НТЦ ПРОТЕЙ и других производителей, мы использовали стандартный стек протоколов EVPN/VXLAN, со всеми их плюсами. Например, ESI, позволяющий резервировать подключение на паре коммутаторов. Из интересных особенностей, мы запустили фабрику с применением фичи BGP Unnumbered, упрощающую первичную настройку коммутаторов и избавляющую от необходимости навешивать на каждый из интерфейсов по IPv4 p2p сетки. Общая схема подключения – это коммутаторы уровня Spine, которые находятся в общей автономной системе, Leaf коммутаторы находятся каждый в своей AS. Такая конфигурация избавляет от необходимости поднимать route-reflector на спайнах и поднятие IGP. Балансировка сети ЦОДа тоже имеет свои особенности, так как трафик внутри ходит инкапсулированный в VXLAN, поэтому мы используем rtag7 hash, дабы обойти данное ограничение. И, конечно же, балансировка на паре лифов имеет Active-Active, поэтому мы не просто резервируем подключение, а полноценно используем все линки. Однако, в нашу модель здоровья мы закладываем мониторинг таких линков, чтобы загрузка не превышала 50%, и при обрыве одного линков или выхода из строя коммутатора можно было сохранять сервис без перегрузки.
Для тех инсталляций, где не требуется наличие целой фабрики и позволяет портовая емкость, мы использовали стандартные механизмы MC-LAG. Из минусов такого подхода, это, конечно же, использование дополнительного линка для синхронизации состояния шасси, контроль от split-brain. Но, для маленьких площадок подходит хорошо. В таких инсталляциях используются производительные IP/MPLS маршрутизаторы, которые сразу включены в сеть заказчика, минуя промежуточные узлы. Но, в целом, никто не мешает подключить к паре маршрутизаторов коммутатор для увеличения портовой емкости. Однако, при данном подходе, мы теряем в резервировании в сторону серверов.
Из плюсов работы с российскими производителями – любые проблемы решаются достаточно быстро. Плюс, достаточно вменяемая дорожная карта, которую можно обсудить непосредственно с вендором, а не с представительством тут, и, далеко не факт, что это пойдет дальше условного менеджера в России.
DC gateway в свою очередь подключаются к PE маршрутизаторам «Ростелекома». Также на стороне оператора работает функционал CGNAT.
Подключение EPC
Из-за особенностей элементов PGW и PCEF, подключение данных инстансов происходит различными методами. Все сервера имеют подключение к ОАМ одним портом управления шасси (BMC). Остальные порты используются для реализации функциональных возможностей сервера в зависимости от установленного программного обеспечения и исполняемой роли.
Здесь следует отметить, что PCEF и CGNAT являются устройствами второго уровня, хоть и манипулируют трафиком на более высоких уровнях. Именно это вызывает появление такого vrf, как Gi-out. Его цель – разбить L2 сегмент на части и упростить диагностику в случае возникновения проблемных ситуаций.
Несмотря на наличие схемы active–standby на стороне PGW (когда есть второй PGW, готовый принять сессии первого), мы получили от заказчика пожелание отказаться от нее и использовать все узлы в качестве active.
Детектирование аварий в этом случае происходит специфическим способом – путём проверки доступности шлюза. И поэтому модель резервирования, используемая НТЦ ПРОТЕЙ, претерпела изменения.
Подключение PGW и VRF GN
Для подключения PGW необходимо использование 4 портов сервера. Сервис PGW непосредственно использует 2 порта объединённых в LACP, для пропуска трафика с использованием DPDK фреймворка. Разделение интерфейсов Gn и Gi производится с помощью vlan.
Следующие 2 порта используются операционной системой для обеспечения функционирования прочих IP сервисов, работающих в обход DPDK (например, обмена данными между PCEF и PGW с использованием radius), а также для непосредственного менеджмента операционной системы Linux.
VRF Gi и подключение PCEF и PGW
Для PGW предполагается использование протокола динамической маршрутизации BGP (с option A для сопряжения с сетевым оборудованием). Для этого на маршрутизаторах DCGW создаются в VRF Gi_in соседства с PGW, в рамках которого передаются подсети пулов и статических адресов. Далее данный префикс передается через VNF PCEF в VRF Gi_out.
Для уменьшения времени сходимости и детектирования возможных проблем сетевой связанности используется BFD (Bidirectional Forwarding Detection) — протокол, работающий на уровне интерфейса и протокола маршрутизации и предназначенный для быстрого обнаружения сбоев между двумя соседними маршрутизаторами, включая интерфейсы, каналы передачи данных и механизмы пересылки. При этом BFD не используется на интерфейсах при подключении к Vrf Gn.
В текущей реализации, PCEF выступает в качестве L2-петли между двумя VRF. Резервирование происходит посредством подключения к сетевому оборудованию через два независимых LAG. Однако, несмотря на наличие BGP opt A, PGW игнорирует входящие маршруты, поступающие по протоколу динамической маршрутизации. И выход трафика наружу осуществляется через статический маршрут, указанный в настройках APN.
Интересно, что из-за особенностей функционирования PCEF, требуемое количество портов для подключения узла составляет 6 единиц.
Узел PCEF является прозрачным на втором уровне (L2), и это осложняет процесс его включения по схеме on-stick. По этой причине в нашей конфигурации используется механизм, при котором трафик поступает в один порт, а выходит через другой. Таким образом, с учётом резервирования функционала DPDK используют сразу 6 портов: 4 для функционала непосредственно DPI и ещё 2 для менеджмента и прочего функционала, не использующего порты DPDK.
VRF Gx и подключение PGW, PCEF, PCRF
VRF Gx является местом обмена информацией о чаржинге и аутентификации абонентов. Он обеспечивает прохождение Gx, Gy, и Radius-обмена между узлами.
Компоненты EPC подключаются к данному VRF путем использования бриджа на хост-машине. Это обеспечивает связанность гостевых машин с сетевой инфраструктурой.
Данное решение было выбрано, потому что продукты НТЦ ПРОТЕЙ не используют для этих подключений DPDK-фреймворк, а трафиковая нагрузка в этом профиле не будет основополагающей, т.к. все сообщения в данном VRF носят сигнальный характер.