сколько серверов ? до 500 клиентов

[Земеля 727]

Добрый день. встал такой вопрос

Сколько нужно серверов (допустим для пионеров )

до 100 клиентов - ( желательно параметры и количество серверов)

до 250 клиентов - (желательно параметры и количество серверов)

от 500 и выше (есть и такие пионеры)

есть сеть на 250 пользователей

На каком этапе и что стоит в первом очереди отделять от 1го сервера

- биллинг

- БД

- шлюз

[nightfly 1 239]

Среднестатистические тазики вида: xeon x3440 /4GB/ Intel Dual Port Server Adapter прожевывают в районе до 600 мбит трафика, справляясь при этом с Shape/Nat/Netflow при 4x/24 юзеров с тарифами 5-100мбит. По ощущениям запас еще есть, но стараюсь не догружать до потолка и просто докупать следующие сервера доступа если требуется.

 

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

Но как водиться добрым советам никто никогда не внимает Поэтому на количествах абонентов до 300-та скажем и общем трафике <300Мбит/с можно сделать и так:

 

после чего таки делать усилия в сторону миграции на более-менее адекватную архитектуру:

.... а потом осознать смысл жизни и масштабироваться.... масштабироваться... вжжжжж

[Земеля 727]

а какие посоветуете параметры билинг сервера и nas1 \ nas2 если обьемы трафика до 200-300 мегабит ( с возможностью апгрейда )

[QI_Can9 3]

бд и билинг на отдельный сервер

[KaYot 3 706]

До первой тыщи(особенно если она планируется и последней) единственный сервер все в одном вполне нормальное решение..

[Земеля 727]

До первой тыщи(особенно если она планируется и последней) единственный сервер все в одном вполне нормальное решение..

хм... и сколько тогда такое удовольствие будет стоять? 1-2к зелени?

обоснуйте пожалуйста почему все в одном ? лучше всего

[Digital_storm 68]

До первой тыщи(особенно если она планируется и последней) единственный сервер все в одном вполне нормальное решение..

+1

[hillers 1]

 

 

 

по этой схеме обслуживаем около 3к при 700Мбит трафика

биллинг, роутер все на одном НР 180

ОС - FreeBSD ( НАТ не используется, шейпинг через МПД)

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

добавим второй Ксеон и , я думаю, и до гигабита справится

а дальше надо уже думать

Відредаговано 2011-10-01 11:27:45 hillers

[Земеля 727]

кто что скажет про Cisco QUAD PORT N442404TX (pci-x, 10/100 PCIX) ? сможет ли она поднять около 300-400 мегабит? (3-4 канала по 100тке ? )

[KaYot 3 706]

До первой тыщи(особенно если она планируется и последней) единственный сервер все в одном вполне нормальное решение..

хм... и сколько тогда такое удовольствие будет стоять? 1-2к зелени?

обоснуйте пожалуйста почему все в одном ? лучше всего

Оно не лучше, оно просто допустимо и недорого. Любой 4ех ядерный системник с 4гб памяти и нормальной двухголовой сетевкой справится, у нас ~1.5k клиентов обслуживал сервер на xeon x3320(аналог core quad q6600) с бортовыми сетевками в supermicro материнке. И это с терминацией pppoe и НАТом.

[nightfly 1 239]

по этой схеме обслуживаем около 3к при 700Мбит трафика

а еще можно туда сервер КС поставить и файлопомойку, давайте че уж там, а про расширение так вобще думать пора будет на 15-ти тысячном абоненте.

[onorua 126]

Все зависит от тарифных планов и трафика. Но до 500 пользователей выдержит практически любой i7 и igb сетевая.

Тут вопрос больше в целесообразности, финансах и как вы подходите к вопросу доступности узлов.

Идеологически правильно разделять сервисы на разные хосты (главный принцип - "разделяй и властвуй"), а критические сервисы - еще и резервировать.

[Земеля 727]

нужна ИТ консультация по серверам (если можно по телефону)

в подарок ) Н-ая сумма )

[KaYot 3 706]

Все зависит от тарифных планов и трафика. Но до 500 пользователей выдержит практически любой i7 и igb сетевая.

500 человек i7 потянет даже с неядерным pptp и криворукой настройкой всего подряд

[hillers 1]

по этой схеме обслуживаем около 3к при 700Мбит трафика

а еще можно туда сервер КС поставить и файлопомойку, давайте че уж там, а про расширение так вобще думать пора будет на 15-ти тысячном абоненте.

 

Оч.смешно.

Работает все отлично. Над расширением думаем, но пока решение не принято в какую сторону двигаться. Знаю в Киеве довольно крупных и всем известных провайдеров, которые перемалывают на тазиках под Линуксом по несколько гигабит трафика. Так же знаю случай когда у провайдера было все построено на цисках - от доступа до роутеров, и при этом они смогли "склеить ласты"

[nightfly 1 239]

Оч.смешно.

я рад что вы оценили

 

 

Знаю в Киеве довольно крупных и всем известных провайдеров, которые перемалывают на тазиках под Линуксом по несколько гигабит трафика.

кто-то утверждал обратное?

 

 

Так же знаю случай когда у провайдера было все построено на цисках - от доступа до роутеров, и при этом они смогли "склеить ласты"

А какое это имеет отношение к тому, что стоит разделять понятия "сервер БД", "сервер с биллингом", "бордер" и "сервер доступа"? Подозреваю никакого.

Хотя может вам кажется адекватным солюшн, держать вообще все на одном тазике.

Ну тогда запасаемся попкорном.

[hillers 1]

А какое это имеет отношение к тому, что стоит разделять понятия "сервер БД", "сервер с биллингом", "бордер" и "сервер доступа"? Хотя может вам кажется адекватным солюшн, держать вообще все на одном тазике..

 

Не скажу, что это "классика жанра". Товарищ спросил будет ли работать 500 юзеров, я привел реальный пример.

 

Ну тогда запасаемся попкорном.

 

Можно запасаться - работает уже 6 лет, правда железо меняли несколько раз - начиналось с обычного ПиСи, потом

был сервер начального уровня, сейчас более мощный сервачок.

По поводу развития рассматриваем варинты - Juniper, Erricson Smart Edge, но у каждого есть свои нюансы и недостатки

[madf 279]

Сам вопрос говорит о том что этих 100/250/500 абонентов у вас еще нет. А т.к. абоненты сразу сотнями не появляются - начинайте с одного сервера удобной вам конфигурации. Наблюдая за ростом нагрузки и ее характером можно в будущем прийти к выводу о дальнейших модификациях. Так, например, рост IO от базы данных (после всяческих ее оптимизаций, естественно) говорит о необходимости выноса ее на отдельный хост. А если, например, появляются "полки" по прерываниям, значит перестают справляться сетевушки и пора добавлять в систему NAS'ы (хотя тут тоже могут быть варианты: установка FreeBSD, более адекватных сетевушек или более производительного процессора).

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

А точных цифр вам мало кто скажет, у всех ведь ситуации разные. Разные топологии, разные каналы и тарифы.

[Melanxolik 63]

Глупо начинать и с 50 абонами на одном сервере.

Ладно NAS и GW держать на одной машинке, но биллинг и мониторинг тут же, это звиздец.

 

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

Для билинга одно железо, для NAS второе, не обязательно сверх мощное, главное чтобы была возможность расширится быстро, новое ввести в строй, а старое убрать из оборота.

 

Из своего примера:

 

80 c копейками абонов, дай бог на этой недели запустим 15 с копейками домов по оптике с тарифами до 100 мегабит в порт.

 

Шлюз и биллинг, мониторинг Zabbix (мониторится порядка 70устройств по 10-30 параметрам) пока на одном железе под CentOS, NAS на базе BSD с mpd5 для pppoe вынесен на другое железо и ворочается в тестовом режиме.

Как будет это все дальше жить?

 

При росте абонов до 200-300 будет добавлен тазик с еще одним MPD, старый нас постеменно будет потушен.

GW будет заменен при 300абонах и постоянном трафике порядка 250мегов на что-то более высокопроизводительное.

 

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

Залог успеха: стабильный пинг и надежный канал.

[madf 279]

Глупо начинать и с 50 абонами на одном сервере.

Ладно NAS и GW держать на одной машинке, но биллинг и мониторинг тут же, это звиздец

 

...

 

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

Залог успеха: стабильный пинг и надежный канал.

Не вижу ничего в этом глупого. Многие сети так и начинались - с одного сервера. А некоторые до сих пор так и живут - на одном сервере. Один сервер вместо нескольких это не только дешевле, но еще и проще в обслуживании и настройке.

Не для всякого тюнинга надо ядро пересобирать. Часто не требуется даже рестарт дэмонов (если они поддерживают SIGHUP). Из своего опыта так-же скажу что в 4 утра мало кого волнует стабильность канала.

[onorua 126]

2 Melanxolik

Докупать сервера потому что вы достигли рубежа 200 пользователей это по меньшей мере странно. Докупать железо нужно тогда когда оно доходит до каких-то критических показателей производительности, а не тогда когда фаза луны правильная или попугаев стало на 5 больше чем вчера в зоопарке. Количество пользователей в вашем случае это как раз попугаи в зоопарке, вы можете подключить 10 человек торрентоводов которые убьют ваше железо сразу же, или 1000 домохозяек проверяющих почту раз в неделю. И то, нужно смотреть во что упирается ваше железо, и проще купить сетевую если по прерыванием умираете чем весь сервак. Выше правильно говорили - нужно правильного админа, а то будете покупать много а в результате можно склеить ласты.

[hillers 1]

Глупо начинать и с 50 абонами на одном сервере.

Из своего примера:80 c копейками абонов,

 

теоретик детектед

 

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

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

[Melanxolik 63]

Глупо начинать и с 50 абонами на одном сервере. Из своего примера:80 c копейками абонов,

теоретик детектед Никто ядро не пересобирает каждый день на работающем серваке, а если есть такая необходимость несколько раз в году работы проводятся рано утром. В схеме с несколькими серверами для полноценной работы узла необходимо чтобы все сервера работали одновременно, а если в это время по пол дня обновлять ядра, то ничего хорошего не выйдет.

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

 

каждая схема должна быть для начала хотя бы не много продумана и вполне реализован тот же vrrp с keepalived чтобы избавится от лишнего гемороя, ведь рост абоненсткой базы как раз зависит от качества предоставляемых услуг в определенных ситуациях.

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

[hillers 1]

, можно и полахтурить и дурака повалять.

 

вот этого не стоит делать в любом случае

[NiTr0 584]

ИМХО: мухи - отдельно, котлеты - отдельно. Насы/роутеры/бордюры - отдельно (ну максимум DNS слэйв или что-то подобное там поднять), вычислительные сервера и хранилища (БД/биллинг/веб/прочее) - отдельно. Хотя бы для того, чтобы один из серверов можно было остановить на профилактику с включением "холодного резерва" с минимальными затратами времени на перенос конфига.

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

Ну и на насах/роутерах/прочих траффкожевалках мы пользуем не полновесный, а урезанный дистр, живущий в RAM и пользующий флэш только для старта или сохранения конфига. Весьма удобно...