В прошлой статье мы рассказали, что умеет GTPCProxy, а теперь заглянем внутрь и разберем устройство решения и результаты замеров.
Многопоточное ядро без общих структур
Главная идея в том, что рабочие потоки прокси не мешают друг другу. Все сессии GTPCProxy разделены на 1024 раздела. Каждый раздел закреплен за одним рабочим потоком, а один поток обслуживает много разделов.
Изменяемых структур, общих для нескольких потоков, нет. Поэтому рабочим потокам не нужно согласовывать доступ к данным, и каждый новый поток добавляет производительность почти без потерь. Замеры это подтверждают: при нагрузке 50% от предельной за минуту не зафиксировано ни одной блокировки рабочих потоков.
Ответы шлюзов PGW и проверочные сообщения Echo, по которым прокси понимает, что шлюз жив, идут через отдельную очередь, а не вместе с новыми запросами. Поэтому даже в пик нагрузки ответы обрабатываются без задержки, а проверки укладываются в отведенное время. Прокси не примет исправный шлюз за отказавший только потому, что сам был занят.
Если прокси все-таки перегружен, он обслуживает сообщения по важности. Сначала идут сообщения по уже работающим сессиям, затем запросы на новые подключения. Так абоненты, которые уже в сети, не страдают от наплыва новых.
Вертикальное масштабирование: результаты замеров
Прокси записывает состояние каждой сессии в Redis — быструю базу данных, которая хранит все в оперативной памяти. Это может быть один сервер Redis или кластер, в котором у каждого узла есть резервная копия (реплика).
У каждого рабочего потока свой канал записи в хранилище и свой ведущий узел Redis с репликой.
В этой схеме мы измерили, сколько запросов Modify Bearer прокси пропускает постоянно и без ошибок. (Modify Bearer — это запрос на изменение параметров уже существующей сессии абонента):
| Рабочих потоков | Modify Bearer в секунду | Рост к предыдущей строке |
| 1 | 87 812 | — |
| 2 | 180 625 | в 2,06 раза |
| 4 | 348 203 | в 1,93 раза |
При переходе с одного потока на два емкость выросла в 2,06 раза, с двух на четыре — в 1,93 раза. Четыре потока обрабатывают 348 203 запроса в секунду. Это на 0,9% меньше, чем четыре емкости одного потока (351 248).
Задержку измеряли на четырех потоках при нагрузке 90% от предельной в течение 30 минут. Результаты:
- p50 — 0,10 мс,
- p99 — 0,33 мс,
- p99,9 — 0,56 мс.
За 30 минут прокси обработал 563 776 014 транзакций без ошибок и потерь. Память процесса за это время выросла на 7,9 МБ.
Для небольших сетей достаточно одиночного Redis. Но одиночный Redis ограничивает емкость. Прокси прокси обрабатывает около 105 000 запросов Modify Bearer в секунду, и добавление рабочих потоков это число не увеличивает.
Если кластеру Redis выделить столько же процессорных ядер, сколько одиночному серверу, емкость прокси снизится примерно на 21–22%. Если же выделить каждому основному узлу кластера отдельное ядро, производительность растет вместе с числом рабочих потоков прокси.
Горизонтальное масштабирование и резервирование через BGP
Чтобы прокси не стал единой точкой отказа, его экземпляры объединяют в группы. У каждой группы есть свой IP-адрес (/32), который экземпляры сообщают по BGP, что этот адрес доступен через них. Активный экземпляр объявляет адрес с лучшим маршрутом, резервный — с худшим, поэтому трафик идет на активный.
Рисунок — Соседние узлы всегда обращаются к одному адресу группы. Какой экземпляр сейчас отвечает, решает BGP, а сессии оба берут из одного Redis.
Отказ прокси или сервера
За процессом прокси следит отдельная программа — сторож BGP. Она проверяет процесс раз в секунду. Если экземпляр неисправен дольше 10 секунд, сторож перестает объявлять его адрес, и трафик уходит на резервный экземпляр. Вернуться в работу экземпляр сможет только после 30 секунд стабильной работы. Так нестабильный экземпляр не будет то пропадать, то появляться снова.
Если отказал весь сервер или его сетевое подключение, срабатывает механизм BFD. Он замечает обрыв за 900 мс, после трех пропущенных проверок с интервалом 300 мс. После этого адрес переходит к резервному экземпляру.
Почему сессии не теряются
Получив сообщение по сессии, резервный экземпляр читает состояние этой сессии в Redis по идентификатору туннеля (TEID).
Соседние узлы переключения тоже не замечают. Каждый узел сообщает соседям свой счетчик перезапусков (Recovery). Если счетчик изменился, сосед решает, что узел перезагрузился, и удаляет связанные с ним сессии. Значение Recovery у всех экземпляров группы одинаковое, поэтому SGW и PGW не принимают переключение за перезапуск и сессии сохраняются.
Отказ Redis
При отказе ведущего узла Redis его функции переходят к реплике.В серии испытаний при нагрузке 6 020 запросов на создание подключения в секунду переключение занимало не больше 2,03 с.
Перезапуск прокси
Перезапуск прокси подключения не обрывает. Сам процесс запускается примерно за 0,135 с (медиана), а затем читает состояние сессий из Redis. Зависший рабочий поток перезапускается сторожевым таймером потока — это отдельный механизм, не связанный со сторожем BGP. При плановой остановке прокси сначала отвечает на открытые транзакции.
Как нарастить емкость
Чтобы обслуживать больше абонентов, добавляют новые группы прокси. Их адреса прописывают в DNS для нужных точек доступа (APN). Все группы работают с одним кластером Redis.
| Событие | Как обнаруживается | Время |
| Сбой процесса прокси | Сторож BGP, проверка раз в секунду | Адрес снимается через 10 с |
| Отказ сервера или сети | BFD, интервал 300 мс, 3 пропуска | 900 мс |
| Возврат экземпляра в работу | Сторож BGP | После 30 с стабильной работы |
| Отказ основного узла Redis | Переход на реплику | До 2,03 с |
| Запуск процесса прокси | — | 0,135 с (медиана) |
VNF или CNF
Прокси поставляется в двух вариантах. Резервирование в них устроено одинаково, разница только в том, где и как прокси запускается. Первый вариант — виртуальная машина (VNF), второй — контейнеры в Kubernetes (CNF).
| Виртуальная машина (VNF) | Kubernetes (CNF) | |
|---|---|---|
| Платформа | VEOS 8 | Kubernetes |
| Из чего ставится | Два RPM-пакета | Образ, собранный из тех же RPM-пакетов, и Helm-чарт |
| Как запускается | Системная служба (systemd) | StatefulSet, два пода на группу |
| Кто объявляет адрес группы | FRR и сторож BGP | FRR внутри пода прокси |
| Ресурсы и настройки | — | Статическое закрепление процессорных ядер, конфигурация в ConfigMap и Secret |
Виртуальную машину обновляют командой dnf upgrade. Сначала обновляют резервный экземпляр, затем активный.
Мониторинг и управление
Метрики Prometheus охватывают сообщения, транзакции, отказы, состояние PGW и хранилища. Готовые панели Grafana встроены в веб-интерфейс прокси. Там же доступны сводные показатели, таблицы PGW и пулов, поиск сессии и ее карточка, в том числе с параметрами сетей 2G/3G (GTPv1).
Интерфейс работает быстро даже на большом числе сессий. При 100 000 сессий первая страница списка открывается за 6,9 мс, а поиск по номеру SIM-карты (IMSI) занимает 0,4 мс.
Настройки разделены на два уровня.
- Файл gtpcp.yaml отвечает за сам прокси. В нем задаются адреса, число потоков, привязка к процессорным ядрам и параметры хранилища.
- Документ маршрутизации отвечает за работу с абонентами. В нем задаются пулы шлюзов, правила выбора, веса, проверки состояния PGW и подмена параметров.
Документ маршрутизации можно менять без перезапуска прокси, через формы или в текстовом виде в веб-интерфейсе. Перед применением прокси проверяет новую версию. Если в ней ошибка, прокси продолжает работать по текущей. К прежней версии всегда можно вернуться. Права разделены между двумя ролями — администратором и наблюдателем.
Вывод
GTPCProxy наращивает производительность за счет новых процессорных ядер и новых групп прокси, а состояние сессий хранит отдельно, в Redis. Поэтому переключение на резервный экземпляр проходит незаметно для SGW и PGW, и делать им для этого ничего не нужно.
Проверить это на своих SGW, SGSN и PGW можно в лаборатории. VAS Experts передает пакет для испытаний с конфигурацией, сценариями и набором инструментов для сбора трасс. Свяжитесь с нами, чтобы спланировать проверку.
