Обработка журналов и файлов конфигурации при балансировке нагрузки apache - PullRequest
9 голосов
/ 28 июля 2011

Итак, в настоящее время я перестраиваю свою веб-платформу с одного компьютера на кластер машин, и для этого я буду использовать балансировку нагрузки Apache, но у меня есть два вопроса, на которые мне нужно получить хороший ответ, прежде чем продолжить,Я гуглил и искал здесь в SO, но ничего хорошего не нашел.

Моей установкой будет одна машина Debian, на которой работает сервер балансировки нагрузки Apache (т.е. Apache с mod_proxy), а затем любое количество «ведомых»машины, которые являются балансирующими членами.Все это VPS внутри машины VMWare, поэтому настройка новых ведомых устройств по мере необходимости будет тривиальной.

Файлы журналов Первый вопрос - это файлы журналов.Чтобы устранить неполадки в моей платформе, мне иногда нужно проанализировать файлы журналов, как журналы доступа, так и журналы ошибок, из Apache.Когда нагрузка распределяется равномерно (т.е. я не знаю, буду ли я использовать липкое балансирование, любой хост, вероятно, сможет обработать любой запрос в любое время), так же как и файлы журнала для каждого подчиненного экземпляра Apache.Есть ли способ объединить эти live , что означает, что мой анализатор журналов в реальном времени мог видеть файлы журналов со всех хостов?Я, конечно, понимаю, что делать это, пока файлы находятся на нескольких хостах, будет сложно, поэтому есть ли способ убедиться, что все файлы журналов хранятся на одном сервере?

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

syslogd Первый - это syslogd, где несколько хостов могли бы выполнять запись на один хост регистрации.Проблема в том, что в моей текущей настройке каждый виртуальный хост в apache имеет свой собственный файл журнала.Возможно, это можно исправить каким-то образом.Я использую это для устранения неполадок, а не для ведения отдельных журналов для каждого хоста (хотя, если бы обе цели были достигнуты, это, безусловно, было бы бонусом).

NFS Моя следующая мысль былао NFS, то есть наличие общего ресурса NFS в локальной сети, где каждый ведомый может записывать в один и тот же файл журнала.Я собираюсь пойти дальше и предположить, что это будет трудно, поскольку ведомое устройство 1 откроет файл журнала, а затем ведомое устройство 2 не сможет выполнить запись в него.

Как я уже сказал, ваш вклад оченьпризнателен, поскольку я чувствую, что застрял в том, как решить эту проблему.

Файлы конфигурации Это совсем другое дело.Каждый ведомый будет отвечать на каждый запрос, как если бы он действовал как один отдельный сервер.Вот и вся идея.Но как насчет внесения изменений в файлы конфигурации apache, добавления виртуальных хостов, настройки других параметров?Что если у меня десять рабов или пятьдесят?Есть ли способ убедиться, что все эти рабы всегда синхронизированы?Я уже использую экспорт NFS, чтобы убедиться, что все они имеют одинаковые файлы, но должен ли я использовать тот же подход с файлами конфигурации?Или я должен иметь их в качестве хранилища, а затем использовать rsync, чтобы скопировать их на подчиненные?Одна из проблем заключается в том, что в моей веб-платформе я создал интерфейс, который редактирует эти файлы конфигурации (а именно файл с виртуальными хостами), и, поскольку это действие будет выполняться на одном из ведомых устройств, самая последняя копия этого файла может потенциальнобыть одним рабом.

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

Я надеюсь, что кто-то там может помочь мне, как и вы раньше!Заранее спасибо!

Ответы [ 3 ]

5 голосов
/ 27 сентября 2011

Я предлагаю не использовать NFS для ведения журналов, поскольку это может сильно снизить производительность. Вместо этого используйте rsyslog с включенной удаленной регистрацией. В вас apache2.conf вы можете настроить LogFormat, который включает имя VirtualHost, а затем направить журнал в rsyslog, сообщив ему записать вывод на удаленный хост.

В apache2.conf:

LogFormat "%v %{X-FORWARDED-FOR}i %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
CustomLog "|/usr/bin/logger -t apache2 -p local7.info" vhost_combined

В rsyslog.conf на веб-сервере:

local7.* @<remote host ip>

В rsyslog.conf на удаленном хосте:

local7.*    /var/log/webfrontends.log;precise

Что касается файлов конфигурации Apache, мы используем NFS.
apache2.conf - это ссылка на удаленный файл (при необходимости, разные файлы для разных машин), а в apache2.conf мы используем директиву Include для чтения конкретных конфигураций сайта (при необходимости, разные директории для разных машин)

на NFS-сервере экспортированный каталог NFS /NFS_EXPORT/etc/apache2/ содержит:

 - webserver1_apache2.conf
 - webserver2_apache2.conf
 - webserver1_vhosts (dir)
 - webserver2_vhosts (dir)

И webserver1_apache2.conf, и webserver2_apache2.conf содержат Include "/etc/apache2/vhosts"

на веб-сервере 1

ln -s /NFS_EXPORT/etc/apache2/webserver1_apache2.conf /etc/apache2/apache2.conf
ln -s /NFS_EXPORT/etc/apache2/webserver1_vhosts/ /etc/apache2/vhosts

на WebServer 2

ln -s /NFS_EXPORT/etc/apache2/webserver2_apache2.conf /etc/apache2/apache2.conf
ln -s /NFS_EXPORT/etc/apache2/webserver2_vhosts/ /etc/apache2/vhosts

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

Конечно, вам понадобится скрипт или какой-то другой механизм для перезапуска apache на всех ваших серверах после изменения конфигурации. Кроме того, обновление программного обеспечения apache2 может быть сложным, если у вас нет корневого доступа к экспорту NFS, поскольку обычно ваша система управления пакетами будет жаловаться на невозможность изменить какой-либо файл конфигурации.

4 голосов
/ 24 сентября 2011

NFS не поможет вам с файлами журналов, именно по тем причинам, которые вы описали выше. Вы должны использовать syslogd (или другое решение, такое как Splunk) для централизации ведения журнала. Обязательно включить информацию о том, с какого хоста поступает запись в журнале, чтобы при устранении неполадок вы все еще могли распознать данные для каждого хоста.

Конфигурационные файлы: вам нужно либо централизовать их («основная» копия), либо иметь способ распространения изменений, внесенных на любом сервере, на все остальные. Я рекомендую централизацию как более простой подход. NFS выполнит эту работу здесь, или, как вы предлагаете, хранилище, из которого все хосты периодически обновляются. Здесь есть много вариантов, вплоть до контроля версий (SVN, git и т. Д.) Или даже серверов конфигурации (Chef и т. Д.).

Обратите внимание, что переход с одного сервера на кластер имеет много последствий. В обоих вышеупомянутых случаях (ведение журнала, файлы конфигурации) существует вероятность появления отдельных точек отказа, если все сделано наивно. Поскольку он у вас уже есть (один сервер), вы не в худшем положении, но вам следует постараться быть в курсе и планировать сценарии сбоев, на которые вам, возможно, придется реагировать.

0 голосов
/ 28 марта 2012

Используйте инструмент, созданный для этой работы - Puppet предназначен для управления файлами конфигурации на нескольких серверах. Существует инструмент с открытым исходным кодом или вы можете получить их версию Enterprise.

puppetlabs.com

...