Программирование под Linux (26-11-2004)

Здравствуйте дорогие подписчики рассылки "Программирование под Linux" !!!
 ....----==== http://www.firststeps.ru/linux ====----....

Сначала, хочу сказать спасибо всем кто написал письма. Думаю их могло бы быть и больше, но хорошо уже, что есть хоть что-то. Значит есть заинтересованность.

Для начала спасибо Vasiliy (work75@------.ru), который указал на то, что в Компьютерре недавно был выпуск с темой номера посвященной биллинговым системам. Настоятельно рекомендую прочитать эти две статейки.

• Биллинг и термодинамика - http://offline.computerra.ru/2004/565/36513/
• Факты по расчету - http://offline.computerra.ru/2004/565/36514/

Конечно же ничего посвященного программированию Вы там не увидите, зато сможете узнать основные проблемы и задачи, которые могут стоять на пути у разработчика. Возможно я на основе этих статей буду приводить какие-то примеры и строить рассуждения, так как в них привидены достаточно жизненные ситуации. Свертывая смысл этих статей в короткую фразу, можно сказать, что хорошая биллинговая система это сложный и дорогой комплекс ПО, требующий постоянного контроля и доработки, т.е. требующий наличия связи с разработчиками.

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

Я целый день ждал Вашей реакции, и даже не думал, что "рыбалка" будет настолько удачной. Наживку заглотила крупная, возможно даже гигантская "рыба" :) Собственно, на письме это человека и хочется остановиться, так как раскрытый ответ на него даст всем понятия обо всем, чем мы будем заниматься, и возможно даже приведет к продолжительному конструктивному разговору.

Вот текст этого письма:

=======================================
Хотелось бы чтобы Вы осветили основные модули и направления будущей биллинговой системы.
А также ответили на несколько следующих вопросов:
1) Будет ли писаться с нуля радиус сервер, или использоваться готовый?
2) Если будет готовый - то как будет осуществляться связь между БД биллинга и БД радиуса?
3) На какой базе данных будет все это крутиться.
4) Метод подсчета траффика (NetFlow? или еще что?).
5) Учет различных методов съема траффика с CISCO, PC-сервер (с разными операционками) и т.п. 
6) На какой платформе должен будет работать биллинг.
7) Будет ли учет распределенной инфраструктуры (сбор с данных с многих точек а подсчет в одной...)
8) Какие потребности в ЦП и памяти потребуются биллингу чтобы считать непрерывный поток, скажем в 100Мбит/сек?
9) Максимальное количество активных/пассивных пользователей.
10) Точность подсчета трафика.
11) Точность подсчета времени.
12) Будет ли связь с такими программами как 1С?
13) Будет ли веб интерфейс?
14) Онлайновый подсчет траффика или оффлайновый?
15) Как быстро система будет работать через, скажем, 2 года?
16) Какие языки будет использованны при написании?
17) Будет ли делиться трафик по разным сетям (home, town, country, world)?
18) Какая информация будет сохраняться для доказывания клиенту что он именно столько и скачал?
19) Взаимодействие клиента и биллинговой системы.
20) Взаимодействие менеждеров (провайдер) и биллинговой системы.
21) Механизы отрубания/подключения пользователя
22) Кроме рубля могут быть еще и друге валюты расчета (евро, доллар, нац. валюта) 
    При чем бывает в одной биллинговой системе одним надо платить по рублям, а другим по долларам.
23) Какова максимальная сложность тарифных планов?
24) Устойчивость системы к взлому.
25) Механизм взаимодействия межжду различными модулями системы.
 
По группам - почему бы их не сделать пересекающимися?
например - Диалапшик/Выделенщик могут пересекаться с группами Плохой/Хороший и все это с 
Предоплата/В Кредит.
(т.е. ввести еще одну табличку связи групп и пользователей)
 
Я сам уже писал ядро биллинговой системы (работает 3 года почти без сбоев), 
но добавлять всякие фенечки приходится до сих пор:))
 
Kern Elvish
kern@----.---.kg
 
P.S. Я не против публикации этого письма в рассылке, исправления орфографических 
и грамматических ошибок приветствуется :))
=======================================

Приступим к ответу на это письмо:

1) Будет ли писаться с нуля радиус сервер, или использоваться готовый?
2) Если будет готовый - то как будет осуществляться связь между БД биллинга и БД радиуса?

  На эти вопросы ответить не могу по причине того, что, каюсь, но незнаю,
  для чего RADIUS сервер нужен. Насколько я себе это представляю, этот
  сервер предназначен для сбора статистики и авторизации, возможно еще и
  для совершения расчетов. Буду признателен, если найдутся люди, которые
  смогут по этому поводу, что-то написать и дать полезные ссылки.
  Пока мое мнение, радиус сервер не нужен. Собрать статистику и 
  обсчитать все можно самим.

3) На какой базе данных будет все это крутиться.
 
  По моим планам конкретной привязки к какой-либо базе данных не будет, вся
  такая работа будет реализована в виде интерфейса с модулем. То есть в 
  программе будет определен набор примитивных операций (например,
  "считать список пользователей", "записать статистику", "считать
  состояние счета" и т.д.), которые далее будут реализованы в виде модуля
  под любую базу данных. За основу примем MySQL и PostgreSQL, а желающие
  могут это перевести на Oracle, DBF, *.txt и т.д.

4) Метод подсчета траффика (NetFlow? или еще что?).
5) Учет различных методов съема траффика с CISCO, PC-сервер (с разными операционками) и т.п. 
6) На какой платформе должен будет работать биллинг.
7) Будет ли учет распределенной инфраструктуры (сбор с данных с многих точек а подсчет в одной...)

  Судя по названию рассылки разработка будет вестись под Linux, 
  соответственно будут использоваться доступные в нем средства
  подсчета трафика. Пока у меня нет задачи родить "монстра", способного
  считать все и вся, поэтому ограничимся подсчетом пакетов в
  системе, т.е. создадим считалку для пограничного маршрутизатора.
  Конкретно будет использоваться netfilter & libipq.

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

  Ограничения на разработку накладывает то обстоятельство, что нет 
  возможности учесть желания всех, даже по тому, что например, чтобы
  что-то делать под Cisco надо ее иметь под рукой и уметь с ней работать.
  А такая "роскошь" есть не у каждого.

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

8) Какие потребности в ЦП и памяти потребуются биллингу чтобы считать непрерывный поток, скажем в 100Мбит/сек?

  Сложно предсказать работу еще не разработанной системы :) Но по
  имеющимся у меня данным (т.е. по уже работающему биллингу, который
  я разработал по этой схеме) могу предположить следующее:
  Обсчитывать 100 мбит будет достаточно средняя машинка.
  Имеющийся сегодня Celeron 1700 на канале 10 мбит загружен не больше
  чем на 5% и все содержимое информации о более чем 300 пользователях
  умещается в 2 Мб (размер базы данных, а в памяти и того меньше).
  Должен отметить, что бОльшую часть загрузки процессора берут на
  себя операции записи на диск и передача пакетов. К тому же
  я планирую оптимизировать все операции поиска и сравнений,
  которые только можно.

9) Максимальное количество активных/пассивных пользователей.

  Думаю количество в несколько тысяч (5-10) пользователей удовлетворит желание
  большинства. Конечно же все будет зависеть от производительности сервера.
  При среднем расчете, что на пользователя будет отводиться около
  500 байт памяти, то для 10000 пользователей это всего 5 Мб. Плюс
  накладные расходы столько же и получаем, что для крупнейшей сети
  потребуется всего несколько десятков мегабайт памяти сервера.

10) Точность подсчета трафика.
11) Точность подсчета времени.

  Трафик я планирую считать (и сейчас считаю) в "параноидальном" режиме,
  т.е. для каждого пользователя и типа трафика более 100 счетчиков.
  (это 4 протокола - [ICMP,UDP,TCP,другие], разделение на размеры
   пакетов 32,64,128,256,512,1024 и все это в обе стороны, т.е.
   входящий и исходящий)
   Точность времени - 1 минута, в идеале конечно будем стремиться
   к realtime.

12) Будет ли связь с такими программами как 1С?

   Пока не планируется. По причине того, что возможно это и не надо.
   А во-вторых, в статях в Компьютерре есть несколько примеров насчет
   этого. Сильная связь с бухгалтерией чревата опасностями.
   Хотя, конечно же, никто не мешает сделать импорт/экспорт данных.
   Вопрос только в требуемых форматах.

13) Будет ли веб интерфейс?

   Естественно. Возможно это будет связка Apache+PHP, а возможно
   и собственная реализация вебинтерфейса в виде отдельного
   сервиса (думаю это единственный вариант для realtime систем).

14) Онлайновый подсчет траффика или оффлайновый?

   Подсчет трафика ведется "на лету". Подсчет денег и блокирование
   услуг с каким-то периодом. В существующей системе это 1 минута,
   но есть желание это сделать realtime, если конечно производительность
   позволит.

15) Как быстро система будет работать через, скажем, 2 года?

   Проживем два года и увидим :)

16) Какие языки будет использованны при написании?

   В ядре не будет никаких Perl, Python и т.д. Любителей скриптов
   попрошу удалиться :) Только С/С++. Еще не до конца пал выбор
   в сторону С++, но возможно это будет именно он, потому что
   объектный подход в такой системе избавит от множества ошибок
   и упростит разработку. Пока сложно сказать как это скажется
   на быстродествии, но думаю не особо значительно.

17) Будет ли делиться трафик по разным сетям (home, town, country, world)?

   Обязательно. Ибо существующая система этого не умеет, и появилось
   желание это реализовать. В вышеупомянутых статьях и про это сказано.
   "Чтобы научить его подобной экзотике, порой требуется работа, 
   сопоставимая по объему с созданием новой биллинговой системы с нуля."
   Мы, собственно говоря, это и начали делать :)))

18) Какая информация будет сохраняться для доказывания клиенту что он именно столько и скачал?

   Сегодня я веду лог по каждому заголовку ip пакета. Думаю следует
   это расширить на уровень TCP/UDP и даже на http/pop/smtp.
   Вопрос лишь в том, насколько хватит дисковых ресурсов сервера.
   В любом случае эта возможность будет задаваться для
   каждого пользователя отдельно.

19) Взаимодействие клиента и биллинговой системы.

   Получение статистики через Web интерфейс. Авторизация по доступным
   стандартным средствам, т.е. ip/mac/login.

20) Взаимодействие менеждеров (провайдер) и биллинговой системы.

   Многоадминистраторская система администрирования с назначением 
   привилегий для каждого действия.

21) Механизы отрубания/подключения пользователя

   Естественно, нет денег - нет стульев. Прекращаем хождение пакетов
   и все. Постараемся прыгнуть и на уровень оборудования L2, для
   блокирования портов подключения.

22) Кроме рубля могут быть еще и друге валюты расчета (евро, доллар, нац. валюта) 
    При чем бывает в одной биллинговой системе одним надо платить по рублям, а другим по долларам.

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

23) Какова максимальная сложность тарифных планов?

   Ну, например, реализация такого тарифа будет пустяковой. Трафик 
   на несколько подсетей по различной цене. На какую-то подсеть
   цена трафика динамически меняется в зависимости от объема.
   Ну об этом скоро поговорим конкретнее. Раскрою секрет. Понятие
   "цена" трафика в биллинге не будет. Будет только понятие
   "функция вычисления цены", а там уж твори, что душе угодно,
   хоть строй зависимость от температуры окружающей среды.

24) Устойчивость системы к взлому.

   Это сложно предсказать :) Думаю взломать будет не просто, 
   если над этой разработкой подумает хотя бы несколько голов.

25) Механизм взаимодействия межжду различными модулями системы.

   Определенные интерфейсы, реализация которых будет варьироваться
   от системы к системе. В идеале конечно же надо стремиться к модели
   по типу OSI, поэтому я и прошу всех помочь это сделать :)

По поводу введения возможности членства пользователя в нескольких группах.
А вы ответьте на вопрос "а как это скажется на подсчете статистики ?"
Ну, помоему, совершенно никак... Ввести такую возможность конечно можно,
но она будет лишь для удобства администрирования. А администрирование
это отдельный разговор, там у нас будет десяток дополнительных таблиц
не имеющих отношение к подсчету пакетов.

Надеюсь это немного прояснит ситуацию с тем, что предстоит сделать. Хотелось бы увидеть и Ваши предложения/пожелания по каждому из вопросов. Пока еще дело не зашло слишком далеко можно смело менять подходы ко всему. Потом же это будет сложно сделать. И снова придется разрабатывать все "с нуля".

Точка подключения пользователя

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

Применительно к локальным сетям описание точки подключения может быть, например таким "свитч NNN, порт MM". К дополнительным данным можно отнести режим работы и скорость порта, номер vlan, активизирование защиты и т.д.

Данный подход к описанию технической части в биллинговой системе имеет большой ряд преимуществ. Самым большим из них, несомненно является - полное документирование сети. Для ввода точек подключения в биллинг Вам придется сначала создать список сетевых устройств с их параметрами. При наличии такой информации техническое обслуживание сети заметно упростится. Если вдруг у пользователя возникают проблемы, то вы в мгновение получите всю исчерпывающую информацию о его подключении.

Вторым достоинством заведения всех точек подключения является автоматизация управления и мониторинга. Большинство современных сетей перестает пользоваться простым неуправляемым оборудованием (хабы и простые свитчи), часто начинает использоваться управляемое оборудование с возможностью снятия статистики и управления через SNMP, Web или Telnet. При наличии полной информации обо всех портах сети можно создать программу наблюдения за их состоянием, например подключен ли сейчас компьютер пользователя к сети или нет. Так же можно автоматизировать блокировку портов пользователей, которые не оплатили услуги.

Так вот для реализации "точки подключения" сначала требуется создать список сетевых устройств. Первой таблицей будет список типов устройств (device_types):

• id - (целое без знака) - идентификатор типа устройства;
• name - (строка) - название типа устройства (кодовое имя);
• config - (строка) - описание списка параметров конкретного устройства (например, ip адрес, логин и пароль администратора, количество портов и каких-либо модулей и т.д.);
• config_user - (строка) - описание списка параметров устройства для конкретного пользователя (например, порт пользователя, скорость и режим работы и т.д.);
• description - (строка) - дополнительная информация о типе устройства (например производитель и модель);
• create - (дата и время) - дата создания записи;
• modify - (дата и время) - дата изменения записи;

При помощи этой таблицы можно создать список всех типов устройств применяемых в сети, например, свитчей, хабов, точек радио-доступа, модемных пулов, маршрутизаторов и т.д. При этом список параметров устройства config задает в специальном формате набор параметров отдельного устройства, а список config_user определяет настройки этого устройства (его частей) под каждого пользователя. Я еще до конца не решил, нужны ли поля config и config_user. По идее, для работы с каждым типом устройства нужна отдельная программа (модуль биллинговой системы), которая знает в каком формате получить данные из устройства. Набор необходимых параметров может быть зашит в эту программу и тогда поля осписывающие набор параметров config и config_user не нужны.

Теперь собственно и сам список устройств в сети (devices):

• id - (целое без знака) - идентификатор устройства;
• type_id - (целое без знака) - идентификатор типа устройства;
• config - (строка) - настройки устройства в соответствии с типом;
• state - (строка) - состояние устройства в последний момент получения информации о нем;
• location - (строка) - местоположение устройства (например, адрес дома и этаж)
• description - (строка) - дополнительная информация об устройстве (например, особенности установки устройства или местоположения)
• create - (дата и время) - дата создания записи;
• modify - (дата и время) - дата изменения записи;

Данная таблица будет описывать все устройства в сети. Здесь наиболее важными полями являются config и state. В этих полях содержатся данные необходимые для работы с устройством. Формат этих полей можно пересматривать и пока не будем на нем зацикливаться, это поле просто текстовое. Для того, чтобы Вы поняли, что это такое, приведу пример для нескольких сетевых устройств. Представим себе, что у нас в сети успользуются управляемые свитчи двух типов с настроенными IP адресами. Один тип свитчей может объединяться в стек, а другой нет. В таком случае:

1 свитч:
 type_id = 1
 config = "ip=192.168.10.1;login=admin;password=manage"
 state = "port1=on,10mb,half;port2=off,100mb,full;port3=on,10mb,full;port4=on,100mb,half"
2 свитч:
 type_id = 1
 config = "ip=192.168.10.2;login=admin;password=qwdareq"
 state = "port1=on,100mb,full;port2=off,100mb,full;port3=off,100mb,full;port4=off,10mb,half"
3 свитч:
 type_id = 2
 config = "ip=192.168.10.3;unit=1;mode=stack;login=manager;password=unit1"
 state = "330111311112313301113001"
4 свитч:
 type_id = 2
 config = "ip=192.168.10.3;unit=2;mode=stack;login=manager;password=unit2"
 state = "130131110133111001330133"

В данном примере Вы видите два типа свитчей с различными параметрами и методами хранения статуса портов. Свитчи типа type_id=1 имеют 4 порта, а свитчи типа 2 имеют 24 порта, статусы которых представлены в виде числовых значений от 0 до 3 (например, 0=on,10mb; 1=off,10mb; 2=on,100mb; 3=off,100mb).

При разработке модулей, осуществляющих конроль устройств Вы будете сами определять для себя набор необходимых параметров config и формат хранения статуса status.

После определения списка устройств нужно создать таблицу подключений пользователей к сети (connections):

• id - (целое без знака) - идентификатор подключения;
• user_id - (целое без знака) - идентификатор пользователя;
• device_id - (целое без знака) - идентификатор устройства;
• config - (строка) - настройка подключения на устройстве для пользователя;
• ctariff_id - (целое без знака) - идентификатор тарифа на подключение;
• period_start - (дата и время) - дата начала отчетного периода;
• status - (перечисление) - статус подключения (например: ON, OFF, BLOCK);
• create - (дата и время) - дата создания записи;
• modify - (дата и время) - дата изменения записи;

Тут несколько интересных полей. Первое поле это config, в нем хранятся настройки устройства для данного подключения. Допустим, если это подключение к свитчу, то например значение этого поля может быть таким "unit=3;port=10;speed=100;mode=FD" или в сокращенном виде "u=3;p=10;s=100;m=fd" (формат можете придумать сами).

Второе важное поле - это ctariff_id, оно задает тариф на подключение. Возможно, кому-то это поле покажется не нужным, но во многих организациях принято брать ежемесячную плату просто за доступ к сети, не включая трафика, который оплачивается отдельно или не оплачивается вообще. Для этого следует определить набор тарифов, чтобы биллинговая система знала сколько списывать средств со счета. Начало отчетного периода задается датой period_start.

Для того, чтобы определить состояние подключения существует поле status. По состоянию подключения можно судить об его "оплаченности", т.е. ориентируясь на это поле биллинговая система будет производить списание денег. Основные значения этого поля следующие:

• ON - рабочее состояние, осуществлять списание средств по тарифу;
• OFF - нерабочее состояние (можно даже считать в процессе регистрации);
• BLOCK - заблокированное или временно выключенное, списание средств не производится;

Я думаю это далеко не все возможные варианты, поэтому думайте, что можно еще туда запихнуть.

Ну и, так как мы связались с тарифами на подключение, то создадим такую таблицу (ctariffs):

• id - (целое без знака) - идентификатор тарифа для подключения;
• name - (строка) - название тарифа;
• price - (строка) - цена списываемая за отчетный период (название функции в модуле);
• period - (целое без знака) - отчетный период в часах;
• options - (целое без знака) - опции тарифа на подключение;
• description - (строка) - описание тарифа;
• create - (дата и время) - дата создания записи;
• modify - (дата и время) - дата изменения записи;

Здесь все должно быть ясно. Основные поля price и period, задающие цену и частоту списывания средств со счета. Интересно подумать над полем задающим цену, потому что под все желания подстроиться не возможно, так как цена может изменяться от времени суток, дней недели, от скидки и т.д. Поэтому я думаю поле price должно содержать не конкретную стоимость, а название функции расчета стоимости, которые будут собраны в отдельном модуле. Тогда можно будет расчитывать стоимость услуг по достаточно сложным алгоритмам, не зависящим только лишь от цены. В связи с этим нам еще предстоит решить какие параметры стоит передавать в функцию расчета стоимости, это может быть дата регистрации пользователя, количество денег на счету, размеры скидок и т.д. Возможно проще передавать просто набор ссылок на структуры описывающие пользователя в режиме чтения.

Для ограничения использования тарифов, создадим таблицу привязки тарифов и групп пользователей. Тогда можно будет для каждой группы пользователей ограничить набор доступных тарифов на подключение. Такая таблица может выглядеть вот так (ctariff_group):

• group_id - (целое без знака) - идентификатор группы;
• сtariff_id - (целое без знака) - идентификатор тарифа на подключение;

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

Также создадим таблицу истории изменения тарифов на подключение (ctariff_history):

• ctariff_id - (целое без знака) - идентификатор тарифа;
• date - (дата и время) - дата внесения изменения;
• code - (целое без знака) - код выполняемой операции;
• value - (строка) - значение параметра операции;
• old_value - (строка) - старое значение обрабатываемого поля;
• admin_id - (целое без знака) - идентификатор администратора, внесшего изменения;

Таким образом любые изменения тарифов на подключение будут отражены в таблице истории.

Количество подписчиков: 

Выпуск подготовил: Кузин Андрей (kuzinandrey@yandex.ru)