Daniel López Azaña

Tema

Social Media

Blog

GNU/Linux, Open Source, Cloud Computing, DevOps y más...

Script para cambiar automáticamente todos los volúmenes gp2 a gp3 con aws-cli

Script para cambiar automáticamente todos los volúmenes gp2 a gp3 con aws-cli

El pasado diciembre Amazon anunció sus nuevos volúmenes EBS gp3, los cuales ofrecen mejores prestaciones y un ahorro en el coste del 20% respecto a los que se venían utilizando hasta ahora, los gp2. Pues bien, tras probar satisfactoriamente estos nuevos volúmenes en varios clientes, no puedo hacer otra cosa más que recomendar su utilización , pues son todo ventajas y en estos 2 meses y medio que han transcurrido desde el anuncio no he apreciado ningún problema ni efecto secundario.

Hacer el cambio es tremendamente sencillo, tan sólo hay que seleccionar un volumen desde la consola de AWS y cambiar su tipo así:

Sin embargo, hacerlo de esta manera cuando se dispone de múltiples clientes que pueden tener cientos o miles de estos volúmenes , hace que esto se convierta en una tediosa tarea que nos llevará mucho tiempo y que además será propensa a cometer errores, pues podemos seleccionar un volumen que no era gp2 sin querer, o cambiarlo a otro tipo que no es el gp3 esperado. Y una vez que nos hemos equivocado, el volumen permanece en estado «modifying» bastante tiempo y luego en estado «optimizing» más tiempo todavía, lo cual nos obligará a pasar a otra cosa y luego acordarnos de revisar todos los volúmenes y corregir aquellos en los que nos hayamos equivocado.

Para evitar estos problemas cuando tenemos una gran cantidad de volúmenes EBS, he escrito un sencillísimo script en bash que automatiza completamente la tarea , con lo cual nos ahorrará un montón de tiempo y de tedio y nos protegerá a su vez de cometer errores:

#! /bin/bash

region='us-east-1'

# Find all gp2 volumes within the given region
volume_ids=$(/usr/bin/aws ec2 describe-volumes --region "${region}" --filters Name=volume-type,Values=gp2 | jq -r '.Volumes[].VolumeId')

# Iterate all gp2 volumes and change its type to gp3
for volume_id in ${volume_ids};do
    result=$(/usr/bin/aws ec2 modify-volume --region "${region}" --volume-type=gp3 --volume-id "${volume_id}" | jq '.VolumeModification.ModificationState' | sed 's/"//g')
    if [ $? -eq 0 ] && [ "${result}" == "modifying" ];then
        echo "OK: volume ${volume_id} changed to state 'modifying'"
    else
        echo "ERROR: couldn't change volume ${volume_id} type to gp3!"
    fi
done

El único requisito es disponer de la herramienta jq para manejar mejor el JSON que devuelve el comando aws. La podemos instalar ejecutando simplemente un apt install jq o yum install jq , pues viene incluida en los repositorios de todas las distribuciones Linux.

Hay que tener en cuenta que este script hará que se establezcan los valores por defecto para los parámetros IOPS (3000) y Throughput (125 MB/s), pero como éstos superan ampliamente las prestaciones que ofrecían los volúmenes gp2, no habrá ningún problema.

Ni que decir tiene que este mismo script se puede usar para cambiar masivamente volúmenes EBS de otros tipos, como io1, io2, sc1, st1, etc.

¡Espero que os ayude a ahorrar tiempo y quebraderos de cabeza!

Daniel López Azaña

Sobre el autor

Daniel López Azaña

Emprendedor tecnológico y arquitecto cloud con más de 20 años de experiencia transformando infraestructuras y automatizando procesos.

Especialista en integración de IA/LLM, desarrollo con Rust y Python, y arquitectura AWS & GCP. Mente inquieta, generador de ideas y apasionado por la innovación tecnológica y la IA.

Artículos relacionados

AWS security groups

Cómo actualizar automáticamente todos nuestros grupos de seguridad EC2 de AWS cuando nuestra IP dinámica cambia

Uno de los mayores fastidios cuando trabajamos con AWS y nuestra conexión a Internet tiene IP dinámica es que cuándo ésta cambia, automáticamente dejamos de tener acceso a todos los servidores y servicios que habíamos protegido mediante un grupo de seguridad EC2 cuyas reglas sólo permiten el tráfico a ciertas IP’s específicas en lugar de abrir las conexiones a todo el mundo (0.0.0.0/0).Ciertamente lo más sencillo es siempre indicar en el grupo de seguridad que permitimos el tráfico en un puerto a todo el mundo, de modo que aunque tengamos IP dinámica en nuestra conexión a Internet siempre podremos continuar accediendo aunque ésta cambie. Pero abrir el tráfico a un puerto a todo el mundo no es la forma correcta de proceder desde el punto de vista de la seguridad, pues entonces cualquier atacante podrá tener acceso a ese puerto sin restricciones, y eso no es lo que queremos.

12 de enero de 2021
terraform-and-route53-logos

Cómo importar rápidamente todos los registros de una zona DNS de Route53 en Terraform

El comando terraform import nos permite importar en HashiCorp Terraform recursos que ya existían previamente en el proveedor con el que estemos trabajando, es este caso AWS. Sin embargo, sólo permite importar dichos registros uno por uno, con una ejecución de terraform import cada vez. Esto, aparte de ser tremendamente tedioso, en algunas situaciones se vuelve directamente impracticable. Este es el caso de los registros de una zona DNS de Route53. La tarea puede resultar inabarcable si tenemos varias zonas DNS, y cada una tiene decenas o cientos de registros. En este artículo te ofrezco un script en bash que te permitirá importar en Terraform todos los registros de una zona DNS de Route53 en cuestión de segundos o de pocos minutos.

8 de febrero de 2022
Logo AWS EBS

Cómo ampliar el tamaño de un volumen EBS y de una partición ext4 en AWS

Cuando se nos llena completamente el sistema de ficheros de una partición ext4 alojada en un volumen EBS de Amazon Web Services y no podemos hacer nada por liberar espacio al no querer perder ninguno de los datos almacenados, el único remedio que nos queda es ampliar el volumen y hacer crecer la partición asociada hasta el 100% de su capacidad para disponer nuevamente de espacio libre de almacenamiento.Partimos en nuestro ejemplo de un volumen de 50 GB lleno al 100% que queremos ampliar a uno nuevo del doble de tamaño, 100 GB:

23 de mayo de 2017

Comentarios

Javier 18 de septiembre de 2021
Llegue a este blog casi por casualidad (como todo lo bueno) y la verdad que le he sacado el jugo bastante en este sabado. directo a favoritos y queria tomarme el tiempo de agradecerte por hacer estos articulos. se que la vida del DevOps es complicada y uno no dispone de mucho tiempo libre, pero usar el poco que tiene disponible para compartir el conocimiento se aprecia mucho. saludos desde Argentina
Daniel 31 de octubre de 2021
¡Gracias por tus palabras Javier!
Javi 27 de enero de 2022
Hola Realmente, en gp2 los valores de iops y througput dependen del tamaño, ¿no? Por lo que podemos tener el caso que con volumenes grandes den mśa rendimiento?. Por otro lado, ¿Se hace en caliente? ¿Como funciona esto por debajo? Es decir, mueve los datos de un disco a otro? saludos
Daniel 27 de enero de 2022
Bueno, técnicamente sí si lo comparas con volúmenes de más de 1 TB de tipo gp3 a los que no has incrementado el número de IOPS base de 3000. Es decir, un volumen gp3 tiene como base 3000 IOPS independientemente del tamaño que tenga. Para alcanzar ese nivel de IOPS en un gp2 tendrías que tener un volumen de al menos 1 TB. Pero es que a un gp3 le puedes aumentar el nº de IOPS hasta 16000 de máximo, con lo cual yo creo que compensa en todo caso optar por un gp3. No obstante, en esta página de Amazon tienes toda la información detallada sobre cómo funciona todo esto: https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/ebs-volume-types.html
Daniel 27 de enero de 2022
Sí, se hace en caliente. Por debajo es una red SAN de almacenamiento. Efectivamente lo que hace es mover tus datos de un "disco" a otro. Y lo pongo entre comillas porque a nivel físico no es un disco, es un espacio asignado dentro de una cabina de discos redundados, que a su vez están también redundadas para garantizar una mayor durabilidad y disponibilidad de los datos.

Enviar comentario