Я знаю, что это обсуждалось.в несколько места, но, похоже, пока нет однозначного ответа - по крайней мере, для RHEL 6. Я просто надеюсь, что кто-нибудь сможет указать накакэто работает, так что я могу немного покопать.
Укороченная версия:У меня есть узел OpenVZ Host с публичным IP-адресом, который действует как обратный прокси для группы контейнеров OpenVZ с частными IP-адресами. Я создал 2 контейнера с одинаковым именем (если хотите узнать почему, перейдите к длинной версии ниже), и HN также имеет эти записи (среди прочих) в своем /etc/hosts:
# Generated by make_clone.sh
10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy
Я могу использовать OpenVZ для приостановки/возобновления работы любого из этих хостов по идентификатору, и обратный прокси-сервер, похоже, волшебным образом направляет запросы на любой работающий хост (например, на IP-адрес 10.0.0.130или 10.0.0.131. Но я не могу понять, какая часть программного обеспечения это делает. Apache? Что-то в сетевой системе HN? Что-то еще? Кажется, это работает, но я хотел бы узнать больше о том, почему/как, поскольку также существуют большие разногласия относительно того,долженРаботает вообще. Чтобы было ясно, я не ищу здесь циклический перебор или балансировку нагрузки. Просто простое ручное переключение с одного контейнера OpenVZ на другой.
Версия Lomg:При настройке некоторых скриптов для создания и управления серией контейнеров OpenVZ я создал скрипт под названием , make_clone.shкоторый берет шаблон и создает новый контейнер. Скрипт принимает 2 параметра — идентификатор контейнера и желаемое имя хоста. Одна из вещей, которую он делает, — это выделяет новый 10.0.0.*IP-адрес для контейнера и настраивает некоторые сетевые параметры, один из элементов которых помещает запись в файл узла хоста /etc/hosts.
Тестируя некоторые скрипты резервного копирования/восстановления для этих контейнеров, я хотел «притвориться», что определенный контейнер умер, запустить другой с тем же именем и восстановить резервную копию. Вместо того, чтобы на самом деле удалить исходный контейнер, я просто переводил vzctl stop 130его в автономный режим. Затем я создал новый контейнер с идентификатором 131, но с тем же именем. Когда он заработал, я восстановил базу данных MySQL и проверил (через браузер), что могу получить к ней доступ — на нем работает Joomla с некоторыми настройками — и все было хорошо.
Но затем я заметил, что в Host Node /etc/hostsу меня есть эти 2 записи (среди прочих):
# Generated by make_clone.sh
10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy
Host Node также действует как обратный прокси-сервер. Только Host Node имеет внешний IP-адрес, а его конфигурация Apache эффективно отображает поддомены на контейнеры. Таким образом, помимо записей выше в /etc/hosts, он также имеет такие разделы в конфигурации httpd:
` Имя_сервера testbackup.xxx.yy
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /server-status !
ProxyPass / http://testbackup.xxx.yy/
ProxyPassReverse / http://testbackup.xxx.yy/
<Location />
Order allow,deny
Allow from all
</Location>
`
В сценарии, который я описываю, на самом деле получится 2 таких раздела из-за скриптов, но они будут идентичны — он ссылается на контейнер по имени хоста, а не по IP, что заставляет меня думать, что это не Apache как таковой выбирает «рабочий» контейнер. Теперь я могу перейти к http://testbackup.xxx.yy/(используя реальное доменное имя, очевидно), и Apache, похоже, с радостью направит запросы на тот из 10.0.0.130или , 10.0.0.131который работает. Я могу переключаться между ними, просто приостанавливая/возобновляя работу контейнеров OpenVZ.
Я не ожидал, что это сработает, но хорошо, что это работает. Мой вопрос: должно ли это работать? Можно ли на это положиться? Или это просто случайность, которая перестанет работать, когда какая-то мелочь, попавшая в какой-то другой файл конфигурации, будет убрана?
решение1
Поскольку хост может иметь несколько IP-адресов, то, что вы видите, является ожидаемым поведением. Это как иметь несколько ников, например: bossman, haus, jungle-jim и т. д... Все, кто меня знает, знают, что это мои ники (хотя на самом деле это не мои ники).
Если вы не пытаетесь получить доступ к ресурсу через IP-адрес, ваши системы должны работать так, как будто ничего не произошло. (Технически говоря, генерация нового IP-адреса в контейнере не должна повлиять на ваши службы, если только эти службы не привязаны к IP-адресу. В вашем случае вам, возможно, просто повезло, и ваши приложения работают без сбоев.)
Пример: я могу назначить 4 IP-адреса одному хосту:
10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy
10.0.0.132 testbackup.xxx.yy
10.0.0.133 testbackup.xxx.yy
Все эти IP-адреса указывают наtestbackup.xxx.yy, что означает, что если я попытаюсь получить доступtestbackup.xxx.yy, я доберусь до любого из них, в зависимости от того, какой IP-адрес активен/отзывчив на момент моего запроса. Опять же, это работает только до тех пор, пока служба, к которой вы пытаетесь получить доступ, не привязана конкретно к этому IP-адресу.
Однако, если вы сняли10.0.0.133, и вы попытались получить доступ к ресурсуконкретнос 10.0.0.133 (т.е. http://10.0.0.133/) вы получите ошибку.
ОБНОВЛЯТЬ:
Если вы используете Apache VirtualHosts:
<VirtualHost *:80>
DocumentRoot /www/example1
ServerName www.example.com
# Other directives here
</VirtualHost>
<VirtualHost *:80>
DocumentRoot /www/example2
ServerName www.example.org
# Other directives here
</VirtualHost>
Эта конфигурация позволит двум сайтам использовать один и тот же IP-адрес и порт. Если так настроен ваш VirtualHosts, то VirtualHosts обрабатывает вашу автоматическую маршрутизацию (если вы указали оба ServerNameполя как один и тот же хост, теоретически).
Вы указали, что используете OpenVZ. OpenVZ может позволить вашим сайтам работать независимо, но физически они все находятся на одном хосте. Если только вы не назначаете каждому отдельному VE свое имя хоста и не пытаетесь получить доступ к этому имени хостаконкретнопока он недоступен, вы получите ожидаемое поведение работающего сайта.
Например, если вы назначили другое имя хоста одному из адресов OpenVZ/IP:
10.0.0.133 mybackup.xxx.yy
Если вы отключите его 10.0.0.133, вы больше не сможете получить к нему доступ mybackup.xxx.yy, но сможете получить к нему доступ с testbackup.xxx.yy(поскольку он проходит через другие IP-адреса, которые все еще работают и связаны с testbackup.xxx.yy).
