[XOPC]

Может не в тему, прошу посоветовать мини компьютер с двумя сетевыми платами для маршрутизатора с билингом.

Нужен не дорогой, без принудительного охлаждения, что бы поставить и "забыть"!

[NiTr0]

Для биллинга советовал бы ЕСС память. Ну и да, какой трафик оно молотить должно?

[XOPC]

Для биллинга советовал бы ЕСС память. Ну и да, какой трафик оно молотить должно?

Триста гигов в месяц на скорости до 12 Мбит/с надо разделить на две конторы. Кто больше съел, тот больше заплатил.

[NiTr0]

Дешево и сердито - сокет 754/ам2 амд с ЕСС (платы от асус все имеют есс), младший проц, пара любых сетевух. Если хочется нового - опять же младший ам3/ам3+ проц.

Полностью пассив навряд сделаете (БП с пассивкой дорого), хотя в принципе можно подумать над каким-то 12В DC БП (Вт 75 хватит для такой системы с головой - и то реальная мощность будет ниже), на проц какую-то пассивную СО типа http://catalog.onliner.by/fan/coolermaster/hyper_z600 (главное корпус разместить чтобы ребра вертикально стояли).

 

Если объемы записи будут небольшие (не будете netflow хранить) - можно и пару ssd поставить (или один + бекап куда-то), а можно и пару винтов.

 

ЕСС стоит ставить на всякий случай - чтобы потом вдруг не вылезла ошибка памяти в виде неадекватного суммарного траффика.

[XOPC]

Дешево и сердито - сокет 754/ам2 амд с ЕСС (платы от асус все имеют есс), младший проц, пара любых сетевух. Если хочется нового - опять же младший ам3/ам3+ проц.

Нет, не пойдёт... нужен типа http://it-explorer.ru/wp-content/uploads/sites/2/2015/01/wpid-i_47d200261.png (http://www.3dnews.ru/908078)

[vlad11]

Это очень хилые железки с трудом осилят пару сотню Мбит. К тому же две сетевые - нереально.

Как вариант, использовать еще L2 коммутатор.

[XOPC]

Это очень хилые железки с трудом осилят пару сотню Мбит. К тому же две сетевые - нереально.

Как вариант, использовать еще L2 коммутатор.

не люблю лишнее. справятся! я видел реально работающий комп с двумя сетевыми и размером с пачку сигарет. но обычно в эти железяки напихивают всяких интерфейсов дохера, а надо по минимуму: 1 usb, 2 lan, 1 hdmi или vga, 1 dc

http://ru.aliexpress.com/item/Barebone-OS-thin-client-pc-mini-computer-Intel-Celeron-1037U-Dual-core-CPU-2-1000M-LAN/2024588937.html

http://ru.aliexpress.com/item/J1900-Cheap-Living-room-mini-computer-NUC-industrial-NANO-J1900-fanless-mini-pc-with-LVDS-port/32292117304.html

http://ru.aliexpress.com/item/intel-core-I3-dual-core-1-8GHz-mini-computer-thin-client-HDMI-VGA-DDR3-8GB-RAM/1922274204.html

[MMM]

есть живой пример - старый нетбук на атоме, спокойно тянет около 50мбит + openvpn мегабит на 40

[vop]

Это очень хилые железки с трудом осилят пару сотню Мбит.

 

Ну 12 мегабит в пике точно уж потянут, не?

Изменено 9 мая, 2015 пользователем vop

[stas_k]

их проверенных решений - http://shop.nativepc.ru/13-readyrouters

 

http://shop.nativepc.ru/31--apu-routers- что то новенькое.

[NiTr0]

Нет, не пойдёт... нужен типа http://it-explorer.r...i_47d200261.png (http://www.3dnews.ru/908078)

Их с ЕСС не видел. Может и есть, но в industrial исполнении с соответствующим конским ценником.

Не то чтобы ЕСС критично, но таки очень желательно на серверах БД/биллинга. Хотя в крайнем случае можно и без ЕСС взять у китайцев шелезяку с кучкой сетевух - но настоятельно рекомендую хотя бы недельный прогон мемтеста. Ну чтобы быть уверенным что планка не глюкает (на планках порой 1-2 ошибки в сутки бывает проскакивает).

[XOPC]

Из проверенных решений - http://shop.nativepc...13-readyrouters

 

http://shop.nativepc...1--apu-routers- что то новенькое.

дороговато для тех задач, надо железка ценой 8-10 т с доставкой. придётся с китайцами договариваться.

[ttttt]

Их с ЕСС не видел. Может и есть, но в industrial исполнении с соответствующим конским ценником.

Не то чтобы ЕСС критично, но таки очень желательно на серверах БД/биллинга.

Нитро, все с этими ЕСС пугалками носитесь. А вот даже Microsoft в своем облаке дает SQL Server в виде сервиса и без ECC, вот саппорт как объясняет:

"a series of mechanisms to give the same benefits as ECC without requiring ECC"

 

А все потому, что так устроены ACID СУБД, не нужен он им. Просто убедитесь, что база не MyISAM, а InnoDB и забейте.

 

XOPC, берите на интеловских J1900 - проверенные, мощные. Впихните туда интеловский SSD (S3500), в нем есть конденсатор для сохранения целостности при пропадании питания во время активной записи, избавит от части возможных проблем. Не забывайте бэкапы и спите спокойно.

[NiTr0]

А вот даже Microsoft в своем облаке дает SQL Server в виде сервиса и без ECC

Облако на десктопных тазиках? Впрочем, это в стиле майкрософт :)

 

А все потому, что так устроены ACID СУБД, не нужен он им.

Да-да, ни СУБД не нужен, но прочему софту вокруг СУБД, обрабатывающему данные, не нужен, подумаешь - никакой гарантии корректности данных, кого такая мелочь на сервере биллинга волнует :)

[ttttt]

но прочему софту вокруг СУБД, обрабатывающему данные, не нужен, подумаешь - никакой гарантии корректности данных, кого такая мелочь на сервере биллинга волнует :)

Софт вокруг если использует СУБД, то уж точно не хранит и не кэширует ничего сам, шансы очень маленькие. Я бы сказал не больше, чем и из-за багов, уязвимостей, неосторожных юзеров и т.д. И тут так - их либо надо решать и ECC не улучшит ситуацию, либо шансы устраивают, но тогда и память без ECC тоже.

Изменено 10 мая, 2015 пользователем ttttt

[NiTr0]

Софт вокруг если использует СУБД, то уж точно не хранит и не кэширует ничего сам, шансы очень маленькие.

Откуда такая уверенность? Вы знаете, какие алгоритмы снижения нагрузки на СУБД реализованы в неназванной биллинговой системе? :)

 

Я бы сказал не больше, чем и из-за багов, уязвимостей, неосторожных юзеров и т.д.

Баги-то правятся. Юзеры тут вообще никаким образом. А вот дырявая память - может приводить к непредсказуемым последствиям.

[ttttt]

Откуда такая уверенность? Вы знаете, какие алгоритмы снижения нагрузки на СУБД реализованы в неназванной биллинговой системе? :)

От транзакций. В биллинге главное только деньги, а там либо будут транзакции, либо будут проблемы с деньгами. Третьего не дано.

Хотя важность проблем с деньгами вы сильно переоцениваете. Не о миллионах в секунду речь идет.

 

Баги-то правятся. Юзеры тут вообще никаким образом. А вот дырявая память - может приводить к непредсказуемым последствиям.

А юзеры и баги каким-то чудом не могут? Все, короче, надоело, изучайте теорию, гуглите, проблем с данными хоть с ECC, хоть без - море. Если вы о них не знаете, то ECC ваша самая последняя забота.

Изменено 10 мая, 2015 пользователем ttttt

[NiTr0]

От транзакций. В биллинге главное только деньги, а там либо будут транзакции, либо будут проблемы с деньгами.

Тарифные планы к примеру не кешируются, и каждый раз база дергается? netflow не агрегируются нигде, все сразу же в БД заталкивается?

 

Хотя важность проблем с деньгами вы сильно переоцениваете. Не о миллионах в секунду речь идет.

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

 

А юзеры и баги каким-то чудом не могут?

Баги правятся. А юзеры - каким образом они могут на что-либо повлиять-то?

 

Все, короче, надоело, изучайте теорию, гуглите, проблем с данными хоть с ECC, хоть без - море.

И поэтому нужно добавить еще один источник гарантированных проблем с данными. Гениально :)

[ttttt]

А юзеры и баги каким-то чудом не могут?

Баги правятся. А юзеры - каким образом они могут на что-либо повлиять-то?

От того, что баги правятся - они не могут приводить к непредсказуемым последствиям?

 

И поэтому нужно добавить еще один источник гарантированных проблем с данными. Гениально :)

Сочинить источник проблем - не добавить.

 

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

Ой, а самому не смешно с надуманных проблем?

[NiTr0]

От того, что баги правятся - они не могут приводить к непредсказуемым последствиям?

Если баги могут приводить к непредсказуемым последствиям - их не надо устранять, так? :)

 

Сочинить источник проблем - не добавить.

Редкие вылеты софта, испорченные данные на машинах без ЕСС - вполне себе реальные и наблюдаемые вещи. Как и внезапные выходы из строя плашек памяти. Которые при отсутствии ЕСС мега одмины будут списывать на "глюкавый софт и непредсказуемых юзеров" (с)

 

Ой, а самому не смешно с надуманных проблем?

Если вам ваш аплинк выставит вдруг счет в 3 раза больше потому что якобы вы потребили больше трафика/выгребли большую полосу чем заявили - куда вы пошлете его? :)

[vop]

Никогда не слышал, что бы дырявая память подделывала счета на оплату. :) Софт вылетает - да. Тазик виснет - да. Обычно после трех-пяти таких случаев память тестируется, и, если надо, меняется. Но деньги "подделать"... Не, даже представить не могу.

[nuclearcat]

Какова сумма вопроса? Т.е. цена ошибки.

Судя по заданию - вы тут обсуждаете лошадку в вакууме :) Две конторы если че неправильно поделят счет, и если правильно организовать подсчет траффика - вероятность такой ошибки будет меньше, чем динозавр наступит на сервер.

[YuryD]

Никогда не слышал, что бы дырявая память подделывала счета на оплату. :) Софт вылетает - да. Тазик виснет - да. Обычно после трех-пяти таких случаев память тестируется, и, если надо, меняется. Но деньги "подделать"... Не, даже представить не могу.

 

В древние времена я видел глючный арифметический сопроцессор *287. Его результаты поражали. В играх рейтинг выглядел вообще потрясающе, в суперкальке - аналогично...

[YuryD]

Для биллинга советовал бы ЕСС память. Ну и да, какой трафик оно молотить должно?

Триста гигов в месяц на скорости до 12 Мбит/с надо разделить на две конторы. Кто больше съел, тот больше заплатил.

 

Обычная задача учёта. Тут даже нетфлоу городить ни к чему, справятся любые счётчики хоть от iptables, хоть от ipfw, хоть байтики на портах коммутатора с snmp - в этом варианте вообще комп на месте не нужен... Малопортовый смарт с snmp. Это конечно не варианты для двух клиентов - они меж собой никогда не договорятся :) Нужна третья сторона - независимый арбитр, которым вполне сможет стать вышестоящий провайдер...

[NiTr0]

Никогда не слышал, что бы дырявая память подделывала счета на оплату. :) Софт вылетает - да. Тазик виснет - да.

Что будет если сбой в памяти попадет не в код/критически важные данные, а в тот самый счетчик трафика/тариф/прочее?

 

 

Обычно после трех-пяти таких случаев память тестируется, и, если надо, меняется.

Эдак % 30-50 новой памяти вполне себе дают около 1 ошибки в сутки. Оно в принципе пофиг на игровой машине, но там где лопатятся важные данные - я бы не рисковал.

Ну или в крайнем случае - как выше писал, недельный прогон мемтеста до установки. Что не гарантирует отсутствие сбоев из-за естественного радиационного фона.