Pregunta ¿Pistas redondas ponderadas vía TTL - posible?


Actualmente utilizo DNS round robin para equilibrar la carga, lo 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 alternan. Algunos simplemente propagan la primera entrada, otros intentan determinar cuál es la mejor (regionalmente cercana) mirando la dirección IP.

Sin embargo, si la base de usuarios es lo suficientemente grande (se extiende sobre varios ISP, etc.) se equilibra bastante bien. Las discrepancias entre el servidor cargado más alto y el más bajo apenas 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 atraer 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.

Así que pensé en usar el TTL.

Si le doy al servidor A 240 segundos, TTL y al servidor B, solo 120 segundos (que es aproximadamente el mínimo para usar en round robin, como muchos servidores DNS configurados en 120 si se especifica un TTL más bajo (por lo que he escuchado)). Creo que algo como esto 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 el round robin ponderado existe y solo es controlado por el servidor raíz. Simplemente recorre los registros de DNS al responder y devuelve los registros de DNS con una probabilidad establecida que corresponde a la ponderación. Mi servidor DNS no admite esto y mis requisitos no son tan precisos. Si no pesa perfectamente, está bien, pero debería ir en la dirección correcta.

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

Mi pregunta ahora es: ¿Existen prácticas / métodos / reglas prácticas para evaluar la distribución de turnos rotativos con el atributo TTL de los registros DNS?

Editar:

El sistema es un sistema de servidor proxy de reenvío. La cantidad de ancho de banda (no las solicitudes) supera lo que puede manejar un solo servidor con Ethernet. Así que necesito una solución de equilibrio que distribuya el ancho de banda a varios servidores. ¿Hay métodos alternativos que el uso de DNS? Por supuesto, puedo usar un equilibrador de carga con canal de fibra, etc., pero los costos son ridículos y también aumentan el ancho del cuello de botella y no lo eliminan. Lo único en lo que puedo pensar son las direcciones IP anycast (¿es anycast o multicast?), Pero no tengo los medios para configurar dicho sistema.


8
2018-02-07 15:11


origen


Prepárese para recibir un golpe en la cabeza con una copia de RFC 2181 § 5.2 por un amplio espectro de encuestados. - JdeBP
Bueno, me doy cuenta de que RR no fue diseñado para equilibrar la carga. pero funciona muy bien ... así que ... tampoco soy consciente de una alternativa. Por supuesto que sí, pero no me son posibles ni demasiado caros o demasiado complicados - The Shurrican
@JdeBP sí, buen lugar: los TTL en un RRset DEBEN ser iguales. - Alnitak


Respuestas:


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 ... ¿hay alguna de las mejores prácticas / methos / rules of thumb para ponderar la distribución de turnos con 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 utilizando DNS es:

  • Ajustar el ocurrencia relativa de registros en respuestas DNS autorizadas. Es decir. Si Server A es tener 1/3 de tráfico y Server B es tener 2/3, luego 1/3 de las respuestas de DNS autorizadas a los proxies DNS contendrían solamente  A's IP, y 2/3 de respuestas solamente B'sorbo. (Si 2 o más servidores comparten el mismo 'peso', entonces se pueden agrupar en una respuesta).
  • Mantenga un DNS TTL bajo para que la carga no balanceada se iguale con relativa rapidez. Debido a que los proxies de DNS descendentes tienen un número de clientes muy desigual detrás de ellos, usted querría volver a mezclar los registros con frecuencia.

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

La cantidad de ancho de banda (no las solicitudes) supera lo que puede manejar un solo servidor con Ethernet. Así que 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 'baratos', donde la tasa de bits total del servicio supera los 1 GB.

Sin saber los detalles específicos de su servicio y la disposición de su servidor, es difícil ser preciso. Pero una La 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 cooperan para mantener una dirección IP siempre activada).
  • Cada instancia del equilibrador de carga utiliza el turno rotativo ponderado o el manejo de la conexión aleatoria ponderada a los servidores back-end.

Este tipo de configuración puede construirse con software de código abierto, o con dispositivos especialmente diseñados por muchos proveedores. los etiqueta de equilibrio de carga Aquí hay un gran punto de partida, o puede contratar administradores de sistemas que hayan hecho esto antes para consultar por usted ...


2
2018-02-09 03:06





Mi pregunta ahora es ... ¿hay alguna de las mejores prácticas / methos / rules of thumb para ponderar la distribución de turnos con el atributo TTL de los registros DNS?

Sí, la mejor práctica es no lo hagas !!

Porfavor repita despues de mi

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

DNS es para mapear un nombre a una o más direcciones IP. Cualquier balance posterior que obtengas es a través de la suerte, no del diseño.


5
2018-02-07 16:26



more IP addresses ... ¿cómo es que no se equilibra? Además, esta es la razón por la que di a mi pregunta una introducción apropiada. Si no hubiera hecho eso, calificaría tu publicación como un COMENTARIO, pero así tengo que votarlo a la baja. maby no está diseñado, pero funciona muy bien y ofrece grandes ventajas en comparación con todas las alternativas. y eso es lo que los sitios web como google, facebook, amazon, etc. también piensan y usan. sin embargo, el comentario señalado. Actualicé mi pregunta con más información sobre el escenario y le ruego que sugiera una solución de equilibrio alternativa @Alnitak - The Shurrican
El equilibrio de esta manera no ofrece ninguna garantía de integridad ya que muchos de los problemas que enfrentan los clientes surgen fuera de su control. Esto es doblemente así que cuando quieres "ponderar" porque, en primer lugar, no puedes garantizar el round robin. DNS es solo un servicio de asesoría, los clientes no necesitan seguirlo en la carta. Creo que ese es el punto que @Alnitak quería hacer. - Matthew Ife
Lo entiendo perfectamente. cita de mi pregunta: 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 alternan. 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 varios ISP, etc.) se equilibra bastante bien. Las discrepancias entre el servidor cargado más alto y el más bajo apenas superan el 15%. - The Shurrican
@JoeHopfgartner, la única forma infalible de proporcionar resiliencia, redundancia y balanceo es a través de la capa IP, es decir, enrutamiento BGP y balanceadores de carga de capa 4. No lo dije en esta respuesta porque ya lo he dicho docenas de veces en otras respuestas. - Alnitak
¿La redundancia es importante para su solución? I.E si un servidor falla, se maneja adecuadamente? Porque si es tu apertura una lata de gusanos con RR-DNS. - Matthew Ife


Echa un vistazo a PowerDNS. Te permite crear un backend de tubería personalizado. He modificado un ejemplo del backend DNS del equilibrador de carga escrito en perl para usar el algoritmo:Consistente:: Módulo 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 un subdoman que llamé 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 de ketama tiene la agradable propiedad de una interrupción mínima de la configuración existente a medida que agrega servidores o ajusta pesos.

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

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


2
2018-02-09 04:17





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

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

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


1
2018-04-12 16:45





Para lidiar con este tipo de configuración, debe buscar una solución de equilibrio de carga real. Leer Servidor virtual de linux y HAProxy. Usted 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 para ser ajustado.


1
2018-02-07 16:47



El problema con eso es que tengo un problema de ancho de banda y no un problema de cantidad de solicitudes que un solo servidor puede manejar. Así que una solución donde tengo que dirigir todo el tráfico a través de un nodo no es una solución para mí. Lo único que puedo pensar al lado de la solución DNS es una dirección IP de multidifusión. Edité mi pregunta en consecuencia. - The Shurrican
lo siento, quiero decir anycast, no multicast (creo) - The Shurrican
Si el problema es el ancho de banda, debe analizar este + LACP en sus conmutadores. Luego, puede unir varias tarjetas 10G en los dispositivos de balanceo de carga. - Mark Harrigan
Upvote esto porque es interesante ... pero hten tengo mi interruptor como cuello de botella! - The Shurrican