Sé que esto se ha discutidoen varios lugares, pero no parece haber una respuesta definitiva todavía, al menos no para RHEL 6. Solo espero que alguien pueda señalarcómoestá funcionando para que pueda cavar un poco.
Version corta:Tengo un nodo host OpenVZ con una dirección IP pública que actúa como proxy inverso para un grupo de contenedores OpenVZ con direcciones IP privadas. He creado 2 contenedores con el mismo nombre (si quieres saber por qué, salta a la versión larga a continuación), y HN también tiene estas entradas (entre otras) en su /etc/hosts:
# Generated by make_clone.sh
10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy
Puedo usar OpenVZ para suspender/reanudar cualquiera de estos hosts por ID, y el proxy inverso parece enrutar mágicamente las solicitudes a cualquier host que se esté ejecutando (por ejemplo, a una dirección IP 10.0.0.130o 10.0.0.131. Pero no puedo, por mi vida, descubrirlo). ¿Qué parte del software está haciendo esto? ¿Es Apache? ¿Hay algo en el sistema de red de HN? Parece que funciona, pero me gustaría saber más sobre por qué y cómo, ya que también parece haberlo. grandes diferencias de opinión sobre sideberíatrabajar en absoluto. Para ser claros, aquí no estoy buscando una operación por turnos o un equilibrio de carga. Simplemente un cambio manual y sencillo de un contenedor OpenVZ a otro.
Versión Lomg:Mientras configuraba algunos scripts para crear y administrar una serie de contenedores OpenVZ, creé un script llamado make_clone.shque toma una plantilla y crea un nuevo contenedor. El script toma 2 parámetros: el ID del contenedor y el nombre de host deseado. Una de las cosas que hace es asignar una nueva 10.0.0.*dirección IP para el contenedor y configurar algunas redes, de las cuales un elemento es colocar una entrada en el archivo del nodo host /etc/hosts.
Mientras probaba algunos scripts de copia de seguridad/restauración para estos contenedores, quería "fingir" que un contenedor en particular había muerto, activar otro con el mismo nombre y restaurar la copia de seguridad. En lugar de eliminar el contenedor original, solía vzctl stop 130desconectarlo. Luego creé un nuevo contenedor con ID 131, pero con el mismo nombre. Una vez que estuvo activo, restauré la base de datos MySQL y verifiqué (a través de un navegador) que podía acceder a ella (está ejecutando Joomla con algunas personalizaciones) y todo estuvo bien.
Pero luego me di cuenta de que en el nodo host /etc/hoststenía estas 2 entradas (entre otras):
# Generated by make_clone.sh
10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy
El nodo anfitrión también actúa como proxy inverso. Solo el nodo host tiene una dirección IP externa y su configuración de Apache asigna efectivamente subdominios a contenedores. Entonces, además de las entradas anteriores en /etc/hosts, también tiene secciones como esta en la configuración httpd:
` Nombre del servidor 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>
`
En el escenario que estoy describiendo, en realidad terminaría con 2 de estas secciones debido a los scripts, pero serían idénticas: se refiere al contenedor por nombre de host, no por IP, lo que me hace pensar que no es Apache per se el que está seleccionando. el contenedor 'en funcionamiento'. Ahora puedo navegar http://testbackup.xxx.yy/(usando el nombre de dominio real, obviamente) y Apache parece feliz de enrutar las solicitudes al que 10.0.0.130esté 10.0.0.131activo. Puedo cambiar entre ellos simplemente suspendiendo/reanudando los contenedores OpenVZ.
No esperaba que esto funcionara, pero es bueno que funcione. Mi pregunta es, ¿debería hacerlo? ¿Se puede confiar en él? ¿O es simplemente una casualidad que dejará de funcionar cuando se arregle cualquier tontería que haya en algún otro archivo de configuración en algún lugar?
Respuesta1
Dado que un host puede tener varias direcciones IP, lo que estás viendo es el comportamiento esperado. Es como tener múltiples apodos, como: bossman, haus, Jungle-Jim, etc... Todos los que me conocen saben que esos son mis apodos (aunque en realidad no son mis apodos).
A menos que esté intentando acceder al recurso a través de una dirección IP, sus sistemas deberían funcionar como si nada hubiera pasado. (Técnicamente hablando, generar una nueva dirección IP en un contenedor no debería afectar sus servicios, siempre y cuando esos servicios no estén vinculados a la dirección IP. En su caso, es posible que haya tenido suerte con sus aplicaciones ejecutándose sin problemas. )
Ejemplo: podría asignar 4 direcciones IP a un host:
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
Todas esas direcciones IP apuntan atestbackup.xxx.yy, lo que significa que si intento accedertestbackup.xxx.yy, accederé a cualquiera de ellos, dependiendo de qué dirección IP esté activa/responda en el momento de mi solicitud. Nuevamente, esto solo funciona siempre y cuando el servicio al que intenta acceder no esté vinculado específicamente a esa dirección IP.
Sin embargo, si bajaste10.0.0.133, e intentaste acceder al recursoespecíficamentedesde 10.0.0.133 (es decir http://10.0.0.133/), obtendría un error.
ACTUALIZAR:
Si está utilizando 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>
Esta configuración permitirá que dos sitios utilicen la misma dirección IP y puerto. Si así es como configura sus VirtualHosts, entonces VirtualHosts está manejando su enrutamiento automático (si enumeró ambos ServerNamecampos como el mismo host, en teoría).
Indicaste que estabas usando OpenVZ. OpenVZ puede permitir que sus sitios se ejecuten de forma independiente, pero físicamente todos están en el mismo host. A menos que asigne a cada VE individual su propio nombre de host e intente acceder a ese nombre de hostespecíficamenteMientras esté inactivo, obtendrá el comportamiento esperado del sitio cuando esté activo.
Por ejemplo, si asignó un nombre de host diferente a una de las direcciones OpenVZ/IP:
10.0.0.133 mybackup.xxx.yy
Si lo eliminas 10.0.0.133, ya no podrás acceder a él desde mybackup.xxx.yy, pero sí podrás acceder a él desde testbackup.xxx.yy(porque pasa por las otras direcciones IP que todavía están activas y asociadas con testbackup.xxx.yy).
