Hi, All!


Где можно можно почитать об архитектурах построения высокопроизводительных биллингов для операторов связи?

Я работаю в ISP и являюсь одним из авторов нашего биллинга. По функциональности он нас устраивает, но есть проблемы с производительностью. Чувствую, что с ростом числа клиентов наш биллинг начнёт загибаться.


Сейчас это построено по следующей схеме:
есть сервер, собирающий данные о сессиях клиентов (RADIUS)

сервер БД (Oracle) хранит данные о сессиях клиентов, их счета и т.п.

рабочие места операторов, с которых заводятся/удаляются клиенты, производится рассылка счетов и т.п.

RADIUS принимает данные о сессиях клиентов из сети и преобразовывает их в удобную для дальнейшей обработки хранимой процедурой форму, затем передаёт эти данные в БД. Вся бизнес-логика реализована в виде хранимых процедур (бизнес-логика достаточно сложная, куча проверок на пускать/не пускать пользователя, кучерявые тарифные планы, роуминг и т.п.). Реализован hot-billing (т.к. большинство тарифов - prepaid): сессия клиента обсчитывается сразу по её окончании. Сам RADIUS ресурсов практически не потребляет, а вот Ораклу плохо -- загрузка процессора всегда 99-100%. А нам важна скорость обработки клиента (чтоб человеку не приходилось ждать по 10 секунд прохождения аутентификации при доступе в сеть). Оракл уже тюнинговали, железо достаточно приличное 2хP3-1,2GHz, диски SCSI.


У меня складывается такое впечатление, что у нас где-то допущена архитектурная ошибка и строить это надо было несколько иначе. Например ввести буферную лёгкую базку (типа MySQL) для хранения оперативных данных ("сырые" данные для последующего обсчёта) и данных по клиенту, достаточных для его быстрой аутентификации. И отдельную базу для собственно биллинга (проведения всех необходимых расчётов по сырым данным), печати счетов и т.п. Эти базы разнести по разным машинам и обеспечить между ними синхронизацию необходимых данных. Мы даже готовы поступиться hot-billing-ом (хотя и не хотелось бы), но чтобы завершившиеся сессии обрабатывались с задержкой не более скажем 2-х минут. Желательно, чтобы у клиента не было возможности вылезти в отрицательный баланс.


Где обо всём этом можно почитать?


P.S. Где-то читал короткую заметку, что одна российская компания написала для оператора сотовой связи с несколькими миллионами клиентов биллинг с hot-billing-ом (в качестве БД - Cache). Удивляюсь как им это удалось реализовать при таком количестве клиентов. Не думаю, что там только дело в БД и мощном железе.

QuarkЧто-то мне кажется что
автор2хP3-1,2GHz
это все таки слабое железо.
Взять например начинающий провинциальный МТС, дык они сразу начинают с 4-х процессорного Sun большой оперативкой только под биллинг(не считая прочих серверов для роумеров, смс, стандбаев и прочего).
И при том что им на такой конфигурации не разрешают делать Hot billing,
под hot отдельное железо.

Garya
Железо действительно слабоватое. А InterSystems (поставщик Cache в России) хвастается, что установка СУБД Cache увеличила производительность по биллингу в 4 раза, и сравнение идет именно с ORACLE. Может быть, действительно имеет смысл с ними связаться?



Не, это всё экстенсивные пути решения :-) Хотелось прежде всего улучшений в идейном плане.

1777, а где именно в Oracle у вас тормоза? На каких именно операциях?

Основные тормоза начинаются при обработке пакетов окончания сессий. Немного информации из предметной области: наша система обрабатывает три типа RADIUS-пакетов
Access-Request - запрос пользователя на вход в сеть. Тут мы проверяем числится ли вообще у нас такой пользователь, есть ли у него деньги на счету, откуда он заходит (из нашей сети или пользуется роумингом), можно ли ему заходить в данный момент времени, предоставлять ему callback и т.д. и т.п. В конечном итоге мы принимаем решение пускать его или нет, плюс переводим его деньги во время, которое он может находиться в сети. Вес этой операции примерно 2-3 балла.

Accounting-Request-Start - свидетельствует о том. что пользователь вошёл в сеть. Это довольно лёгкая оперция с весом 1.

Accounting-Request-Stop - свидетельствует об окончании сессии. При этом мы получаем реальную длительность сессии, пересчитываем время в деньги, обновляем баланс пользователя и т.п. Это самая тяжёлая операция, весит 5-6 баллов.

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

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

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

Вобщем такие дела.

mvА вот в Германии такая система вообще на InterBase. И, говорят, тянет.

А что за оператор и сколько там юзеров?

Whateva 777ogAccounting-Request-Stop - свидетельствует об окончании сессии. При этом мы получаем реальную длительность сессии, пересчитываем время в деньги, обновляем баланс пользователя и т.п. Это самая тяжёлая операция, весит 5-6 баллов.


Вам действительно необходимо TDR в CDR переводить на лету? Может лучше это отложенным batch'ем обрабатывать?


Нашёл в гугле, что CDR - это Call Detail Record, а TDR - Transaction Data Record. Если Вам не трудно, Вы могли бы объяснить, что обозначают эти термины?


Если я понял Ваш вопрос правильно, то имеется в виду нужно ли нам в реальном времени переводить время в деньги по окончании сессии? Вобщем-то говоря это очень желательно, т.к. большинство наших услуг являются предоплачеными и надо не дать пользователю возможности влезть в отрицательный баланс. Скажем если обсчёт завершившихся сессий будет отложен на 5 минут после окончания сессии, то мы либо должны запретить пользователю заходить в течение этих 5 минут (что не устроит пользователей, т.к. есть такие, которые "звонят в интернет" только чтобы проверить почту каждые 2 минуты с длительностью сессий по 40 секунд), либо его пустить и тогда он будет висеть в сети столько, сколько ему захочется (отключить мы его не можем, вернее можем, но не все наши сервера доступа позволяют это делать).

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

Whateva GaryaСудя по всему, к таблицам, в которых вся эта бодяга находится, прицеплены индексы. Возможно, даже много индексов. Они ускоряют выборку, но замедляют обновление информации.


Автор меня конечно поправит если я не прав, но только неадекватный проектировщик будет индексировать колонки балансов (а именно они и обновляются).


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

Garya подал очень хорошую идею с разделением данных на оперативные и статические. Надо только подумать как впишется разрезание SessuionLog-a в нашу бизнес-логику, нам надо просматривать SessuinLog полностью например для показа статистики пользователю, возможно ещё в нескольких местах. Вобщем надо будет подумать на эту тему.

Whateva2 777og

Вы вообще как тьюнингом занимались? На что смотрели-то? STATS Pack'ом пользовались?

Не могу сказать, т.к. я не ораклист. Тюнингом занималась наша DBA, с помощью чего она собирала статистику я узнаю завтра. Надо будет самому почитать что на эту тему советует оракловая документация. Если Вам не трудно, то посоветуйте чем лучше пользоваться и на что обращать особое внимание.


Я вот сейчас проверяю хорошо ли стоится нашему ораклу. Активного обмена со свопом нет, да и своп не сильно занят, значит памяти ему хватает. Смотрю iostat-ом распеределение дисковой нагрузки по дискам и разделам. Есть некоторый дисбаланс между дисками: за период в 10сек по одному диску 20 wsec/s, по другому 8 wsec/s при скорости записи 10 vs 3 kb/s. Это можно поправить, но IMHO это не очень большая нагрузка на диски (там SCSI Ultra 160, к тому же на удивление мало чтений, неужели всё в памяти крутится?), так что если я сбалансирую диски, то всё равно сильно ему не полегчает. При этом загрузка процессоров довольно высокая 70-100%

Whateva
CDR - грубо говоря результат сессии/звонка (т.е. какой клиент, куда, когда, сколько и т.п.). Одна запись на сессию/звонок. По ним балансы обновляют.
TDR - это как проходила сессия/звонок (то что Вы получаете с Radius'а насколько я понимаю). Как минимум две записи (начал, закончил) на сессию/звонок. По ним формируются CDR.


Понял, спасибо.

Whateva
Т.е. я предложил рассмотреть построение в очередь запросов на формирование CDR (и соответственно обновление балансов) из TDR (и при возможности разнести их). Риск пустить клиента в минус конечно при этом есть, но Вы же как-то и сейчас проверяете возможные "проблемные" сессии (типа баланс на 5 минут а он висит уже пол часа), не так ли?

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

mv
- Deutche Telecom. На одном серваке примерно по 200 одновременно работающих (конкурирующих) юзеров. Естественно, транзакции очень короткие.


Биллинг Deutsche Telecom-а работает на Интербейзе? Вот это да! А ссылочку можно? А то я потыкался в гугле и по словам 'Deutsche Telecom Interbase billing' ничего подробного не нашёл.

mv
ABACS - там описана архитектура комплекса. И, кажется, демка есть.


Спасибо, посмотрю.

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



Вобщем мы пока решили разделить SessionLog на две части - оперативную и "статическую". Оперативный SL будет неиндексируемым (т.к. в него будут частые инсерты и он будет небольшим), а статический проиндексируем (у него большой объём и из него производятся частые выборки, обновляться он будет редко). Может ещё выиграем что-нибудь за счёт тюнинга. Ещё мне подсказали, что 9-ый и 10-ый ораклы умеют перекомпилировать пакеты в нативный код, это ещё может дать какое-то ускорение.

Если высвободившихся ресурсов будет достаточно, то организуем репликацию на другую машину всех таблиц кроме "горячих" (с оперативными данными, таких должно быть немного. Данные из "горячиех" таблиц будут ночью (во время минимальной нагрузки) переноситься в статические таблицы. Репликация должна будет позволить перенести печать отчётов, счетов, выписок и т.п. на другую машину и тем самым ещё больше разгрузить основной (авторизующий) сервер.

Вот такие предварительные соображения. Ещё накачал статей с http://citeseer.ist.psu.edu может ещё из них удастся почерпнуть каких-нибудь идей.

Wireless2 777og:
1. Какая реальная нагрузка на ваш сервер - сколько запросов на авторизацию/минуту,
сколько accounting-запросов/минуту ?
2. Можете дать краткие характеристики самых тяжелых таблиц, к которым обращаются ваши SP в момент авторизации? Информация вида - размер на диске, число записей, число индексов, наличие триггеров и пр.


1. Померял за 30минут: получается около 20авторизаций/минуту и 34 акаунтингов/минуту (без разбивки на старт/стоп). Но это не показательная статистика, т.к. народ сейчас действительно вяло работает - отпуска, каникулы и т.п. Сервер сейчас загружен где-то только наполовину.

2. Из больших таблиц в аторизации учавствуют SessionLog (~600тыс. записей) - в основном выборка/обновление/вставка, user_totals (~160тыс.) - в основном выборка/обновление, таблица юзеров (~30тыс.) - в основном выборка. Деталей по поводу размера на диске, триггеров и индексов, честно говоря, не знаю. Выяснение деталей у нашего DBA имеет свои м-м-м, скажем так, свои сложности.

Даже глядя на эти цифры (пускай даже если их и умножить на 3) видно, что объёмы не очень серьёзные. И реального прироста производительности можно добиться, как правильно заметил Aion простыми вещами типа грамотной организации данных, индексов и т.п. Осталось в этом убедить нашего DBA :-)

AionВсем привет.

2 777og
Те данные, которые Вы тут привели (характуристики системы, железо и т.д.), наводит (точнее доводит) мои мысли до следующего:
- та техника, что у Вас имееться должна справляться с поставлеными задачами
- большие проблемы не толко в организации данных но и в их обработки


Согласен. Будем исправлять.

Aion
А вообщето неплохо бы посчитать стоимость одной единицы.
Т.е. сделать некий простой тест, который Вам даст результаты (сурогатные) типа: мах производительность, сколько нужно времени для обработки одной единицы (если с системой никто неработает, работают 10/100/1000 пользователей).
Это еще может Вам дать аргумент для админа, типа: "Вот видишь, наш Oracle обрабатывает 1 request в секунду!!! Если в системе будут 100 пользователей, то 100-й пользователь будет ждать антификации 40 секунд!!!!" :-))))


Вот по этому поводу я и думал. Хочется вокруг нашего биллинга построит систему мониторинга, отображающую качество обработки поступающих запросов. Я имею в виду следующее:
скорость обработки одного запроса (Dt) - время между приходом пакета на интерфейс и уходом пакета с ответом на пришедший запрос. Можно получить Dt_auth, Dt_start, Dt_stop. Dt_auth имеет смысл разбить на Dt_accept и Dt_reject, т.к. Reject пакеты имеет смысл задерживать (увеличивать Dt_reject) намеренно для защиты от флуда пакетами н.п. с подбором пароля, а борьба за минимизацию Dt_accept для нас имеет очень важное значение :-) Аналогично с Dt_start и Dt_stop, они являются показателями качества алгоритмов обработки и настроек базы, с одной стороны, и позволяют правильно выбрать время для ретрансмита пакетов на серверах доступа с другой стороны.

количество поступивших на обработку пакетов (N_access, N_start, N_stop) - с этип понятно.

некую относительную характеристику (dt_accept, dt_start, dt_stop) - аналогичную первой, но учитывающую количество поступивших запросов.

Имеется в виду следующее: если к нам поступает 3 пакета в течение 3 минут (DT = 3 мин) с интервалом в 20 секунд, то даже на самом хилом железе и на криво настроенной базе мы их сможем обработать с Dt_accept = 1сек. Если к нам за DT=3мин приходит 30 пакетов, то мы их можем обработать скажем за Dt_accept = 1,5сек, в случае 300 пакетов Dt_accept = 5сек. Поскольку DT=const, хилость_железа=const, то полученные Dt_accept(300) - Dt_accept(3) = 5 - 1 = 4 сек являются показателем неадаптированости алгоритмов обработки и настроек базы к данной нагрузке (чего нам собственно говоря и хочется узнать). Смотреть на график Dt_auth(t) и совмещать его с N_auth(t) неудобно, поэтому хочется относительную характеристику dt_accept(t) и аналогичные ей. Только я не могу придумать как её определить.


количество необработанных запросов (N_access_dropped, N_start_dropped, N_stop_dropped) - количество тех пакетов, на которые сервер вообще не ответил.

По полученным данным можно потом ещё строить гистограммы/распределения вида:
- количество обработанных запросов N за определённый Dt. В идеале эти распределения должны иметь вид дельта-функций :-)
- Dt от количества запросов и т.п.

Может мне не стоит изобретать велосипед, и уже есть ряд ТТХ, характеризующих подобные системы? Где об этом можно почитать?

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