He visto esta respuesta para aumentar los volúmenes de EBS , pero me gustaría reducir uno.
Las imágenes predeterminadas de Ubuntu Server son de 15 GB, mientras que realmente solo necesito 2 GB como máximo (uso un volumen diferente para los datos). ¿Hay alguna manera de reducir el tamaño del volumen?
Respuestas:
Tenía la misma pregunta que tú, así que resolví cómo hacerlo.
Primero, hice esto desde el ami Ubuntu de 32 bits respaldado por EBS de la región este de EE. UU., Otros sistemas operativos o imágenes pueden funcionar de manera diferente. Sin embargo, sospecho que deberías estar bien, siempre y cuando estés usando un sistema de archivos ext *. Puede funcionar en otros sistemas de archivos, pero tendrá que descubrir cómo cambiar su tamaño por su cuenta.
Los pasos son básicamente:
Adjunte dos volúmenes a una instancia en ejecución, el primero basado en la instantánea que desea reducir y el segundo un volumen en blanco con el nuevo tamaño al que desea reducir.
Verifique el sistema de archivos del primer volumen y repare cualquier error.
Reduzca el sistema de archivos en el primer volumen para que sea tan grande como sea necesario para mantener los datos.
Copie el sistema de archivos del primer volumen al segundo.
Expanda el sistema de archivos en el segundo volumen a su tamaño máximo.
Asegúrese de que todo se vea bien al verificar el segundo volumen en busca de errores.
Tome una instantánea del segundo volumen.
Cree una imagen de máquina basada en la instantánea del segundo volumen que acaba de tomar.
Primero necesita obtener información de la ami que desea reducir. En particular, necesita la ID del kernel y la ID de ramdisk, si las hay (la imagen que reduje no tenía un ramdisk). Toda esta información debe estar disponible desde la consola de administración de aws, en la ventana AMI.
La ID del núcleo se parece a kia-xxxxxxxx, y la ID de la instantánea se parece a snap-xxxxxxxx, y las ID de ramdisk se parecen a RIA-xxxxxxxx.
A continuación, inicie una instancia de Linux. Lancé una instancia de Ubuntu. Puede usar una instancia t1.micro si lo desea. No se necesita mucho poder para realizar estos próximos pasos.
Después de que la máquina esté funcionando, adjunte la instantánea que anotó desde el primer paso. En mi caso, lo adjunté a / dev / sdf
Luego, cree un nuevo volumen, que tenga el tamaño que desee. En mi caso, creé un volumen de 5GB, ya que ese es el tamaño al que quería reducirlo. No cree este nuevo volumen a partir de una instantánea. Necesitamos un nuevo volumen en blanco. Luego, adjúntelo a la instancia en ejecución, en mi caso, lo adjunté como / dev / sdg
Luego, ssh en la máquina pero no monte los volúmenes adjuntos.
En este punto, erré del lado de la paranoia, y opté por verificar el sistema de archivos en el gran volumen, solo para asegurarme de que no hubiera errores. Si está seguro de que no hay ninguno, puede omitir este paso:
$ sudo e2fsck -f /dev/sdf
Luego, cambié el tamaño del sistema de archivos en el volumen grande para que solo fuera tan grande como los datos en el disco:
$ sudo resize2fs -M -p /dev/sdf
La -M lo encoge y la -p imprime el progreso.
Resize2fs debería decirle qué tan grande es el sistema de archivos retráctil. En mi caso, me dio el tamaño en bloques de 4K.
Ahora copiamos el sistema de archivos shrunkin al nuevo disco. Vamos a copiar los datos en fragmentos de 16 MB, por lo que debemos averiguar cuántos fragmentos de 16 MB necesitamos copiar. Aquí es donde el tamaño reducido del sistema de archivos entra en juego.
En mi caso, el sistema de archivos reducido tenía poco más de 1 GB, porque había instalado muchos otros programas en el sistema básico de Ubuntu antes de tomar una instantánea. Probablemente podría haber salido con solo copiar el tamaño del sistema de archivos redondeado a los 16 MB más cercanos, pero quería jugar a lo seguro.
Entonces, 128 veces 16MB trozos = 2GB:
$ sudo dd if=/dev/sdf ibs=16M of=/dev/sdg obs=16M count=128
Copié en bloques de 16 MB porque con EBS, usted paga por cada lectura y escritura, por lo que quería minimizar el número de ellos tanto como sea posible. No sé si hacerlo así lo hizo, pero probablemente no dolió.
Luego, debemos cambiar el tamaño del sistema de archivos que acabamos de copiar al nuevo volumen para que use todo el espacio disponible en el volumen.
$ sudo resize2fs -p /dev/sdg
Finalmente, verifíquelo para asegurarse de que todo esté bien:
$ sudo e2fsck -f /dev/sdg
Eso es todo lo que necesitamos hacer en esta máquina, aunque no estaría de más montar el nuevo volumen, solo como prueba. Sin embargo, este paso es casi seguro opcional, ya que e2fsck debería haber detectado algún problema.
Ahora necesitamos tomar una instantánea del nuevo volumen y crear un AMI basado en él. Hemos terminado con la máquina, por lo que puede terminarla si lo desea.
Asegúrese de desmontar el pequeño volumen si lo montó, y luego tome una instantánea. Nuevamente, puede hacer esto en la consola de administración.
El último paso requiere la línea de comandos ec2 herramientas.
EDITAR:
Dado que esta respuesta se publicó, la consola de AWS le permite simplemente hacer clic con el botón derecho en una instantánea y seleccionar Crear imagen a partir de una instantánea. Aún deberá seleccionar la ID de kernel adecuada. Si no aparece en la lista, asegúrese de haber seleccionado la arquitectura adecuada.
Utilizamos la aplicación ec2-register para registrar un AMI basado en la instantánea que acaba de tomar, así que escriba el valor snap-xxxxxxxx de la instantánea que acaba de tomar.
Entonces deberías usar un comando como:
ec2-register -C cert.pem -K sk.pem -n The_Name_of_Your_New_Image
-d Your_Description_of_This_New_AMI --kernel aki-xxxxxxxx
-b "/dev/sda1=snap-xxxxxxxx" --root-device-name /dev/sda1
Por supuesto, debe reemplazar la ID del kernel con la que escribió al principio y la ID de la instantánea con la que creó en el paso anterior. También necesita apuntarlo a su clave secreta (llamada sk.pem) arriba, y su certificado x509 (llamado cert.pem). Por supuesto, puede elegir lo que quiera para el nombre y la descripción.
Espero que esto ayude.
sudo e2fsck -f /dev/sdfpodría ser un paso obligatorio antes de hacer el cambio de tamaño (en mi caso particular, una AMI de Amazon Linux).
sudo mkfs -t ext4 /dev/sdg.
Sí, también me he preguntado esto. El siguiente tutorial es excesivo, pero creo que contiene las herramientas necesarias: http://www.linuxconfig.org/Howto_CREATE_BUNDLE_UPLOAD_and_ACCESS_custom_Debian_AMI_using_ubuntu
En lugar de instalar en una nueva imagen de disco como se indicó anteriormente, debería ser posible iniciar la AMI grande, crear una nueva EBS, adjuntar EBS a la instancia en ejecución y copiar la AMI en ejecución a la nueva EBS. Finalmente, registre el nuevo EBS como AMI.
Eche un vistazo a esta publicación de blog para obtener más información, especialmente el comentario de freremark: http://alestic.com/2010/01/public-ebs-boot-amis-for-ubuntu-on-amazon-ec2
En una nota final, euca2ools parece un gran reemplazo para ec2-ami-tools: ¡euca2ools incluye páginas de manual reales! Tienen todos los mismos nombres que los comandos ec2- *, solo que con el prefijo euca-. http://open.eucalyptus.com/wiki/Euca2oolsUsing
Quería reducir el tamaño del volumen que usa una instancia general de EC2. Seguí pasos similares a las otras respuestas aquí, pero me encontré con un problema. Entonces, esto es lo que tuve que hacer para reducir mi volumen raíz ...
En la consola de AWS
1. Stop the source EC2 instance
2. Create a snapshot of the volume you want to shrink
3. Use the snapshot to create a new 'source' volume
4. Created a new volume with smaller size (made sure it was big enough for the data on source)
5. Attached both volumes to any EC2 instance (mine were /dev/sdf = source & /dev/sdg = target)
6. Start the EC2 instance
En la instancia EC2
7. sudo su - (everything from here is run as root)
8. mkdir /source /target
9. mount -t ext4 /dev/sdf /source
10. mkfs.ext4 /dev/sdg
11. mount -t ext4 /dev/sdg /target
12. rsync -aHAXxSP /source/ /target
** notice that there is no trailing '/' after target if
you put one there your data will be copied to
/target/source and you will have to move it up a directory
13. cat /boot/grub/grub.conf (indicated that grub is using root=LABEL=/)
14. cat /source/etc/fstab (indicated that fstab was also using LABEL=/)
15. e2label /dev/sdg /
16. umount /source
17. umount /target
De vuelta en la consola de AWS
18. Stop the instance
19. Detach ALL volumes from the instance
20. Attach the 'target' volume to the instance using /dev/sda1 as the device
21. Start the instance
Aquí es donde nos encontramos con un problema que no se ha mencionado hasta donde puedo encontrar. La instancia comenzó bien, ¡genial! Pero cuando traté de ssh a la instancia, no pude conectarme. Después de muchas variaciones de los pasos anteriores, finalmente decidí intentar usar el volumen raíz de una instancia EC2 recién creada.
En la consola de AWS
1. Create a new EC2 instance with the right sized root volume
2. Stop the new instance
3. Detach the /dev/sda1 volume from the new instance
** used the 'source' volume from before & the new volume we just detached
4. Attached both volumes to the original EC2 instance (/dev/sdf & /dev/sdg)
5. Start the instance with the attached volumes
En la instancia EC2
1. sudo su -
2. mkdir /source /target (only need to do this if you don't already have these directories)
3. mount -t ext4 /dev/sdf /source
4. mount -t ext4 /dev/sdg /target (no need to create a file system because it is already there)
5. rsync -aHAXxSP /source/ /target
6. umount /source
7. umount /target
De vuelta en la consola de AWS
1. Stop the instance
2. Detach the 'source' and 'target' volumes from instance
3. Attach the 'target' volume to the instance from step 1 using /dev/sda1 as the device
4. Start the instance
5. ** we use an elastic IP so we just reassigned the IP to the new instance
Espero que esto ayude a alguien