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

[ruri]

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

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

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

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

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

 

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

QNAP TS-419U

NetGear ReadyNAS 2100

 

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

 

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

 

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

 

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

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

[SokolovS]

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

 

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

[No_name]

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

 

[ruri]

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

Денег есть ~60т.р.

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

 

[SokolovS]

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

[ruri]

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

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

[SokolovS]

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

 

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

 

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

Edited June 24, 2010 by SokolovS

[YuryD]

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

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

[ruri]

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

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

Edited June 25, 2010 by ruri

[Ivan_83]

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

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

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

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

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

[SokolovS]

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

 

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

Edited June 25, 2010 by SokolovS

[ruri]

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

[SokolovS]

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

Дело в том, что РСУБД вещь достаточно универсальная и как все универсальное слишком избыточна. Например: более половины ваших данных по первичному трафику будет составлять индекс :)

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

 

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

 

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

 

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

 

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

[YuryD]

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

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

[YuryD]

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

[ruri]

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

[SokolovS]

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