1 registro A para cada subdominio (10000+); cualquier problema potencial? ¿Alguna otra solución?

Question

La mayoría de las soluciones que he leído aquí para admitir el subdominio por usuario en el nivel DNS son apuntar todo a una IP usando * .dominio.com.

Es una solución fácil y simple, pero ¿qué sucede si quiero señalar los primeros 1000 usuarios registrados al servidor A y los siguientes 1000 usuarios registrados al servidor B? Esta es la solución preferida para mantener bajos nuestros costos en software y hardware para la agrupación.

texto alternativo http://learn.iis.net/file.axd?i = 1101 (diagrama citado del sitio de MS IIS)

La solución más lógica parece tener 1 x A-record por subdominio en Zone Datafiles. BIND no parece tener ningún límite de tamaño en los archivos de datos de zona, solo está restringido a la memoria disponible.

Sin embargo, mi equipo está preocupado por la latencia de tener el nuevo subdoamin listo y listo, ya que crear un nuevo subdominio consiste en insertar un nuevo registro A & amp; reiniciando el servidor DNS.

¿Es el rendimiento de reiniciar el servidor DNS algo de lo que deberíamos preocuparnos?

Gracias de antemano.

UPDATE:

Parece que la mayoría de ustedes me sugiere que use una configuración de proxy inverso en su lugar:

texto alternativo http://learn.iis.net/file.axd?i = 1102

(ARR es la solución de proxy inverso de IIS7)

Sin embargo, aquí están los CONS que puedo ver:

1. punto único de falla
2. no puede configurar servidores estratégicamente en diferentes ubicaciones según la geolocalización de IP.

Answer 1

El proxy front-end con una entrada de DNS comodín realmente es el camino a seguir con esto. Es cómo funcionan los sitios grandes como LiveJournal.

Tenga en cuenta que esto no es solo un equilibrador de carga de capa TCP: hay muchas soluciones que examinarán la parte del host de la URL para determinar qué servidor de fondo reenviará la consulta también. Puede hacerlo fácilmente con Apache ejecutándose en un servidor de baja especificación con configuración adecuada .

El proxy garantiza que la sesión de cada usuario siempre vaya al servidor de fondo correcto y que la mayoría de los métodos de manejo de sesiones seguirán funcionando.

Además, el proxy no necesita ser un solo punto de falla. Es perfectamente posible y bastante fácil ejecutar dos o más proxies front-end en una configuración redundante (para evitar fallas) o incluso hacer que compartan la carga (para evitar el estrés).

También respaldaría la sugerencia de John Sheehan de que la aplicación solo mire la parte izquierda de la URL para determinar qué contenido del usuario mostrar.

Si usa Apache para el back-end, consulte esta publicación también para obtener información sobre cómo configurarlo.

Answer 2

Use la entrada DNS comodín, luego use el equilibrio de carga para distribuir la carga entre los servidores, independientemente del cliente que sean.

Mientras lo hace, omita el paso de reescritura de URL y haga que su aplicación determine qué cuenta se basa en la URL tal como se ingresó (puede determinar fácilmente qué X está en X.domain.com como en el dominio. com? user = X).

EDITAR: Según su información adicional, es posible que desee desarrollar un "corredor" que almacena qué clientes deben acceder a qué servidores. Haga esa orientación pública y luego extraiga de los recursos asociados con el cliente almacenados con el corredor. Su front-end puede equilibrarse con la carga, luego puede tomar de los servidores de archivos / db en función de quiénes son.

Answer 3

Si usa tinydns, no necesita reiniciar el servidor de nombres si modifica su base de datos y no debería ser un cuello de botella porque generalmente es muy rápido. Sin embargo, no sé si funciona bien con más de 10000 entradas (me sorprendería si no).

http://cr.yp.to/djbdns.html