Necesitaría poder hacer lo siguiente:
- Apuntar N dominios a una IP, cambiando el registro tipo A de dichos dominios
- En dicha IP, en dicho servidor, poder desviar/enrutar/redirigir el tráfico a un servidor u otro dependiendo del dominio que llegara
Esto es para poder decirle a los clientes: pon esta IP en el registro A de tu dominio. Pero nosotros realmente tener los dominios alojados en varios servidores, así poder mover nosotros los dominios de un servidor a otro sin tener que el cliente volver a cambiar la IP. Para reparto de carga, para operaciones de mantenimiento, utilizar datacenters más cercanos al cliente, etc. Le veo muchas ventajas al tema.
He visto que se puede hacer algo similar con el mod_proxy de apache, pero me pregunto si existe algún método mejor o más correcto.
Puedes conseguir prácticamente lo mismo de forma más eficiente y sencilla por DNS, me explico:
- Todos tus clientes usan los servidores DNS de tu empresa (ns1.tuempresa.com, ns2.tuempresa.com), que incluso podrían ser nameservers "personalizados" por cliente (ns1.cliente1.com y ns2.client1.com para un cliente, etc.). Tan solo necesitas un par de servidores BIND.
- Al encargarte de la gestión de los servidores DNS tienes control total: puedes apuntar a otra IP un dominio, migrar todos los dominios de una máquina a otra cambiado de IP, etc.. y todo ello de forma transparente para tus clientes y sin corte [1].
Así es como funcionan, por ejemplo, las empresas de hosting, donde tienen miles de dominios distribuidos en cientos de servidores y realizan tareas de este tipo a diario.
También podrías hacerlo en capa HTTP, con HAproxy, mod_proxy o nginx como propones. Sería la opción que te daría más flexibilidad (con HAproxy podrías hacer magia negra) pero la menos eficiente: piensa que todo el tráfico va a pasar por ese "puente", posible punto de fallo, etc.. DNS sería la solución más eficiente: te aprovechas del caching en los clientes, ISP, etc.. y las conexiones serían directas desde el cliente hasta el servidor, sin puntos intermedios, tan solo una primera resolución DNS, que además la controlas tu.
[1] 24/48 horas antes del cambio de IP, tendrías que bajar el TTL a un tiempo que consideres razonable (1 minuto? 1 hora?), de este modo evitas que durante el cambio los servidores DNS de los ISP devuelvan IP antigua.
Habiamos pensado lo de los name servers, de hecho hemos estudiado el servicio Route53 de AWS. Es una opción, sin duda :)
El problema que le veo a poner los NS nuestros, es el tema de los correos, o de otros servicios que el cliente pueda querer gestionar en su dominio. Deberíamos entonces habilitar una forma para que ellos pudieran hacer cambios en la configuración DNS de su dominio, cosa que al final implica más soporte, más incidencias...
Igual haciendo que el registro A no lo pudieran tocar, y que los otros sí... Lo pensaremos.
Pero sin duda, creo que el HAProxy es lo que más se parece a lo que buscamos.
Si quieres que tus clientes puedan modificar la configuración DNS puedes montar algo tipo al panel de control Plesk, donde podrías prepararles una interfaz "capada" con lo mínimo indispensable: añadir registros, editar, borrar, etc. Si ya tienes un panel de control puedes integrar esta funcionalidad a través de la API del panel [1].
Tampoco descartes la solución de los CNAMEs que te han recomendado.
Como te decía, descartaría utilizar HAproxy si puedes hacerlo en la capa DNS. Piensa que cada petición HTTP será una conexión desde el cliente hasta el proxy y a su vez desde aquí una nueva conexión a los backend de HAproxy, que por lo que comentas pueden estar en otros datacenters, etc. Si sigues adelante con esta configuración, revisa que HAproxy haga uso de conexiones HTTP persistentes contra los backends para evitar el overhead del TCP handshake por cada nueva petición.
Podrías pedir a tus clientes que creen un registro de tipo CNAME apuntando a algo que controléis vosotros, un dominio en exclusiva para estas cosas, de forma que podéis cambiar la IP final sin que el cliente tenga que hacer nada, por ejemplo
Gracias a vuestros comentarios parece claro que la solución del HAProxy es lo que necesitamos.
Ahora, la segunta parte :) ¿Conocéis algún servicio para HAProxy, es decir, que podamos utilizar su infraestructura para implantar el reverse proxy? El ElasticLoadBalancer de Amazon es solo para instancias de EC2.
Necesitaría poder hacer lo siguiente:
- Apuntar N dominios a una IP, cambiando el registro tipo A de dichos dominios
- En dicha IP, en dicho servidor, poder desviar/enrutar/redirigir el tráfico a un servidor u otro dependiendo del dominio que llegara
Esto es para poder decirle a los clientes: pon esta IP en el registro A de tu dominio. Pero nosotros realmente tener los dominios alojados en varios servidores, así poder mover nosotros los dominios de un servidor a otro sin tener que el cliente volver a cambiar la IP. Para reparto de carga, para operaciones de mantenimiento, utilizar datacenters más cercanos al cliente, etc. Le veo muchas ventajas al tema.
He visto que se puede hacer algo similar con el mod_proxy de apache, pero me pregunto si existe algún método mejor o más correcto.
Gracias.
29/04/2013 17:14
29/04/2013 17:40
- Todos tus clientes usan los servidores DNS de tu empresa (ns1.tuempresa.com, ns2.tuempresa.com), que incluso podrían ser nameservers "personalizados" por cliente (ns1.cliente1.com y ns2.client1.com para un cliente, etc.). Tan solo necesitas un par de servidores BIND.
- Al encargarte de la gestión de los servidores DNS tienes control total: puedes apuntar a otra IP un dominio, migrar todos los dominios de una máquina a otra cambiado de IP, etc.. y todo ello de forma transparente para tus clientes y sin corte [1].
Así es como funcionan, por ejemplo, las empresas de hosting, donde tienen miles de dominios distribuidos en cientos de servidores y realizan tareas de este tipo a diario.
También podrías hacerlo en capa HTTP, con HAproxy, mod_proxy o nginx como propones. Sería la opción que te daría más flexibilidad (con HAproxy podrías hacer magia negra) pero la menos eficiente: piensa que todo el tráfico va a pasar por ese "puente", posible punto de fallo, etc.. DNS sería la solución más eficiente: te aprovechas del caching en los clientes, ISP, etc.. y las conexiones serían directas desde el cliente hasta el servidor, sin puntos intermedios, tan solo una primera resolución DNS, que además la controlas tu.
[1] 24/48 horas antes del cambio de IP, tendrías que bajar el TTL a un tiempo que consideres razonable (1 minuto? 1 hora?), de este modo evitas que durante el cambio los servidores DNS de los ISP devuelvan IP antigua.
Santi Saez
29/04/2013 18:03
El problema que le veo a poner los NS nuestros, es el tema de los correos, o de otros servicios que el cliente pueda querer gestionar en su dominio. Deberíamos entonces habilitar una forma para que ellos pudieran hacer cambios en la configuración DNS de su dominio, cosa que al final implica más soporte, más incidencias...
Igual haciendo que el registro A no lo pudieran tocar, y que los otros sí... Lo pensaremos.
Pero sin duda, creo que el HAProxy es lo que más se parece a lo que buscamos.
30/04/2013 14:55
Tampoco descartes la solución de los CNAMEs que te han recomendado.
Como te decía, descartaría utilizar HAproxy si puedes hacerlo en la capa DNS. Piensa que cada petición HTTP será una conexión desde el cliente hasta el proxy y a su vez desde aquí una nueva conexión a los backend de HAproxy, que por lo que comentas pueden estar en otros datacenters, etc. Si sigues adelante con esta configuración, revisa que HAproxy haga uso de conexiones HTTP persistentes contra los backends para evitar el overhead del TCP handshake por cada nueva petición.
Santi Saez
[1] http://download1.parallels.com/Plesk/PP10/10.1.1/Doc/en-US/online/plesk-api-rpc/34756.htm
29/04/2013 22:49
www.dominiomicliente.com -> CNAME micliente.midominioservers.com
micliente.midominioservers.com -> A xxx.xxx.xxx.xxx
30/04/2013 08:48
Ahora, la segunta parte :) ¿Conocéis algún servicio para HAProxy, es decir, que podamos utilizar su infraestructura para implantar el reverse proxy? El ElasticLoadBalancer de Amazon es solo para instancias de EC2.