Estamos tratando de ejecutar una configuración bastante sencilla en Amazon EC2: varios servidores HTTP ubicados detrás de un Amazon Elastic Load Balancer (ELB).

Nuestro dominio se administra en Route53, y tenemos un registro CNAME configurado para apuntar al ELB.

Hemos experimentado algunos problemas en los que algunas ubicaciones, pero no todas, no pueden conectarse de forma intermitente al equilibrador de carga; parece que esta puede ser la resolución del nombre de dominio del ELB.

El soporte de Amazon nos informó que la IP elástica subyacente del equilibrador de carga ha cambiado y que el problema es que los servidores DNS de algunos ISP no cumplen con el TTL. No estamos satisfechos con esta explicación, porque replicamos el problema usando los propios servidores DNS de Amazon desde una instancia EC2, así como en los ISP locales en Australia y a través del servidor DNS de Google ( 8.8.8.8).

Amazon también confirmó que durante el período en que notamos el tiempo de inactividad de algunas ubicaciones, el tráfico que pasaba por el ELB disminuyó significativamente, por lo que el problema no está en nuestros puntos finales.

Curiosamente, el dominio parece resolverse a la IP correcta en los servidores que no pueden conectarse, pero el intento de establecer una conexión TCP falla.

Todas las instancias vinculadas al ELB han sido saludables en todo momento. Son todos

¿Alguien sabe cómo podríamos diagnosticar este problema más profundamente? ¿Alguien más ha experimentado este problema con Elastic Load Balancer?

Gracias,

Encontré esta pregunta en Google sobre cómo diagnosticar los equilibradores de carga elásticos de Amazon (ELB) y quiero responderla a cualquier otra persona como yo que haya tenido este problema sin mucha orientación.

Propiedades ELB

Los ELB tienen algunas propiedades interesantes. Por ejemplo:

• Los ELB están formados por 1 o más nodos
• Estos nodos se publican como registros A para el nombre ELB
• Estos nodos pueden fallar o cerrarse, y las conexiones no se cerrarán correctamente
• A menudo se requiere una buena relación con el soporte de Amazon ($$$) para que alguien pueda investigar los problemas de ELB

NOTA: Otra propiedad interesante pero un poco menos pertinente es que los ELB no fueron diseñados para manejar picos repentinos de tráfico. Por lo general, requieren 15 minutos de tráfico pesado antes de que se amplíen o pueden precalentarse a pedido mediante un ticket de soporte

Solución de problemas de ELB (manualmente)

Actualización: AWS desde entonces ha migrado todos los ELB para usar Route 53 para DNS. Además, todos los ELB ahora tienen un all.$elb_nameregistro que devolverá la lista completa de nodos para el ELB. Por ejemplo, si su nombre ELB es elb-123456789.us-east-1.elb.amazonaws.com, entonces obtendría la lista completa de nodos haciendo algo como dig all.elb-123456789.us-east-1.elb.amazonaws.com. Para nodos IPv6, all.ipv6.$elb_nametambién funciona. Además, Route 53 puede devolver hasta 4KB de datos que todavía usan UDP, por lo +tcpque puede que no sea necesario usar el indicador.

Sabiendo esto, puede hacer un poco de solución de problemas por su cuenta. Primero, resuelva el nombre ELB en una lista de nodos (como registros A):

$ dig @ns-942.amazon.com +tcp elb-123456789.us-east-1.elb.amazonaws.com ANY

Se tcpsugiere el indicador ya que su ELB podría tener demasiados registros para caber dentro de un solo paquete UDP. También me han dicho, pero no he confirmado personalmente, que Amazon solo mostrará hasta 6 nodos a menos que realice una ANYconsulta. Ejecutar este comando le dará un resultado similar a este (recortado por brevedad):

;; ANSWER SECTION:
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN SOA ns-942.amazon.com. root.amazon.com. 1376719867 3600 900 7776000 60
elb-123456789.us-east-1.elb.amazonaws.com. 600 IN NS ns-942.amazon.com.
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 54.243.63.96
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 23.21.73.53

Ahora, para cada uno de los Aregistros, use, por ejemplo, curlpara probar una conexión al ELB. Por supuesto, también desea aislar su prueba solo para el ELB sin conectarse a sus backends. Una propiedad final y un hecho poco conocido sobre los ELB:

• El tamaño máximo del método de solicitud (verbo) que se puede enviar a través de un ELB es de 127 caracteres . Más grande y el ELB responderá con un HTTP 405 - Método no permitido .

Esto significa que podemos aprovechar este comportamiento para probar solo que el ELB está respondiendo:

$ curl -X $(python -c 'print "A" * 128') -i http://ip.of.individual.node
HTTP/1.1 405 METHOD_NOT_ALLOWED
Content-Length: 0
Connection: Close

Si ve HTTP/1.1 405 METHOD_NOT_ALLOWED, el ELB está respondiendo con éxito. También es posible que desee ajustar los tiempos de espera de curl a valores que sean aceptables para usted.

Solución de problemas de ELB con elbping

Por supuesto, hacer esto puede ser bastante tedioso, así que he creado una herramienta para automatizar esto llamado elbping . Está disponible como una gema de rubí, por lo que si tiene rubygems, puede instalarlo simplemente haciendo lo siguiente:

$ gem install elbping

Ahora puedes ejecutar:

$ elbping -c 4 http://elb-123456789.us-east-1.elb.amazonaws.com
Response from 54.243.63.96: code=405 time=210 ms
Response from 23.21.73.53: code=405 time=189 ms
Response from 54.243.63.96: code=405 time=191 ms
Response from 23.21.73.53: code=405 time=188 ms
Response from 54.243.63.96: code=405 time=190 ms
Response from 23.21.73.53: code=405 time=192 ms
Response from 54.243.63.96: code=405 time=187 ms
Response from 23.21.73.53: code=405 time=189 ms
--- 54.243.63.96 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 187/163/210 ms
--- 23.21.73.53 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 188/189/192 ms
--- total statistics ---
8 requests, 8 responses, 0% loss
min/avg/max = 188/189/192 ms

Recuerde, si ve code=405, eso significa que el ELB está respondiendo.

Próximos pasos

Cualquiera que sea el método que elija, al menos sabrá si los nodos de su ELB responden o no. Armado con este conocimiento, puede enfocarse en la solución de problemas de otras partes de su pila o puede hacer un caso bastante razonable para AWS de que algo está mal.

¡Espero que esto ayude!

La solución es realmente simple: use un Aregistro en lugar de un CNAMEen Route53.

En la consola de administración de AWS, elija "A record" y luego mueva el botón de opción "Alias" a "Sí". Luego seleccione su ELB del menú desplegable.

Hay algunas posibles soluciones que podría probar en este foro de desarrolladores de AWS. https://forums.aws.amazon.com/message.jspa?messageID=387552 .

Por ejemplo:

posible solución n. ° 1

Tuvimos un problema similar cuando nos mudamos a ELB, lo resolvimos reduciendo el nombre de nuestro ELB a un solo carácter. Incluso un nombre de 2 caracteres para ELB causó problemas aleatorios con las soluciones de red de resoluciones DNS.

El nombre DNS de su ELB debe ser algo así como -> X. <9chars> .us-east-1.elb.amazonaws.com

posible solución n. ° 2

Soy el cartel original. Gracias por todas las respuestas. Pudimos reducir la frecuencia con la que experimentamos problemas de DNS al configurar el TTL muy alto (para que los servidores que no son de Network Solutions lo almacenen en caché). Sin embargo, todavía recibíamos suficientes problemas en los que ya no podíamos seguir con Network Solutions. Pensamos en mudarnos a UltraDNS en base a buenos informes sobre el servicio, pero parecía que la Ruta 53 (que usa UltraDNS debajo de las cubiertas, al parecer) sería más barata para nosotros. Desde que cambiamos a la ruta 53, no tenemos más problemas de DNS, y nuestros nombres ELB también pueden ser agradables y largos.

Había otras cosas que probar en esa publicación, pero esas parecen ser las mejores pistas.