Перейти к содержимому
Калькуляторы

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

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

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

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

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

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

 

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

QNAP TS-419U

NetGear ReadyNAS 2100

 

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

 

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Изменено пользователем SokolovS

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем ruri

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Изменено пользователем SokolovS

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.