Разделение управляющей и пользовательской плоскостей позволяет развести эти функции по разным узлам и масштабировать их независимо. Но само по себе разделение не делает сервис непрерывным — оно лишь создает архитектуру, в которой непрерывность можно обеспечить.
Для этого узел передачи данных должен стать заменяемым, а его замена — управляемой операцией без обрыва активных сессий.Такой архитектурный подход называется CUPS. Разберем, почему разделение плоскостей не гарантирует непрерывность сессий, в каких ситуациях она может нарушаться, как работает управляемый перевод сессии и где этот подход имеет свои границы.
Из чего состоит сервисный шлюз
В сервисном шлюзе идет разделение на три сущности: данные о состоянии абонента, логика обработки трафика и интерфейс, который их связывает.
Управляющая плоскость знает, кто абонент и что ему положено. Это слой, в котором изменения происходят нечасто, но они критически важны.
Пользовательская плоскость, напротив, получает только определенную информацию по сессии, но знает что происходит с пакетами. Она классифицирует трафик по принадлежности к сервису, применяет уже готовые правила и ведёт счетчики потребления по каждой услуге. Это высокопроизводительный слой, оптимизированный под пропускную способность, а не под хранение знаний.
Между ними остается узкий и явный интерфейс: управляющая плоскость отправляет команды вниз, а пользовательская возвращает отчеты о состоянии и потреблении.
Именно потому что интерфейс узкий, узел пользовательской плоскости становится заменяемым. Он не хранит ничего постоянного — только то, что можно восстановить командой сверху. Если этот узел упадёт, сгорит, его перезапустят или заменят на новый — управляющая плоскость просто пришлет те же команды заново, и всё восстановится.
Рисунок 1 — Сущности управляющей и пользовательской плоскости
Где может нарушиться непрерывность
Возможность независимо менять узлы — это еще не гарантия, что абонент не заметит замены. Узел передачи данных приходится выводить из строя не только при отказе, но и планово: при ремонтных работах или обновлении.
Разница между этими случаями принципиальна. Во время технических работ узел еще продолжает работать, есть время подготовить сначала замену и только потом отключить источник. При аварии такого нет. Узел перестает отвечать до того, как сеть успевает подготовить перенос сессий. Часть состояния теряется, и полностью исключить обрыв уже невозможно.
Отсюда простой, но ключевой подход: пока узел еще доступен, сессию нужно успеть перевести на новый, до того как старый отключат. Именно на этом правиле и строится управляемый перевод.
Управляемый перевод: сначала подключить, потом отключить
Этот принцип известен в других областях как «сначала соединить, потом разорвать». Новый узел сначала готовят к обслуживанию сессии, затем на него переводится трафик, и только после этого старый узел отключают. Здесь и проявляется смысл разделения плоскостей: управляющая плоскость полностью управляет переводом сессии, а узлы пользовательской плоскости только выполняют её команды.
Состояние абонента хранится в управляющей плоскости. Поэтому она может заново создать его на другом узле, передать профиль, правила и разрешенные сервисы. Новый узел не получает состояние напрямую от старого — узлы пользовательской плоскости не взаимодействуют между собой.
Важно, что сессию не «перекидывают» с одного узла на другой. Ее переводят как последовательную операцию по шагам и точкой невозврата. Пока последовательность не завершена, в системе всегда остается узел, готовый обслуживать сессию. Поэтому плановая замена не должна приводить к обрыву соединения.
Рисунок 2 — Схема управляемого перевода сессии
А что с тарификацией
Непрерывность передачи данных сама по себе еще не означает непрерывность учета. Абонент может не заметить переключение узла, но если в биллинге при этом возникнет расхождение, задача решена только наполовину. Поэтому при переводе нужно сохранить не только состояние обслуживания, но и информацию о потреблении.
Здесь используются отчеты двух узлов. Новый узел получает порог — объем трафика, который абоненту ещё разрешено потребить. Этот порог соответствует остатку известной квоты. Старый узел перед отключением передает управляющей плоскости итоговый отчет о фактически потребленном объеме. Управляющая плоскость складывает эти значения и устанавливает на новом узле уже абсолютный порог.
Важно, что объем не восстанавливается из самих порогов. Он берется из отчетов о фактическом потреблении. Это позволяет избежать двух проблем:
- потерю части потребленного объема;
- повторный учет одного и того же объема.
Отсюда еще одно следствие — активную тарификационную сессию не требуется закрывать только из-за перевода узла. Абонент продолжал пользоваться сервисом, потребленный объем известен точно. Значит, нет основания отправлять в биллинг сообщение об обрыве.
При 20 миллионах абонентов и пяти узлах передачи данных это становится особенно заметно. Если выводить один узел через принудительное закрытие сессий, в сторону биллинга могло бы уйти до 16 миллионов сообщений. При управляемом переводе таких сообщений не возникает.
Где непрерывность заканчивается
У любого механизма есть границы применимости. Архитектура должна не только показывать, что она умеет сохранять, но и честно обозначать, что сохранить невозможно.
Трансляция адресов NAT
Отметим, что User Plane PCEF обладает не только функцией DPI, но и обеспечивает NAT (CG-NAT, NAT64, NAT 1:1).
Трансляция адресов CG-NAT — это механизм, при котором устройство абонента получает один приватный IP адрес внутри сети оператора, а наружу выходит под другим, публичным. Это решает проблему нехватки адресов и повышает безопасность. Но соответствие между внутренним и внешним адресом хранится в памяти конкретного узла. Если сессию перевести на другой узел, публичный адрес и порт для уже установленных соединений изменятся. Для них это обрыв.
Поэтому такие соединения нельзя перевести бесшовно. Для них используется естественное прерывание текущих сессий и установка новых трафиковых сессий: плановый вывод узла предполагает перевод трафика с приватного адреса на другой Usr Plane с другим пулом публичных IP адресов.
Есть и другой подход — синхронизация соединений между NAT. В этом случае идет синхронизация таблицы NAT трансляций между несколькими узлами.. Но это уже отдельное архитектурное решение, которое влияет в том числе на план адресации. Поэтому его нельзя рассматривать просто как настройку, которая автоматически устраняет ограничение.
Балансировка трафика между несколькими UP
Трафик у сессий двусторонний — от абонента к серверу и обратно. Прямое и обратное направления балансируются разными механизмами.
Исходящий трафик балансируется с помощью L3 балансировщика на основании IPscr и IMSI. Входящий трафик притягивается самим User Plane (DPI+NAT) с помощью BGP анонсов.
Отказ узла
При аварии User Plane управляемого перевода нет — DPI просто перестал отвечать. В этом случае часть потребленного объема может не попасть в итоговый отчет. Но даже здесь размер возможной потери можно ограничить заранее. Он определяется суммой порогов, установленных на узле. Управляющая плоскость может дробить выдаваемые квоты, устанавливая меньшие пороги отчетности и собирая промежуточные данные у себя. В биллинг при этом отправляется исходная величина квоты, когда накопленный объем достигает нужного значения.
Так появляется управляемый бюджет риска. Оператор заранее задает, какой объем допустимо потерять при отказе одного узла. Периодичность отчетов от узлов определяется бюджетом, а периодичность передачи информации в биллинг — величиной квоты. Сам обмен с биллингом при этом не становится чаще.
Как проверить непрерывность
Непрерывность сервиса нельзя доказать тем, что система не отправила сообщение об ошибке. Ее нужно измерять во время реального перевода.
Тест необходимо проводить, только если через активную сессию в момент перевода идет настоящий трафик. Появился разрыв в потоке — непрерывность не обеспечена, и неважно, насколько аккуратно система залогировала само переключение. Так что приемочное испытание должно проверять именно передачу данных, а не корректность служебных сообщений.
Что в итоге дает разделение плоскостей
Ценность CUPS не сводится к независимому масштабированию управления и передачи данных. Куда более важно, что пользовательская плоскость становится заменяемой. А когда узел можно заменить, появляется возможность превратить его вывод из аварийного события в управляемую операцию.
Для плановых работ это означает понятную последовательность: подготовить новый узел, перевести на него сессии, отключить старый и сверить счетчики. Для аварий остается другой механизм — заранее определенный бюджет допустимых потерь.
Именно здесь возникает непрерывность сервиса. Разделение позволяет управлять состоянием сессий во время изменения инфраструктуры. Тогда обещание «плановые работы без влияния на абонентов» перестает быть общей формулировкой и становится конкретной процедурой с измеримым результатом и четко обозначенными исключениями.
