NiTr0

Микбилл, писаный на пхп. Абиллс (который весьма недавно обзавелся транзакциями, и то - лишь местами, а foreign ключи до сих пор то ли в todo, то ли в "нафиг нужно"). Думал, вы угадаете продукт из описаных "особенностей реализации". Вы какбы сами впряглись, я вас не тянул и ваш биллинг вообще не упоминал. А раз зацепило - очевидно, есть на то причина. Я вашего проекта какбы не видел (и не присматривался к нему), и конкретно о нем не говорил. Я говорил о других околосетевых проектах. Как опенсорсных, так и платных (в т.ч. довольно дорогих типа ned2).

SATA винт легко вытягивает до 200 иопс на БД порядка гига объемом. При 40-50 иопс винт гуляет. А это, при грамотном тюнинге, порядка 40 операций insert/update в секунду. Или же, при интервале аккаунтинга в 1 минуту, порядка 1500 сессий онлайн. Т.е. абонбаза порядка 3к. Т.е., до 150 иопс можно не напрягаться, тазик с парой десктопных 7200 об/мин винтов вытянет 10к абонбазу легко, и не скукожится во время репликации. Далее, при репликации выгребается один кусок бинлога, блоком максимального размера (сколько там - 2к секторов? или больше?), и даже если будет 20 конкурирующих запросов со средним размером блока в 5-7 секторов, бинлог будет вытягиваться весьма шустро. С какой такой радости? Размер нашей БД биллинга за 5 лет работы всего 2.7 гига. База естественным образом поднимается в кеш, и из кеша работает. Оперативные данные, типа детализированного аккаунтинга сессий, ессно, периодически удаляются. Если же у вас база намного больше оперативной памяти - flashcache в помощь. Из допущения, что дисковая подсистема должна быть всенепременно загружена на 101%, делается вывод о неприспособленности СУБД к отказоустойчивой работе. Занятно...

Скажите, адекватный разработчик будет писать биллинг, включая резидентное ядро, на php, у которого кривой сборщик мусора, а утечки памяти - нормальное явление? А может, биллинг без foreign ключей в БД и без транзакций (ну подумаешь, деньги снялись а услуга забыла активироваться т.к. СУБД лагонула) - это нормально? Не, оно работает, почти без проблем, но... Ну я к примеру почти всегда вижу в своих проектах спустя год-другой (не говоря уже о большем времени), что можно было сделать иначе, немного (или намного) лучше. И если проект актуальный - не стесняюсь уделять время на рефакторинг. Банально потому, что не бывает идеального кода. И да, требования к функционалу никоим образом не могут однозначно определять архитектуру системы. От того - сдается мне, что вы сильно лукавите... Ну что ж, мериться так мериться. Да, мой опыт несколько поменьше вашего, всего каких-то лет 15, но за это время писал на разных языках (это и асм, включая х86, 8051, AVR, и паскаль/делфи, и С/С++ включая Qt framework, голое WinAPI, RTOS, эксперименты с драйверами ядра и модулями нетфильтра linux, и перл, и питон, и чуток тикля, и яваскрипт, ну и шеллскрипт ессно - не тянуть же в embedded перл/питон), начиная от небольших утилит/библиотек оканчивая скада-системами. И да, чем дальше, тем больше я убеждаюсь, что лучший код - не написанный. Т.е., чем больше юзается адекватных популярных библиотек/фреймворков на замену собственноручно писаным велосипедам, тем легче поддержка кода в итоге, и легче разработка. Особенно - если к разработке придется привлекать еще кого-то. И да, если из кода без комментариев на высокоуровневом языке стороннему человеку непонятно, что сей код делает хотя бы в общих чертах - значит, код написан плохо. А если при попытке понять логику салата вскипает мозг - тогда появляется лютое желание плюнуть и написать все с нуля, пусть и убив несколько месяцев.

Мы здесь не мериться собрались какбы. О вашем опыте программирвания мне судить сложно, но, думаю, не от хорошего качества кода и грамотного проектирования системы в нодени кое-кто из присутствующих перепиливал ядро наполовину... Темплейт энжины обычно обладают обратной совместимостью... Вы пробовали переделать ЛК под конкретный скин? Не-не, не сменить стиль текущего ЛК, а изрядно его перелопатить, слив часть пунктов меню на одну страничку, часть - исключив, часть - урезав наполовину? Когда часть кода генерится темплейт энжином, часть - хранится в темплейтах (в порядке вывода которых черт ногу сломит), часть - вообще генерится в смеси логики с выводом (index.cgi + modules/*/webinterface)? Я вам привел пример того как по-хорошему должен выглядеть код. Отдельно - работа с БД (с некоторым ф-ями логики, которые невозможно отделить от скл), отдельно - логика (разбитая на минимальные самодостаточные ф-и вместо полотен кода), дергающая ф-и работы с БД и полностью абстрагированная от скл бэкэнда, отдельно - веб-интерфейс, чья задача лишь дернуть вызов некой ф-и, и отрисовать на шаблоне возвращенный результат. Рассказал и о прифите этого, в виде более быстрой разработки, уменьшения дублирования кода и т.п. Причесал до подобного вида даже набросок биллинга для сети хотспотов и выложил в качестве примера. То, что вашу систему нужно будет наполовину переписывать, убирая мешанину кода бизнес-логики и генерации веб-странички, писаную в лучших традициях php-салата - само собой разумеется. Что это займет немало ресурсов - тоже понятно. Стоит это того или не стоит - решать вам. Но в текущей системе, по-моему, даже вы уже теряете контроль над кодом...

Открою ОГРОМНЫЙ секрет. Включение отдельно стоящей общаги обойдется значительно дороже 1-2к грн. Если, ессно, не медью/вафлемостом включать, и не б/у мыльницы ставить. Потому не надо баек о долгом отбивании дополнительных 1-2к грн - на фоне 10-20к грн затрат это не так и много. И да, 1-2к грн комменданту с головой покроются первым же взносом новоподключенных. А по поводу "5 роутеров на 5 этажей" - прекращайте рассказывать сказки. Роутеры не умеют балансировать скорость, в итоге качок Вася никак не уживется с геймером Петей на одном роутере.

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

Не брезговать проектированием и обдумыванием структуры вместо разработки "снизу вверх" (проект, вырастающий "сам собой" из кнопки - конечно, просто и интересно, но в какую сторону он вырастет и что с ним спустя пару лет делать - вопрос), и не стесняться рефакторинга вместо налепливания костылей. Код надо писать понятно и без грязных хаков в погоне за 0.5% производительности в редких ситуациях. И по максимуму использовать готовые наработки вместо изобретения велосипедов. Готовые решения весьма часто имеют неправильную архитектуру базы, и порой весьма неочевидные костыли и подпорки в реализации некоторых фич, которые уже успели укорениться и пустить уйму свежих ростков - так что выдирать их эквивалентно переписыванию половины кода биллинга. Отнюдь. Самописный биллинг - точно знаешь, что под капотом и кому давать по рукам за говнокод. Покупной/опенсорсный - тот самый кот в мешке. Оно вроде есть и вроде работает, но где вылезет баг - неведомо, а как захочется прикрутить что-то свое, но тесно завязанное с основным функционалом (ну, например, коэффициенты стоимости для групп пользователей, дабы ограничиться десятком базовых тарифов вместо 100500 тарифов из 100500 групп, да или хотя бы банально разделить учетную запись доступа и персональный счет клиента, для возможности гибкого управления сервисами, не превращая одинокого клиента в корпорацию) - так и наступит горькое прозрение... Впрочем, это освсем не значит что сразу же надо бросаться с шашкой наголо на написание биллинга. Гораздо полезнее будет наесться кактусов на каком-то готовом решении. В противном случае - результат скорее всего будет грустным и печальным, с той же горой костылей и врожденными уродствами дизайна, несовместимыми с полноценной жизнью за пределами строго очерченных в момент разработки реалий.

Присмотрелся конкурент к общаге. Увидел всю идиотичность запретов (которые аццки драконят пользователей), отлистал комменданту скажем 1к-2к грн с уговором листать столько же сколько и действующий пров ежемесячно, сделал акцию "подключись и получи в подарок роутер" - и за месяц ВСЯ общага стала его. Тихо, мирно и без шума. А по части пионернетов - если сильно страшно, делайте лимитированные тарифы. Посмотрите потребление среднего юзера, умножьте на 1.5, и поставьте лимит. Либо - пакеты 100 мбит с лимитом по трафику, от 10 гигов до 1 ТБ, с разными расценками. И будет счастье всем - и студентам, и прову.

В таком случае - либо тянуть свой форк, либо таки плюнуть и написать свой биллинг. На том же джанго это будет довольно быстро, и по потреблению ресурсов достаточно гуманно (во всяком случае, какой-то i5 думаю вполне вытянет порядка сотни-другой запросов в секунду на радиус/морду без особого напряга). А натягивать морду/реализовывать аякс либо RPC через джанго - одно удовольствие, никаких страшных велосипедов, все искаропки. Да и, если честно, синтаксис питона поприятнее, чем перла (сложнее ошибку сделать, да и легче дебажить ошибки)...

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

Почему же. С мастера на слэйв перешлются только бинлоги. Слэйв же их потом накатывает на свою базу.

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

Да какбы написать не проблема. Не так уж и сложно должно быть. Если не осилите сами - могу помочь (ЛС).

Если бы мой пров ввел такую "услугу" и сделал ее неотключаемой - я бы его нахрен сменил бы...

В общем - да, но гораздо спокойнее если железки 3. Причем третья - какая угодно, чисто для кворума. Вообще-то есть полусинхронная. semi-synchronous. В рамках кластера из 2 мускул нод - разницы по сравнению с синхронной не будет. В рамках кластера из N нод - да, придется по отвалу мастера делать выборы слэйва. Зато быстро, мастер не тупит в сторонке пока самый неторопливый слэйв подтянет транзакцию... С какой радости? Посмотрите перкону, вроде как все автоматически делает. И старый мастер, вернувшийся в строй, синхронизирует со слэйвом, и т.д... Единственные грабли, которые могут всплыть - это если мастер работал, потом умер, потом слэйв встал мастером, работал, потом умер, потом подняли обе ноды - и старый мастер стал новым мастером, и все данные с момента его останова похерились... Но это - редкий форс-мажор. Софтовый рэйд к кластеризации никакого отношения не имеет. Да и бекапы - тоже конечно полезно, но не заменят кластер. Как и кластер не заменит бэкапы.

Вот та вот китайская коробочка и есть самый что ни на есть NAS. То вы с SAN попутали. Да затем, чтобы на втором тазике была актуальная комия БД, а не недельной давности. И точная, а не приблизительная. Угу, а сдохнет хранилище (или вы считаете, что там БП качественнее, чем в сервере?) - ляжет все... Не занимайтесь техноонанизмом, включите мозг и почитайте о отказоустойчивых кластерах и репликации. У мускула с этим все вообще прекрасно (percona replication manager для heartbeat к примеру годная вещь), у постгри - похуже, но в принципе жить можно.

Насколько хорошо? Уже достаточно хорошо для того, чтобы привести хотя бы хендбук в актуальное состояние (там до сих пор natd указан в качестве рекомендованного ната - хотя его еще лет 10 назад надо было бы убить, закопать и забыть то место где закопан), или все еще недостаточно? Или, может, наконец-то запилят какую-никакую виртуализацию (только не надо говорить, что джейлов хватит всем и для всего)? А вообще - поднимать биллинг стоит прежде всего на той системе, которую знает админ. Во вторую очередь - ориентироваться на наличие специалистов по оси в пределах досягаемости (тут у бсд все печально - по большей части присутствуют эникеи с завышенным ЧСВ ввиду нераспространенности бзди). В третью очередь - на мануалы и т.п., ибо поднятие биллинга на бзде отличается от поднятия на линуксе разве что названиями устанавливаемых по зависимостям пакетов, да путями конфигов. И дистрибутивы лучше выбирать более серверные (как по мне - дебиан или центос), не убунту. Благое дело, у привыкшего к убунте не будет проблем с дебианом.

Угу, как-то. Как - сравните на одном и том же железе пропускную способность. Разница раз в 20-50 будет на нате скорее всего. А кому оно нужно, кроме мелких домосетей и офисов? Кто в здравом уме Ну так напишите юзер-фриендли биллинг, или упакуйте какой-то опенсорс, делов-то. Задолбаетесь только потом объяснять дипломированным сантехникам, переквалифицировавшимся в сисадмины, объяснять, какую галочку где поставить. У меня, при месячном опыте эксплуатации линукса на домашнем тазике, почему-то хватило знаний прочитать документацию и развернуть абиллс в течение нескольких дней. Если эникей не умеет читать документацию - это его и только его личное горе. Надо будет биллинг - эникей должен либо поставить опенсорс, либо оплатить услуги установки решения. Покупать закрытую, нерасширяемую и немасштабируемую коробку будет разве что камикадзе, не совсем дружащий с мозгом. Ибо шаг влево/шаг вправо от функционала, заложенного автором - или невозможен, или стоит очень дорого. А когда трафик сквозь сию коробку упрется в полку - тут и наступит горе...

И получить немасштабируемую, нерезервируемую какашку, пригодную только для эксплуатации в офисе или пионернете на 500 хомяков от силы... Никогда не задумывались, сколько лучей поноса пошлет каждый хомяк горе-админу, поставившему такой комбайн, в случае его падения? А что случится с биллинговой частью, крутящейся в юзерленде, если 100% времени займет ядро с обработкой пакетов (ну, там, новый юторрент вышел с поломанным в очередной раз ютп, или десяток машин в сети заразились червячками и начали масштабный ддос мелкими пакетами через ваш биллинг-роутер-кофеварку)?

Пиленный на коленке мульти-мастер кластер СУБД? А как у него с транзакциями-то? Синхронной-то репликации у вас нет, а асинхронная мастер-мастер - грусть и печаль по части рассинхронизации данных нод. О периодических заданиях - помолчу (на каком из биллингов выполнять их, и как резервировать?). NAS - network attached storage имелось ввиду. Да и странный выбор - дешевая сохо железка... Понимаю, какую-то дисковую полку-SAN скзевую по дешевке взять рекомендвали бы, а так... Репликацию СУБД настроить религия не позволяет?

Нет никакой заточенности. Поднимается и работает на чем угодно. Уверен, и под виндой можно при должном желании и упоротости упорности заставить работать - перл и фрирадиус есть. Нет и не надо. Задача биллинга - учет и авторизация. Остальное - задача браса/файрвола/шейпера/прочего. Вы же не требуете от стиральной машины функций кофеварки? В мелких сетях таки правит бал PPPoE/PPTP. Банально потому, что не требует управляемого железа и не требует системы управления тем самым железом. А если руки ровные - то и accel-ppp/реализации isg прикручиваются элементарно, небольшой правкой кода. Причем - полноценный IPoE, с возможностью выдачи белых динамических адресов. А привязка юзер-мак-ип - это уже в общем-то и нафиг никому не нужно. У абиллса проблемы в другом, но среднестатистического юзера они скорее всего не коснутся. Проблемы - под капотом, и касаются в основном тех, кто решает что-то под себя пилить.

Падает сохо нас, скукоживается вся сеть + битая БД бонусом (кеш записи)...

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

Да сколько угодно. Температурный режим стабилизируется в течение максимум получаса. Врезал кулер в морду. Там его вообще нет.

А чего ему гореть если он в нормальном режиме свой ток выдает часов 12? Заряднику пофиг, сколько емкости вливать... Другое дело - при разряде угреться могут ключи, но принудительное охлаждение вполне справляется. Сами так BNT600/BNT800 переделывали.