OScam lb_mode: настройка балансировки ридеров и пиров

Если у вас несколько ридеров и пиров в OScam, а запросы уходят только на один источник — это не баг, это дефолтное поведение. OScam loadbalancer lb_mode: настройка распределения нагрузки между ридерами и пирами — именно то, что позволяет выровнять картину и убрать таймауты. Разберём, как это работает, какие значения что делают и как не испортить рабочую конфигурацию неудачными параметрами.

Что делает lb_mode и когда он нужен

Loadbalancer в OScam — это внутренний механизм, который накапливает статистику по каждому источнику (время ответа, процент успешных ECM, количество ошибок) и на основе этих данных выбирает, куда отправить следующий запрос. Он не работает по расписанию — он работает по истории.

Параметр lb_mode задаётся в секции [global] файла /etc/oscam/oscam.conf. Именно там, не в oscam.server и не в oscam.user. После изменения нужен reload: либо через webif, либо командой перезапуска демона.

Принцип балансировки запросов в OScam

Когда клиент запрашивает ECM для определённого CAID/provider/SID, балансировщик смотрит, какие ридеры и пиры вообще могут его обработать, и выбирает среди них по критерию, заданному в lb_mode. Статистика хранится в файле, путь к которому задаёт lb_savepath — например, /var/oscam/stat. При рестарте OScam загружает её обратно.

Важный момент: балансировщик работает на уровне CAID + provider. Два ридера, которые отдают один CAID, но разные provider — для балансировщика это разные источники, и он не будет ротировать их как взаимозаменяемые. Это частая причина, почему ожидаемая балансировка не происходит.

Разница между ридерами (reader) и пирами (peer/proxy)

Ридер — это физическое считывающее устройство с картой или эмулятор. Пир — это подключение к другому серверу по протоколам newcamd, camd35, cccam и т.д. Для балансировщика разницы почти нет: оба источника участвуют в статистике одинаково. Но на практике ридер обычно быстрее и стабильнее по латентности, а пир зависит от сети и политики удалённого сервера.

В конфигурации oscam.server ридеры описываются с параметрами типа device = /dev/ttyUSB0 или device = localhost:8080. Пиры — как протокольные подключения (protocol = newcamd, protocol = cccam и т.д.). Группы (group) и приоритет (cacheex, порядок в конфиге) влияют на то, какие источники вообще попадают в выборку балансировщика.

Когда балансировка реально улучшает работу, а когда мешает

Балансировка помогает при двух и более источниках на один CAID. Если источник один — lb_mode ничего не даст, запросы всё равно идут туда единственно возможным путём. Ещё один случай, где балансировка скорее мешает: разные источники с сильно разным временем ответа и при lb_mode = 1 — быстрый локальный ридер будет забирать 100% запросов, и пиры никогда не наберут достаточно ECM для оценки. Их статистика останется пустой, и при падении локального ридера переключение замедлится.

Значения параметра lb_mode и их поведение

Всего четыре режима. Каждый решает конкретную задачу, и выбор между ними зависит от топологии вашего сервера, а не от универсального «лучшего» варианта.

lb_mode = 0 — балансировка отключена (fallback по порядку)

При lb_mode = 0 OScam вообще не использует статистику для выбора источника. Запросы идут по приоритету группы и порядку ридеров в oscam.server. Первый в списке получает всё, остальные подключаются только если первый не ответил.

Это полезно в одном сценарии: у вас есть чёткая иерархия — локальная карта всегда первая, конкретный пир второй, остальные резерв — и вы хотите этот порядок жёстко зафиксировать без влияния накопленной статистики. Настройка через group в oscam.server и oscam.user здесь работает предсказуемо.

lb_mode = 1 — fastest reader first (минимальное время ответа)

Самый популярный режим. OScam выбирает источник с минимальным средним временем ответа по накопленной статистике ECM. Работает хорошо при зэппинге — быстрое переключение каналов именно за счёт того, что запрос сразу уходит на самый отзывчивый источник.

Строка в конфиге: lb_mode = 1. Но здесь есть подводный камень: очень быстрый локальный ридер (скажем, 80 мс против 300 мс у пиров) «забивает» статистику, и пиры перестают получать ECM для оценки. Через какое-то время их данные устаревают, и при сбое локального ридера переключение происходит медленнее, чем хотелось бы. Лечится через lb_nbest_readers и lb_nfb_readers.

lb_mode = 2 — oldest reader first (равномерная ротация)

Режим выбирает источник, который дольше всего не использовался. Фактически это round-robin по давности последнего обращения. Хорошо подходит, если у вас несколько платных пиров с ограниченным числом запросов в сутки — нагрузка распределяется равномерно, ни один не перегружается.

Скорость ответа здесь не учитывается, что и является главным компромиссом. При зэппинге этот режим заметно хуже lb_mode = 1.

lb_mode = 3 — lowest usage level (наименее загруженный источник)

OScam смотрит на текущую загрузку — сколько активных запросов сейчас обрабатывает каждый источник — и выбирает наименее занятый. Актуально, если у источников есть ограничение на одновременные соединения (например, пир разрешает максимум 2 параллельных ECM). При превышении лимита следующий запрос уйдёт на менее занятый источник автоматически.

На практике этот режим реже применяется в домашних конфигурациях, но полезен на серверах с большим числом клиентов и несколькими пирами с явными ограничениями.

Ключевые параметры тонкой настройки loadbalancer

Один только lb_mode — это рычаг без механизма. Реальная работа балансировщика определяется связкой параметров, которые большинство гайдов просто перечисляют без объяснения, как они влияют друг на друга.

lb_nbest_readers и lb_nfb_readers

lb_nbest_readers — сколько лучших источников держать в активной ротации. При значении 2 балансировщик работает с двумя лучшими по статистике, остальные находятся в резерве. Рекомендую начинать с lb_nbest_readers = 2 — это баланс между предсказуемостью и устойчивостью к сбоям.

lb_nfb_readers — количество fallback-источников, которые подключаются при неудаче основных. Значение 1 обычно достаточно. Если выставить оба параметра в 1, получится поведение, близкое к приоритетному fallback, а не реальной балансировке.

lb_min_ecmcount и lb_max_ecmcount

lb_min_ecmcount = 5 — минимальное количество ECM, которое нужно накопить, прежде чем балансировщик начнёт учитывать статистику источника. До этого порога ридер участвует в выборке, но его данные считаются ненадёжными. Слишком высокое значение замедляет «прогрев» новых источников.

lb_max_ecmcount = 500 ограничивает историю: после 500 ECM старые данные начинают вытесняться новыми. Если источник деградировал, но статистика у него хорошая с прошлой недели, высокий lb_max_ecmcount маскирует проблему. Я обычно ставлю 300–500 в зависимости от нагрузки.

lb_reopen_seconds и lb_retrylimit

lb_reopen_seconds = 900 — пауза перед повторной попыткой подключения к источнику, который вернул ошибку или таймаут. 15 минут — разумный дефолт. Слишком маленькое значение (например, 60) создаёт шквал reconnect к упавшему пиру. Слишком большое (3600+) означает, что восстановившийся пир час будет простаивать.

lb_retrylimit = 800 задаёт порог времени ответа в миллисекундах. Если источник отвечает медленнее этого значения, OScam переключается на следующий в списке. Это, по сути, soft-таймаут на уровне балансировщика. Важно: слишком высокий lb_retrylimit (например, 2000 мс) маскирует деградацию — источник формально не падает, но таймауты растут, а переключения не происходит. Клиенты при этом жалуются на фризы.

lb_stat_cleanup и lb_savepath

lb_savepath — путь к файлу статистики. Например: lb_savepath = /var/oscam/stat. Убедитесь, что директория существует и у пользователя, под которым запускается OScam, есть права на запись. Если путь указывает на tmpfs или RAM-диск — статистика теряется при каждом рестарте, и балансировщик каждый раз начинает с нуля. Это не катастрофа, но «прогрев» после перезапуска займёт время.

lb_stat_cleanup = 336 (в часах) — через сколько часов неиспользуемая запись в статистике удаляется. 336 часов — это две недели. При смене источников или CAID старые записи могут мешать корректной работе, поэтому иногда проще удалить файл stat вручную и дать балансировщику пересчитать всё с нуля.

lb_max_readers и lb_auto_betatunnel

lb_max_readers ограничивает количество ридеров, участвующих в балансировке для одного запроса. По умолчанию OScam проверяет всех подходящих — при большом числе пиров это может создавать лишние задержки на этапе выбора.

lb_auto_betatunnel = 1 — обязательный параметр при работе с каналами на CAID 1801 (Nagravision), которые часто идут через betatunnel на CAID 1722. Без этого параметра балансировщик не корректно сопоставляет запросы, и часть ECM не балансируется — они просто идут на первый доступный источник без учёта статистики. В смешанных конфигурациях с несколькими CAID это одна из частых причин неравномерной нагрузки.

Диагностика балансировки через webif и логи

Настроить параметры — полдела. Понять, работает ли балансировка как задумано — вторая половина. OScam предоставляет достаточно инструментов для диагностики, нужно только знать, куда смотреть.

Чтение раздела Loadbalancer Statistics в веб-интерфейсе

Webif открывается на порту 8888 по умолчанию — http://your-server:8888. Порт задаётся параметром httpport в секции [webif] файла oscam.conf. Раздел Loadbalancer находится в меню, там же — таблица с источниками.

Колонки, на которые нужно смотреть: rc (return code — успех или ошибка последнего ECM), time (среднее время ответа в мс), ecmok (количество успешных ECM), ecmerr (количество ошибок). Если у одного ридера ecmok = 1500, а у остальных по 5–10 — балансировка фактически не работает, всё уходит на один источник.

Интерпретация времени ответа (ms) и счётчиков ECM

Нормальное время ответа для локального ридера — 50–150 мс. Для пира через интернет — 150–500 мс. Значения выше 800 мс стоит воспринимать как сигнал к действию: либо источник перегружен, либо сетевые проблемы, либо карта деградирует.

Большой разброс между минимальным и максимальным временем ответа (колонки min/max, если отображаются) указывает на нестабильность источника — даже при хорошем среднем такой пир будет периодически давать фризы. Стабильный источник с 300 мс лучше нестабильного с 150 мс среднего и выбросами до 1500 мс.

Анализ статуса readers: ON/OFF/ERROR/timeout

Статус ERROR у ридера означает, что последние попытки подключения завершились неудачей и источник временно исключён из балансировки на время lb_reopen_seconds. timeout — источник отвечал, но медленнее lb_retrylimit. OFF — ридер вручную отключён или не прошёл инициализацию.

Если источник постоянно мигает между ON и ERROR — проблема в нестабильном соединении или в слишком низком значении lb_reopen_seconds. Первое нужно чинить на уровне сети или у провайдера пира, второе — увеличением паузы.

Сброс и пересоздание lb-статистики

Через webif есть кнопка сброса статистики для конкретного ридера или для всех сразу. Альтернативный вариант — остановить OScam, удалить файл по пути из lb_savepath, запустить снова. Балансировщик начнёт с чистого листа и начнёт накапливать данные заново.

Это особенно полезно после добавления или удаления источников. Старая статистика по несуществующим пирам не мешает работе, но засоряет картину при анализе. При смене CAID или добавлении новых провайдеров — тоже рекомендую сбрасывать.

Для диагностики на уровне логов: выставить loghistorysize = 200 в [global] и включить debug с флагом loadbalancer. В oscam.conf это debuglevel = 4 или использование маски с битом LB (зависит от версии OScam). В логах появятся строки с указанием, какой ридер выбран для конкретного ECM и почему.

Рекомендации по конфигурации под разные сценарии

Теоретические режимы — это хорошо, но практика важнее. Вот готовые блоки настроек, которые я использую в реальных конфигурациях.

Сервер с одним локальным ридером и несколькими пирами

Задача: локальный ридер всегда первый, пиры — резерв при его недоступности.

[global]
lb_mode = 1
lb_nbest_readers = 1
lb_nfb_readers = 2
lb_min_ecmcount = 5
lb_max_ecmcount = 300
lb_reopen_seconds = 600
lb_retrylimit = 500
lb_savepath = /var/oscam/stat

В oscam.server для локального ридера выставляем group = 1, для пиров — group = 2. В oscam.user для клиентов — group = 1,2. Так локальный ридер попадает в первичную группу, пиры — в fallback.

Но здесь есть нюанс: если локальный ридер значительно быстрее пиров, при lb_nbest_readers = 1 пиры вообще не получат ECM для статистики. При его сбое OScam будет выбирать среди источников без данных. Если резервность важнее скорости — ставьте lb_nbest_readers = 2 и добавьте один пир в активную ротацию.

Чистый proxy без локальных карт

Только пиры, нет локального ридера. Нагрузку нужно распределять равномерно.

[global]
lb_mode = 2
lb_nbest_readers = 3
lb_nfb_readers = 1
lb_min_ecmcount = 10
lb_max_ecmcount = 500
lb_reopen_seconds = 900
lb_retrylimit = 800
lb_savepath = /var/oscam/stat
lb_stat_cleanup = 168

lb_mode = 2 здесь логичен — равномерная ротация при отсутствии явного «лидера». lb_nbest_readers = 3 держит три источника в активной выборке. Если у пиров есть ограничения на число одновременных запросов — рассмотрите lb_mode = 3.

Смешанная схема: локальная карта + резервные пиры

Эта схема встречается чаще всего. Локальная карта обслуживает свои CAID, пиры нужны для остальных каналов и как резерв.

[global]
lb_mode = 1
lb_nbest_readers = 2
lb_nfb_readers = 2
lb_min_ecmcount = 5
lb_max_ecmcount = 400
lb_reopen_seconds = 900
lb_retrylimit = 700
lb_auto_betatunnel = 1
lb_savepath = /var/oscam/stat

Главная тонкость здесь — правильная настройка caid и ident в секциях ридеров. Балансировщик не будет предлагать локальную карту для CAID, который она не поддерживает, но если CAID совпадает у локального ридера и пира — балансировщик сравнит их по статистике. Убедитесь, что локальный ридер имеет корректно прописанные caid и services.

Критерии оценки качества источника без привязки к конкретному провайдеру

При добавлении нового пира в конфигурацию смотрите на следующие показатели: стабильность времени ответа (маленький разброс между min/max важнее низкого среднего), процент ecmok относительно общего числа запросов (хороший источник — выше 95%), частота reconnect в логах (частые переподключения сигнализируют о нестабильном канале или перегруженном удалённом сервере), поддержка нужных CAID и provider без туннелирования.

И последнее: проверяйте, совпадает ли системное время на вашем сервере и удалённом. Расхождение больше нескольких секунд ведёт к некорректным расчётам времени ответа в OScam — балансировщик получает отрицательные или неправдоподобно маленькие значения и начинает принимать неверные решения. ntpd или chrony решают проблему.

Понимание того, как работает OScam loadbalancer lb_mode: настройка распределения нагрузки между ридерами и пирами — это не разовая задача. После изменения конфигурации стоит понаблюдать за статистикой в webif хотя бы сутки, прежде чем делать выводы об эффективности выбранного режима. Балансировщик работает с накопленными данными, и первые часы после сброса статистики — не репрезентативная картина.

Полный контроль над OScam loadbalancer lb_mode: настройка распределения нагрузки между ридерами и пирами начинается с понимания связки трёх параметров: lb_nbest_readers (сколько источников в активной ротации), lb_retrylimit (когда переключаться на следующий), lb_reopen_seconds (когда снова пробовать упавший). Без этой троицы даже правильный lb_mode даст посредственный результат.