Назад | Перейти на главную страницу

Какие инструменты мне следует использовать для оценки пропускной способности фермы веб-серверов ..?

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

В настоящее время с меня взимается плата за гигабайт трафика в месяц (в настоящее время около 42 ГБ входящего трафика - только для запросов), но новый бандит арендовал бы мне канал, и его размер определял цену.

У меня есть несколько веб-серверов Centos и один сервер базы данных за балансировщиком нагрузки; веб-серверы обращаются к серверу базы данных, а публика - нет (то есть напрямую).

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

Могу ли я легко это сделать с моих веб-серверов Linux?

Я начал смотреть на такие инструменты, как ntop и bandwidthd, но решил сначала обратиться за советом к специалисту.

Я думаю, что мне нужно сделать, это посмотреть трафик между каждым веб-сервером и IP-адресом балансировщика нагрузки и сложить их вместе. Такие инструменты, как ntop, показывают трафик между серверами и удаленным IP-адресом, но не между сервером и промежуточным IP-адресом ...

Есть какие-нибудь подсказки?

Вам действительно нужна точная цифра (что бы это ни значило) для этого? Имеет ли значение знание того, что вы используете 100 Мбит / с или 150,3528 Мбит / с? Возможно, вам не нужно собирать эти данные, чтобы узнать цены.

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

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

Затем посмотрите варианты обновления. Сколько времени потребуется на обновление? Будут ли изменены их дополнительные расходы позже? Сколько вам будет стоить слишком маленькая труба за время, необходимое для реализации и реализации изменений? Это может побудить вас выбрать трубку побольше.

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

Вы можете использовать vnstat для мониторинга входящего и исходящего трафика. Это консольный монитор сетевого трафика, он ведет дневной, часовой и ежемесячный журнал, также вы можете использовать vnstat php-frontend для графического мониторинга.

Конфигурация:

ням установить vnstat

После установки вам необходимо создать базу данных с помощью следующей команды:

vnstat -u -i eth0 ()

-u :forces a database update for interface or creates the database if it doesn’t exist
-i eth0 : use to specify interface

Обратите внимание, что он начнет сбор данных через cronjob: 0-55 / 5 * * * * root / usr / bin / vnstat -u

для Vnstat PHP-Frontend: http://www.sqweek.com/sqweek/index.php?p=1

вы можете запустить что-то вроде iptraf или просто сбросить счетчики ifconfig. на каждом из ваших серверов возьмите выборку за 24 часа, чтобы узнать некоторые средние числа. это даст вам фигуру в парке с мячом.

Думали ли вы о CDN, который может разгрузить ОЧЕНЬ много контента и нагрузку на ваши серверы, на ум приходит облачная вспышка. с распределенным CDN вы действительно можете сократить расходы на сервер и пропускную способность. Зависит от характера вашего приложения и данных, которые вы отправляете своим клиентам.

Ах да, я был в сокращенном режиме CDN = сеть доставки контента

Входящий веб-трафик? Вы имеете в виду с точки зрения браузера или вашего сервера?

Ваши сетевые журналы (надеюсь, apache?) Должны иметь размер контента, доставляемого пользователям.

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

Обязательно конвертируйте из байтов / с в бит / с (8 бит в байте).

Часто счета за трубы выставляются по 95-му процентилю. (ваши первые 5% данных выбрасываются)

Некоторая математика салфетки: 42 ГБ / месяц = ​​~ 1,4 ГБ / день = ~ 0,02 МБ / с = ~ 0,13 МБ / с. Это в среднем. Пик трафика, вероятно, в 2-3 раза больше. Так что ссылка на 1 Мбит / с может помочь.

Это зависит от вашей схемы движения.

Как я уже сказал, вы можете получить это через журналы apache.