¿El DNS Round-Robin es "suficientemente bueno" para equilibrar la carga de contenido estático?

Tenemos un conjunto de contenido compartido y estático que servimos entre nuestros sitios web en http://sstatic.net . Desafortunadamente, este contenido no tiene una carga balanceada actualmente, se sirve desde un solo servidor. Si ese servidor tiene problemas, todos los sitios que dependen de él están efectivamente inactivos porque los recursos compartidos son bibliotecas e imágenes compartidas esenciales de JavaScript.

Estamos buscando formas de equilibrar la carga del contenido estático en este servidor, para evitar la dependencia de un solo servidor.

Me doy cuenta de que el DNS round robin es, en el mejor de los casos, una solución de gama baja (algunos incluso podrían decir que es un gueto ), pero no puedo evitar preguntarme: ¿ es el DNS round robin una solución "suficientemente buena" para el equilibrio básico de carga de contenido estático? ?

Hay una discusión sobre esto en las etiquetas [dns] [equilibrio de carga] , y he leído algunas excelentes publicaciones sobre el tema.

Soy consciente de las desventajas comunes del equilibrio de carga de DNS a través de múltiples registros A round-robin:

• Por lo general, no hay latidos ni detección de fallas con los registros DNS, por lo que si un servidor determinado en la rotación se cae, su registro A debe eliminarse manualmente de las entradas DNS
• el tiempo de vida (TTL) necesariamente debe establecerse bastante bajo para que esto funcione, ya que las entradas de DNS se almacenan en caché de forma agresiva en Internet
• las computadoras del cliente son responsables de ver que hay múltiples registros A y elegir el correcto

Pero, ¿es el DNS round robin lo suficientemente bueno como iniciador, mejor que nada, "mientras investigamos e implementamos mejores formas alternativas" de equilibrio de carga para nuestro contenido estático? ¿O el DNS round robin no tiene ningún valor bajo ninguna circunstancia?

Jeff, no estoy de acuerdo, el equilibrio de carga no implica redundancia, de hecho es todo lo contrario. Cuantos más servidores tenga, más probabilidades tendrá de fallar en un instante dado. Es por eso que la redundancia ES obligatoria cuando se realiza el equilibrio de carga, pero desafortunadamente hay muchas soluciones que solo proporcionan equilibrio de carga sin realizar ninguna verificación de estado, lo que resulta en un servicio menos confiable.

DNS roundrobin es excelente para aumentar la capacidad, al distribuir la carga en varios puntos (potencialmente distribuidos geográficamente). Pero no proporciona conmutación por error. Primero debe describir qué tipo de falla está tratando de cubrir. Una falla del servidor debe ser cubierta localmente usando un mecanismo estándar de toma de dirección IP (VRRP, CARP, ...). Una falla del conmutador está cubierta por enlaces resistentes en el servidor a dos conmutadores. Una falla de enlace WAN puede ser cubierta por una configuración de enlaces múltiples entre usted y su proveedor, utilizando un protocolo de enrutamiento o una solución de capa 2 (por ejemplo: PPP de enlaces múltiples). BGP debe cubrir una falla del sitio: sus direcciones IP se replican en varios sitios y usted las anuncia a la red solo donde están disponibles.

Según su pregunta, parece que solo necesita proporcionar una solución de conmutación por error del servidor, que es la solución más fácil ya que no involucra ningún hardware ni contrato con ningún ISP. Solo tiene que configurar el software apropiado en su servidor para eso, y es, con mucho, la solución más barata y confiable.

Usted preguntó "¿y si falla una máquina haproxy?". Es lo mismo. Todas las personas que conozco que usan haproxy para el equilibrio de carga y la alta disponibilidad tienen dos máquinas y ejecutan ucarp, keepalived o heartbeat en ellas para asegurarse de que una de ellas esté siempre disponible.

Esperando que esto ayude!

Como equilibrio de carga, es un gueto pero más o menos efectivo. Si tenía un servidor que se estaba cayendo de la carga y quería distribuirlo a varios servidores, esa podría ser una buena razón para hacerlo, al menos temporalmente.

Hay una serie de críticas válidas al DNS de round-robin como "equilibrio de carga", y no recomendaría hacerlo para otra cosa que no sea una curita a corto plazo.

Pero usted dice que su motivación principal es evitar una dependencia de un solo servidor. Sin alguna forma automatizada de sacar los servidores muertos de la rotación, no es muy valioso como una forma de prevenir el tiempo de inactividad. (Con una forma automatizada de extraer servidores de la rotación y un TTL corto, se convierte en conmutación por error del ghetto. Manualmente, ni siquiera es eso).

Si uno de sus dos servidores redondos se cae, entonces el 50% de sus clientes tendrá un fallo. Esto es mejor que el 100% de falla con solo un servidor, pero casi cualquier otra solución que hizo una conmutación por error real sería mejor que esto.

Si la probabilidad de falla de un servidor es N, con dos servidores su probabilidad es 2N. Sin una conmutación por error rápida y automatizada, este esquema aumenta la probabilidad de que algunos de sus usuarios experimenten fallas.

Si planea sacar el servidor muerto de la rotación manualmente, está limitado por la velocidad con la que puede hacer eso y el DNS TTL. ¿Qué pasa si el servidor muere a las 4 AM? La mejor parte de la verdadera conmutación por error es dormir toda la noche. Ya usa HAProxy , por lo que debe estar familiarizado con él. Sugiero encarecidamente usarlo, ya que HAProxy está diseñado para esta situación exactamente.

El DNS round robin no es lo que la gente piensa que es. Como autor del software del servidor DNS (a saber, BIND ), obtenemos usuarios que se preguntan por qué su round robin deja de funcionar según lo previsto. No entienden que incluso con un TTL de 0 segundos habrá cierta cantidad de almacenamiento en caché, ya que algunos almacenan un tiempo mínimo (a menudo 30-300 segundos) sin importar qué.

Además, si bien sus servidores AUTH pueden hacer round robin, no hay garantía de que los que le importan, las cachés con las que hablan sus usuarios, lo harán. En resumen, round robin no garantiza ningún pedido desde el punto de vista del cliente, solo lo que sus servidores de autenticación proporcionan a un caché.

Si desea una conmutación por error real, el DNS es solo un paso. No es una mala idea enumerar más de una dirección IP para dos clústeres diferentes, pero usaría otra tecnología allí (como la difusión simple) para hacer el equilibrio de carga real. Personalmente desprecio el hardware de equilibrio de carga de hardware que se entromete con DNS, ya que generalmente se equivoca. Y no olvide que viene DNSSEC, así que si elige algo en esta área, pregunte a su proveedor qué sucede cuando firma su zona.

Lo he dicho varias veces antes, y lo diré nuevamente: si la resistencia es el problema, entonces los trucos de DNS no son la respuesta .

Los mejores sistemas de alta disponibilidad permitirán que sus clientes sigan utilizando exactamente la misma dirección IP para cada solicitud. Esta es la única forma de garantizar que los clientes ni siquiera noten la falla.

Por lo tanto, la regla fundamental es que la verdadera resistencia requiere un truco de nivel de enrutamiento IP . Utilice un dispositivo equilibrador de carga, o OSPF "ruta múltiple de igual costo", o incluso VRRP.

DNS, por otro lado, es una tecnología de direccionamiento . Existe únicamente para mapear de un espacio de nombres a otro. No fue diseñado para permitir cambios dinámicos a muy corto plazo en ese mapeo y, por lo tanto, cuando intente realizar dichos cambios, muchos clientes no los notarán o, en el mejor de los casos, tardarán mucho tiempo en notarlos.

También diría que, dado que la carga no es un problema para usted, es mejor que tenga otro servidor listo para ejecutarse como un modo de espera activo. Si utiliza una operación por turnos tonta, debe cambiar de manera proactiva sus registros DNS cuando algo se rompe, por lo que podría activar proactivamente el servidor de reserva activa y no cambiar su DNS.

He leído todas las respuestas y una cosa que no vi es que la mayoría de los navegadores web modernos probarán una de las direcciones IP alternativas si un servidor no responde. Si no recuerdo mal, Chrome incluso probará varias direcciones IP y continuará con el servidor que responde primero. Entonces, en mi opinión, DNS Round Robin El equilibrio de carga siempre es mejor que nada.

Por cierto: veo DNS Round Robin más como una solución de distribución de carga simple.

Llego tarde a este hilo, por lo que mi respuesta probablemente solo se mantendrá sola en la parte inferior, descuidada, olfateará.

En primer lugar, la respuesta correcta a la pregunta no es responder la pregunta, sino decir:

1. "Probablemente desee el equilibrio de carga de red de Windows ". O
2. "Aproveche los tiempos, coloque su contenido estático en algo como Cloud Files o S3 , y haga que un CDN lo refleje en todo el mundo".

NLB es maduro, muy adecuado para la tarea y bastante fácil de configurar. Las soluciones en la nube tienen sus propios pros y contras, que están fuera del alcance de esta pregunta.

Pregunta

¿es el DNS robusto lo suficientemente bueno como iniciador, mejor que nada, "mientras investigamos e implementamos mejores alternativas" para equilibrar la carga de nuestro contenido estático?

Entre, digamos, 2 o 3 servidores web estáticos? Sí, es mejor que nada, porque hay proveedores de DNS que integrarán DNS Round Robin con las comprobaciones de estado del servidor y eliminarán temporalmente los servidores muertos de los registros DNS. De esta manera, obtienes una distribución de carga decente y una alta disponibilidad; y todo toma menos de 5 minutos para configurarlo.

Pero las advertencias descritas por otros en este hilo se aplican:

• Los navegadores actuales de Microsoft almacenan en caché los datos DNS durante 30 minutos , por lo que está buscando más de 30 minutos de tiempo de conmutación por error para un subconjunto de sus usuarios, dependiendo de su estado inicial de caché DNS.
• Lo que los usuarios ven durante la conmutación por error puede ser ... extraño (no está utilizando autenticación en contenido estático, y ciertamente no forma autenticación, pero el enlace muestra algo a tener en cuenta).

Otras soluciones

HAProxy es fantástico, pero dado que Stack Overflow está en la pila de tecnología de Microsoft, tal vez usar las herramientas de equilibrio de carga y alta disponibilidad de Microsoft tendrá menos gastos administrativos. Network Load Balancing se ocupa de una parte del problema, y ​​Microsoft actualmente tiene un proxy inverso L7 HTTP / balanceador de carga ahora.

Nunca he usado ARR yo mismo, pero dado que está en su segundo lanzamiento principal, y viniendo de Microsoft, supongo que se ha probado lo suficientemente bien. Tiene documentos fáciles de entender , aquí hay uno sobre cómo ven la distribución de contenido estático y dinámico en los nodos web, y aquí hay una pieza sobre cómo usar ARR con NLB para lograr la distribución de carga y la alta disponibilidad.

Es notable cuántos de los contribuyentes están ayudando a contribuir con la desinformación sobre DNS Round Robin como mecanismo de resistencia y distribución de carga. Por lo general, funciona, pero debe comprender cómo funciona y evitar los errores causados ​​por toda esa desinformación.

1) El TTL en los registros DNS utilizados para Round Robin debe ser corto, pero NO CERO. Tener el TTL en cero rompe la forma principal de proporcionar resistencia.

2) El DNS RR se extiende, pero no equilibra la carga, lo distribuye porque en una gran base de clientes, tienden a consultar el servidor DNS de forma independiente y, por lo tanto, terminan con diferentes entradas DNS de primera opción. Esas primeras opciones diferentes significan que los clientes son atendidos por diferentes servidores, y la carga se distribuye. Pero todo depende de qué dispositivo está haciendo la consulta DNS y cuánto tiempo tiene el resultado. Un ejemplo común es que todos los clientes detrás de un proxy corporativo (que realiza la consulta de DNS para ellos) terminarán apuntando a un solo servidor. La carga se distribuye, pero no está equilibrada de manera uniforme.

3) DNS RR proporciona resistencia siempre que el software del cliente lo implemente correctamente (y tanto el TTL como la capacidad de atención de los usuarios no es demasiado corta). Esto se debe a que DNS round robin proporciona una lista ordenada de las direcciones IP del servidor, y el software del cliente debe intentar contactar a cada una de ellas, hasta que encuentre un servidor que acepte la conexión.

Entonces, si el servidor de primera opción está inactivo, la conexión TCP / IP del cliente agota el tiempo de espera, y siempre que no haya expirado el TTL o el período de atención, entonces el software del cliente realiza otro intento de conexión a la segunda entrada en la lista, y así sucesivamente hasta que TTL caduca o llega al final de la lista (o el usuario se da por vencido).

Una larga lista de servidores rotos (su culpa) y grandes límites de reintento de conexión TCP / IP (configuración incorrecta del Cliente) pueden hacer que el Cliente encuentre un servidor que funcione durante un largo período. Un TTL demasiado corto significa que nunca llega al final de la lista y, en cambio, emite una nueva consulta DNS y recibe una nueva lista (con suerte en un orden diferente).

A veces el Cliente tiene mala suerte y la nueva lista todavía comienza con servidores rotos. Para dar al sistema la mejor oportunidad de proporcionar resistencia al cliente, debe asegurarse de que el TTL sea más largo que el lapso de atención típico y que el cliente llegue al final de la lista.

Una vez que el cliente ha encontrado un servidor en funcionamiento, debe recordarlo, y cuando necesite realizar la siguiente conexión, no debe repetir la búsqueda (a menos que el TTL haya expirado). Un TTL más largo reduce la frecuencia con la que los usuarios experimentan un retraso mientras el cliente busca un servidor que funcione, lo que brinda una mejor experiencia.

4) DNS TTL tiene su propio valor, cuando desea cambiar manualmente los registros DNS (por ejemplo, para eliminar un servidor roto a largo plazo), entonces un TTL corto permite que ese cambio se propague rápidamente (una vez que haya comenzado a hacerlo), entonces considere el equilibrio entre cuánto tiempo tomará antes de conocer el problema y realice ese cambio manual, y el hecho de que los clientes normales solo tendrán que hacer una nueva búsqueda de un servidor que funcione cuando expire el TTL.

DNS round robin tiene dos características sobresalientes que lo hacen muy rentable en una amplia gama de escenarios: en primer lugar, es gratis y, en segundo lugar, está casi tan disperso geográficamente como su base de clientes.

No introduce una nueva 'unidad de falla' que hacen todos los otros sistemas 'inteligentes'. No hay componentes adicionales que puedan experimentar una falla común y simultánea en una carga completa de elementos interconectados.

Los sistemas 'inteligentes' son geniales e introducen mecanismos maravillosos para coordinar y proporcionar un equilibrio perfecto y un mecanismo de conmutación por error, pero en última instancia, los mismos métodos que utilizan para proporcionar esa experiencia perfecta son su talón de Aquiles, lo complicado adicional que puede salir mal, y cuando lo haga, proporcionará una experiencia perfecta de fallas en todo el sistema.

Entonces, SÍ, el round robin de DNS es definitivamente "lo suficientemente bueno" para su primer paso más allá de un solo servidor que aloja todo su contenido estático en un solo lugar.

Windows Vista y Windows 7 implementan el soporte del cliente para round robin de manera diferente ya que respaldaron la selección de direcciones IPv6 a IPv4. ( RFC 3484 )

Por lo tanto, si tiene un número significativo de usuarios de Vista, Windows 7 y Windows 2008, es probable que encuentre un comportamiento inconsistente con su pensamiento planificado en su solución de equilibrio de carga ersatz.

Siempre he usado DNS Round-Robin, con TTL largo, como balanceador de carga. Funciona realmente bien para los servicios HTTP / HTTPS con navegadores .

Realmente me estreso con los navegadores, ya que la mayoría de los navegadores implementan algún tipo de "reintento en otra IP", pero no sé cómo otras bibliotecas o software manejarían la solución de IP múltiple.

Cuando el navegador no recibe una respuesta de un servidor, llamará automáticamente a la siguiente IP y luego la mantendrá (hasta que esté inactiva ... y luego intente con otra).

En 2007, hice la siguiente prueba:

• agregar un iframe en mi sitio web, apuntando a una entrada Round-Robin, como http://roundrobin.test:10080/ping.php
• la página fue atendida por 3 sockets PHP, escuchando en 3 IP diferentes, todos en el puerto 10080 (no podía permitirme probar en el puerto 80, ya que mi sitio web se estaba ejecutando en él)
• un socket (digamos A ) estaba allí para verificar que el navegador pudiera conectarse en el puerto 10080 (ya que muchas compañías solo permiten puertos estándar)
• otros dos enchufes (digamos B y C ) podrían activarse o desactivarse sobre la marcha.

Lo dejé correr una hora, tenía muchos datos. Los resultados fueron que para el 99.5% de los golpes en el zócalo A , tuve un golpe en el zócalo B o C (no desactivé ambos al mismo tiempo, por supuesto). Los navegadores fueron: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... ¡Así que incluso los navegadores que no eran compatibles lo manejaban bien!

Hasta el día de hoy, nunca lo volví a probar, pero quizás algún día configure una nueva prueba o publique el código en github para que otros puedan probarlo.

Nota importante: incluso si se trata de trabajar la mayor parte del tiempo, no quita el hecho de que algunas de las solicitudes serán fallar. También lo uso para solicitudes POST, ya que mi aplicación devolverá un mensaje de error en caso de que no funcione, para que el usuario pueda enviar los datos nuevamente, y lo más probable es que el navegador use otra IP en este caso y guardar funcionará . Y para el contenido estático, está funcionando realmente bien.

Entonces, si está trabajando con navegadores, utilice DNS Round-Robin, ya sea para contenido estático o dinámico, estará bien. Los servidores también pueden fallar en el medio de una transacción, e incluso con el mejor equilibrador de carga no puede manejar tal caso. Para el contenido dinámico, debe hacer que sus sesiones / base de datos / archivos sean sincrónicos, de lo contrario no podrá manejar esto (pero eso también es cierto con un equilibrador de carga real).

Nota adicional: puede probar el comportamiento en su propia IP utilizando iptables. Por ejemplo, antes de su regla de firewall para el tráfico HTTP, agregue:

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

(donde 12.34.56.78obviamente está su IP)

No lo use DROP, ya que deja el puerto filtrado y su navegador esperará hasta que se agote el tiempo. Entonces, ahora puede habilitar o deshabilitar un servidor u otro. La prueba más obvia es deshabilitar el servidor A, cargar la página, luego habilitar el servidor A y deshabilitar el servidor B. Cuando vuelva a cargar la página, verá una pequeña espera desde el navegador, luego se cargará desde el servidor A de nuevo. En Chrome, puede confirmar la IP del servidor mirando la solicitud en el panel de red. En la Generalpestaña de Headers, verá un encabezado falso llamado Remote Address:. Esta es la IP de donde obtuviste una respuesta.

Entonces, si necesita pasar al modo de mantenimiento en un servidor, simplemente deshabilite el tráfico HTTP / HTTPS con una iptables REJECTregla, todas las solicitudes irán a otros servidores (con una pequeña espera, casi imperceptible para los usuarios).

No creo que sea una solución lo suficientemente buena porque supongamos que tiene dos servidores ahora y utiliza el DNS en la dirección IP de cada servidor. Cuando un servidor se cae, los servidores DNS no tienen conocimiento de que se cayó y continuarán sirviendo esa dirección IP, como parte del proceso RR. Luego, el 50% de su audiencia obtendrá un sitio roto que carezca de JavaScript o imágenes.

Quizás sea más fácil apuntar a una dirección IP común manejada por Windows NLB que represente dos servidores detrás. A menos que esté utilizando un servidor Linux para su contenido estático, si recuerdo haber leído eso en alguna parte.

El balanceo de carga round-robin solo funciona cuando también tiene el control de la Zona DNS para que pueda cambiar la lista de servidores y enviarla a los maestros de zona de manera oportuna.

Como se menciona en una de las otras respuestas, el mal oculto del round-robin es el almacenamiento en caché de DNS que puede ocurrir en cualquier lugar entre sus servidores y el cliente, lo que niega por completo el pequeño beneficio de esta solución. Incluso con DNS TTL configurado en un valor muy bajo, tiene poco control sobre cuánto tiempo los ISP o incluso el caché DNS del cliente mantendrán activa la dirección IP ahora muerta.

Es una mejora con respecto a un SPOF seguro, pero solo marginal. Echaría un vistazo a quién aloja su servidor y veré qué tienen para ofrecer, muchos tienen algún tipo de servicio básico de equilibrador de carga que pueden proporcionar.

También puede tener un único servidor con el contenido estático duplicado en S3 y cambiar al CNAME S3 cuando su primario se apaga. Terminará con el mismo retraso pero sin el costo del servidor múltiple.

Esto realmente depende de lo que esté hablando y de cuántos servidores esté rotando. Una vez tuve un sitio que funcionaba en varios servidores, y usé DNS round robin en eso debido principalmente a mi novato en ese momento, y realmente no fue un gran problema. No fue un gran problema porque no se bloqueó. Era un sistema realmente estúpido y no complicado, por lo que aguantó y tenía un nivel de tráfico bastante constante. Si se estrelló por el tráfico, fue durante el día y algo que fácilmente podría solucionar. Diría que su contenido estático califica como lo suficientemente simple como para no causar bloqueos por sí solo.

Fuera de la falla de hardware, etc., ¿qué tan estable ha sido su servidor? ¿Qué tan "puntiagudo" es su tráfico en este contenido? Suponiendo que apache o algo así y tráfico relativamente plano, no se bloqueará mucho, y yo diría que el round robin es "lo suficientemente bueno".

Estoy seguro de que me votarán porque no estoy predicando una solución 100% HA, pero eso no es lo que pediste. Todo se reduce a lo que está dispuesto a aceptar como solución frente al esfuerzo invertido.

Si estuviera utilizando RR DNS para el equilibrio de carga, estaría bien, pero no lo está. Lo está utilizando para habilitar un servidor redundante, en cuyo caso no está bien.

Como dijo una publicación anterior, necesitas algo para detectar los latidos del corazón y dejar de golpearlo hasta que vuelva.

La buena noticia es que Heartbeat está disponible de forma muy económica, ya sea en conmutadores o en Windows.

No sé sobre otros sistemas operativos, pero supongo que también está allí.

Le sugiero que asigne una dirección IP adicional a cada uno de sus servidores (además de la IP estática que usa para, por ejemplo, ssh), y que la incorpore al conjunto de DNS. Y luego usa algún software para cambiar estas direcciones IP en caso de que falle un servidor. Heartbeat o CARP pueden hacer eso, por ejemplo, pero hay otras soluciones disponibles.

Esto tiene la ventaja de que para los clientes de su servicio, nada tiene que cambiar en la configuración, y no tiene que preocuparse por el almacenamiento en caché de DNS o TTL, pero aún puede aprovechar el "equilibrio de carga" de round-robin de DNS .

Probablemente hará el trabajo, especialmente si puede tener varias IP en sus cuadros estáticos. tener una IP de "servir contenido estático" y una IP de "administrar máquina". Si un cuadro se cae, puede usar una solución HA existente o una intervención manual para activar la IP de la máquina fallida en uno de los otros "miembros del clúster" o en una máquina completamente nueva (dependiendo de qué tan rápido sea para ponerlo en marcha).

Sin embargo, tal solución tendrá algunos problemas pequeños. El equilibrio de carga no será casi perfecto y si confía en la intervención manual, puede tener interrupciones para algunos visitantes.

Un equilibrador de carga de hardware probablemente puede hacer un mejor trabajo al compartir la carga y al proporcionar "tiempo de actividad del clúster" que el DNS round-robin. Por otro lado, esa es una (o dos, ya que idealmente tiene los LB en un clúster HA) piezas de hardware que necesitarán compra, energía y enfriamiento y (posiblemente) algo de tiempo para familiarizarse (si aún no lo tiene) tienen equilibradores de carga dedicados).

Para responder sucintamente a la pregunta (¿es el DNS robin lo suficientemente bueno como iniciador, mejor que nada, "mientras investigamos e implementamos mejores formas alternativas" de equilibrio de carga para nuestro contenido estático?), Diría que es mejor que nada, pero definitivamente debe continuar investigando otras formas de equilibrio de carga.

Al investigar el equilibrio de carga de Windows hace varios años, vi un documento que decía que la granja de servidores web de Microsoft estaba configurada como múltiples grupos de equilibrio de carga, con DNS round robin entre ellos. Dado que puede tener múltiples servidores DNS respondiendo en cada espacio de nombres, y dado que el equilibrio de carga de Microsoft se repara automáticamente, esto proporciona redundancia y equilibrio de carga.

Desventaja: necesita al menos 4 servidores (2 servidores x 2 grupos).

Respondiendo al comentario de Jeff sobre la respuesta de Schof, ¿hay alguna forma de DNS round-robin entre servidores HAProxy?

Tiene un uso muy marginal, suficiente para ayudarlo mientras coloca una solución real. Como usted dice, los TTL deben establecerse bastante bajos. Sin embargo, esto tiene el beneficio secundario de sacar una máquina problemática del DNS mientras tiene problemas. Digamos que tiene SvrA, SvrB y SvrC entregando su contenido y SvrA se cae. Lo sacas del DNS y después del corto período de tiempo definido por tu bajo TTL, los resolutores encontrarán un servidor diferente (SvrB o SvrC) que esté activo. Obtiene SvrA nuevamente en línea y lo vuelve a poner en DNS. Un corto tiempo de inactividad para algunas personas, ninguno para otros. No es genial, pero viable. Cuantos más servidores estáticos pongas en la mezcla, menos probabilidades tendrás de tener grupos de usuarios inactivos.

Ciertamente no obtendrá la verdadera distribución equilibrada que proporcionará una solución de equilibrio de carga real debido a la topología de Internet. Todavía vería la carga en todos los servidores involucrados.