Каково ожидаемое поведение нескольких записей имени хоста с разными IP-адресами в / etc / hosts?

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

Укороченная версия: У меня есть узел хоста OpenVZ с общедоступным 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. Но я хоть убей не могу узнать, какая именно программа делает это. Это Апач? Это что-то в сетевой системе HN? Что-то другое? Кажется, это работает, но я хотел бы узнать больше о том, почему / как, поскольку также существуют большие расхождения во мнениях относительно того, должен работают вообще. Чтобы было ясно, я не ищу здесь циклический перебор или балансировку нагрузки. Просто ручное переключение с одного контейнера OpenVZ на другой.

Версия Lomg: При настройке нескольких скриптов для создания и управления серией контейнеров OpenVZ я создал скрипт под названием make_clone.sh который берет шаблон и создает новый контейнер. Скрипт принимает 2 параметра - идентификатор контейнера и желаемое имя хоста. Одна из вещей, которые он делает, - выделяет новый 10.0.0.* IP-адрес для контейнера и настроить некоторые сети, из которых один элемент помещает запись в хост-узел /etc/hosts файл.

Во время тестирования некоторых сценариев резервного копирования / восстановления для этих контейнеров я хотел «притвориться», что один конкретный контейнер умер, запустить другой с тем же именем и восстановить резервную копию. Вместо того, чтобы удалять исходный контейнер, я просто использовал vzctl stop 130 чтобы отключить его. Затем я создал новый контейнер с идентификатором 131, но с тем же именем. Как только он был запущен, я восстановил базу данных MySQL и проверил (через браузер), что у меня есть доступ к ней - она ​​работает с Joomla с некоторыми настройками - и все было хорошо.

Но потом я заметил, что в хост-узле /etc/hosts, У меня были эти 2 записи (среди прочих):

# Generated by make_clone.sh
10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy

Узел хоста также действует как обратный прокси. Только хост-узел имеет внешний IP-адрес, и его конфигурация Apache эффективно сопоставляет поддомены с контейнерами. Таким образом, помимо приведенных выше записей в / etc / hosts, в конфигурации httpd есть такие разделы:

ServerName 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>

`

В сценарии, который я описываю, из-за сценариев у него будет два таких раздела, но они будут идентичны - он относится к контейнеру по имени хоста, а не по IP, что заставляет меня думать, что это не Apache как таковой выбирает «рабочий» контейнер. Теперь я могу перейти к http://testbackup.xxx.yy/ (очевидно, с использованием настоящего доменного имени), и Apache, похоже, счастлив перенаправить запросы на любой из 10.0.0.130 или 10.0.0.131 вверх. Я могу переключаться между ними, просто приостанавливая / возобновляя работу контейнеров OpenVZ.

Я не ожидал, что это сработает - но приятно, что это работает. Мой вопрос: а должно ли? На это можно положиться? Или это просто случайность, которая перестанет работать, когда всякая ерунда, которая попала в какой-то другой файл конфигурации, будет где-то убрана?