Расхождение в учете трафика обнаруживается поздно. Оно всплывает в конце расчетного периода при сверке с биллингом, иногда только после претензии абонента. К этому моменту логи за нужный период уже перезаписаны, а узлы успели перезапуститься. Расхождение обычно невелико, порядка процента. Связать его с конкретным событием почти невозможно.
Мест, где теряются данные учета, немного. Их можно перечислить, для каждого заранее вычислить величину потери и превратить ее из свойства системы в настраиваемый параметр. Таких мест четыре — отказ узла обработки, перебалансировка, смена узла управления и смена набора правил.
Меня зовут Алексей Червяков, я разработчик и тимлид в VAS Experts. В этой статье разберу каждое из этих мест, покажу, как оценить и ограничить потери, и какие показатели стоит отслеживать, чтобы заметить проблему вовремя.
Как устроен учет в сервисном шлюзе
Сервисный шлюз состоит из узлов обработки и узлов управления. В учете трафика участвуют несколько элементов:
Узел обработки (DPI) — элемент сервисного шлюза на плоскости данных (user plane), через который физически проходит трафик абонентов.
Узел управления (PCEF) — элемент сервисного шлюза на плоскости управления (control plane), который выдает узлам обработки пороги по группам учета и получает отчеты о потреблении.
Биллинг (OCS) — внешняя система тарификации. Она выдает квоты на трафик и принимает отчеты о потреблении.
PCRF — внешняя система управления политиками. Она определяет политику обслуживания абонента и набор групп, которые разрешены абоненту. Иногда PCRF выполняет и роль OCS.
Сервисный шлюз СКАТ
Квота — это объем, который система тарификации выдала сессии по группе учета. Порог — это объем, после которого узел обработки отправляет отчет. Узел управления устанавливает порог на основе квоты от OCS.
Основная единица учета — группа учета. Она объединяет трафик нескольких сервисов, которые тарифицируются одинаково, и DPI отчитывается по их суммарному объему. Например, группа «видеостриминг» с идентификаторами RG 10 и SI 0 (Rating Group и Service Identifier) может собирать трафик YouTube, Rutube и других видеосервисов.
DPI классифицирует пакеты, относит их к группам учета и по каждой группе ведет счетчик объема. Данные об объеме PCEF получает из отчетов DPI. При этом PCEF хранит состояние сессий — выданные кредиты, израсходованный объем, сроки действия квот.
PCRF определяет также ограничения скорости для каждой группы учета. OCS выдает объемы по каждой разрешенной группе и принимает отчеты о расходе.
Цикл учета начинается с PCRF. Он сообщает PCEF, какие группы учета доступны абоненту. PCEF запрашивает у OCS объемы по каждой разрешенной группе и передает в DPI набор групп с ограничениями и порогами.
Когда расход по группе доходит до порога, DPI отправляет отчет в PCEF. По запросу PCEF отчет может быть отправлен и раньше. PCEF передает данные в OCS или PCRF и в ответ получает новую квоту или новый набор правил, который снова отправляет в DPI. Весь обмен между DPI и OCS идет через PCEF.
Слабое место этого цикла — промежуток между отчетами. Данных о накопленном расходе у PCEF и OCS нет до получения отчета. Расход существует только в счетчиках DPI. Если узел отказывает или сессия переезжает при перебалансировке, неотправленный объем пропадает. Это и есть причина потерь в учете.
Место первое: отказ узла обработки
При отказе узла потеря неизбежна, ведь он не успевает передать накопленные данные. Но величину потери можно рассчитать заранее:
Формула дает оценку для узла, загруженного полностью. За интервал между двумя отчетами такой узел пропускает объем, равный его пропускной способности, умноженной на длительность интервала. Отказ в среднем приходится на середину этого интервала. Значит, теряется примерно половина этого объема.
Для узла с пропускной способностью 200 Гбит/с это выглядит так.
Средний интервал между отчетами | Потеря при отказе узла |
5 минут | около 3,75 ТБ |
1 минута | около 750 ГБ |
30 секунд | около 375 ГБ |
Цифры внушительные, но в масштабе узла это немного. Итоговый убыток зависит от того, как часто узлы отказывают и как тарифицируется потерянный трафик.
По формуле, потеря пропорциональна интервалу между отчетами. DPI отправляет отчет, когда сессия расходует объем, равный порогу. Чем меньше порог, тем быстрее он набирается, тем чаще уходят отчеты и тем короче интервал, а значит, тем меньше потеря.
Неотправленный объем каждой сессии не превышает ее порога. Значит, потеря при отказе узла обработки не превышает суммы порогов всех сессий на этом узле. Получается, потери можно регулировать через пороги, которые в свою очередь устанавливает узел управления PCEF.
По умолчанию PCEF устанавливает порог, равный квоте от OCS. Тогда сумма порогов на узле — это квота, умноженная на число сессий. Столько и будет потеряно в худшем случае при отказе узла. Чтобы снизить риск, оператор может заранее ограничить возможные потери.
Бюджет риска
Для этого в PCEF от Vas Experts есть бюджет риска — предельный объем, который допустимо потерять при отказе одного узла. Оператор может задать его в настройках для узла в целом и отдельно для каждой группы услуг. При заданном бюджете PCEF проверяет, чтобы выдаваемая абоненту квота, умноженная на число сессий с этой услугой, не превышала его.
Если бюджет превышен — квота дробится: на узел обработки устанавливается меньший порог отчетности. Промежуточные отчеты PCEF суммирует сам, а в OCS отправляет отчет, только когда израсходована вся квота.
Пример расчета
Система тарификации выдала квоту 100 МБ. Дальше возможны два сценария:
Квота с учетом числа сессий укладывается в бюджет риска. Узел управления устанавливает порог 100 МБ. По достижении порога PCEF отправляет отчет в систему тарификации и запрашивает новую квоту.
Квота превышает бюджет риска. Узел управления устанавливает порог 10 МБ, и узел обработки отправляет промежуточный отчет после каждых 10 МБ. Как только сумма промежуточных отчетов достигает 100 МБ, узел управления отправляет отчет в систему тарификации и запрашивает новую квоту.
Вместо бюджета риска можно использовать упрощенный вариант. Квоту делят на фиксированный коэффициент или ограничивают сверху постоянным значением. Настройка задается для всех услуг сразу или для каждой отдельно. Упрощенный вариант не учитывает число сессий. Он ограничивает потерю по одной сессии, а не по узлу обработки в целом. Его преимущество — отсутствие расчетов, поэтому с него удобно начинать внедрение.
Две периодичности вместо одной
В нашем решении дробление квоты выполняет PCEF. PCEF передает узлам DPI настройки по протоколу PFCP. Этот протокол позволяет задать узлу DPI порог отчета меньше квоты. Размер порога определяет PCEF и подстраивает его под заданный бюджет риска. Например, оператор указал в настройках, что по группе «видеостриминг» на одном узле может накопиться не больше 100 ГБ трафика, по которому еще нет отчета. Если услугой пользуется один абонент, PCEF задаст ему порог 50 ГБ. Если абонентов миллион, DPI будет отчитываться по каждой сессии примерно раз в 100 КБ.
Без дробления порог равен квоте, поэтому DPI отчитывается в PCEF так же часто, как PCEF — в OCS. С дроблением эти периодичности разделяются и задаются независимо.
Отчеты | Чем задается частота | Результат |
От узла управления в систему тарификации (От PCEF в OCS) | Квотой, которую выдала система тарификации | Нагрузка на систему тарификации не меняется |
От узла обработки узлу управления (От DPI в PCEF) | Бюджетом риска | Потеря при отказе узла обработки не превышает бюджета риска |
Без дробления оператору приходится выбирать. Частые отчеты снижают потери при отказе, но нагружают OCS. Редкие отчеты разгружают OCS, но увеличивают потери. С дроблением чаще отправляются только отчеты от узла обработки к узлу управления. Этот обмен идет внутри сервисного шлюза и обходится дешевле обмена с системой тарификации.
Три условия корректной работы механизма
Промежуточные отчеты не передаются в систему тарификации
Промежуточные отчеты в OCS не передаются. OCS получает отчет, когда израсходована вся квота, а также при истечении ее срока или завершении сессии. Промежуточные отчеты увеличили бы нагрузку на нее во столько раз, на сколько частей поделена квота, — как раз там, где ее старались не допустить.
Действие при исчерпании квоты выполняется только после расхода всей квоты
Система тарификации может назначить действие на случай исчерпания квоты: блокировку или переадресацию. Промежуточный порог лишь запускает отправку отчета, а действие выполняется, когда израсходована вся квота. Если связать действие с промежуточным порогом, абонент с квотой 100 МБ будет заблокирован уже после 10 МБ.
Дробление ограничено снизу
Чем меньше часть квоты, тем больше отчетов, и при слишком мелком дроблении внутренний обмен тоже становится заметной нагрузкой. Поэтому у порога есть минимальное значение. Если бюджет риска не выдерживается даже при нем, PCEF формирует предупреждение: превышать бюджет без уведомления оператора недопустимо.
Место второе: перебалансировка
Потери при перебалансировке менее заметны, чем потери при отказе. Когда распределение абонентов по узлам считается функцией от списка живых узлов, любое изменение списка переносит часть сессий на другие узлы. Абонент при этом теряет соединение — это видно. А вот объем, накопленный на прежнем узле после последнего отчета, пропадает вместе с сессией.
Перебалансировку вызывают не только аварии, но и плановое добавление узла DPI — штатная операция для наращивания емкости. То есть учет теряется именно тогда, когда сеть, казалось бы, улучшают.
Узнайте, как расти без потерь для абонентов в статье — Масштабирование в модели CUPS: как расти, не задевая абонентов.
Чтобы объем не терялся, сессию переводят на новый узел управляемо:
PCEF создает сессию на узле‑приемнике, передает услуги и профили абонента и устанавливает порог на остаток квоты.
Трафик абонента переключается на узел‑приемник.
PCEF завершает сессию на узле‑источнике, и тот отправляет итоговый отчет.
PCEF складывает объемы, которые насчитали оба узла, и устанавливает узлу‑приемнику новый порог.
При таком переводе потерь нет. Узел‑источник завершает сессию штатно и перед этим отправляет весь накопленный объем. Двойного учета тоже нет. Каждый байт насчитан только одним из двух узлов, а новый порог приемнику задается абсолютным значением, рассчитанным от суммарного расхода по обоим узлам, а не прибавкой к тому, что приемник уже насчитал.
У управляемого перевода есть еще одно преимущество. Подключение абонента не прерывается, а потребление известно точно. Значит, сессию тарификации не нужно закрывать и открывать заново. При большом числе сессий разница существенна. Закрытие и повторное открытие одной сессии тарификации требует четырех сообщений: запрос и ответ на закрытие, запрос и ответ на открытие. Если выводить из работы узел обработки с четырьмя миллионами сессий через закрытие и повторное открытие, в системе тарификации возникнет до шестнадцати миллионов сообщений. При управляемом переводе обмена с системой тарификации нет.
Место третье: смена узла управления
PCEF хранит в памяти состояние сессий тарификации: выданные квоты, израсходованные объемы, сроки действия квот и номера запросов к системе тарификации. При дроблении квоты сюда же добавляются суммы промежуточных отчетов. При отказе узла управления его сессии переходят к другому узлу управления. Без этого состояния новому узлу неизвестен остаток квоты и срок ее действия. Поэтому состояние сессий хранится в общем хранилище, доступном всем узлам PCEF. К хранилищу есть два требования.
Сроки действия квот хранятся как абсолютное время окончания, а не как остаток
Запись «квота действует еще 400 секунд» бесполезна для нового узла управления: момент создания записи неизвестен. Запись «квота действует до 14:32:07» однозначна в любой момент. Это требование предполагает, что часы на всех узлах PCEF синхронизированы.
Номер запроса к системе тарификации сохраняется в хранилище до отправки запроса, а не после
Каждый запрос к OCS в рамках сессии получает свой номер. Запрос с уже использованным номером OCS отбрасывает как дубликат. Допустим, узел управления отправил запрос и вышел из строя до сохранения номера в хранилище. Новый узел управления возьмет из хранилища последний сохраненный номер и повторит его. OCS отбросит запрос, новая квота не будет выдана, и сессия останется без квоты. Чтобы этого избежать, достаточно сначала сохранять номер запроса в хранилище и только потом отправлять запрос. Сделать это в коде просто. Гораздо сложнее заметить саму ошибку. Она срабатывает редко и выглядит как случайный сбой у одного абонента.
Место четвертое: смена набора правил во время сессии
PCRF может сменить набор правил прямо во время сессии, например при переходе с дневного тарифа на ночной. Объем, насчитанный до смены, должен учитываться по старым правилам. Иначе трафик, потребленный по дневному тарифу, будет учтен по ночному.
Механизм простой, но требует строгого порядка действий:
DPI получает от PCEF новые правила.
DPI отправляет отчет о накопленном объеме.
DPI применяет новые правила.
DPI подтверждает PCEF смену правил.
Подтверждение уходит после отчета, поэтому к моменту, когда PCEF узнает о смене правил, весь объем по старым правилам уже учтен.
Между отправкой отчета и применением новых правил есть промежуток, в котором конфигурация учета не определена. На это время должно действовать правило по умолчанию, которое блокирует трафик абонента:
Не ждите сверки с биллингом
Ошибки учета не проявляются сразу, и к концу расчетного периода их причину уже не восстановить. Чтобы заметить проблему вовремя, следите за шестью показателями.
Показатель | Что означает рост |
Разница между числом открытых и закрытых сессий тарификации | Часть сессий не завершается штатно, и итоговое потребление по ним не передается |
Число сессий, переведенных без итогового отчета | Растет число случаев потери объема |
Средний интервал между отчетами по активным сессиям | Растет множитель в формуле потери при отказе узла обработки |
Сумма порогов всех сессий на узле обработки | Растет верхняя граница потери при отказе этого узла. Приближение к бюджету риска — повод пересмотреть дробление квот |
Отставание узлов от обновлений таблицы распределения сессий | Узлы используют устаревшую таблицу распределения. Трафик абонента может попасть на узел DPI, который больше не обслуживает его сессию |
Число отчетов от узла обработки, который больше не обслуживает сессию | Растет число опоздавших отчетов |
Последний показатель требует пояснения. Когда сессию переводят на другой узел DPI, прежний узел может прислать отчет с опозданием. Например, отчет ушел до переключения, а дошел до PCEF уже после. В таком отчете реальный трафик абонента, который еще нигде не учтен. Если PCEF отбросит его только потому, что этот узел больше не обслуживает сессию, объем пропадет. То есть сервисный шлюз потеряет учет сам, без всякого отказа. Поэтому опоздавшие отчеты нужно принимать и добавлять к расходу той сессии, к которой они относятся.
Итог
Потери в учете трафика возникают в четырех ситуациях, и неизбежна только одна из них — отказ узла обработки. Узел не успевает передать накопленный объем, и этот трафик выпадает из учета. Но и здесь потерю можно держать под контролем: ее верхняя граница равна сумме порогов на узле, а через бюджет риска оператор сам решает, сколько готов потерять. В нашем решении PCEF сам подстраивает пороги под этот бюджет, поэтому граница потери при отказе любого узла известна заранее, а нагрузка на OCS при этом не растет.
В остальных трех ситуациях потерь можно избежать, если заранее заложить правильный порядок действий:
при перебалансировке сессии переводятся на другой узел обработки управляемо;
сроки действия квот хранятся как абсолютное время;
номер запроса сохраняется до отправки запроса;
накопленный объем отправляется до смены правил.
Все это несложно сделать заранее. А вот найти причину расхождения после сверки с биллингом почти невозможно.
