ruri Posted June 22, 2010 · Report post Выбираем свой первый NAS. Клиентов не особо (по здешним меркам) много 2-3 тыс. На нём будет вертеться база биллинга Lanbilling. Желательно по началу на него же поставить MySQL сервер. Пока достаточно обычного RADI 1. Есть предложения QNAP TS-419U NetGear ReadyNAS 2100 Нетгир не нравится своей закрытостью. Всё что можно на него "довесить" находится в аддонах.. Какой там MySQL не понятно. поменять его при случае вряд-ли получится. Кунап, как мы поняли, более открыт (Linux). Т.е. можно ставить, что-то своё по необходимости. Рассматривался вариант вообще поставить HP сервер с программноаппаратным RAID 1 (люди отговаривают - лучше специализированное) Есть у кого-то опыт работы с этими железками? Может кто-то посоветует что-то ещё? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SokolovS Posted June 22, 2010 · Report post В NAS свои функции ни к чему, не потребуется, он должен просто работать ;) Так что берите исходя из финансовых возможностей. При 2-3к абонентов можно взять и посерьезнее типа AXUS или IBM с внешним интейфесом SAS, за IBM конечно же переплатите. Нужно что бы так "поставил и забыл", только иногда винтами подкармливать. И сразу рекомендую делать не RAID1 если объем важен. RAID5 более экономичен, правда для СУБД не совсем подходит, но в случае с аппаратными реализациями разница по скорости не велика. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
No_name Posted June 23, 2010 · Report post Есть деньги бери НР, нету собери писюк и будет работать. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ruri Posted June 23, 2010 · Report post Есть деньги бери НР, нету собери писюк и будет работать.Денег есть ~60т.р.Писюк не хотелось-бы... Не хочется рисковать базой биллинга Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SokolovS Posted June 23, 2010 · Report post Чтобы не рисковать нужно делать ежедневные инкрементальные бэкапы, скорее риск простоя более опасен. Ищите именно с интерфейсом iSCSI ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ruri Posted June 24, 2010 · Report post Чтобы не рисковать нужно делать ежедневные инкрементальные бэкапы, скорее риск простоя более опасен. Ищите именно с интерфейсом iSCSI ? Насколько он принципиален? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SokolovS Posted June 24, 2010 (edited) · Report post iSCSI это скази поверх IP, т.е. воткнул шнурок с витухой, который и так по любому будет, подцепил устройство и работаешь как с локальным диском. Органичение тут 1 Гбит отдачи с NAS. Подключить к хранилищу можно несколько серверов одновременно. В случае с SAS интерфесом у NAS, нужно будет еще купить RAID контроллер с внешним SAS интерфейсом для сервера. Серверов тоже можно подключить несколько, но в каждый нужен контроллер. Цены в принципе сейчас приемлемые можно брать самый недорогой из апаратных. Преимущество - скорость не делится, каждому серверу до 2.5 Гбит/c. Решение с SAS интерфесом дороже, но судя по опыту работает лучше, проблемы с сетью не влияют на работоспособность. Edited June 24, 2010 by SokolovS Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
YuryD Posted June 25, 2010 · Report post NAS - это network access storage как я понял ? Собственно не вижу никакой необходимости в нем для биллинга... Просто к невозможности биллинга приконнектиться к БД вы добавите еще дополнительных сущностей - тот-же сетевой кабель, порты коммутатора , ну и наконец лишние проблемы с электропитанием...Выносить mysql на другой комп - пожалуйста, но это необязательно должен быть NAS... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ruri Posted June 25, 2010 (edited) · Report post Вообщем так и решили. Купить просто сервер с RAID контроллером и вынести туда MySQL с базами. Edited June 25, 2010 by ruri Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted June 25, 2010 · Report post Купить просто сервер с RAID контроллером и вынести туда MySQL с базами. У вас 3 варианта как поступить после: - свалить подальше и не супортить - купить ещё рейд контролёр про запас и хранить его - использовать софтварный рейд Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SokolovS Posted June 25, 2010 (edited) · Report post Почему? :) Волне такое нормально решение если конкретно под MySQL использовать, то сервер + Adaptec 3405 + SATA винты по 1.5 Тб. Имхо это будет лучше чрез NAS с iSCSI интерфейсом. Если уж брать нас, то с SAS интерфейсом. Вобще я не понимаю когда все первичные данные по трафику пытаются хранить в СУБД, они для этого ну никак не предназначены, порционирование как то исправляет ситуацию, но все равно не айс. Там нужно хранить только суммурный за сутки трафик. А если так, то и винтами запасаться не нужно, вернее нужно но это уже не будет влиять на работоспособность билинга. Edited June 25, 2010 by SokolovS Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ruri Posted June 28, 2010 · Report post А как вы предлагаетет хранить развёрнутую статистику? Она необходима для разбирательства с клиентами. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SokolovS Posted June 28, 2010 · Report post А как вы предлагаетет хранить развёрнутую статистику? Она необходима для разбирательства с клиентами.Дело в том, что РСУБД вещь достаточно универсальная и как все универсальное слишком избыточна. Например: более половины ваших данных по первичному трафику будет составлять индекс :)Далее, данные по трафику структурированы, как минимум день, час и лицевой счет будут так же дублироваться для все данных в пределах дня. Я предлагаю хранить "сырые" данные отдельно не в РСУБД. Ну вот как вариант, создаем структуру каталогов /год/мес/день/<лиц.счет> там ложим файлики с сырыми данными за каждый час для этого абонента. Ложить можно как flow-данные, так и Belkeley DB или SQLite, да хоть текстовые. Самая частая выборка это выборка по лицевому счету, тут она будет очень быстрой. Оптимизировать нужно еще в плане структурирования, т.к. лицевых счетов может быть много, вложнность нужно увеличивать, т.е. каталоги делать вида 1-100, 101-200 и.т.д, та там уже по 100 лицевых счетов, это упрощенно. Зачастую при разбирательствах достаточно показать в какой час с какого ресурса был трафик, точность до минут и секунд не нужна, ну неплохо бы иметь время начала первого обмена с ресурсом и время окончания в пределах часа. Об этом я тут писал: http://forum.nag.ru/forum/index.php?showtopic=58159 Если нужны отчеты через веб, то простой perl-демон будет отдавать данные принимая 2 параметра, день и лицевой счет. Делать детализации за длительные периоды считаю нецелесообразным. Так же считаю что детализации должны быть платными, т.к. у оператора это доп. нагрузка. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
YuryD Posted June 29, 2010 · Report post А как вы предлагаетет хранить развёрнутую статистику? Она необходима для разбирательства с клиентами. Для безлимитов проблема неактуальна, поэтому netflow есть, но лежит на дисках насов, для других разборок - потому как достаточно radius-accounting. Для помегабайтников - да, но в биллинг надо гнать агрегированную статистику, иначе он сдохнет, в принципе хватает того-же радиуса... У нас просто единобразная система снятия netflow где бы ни было, единая структура хранения этих flow... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
YuryD Posted June 29, 2010 · Report post Вдогонку, netflow для разборок с клиентом неудобна. Более пригоден перехват всех dns-запросов, и места немного занимает, и нагляден весьма... :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ruri Posted June 29, 2010 · Report post LanBilling хранит агрегированную статистику (не реклама, пользуемся тем что есть) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SokolovS Posted June 30, 2010 · Report post Так это хорошо, тогда точно "сервер + аппаратный рейд" тебе хватит. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
