Jump to content
Калькуляторы

Какой NAS выбрать ?

Выбираем свой первый NAS.

Клиентов не особо (по здешним меркам) много 2-3 тыс.

На нём будет вертеться база биллинга Lanbilling.

Желательно по началу на него же поставить MySQL сервер.

Пока достаточно обычного RADI 1.

 

Есть предложения

QNAP TS-419U

NetGear ReadyNAS 2100

 

Нетгир не нравится своей закрытостью. Всё что можно на него "довесить" находится в аддонах.. Какой там MySQL не понятно. поменять его при случае вряд-ли получится.

 

Кунап, как мы поняли, более открыт (Linux). Т.е. можно ставить, что-то своё по необходимости.

 

Рассматривался вариант вообще поставить HP сервер с программноаппаратным RAID 1 (люди отговаривают - лучше специализированное)

 

Есть у кого-то опыт работы с этими железками?

Может кто-то посоветует что-то ещё?

Share this post


Link to post
Share on other sites

В NAS свои функции ни к чему, не потребуется, он должен просто работать ;) Так что берите исходя из финансовых возможностей. При 2-3к абонентов можно взять и посерьезнее типа AXUS или IBM с внешним интейфесом SAS, за IBM конечно же переплатите. Нужно что бы так "поставил и забыл", только иногда винтами подкармливать.

 

И сразу рекомендую делать не RAID1 если объем важен. RAID5 более экономичен, правда для СУБД не совсем подходит, но в случае с аппаратными реализациями разница по скорости не велика.

Share this post


Link to post
Share on other sites

Есть деньги бери НР, нету собери писюк и будет работать.

 

Share this post


Link to post
Share on other sites
Есть деньги бери НР, нету собери писюк и будет работать.
Денег есть ~60т.р.

Писюк не хотелось-бы... Не хочется рисковать базой биллинга

 

Share this post


Link to post
Share on other sites

Чтобы не рисковать нужно делать ежедневные инкрементальные бэкапы, скорее риск простоя более опасен. Ищите именно с интерфейсом iSCSI ?

Share this post


Link to post
Share on other sites

Чтобы не рисковать нужно делать ежедневные инкрементальные бэкапы, скорее риск простоя более опасен. Ищите именно с интерфейсом iSCSI ?

Насколько он принципиален?

Share this post


Link to post
Share on other sites

iSCSI это скази поверх IP, т.е. воткнул шнурок с витухой, который и так по любому будет, подцепил устройство и работаешь как с локальным диском. Органичение тут 1 Гбит отдачи с NAS. Подключить к хранилищу можно несколько серверов одновременно.

 

В случае с SAS интерфесом у NAS, нужно будет еще купить RAID контроллер с внешним SAS интерфейсом для сервера. Серверов тоже можно подключить несколько, но в каждый нужен контроллер. Цены в принципе сейчас приемлемые можно брать самый недорогой из апаратных. Преимущество - скорость не делится, каждому серверу до 2.5 Гбит/c.

 

Решение с SAS интерфесом дороже, но судя по опыту работает лучше, проблемы с сетью не влияют на работоспособность.

Edited by SokolovS

Share this post


Link to post
Share on other sites

NAS - это network access storage как я понял ? Собственно не вижу никакой необходимости в нем для биллинга...

Просто к невозможности биллинга приконнектиться к БД вы добавите еще дополнительных сущностей - тот-же сетевой кабель, порты коммутатора , ну и наконец лишние проблемы с электропитанием...Выносить mysql на другой комп - пожалуйста, но это необязательно должен быть NAS...

Share this post


Link to post
Share on other sites

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

Купить просто сервер с RAID контроллером и вынести туда MySQL с базами.

Edited by ruri

Share this post


Link to post
Share on other sites
Купить просто сервер с RAID контроллером и вынести туда MySQL с базами.

У вас 3 варианта как поступить после:

- свалить подальше и не супортить

- купить ещё рейд контролёр про запас и хранить его

- использовать софтварный рейд

Share this post


Link to post
Share on other sites

Почему? :) Волне такое нормально решение если конкретно под MySQL использовать, то сервер + Adaptec 3405 + SATA винты по 1.5 Тб. Имхо это будет лучше чрез NAS с iSCSI интерфейсом. Если уж брать нас, то с SAS интерфейсом.

 

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

Edited by SokolovS

Share this post


Link to post
Share on other sites

А как вы предлагаетет хранить развёрнутую статистику? Она необходима для разбирательства с клиентами.

Share this post


Link to post
Share on other sites
А как вы предлагаетет хранить развёрнутую статистику? Она необходима для разбирательства с клиентами.
Дело в том, что РСУБД вещь достаточно универсальная и как все универсальное слишком избыточна. Например: более половины ваших данных по первичному трафику будет составлять индекс :)

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

 

Я предлагаю хранить "сырые" данные отдельно не в РСУБД. Ну вот как вариант, создаем структуру каталогов /год/мес/день/<лиц.счет> там ложим файлики с сырыми данными за каждый час для этого абонента. Ложить можно как flow-данные, так и Belkeley DB или SQLite, да хоть текстовые.

 

Самая частая выборка это выборка по лицевому счету, тут она будет очень быстрой. Оптимизировать нужно еще в плане структурирования, т.к. лицевых счетов может быть много, вложнность нужно увеличивать, т.е. каталоги делать вида 1-100, 101-200 и.т.д, та там уже по 100 лицевых счетов, это упрощенно.

 

Зачастую при разбирательствах достаточно показать в какой час с какого ресурса был трафик, точность до минут и секунд не нужна, ну неплохо бы иметь время начала первого обмена с ресурсом и время окончания в пределах часа. Об этом я тут писал: http://forum.nag.ru/forum/index.php?showtopic=58159

 

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

Share this post


Link to post
Share on other sites
А как вы предлагаетет хранить развёрнутую статистику? Она необходима для разбирательства с клиентами.

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

Share this post


Link to post
Share on other sites

Вдогонку, netflow для разборок с клиентом неудобна. Более пригоден перехват всех dns-запросов, и места немного занимает, и нагляден весьма... :)

Share this post


Link to post
Share on other sites

LanBilling хранит агрегированную статистику (не реклама, пользуемся тем что есть)

Share this post


Link to post
Share on other sites

Так это хорошо, тогда точно "сервер + аппаратный рейд" тебе хватит.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this