Crear i muntar un volum EBS addicional a EC2

Muntar un volum addicional en una instància EC2 sembla trivial quan ho fas per primera vegada. Clics a la consola, uns comandaments de mkfs, i tot funciona. El problema no està en el que cal fer per a què funcioni avui, sinó en el que cal fer per a què continuï funcionant després d’un reinici, un creixement de volum, una migració d’AZ o una rotació de personal.

1. Crear el volum: tria bé des del començament

A la pràctica, gairebé tots els problemes que he vist amb volums EBS venen de decisions poc meditades en crear-los. Tipus de volum, zona de disponibilitat, IOPS sense justificació, mida arbitrària o etiquetes mal posades.

Zona de disponibilitat.

Si el volum no és a la mateixa zona de disponibilitat que la teva instància, no podràs adjuntar-lo. AWS no t’ho impedeix, però sí que ho notes quan et preguntes per què no apareix com a adjuntable. Això passa força quan la creació del volum s’automatitza amb una AZ codificada sense validar.

Tipus de volum

No tots els tipus de volum es comporten igual. gp3 és una bona opció general si vols rendiment predictible sense pagar per IOPS que no necessites. gp2 encara està en molts scripts antics, però té una lògica de burst que complica diagnòstics quan la càrrega canvia. Si necessites rendiment sostingut, tria tu mateix els IOPS (encara que ho deixis en el mínim de 3.000).

Mida mínima

Si tries gp2, recorda que el rendiment base depèn de la mida: per sota d’1 TB vas acumulant crèdits d’IOPS (3 IOPS per GB). Això significa que un volum de 20 GB pot anar bé al principi i degradar-se sota càrrega prolongada sense que canviï res en el sistema operatiu. Evitable amb gp3.

Etiquetes útils

Etiqueta el volum en el moment de crear-lo. Inclou almenys: Environment, InstanceId, MountPurpose. Costa poc i estalvia temps quan has de fer neteja, auditories o simplement buscar “aquest volum de 500 GB que es muntava en staging i ningú recorda per a què era”.

2. Adjuntar el volum: el nom del dispositiu sí que importa

Quan adjuntes un volum EBS des de consola o API, pots triar el nom del dispositiu virtual, com /dev/sdf. El problema és que el sistema operatiu pot veure’l com /dev/xvdf, o fins i tot com /dev/nvme1n1 si la instància fa servir NVMe (que és el comú des de fa ja diverses generacions d’instàncies).

Errors típics:

• Assumir que /dev/sdf serà visible com a tal dins de la instància.
• Referenciar /dev/sdf en un fstab i que no es munta perquè aquest nom no existeix realment.
• Crear una AMI amb un volum addicional muntat i que falli en iniciar una altra instància perquè el dispositiu no apareix amb el mateix nom.

Com ho podem gestionar:

• Un cop adjuntat el volum, entrem a la instància i executem lsblk o nvme list. Això ens dona el nom real: /dev/nvme1n1, per exemple.
• Creem una etiqueta interna en el sistema fent servir e2label o xfs_admin -L segons el tipus de sistema d’arxius, per poder referenciar-lo després per UUID o label.
• Mai hem de referenciar dispositius directament per nom en /etc/fstab si podem evitar-ho. És preferible fer servir UUID = o LABEL =.

3. Formatejar el volum: amb cura i sense sobrescriure

El format és directe, però hi ha un detall que s’ignora quan anem amb pressa: de vegades el volum ja té dades o una capçalera de sistema d’arxius. Es poden perdre dades per un mkfs.ext4 sense verificació en volums que ja estaven muntats en una altra instància.

Validar abans de formatejar:

file -s /dev/nvme1n1

Et dirà si el volum està buit o si detecta un sistema d’arxius. Si veus alguna cosa com a “data”, probablement està net. Si veus “ext4 filesystem data”, més val que sàpigues d’on ve.

Formatejar (si s’escau):

mkfs.ext4 -L datavol /dev/nvme1n1

O amb XFS si saps que necessitaràs expansió online o rendiment més predictible amb fitxers grans:

mkfs.xfs -L datavol /dev/nvme1n1

4. Muntar el volum i preparar la persistència

Aquí ve una altra error habitual: muntar-lo manualment funciona, però després del següent reboot la instància no arrenca correctament perquè fstab té una entrada mal feta, o perquè el volum no està disponible encara quan s’intenta muntar.

Pas a pas:

mkdir -p /mnt/data
mount /dev/nvme1n1 /mnt/data

Confirma que funciona, després, l’UUID:

blkid /dev/nvme1n1

Ara edita /etc/fstab fent servir UUID=… o LABEL = datavol. Per exemple:

UUID=6c8a74d4-2c71-4f4b-9b60-44257b15c1d6 /mnt/data ext4 defaults,nofail 0 2

Detalls importants:

• Fes servir nofail si no vols que el sistema entri en mode d’emergència si el volum no hi és present en arrencar. Això és útil en entorns on els volums s’ adjunten dinàmicament.
• Si estàs fent servir xfs, el camp fs_passno al final de la línia (el 2) no es fa servir, però no el deixis en blanc.
• Sempre prova amb mount -a després de modificar fstab, no esperis al proper reinici.

5. Creixement del volum

Expandir un volum EBS no implica que el sistema d’ arxius el reconegui automàticament. AWS permet re-dimensionar volums en calent, però si no fas el resize dins del sistema, és com si no hagués passat res.

Després de re-dimensionar el volum:

1. Confirma que el SO veu la nova mida:

lsblk

• Expandeix la partició (si el sistema d’arxius està en una partició, i no directament sobre el dispositiu):

growpart /dev/nvme1n1 1

• Expandeix el sistema d’ arxius:
  • Per a ext4:

resize2fs /dev/nvme1n1p1

• Per a XFS:

xfs_growfs /mnt/data

Error freqüent:

En volums que no tenen particions (mkfs es va executar directament sobre /dev/nvme1n1), no necessites growpart. En aquests casos, el resize2fs o xfs_growfs directament funciona.

6. Volums persistents i automatització neta

Un cop tens muntat i funcionant el teu volum addicional, el següent que sovint passa és que algú crea una AMI o un snapshot, o automatitza una infraestructura amb Terraform o CloudFormation. Si no tens cura amb com deixes configurat el volum, comencen els errors silenciosos: instàncies noves que no munten, que arrenquen amb el volum incorrecte, o que no arrenquen en absolut.

Evitar referències fràgils

El pitjor error que es repeteix és assumir que el nom del dispositiu serà sempre el mateix. Com ja he comentat, si poses /dev/sdf en adjuntar, pots veure /dev/xvdf o /dev/nvme1n1 segons la instància. El consell és clar: no fer /dev/sdf a cap script intern del sistema. Ni al fstab, ni a les unit files de systemd, ni a comandes de backup.

Referència’l per UUID= o per LABEL=, que és més robust al canvi de maquinari virtual.

Automatització predictible amb cloud-init

Si treballes amb imatges base o llences moltes instàncies iguals, pots deixar muntat el volum automàticament amb un snippet de cloud-init. Exemple real:

#cloud-config
mounts:

 - [ "UUID=6c8a74d4-2c71-4f4b-9b60-44257b15c1d6", "/mnt/data", "auto", "defaults,nofail", "0", "2" ]

Això evita haver d’editar fstab manualment i és fàcilment versionable en infraestructura com a codi.

Recordatori útil: si estàs fent ser vir Terraform o similars, defineix l’etiqueta Name en els volums EBS si vols poder filtrar-los fàcilment a la consola d’AWS o en scripts de manteniment. Si els deixes sense nom, et trobaràs volums orfes sense context després de sis mesos.

7. Eliminació segura

Quan acabes amb un volum, no n’hi ha prou amb esborrar-lo. En entorns compartits o automatitzats, més d’una vegada m’he trobat amb volums no eliminats perquè es van crear amb l’opció “DeleteOnTermination: false” (la predeterminada quan els adjuntes manualment).

Verifica això en llançar instàncies si el volum és temporal o només útil per a la vida d’ aquesta instància. Pots fer-ho també per línia de comandaments:

aws ec2 modify-instance-attribute \
--instance-id i-xxxxxxxxxx \
  --block-device-mappings '[{"DeviceName":"/dev/sdf","Ebs":{"DeleteOnTermination":true}}]'

Si no automatitzes aquesta part, acabaràs pagant per volums orfes que ningú recorda per a què eren.

Snapshots abans d’esborrar

Encara que el volum ja no es necessiti, pot ser bona pràctica treure un snapshot abans d’eliminar-lo. Especialment si no estàs 100% segur que no hi hagi dades útils dins. Un snapshot costa menys que deixar un volum complet actiu, i es pot eliminar amb calma si després veus que realment no calia.

8. Alguns errors freqüents

Muntar el volum abans que estigui disponible

He vist scripts que corren mount /mnt/data just després de llançar la instància sense esperar que el volum estigui adjuntat. El resultat: l’ script falla, el sistema no arrenca correctament o el servei que depèn d’ aquest punt de muntatge es cau.

Solució: fes servir nofail en fstab, i si automatitzes amb scripts, espera que el dispositiu aparegui amb lsblk o udevadm settle.

Assignar la mateixa lletra de dispositiu a dos volums

Això passa més del que sembla a proves manuals. Adjunto un volum com a /dev/sdf, m’oblido de que ja hi ha un altre muntat amb aquest nom, i sobreescric sense voler.

Solució: revisar sempre lsblk abans d’adjuntar una cosa nova. I si és un entorn reproduïble, fixa els noms a Terraform o el que facis servir per a què no hi hagi ambigüitat.

Ignorar la relació entre mida i IOPS en gp2

Amb volums petits, com comentava abans, et pots quedar sense IOPS enmig d’una operació de base de dades, simplement perquè el volum no tenia prou crèdits. Això s’interpreta com “la instància està lenta”, quan en realitat el coll d’ampolla està a EBS.

Solució: fes servir gp3 i defineix IOPS des del començament si necessites rendiment constant.

Deixar el volum sense muntar després d’un reinici

Tot funciona perfecte… fins que algú reinicia la instància i l’aplicació no aixeca perquè el volum no s’ha muntat. Això passa quan es munta manualment, s’oblida afegir-ho a fstab, o es referencia malament el dispositiu.

Solució: fes un reinici de prova després de tota modificació estructural i valida que tot continua funcionant.

9. Recomanacions per al dia a dia

1. Fes una plantilla pròpia de fstab i revísala en revisions d’infraestructura. T’assegures que els muntatges estan ben fets i pensats.
2. Etiqueta-ho tot. No perquè AWS ho digui, sinó perquè després tu mateix agrairàs saber de què era cada cosa.
3. Automatitza la creació i muntatge si has de repetir més de dues vegades. I no barregis configuració manual amb automatització sense documentar-ho.
4. No facis servir noms de dispositius en els teus scripts interns. Fes servir UUID o label.
5. Fes créixer volums només si saps que el sistema d’arxius ho permet sense reiniciar. Ext4 i XFS ho permeten, però si hi ha particions, assegura’t que growpart funciona bé en aquesta versió de cloud-init.

Conclusió

Muntar un volum EBS no és complicat, però fer-ho bé, de manera que no doni problemes dintre de sis mesos quan un altre l’hereti o quan calgui escalar, és una altra història. La diferència entre un sistema net i un ple de trampes no està en els comandaments que es fan servir, sinó en com i quan es fan servir, i en tenir clar què pot fallar després. Qui ha hagut de muntar sistemes d’arxius a les tres del matí per un fstab mal configurat ho sap.