Una de las pocas cosas que no me gustan del servicio EC2 de Amazon Web Services es que todas las imágenes o AMI’s disponibles a partir de las cuales lanzar una nueva instancia requieren un volumen raíz o root volume de un mínimo de 8 ó 10 GB y todos ellos cuentan además con una única partición donde se monta el sistema de ficheros raíz con todos sus directorios.

En mi artículo La importancia de particionar correctamente un disco en Linux ya discutí por qué este enfoque no me parece adecuado y en este artículo voy a abordar cómo dividir dichos volúmenes en varias particiones conservando el tamaño base de 8-10 GB o haciéndolos incluso más pequeños para ahorrar costes en caso de que queramos montar servidores más pequeños que no necesiten tanto espacio de almacenamiento.

Requerimientos previos

Para llevar a cabo este procedimiento es necesario contar con una instancia EC2 auxiliar aparte de aquella cuyo volumen raíz queramos particionar. Servirá cualquier tipo de instancia, por lo que podemos optar por la más económica disponible actualmente, la t2.nano. Dado que Amazon sólo nos cobrará por el tiempo que tardemos en ejecutar el procedimiento (unos 30 minutos) y luego terminaremos la instancia, el coste asociado será muy bajo.

Si ya disponemos de otra instancia EC2 corriendo en la misma región y zona de disponibilidad no será necesario crear una nueva, ya que podremos usar la existente para montar los volúmenes que vamos a necesitar más adelante. Estos montajes no tendrán ningún impacto significativo sobre el rendimiento ni la capacidad del servidor auxiliar que utilicemos, pero aún así no es recomendable usar uno en producción que sea crítico para nosotros, pues si nos equivocamos en algún paso podemos afectar el servicio que presta.

No es imprescindible, pero si muy recomendable, que la instancia auxiliar tenga la misma distribución y versión de Linux que la instancia que queremos particionar para que la instalación del cargador de arranque en el nuevo volumen sea lo más directa y exenta de problemas posible. Para el ejemplo de este artículo he utilizado una instancia Ubuntu 16.04.2 LTS.

Partimos por tanto con 2 instancias en ejecución: aquella que queremos particionar y la instancia auxiliar que voy a llamar AMI y AUX respectivamente, cada una con su correspondiente root volume: amiroot y auxroot.

Situación de partida: instancias AMI y AUX con sus respectivos volúmenes raíz

Instancias EC2 de partida

Volúmenes EBS de partida

1. Crear un nuevo volumen EBS

En nuestro ejemplo vamos a crear un volumen más pequeño (6 GB) que el tamaño por defecto de 8 GB que ofrece Amazon, pero podemos elegir el tamaño que más nos convenga, sea éste mayor o menor de 8 GB. Podemos aprovechar también para cifrar el nuevo volumen , ya que por defecto todos los volúmenes raíces que utilizan las AMI’s de Amazon no están encriptados.

Creación del nuevo volumen EBS a particionar

Creación nuevo volumen cifrado inferior a 8 GB

Nuevo volumen creado no vinculado a ninguna instancia

2. Vincular volúmenes amiroot y myroot a la instancia auxiliar

Ahora desvincularemos el volumen amiroot de la instancia AMI y lo vincularemos a la instancia auxiliar AUX. Para ello es necesario detener primero la instancia AMI, ya que al ser su root volume no se puede desvincular sin pararla antes. Por el contrario, ambos volúmenes se pueden vincular a la instancia auxiliar en caliente sin ningún problema, pues su volumen raíz es auxroot y ese no lo tocaremos en ningún momento. Asignaremos el dispositivo /dev/sdf al volumen amiroot y el /dev/sdg a myroot.

Diagrama de la instancia auxiliar con los 3 volúmenes vinculados

Desvincular volumen amiroot de la instancia AMI

Vincular volumen amiroot a la instancia auxiliar

3. Comprobar que la instancia auxiliar reconoce los nuevos volúmenes vinculados

Entraremos mediante SSH a la instancia auxiliar y comprobaremos que los nuevos volúmenes están disponibles con el comando lsblk :

~$ ssh ubuntu@ec2-54-194-114-199.eu-west-1.compute.amazonaws.com -i ~/.ssh/awskey.pem 
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-1020-aws x86_64)
...
...
ubuntu@ip-172-31-17-107:~$ lsblk 
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT 
xvda    202:0    0   8G  0 disk  
└─xvda1 202:1    0   8G  0 part / 
xvdf    202:80   0   8G  0 disk  
└─xvdf1 202:81   0   8G  0 part  
xvdg    202:96   0   6G  0 disk

Si todo ha ido bien debería aparecer nuestro volumen amiroot como xvdf y myroot como xvdg. Como se puede observar, existe una partición /dev/xvdf1 de 8 GB ya creada que se corresponde con la partición que traía el volumen raíz de la instancia creada a partir de la AMI de Amazon. El volumen myroot como se ha creado desde cero no tiene todavía ninguna partición creada.

4. Crear esquema de particiones personalizado en el volumen myroot

Ha llegado el momento de particionar el volumen a nuestro gusto , que es realmente nuestro objetivo inicial. Si tienes dudas de qué particiones crear y qué tamaños asignar a cada una de ellas te recomiendo que eches un vistazo al siguiente artículo:

Lectura recomendada:
La importancia de particionar correctamente un disco en Linux

A continuación indico los comandos necesarios para establecer una tabla de particiones GPT, una partición de arranque BBP (BIOS Boot Partition) y el esquema de particionamiento deseado para nuestro volumen de 6 GB usando la herramienta parted :

~# parted /dev/xvdg
GNU Parted 3.2 
Using /dev/xvdg 
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
(parted) mkpart bbp 1MB 2MB
(parted) set 1 bios_grub on
(parted) mkpart root ext4 2MB 20%
(parted) mkpart swap linux-swap 20% 25%
(parted) mkpart home ext4 25% 30%
(parted) mkpart usr ext4 30% 65%
(parted) mkpart var ext4 65% 100%

Una vez creadas, la tabla de particiones debería mostrar un aspecto similar a este:

(parted) unit GiB                                                          
(parted) p                                                                 
Model: Xen Virtual Block Device (xvd) 
Disk /dev/xvdg: 6.00GiB 
Sector size (logical/physical): 512B/512B 
Partition Table: gpt 
Disk Flags:  
 
Number  Start    End      Size     File system     Name  Flags 
 1      0.00GiB  0.00GiB  0.00GiB                  bbp   bios_grub 
 2      0.00GiB  1.20GiB  1.20GiB                  root 
 3      1.20GiB  1.50GiB  0.30GiB  linux-swap(v1)  swap 
 4      1.50GiB  1.80GiB  0.30GiB  ext4            home 
 5      1.80GiB  3.90GiB  2.10GiB  ext4            usr 
 6      3.90GiB  6.00GiB  2.10GiB  ext4            var

De cara a obtener un mejor rendimiento querremos comprobar si todas las particiones están alineadas de forma óptima conforme a la geometría del disco. En realidad esto sólo es necesario si hemos creado un volumen EBS tipo HDD, como los st1 , sc1 o magnetic , pues los volúmenes gp2 e io1 usan discos SSD (puedes ver las características de los distintos tipos de volúmenes EBS de AWS en https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html).

(parted) align-check optimal 1                                             
1 aligned 
(parted) align-check optimal 2 
2 aligned 
(parted) align-check optimal 3 
3 aligned 
(parted) align-check optimal 4 
4 aligned 
(parted) align-check optimal 5 
5 aligned
(parted) align-check optimal 6
6 aligned

No obstante, si has especificado el tamaño de las particiones usando porcentajes (%) en lugar de GB, MB o sectores no tendrás que preocuparte por esto porque parted siempre las alineará de forma óptima y el resultado de la comprobación anterior será siempre satisfactorio.

Al salir de parted es posible que recibas el siguiente mensaje:

(parted) quit
Información: Puede que sea necesario actualizar /etc/fstab

En ese caso, si no vemos el nuevo esquema de particiones con el comando lsblk tendremos que ejecutar el comando partprobe y a continuación ya debería mostrase correctamente:

~# lsblk                                             
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT 
xvda    202:0    0    8G  0 disk  
└─xvda1 202:1    0    8G  0 part / 
xvdf    202:80   0    8G  0 disk  
└─xvdf1 202:81   0    8G  0 part  
xvdg    202:96   0    6G  0 disk  
├─xvdg1 202:97   0    1M  0 part  
├─xvdg2 202:98   0  1.2G  0 part  
├─xvdg3 202:99   0  307M  0 part  
├─xvdg4 202:100  0  307M  0 part  
├─xvdg5 202:101  0  2.1G  0 part  
└─xvdg6 202:102  0  2.1G  0 part

5. Formatear las nuevas particiones

Una vez encontremos el esquema de particiones a nuestro gusto procederemos a formatearlas todas ellas excepto la partición de arranque BPP y la de swap. Usaremos el sistema de ficheros más estándar de Linux, el ext4:

~# for I in 2 4 5 6; do mkfs.ext4 /dev/xvdg${I}; done
...
...
~# mkswap /dev/xvdg3
Setting up swapspace version 1, size = 307 MiB (321908736 bytes) 
no label, UUID=1aad1fa2-188e-4b7a-8a0f-33f775cdd329

6. Montar las particiones

Montaremos todas aquellas particiones cuyo contenido nos interese replicar a partir del disco raíz de la AMI de partida, que serán la partición raíz (/), /home, /usr y /var del volumen myroot. También montaremos la partición raíz del volumen amiroot :

~# mkdir /mnt/amiroot
~# mkdir -p /mnt/myroot/root /mnt/myroot/home /mnt/myroot/usr /mnt/myroot/var

~# tree /mnt 
/mnt 
├── amiroot 
└── myroot 
    ├── home 
    ├── root 
    ├── usr 
    └── var 
 
6 directories, 0 files

~# mount /dev/xvdf1 /mnt/amiroot
~# mount /dev/xvdg2 /mnt/myroot/root
~# mount /dev/xvdg4 /mnt/myroot/home
~# mount /dev/xvdg5 /mnt/myroot/usr
~# mount /dev/xvdg6 /mnt/myroot/var

7. Sincronizar el contenido de amiroot en su correspondiente partición

Sincronizaremos con rsync el contenido de los distintos directorios de la única partición del volumen raíz de la AMI de partida (amiroot) en sus correspondientes particiones asignadas. Hay que tener la precaución de no copiar en la nueva partición raíz el contenido de esos mismos directorios que ahora tienen una partición propia asignada, por lo que usaremos el parámetro –exclude de rsync. Dado que hemos excluido esos directorios, los crearemos manualmente, pero vacíos y con los permisos adecuados:

~# rsync -av /mnt/amiroot/home/ /mnt/myroot/home/
~# rsync -av /mnt/amiroot/usr/ /mnt/myroot/usr/
~# rsync -av /mnt/amiroot/var/ /mnt/myroot/var/
~# rsync -av --exclude=home --exclude=usr --exclude=var /mnt/amiroot/ /mnt/myroot/root/
~# mkdir /mnt/myroot/root/home;chmod 755 /mnt/myroot/root/home
~# mkdir /mnt/myroot/root/usr;chmod 755 /mnt/myroot/root/usr
~# mkdir /mnt/myroot/root/var;chmod 755 /mnt/myroot/root/var

Es muy importante que llegados a este punto desmontemos la partición del volumen original amiroot y lo desvinculemos de la instancia auxiliar para que el instalador del cargador de arranque grub que ejecutaremos en el siguiente punto no detecte que hay otra partición bootable que no nos interesa que interfiera con la de nuestro nuevo volumen. No basta sólo con desmontarla con el comando umount , sino que será necesario también desconectarla de la instancia como hemos hecho anteriormente en el apartado 2.

~# sync && umount /mnt/amiroot

8. Instalar el cargador de arranque grub en el nuevo volumen myroot

Antes de hacerlo tendremos la precaución de deshabilitar los scripts /etc/grub.d/10_linux y /etc/grub.d/20_linux_xen porque pueden generar algún problema a la hora de detectar nuestra partición arrancable BPP. Para ello bastará con que añadamos el comando exit a la segunda línea de ambos ficheros, justo después de #! /bin/sh.

A continuación eliminaremos el fichero /boot/grub/grub.cfg que era el que traía la AMI en origen para sustituirlo por uno adaptado a nuestro nuevo volumen recién particionado:

~# rm /mnt/myroot/root/boot/grub/grub.cfg
~# grub-mkconfig -o /mnt/myroot/root/boot/grub/grub.cfg

Ahora ya podemos instalar el cargador de arranque grub en nuestro nuevo disco de 6 GB:

<span style="font-weight: 400;">~# grub-install --target=i386-pc --directory=/mnt/myroot/usr/lib/grub/i386-pc --recheck --boot-directory=/mnt/myroot/root/boot /dev/xvdg</span>

No olvidar volver a habilitar los scripts 10_linux y 20_linux_xen cuando hayamos terminado si hemos utilizado como instancia auxiliar un servidor que estemos usando para otro cometido. Si no dará igual porque al finalizar el procedimiento terminaremos la instancia y ésta se destruirá.

9. Reflejar en el fichero /etc/fstab las nuevas particiones

Primero será necesario obtener los identificadores UUID de las particiones con el comando blkid. Es mejor ejecutarlo como root porque si no no mostrará información de la partición de swap.

~# blkid 
/dev/xvda1: LABEL="cloudimg-rootfs" UUID="567ab888-a3b5-43d4-a92a-f594e8653924" TYPE="ext4" PARTUUID="1a7d4c6a-01" 
/dev/xvdg2: UUID="<strong>286a4418-45b4-40c6-aece-6a4e1efd247a</strong>" TYPE="ext4" PARTLABEL="root" PARTUUID="56c0cfb6-20eb-4123-a766-420911980fb3" 
/dev/xvdg4: UUID="<strong>6e244eed-310f-4aae-aaa1-7ef549bbdbd1</strong>" TYPE="ext4" PARTLABEL="home" PARTUUID="bdbacb79-532b-410f-853e-f5530c4f9fa7" 
/dev/xvdg5: UUID="<strong>cceffcdd-1aeb-4aab-b8e0-7ac04893858c</strong>" TYPE="ext4" PARTLABEL="usr" PARTUUID="fbee2b01-9d41-4c16-bda6-a4b2abc02a04" 
/dev/xvdg6: UUID="<strong>b3fe50cb-b147-4b3b-b8ce-17ee445db64c</strong>" TYPE="ext4" PARTLABEL="var" PARTUUID="b4983050-a4e6-4d8a-9284-1a269a451d35"
/dev/xvdg3: UUID="<strong>1aad1fa2-188e-4b7a-8a0f-33f775cdd329</strong>" TYPE="swap" PARTLABEL="swap" PARTUUID="24eecaf3-4942-4ead-bab4-909e359dd5ae"
/dev/xvdg1: PARTLABEL="bbp" PARTUUID="916ca11f-db90-48d1-93d2-de6a99b60f40"

A continuación trasladaremos esos identificadores al fichero /mnt/myroot/root/etc/fstab así:

UUID=<strong>286a4418-45b4-40c6-aece-6a4e1efd247a</strong>  /      ext4   defaults,discard,noatime,errors=remount-ro      0 1
UUID=<strong>6e244eed-310f-4aae-aaa1-7ef549bbdbd1</strong>  /home  ext4   defaults,noatime,acl,user_xattr,nodev,nosuid    0 2
UUID=<strong>cceffcdd-1aeb-4aab-b8e0-7ac04893858c</strong>  /usr   ext4   defaults,noatime,nodev,errors=remount-ro        0 2
UUID=<strong>b3fe50cb-b147-4b3b-b8ce-17ee445db64c</strong>  /var   ext4   defaults,noatime,nodev,nosuid                   0 2
UUID=<strong>1aad1fa2-188e-4b7a-8a0f-33f775cdd329</strong>  swap   swap   defaults                                        0 0
tmpfs                                      /tmp   tmpfs  defaults,noatime,nodev,noexec,nosuid,size=256m  0 0

Si quieres saber más sobre el significado de las opciones de montaje que he utilizado te recomiendo de nuevo la lectura de mi artículo La importancia de particionar correctamente un disco en Linux.

10. Vincular el nuevo volúmen como root volume de la instancia que lanzamos a partir de la AMI

Como parte del último punto de este procedimiento desmontaremos todas las particiones que montamos anteriormente y desvincularemos el volumen myroot ya particionado, configurado y listo para el arranque de la instancia auxiliar para vincularlo a la instancia definitiva en la que será utilizado, en nuestro ejemplo la instancia AMI que lanzamos en un primer momento.

~# sync && umount /mnt/myroot/root /mnt/myroot/home /mnt/myroot/usr /mnt/myroot/var

Es muy importante que cuando vinculemos el volumen myroot a la instancia EC2 indiquemos como dispositivo /dev/sda1 para indicar que se trata del root volume de la instancia, ya que si no lo ponemos así tendremos problemas con el arranque del sistema operativo.

Si todo ha ido bien nuestra instancia arrancará normalmente y podremos ver en el log de sistema de la instancia EC2 el mensaje de login tal y como aparece en la tercera captura a continuación. Si algo va mal obtendremos más información del problema en ese mismo log.

Diagrama situacion final: instancia AMI con root volume vinculado

Vincular volumen como root volume (/dev/sda1)

Log del sistema de una instancia que ha arrancado satisfactoriamente

Y eso es todo. Ahora si te conectas a la nueva instancia verás que todo es igual que antes, pero si haces un df -h verás que aparecen todas las particiones que has creado, y si ejecutas el comando free -h aparecerá una cantidad de swap equivalente al tamaño de la partición que creaste en el punto 4. No olvides terminar la instancia auxiliar si ya no la vas a utilizar para nada más.

¡Qué disfrutes de tu nuevo sistema, que ahora es más seguro y está mejor preparado para hacer frente a cambios que se puedan presentar en el futuro!