Российское сердце всея телеком: как мы тестируем компоненты для импортозамещения ядра мобильной сети
На ЦИПР-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 и его элементов на реальных мобильных сетях, правда, в основном за рубежом. Ниже представлена актуальная на момент разработки проекта схема распределения трафика.
Control plane
User plane
Таким образом, на этапе моделирования мы получили количество абонентов, объём трафика, количество вызываемых событий. Также у нас были сценарии, которые будут применяться в сессии абонента в целом и при сочетании определённых условий, инициированные его регистрацией в определённых сетях и территориях (в данной статье они не приводятся).
Архитектура ядра
Структура решения состоит из нескольких слоев (уровней).
Лабораторное окружение
Чтобы собрать подходящий тестовый стенд, мы объединили ресурсы собственной лаборатории РТК-Сервис с лабораторией НТЦ ПРОТЕЙ через IPSec-туннель. Это позволило нам провести функциональное тестирование схемы мобильного ядра в полноценном окружении всех узлов передачи данных (см. Рисунок 1).
Рисунок 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-ноды.
Схема использование numa-node
Подключение ВМ к менеджменту, а также к сервисным сетям при условии отсутствия большой трафиковой нагрузки происходит при помощи бриджа через хост машину 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 сегмент на части и упростить диагностику в случае возникновения проблемных ситуаций.
Логическая схема EPC
Несмотря на наличие схемы active–standby на стороне PGW (когда есть второй PGW, готовый принять сессии первого), мы получили от заказчика пожелание отказаться от нее и использовать все узлы в качестве active.
Детектирование аварий в этом случае происходит специфическим способом – путём проверки доступности шлюза. И поэтому модель резервирования, используемая НТЦ ПРОТЕЙ, претерпела изменения.
Подключение PGW и VRF GN
Для подключения PGW необходимо использование 4 портов сервера. Сервис PGW непосредственно использует 2 порта объединённых в LACP, для пропуска трафика с использованием DPDK фреймворка. Разделение интерфейсов Gn и Gi производится с помощью vlan.
Следующие 2 порта используются операционной системой для обеспечения функционирования прочих IP сервисов, работающих в обход DPDK (например, обмена данными между PCEF и PGW с использованием radius), а также для непосредственного менеджмента операционной системы Linux.
Подключение PGW к VRF Gn.
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.
PGW/PCEF VRF-Gi
В текущей реализации, 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 носят сигнальный характер.
Схема VRF Gx
Резервирование
В нашем решении используется георезервирование по схеме 1+1. Каждая из площадок способна взять на себя полную нагрузку и обеспечить полноценное функционирование сервисов.
Как мы уже говорили выше, использование механизмов active/standby не предусмотрено. По умолчанию, все узлы на обеих площадках работают в режиме горячего резерва. А это значит, что при единичном отказе любого из узлов, нагрузка распределяется между оставшимися в сервисе узлами, не вызывая «перекос» нагрузки на разных площадках.
В случае отказа PCEF, проблема детектируется PGW с помощью трекера. Трекер выполняет проверку доступности «внешнего ресурса», находящегося за PCEF.
В случае недоступности PCEF, PGW, который подключен к этому PCEF, не создает новые сессии и отвечает соответствующим cause code-сообщением в сторону SGW. SGW таким образом понимает о проблеме и направляет сессии абонентов на другой доступный PGW. См. Рисунок 9.
Рисунок 9. Отказ PCEF.
В случае отказа PGW сессию установить не получится, и на основе DNS записи APN будет произведён выбор другого узла PGW.
Рисунок 10. Отказ PGW
Если PGW обнаруживает отказ PCEF, он начинает процедуру offload для тех абонентов, сессии которых находятся на нём. И после поднятия сессии абоненты окажутся в зоне действия уже другого PGW с другим PCEF, а значит, они продолжат получать сервис.
Вспомогательные системы
Также в ходе проекта мы параллельно протестировали и использовали решения от компании ООО «РДП.РУ», тоже российский производитель:
CG-NAT RDP EcoNAT 4160L, который обеспечивал выход наших тестовых карт в Internet.
(из пушки по воробьям, но очень хотелось…)
Трафик-брокер EcoNPB 1032 для управления трафиком, фильтрации и направления трафика на СОРМ, системы мониторинга и т.д. (иногда просто интересно посмотреть, что на сниффер прилетит – интрига же…)
Заключение
После всех доработок, настроек и интеграций совместными усилиями всех участников процесса нам удалось привести в соответствие EPC НТЦ ПРОТЕЙ ожиданиям заказчика. Это очень хороший результат, учитывая, что все российские операторы связи находятся сегодня в ожидании альтернативы западным решениям. А на базе текущего 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 и его элементов на реальных мобильных сетях, правда, в основном за рубежом. Ниже представлена актуальная на момент разработки проекта схема распределения трафика.
Control plane
User plane
Таким образом, на этапе моделирования мы получили количество абонентов, объём трафика, количество вызываемых событий. Также у нас были сценарии, которые будут применяться в сессии абонента в целом и при сочетании определённых условий, инициированные его регистрацией в определённых сетях и территориях (в данной статье они не приводятся).
Архитектура ядра
Структура решения состоит из нескольких слоев (уровней).
Лабораторное окружение
Чтобы собрать подходящий тестовый стенд, мы объединили ресурсы собственной лаборатории РТК-Сервис с лабораторией НТЦ ПРОТЕЙ через IPSec-туннель. Это позволило нам провести функциональное тестирование схемы мобильного ядра в полноценном окружении всех узлов передачи данных (см. Рисунок 1).
Рисунок 1.
У нас в лаборатории на тот момент не было развёрнуто работоспособных узлов MME SGW HSS, мы распределили «железо» между площадками. На нашей стороне располагались все необходимы по проекту узлы (которые будут установлены заказчику). В лаборатории НТЦ ПРОТЕЙ находились остальные узлы, которые не относились к исследуемым характеристикам ядра MVNO (условно: остальная часть большого оператора).
Сервера
На основании уже имеющихся данных, а также некоторых нагрузочных тестов EPC ПРОТЕЙ, были сформулированы требования к конфигурации серверов, под три сервиса (PGW, PCEF, PCRF).
Вычислительный сервер GAGAR>N Оракул GEN2 тип Server 1
| Серверная платформа | GAGAR>N Оракул Gen2.0 |
| Процессоры | 2xIntel Xeon Gold 6342 (24 cores, 2.8/3.5 Ghz, 36 MB Cache, 230W TDP) |
| ОЗУ | 16x64GB 3200MHz DDR4 RDIMM ECC |
| RAID | 1xRAID SAS 9440-8i RAID 0,1,5,10,50 |
| Диски |
2xSSD SATA 2,5" 480GB
2xSSD SAS 2,5" 1,92TB - 12 GB/s |
| Сетевые адаптеры |
1x1 Gbps PCIe gen2 2 порта RJ45
2x25Gbps PCIe gen3/gen4 2 порта SFP28 (Intel E810) |
| Оптический трансивер | 4x25GE-SFP28 Optical Transceiver SR |
Вычислительный сервер 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-ноды.
Схема использование numa-node
Подключение ВМ к менеджменту, а также к сервисным сетям при условии отсутствия большой трафиковой нагрузки происходит при помощи бриджа через хост машину 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 сегмент на части и упростить диагностику в случае возникновения проблемных ситуаций.
Логическая схема EPC
Несмотря на наличие схемы active–standby на стороне PGW (когда есть второй PGW, готовый принять сессии первого), мы получили от заказчика пожелание отказаться от нее и использовать все узлы в качестве active.
Детектирование аварий в этом случае происходит специфическим способом – путём проверки доступности шлюза. И поэтому модель резервирования, используемая НТЦ ПРОТЕЙ, претерпела изменения.
Подключение PGW и VRF GN
Для подключения PGW необходимо использование 4 портов сервера. Сервис PGW непосредственно использует 2 порта объединённых в LACP, для пропуска трафика с использованием DPDK фреймворка. Разделение интерфейсов Gn и Gi производится с помощью vlan.
Следующие 2 порта используются операционной системой для обеспечения функционирования прочих IP сервисов, работающих в обход DPDK (например, обмена данными между PCEF и PGW с использованием radius), а также для непосредственного менеджмента операционной системы Linux.
Подключение PGW к VRF Gn.
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.
PGW/PCEF VRF-Gi
В текущей реализации, 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 носят сигнальный характер.
Схема VRF Gx
Резервирование
В нашем решении используется георезервирование по схеме 1+1. Каждая из площадок способна взять на себя полную нагрузку и обеспечить полноценное функционирование сервисов.
Как мы уже говорили выше, использование механизмов active/standby не предусмотрено. По умолчанию, все узлы на обеих площадках работают в режиме горячего резерва. А это значит, что при единичном отказе любого из узлов, нагрузка распределяется между оставшимися в сервисе узлами, не вызывая «перекос» нагрузки на разных площадках.
В случае отказа PCEF, проблема детектируется PGW с помощью трекера. Трекер выполняет проверку доступности «внешнего ресурса», находящегося за PCEF.
В случае недоступности PCEF, PGW, который подключен к этому PCEF, не создает новые сессии и отвечает соответствующим cause code-сообщением в сторону SGW. SGW таким образом понимает о проблеме и направляет сессии абонентов на другой доступный PGW. См. Рисунок 9.
Рисунок 9. Отказ PCEF.
В случае отказа PGW сессию установить не получится, и на основе DNS записи APN будет произведён выбор другого узла PGW.
Рисунок 10. Отказ PGW
Если PGW обнаруживает отказ PCEF, он начинает процедуру offload для тех абонентов, сессии которых находятся на нём. И после поднятия сессии абоненты окажутся в зоне действия уже другого PGW с другим PCEF, а значит, они продолжат получать сервис.
Вспомогательные системы
Также в ходе проекта мы параллельно протестировали и использовали решения от компании ООО «РДП.РУ», тоже российский производитель:
CG-NAT RDP EcoNAT 4160L, который обеспечивал выход наших тестовых карт в Internet.
(из пушки по воробьям, но очень хотелось…)
Трафик-брокер EcoNPB 1032 для управления трафиком, фильтрации и направления трафика на СОРМ, системы мониторинга и т.д. (иногда просто интересно посмотреть, что на сниффер прилетит – интрига же…)
Заключение
После всех доработок, настроек и интеграций совместными усилиями всех участников процесса нам удалось привести в соответствие EPC НТЦ ПРОТЕЙ ожиданиям заказчика. Это очень хороший результат, учитывая, что все российские операторы связи находятся сегодня в ожидании альтернативы западным решениям. А на базе текущего EPC нам удалось создать 100% независимую от импорта конфигурацию ядра мобильной сети.
Следует оговориться, что НТЦ ПРОТЕЙ имеет несколько реализаций своего пакетного ядра, и на момент поступления задачи последняя на сегодняшний день реализация с использованием новой архитектуры еще не была доступна и находилась в разработке. Таким образом, все действия и расчёты произведены на текущий в тот момент времени релиз продукта, а значит, в перспективе качество работы мобильного ядра может быть еще лучше.
К списку новостей