amazon ec2 - una - API de escalamiento automático de Amazon para servidores de trabajos

servidores amazon gratis (2)

He leído prácticamente toda la documentación, incluso más allá, en AWS AS API para comprender todo el material de AS.

Sin embargo, todavía me pregunto (sin haber usado la API aún, ya que quiero descubrir esto primero de alguien) si mi escenario es viable con AS.

Digamos que tengo una gran cantidad de servidores de trabajo configurados dentro de un grupo AS que trabajan en un trabajo cada uno y de repente llega el momento (no lo sé, la CPU AVG es mayor que o en otro caso menos del 80%) para aumentar o disminuir la escala.

Mi principal preocupación es la pérdida de un trabajo actualmente en progreso. Tal vez esto sería mejor explicado con un ejemplo:

Inicié 5 servidores de trabajo con 5 trabajos en ellos
Un trabajo termina en uno y activa un disparador de reducción en la API de Amazon
Amazon viene a escalarlos
Pierdo un servidor de trabajo que actualmente está ejecutando un trabajo (el 90% completo debe comenzar de nuevo)

Con esto en mente, ¿es mejor para mí simplemente usar la API Amazon Spot Instance / EC2 y simplemente administrar mi propia escala o hay algo que me falta acerca de cómo la API de Amazon juzga las terminaciones del servidor?

Para ser honesto, prefiero escalar a la cantidad de espera de SQS que una cifra de salud en los servidores:

por cada 100 mensajes en espera aumenta la capacidad del clúster en un 20%

Pero esto tampoco parece ser demasiado viable con AS.

Entonces, ¿la API AS de AWS no es la solución correcta o me falta información vital sobre cómo funciona?

Gracias,

Después de buscar, descubrí que hay dos maneras aceptadas de administrar AS API o AS en general para trabajos:

Un método es manipular el estado de un servidor directamente desde el propio trabajador. Esto es lo que hacen algunos sitios y es efectivo, cuando su trabajador no detecta más trabajos o redundancia en el sistema, marca que el servidor en el que se encuentra no es saludable. De esta forma, aparece la API AS y la elimina automáticamente después de un período de tiempo.

Por lo tanto, con este método, tendría una política de ampliación basada en el tamaño de cola SQS durante un período de tiempo (por ejemplo, cada 5 minutos de mensajes SQS con más de 100 agregar 2 servidores; cada 10 minutos con mensajes SQS con capacidad de red doble superior a 500 en un 50%). La reducción de escala sería manejada por código en lugar de una política activa.

Este método también funcionaría con cero clústeres, por lo que puede bajar su clúster hasta llegar a ningún servidor cuando no se esté utilizando, lo que lo hace bastante rentable.

Ventajas:

Fácil de instalar
Uso de las funciones de AWS API
Probablemente el más rápido de configurar
Usar la API administrada de AWS para administrar el tamaño del clúster por usted

Desventajas:

Es difícil de administrar sin utilizar AWS API completa, es decir, cuando se crea un nuevo servidor no se puede recuperar su instancia sin realizar un retorno completo de todos los comandos de la API. Hay otras ocasiones en que AWS AS API se interpone en su camino y hace la vida un poco más difícil si desea un elemento de autocontrol sobre su clúster
Confiar en Amazon para saber qué es lo mejor para tu billetera. Confía en la API de Amazon para escalar correctamente, esto es una ventaja para muchos pero una desventaja para algunos.
El trabajador debe albergar parte de su código de grupo de servidores, lo que significa que el trabajador no es genérico y no puede ser movido instantáneamente a otro clúster sin algún cambio de configuración.

Con esto en mente, hay una segunda opción, bricolaje. Utiliza la Instancia puntual EC2 y la API Instancia a petición para crear su propia API AS en función de sus reglas personalizadas. Esto es bastante simple de explicar:

Tiene una secuencia de comandos cli que cuando se ejecuta comienza, por ejemplo, 10 servidores
Usted tiene un cronjob que cuando detecta una satisfacción de ciertas condiciones baja los servidores o sube más

Ventajas:

Fácil y limpio para administrar su fin
Puede hacer que los trabajadores genéricos
El grupo de servidores puede comenzar a administrar muchos clusters
Puede establecer las reglas y lo que no es realmente complejo para obtener cifras de las métricas de AWS y usarlas con intervalos de comparación y tiempo para comprender si las cosas deberían cambiar.

Desventajas:

Difícil de obtener en múltiples regiones (no tan malo para SQS ya que SQS es una sola región)
Es difícil lidiar con los errores en la capacidad de la región y la carga de trabajo
Debe confiar en el tiempo de actividad de sus propios servidores y en su propio código para garantizar que el cronjob se ejecute como debería y aprovisione los servidores como debería y los deshace cuando debería.

Entonces realmente parece ser una batalla de la cual es más cómodo para el usuario final. Personalmente estoy reflexionando sobre los dos y creo un pequeño servidor de servidores alojado que podría funcionar para mí, pero al mismo tiempo estoy tentado de intentar que esto funcione en la propia API de AWS.

Espero que esto ayude a la gente,

EDITAR: tenga en cuenta que con cualquiera de estos métodos todavía necesitará una función de su parte para predecir cómo debe pujar, por lo tanto, tendrá que llamar a la API del historial de ofertas en su tipo spot (tipo EC2) y calcular cómo ofertar.

Otra Edición: Otra forma de detectar automáticamente la redundancia en un sistema es verificar la métrica de respuestas vacías para su cola SQS. Esta es la cantidad de veces que sus trabajadores han conectado la cola y no han recibido respuesta. Esto es bastante efectivo si usa un bloqueo exclusivo en su aplicación mientras dure el trabajador.

Simplemente tuve el mismo tipo de problema y hablé con un chico de Amazon que me habló sobre la protección de terminación. De hecho, si una instancia tiene la protección de terminación activada, no puede ser terminada. Cuando se activa una reducción de escala, la aplicación se eliminará del grupo de escalado automático, pero no se terminará. Para finalizarlo, debe desactivar la protección de terminación y luego finalizarla (puede hacerlo al final de su trabajo, por ejemplo).

En resumen, lo que tienes que hacer es:

Agregue una secuencia de comandos de inicio en su AMI para activar la Protección de terminación
Mantenga sus reglas de escalado automático (ampliación y reducción)
En las instancias en ejecución, una vez que es seguro finalizar una instancia (fin de un trabajo, ...), desactive la protección de terminación y finalice la instancia

Puedes hacer todo eso usando la API de AWS.