Robots redondos ponderados a través de TTL: ¿posible?

Actualmente uso DNS round robin para el equilibrio de carga, que funciona muy bien. Los registros se ven así (tengo un TTL de 120 segundos)

;; ANSWER SECTION:
orion.2x.to.        116 IN  A   80.237.201.41
orion.2x.to.        116 IN  A   87.230.54.12
orion.2x.to.        116 IN  A   87.230.100.10
orion.2x.to.        116 IN  A   87.230.51.65

Aprendí que no todos los ISP / dispositivos tratan esa respuesta de la misma manera. Por ejemplo, algunos servidores DNS rotan las direcciones al azar o siempre las cambian. Algunos simplemente propagan la primera entrada, otros intentan determinar cuál es el mejor (regionalmente cercano) mirando la dirección IP.

Sin embargo, si la base de usuarios es lo suficientemente grande (se extiende sobre múltiples ISP, etc.) se equilibra bastante bien. Las discrepancias entre el servidor cargado más alto y el más bajo casi no superan el 15%.

Sin embargo, ahora tengo el problema de que estoy introduciendo más servidores en los sistemas y que no todos tienen las mismas capacidades.

Actualmente solo tengo servidores de 1 Gbps, pero quiero trabajar con servidores de 100 Mbps y también de 10 Gbps.

Entonces, lo que quiero es presentar un servidor con 10 Gbps con un peso de 100, un servidor de 1 Gbps con un peso de 10 y un servidor de 100 Mbps con un peso de 1.

Anteriormente agregué servidores dos veces para atraerles más tráfico (lo que funcionó bien, el ancho de banda casi se duplicó). Pero agregar un servidor de 10 Gbps 100 veces a DNS es un poco ridículo.

Entonces pensé en usar el TTL.

Si le doy al servidor A 240 segundos TTL y el servidor B solo 120 segundos (que es aproximadamente el mínimo que se debe usar para round robin, ya que muchos servidores DNS se configuran en 120 si se especifica un TTL más bajo (así lo he oído)). Creo que algo así debería ocurrir en un escenario ideal:

First 120 seconds
50% of requests get server A -> keep it for 240 seconds.
50% of requests get server B -> keep it for 120 seconds

Second 120 seconds
50% of requests still  have server A cached -> keep it for another 120 seconds.
25% of requests get server A -> keep it for 240 seconds
25% of requests get server B -> keep it for 120 seconds

Third 120 seconds
25% will get server A (from the 50% of Server A that now expired) -> cache 240 sec
25% will get server B  (from the 50% of Server A  that now expired) -> cache 120 sec
25% will have server A cached for another 120 seconds
12.5% will get server B (from the 25% of server B that now expired) -> cache 120sec
12.5% will get server A (from the 25% of server B that now expired) -> cache 240 sec

Fourth 120 seconds
25% will have server A cached -> cache for another 120 secs
12.5% will get server A (from the 25% of b that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of b that now expired) -> cache 120 secs
12.5% will get server A (from the 25% of a that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of a that now expired) -> cache 120 secs
6.25% will get server A (from the 12.5% of b that now expired) -> cache 240 secs
6.25% will get server B (from the 12.5% of b that now expired) -> cache 120 secs
12.5% will have server A cached -> cache another 120 secs
... I think I lost something at this point, but I think you get the idea...

Como puede ver, esto se vuelve bastante complicado de predecir y seguramente no funcionará así en la práctica. ¡Pero definitivamente debería tener un efecto en la distribución!

Sé que existe un round robin ponderado y solo es controlado por el servidor raíz. Simplemente recorre los registros DNS al responder y devuelve registros DNS con una probabilidad establecida que corresponde a la ponderación. Mi servidor DNS no es compatible con esto, y mis requisitos no son tan precisos. Si no pesa perfectamente, está bien, pero debe ir en la dirección correcta.

Creo que usar el campo TTL podría ser una solución más elegante y fácil, y no requiere un servidor DNS que controle esto dinámicamente, lo que ahorra recursos, que en mi opinión es el punto central del equilibrio de carga de DNS frente a los equilibradores de carga de hardware.

Mi pregunta ahora es: ¿Existen mejores prácticas / métodos / reglas generales para ponderar la distribución por turnos utilizando el atributo TTL de los registros DNS?

Editar:

El sistema es un sistema de servidor proxy directo. La cantidad de ancho de banda (no solicitudes) excede lo que puede manejar un solo servidor con Ethernet. Por lo tanto, necesito una solución de equilibrio que distribuya el ancho de banda a varios servidores. ¿Hay algún método alternativo que no sea usar DNS? Por supuesto, puedo usar un equilibrador de carga con canal de fibra, etc., pero los costos son ridículos y también aumenta solo el ancho del cuello de botella y no lo elimina. Lo único que se me ocurre son las direcciones IP de difusión directa (¿es variable o multidifusión?), Pero no tengo los medios para configurar dicho sistema.

En primer lugar, estoy completamente de acuerdo con @Alnitak en que DNS no está diseñado para este tipo de cosas, y la mejor práctica es no (ab) usar DNS como equilibrador de carga de un hombre pobre.

Mi pregunta ahora es ... ¿existen las mejores prácticas / métodos / reglas generales para ponderar la distribución por turnos utilizando el atributo TTL de los registros DNS?

Para responder sobre la premisa de la pregunta, el enfoque utilizado para realizar el round robin ponderado basix usando DNS es:

• Ajuste la ocurrencia relativa de registros en respuestas DNS autorizadas. Es decir, si Server Adebe tener 1/3 de tráfico y Server Btener 2/3, entonces 1/3 de las respuestas autorizadas de DNS a los proxies DNS contendrían solo A la IP y 2/3 de las respuestas solo Bla IP. (Si 2 o más servidores comparten el mismo 'peso', entonces se pueden agrupar en una sola respuesta).
• Mantenga un TTL de DNS bajo para que la carga no equilibrada se nivele con relativa rapidez. Debido a que los proxies DNS descendentes tienen un número muy poco uniforme de clientes detrás de ellos, querrá volver a mezclar los registros con frecuencia.

El servicio DNS de la ruta 53 de Amazon utiliza este método .

La cantidad de ancho de banda (no solicitudes) excede lo que puede manejar un único servidor con Ethernet. Por lo tanto, necesito una solución de equilibrio que distribuya el ancho de banda a varios servidores.

Derecha. Entonces, según tengo entendido, tiene algún tipo de servicio de descargas / distribución de video / descarga de archivos grandes 'barato', donde la tasa de bits total del servicio excede 1 GBit.

Sin conocer los detalles exactos de su servicio y el diseño de su servidor, es difícil ser preciso. Pero una solución común en este caso es:

• DNS round robin a dos o más instancias de equilibrador de carga de nivel TCP / IP o HTTP.
• Cada instancia del equilibrador de carga está altamente disponible (2 equilibradores de carga idénticos que cooperan para mantener una dirección IP siempre activa).
• Cada instancia de equilibrador de carga utiliza un sistema robótico ponderado o una gestión de conexión aleatoria ponderada para los servidores de fondo.

Este tipo de configuración se puede construir con software de código abierto o con dispositivos diseñados especialmente por muchos proveedores. La etiqueta de equilibrio de carga aquí es un excelente punto de partida, o puede contratar administradores de sistemas que hayan hecho esto antes para consultar por usted ...

Mi pregunta ahora es ... ¿existen las mejores prácticas / métodos / reglas generales para ponderar la distribución por turnos utilizando el atributo TTL de los registros DNS?

¡Sí, la mejor práctica es no hacerlo !

Porfavor repita despues de mi

• DNS no es para equilibrio de carga
• DNS no proporciona resistencia
• DNS no proporciona instalaciones de conmutación por error

DNS es para asignar un nombre a una o más direcciones IP . Cualquier balance posterior que obtenga es por suerte, no por diseño.

Echa un vistazo a PowerDNS . Le permite crear un backend de tubería personalizado. He modificado un ejemplo de backend DNS de equilibrador de carga escrito en perl para usar el módulo Algorithm :: ConsistentHash :: Ketama. Esto me permite establecer pesos arbitrarios así:

my $ketamahe = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamahe->add_bucket("192.168.1.2", 50);
$ketamahe->add_bucket("192.168.1.25", 50);

Y otro:

# multi-colo hash
my $ketamamc = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamamc->add_bucket("192.168.1.2", 33);
$ketamamc->add_bucket("192.168.1.25", 33);
$ketamamc->add_bucket("192.168.2.2", 17);
$ketamamc->add_bucket("192.168.2.2", 17);

Agregué un cname de mi dominio de nivel superior deseado a una subomanía a la que llamo gslb o Global Server Load Balancing. Desde allí, invoco este servidor DNS personalizado y envío registros A de acuerdo con mis pesos deseados.

Funciona como un campeón. El hash ketama tiene la agradable propiedad de una interrupción mínima en la configuración existente a medida que agrega servidores o ajusta pesos.

Recomiendo leer servidores DNS alternativos, de Jan-Piet Mens. Tiene muchas buenas ideas allí, así como código de ejemplo.

También recomendaría abandonar la modulación TTL. Ya está bastante lejos y agregar otro kludge en la parte superior hará que la solución de problemas y la documentación sean extremadamente difíciles.

Puede usar PowerDNS para hacer un round robin ponderado, aunque distribuir la carga de manera tan desequilibrada (100: 1?) Puede ser muy interesante, al menos con los algoritmos que utilicé en mi solución, donde cada entrada RR tiene un peso asociado. , entre 1 y 100, y se utiliza un valor aleatorio para incluir o excluir registros.

Aquí hay un artículo que escribí sobre el uso del backend MySQL en PowerDNS para hacer DNS RR ponderado: http://www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/

RIPienaar también tiene algunos ejemplos basados ​​en Ruby (usando el backend de tubería PowerDNS): http://code.google.com/p/ruby-pdns/wiki/RecipeWeightedRoundRobin

Para lidiar con este tipo de configuración, debe buscar una solución de equilibrio de carga real. Lea Linux Virtual Server y HAProxy . Obtiene el beneficio adicional de que los servidores se eliminan automáticamente del grupo si fallan y los efectos se entienden mucho más fácilmente. La ponderación es simplemente un ajuste a modificar.