| forum.bitel.ru http://forum.bitel.ru/ |
|
| Требования к железу http://forum.bitel.ru/viewtopic.php?f=1&t=177 |
Страница 1 из 1 |
| Автор: | alv [ 30 мар 2007, 15:00 ] |
| Заголовок сообщения: | Требования к железу |
Сорри, если ответ где-то на поверхности, но я не увидел 
Какие требования и рекомендации по железу серверной части для версии Linux? Как рекомендуется разносить модули - достаточно ли двух серваков: ядро и БД? Планируются модули: IPN, Phone, NPAY и ессесно Bill, Reports. Клиентов не много - юр.лица, скажем где-то около 300 |
|
| Автор: | Администратор [ 30 мар 2007, 15:06 ] |
| Заголовок сообщения: | |
Достаточно LINUX совмещенного БД и BILL сервера, 2 ГГц CPU, 1 ГБ ОЗУ (это с большим запасом). Вринципе для таких объемов железо не очень критично. Единственно отнеситесь внимательно к жестким дискам, очень желательно RAID с зеркалом т.к. при активной работе БД диски существенно изнашиваются, так чтобы полетевший один диск не привел к потере данных. |
|
| Автор: | alv [ 05 апр 2007, 20:43 ] |
| Заголовок сообщения: | |
Можно ли еще услышать рекомендации по размещению сервера при условии, что офис и центральный узел территориально разнесены и между ними своего канала нет (только тунель через Инет). В таком случае куда лучше поместить сервер с ядром биллинга с точки зрения удобства и для минимизации трафика узел - офис. |
|
| Автор: | Администратор [ 06 апр 2007, 11:23 ] |
| Заголовок сообщения: | |
Оптимально поместить его на центральном узле. |
|
| Автор: | alv [ 06 апр 2007, 11:35 ] |
| Заголовок сообщения: | |
Спасибо за оперативные ответы. Можно ли как-то (среднепотолочно) оценить объем трафика между сервером биллинга и оператором? |
|
| Автор: | Администратор [ 06 апр 2007, 11:41 ] |
| Заголовок сообщения: | |
Трафик будет примерно равен как при активном WEB серфинге |
|
| Автор: | ipfwd [ 19 ноя 2007, 14:20 ] |
| Заголовок сообщения: | |
Какие требования к системе? планируется IPN=1000юзеров dialup=4000юзеров |
|
| Автор: | Администратор [ 19 ноя 2007, 14:41 ] |
| Заголовок сообщения: | |
Core Dual 2200 + 2 Гб ОЗУ + SATA RAID Должно быть достаточно.. |
|
| Автор: | serano [ 12 дек 2007, 11:09 ] |
| Заголовок сообщения: | |
А подскажите плиз. какой сервер понадобиться если уже предоставляется кабельное ТВ 20000 абонентов и планируется предоставлять еще и инет скажем на 6000 юзеров??? |
|
| Автор: | Администратор [ 13 дек 2007, 01:00 ] |
| Заголовок сообщения: | |
КТВ прямо скажем железо не ест почти совсем.. Ну начислите вы им абонки раз в месяц, ну даже если переначисление сделаете раз в сутки, ничего страшного. А инет какой? VPN, прямой доступ? |
|
| Автор: | serano [ 17 дек 2007, 15:19 ] |
| Заголовок сообщения: | |
Прямой |
|
| Автор: | Администратор [ 17 дек 2007, 15:59 ] |
| Заголовок сообщения: | |
С какой оперативностью обсчет нужен? |
|
| Автор: | serano [ 18 дек 2007, 07:10 ] |
| Заголовок сообщения: | |
ну чем оперотивнее тем лучше. Приведите минимальные требования и наилучшие. |
|
| Автор: | Администратор [ 18 дек 2007, 12:21 ] |
| Заголовок сообщения: | |
Ну указанные выше требования будут вполне достаточные, обсчет рекомендую раз в час, не чаще. Особенность модуля такова, что он перетарифицирует каждый раз весь месяц. Перетарификация будет до 10 минут. |
|
| Автор: | Ivanov_AP [ 14 июн 2009, 18:56 ] |
| Заголовок сообщения: | |
Здравствуйте! Чтобы не поднимать новую тему, пишу в этой же. На данный момент имеется: Абонентская база - около 10000 абонентов. Доступ по PPTP VPN (NAS'ы на poptop, Linux) Авторизация через RADIUS Подсчет траффика - через RADUIS. Около 2500 абонентов онлайн (одновременных сессий). Тарифные планы - 85% безлимитные, остальные - с оплатой за траффик Сейчас стоит задача выбора биллинга. Планируемые модули: для начала DialUP/VPN, Npay В связи с этим вопросы к разработчикам: 1. Какое железо (особенно дисковая подсистема) "без тормозов потянет" 2500 одновременных vpn-сессий (допустим, с radius-аккаунтингом при interim-update=2 мин) ? 2. Как биллинг относится к 300-500 одновременным подключениям (именно одновременные запросам на авторизацию и т.д) ? (Например, отключили свет во всем районе, потом дали, и все дружно ломятся в Интернет; к сожалению, у нас такое не редкость) поэтому ответ на этот вопрос очень важен. 3. Сколько будет длиться снятие абонентской платы (через модуль npay ) с этих 10000 пользователей? А/П желательно снимать каждый день. 4. Нужно ли при такой нагрузке разносить сервер RADIUS и Сервер биллинга+БД на разные компьютеры ? В будующем скорее всего придется этим же биллингом обсчитывать netflow с около 100 выделенных каналов. 5. Справится ли со всем этим сервер с 4 Гб RAM, Intel Xeon X3370 и дисками SATA без RAID? Или в обязательном порядке для повышения производительности придется организовывать какой-либо из серьезных RAID-массивов? (stripped для производительности + зеркало для отказоустойчивости...) |
|
| Автор: | Феанор [ 14 июн 2009, 19:47 ] |
| Заголовок сообщения: | |
у нас примерно похожая ситуация, поделюсь опытом Ivanov_AP писал(а): 2. Как биллинг относится к 300-500 одновременным подключениям (именно одновременные запросам на авторизацию и т.д) ? (Например, отключили свет во всем районе, потом дали, и все дружно ломятся в Интернет; к сожалению, у нас такое не редкость) поэтому ответ на этот вопрос очень важен. плохо относится. радиус начинает проглатывать аккаунтинг пакеты, отбрасывать авторизации. может дойти до полного затыка. узкое место - количество обращений к базе. мы сейчас изучаем возможность работы радиуса со slave базой. Цитата: 3. Сколько будет длиться снятие абонентской платы (через модуль npay ) с этих 10000 пользователей? А/П желательно снимать каждый день. 1-2 минуты Цитата: 4. Нужно ли при такой нагрузке разносить сервер RADIUS и Сервер биллинга+БД на разные компьютеры ? В будующем скорее всего придется этим же биллингом обсчитывать netflow с около 100 выделенных каналов. я бы советовал разнести. чтобы от пиковых нагрузок на радиус не страдал сервер биллинга с основной бд. Цитата: 5. Справится ли со всем этим сервер с 4 Гб RAM, Intel Xeon X3370 и дисками SATA без RAID?
Или в обязательном порядке для повышения производительности придется организовывать какой-либо из серьезных RAID-массивов? (stripped для производительности + зеркало для отказоустойчивости...) что сервер, что шедулер в обычном режиме процессорного времени и памяти отжирают немного. шедулер грузит машину в 100% при операциях снятия абонплат, предоставления детализированной статистики. поэтому он у нас на отдельной машине, на нем же коллектор. по дискам - как уже и писалось в этой теме, зеркало поставьте обязательно, бэкапы бэкапами, но винты при таких нагрузках отказывают и никуда от этого не деться. да, риск отказа невелик, но вы хотите рисковать своей бд? а вообще советую рэйд 10, работа с большой бд потом потребует шустрого накопителя. |
|
| Автор: | Ivanov_AP [ 14 июн 2009, 22:29 ] |
| Заголовок сообщения: | |
Феанор писал(а): у нас примерно похожая ситуация, поделюсь опытом огромное спасибо! Феанор писал(а): > плохо относится. радиус начинает проглатывать аккаунтинг пакеты, отбрасывать авторизации. может дойти до полного затыка.
это грустно. В связи с этим появился еще вопрос. Под "полным затыком" Вы понимаете полную неработоспособность радиуса, из которого он без ручного вмешательства (то есть перезапуска ) выйти уже не может или же все-таки он постепенно, съев часть запросов, сам приходит в себя? Но в описании биллинга сказано, что он должен сбрасывать соединения при переходе с месяца на месяц. В таком случае после такого сброса гарантировано около 700 одновременных попыток зайти. Кошмар с падением радиуса обеспечен? и отделываться только тем, что на NAS-ах приделывать костыль в виде ограничения на количество SYN-пакетов на 1723 порт... |
|
| Автор: | Феанор [ 14 июн 2009, 22:52 ] |
| Заголовок сообщения: | |
Ivanov_AP писал(а): Но в описании биллинга сказано, что он должен сбрасывать соединения при переходе с месяца на месяц.
В таком случае после такого сброса гарантировано около 700 одновременных попыток зайти. Кошмар с падением радиуса обеспечен? мы на бгбиле с 1го числа работаем, так что смену месяца пока еще не ощутили =) но возможно мы еще и радиус просто не отлизали до нужной степени. у нас апдейт пакеты с каждого наса шли каждую минуту, сейчас поставили реже и чтобы не одновременно с каждого. плюс активно читаем про слэйв базы и вообще про обращение к базе. затыки были полные, приходилось сервис радиуса перезапускать. но тут мне кажется мы сами просто не расчитали нагрузки которые могут возникать при отключении должников и сбросах света. сейчас поправили конфиги и читаем документацию по оптимизации. из правок - унесли списание абонплат на глубокое утро, когда совсем мало народа в онлайне. а то в 00:00 летом сидит еще дай бог сколько народа =) |
|
| Автор: | Администратор [ 15 июн 2009, 15:44 ] |
| Заголовок сообщения: | |
To: Феанор Проверьте скорость чтения с диска командой hdparm -t .. Гораздо большие объемы тянутся без проблем. |
|
| Автор: | Феанор [ 15 июн 2009, 18:16 ] |
| Заголовок сообщения: | |
40-45 мегабайт в секунду. ps поправка. это было на бутовом разделе. раздел на котором находится сама база выдает 90-120 мегабайт в секунду |
|
| Автор: | Администратор [ 16 июн 2009, 11:44 ] |
| Заголовок сообщения: | |
Цитата: В таком случае после такого сброса гарантировано около 700 одновременных попыток зайти. Кошмар с падением радиуса обеспечен?
Там сбрасывает не сразу а постепенно. Вообще 4.6 не должен умирать никак, т.е. потихоньку авторизовывать должен все равно.. За Феаноровским будем еще наблюдать. Там вообще какое-то аномальное поведение было, радиус почему-то вообще не отвечал.. |
|
| Страница 1 из 1 | Часовой пояс: UTC + 5 часов [ Летнее время ] |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|