Blog de Amazon Web Services (AWS)
Utilizar la reserva de capacidad optimizando el costo y el impacto en el medio ambiente
Por Alexis Dagues, Juan Diaz, Iadh Allani, y Laurent Busecké
Una práctica recomendada para ganar resiliencia es implementar sus aplicaciones en varias zonas de disponibilidad dentro de una región de AWS. Podemos lograrlo separando los componentes que se pueden separar para garantizar la disponibilidad del servicio en caso de pérdida de uno o más componentes.
Sin embargo, algunas aplicaciones consumen muchos recursos y pueden requerir que los componentes se concentren en un solo servidor. Por lo tanto, estas aplicaciones no pueden, por diseño, aprovechar una arquitectura «multi-az» (varias zonas de disponibilidad) y se implementan en la misma zona de disponibilidad.
En caso de falla mayor en la Zona de Disponibilidad donde se implementa el entorno de producción, nuestros clientes necesitan garantizar la disponibilidad de la capacidad de cómputo de Amazon EC2 en otra Zona de Disponibilidad para activar el plan de continuidad del negocio y asegurar sus procesos.
Para garantizar la capacidad de los recursos de cómputo de EC2 en una Zona de Disponibilidad de una Región de AWS, especialmente para entornos de producción, nuestros clientes cuentan con dos funcionalidades. Por un lado, reservas de instancias por zona de disponibilidad y por otro, reserva de capacidad bajo demanda, una solución flexible y totalmente articulada con el uso de Saving Plans, EC2 o Compute. Ambas características están en el ámbito de la zona de disponibilidad definida.
Una pregunta recurrente de nuestros clientes es: “¿Cómo puedo tener la mayor eficiencia económica y limitar mi huella de carbono con la certeza de tener la capacidad necesaria al momento de activar mi plan de continuidad?”
Un enfoque común es implementar un entorno que no sea de producción; a menudo la pre-producción, que tiene un tamaño idéntico al de la producción, en una segunda zona de disponibilidad y reserva la capacidad necesaria para su funcionamiento.
Si falla la zona de disponibilidad que aloja el entorno de producción, podemos cerrar el entorno de no producción y aprovechar su capacidad reservada para iniciar un nuevo entorno de producción. Tenga en cuenta que las reservas de capacidad se pueden compartir entre diferentes cuentas de AWS o entre las mismas AWS Organizations. Por lo tanto, las instancias de producción y las instancias que no son de producción no necesitan residir en la misma cuenta de AWS. Siguiendo este enlace encontrará más información sobre el reparto de capacidad reservada: https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/capacity-reservation-sharing.html
Proponemos una arquitectura de recuperación ante desastres que aprovechará la reserva de capacidad en dos zonas de disponibilidad (la primera para producción, la segunda para un entorno que no sea de producción, como la preproducción) para superar la falla de una zona de disponibilidad. Esta arquitectura corresponde a “Pilot Light” que describimos con más precisión en este whitepaper.
Esta arquitectura permite dar respuesta a tres cuestiones destacadas en los pilares del Well-Architected Framework. Permite optimizar costes, limitar la huella de carbono y optimizar la resiliencia densificando el uso de las infraestructuras y limitando el despilfarro de recursos reservados pero no utilizados.
Algunos ejemplos de arquitecturas Mono-AZ que pueden beneficiarse de esta implementación son: SAP, Oracle en EC2 o cualquier aplicación que limite la cantidad de instancias por razones de optimización de licencias.
Implementación
Crear una reserva de capacidad en la zona donde la production sera creada :
- Instance Type – Tipo de instancia que sera lanzada,
- Instance Platform – El sistema operativo de la EC2,
- Availability Zone – La zona de disponibilidad donde sera lanzada la EC2,
- Instance Count – Cuantas capacidades seran reservadas, 2 para reservar para 2 EC2 del mismo tipo, 3 para 3 EC2.
Este comando tiene como salida un json que contiene un CapacityReservationId parecido a este : “cr-05e49c438fd186e71”
Utilizando la consola:
Hacer clic en Create Capacity Reservation :
La reserva de capacidad bajo demanda permite a los usuarios de AWS definir una ventana de uso en la que se reservará esta capacidad, por ejemplo, para garantizar la ejecución de cálculos intensivos por lotes. En nuestro caso, queremos controlar manualmente el final de esta reserva y apuntar qué instancia la usa (Instance Eligibility: Targeted)
Supervisión de sus reservas de capacidad bajo demanda
La función de Reserva de capacidad bajo demanda le permite elegir una fecha en la que se detiene la reserva. Esto es interesante durante necesidades puntuales, y cuyo final de procesamiento es predecible, pero para las cuales es necesario garantizar la disponibilidad de cálculo (Batch, HPC).
En nuestro caso, no definimos una fecha de finalización para la reserva de capacidad. Entonces es necesario monitorear la utilización de la reserva para asegurarse de que se utilice en su totalidad y evitar costos que no correspondan al uso real de la misma.
El monitoreo del uso de la reserva de capacidad bajo demanda se realiza desde Cloudwatch Metrics, utilizando la métrica InstanceUtilization del espacio de nombres AWS/EC2CapacityReservations.
https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/capacity-reservation-cw-metrics.html
Es posible activar una alarma cuando el umbral de esta métrica es inferior a 100. Esta alarma puede enviar una notificación SNS. https://docs.aws.amazon.com/es_es/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html
Desde abril de 2023 si menos del 20% de las reservaciones están siendo utilizadas una notificación será enviada a través del panel de AWS Health, Cloudwatch Events y por correo electrónico.
- Cree una reserva de capacidad bajo demanda en la zona donde se lanzará la no producción:
- Inicie la instancia de producción en la capacidad reservada de producción:
a. Image Id – ID de la imagen AMI para lanzar
b. Count –El número de instancias para lanzar
c. Instance Type: Tipo de instancia para lanzar en capacidad reservada
d. Subnet Id : ID de la subred donde se lanzará la instancia
e. Capacity Reservation Id : el ID de la capacidad reservada
Este comando devuelve la identificación de la instancia iniciada.
En la consola web, al definir la instancia EC2:
Recuperación de desastres
Si se ejecuta el plan de recuperación ante desastres:
- Apague la instancia que no es de producción, lo que libera la capacidad reservada que no es de producción en la zona de disponibilidad de no producción
- Inicie la instancia de producción desde la AMI y asígnele la capacidad de no producción reservada:
Después de la recuperación ante desastres
Después de la ejecución del plan de recuperación ante desastres podemos recrear la instancia de producción y asignarle la reserva de capacidad de producción, se procede de la misma manera con la instancia de no producción para restaurar la situación nominal.
Conclusión
Este artículo propone utilizar la reserva de capacidad bajo demanda para optimizar sus costos y el impacto ambiental de sus infraestructuras de producción mientras mejora su resiliencia. La reserva de capacidad bajo demanda es flexible y reversible en cualquier momento en función de la evolución de sus entornos y de sus necesidades reales de capacidad. Totalmente automatizable a través de la CLI de AWS, el SDK de AWS o AWS CloudFormation, ahora puede actualizar los runbooks de sus diferentes aplicaciones.
Este artículo fue traducido del Blog de AWS en Francés.
Acerca de los autores
Alexis Dagues es Senior Solutions Architect
Juan Diaz es Solutions Architect
Iadh Allani es Solutions Architect
Laurent Busecké es Senior Technical Account Manager.