Обработка файлов журнала и конфигурации при балансировке нагрузки apache

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

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

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

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

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

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

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

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

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

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


person Sandman    schedule 28.07.2011    source источник


Ответы (3)


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

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

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

person Zac Thompson    schedule 24.09.2011
comment
Большое спасибо за комментарии. Я хорошо знаю единую точку отказа, но мне все еще нужно централизовать ведение журнала. - person Sandman; 26.09.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

на веб-сервере 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 может быть сложным, если у вас нет root-доступа к экспорту NFS, потому что обычно ваша система управления пакетами будет жаловаться на невозможность изменить какой-либо файл конфигурации.

person jeremyjr    schedule 27.09.2011
comment
Большое спасибо за ответ, очень исчерпывающий! - person Sandman; 08.11.2011

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

puppetlabs.com

person Stephen    schedule 27.03.2012