NiTr0

flashcache лучше развалится ссд - не страшно.

а я понял, что вы ничего не поняли. у меня стояла задача свалить с глюкала "isc dhcpd + горка костылей", дабы иметь возможность в реалтайме и логи посмотреть, и ип сменить, не рестартуя сервак и не залазя в дебри парсинга логов. задача решена более чем успешно. то, что вам этого мало - ваши личные проблемы. модуль дхцп к слову из коробки большего и не дает (ну или как минимум года 1.5 назад не давал - биллинг пока не апдейтил, нужды не было, а портировать дифф допиливаний под наши нужды эдак с сотню кб на новый релиз просто так со скуки - смысла не вижу). вы бы как-то определились что ли - невозможна в принципе, или дописать немного логики (добавить в скл запрос АЖ 3 поля из целых 2 таблиц, и провести весьма сложные операции - сложение и вычитание - из полученных значений). и при этом нахрен не надо тащить гору лишней логики, тысячи строк кода. да, дублирование функционала ради выигрыша в скорости (в разы) - но кто виноват, что в абиллсе логика сделана без адекватного предварительного проектирования, с кучей хитросплетений между разными модулями, и при этом равномерно размазана между бэкэндом и фронтэндом вместо выделения в отдельную сущность... не два запроса, а реализация полноценного конечного автомата, с N состояниями (что, к примеру, вы собрались слать в ответ на ACK если перед ним не было Discover? ах да, это не укладывается в 2 запроса, потому игнорим?). и в биллинге для этого не реализовано ни-че-го. и чо, память не текла? у меня радиус 2.1.7 течет, как сука, где-то на пару гигов в месяц. ибо решето дырявое. фиксить, гоняя через valgrind - нунафиг, лучше уж это время потратить на написание чего-то своего, более адекватного. к слову, тривиальный радиус-сервер с pap/chap аутентификацией на перле пишется за 2-3 дня... а, к примеру, мини-биллинговая система для сети хотспотов, с радиусом, с печатю на POS-принтере талончиков (вернее, выдача по хттп запросу кода для вывода на принтер), без веб-морды - за неделю.

мне не нужно было делать проверку баланса и выдачу ип из левого пула - я и не делал. банальная статика, с опцией 82 (которая, впрочем, у нас пока еще не используется). вам надо - допилите, делов-то на 5 минут, элементарно же... а биллинг - как раз таки непосредственное участие принимает. собссно он наполняет базу. 1) опция 82 - нормальная, а не костыль 2) отсутствие необходимости рестартовать сервер (для нескольких тысяч абонов - генерация конфига занимает с полминуты, будет 10000+ абонов - устанете ждать пока конфиг сгенерится) 3) нормальные логи в БД. не через костыль в виде скриптовой прослойки. 4) вообще - вместо скрипта на несколько десятков кб тянуть несколько метров говнокода (вы, к слову, в кишки isc dhcpd не смотрели? зря...) - вообще бредово 5) при любой ошибке в конфиге (к примеру, оператор протупил и неправильно заполнил опцию 82 или вообще не заполнил поля, поставив галку) - ваш дхцп сервер упадет, а вы об этом даже не узнаете пока не пойдет шквал звонков... ну да, ну да, подумаешь - всего лишь написать логику работы дхцп сервера а так - да, все готовое ну и подтянуть к модулю абиллса еще горстку модулей... и да к слову, что-то у меня ни сокеты не падали, ни мускул не отваливался (кстати, в отличие от rlm_perl - там мускул порой отсыхает, пришлось патчевать биллинг для постоянного передергивания соединения с бд при каждой аутентификации), ни прочих приключений не было. аптайм более месяца, все стабильно, 300-500 запросов в секунду выдерживал и не кашлял... а вы можете и дальше на коленке глюкало в виде фрирадиуса лепить...

Да ну? Неужели? Нахрена там радиус, когда дхцп сервер выгребает данные напрямую из мускул БД? Или просто вам хочется усложнить себе задачу? Для статики еще проканает кое-как, хоть и с минусами. Для динамики - нет. Что есть готовое? Как вы реализуете динамически выдаваемые ип адреса из пула? При этом - с полноценной stateful логикой (т.е. - освобождать лизу по тайм-ауту или по release пакету, продлевать по dhcp inform и т.д.)?

Да нормально все с ними в общем-то. Особенно если сервер будет недогруженным. Интенсивное i/o вынесите из виртуалок (к примеру высоконагруженную БД), и будет счастье. Стройте софт-рэйд (в чипсетном контроллере тоже софт-рэйд, но со своими вендорскими тараканами, тупо на другую мать с другим чипсетом винты навряд удастся перенести к примеру, да и как со смарт будет дружить хз). Целесообразность еще одного винта - разве что рази восстановления бекапа после ошибочного удаления базы или файлов. не более. лучше бекапить на какой-то тазик, доступный извне, с толстым домашним пакетом (предусмотреть при этом отказ связи - т.е. попытки бекапа до тех пор, пока тазик не появится в онлайне). Памяти можно и 16 гиг ткнуть, много не бывает.

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

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

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

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

тупой юникаст, скучно...

Юзаем феномы 2. 4-головый феном на ддр2 на терминации пппое + шейпишге до гигабита пережевывает. У интела подсистема памяти шустрее, для траффикомолотилки он предпочтительнее будет.

Угу, нолик лишний.

1. любой онлайновый упс, оснащенный блоком заряда с контролем peak current свой APC я чутка доработал паяльником, но это мой частный случай - здесь батарея большой емкости. Номинальное напряжение ячейки - 1.55В, ЭДС (напряжение полностью заряженной ячейки без нагрузки) - 1.85В. Сколько банок должно быть, чтобы упс их нормально зарядил и в то же время не сдох раньше времени при разряде? Кол-во циклов заряд-разряд, если память не подводит, у них что-то около 40... Для б/у батарей - считайте, они исчерпались. А со свинцовыми автомобильными аккумами я для киловаттной стойки (реальное потребление в ЧНН) имею 4-5 часов автономной работы (4 шт по 1000Ач). Батареи с 2005 года работали, в том году были сменены на свежие, т.к. одна осыпалась... Учитывая, что на 1 Ач в СЦ акке идет 4-5г серебра, для 100Ач 12В батареи нужно 7-8 элементов по 100Ач = 2.8-4 кг серебра. Стоимость серебра как металла можете узнать. Стоимость свинцового акка - около 1000 грн. Сколько новых свинцовых акков вместо 1 б/у серебряно-цинкового того же номинала можно купить - думаю, посчитать несложно.

ИМХО если баксов за 200 уйдет - и то хорошо...

опечтка, сорри.

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

в ирц в уанете в пик популярности вечерами до 7-8 тысяч было. если не больше. сейчас - менее сотни юзеров. на весь юанет. если делать локальный чат - то ставить уже дц++ и пускай в нем чатятся, + юа-икс хабы туда накидать в инсталляху. мир таким образом сэкономите...

Нет фактически. Во всяком случае - не более, чем у обычных АГМ. Пожароопасны при интенсивном кипении, которое происходит при заряде большим током в конце заряда, когда напряжение переваливает за 13.8В. чего в упсах не бывает (ессно, если упс исправен). ну или при перезаряде аккума. При заряде током менее 0.1С (а в случае упса - намного менее 0.1С) до 13.8В - никакого газовыделения практически не происходит. Если свинцовый акк будет кипеть - то гелевый в тех же условиях заряда накроется волосатым органом, и стойка при отключении напряжения остановится... Для начала, прежде чем советовать, найдите ответы на 2 вопроса: 1) какой упс с ними сможет работать и 2) сколько циклов они переживут?

Думается, где-то сопоставимо с V440-м будет. Скорее всего - выигрывая в однопотоке (к примеру, сложный скл запрос), и возможно проигрывая при 4+ активных процессов (нагруженный веб-сервер), а возможно - и не проигрывая... Сравнение по головам. ИМХО - эквивалент 4-голового нетбёрст зиона с частотой эдак 2.2-2.4ГГц на голову, ну или младшего 4-голового зиона на Core архитектуре... 880-й - да, повеселее конечно за счет 48 голов, но 3.2кВт потребление впечатляет Хотя как хай-тек обогреватель - вполне ничо будет, если бы не шум

Ну сделайте у себя более-менее нормальное резервирование + резервное копирование... 1) софт-рэйд на машине с биллингом 2) тазик на каком-то древнем пеньке 3/атлоне(семпроне) 64, с новым блоком питания, и с парой винтиков опять же в рэйде, для бэкапов. Стоимость этого - копейки, гораздо меньше вашей месячной з/п, и на порядки меньше стоимости простоя из-за отказа железа.

Станет. Но это скорее для души, чем для продакшна. А как для какой-то помойки юзать - опять же жирно, учитывая недетское жнергопотребление, за год оно сожрет больше, чем стоит б/у 2-головый сервак на лга771 зионах... Не так уж и дорого будет стоить - холодильники-то через интернеты продают к примеру... Винты по 36 гиг - мало кого интересуют (куда их ставить-то?), ддр1 регистровая - вообще никому не надо (+ вполне вероятно там свой форм-фактор памяти), процы - разве что в коллекцию (соответственно значительно дешевле, чем в комплекте рабочего раритета). Т.е. кроме винтов (и с некой вероятностью памяти) - с другими платформами там ничего не совместимо.

Ну лет 10 назад это были довольно-таки серьезные железки... Сейчас, учитывая, что 1) оси под них нет (солярка давно померла, линь - навряд какой собирают) 2) прожорливости их и 3) наличие в продаже по 350-400 баксов гораздо более серьезных б/у серверов высотой в 1 юнит (эти - вроде как на 3 юнита и длинные) - сейчас они представляют скорее коллекционную ценность, и для практического применения малопригодны (ибо производительность их, скорее всего, окажется соизмеримой с каким-то целероном G540)...

Локальные домосетки УЖЕ не могут, потому что они "локальные", основной доход которой идет не от юриков, а от хомяков, все что они могут, так это повысить тариф на 10-20 грн. чтоб выжить, аргумент - "а все подняли цены". Ну-ну Вы так лихо расписываетесь за все домосетки, при том, что сами не относитесь ни к одной из них... Поднимать цены как раз таки нельзя. Даже на 5 грн. Нужно другими способами повышать АРПУ (стимулировать переход на более дорогие пакеты) или же уменьшать затраты/аппетиты по части прибыльности. Таки да. И не нужно придумывать объяснение, почему же это АРПУ упало ниже плинтуса, затраты на подключение непомерно выросли, а выхлопа - ноль....

Дык никто и не говорит продавать 1 мбит по 100 когда сосед продает 100 мбит за 100... Поставить конкурентную цену (можно даже чуть выше, чем у конкурента), и потихоньку выживать... Ну набьют абонбазу, пускай, а сколько после окончания акции абонов-то остаентся на фрегате, если локальные домосетки начнут подобными акциями возвращать абонов? + ко всему - если с 100 мбит в ЧНН доступно 20 на торренте, это значит лишь одно: об онлайн-видео (ютубы и т.п.) в это время можно забыть, ибо оверкоммит канала 5-кратный... Любая полка на канале режет однопоток весьма сильно...

Проблема еще в том, что чем больше масштабы обслуживаемой КЦ сети, тем сложнее рядовому сотруднику КЦ знать состояние дел на местах (перегружен линк на участок сети/пропадает надолго свет на магистральном узле/прочее), и тем медленнее доходит информация с районов в центр и обратно. Да и уровень квалификации (именно по части сетевых технологий) персонала КЦ (той самой первой линии) обычно ставится на последний план. Какой такой минус? Откуда? Фрегату значит вы полгода шары в плюс считаете, мелким - в минус? Пионеров (колхозов вернее) сейчас практически нет, да и не будут они бегать ради десятка грн экономии. Им сеть приносит деньги, и им главное - стабильность работы (относительная). А вот куча студентов и т.п. - да, будет бегать ради халявы. Однако они либо остаются на последнем смененом ними прове, либо - на прове с лучшим качеством услуг, чьими услугами они смогут воспользоваться после окончания полной халявы у всех доступных провов. Низведут себе АРПУ в говно, и накроются медным тазом либо поднимут тарифы. Пионеры же с малым кол-вом абонов, работающие вчерную и "решающие" вопросы "на месте", потеряют часть абонов либо пострадавшие по деньгам, после смерти/подъема тарифов крупняками продолжат дальше свою деятельность... Средние по размеру провы - да, полиняют более ощутимо, но все же. Убегут к тому, кто даст при переключении халяву. Останутся на нем или нет - зависит от впечатлений о новом прове и тарифов/качества услуг. Причем качество услуг будет на 2-м месте после тарифов. Т.е. - если качество услуг чуть хуже, но цена ниже - останутся, если лучше, но цена выше - многие слиняют туда, где дешевле.