Apache на нескольких серверах с одной конфигурацией
Я хочу копировать свою виртуальную машину и поместить ее позади подсистемы балансировки нагрузки.
Apache1 Apache2 ....ApacheN
| | |
-------------------------
LoadBalancer
Я хотел бы использовать ТОЛЬКО ОДИН конфигурационный файл для виртуальных хостов (на самом деле, каталог conf файлов с Включает в каждый httpd.conf), ОДИН файл журнала и общий каталог DocumentRoot для всех экземпляров. Это возможно, просто совместно использовав некоторый каталог между виртуальными машинами и настраивая каждый Apache соответственно?
Или будет некоторый конфликт с открытием файла и записью?
Существует ли, возможно, лучший способ поддержать все машины с той же конфигурацией?
Единственная другая вещь, о которой я могу думать, это - сценарий, который копирует основную конфигурацию и перезапускает все экземпляры Apache. И также некоторый сценарий для слияния всех журналов...
Любое приветствие предложения.
ОБНОВЛЕНИЕ: Я думал, что в моей производительности случая не была проблема, но я прекратил писать в тот же файл журнала от двух экземпляров, когда я начал замечать повреждение журнала.
[04/Oct/2014:17:10:34 +0200] "GET /index.html HTTP/1.0" 200 15082 22633
[04/Oct/2014:17:10:36 +0200] "GET /index.html HTTP/1.0" 200 15082 13[04/Oct/2014:17:10:38 +0200] "GET /index.html HTTP/1.0"[04/Oct/[04/Oct/2014:17:10:40 +0200] "GET /index.[04/Oct/2014:17:09:42[04/Oct/2014:17:10:42 +0200][04/Oct/2014:17:09:44 +0200] "GET /index.html HTTP/1.0" 200 15082
Вы вполне можете совместно использовать конфигурацию apache и корень документа на многих одинаковых машинах - нет проблем с использованием, например, разделяемого ресурса NFS для этих целей.
Было бы разумно не использовать разделяемые директории журналов apache, потому что при большой нагрузке вы получите много одновременных записей. В одной установке я использовал удалённый syslogging для получения общих логов apache. Это будет отдельный вопрос, как этого добиться. Смотрите http://httpd.apache.org/docs/2.2/mod/core.html в качестве отправной точки для стороны отправителя.
Вы должны настроить ваш (локальный) системный журнал сервера соответствующим образом.
.Может быть, есть лучший способ обслуживания всех машин с одинаковой конфигурацией?
Да, система управления конфигурацией (Кукла, Шеф-повар, ...) является правильным способом решения этой проблемы.
Они могут автоматически развернуть обновленные файлы конфигурации и перезапустить службы после этого.
.
Журналы должны отправляться через (r)syslog на центральный лог-сервер.
Что касается содержимого DocumentRoot: то это зависит от того, что там находится
.
Если это статический код, то предпочтительнее упаковать его и развернуть с помощью стандартных инструментов ОС (yum, apt-get, ...).
.
Это также облегчает медленное развертывание новых версий.
Конечно, можно иметь общий доступ к файлам, но тогда это может действовать как единая точка отказа.
.
И будет больно проверять, какая машина уже перезапустила службу после того, как новая конфигурация была помещена туда по мере того, как вы добавляете новые серверы.
Я бы рекомендовал либо использовать систему управления конфигурациями, например, марионетку или CFEngine, либо, по крайней мере, централизованно хранить конфигурации в одном репозитории и вытаскивать их на все веб-серверы.
Для решения по управлению конфигурацией можно либо указать целые файлы, которые должны существовать, и где получить пустую копию на сервере управления конфигурацией, либо указать параметры этих файлов на языке управления конфигурацией, что обеспечивает уровень абстракции и упрощает процесс внедрения новых конфигураций корректным образом.
Для простого централизованного обслуживания и распространения файлов, вам, вероятно, захочется проверить конфигурационные файлы в программе управления версиями, такой как CVS или SVN. Отсюда есть два довольно простых способа внедрить эти конфигурации во все ваши веб-серверы.
- Затем вы можете поручить вашим веб-серверам извлечь непосредственно из инструмента управления версиями (cvs co или svn checkout)
- С другой стороны, вы можете сделать немного больше работы, чтобы сделать более надежное, масштабируемое и многоразовое решение
- скрипт, создающий RPM всех конфигурационных файлов apache (или их эквивалент для вашей операционной системы)
- запустите yum repo внутри сервера управления версиями (или его эквивалент для вашей операционной системы)
- затем просто проинструктируйте ваши веб-серверы о выполнении yum update my-apache-configs (или его эквивалент для вашей операционной системы).
Решение только для VCS проще всего настроить, и оно будет работать в различных операционных системах. Решение для репозитория пакетов немного сложнее в настройке, но оно проложит вам путь к пакетированию и распространению различного рода конфигураций, кодов и скриптов, а также более тесно согласуется с методологией производителя операционной системы.
Другая приятная вещь в решении для репозитория пакетов - это то, что вы можете определить зависимости и группы пакетов. Это означает, что вы можете сделать my-apache-configs зависимыми от httpd и mod_ssl. Затем вы можете создать пустой пакет, который будет вызываться как company_com-web_server, зависящий от my-apache-configs и my-ssl-сертификатов, а также любых других пакетов, специфичных для вашей компании. Чтобы настроить новый экземпляр веб-сервера, поставьте свежеустановленный сервер (добавьте ваше yum repo к кикстарту) за балансировщиком нагрузки, выпустите yum -y install company_com-web_server, пройдитесь за кофе, и придумайте готовый к прокрутке экземпляр веб-сервера.
===== EDIT =====
Ценность этого механизма в том, что он создает свободно соединенную систему. Если сервер управления конфигурацией или yum repo переходит в автономный режим, вы теряете возможность перенастройки, но веб-серверы остаются в рабочем состоянии. Даже в случае htat, вы можете вручную реплицировать изменения на всех машинах, и проверять изменения в by-hand, когда репо возвращается обратно. Использование общего хранилища (NFS, кластерной файловой системы и т.д.) создаст сбой в одной точке
.