amazon ec2 - the - ¿Qué hace la comprobación automática de estado de Amazon ELB y qué espera?

https console aws amazon com ec2 v2 home region us east 1

Question

Aquí está la cosa:

1. Hemos implementado un servidor de API RESTful de C ++, con un analizador HTTP incorporado y ningún servidor HTTP estándar como Apache o algo por el estilo
2. Ha estado en uso durante varios meses en la estructura de Amazon, utilizando comunicaciones simples y SSL, y no se han identificado problemas relacionados con la infraestructura de Amazon
3. Estamos implementando nuestro primer backend usando Amazon ELB
4. Amazon ELB tiene un sistema de control de salud personalizable pero también automático, como se indica here
5. No hemos encontrado documentación sobre qué datos envía el sistema de control de estado
6. El backend simple se cuelga en la instrucción de lectura del socket y, finalmente, la conexión se cierra

No estoy buscando una solución para el problema ya que el servidor no se basa en un servidor web estándar, solo si alguien sabe qué tipo de mensaje está enviando el sistema de verificación de estado de ELB, ya que no hemos encontrado documentación sobre esto , en cualquier sitio.

La ayuda es muy apreciada. Gracias.

Answer 1

Amazon ELB tiene un sistema de control de salud personalizable pero también automático, como se indica here

Con el personalizable es probable que se refiera a la comprobación de estado configurable a través de la Consola de administración de AWS (consulte Configuración de los ajustes de verificación de estado ) o a través de la API (consulte ConfigureHealthCheck ).

Los requisitos para pasar las comprobaciones de estado configurados de esta manera se describen en el campo Destino de la documentación del tipo de datos de HealthCheck :

Especifica la instancia que se está comprobando. El protocolo es TCP, HTTP, HTTPS o SSL. El rango de puertos válidos es de uno (1) a 65535.

Nota

• TCP es el valor predeterminado, especificado como un par TCP: puerto, por ejemplo, "TCP: 5000". En este caso, un chequeo de salud simplemente intenta abrir una conexión TCP a la instancia en el puerto especificado. La falta de conexión dentro del tiempo de espera configurado se considera poco saludable.

• SSL también se especifica como SSL: par de puertos, por ejemplo, SSL: 5000.

• Para el protocolo HTTP o HTTPS, la situación es diferente. Tienes que incluir una ruta de ping en la cadena. HTTP se especifica como HTTP: puerto; /; PathToPing; agrupación, por ejemplo, "HTTP: 80 / weather / us / wa / seattle". En este caso, se emite una solicitud HTTP GET a la instancia en el puerto y la ruta especificados. Cualquier respuesta que no sea "200 OK" dentro del período de tiempo de espera se considera insalubre.

• La longitud total del destino de ping HTTP debe ser de 1024 caracteres Unicode de 16 bits o menos.

[énfasis mío]

Con la función automática , es probable que se refiera a la comprobación de estado descrita en el párrafo Causa dentro de ¿Por qué la URL de comprobación de estado es diferente de la URL que se muestra en API y consola? :

Además de la comprobación de estado que configura para su equilibrador de carga, el servicio realiza una segunda comprobación de estado para protegerse contra los posibles efectos secundarios causados ​​por la finalización de las instancias sin cancelar el registro. Para realizar esta verificación, el equilibrador de carga abre una conexión TCP en el mismo puerto para el que está configurada la verificación de estado y luego cierra la conexión una vez que se completa la verificación de estado. [énfasis mío]

La solución del párrafo aclara que la carga útil es cero aquí, es decir, es similar al método no HTTP / HTTPS descrito para la comprobación de estado configurable anterior:

Esta comprobación de estado adicional no afecta el rendimiento de su aplicación porque no está enviando ningún dato a sus instancias de back-end. No puede desactivar o desactivar esta comprobación de estado.

Resumen / Solución

Suponiendo que su servidor de API RESTful, con el analizador HTTP incorporado se supone que solo sirve HTTP, es necesario que maneje dos controles de estado:

1. La primera vez que te configuraste como HTTP: port; /; PathToPing : recibirás una solicitud HTTP GET y deberás responder con 200 OK dentro del período de tiempo especificado para que se considere 200 OK .
2. La segunda configurada automáticamente por el servicio: abrirá una conexión TCP en el puerto HTTP configurado anteriormente, no enviará ningún dato y luego cerrará la conexión una vez que se complete la comprobación de estado.

En conclusión, parece que su servidor ya se está comportando perfectamente bien y que simplemente está irritado por el comportamiento de la segunda prueba de estado: ¿ELB considera realmente que su servidor no es saludable?

Answer 2

Por lo que sé, es solo una solicitud HTTP GET que busca una respuesta http 200 OK.