¿Escalado automático EC2 con instancias puntuales y bajo demanda?

Estoy buscando optimizar el costo de nuestros grupos EC2 de autoescalado al hacer que inicien instancias puntuales en lugar de instancias bajo demanda.

Lo que realmente quiero es poder mantener algunos servidores en el grupo como instancias bajo demanda, independientemente de lo que ocurra en el mercado de precios de instancias spot. Entonces quiero que los servidores adicionales en el grupo, por encima de mi mínimo configurado, sean instancias puntuales. En general, estoy de acuerdo con la demora en agregar servidores a través de solicitudes puntuales.

Parece que no puedo encontrar ninguna manera de hacer esto y he intentado buscar en la documentación de AWS. Parece que un ASG puede ser a pedido o puntual, pero no un híbrido.

Posiblemente podría agregar manualmente una instancia a pedido al Elastic Load Balancer asignado al grupo de autoescalado, pero luego la carga de ese servidor no se tendría en cuenta en las medidas y los desencadenantes de autoescalado.

Supongo que podría ingresar un precio de oferta ridículamente alto para garantizar que siempre obtenga los servidores que necesito, pero luego miro el historial de precios y veo grandes picos ocasionales.

La documentación de AWS está en desacuerdo consigo misma, ya que en un lugar dice que si ingresa un mínimo de servidor, ese número está "asegurado" para estar allí. Pero luego, cuando lees sobre instancias puntuales, no hay garantías. El diferencial de precios para el spot es convincente, por lo que me gustaría aprovecharlo tanto como pueda sin dejar de mantener una línea de base siempre activa. es posible?

Por el momento , puede mezclar instancias ondemand y spot en un solo ASG

Amazon EC2 Auto Scaling ahora le permite aprovisionar y escalar automáticamente instancias en opciones de compra, zonas de disponibilidad (AZ) y familias de instancias en un solo grupo de Auto Scaling (ASG), para optimizar la escala, el rendimiento y el costo. Ahora puede incluir instancias puntuales con On-Demand y RI en un solo ASG , para ahorrar hasta un 90% en el cómputo.

El enfoque discutido anteriormente sería un poco desordenado y no tan flexible. El enfoque más canónica es crear sólo 2 ASG (una para comer, uno para bajo demanda) y luego registrarlas tanto con el mismo ELB (discutido aquí ). Esto le brinda la capacidad de controlar cada uno de forma independiente en lugar de tratar de muckear con swaps LC en un solo ASG.

Desafortunadamente, este enfoque híbrido de Auto Scaling no parece estar disponible de fábrica.

Sin embargo, es posible que pueda evitar esta limitación de la siguiente manera (no probado, solo un diseño de sistema que he estado haciendo malabares durante un tiempo):

Posible solución

Como se describe en Uso de Auto Scaling para iniciar instancias spot , la oferta de precio spot es un parámetro de la configuración de lanzamiento en uso. Como señaló, no hay una configuración de lanzamiento híbrida disponible, sino que debe ser a pedido o puntual, lo que significa que el caso de uso requiere dos configuraciones de lanzamiento diferentes.

Esto no parece ayudar de inmediato, porque puede adjuntar solo una configuración de inicio a un grupo de Auto Scaling a la vez , con las siguientes restricciones (parcialmente desactualizadas) (consulte Configuración de inicio ):

Cuando adjunte una configuración de inicio nueva o actualizada a su grupo de Auto Scaling, cualquier nueva instancia se iniciará utilizando los nuevos parámetros de configuración. Las instancias existentes no se ven afectadas . Cuando Auto Scaling necesita reducir, primero termina las instancias que tienen una configuración de inicio más antigua . [énfasis mío]

Sin embargo, las partes enfatizadas son clave, y la primera cubre el requisito de mantener las instancias bajo demanda ejecutándose después de cambiar de la configuración de lanzamiento inicial bajo demanda respectiva a la configuración de lanzamiento spot adicional, y la segunda ya no es necesariamente el caso debido a las Políticas de terminación de Auto Scaling recientemente introducidas (para variar, no ha habido la fanfarria habitual a través de una publicación de blog de AWS adjunta), documentada en la Política de terminación de instancias para su grupo de Auto Scaling :

Antes de que Auto Scaling seleccione una instancia para finalizar, primero identifica la zona de disponibilidad que tiene más instancias que las otras zonas de disponibilidad utilizadas por el grupo. Si todas las zonas de disponibilidad tienen el mismo número de instancias, identifica una zona de disponibilidad aleatoria. Dentro de la zona de disponibilidad identificada, Auto Scaling utiliza la política de terminación para seleccionar la instancia para la terminación . [énfasis mío]

Como se describe en Cómo funciona su política de finalización , ahora puede especificar NewestInstance , si desea que finalice la última instancia iniciada , que sería una de las instancias puntuales lanzadas más recientemente:

Auto Scaling usa el tiempo de inicio de la instancia para identificar la última instancia que se lanzó.

Obviamente, puede haber un poco más de esto, por ejemplo , puede especificar cualquiera de las políticas como una política independiente, o puede enumerar varias políticas en una lista ordenada , pero este enfoque debería garantizar la carga de todas las instancias que se tienen en cuenta en el medidas y disparadores de autoescalado ; Sin embargo, queda una advertencia:

Consideración

Si el equilibrador de carga finaliza una de las instancias bajo demanda por cualquier otro motivo (por ejemplo, porque se ha vuelto poco saludable en sí mismo), no se reemplazará automáticamente por una instancia bajo demanda. Por lo tanto, deberá supervisar y dar cuenta de este evento por separado, por ejemplo, activando temporalmente la configuración de inicio bajo demanda nuevamente.

¡Buena suerte!

Me inspiré en las respuestas aquí para encontrar https://github.com/ashwanthkumar/matsya

Te ayuda a hacer lo siguiente

• Siempre necesita una flota de máquinas para sus requisitos de clúster Hadoop / Mesos / YARN
• Desea ahorrar dinero utilizando Spot pero también recurrir a OD porque necesita la potencia de procesamiento para cumplir con su SLA
• Vuelva a Spot una vez en OD para ahorrar dinero nuevamente.

En caso de que solo desee 1 ASG con un número estático de instancias bajo demanda, lo siguiente debería funcionar:

• Cree un grupo de Auto Scaling basado en la configuración de Lanzamiento de instancia puntual.

• Suspender Auto Scaling en ASG

• Agregue manualmente instancias bajo demanda (carga base estática) a ASG y active la protección de instancias para esas instancias.

• Reanudar el escalado automático en ASG

• La política de escalado automático predeterminada ahora ignorará las instancias bajo demanda (debido a la protección) y terminará el mismo número de instancias puntuales que la instancia bajo demanda para lograr el número deseado del grupo. Cualquier actividad de ampliación o reducción solo iniciará o terminará instancias puntuales.