Я хочу реплицировать свою виртуальную машину и поставить ее за балансировщик нагрузки.
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
Может быть, есть лучший способ поддерживать все машины с одинаковой конфигурацией?
Да, система управления конфигурацией (Puppet, Chef, ...) - правильный способ справиться с этим.
Они могут автоматически развертывать обновленные файлы конфигурации и после этого перезапускать службы.
Журналы следует отправлять через (r) syslog на центральный сервер журналов.
Что касается содержимого DocumentRoot: это зависит от того, что там находится.
Если это статический код, предпочтительнее было бы упаковать его и развернуть с помощью стандартных инструментов ОС (yum, apt-get, ...).
Это также упрощает медленное развертывание новых версий.
Конечно, можно иметь общий файловый ресурс, но тогда это может стать единственной точкой отказа.
И будет больно проверять, какая машина уже перезапустила службу после того, как новая конфигурация была помещена туда, когда вы добавляете больше серверов.
Вы можете использовать конфигурацию apache и корень документа на многих идентичных машинах - без проблем, например, общий ресурс NFS для этих целей.
Было бы разумно не делиться каталогами журналов apache, потому что при большой нагрузке вы получите много одновременных записей. В одной из установок я использовал удаленное ведение системного журнала для получения общих журналов apache. Как этого добиться - это отдельный вопрос. Видеть http://httpd.apache.org/docs/2.2/mod/core.html в качестве отправной точки для отправителя.
Вам нужно будет соответствующим образом настроить системный журнал (локальный сервер).
Я бы рекомендовал либо использовать систему управления конфигурациями, такую как puppet или CFEngine, либо хотя бы централизованно хранить конфигурации в едином репозитории и передавать их на все веб-серверы.
Для решения по управлению конфигурацией вы можете либо указать целые файлы, которые должны существовать, и место для получения канонической копии на сервере управления конфигурацией, либо вы можете указать параметры для этих файлов на языке управления конфигурацией, который обеспечивает уровень абстракции и упрощает процесс ввода новых конфигураций правильным образом.
Для простого централизованного обслуживания и распространения файлов вы, вероятно, захотите проверить файлы конфигурации в программном обеспечении для контроля версий, таком как CVS или SVN. Отсюда есть два довольно простых способа добавить эти конфигурации на все ваши веб-серверы.
Решение только для VCS проще всего настроить и будет работать в разных операционных системах. Решение для репозитория пакетов немного сложнее настроить, но оно откроет вам путь к упаковке и распространению конфигураций, кодов и сценариев всех видов и более точно соответствует методологии поставщика ОС.
Еще одна приятная особенность решения для репозитория пакетов - это возможность определять зависимости и группы пакетов. Это означает, что вы можете сделать мои-апач-конфиги зависит от httpd и mod_ssl. Затем вы можете создать пустой пакет, который вы называете чем-то вроде company_com-web_server это зависит от мои-апач-конфиги и мои-ssl-сертификаты и любые другие пакеты, характерные для вашей компании. Чтобы настроить новый экземпляр веб-сервера, поместите только что установленный сервер (добавьте репозиторий yum в кикстарт) за балансировщиком нагрузки, выполните команду yum -y установить company_com-web_server, выйдите на чашку кофе и вернитесь с готовым экземпляром веб-сервера.
===== РЕДАКТИРОВАТЬ =====
Ценность этого механизма в том, что он создает слабосвязанную систему. Если сервер управления конфигурацией или репозиторий yum отключаются, вы теряете возможность перенастроить, но веб-серверы продолжают работать. Даже в экземпляре htat вы можете вручную реплицировать изменения на все машины и проверять изменения вручную, когда репо возвращается. Использование общего хранилища (NFS, кластерная файловая система и т. Д.) Приведет к единому отказу.