BiTel

Доброго времени суток.
Никак не могу взять в толк некоторые моменты...
При открытии шлюза в договоре, посылаются открывающие правила на шлюз, при закрытии - наоборот, это понятно, все работает.

Поясните кто может следующие моменты:
1) Что происходит при проверке шлюзов IPN шедулером, посылаются какие-нибудь правила? или просто проверяется доступность шлюза и проверка на предмет "открыт/закрыт" для договора?

2)Отправили открывающие правила, манад отработал, скорость ограничилась, все работает... но потом, допустим я взял и перезагрузил шлюз, правил которые были добавлены больше нет..
а они должны появиться? манад после перезагрузки должен их восстанавливать?
если нет то как сделать?
Просто непонятно, перезагрузился сервер, правил нет.. ждать шедулера? пока он проверит шлюзы?

спасибо

Кстати говоря, пользуясь случаем, осмелюсь поправить автора мануала по настройке manad Для linux.

init_shaping.sh для шейпера в обе стороны на eth0 должен выглядеть примерно так:



кстати этот способ можно использовать когда на шлюза 2 интерфейса и одновременно работают шейпер и НАТ.
Чтобы увидеть адреса за НАТом - либо Iptables MARK, но получаем макс количество правил MARK 255, либо IMQ, тогда патчить, и IMQ вроде как нормально работает на последних ядрах >2.6.2х
либо с Ingress как в примерею

В исходном варианте мануала, шейпится только входящий трафик клиентам т.е. eth0 egress.

Пример запроса шлюза для manad примерно такой:


также обратил внимание, что в примере мануала
вот так:
tc filter add dev eth0 parent ffff: protocol ip prio [N2] u32 match ip src {A} flowid 1:1[N2]
мне кажется должно быть так:
tc filter add dev eth0 parent ffff: protocol ip pref [N2] u32 match ip src {A} flowid 1:1[N2]
Пример запроса здесь не до конца проработан, можно при создании классов наследовать их чуть по другому, но работать будет

Может кто все же откликнется?
UP.

upd. Если создал не в том разделе - переместите тему плз.

традиционно UP

Там послаются все правила - как при открытии , так и при закрытии . Манад сам разбирается какие ему нужны .. кажется при закрытии он вообще сейчас ими не пользуется , он просто по коду договора удаляет их своего кеша и правила на удаление, тоже берет из кеша.

Проверка шлюза ничем не отличается от того что вы делаете в договоре . Вы менеяте статус шлюза и потом вызывается сихронизация этого статуса для этого договора на этот шлюз .. Задача проверки шлюзов собирает список всех договоров для каждого шлюза и вызывает синхронизации шлюза. Синхронизация шлюза просто получает список догоров и их статусов ( при работе из клиента биллинга - передается всего один договор и его статус) . Потом посылается команада test на данный шлюз.. В ответ получает список id договоров, которые открыты на данном шлюзе ..потом для каждорго договра из списка берется его статус .
1. если статус - открыт и резултате команды test он есть, то ничего не делаем
2. если статус - открыт и резултате команды test его нет , то посылаем команду на откытие шлюза "add id команды".
3. если статус - закрыт(имеются ввиду все статусы кроме открыт) и в результате команды test его нет, то ничего не делаем
2. если статус - закрыт(имеется ввиду все статусы кроме открыт) и в резултате команды test он есть , то посылаем команду на закрытие "remove id команады". Причем в это случае комнады Manad не использует ., он берет их по id из кеша, который положил при команде add. Но может и использовать, завсит от реализации manad, это его дело



Да ждать шедулера..при следующем вызове manad в test ничего не вернет, тогда туда полшлются комнады синхронизаии для всех договров, которые на нем .. Вообще можно переписать скрипт manad чтобы вообще не держал своего кеша, а при вызове команды test парсил вывод iptables и выдавал реально то, что есть ..т.е напрмер шлюз мог не перезагружаться, а manad перезагрузился ..тогда у него кеш пустой ..либо переодическси считывал бы iptables и обновлял свой кеш сам

По поводу мануала - спасибо . Как будет время изучу и подправлю, если надо

Спасибо за подробное разъяснение!
т.е. если я правильно понял: если я просто остановлю и запущу manad.pl
не перезагружая шлюз, он должен взять правила из кеша? или он полностью обнуляется? (кстати, что представляет из себя кэш фактически?, я в перле пока не силен, код проанализировать сложно)

Появились еще вопросы...
1)Скажите, а какой рекомендуемый интервал запуска проверки шлюзов в шедулере?
вообще конечно логично запускать его в 23:59 раз в сутки,
Но что если необходима перезагрузка шлюза?
Варианты:
В случае анлимщиков:
--отложить перезагрузку до 23:59

--запускать проверку шлюзов раз, допустим в час - пол часа или еще чаще, тогда можно легче планировать перезагрузку.

Вообще я сам понимаю, что сервер будет перезагружаться редко, это не win, но всеже, на период отладки и внедрения мало ли что будет.

2) всвязи со всем вышесказанным второй вопрос:
может быть легче будут варианты:

--После перезагрузки шлюза - я вручную запускаю задачу проверки шлюзов в шедулере. Это можно сделать?

--После перезагрузки шлюза и запуска манад. скрипт манад (модуль IPN ведь постоянно слушает его порт) брал и без запроса IPN возвращал ему самостоятельно - мол test пуст, давай синхронизацию.
Можно ли реализовать такое? или подобное?

Разумеется последний способ был бы полезен и при внеплановой/аварийной перезагрузке шлюза.

upd.
3)Кстати про лимитчиков:
Схема как я понимаю такая (дабы внести ясность):
IPN считает трафик по услугам, с баланса пользователя списывается сумма(трафик) при каждом обсчете логов IPN, по достижении порога отключения, договор переводится в состояние закрыт, а потом уже шедулер проверят шлюзы и посылает команды на манад..так?

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

Кеш - манада живает только в памяти . в той реализации, которая доступна у нас, он не сохраняется на диск и сбрасывается после перезагрузки манада.. Кеш просто структура данных, которая по ключу ( в данном случае id договора) сохряняет набор команд..


кач часто проверять зависит от того сколько у вас шлюзов и клиентов на них ..если шлюз сего один и на нем клент один то можно поставить и чаще чем раз в минуту.. Вообще подрузумевается какой-то разумны интервал (допустим 10 минут, 30 минут) . И если манад перезагрузился , то за это интревал задача проверки шлюзов восстановит все правила..


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


Нет , вы не правы по поводу IPN. Этот модуль ничего не слушает, кроме разве что трафика нетфлоу (в коллекторе) . Его функционально можно поделить на 2 части - считать деньги(наработку) и управлять доступом клиента. первая задача считает по логам(которых может сама же и собирать) и за нее отвечает колеллектор + задача обсчета баланса модуля IPN. вторая это синхронизация статуса шлюза в биллинге и реального статуса , заодно тут еще и закрывают шлюз(и там и там), если денег нет .. это задача проверки шлюзов ..IPN послылает test в задаче проверке шлюзов манад ( по таймеру )..т.е через каждые 10 минут он пробегается по всем договорам на всех шлюзах и там, где статусы реальные не совпадают с биллингом (манад перезагрузился , или у шлюза в билинге изменился статус за эти 10 минут), исправляет ситуацию.. т.е это манад постоянно слушает , а ipn раз в 10 минут ему шлет команды (test и потом остальное если надо). ..Вообще магад может быть недоступен по каким-то причинам и поптыка работаь с ним получит ошибку - шлюз недоступен .. Тогд через 10 минут если шлюз станет достпуен, то там обновят правила ..


Да, так и есть .. выше вы несколько ошиблись, а тут в целом правы..

Только задача проверки шлюзов IPN еще дополнительно делает такую вещь - если денег < лимита, то закрывает шлюз(меняет статус шлюза в биллинге и меняет статус шлюза рельно ) .. тут вообще есть 2 статуса - первый это статус договора , а второй -статус шлюза IPN.. Статус договора влияет на все модули глобально, если его проставили (этим занимается задача "Установка статусов договоров" и при поступлени платежа например статус может изменится), то статус шлюза тоже меняется ..

Все предельно понятно, спасибо!
Одно уточнение:
Т.е. manad.pl возвращает что-либо только после запроса "test" из IPN?
а IPN готов принять возвращаемое значение только после того как послал test манаду?

Можно ли подпрограмму манада - hundle (она ведь анализирует запрос? или нет?) вызвать, передав ей параметром (или как то еще) "test", без запроса из IPN. и тогда бы она на сокет вернула значение.
Или этого не сделать пока IPN не послал запрос и соответственно не подключился к порту?

какая еще возможна реализация случая когда манад при запуске сам просит IPN о синхронизации?

Да


манад - это сервер, а IPN - это клиент .. клиент опрашивает сервер (переодически) и на основе его ответа шлет корректирующие команды. Заставить клиента что-то сделать нельзя , он нечего не слушает .. вы можете написать своего клиента, который будет обращаться к манад ..

Понятненько, я так и предполагал.
спасибо

Не хочу создавать лишнюю тему поэтому спрошу здесь
Какие сложности могут возникнуть при запуске скрипта manad.pl и биллинга на одной машине? (linux)
могут быть проблемы с портами? или просто адрес шлюза будет локалхост?
спасибо.

никаких проблем