Какие инструменты мне следует использовать для оценки пропускной способности фермы веб-серверов?
Я обдумываю перемещение центра обработки данных, и мне нужно знать размер трубы, которая понадобится мне, чтобы получить предложение.
В настоящее время с меня взимается гигабайт трафика в месяц (в настоящее время около 42 Гб входящего трафика - так что только запросы), но новый моб вместо этого арендовал бы мне канал, и размер его определяет цену.
У меня есть несколько веб-серверов Centos и один сервер баз данных за балансировщиком нагрузки; веб-серверы обращаются к серверу базы данных, но общедоступные - нет (то есть напрямую).
Очевидным местом для измерения использования полосы пропускания является балансировщик нагрузки, но у меня нет к нему доступа, и мой нынешний центр обработки данных хочет, чтобы за ним следили рука и нога.
Это то, что я могу легко сделать с моих веб-серверов Linux?
Я начал изучать такие инструменты, как ntop и bandwidthd, но подумал, что сначала мне понадобится совет специалиста.
Я думаю, что мне нужно сделать, это посмотреть трафик между каждым веб-сервером и IP-адресом loadbalancer и сложить их вместе. Такие инструменты, как ntop, показывают трафик между серверами и удаленным IP, но не между сервером и промежуточным IP...
Есть какие-нибудь подсказки?
4 ответа
Вам действительно нужна точная цифра (что бы это ни значило), чтобы сделать это? Зная, что вы в настоящее время используете 100 Мбит / с или 150,3528 Мбит / с, вы что-то измените? Может быть, вам не нужно собирать эти данные, чтобы узнать цены.
Какие варианты цены / цены они предлагают? Если они не предлагают их, попросите цитаты в группах, которые имеют смысл для вас. Вы можете получить более выгодную сделку, не раскрывая заранее, сколько вам на самом деле нужно, а вместо этого заставьте их раскрыть структуру ценообразования. И информация может быть полезна в будущем, когда вам нужно обновить.
Что платит то, что вы можете себе позволить? Если это даст вам больше, чем вы ожидаете, сейчас или в ближайшие несколько месяцев, тогда спуститесь на уровень ниже и снова спросите, нужно ли вам столько труб. Повторяйте, пока не найдете хороший баланс цены / трубы.
Затем посмотрите на варианты для обновления. Сколько времени займет обновление? Их дополнительные расходы изменятся позже? Сколько это будет стоить, чтобы иметь слишком маленькую трубу на время, необходимое для реализации и реализации изменений? Это может побудить вас пойти на большую трубу.
Ответы на эти вопросы также будут полезны в счастливых обстоятельствах, когда вам нужна дополнительная пропускная способность, потому что вы так успешны в будущем!
Вы можете запустить что-то вроде iptraf или просто или сбросить счетчики ifconfig. на каждом из ваших серверов возьмите пример за 24 часа, чтобы узнать средние числа. это даст вам фигуру парковой зоны.
Задумывались ли вы о CDN, который может разгрузить МНОГО доставки контента и загрузить на ваши серверы? с распределенным CDN вы действительно сможете сократить расходы на сервер и пропускную способность. Зависит от характера вашего приложения и данных, передаваемых вашим клиентам.
О да, я был в режиме аббревиатуры CDN = сеть доставки контента
Входящий веб-трафик? Вы имеете в виду с точки зрения браузера или вашего сервера?
Ваши блоги (надеюсь, apache?) Должны иметь размер контента, доставляемого пользователям.
Вы можете использовать эти байты с временными метками, чтобы определить, какой объем трафика уходит.
Обязательно выполните преобразование из байтов / с в бит / с (8 бит в байте).
Часто трубы выставляются по 95-му процентилю. (ваши лучшие 5% данных выбрасываются)
Немного математики для салфеток: 42 ГБ / месяц = ~ 1,4 ГБ / день =~ 0,02 МБ / с =~ .13 МБ / с. Это в среднем. Ваши пики трафика, вероятно, в 2-3 раза больше. Так что ссылка на 1 Мбит / с может помочь.
Это зависит от ваших моделей трафика.
Как я уже сказал, вы можете получить это через логи apache.
Вы можете использовать vnstat для мониторинга вашего входящего и исходящего трафика. Это консольный монитор сетевого трафика, он ведет журнал часов, ежедневно и ежемесячно, также вы можете использовать vnstat php-frontend для графического мониторинга.
Конфигурация:
ням установить внстат
После установки вам нужно создать базу данных с помощью следующей команды:
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
для PHP-интерфейса Vnstat: http://www.sqweek.com/sqweek/index.php?p=1