Балансинг нагрузки на ресурсах с высокой посещаемостью
26 Mar 2013 | Автор: dd |В одном из проектов мне пришлось прорабатывать тему видеосервера для телепрограммы под высокой нагрузкой, порядка 70-80к уников в сутки, которые генерили около полуляма просмотров, и что самое интересное- единственные кто мне смог дать внятную консультацию- это так называемые AWM, то есть вебмастера работающие в сфере адалта, так как в этой нише условия наиболее приближены к требуемым мне: видео и высокие нагрузки.
После ряда консультаций я продолжил общение с помогавшими мне людьми, так что когда мне предложили статью на тему балансировки нагрузки высоконагруженного сервера, на примере работающего проекта, я не отказался. Далее сохранена авторский стиль изложения. Учитывая что я с несколькими бывшими коллегами вел общение на тему моего проекта и творчества в интернете, то полагаю, что в дальнейшем буду публиковать еще статьи коллег по цеху.
Вебмастера, как правило, не особенно вникают в технические особенности настройки серверов – это дело администраторов. Но логику стоит знать, хотя бы затем, чтобы иметь возможность объяснить своему администратору, как и для чего вы хотите настроить вашу систему.
Рассмотрим для примера сервер, на котором работает система CJ.
Пока посещаемость CJ не превышает 100К в день, беспокоиться особо не о чем, любой Р4 будет легко справляться с таким объемом даже с дефолтными настройками, но если нагрузка на сервер продолжит расти, то процессор начнет испытывать повышенную нагрузку, также, возможно, возникнет недостаток оперативной памяти. В результате ресурс начнет работать медленнее, вплоть до залипания сервера, и вы начнете терять трафик и, соответственно, часть доходов.
Есть очень простой метод, позволяющий повысить производительность сервера без замены железа на более мощное – разделение динамической (скрипты) и статической нагрузок.
В типовой конфигурации сервера у вас есть демон apache, через который и происходит отдача всего контента, он же обслуживает запросы к php и cgi-скриптам. Чем больше функций (php, geo, modrewrite etc.) задействовано в http-демоне, тем больше он занимает памяти и процессорного времени. Для того чтобы отдавать статический контент (картинки, мувики, архивы и т.д.) не требуется функциональность apache с его разнообразными возможностями и дополнительными модулями, достаточно быстрого и легковесного демона с ограниченной функциональностью – например, nginx.
Для реализации подобной схемы нам необходим 1 свободный IP-адрес на сервере. Необходимо указать apache не слушать данный IP, для того чтобы избежать конфликта между разными демонами. Далее вы ставите nginx на выбранный вами IP и указываете ему путь к директории с сайтами – это операцию лучше поручить администраторам.
Вам, как вебмастеру, остается только поменять URL к тумбам в своем ротаторе, чтобы они загружались не через apache, а через nginx. Пример можно посмотреть на 6fetish9.com. В скрипте ротации тумб streamrotator (streamscripts.com) это выглядит так:
В subtemplate заменяется
<img scr=http://6fetish9.com/screamrotator#THUMB#…>
на
<img scr=http://194.99.117/6fetish9.com/streamrotator# THUMB#…>
Далее «свойства тумбы» – Location указывает не на сам домен, а на IP-адрес статик сервера, через который грузится графика.
После выполнения этой несложной операции, вы сразу заметите значительное снижение нагрузки на процессор и память. Если в момент разноса демонов нагрузка на вашем ресурсе уже была высокой, то вы также заметите увеличение продуктивности.
Если же на вашем ресурсе объем трафика превышает 500к в сутки, то стоит всерьез подумать о выносе тумбового трафика на отдельный сервер.
В такой ситуации вам нужно предпринять следующие шаги:
• Приобретаете сервер, с которого будет грузиться только графика – тут мощность не требуется, обычный Р4 потянет до 100Мбит статик-трафика, в случае использования nginx.
• Настраиваете синхронизацию контента:
*при помощи rsync** копируете не весь контент, а только то, что изменялось, 5Гб сиджейного контента синхронизируется за 15-20 минут, в зависимости от количества обновлений контента на оригинальном сервере (мы делаем синхронизацию обычно раз в час по cron).
*устанавливаете nginx на статик-сервер;
*указываете nginx корневую директорию, в которую происходит синхронизация контента сайтов.
• Вебмастеру остается поменять URL к тумбам в ротаторе.
Если у вас уже была настроена статик-схема с nginx на том же сервере, где и apache, то для переезда тумбового трафика на новый статик-сервер достаточно в базе ротатора сменить IP, с которого грузится графика.
Чтобы наглядно проиллюстрировать преимущества подобной схемы, был проведен тест на реально работающих CJ.
Эксперименты проводились на однопроцессорном Атлоне с 1Гб оперативной памяти. На сервере располагалось 14 небольших CJ. Суммарный объем трафика – 160К в сутки.
Перед тестом сервер уже долгое время работал по приведенной выше схеме – обрабатывая только математику, а вся графика грузилась из отдельного статик-сервера от компании webazilla.com.
Вот показатели Mrig и top до начала теста:
Примечание:
top-стандартная *nix программа для базового мониторинга ресурсов системы, на рисунке стоит обратить внимание на показатель load average.
Load average – показывает нагрузки на процессор текущая/средняя за 5 мин/средняя за 15 мин. При нормальной работе на нагруженных серверах, load average обычно не превышает показателя – 3. Если этот показатель достигает 10, то это означает серьезную перегрузку сервера, которая может привести к повисанию сервера.
В 14:50 я начал тест – переключил тумбовый трафик на тот же apache, который обрабатывал математику.
На прилагаемом скрине mrtg хорошо видно, что загрузка канала возросла с 2 до 10Мбит. Четко видно, как после старта теста и до зависания сервера трафик снижался – это связано с тем, что перегруженный сервер не справлялся с нагрузкой и терял посетителей.
Во время теста я каждые 5-10 минут визуально проверял работу доменов, чтобы остановить тест в том случае, если сервер вообще перестанет работать.
В 15:35 (45 минут от начала теста) сервер практически перестал отвечать на запросы, только иногда обновлялись данные в top. Сайты перестали грузиться, выполнять команды в shell не получалось.
15:44 сервер поднялся, благодаря оперативности саппорта.
Сразу после ребута, я поменял настройки, и тумбы продолжили грузиться с того же сервера, но уже не через тяжелый apache, а через nginx. Уровень трафика поднялся навеличину чуть меньшую, чем была до падения, и начал расти, стремясь к прежней величине – это обычное поведение CJ после непродолжительного падения сервера.
Скрин top сделанный через 1 час после восстановления работоспособности сервера.
Сравнив этот скрин с самым первым, вы увидите, что нагрузка при использовании локального статик сервера все равно значительно выше, чем при использовании удалённого сервера, но находится в допустимых пределах для нормального функционирования CJ.
В 17:10 я переключил графический трафик обратно на удалённый статик сервер, и сервер продолжил работать в штатном режиме.
Это график загрузки канала того сервера, с которого грузится графика тестируемого сервера. Провал на графике – показывает отсутствие трафика, который мы переключали на время проведения теста.
На данном графике четко видно, что после окончания тестов загрузка каналов возросла до своей постоянной величины.
В заключение приведу скрин top’a и mrtg своего статик сервера, с которого 6 серверов, подобных серверу, использованному в тесте, хотлинкуют тумбы.
На данном сервере нет работающих CJ, только контент (тумбы), который хотлинкуется через nginx.
Какие выводы можно сделать на основании приведенного теста?
Путём простого переключения тумбового графика на локальный статик-демон, без труда удаётся перегруженный до периодических зависаний сервер превратить в стабильную систему с нагрузкой в пределах нормы.
Кроме оптимизации использования ресурсов сервера, подобные схемы позволяют серьезно сэкономить. Под «математику» (скрипты) рекомендуется использование более дорогих и надежных хостеров, и более мощных серверов, тогда как под значительный тумбовый трафик можно взять хостинг проще и дешевле – однопроцессорный Р4 с 1Гб памяти легко будет держать 100Мбит статики.
Балансинг нагрузки на ресурсах с высокой посещаемостью,