La lliçó anterior va acabar amb una pregunta incòmoda: si el grup d'Auto Scaling crea i destrueix instàncies de la botiga de MercadoFresco segons el trànsit del divendres, on viuen les dades? Les fotos de producte que avui són a /var/www/fotos del servidor de l'oficina no poden viure dins d'un disc que desapareix quan l'ASG decideix que sobra una màquina.

Aquesta lliçó respon a aquesta pregunta des de dos angles complementaris. Amazon EBS (Elastic Block Store) dona a cada instància discs que sobreviuen a la màquina, s'amplien en calent i es copien sols. Amazon EFS (Elastic File System) dona a diverses instàncies alhora un sistema de fitxers compartit, que és exactament el que l'Auto Scaling necessita perquè les quatre màquines del divendres vegin les mateixes fotos.

I pel camí tanquem el problema 2 de MercadoFresco: les còpies de seguretat no fiables. El disc dur extern que la Marta connecta "quan se'n recorda" se substitueix per instantànies incrementals automatitzades amb Data Lifecycle Manager, amb retenció definida i còpia a una altra regió.

1. Els tres models d'emmagatzematge: blocs, fitxers i objectes
2. Què és un volum EBS i què garanteix
3. Tipus de volum EBS i com triar
4. Dimensionar gp3: IOPS i rendiment independents de la mida
5. Crear, adjuntar, formatar i muntar un volum
6. Ampliar un volum en calent, sense aturar la botiga
7. Instantànies: què són, com es cobren i com es restauren
8. Data Lifecycle Manager: la fi del problema 2
9. Xifratge de volums
10. Instance store: ràpid, local i efímer
11. Amazon EFS: un sistema de fitxers per a diverses instàncies
12. Muntar EFS a les instàncies de la botiga
13. Taula final: EBS, EFS, instance store i S3

Abans de tocar cap servei cal tenir clara una distinció que ordena tot el capítol de l'emmagatzematge al núvol. No són tres productes que competeixen: són tres models diferents de desar dades, i cadascun resol un problema diferent.

La regla mental que convé fixar:

• Blocs: quan el programari espera un disc. Un sistema operatiu, PostgreSQL, un motor de base de dades. Res d'això sap parlar HTTP.
• Fitxers: quan diversos servidors han de compartir els mateixos fitxers i el programari espera rutes del sistema de fitxers (/var/www/fotos). És la via de mínima modificació quan migres una aplicació heretada.
• Objectes: quan la dada és un fitxer complet que s'escriu una vegada i es llegeix moltes. És el més barat, el més durador i el més escalable, però exigeix que l'aplicació faci servir la seva API.

Per a MercadoFresco, les fotos de producte podrien anar a EFS (sense tocar el codi) o a S3 (canviant el codi, més barat i millor a llarg termini). Veurem EFS aquí i S3 a la lliçó 02-03, on quedarà clar per què aquesta és la decisió definitiva.

Un volum EBS és un disc virtual que es connecta per xarxa a una instància EC2, però que el sistema operatiu veu exactament com un disc local: apareix a lsblk, es formata amb mkfs i es munta amb mount.

Les seves propietats essencials:

• És independent de la instància. Si termines la instància, el volum pot sobreviure (depèn de l'atribut DeleteOnTermination). El pots desconnectar i connectar a una altra màquina.
• Viu en una sola zona de disponibilitat. Un volum d'eu-west-1a no es pot connectar a una instància d'eu-west-1b. Per moure'l cal fer una instantània i restaurar-la a l'altra AZ.
• Està replicat dins de la seva AZ. AWS en manté diverses còpies en servidors diferents: una fallada de disc físic no t'afecta. Però una fallada de l'AZ sencera, sí. Per això les instantànies importen.
• Es paga per GB provisionat, no per GB fet servir. Un volum de 500 GiB amb 3 GiB de dades costa com 500 GiB. Aquesta és una de les despeses ocultes més habituals.
• Es pot ampliar en calent, però no reduir. Dimensiona amb cap.

Fixa't en el detall important del diagrama: mercadofresco-tienda-02 no pot connectar-se al volum de fotos de l'altra AZ. Aquest límit és precisament el que empeny cap a EFS o S3.

N'hi ha dues categories: SSD, optimitzats per a operacions per segon (IOPS) i accés aleatori, i HDD, optimitzats per a rendiment seqüencial (MB/s) i cost per GB.

Els preus són orientatius i canvien; consulta'ls sempre a la calculadora d'AWS. El que no canvia és l'ordre de magnitud entre ells.

Quatre criteris de decisió:

1. Comença sempre per gp3. És més barat que gp2 en un ~20 % i dona 3.000 IOPS de base encara que el volum sigui d'1 GiB.
2. Puja a io2 només si has mesurat que necessites més de 16.000 IOPS o si el negoci exigeix la durabilitat de cinc nous. És car.
3. HDD (st1/sc1) només per a accés seqüencial. Si la càrrega fa moltes lectures petites i aleatòries, un HDD donarà un rendiment pèssim encara que el preu per GB sigui temptador.
4. Els HDD no poden ser volums d'arrencada. El disc arrel sempre és SSD.

Migrar de gp2 a gp3 és gratis, en calent i estalvia diners. Si heretes un compte amb volums gp2, aquest és l'estalvi més fàcil que existeix:

Aquí hi ha la millora conceptual de gp3 respecte a gp2, i val la pena aturar-s'hi perquè explica moltes decisions d'arquitectura.

Amb gp2, el rendiment estava lligat a la mida: 3 IOPS per GiB. Si volies 3.000 IOPS, havies de provisionar 1.000 GiB, encara que només en fessis servir 40. Es comprava espai per comprar velocitat.

Amb gp3, els tres paràmetres es contracten per separat:

Comparació per al cas de MercadoFresco, que necessita 100 GiB i 3.000 IOPS:

Un factor 12 de diferència per conèixer el tipus correcte de volum. I si més endavant la base de dades necessités 6.000 IOPS, s'afegeixen sense tocar la mida:

Un límit pràctic que cal conèixer: la instància també té un sostre. Un t3.micro no podrà aprofitar 16.000 IOPS per molt que les contractis, perquè la seva amplada de banda cap a EBS està limitada. Per a càrregues de disc intensives es fan servir instàncies "optimitzades per a EBS" de mida suficient. Serveix de poc un volum rapidíssim penjat d'una instància diminuta.

Donarem a mercadofresco-tienda-01 un disc dedicat de 20 GiB per a les fotos de producte, separat del disc de sistema. Separar dades de sistema és una bona pràctica: pots reinstal·lar la màquina sense tocar les dades, i fer instantànies només del que importa.

• --encrypted activa el xifratge en repòs amb la clau gestionada per AWS. Costa el mateix que sense xifrar i no es pot afegir després, així que es posa sempre des del principi.
• El Componente és catalogo, perquè són les fotos de producte, no la botiga en si. L'esquema d'etiquetatge permet després imputar el cost a l'equip correcte.

Un detall que despista: demanes /dev/sdf però Amazon Linux amb nucli modern i NVMe el mostrarà com a /dev/nvme1n1. El nom que demanes és una etiqueta; el que veus a dins depèn del sistema. Per això mai no es munta per nom de dispositiu a /etc/fstab, sinó per UUID.

Sense aquest pas, el muntatge es perd al següent reinici i la botiga arrenca amb el directori de fotos buit.

L'opció nofail no és decorativa. Sense ella, si el volum no està disponible en arrencar, la instància es queda bloquejada a l'arrencada i no hi podràs entrar ni per SSH. És una de les formes més freqüents de "perdre" una instància a EC2. Executa sempre sudo mount -a abans de reiniciar per comprovar que la línia de fstab és correcta.

Al novembre, amb la campanya de Nadal, les fotos del catàleg omplen els 20 GiB. Ampliar és una operació en dues meitats: primer el volum a AWS, després el sistema de fitxers dins de la instància. Si només fas la primera, df -h continuarà mostrant 20 GiB i pensaràs que no ha funcionat.

Restriccions importants:

• No es pot reduir un volum. L'única via és crear-ne un de més petit, copiar-hi les dades i eliminar el gran.
• Entre dues modificacions del mateix volum han de passar almenys 6 hores.
• L'ampliació és transparent per a l'aplicació: no cal aturar nginx ni desmuntar.

Una instantània (snapshot) és una còpia puntual d'un volum desada a Amazon S3 (en un espai gestionat per AWS, no en un bucket teu). És la base de les còpies de seguretat a EC2 i la resposta al problema 2 de MercadoFresco.

Tres propietats que cal entendre bé, perquè gairebé tothom les malinterpreta:

1. Són incrementals, però cadascuna és completa. La primera instantània copia tots els blocs fets servir. La segona copia només els blocs que han canviat des de la primera. Tanmateix, restaurar la segona retorna el volum sencer, no un diferencial. AWS gestiona les referències internament.
2. Esborrar una instantània intermèdia és segur. Si esborres la instantània 2, AWS conserva els blocs que la instantània 3 encara necessita. Mai no es corromp una cadena per esborrar-ne una baula.
3. Es cobren per GB de dades úniques emmagatzemades (≈0,05 USD/GB-mes), no per la mida del volum. Un volum de 50 GiB amb 8 GiB de dades que gairebé no canvien genera instantànies molt barates.

Coherència de les dades. Una instantània captura el que hi ha al disc, no el que l'aplicació té a la memòria. Per a fitxers estàtics com les fotos n'hi ha prou. Per a una base de dades cal congelar el sistema de fitxers o, molt millor, fer servir les còpies natives del motor —que és exactament el que fa RDS i veurem a la lliçó 02-04.

Una instantània no es restaura sobre el volum original: crea un volum nou. Aquest és el mecanisme que permet moure dades entre zones de disponibilitat, cosa que un volum EBS no pot fer per si sol.

Copiar instantànies entre regions té cost de transferència de dades i d'emmagatzematge a destinació, però és la protecció real contra la fallada d'una regió sencera.

Fins ara les còpies de MercadoFresco eren "la Marta connecta el disc extern quan se'n recorda": sense calendari, sense verificació i sense còpia fora de l'oficina. Això és el problema 2. Una instantània manual com l'anterior no ho arregla, perquè també depèn que algú se'n recordi.

Amazon Data Lifecycle Manager (DLM) executa instantànies segons una política: a quins recursos s'aplica (seleccionats per etiquetes), amb quina freqüència, quantes se'n conserven i on es copien. Aquí es veu per què l'esquema d'etiquetatge de MercadoFresco no era burocràcia: és el mecanisme de selecció de la política.

Primer, el rol que DLM necessita per actuar en nom teu (IAM es detalla a 04-01):

I la política, desada a politica-dlm.json:

Què fa exactament aquesta política, línia a línia:

• TargetTags: s'aplica a tots els volums etiquetats Proyecto=mercadofresco. Qualsevol volum nou que el Luis creï amb l'etiqueta correcta entra automàticament al pla de còpies, sense que ningú se n'hagi de recordar. Aquest és el canvi cultural.
• Programació diària: cron(0 2 * * ? *) = tots els dies a les 02:00 UTC. Conserva les últimes 7; en crear la vuitena, esborra la més antiga, així que el cost s'estabilitza.
• Programació setmanal: diumenges a les 03:00 UTC, en conserva 4 i copia cadascuna a eu-central-1 xifrada. Un mes d'història fora de la regió principal.
• CopyTags: true: les instantànies hereten les etiquetes del volum, amb la qual cosa el cost de les còpies també queda imputat al seu CentroCoste.

Amb això, el problema 2 queda resolt en la seva part de disc:

Falta un matís honest: una còpia no provada no és una còpia. La Marta apunta al calendari una prova de restauració trimestral: crear un volum des de l'última instantània, muntar-lo en una instància de proves i verificar que les fotos hi són. La part de la base de dades d'aquest problema es tancarà a la lliçó 02-04, amb les còpies automàtiques i el PITR d'RDS.

El xifratge d'EBS és transparent: es xifren les dades en repòs, les dades en trànsit entre la instància i el volum, i totes les instantànies derivades. No cal canviar res a l'aplicació i l'impacte en rendiment és menyspreable.

Punts pràctics:

• No es pot xifrar un volum existent. El procediment és: instantània → còpia de la instantània amb --encrypted → crear un volum nou des d'aquesta còpia → intercanviar.
• Es pot activar el xifratge per defecte a la regió, i és molt recomanable:

A partir d'aquí, tot volum nou a eu-west-1 neix xifrat encara que ningú no ho demani.

• Les claus les gestiona AWS KMS. Pots fer servir la clau gestionada per AWS (aws/ebs, gratis) o una clau pròpia que et doni control de la rotació i de qui pot desxifrar. KMS és la lliçó 04-02; de moment n'hi ha prou de saber que el xifratge s'activa amb una casella.

Algunes famílies d'instàncies (les que porten d al nom, com m6id.large, i les famílies i i d) inclouen discs NVMe físicament connectats al servidor amfitrió. És l'instance store.

És efímer per disseny: en aturar la instància, AWS la mourà a un altre host físic en arrencar-la, i aquest host té altres discs. Un reinici (reboot) sí que conserva les dades, perquè no canvia de host; un stop/start, no.

Usos legítims: memòries cau, fitxers temporals, dades intermèdies d'un procés de càlcul, scratch de compilació. Per a MercadoFresco avui no aplica, però convé reconèixer-lo per no triar per error una instància d pensant que el disc inclòs és un estalvi.

Tornem al problema que va obrir la lliçó. El grup d'Auto Scaling aixeca 4 instàncies el divendres. Cadascuna té el seu volum EBS. Si el Luis puja una foto de producte nova a la instància 1, les altres tres no la veuen. I cap instància d'eu-west-1b no pot ni tan sols connectar-se al volum de fotos que viu a eu-west-1a.

Amazon EFS resol exactament això: un sistema de fitxers NFS v4.1 gestionat que es munta simultàniament en milers d'instàncies, en diverses AZ, i que creix i decreix sol.

Les seves característiques diferencials:

• Elàstic de veritat: no es provisiona mida. Pagues pels GB que realment deses (≈0,30 USD/GB-mes a Standard, unes 3,4 vegades més car que EBS gp3).
• Regional: s'hi accedeix des de qualsevol AZ de la regió mitjançant "objectius de muntatge" (mount targets), un per subxarxa.
• Compartit: lectura i escriptura concurrent des de totes les instàncies muntades.
• Semàntica POSIX: permisos, propietaris, enllaços. Per a l'aplicació és un directori normal.

La gestió del cicle de vida és automàtica: es configura "mou a IA el que porti 30 dies sense tocar-se" i EFS ho fa sol. Per al catàleg de MercadoFresco encaixa perfectament, perquè les fotos dels productes de temporada deixen de consultar-se fora de la seva època.

A la pràctica: General Purpose + Elastic llevat que mesuris que no t'arriba.

El grup de seguretat sg-efs-mercadofresco ha de permetre el port 2049 (NFS) des del grup de seguretat de les instàncies de la botiga. És la fallada número u en muntar EFS i s'explica a fons a la lliçó 03-02.

Dins de la instància:

Aquesta mida de "8.0E" (8 exabytes) és la manera que té NFS de dir "il·limitat": no hi ha mida que provisionar.

La línia corresponent aniria al user data de la plantilla de llançament que vam crear a 02-01, perquè cada instància nova de l'ASG munti les fotos automàticament en arrencar. Amb això, el diagrama del principi deixa de tenir el problema:

Avís de cost i honestedat tècnica. EFS resol el problema sense tocar el codi de MercadoFresco, i per això és la resposta correcta quan migres una aplicació heretada amb pressa. Però per servir fotos de producte a navegadors és car (≈3,4× EBS, ≈13× S3 Standard), continua consumint CPU i amplada de banda de les instàncies, i no aprofita cap xarxa de distribució. A la lliçó 02-03 mourem /var/www/fotos a S3, que és la decisió definitiva de MercadoFresco, i a 03-04 hi posarem CloudFront al davant.

• Crear el volum en una AZ diferent de la de la instància. L'attach-volume fallarà. Consulta sempre Placement.AvailabilityZone de la instància abans de crear el disc.
• Oblidar /etc/fstab i descobrir després d'un reinici que la botiga serveix un directori buit. I a l'inrevés: posar una línia malament a fstab sense nofail i deixar la instància sense arrencar. Executa sudo mount -a abans de cada reinici.
• Ampliar el volum a AWS i no estendre el sistema de fitxers. df -h no canvia i sembla que l'ampliació no ha funcionat. Falten growpart i/o xfs_growfs/resize2fs.
• Creure que es pot reduir un volum. No es pot. Provisiona amb criteri i amplia quan calgui.
• Volums orfes. En terminar instàncies queden volums en estat available que es continuen pagant i que ningú no mira. Revisa-ho cada mes:

  aws ec2 describe-volumes --filters Name=status,Values=available \\
    --query 'Volumes[].{ID:VolumeId,GB:Size,Creat:CreateTime}' --output table \\
    --profile mercadofresco-dev --region eu-west-1
  

• Instantànies que s'acumulen per sempre. Centenars d'instantànies manuals sense política de retenció són un degoteig constant a la factura. Per això tot ha de passar per DLM.
• Confiar en una còpia que no s'ha restaurat mai. Prova la restauració cada trimestre.
• Continuar fent servir gp2. Migrar a gp3 és gratis, en calent i més barat.
• Muntar EFS sense obrir el port 2049. El mount es queda penjat sense missatge clar. Revisa el grup de seguretat de l'EFS.
• Fer servir EFS per a tot per comoditat. És l'opció cara. Fes-lo servir quan necessitis semàntica POSIX compartida; per a fitxers que se serveixen per HTTP, S3.
• No xifrar des del principi. Costa el mateix i no es pot afegir després sense recrear el volum. Activa enable-ebs-encryption-by-default a la regió i oblida-te'n.

La base de dades de comandes de MercadoFresco necessita 200 GiB d'espai i, mesurat durant el pic dels divendres, 5.000 IOPS sostingudes amb un rendiment de 200 MB/s.

1. Quin tipus de volum triaries i amb quina configuració exacta?
2. Calcula el cost mensual aproximat amb els preus de la taula (0,088 USD/GB-mes, 0,006 USD per IOPS extra, 0,048 USD per MB/s extra).
3. Quant costaria el mateix amb gp2? I per què gp2 obligaria a més a una altra decisió?

La Marta vol una política de còpies que compleixi aquests requisits de negoci:

• Còpia cada 12 hores de tots els volums de producció, conservant 14 dies.
• Còpia mensual conservada 12 mesos i replicada a eu-central-1.
• Els volums de desenvolupament només necessiten còpia diària amb 3 dies de retenció.
• Les còpies han de poder imputar-se al centre de cost correcte a la factura.

Explica com estructuraries les polítiques de DLM i quines etiquetes fan possible cada selecció.

Per a cada situació de MercadoFresco, tria entre EBS, EFS, instance store o S3, i justifica-ho en dues frases:

• A) El disc d'arrencada de les instàncies de la botiga.
• B) Un directori /var/www/uploads on els clients pugen fotos d'incidències amb la seva comanda, i que les 4 instàncies de l'ASG han de veure per igual, sense poder tocar el codi PHP.
• C) Els fitxers temporals del procés nocturn que recomprimeix 40.000 fotos del catàleg.
• D) Les 40.000 fotos del catàleg servides als navegadors dels clients.

Solució 1.

1. gp3, 200 GiB, amb 5.000 IOPS i 200 MB/s provisionats. No cal io2: el límit de gp3 és 16.000 IOPS i 1.000 MB/s, molt per sobre del que es demana, i io2 és força més car. Un detall addicional: cal comprovar que la instància admet aquest rendiment cap a EBS (un t3.micro no; caldria un tipus optimitzat per a EBS de mida adequada).

2. Cost gp3:

   Emmagatzematge: 200 GB × 0,088          = 17,60 USD
   IOPS extra:     (5.000 − 3.000) × 0,006 = 12,00 USD
   Rendiment extra: (200 − 125) × 0,048    =  3,60 USD
   ------------------------------------------------------
   Total                                    ≈ 33,20 USD/mes
   

3. Amb gp2, el rendiment va lligat a la mida a raó de 3 IOPS/GiB, així que per a 5.000 IOPS caldrien 1.667 GiB:

   1.667 GB × 0,11 ≈ 183 USD/mes
   

   Més de 5 vegades el cost, i amb la decisió forçada de provisionar 1.667 GiB per fer-ne servir 200: pagues 1.467 GiB d'espai buit només per comprar velocitat. Aquest és l'argument definitiu per no fer servir gp2 en res nou.

Solució 2.

Es creen tres polítiques de DLM, totes seleccionant per etiquetes, que és el que fa que funcioni sense manteniment:

Claus del disseny:

• TargetTags amb dues etiquetes actua com un I lògic: només hi entren els volums que porten totes dues. Per això l'esquema d'etiquetatge obligatori del projecte és el que fa viable l'automatització: un volum nou ben etiquetat queda protegit sense que ningú hi intervingui.
• CopyTags: true propaga CentroCoste, Componente i Propietario a cada instantània, amb la qual cosa el cost de les còpies apareix correctament repartit a Cost Explorer (lliçó 11-03).
• La retenció s'expressa en nombre d'instantànies, no en dies: cal traduir la freqüència. A 2 còpies diàries, 14 dies són 28 instantànies.
• Es poden agrupar les dues primeres en una sola política amb dos Schedules (DLM n'admet fins a quatre per política); separar-les és igual de vàlid i més llegible.

Solució 3.

Has après a distingir els tres models d'emmagatzematge —blocs, fitxers i objectes— i a reconèixer per la forma del problema quin toca en cada cas: si el programari espera un disc, blocs; si diversos servidors comparteixen fitxers amb rutes POSIX, fitxers; si la dada és un fitxer complet servit per HTTP, objectes.

D'EBS saps que un volum viu en una sola AZ, que es paga per GB provisionat i no fet servir, i que s'amplia però mai no es redueix. Saps triar entre gp3, gp2, io2, st1 i sc1, i has calculat amb números per què gp3 és l'opció per defecte: en desacoblar mida, IOPS i rendiment, evita l'absurd de gp2 de comprar 1.667 GiB per aconseguir 5.000 IOPS. Has recorregut el cicle complet d'un disc de dades: create-volume, attach-volume, lsblk, mkfs, mount, la línia d'/etc/fstab per UUID i amb nofail, i l'ampliació en calent en les seves dues meitats, modify-volume a AWS i xfs_growfs dins de la màquina.

Has entès les instantànies de veritat: incrementals en el cobrament però completes en la restauració, segures d'esborrar en qualsevol punt de la cadena, capaces de moure dades entre AZ i entre regions. I amb Data Lifecycle Manager has convertit aquesta capacitat en un pla de còpies que s'executa sol, selecciona per etiquetes i reté el just: set diàries, quatre setmanals replicades a eu-central-1. Amb això, la part de disc del problema 2 de MercadoFresco —les còpies que depenien que algú se'n recordés— està tancada, amb l'advertiment que una còpia sense prova de restauració no compta com a còpia.

Coneixes a més el xifratge transparent d'EBS i per què s'activa per defecte a la regió, i saps què és l'instance store i per què la seva velocitat no compensa la seva volatilitat llevat que sigui per a dades prescindibles. Finalment, EFS t'ha donat la primera solució real al problema que va deixar obert l'Auto Scaling: un sistema de fitxers NFS regional, elàstic i muntat alhora a les quatre instàncies del divendres, amb les seves classes d'emmagatzematge i els seus modes de rendiment.

Però tanquem amb una decisió pendent i deliberada. EFS resol el problema de les fotos sense tocar el codi, i per això és la resposta correcta amb pressa. No és la resposta correcta a llarg termini: és unes tretze vegades més car que l'alternativa, obliga que el trànsit d'imatges passi per les instàncies i no aprofita l'escala global d'AWS. A la lliçó 02-03, «Amazon S3», migrarem de veritat /var/www/fotos amb aws s3 sync, coneixerem els onze nous de durabilitat, les classes d'emmagatzematge amb regles de cicle de vida que abarateixen les fotos antigues del catàleg, el versionat que protegeix dels esborrats accidentals, les URL signades prèviament amb què la Sara descarregarà els seus informes sense credencials, i els esdeveniments que més endavant dispararan una funció Lambda per generar les miniatures.