Lab práctico · Semana 9: Fiabilidad y operaciones — Well-Architected, alta disponibilidad, DR, SRE y observabilidad

Backup y recuperación ante desastres de una VM

Qué vas a construir

Protegerás una VM con tres mecanismos y ejecutarás un simulacro de DR midiendo el RTO real:

1. Una programación de snapshots (snapshot schedule) asociada al disco, como harías en producción.
2. Un snapshot manual con el que restaurarás el disco en otra región (Bélgica) y levantarás allí una VM nueva.
3. Una machine image, con la que clonarás la VM completa en otra zona.

flowchart LR
  VM["vm-origen (europe-southwest1-a)"] -->|"snapshot schedule diario"| SS["Snapshots automáticos"]
  VM -->|"snapshot manual"| SN["Snapshot (almacenamiento multirregional)"]
  SN -->|"disco + VM nuevos"| DR["vm-dr (europe-west1-b)"]
  VM -->|"machine image"| MI["Machine image"]
  MI -->|"VM nueva"| CL["vm-clon (europe-southwest1-b)"]

Antes de empezar

• Proyecto dedicado (por ejemplo pca-lab-19) con facturación.
• En Cloud Shell:

export PROJECT_ID=$(gcloud config get-value project)
export REGION=europe-southwest1
export ZONE=europe-southwest1-a
export ZONE_B=europe-southwest1-b
export DR_REGION=europe-west1
export DR_ZONE=europe-west1-b
gcloud services enable compute.googleapis.com

Coste orientativo: dos o tres VMs e2-micro durante una hora y unos pocos GB de snapshots y machine image durante el lab (céntimos). El coste real está en olvidar borrar los snapshots y la machine image: la limpieza es obligatoria.

Paso 1: crea la VM de origen con datos

Creamos una VM pequeña con un script de arranque que escribe un fichero con la fecha. Ese fichero es nuestro «dato de negocio»: al restaurar comprobaremos hasta qué momento se conservó (el RPO).

gcloud compute instances create vm-origen \
  --zone=$ZONE --machine-type=e2-micro \
  --image-family=debian-12 --image-project=debian-cloud \
  --metadata=startup-script='#!/bin/bash
mkdir -p /datos
date -u +"%Y-%m-%dT%H:%M:%SZ arranque" >> /datos/pedidos.log'

Añade un par de «pedidos» por SSH (la primera vez te pedirá crear una clave SSH; acepta los valores por defecto):

gcloud compute ssh vm-origen --zone=$ZONE --command='for i in 1 2 3; do date -u +"%H:%M:%S pedido $i" | sudo tee -a /datos/pedidos.log; sleep 2; done; sync'

El sync fuerza a escribir a disco lo que está en caché. Recuerda la idea: un snapshot de un disco en uso es crash-consistent (como si hubieras quitado la corriente); para bases de datos se paran las escrituras o se usan snapshots coherentes con la aplicación.

Paso 2: programación de snapshots

Una snapshot schedule es una resource policy regional que crea snapshots automáticamente y borra los antiguos según la retención. Es la base de un patrón de DR «backup y restauración».

gcloud compute resource-policies create snapshot-schedule diario-7d \
  --region=$REGION \
  --daily-schedule --start-time=03:00 \
  --max-retention-days=7 \
  --on-source-disk-delete=keep-auto-snapshots \
  --storage-location=eu

gcloud compute disks add-resource-policies vm-origen \
  --resource-policies=diario-7d --zone=$ZONE

• --start-time está en UTC; el primer snapshot automático se hará esa noche, no ahora.
• --storage-location=eu guarda los snapshots en la multirregión de la UE: sobreviven a la pérdida de una región y cumplen residencia de datos en Europa.
• keep-auto-snapshots conserva los snapshots aunque se borre el disco (útil ante un borrado accidental).

Por consola: Compute Engine > Snapshots > Snapshot schedules > Create snapshot schedule, y después edita el disco para asociarla.

Paso 3: snapshot manual

Para el simulacro no esperamos a la noche: hacemos un snapshot ya. Apunta la hora: es tu punto de recuperación.

date -u
gcloud compute snapshots create snap-origen-1 \
  --source-disk=vm-origen --source-disk-zone=$ZONE \
  --storage-location=eu

Escribe un pedido después del snapshot. No debería aparecer en la restauración: es el dato que «pierdes» en un desastre (la ventana del RPO).

gcloud compute ssh vm-origen --zone=$ZONE --command='date -u +"%H:%M:%S pedido POSTERIOR al snapshot" | sudo tee -a /datos/pedidos.log; sync'

Paso 4: simulacro de DR en otra región (mide el RTO)

Supón que la región de Madrid no está disponible. Restauras en europe-west1 (Bélgica) a partir del snapshot. Mide el tiempo desde que «declaras el desastre» hasta que el dato es accesible.

INICIO=$(date +%s)

gcloud compute disks create disco-dr \
  --zone=$DR_ZONE --source-snapshot=snap-origen-1 --type=pd-balanced

gcloud compute instances create vm-dr \
  --zone=$DR_ZONE --machine-type=e2-micro \
  --disk=name=disco-dr,boot=yes,auto-delete=yes

gcloud compute ssh vm-dr --zone=$DR_ZONE --command='cat /datos/pedidos.log'

FIN=$(date +%s)
echo "RTO medido: $(( (FIN - INICIO) / 60 )) min $(( (FIN - INICIO) % 60 )) s"

Deberías ver los pedidos 1 a 3, pero no el «pedido POSTERIOR». Los snapshots son recursos globales: puedes usarlos en cualquier región sin copiarlos.

Paso 5: machine image y clon en otra zona

Una machine image guarda toda la VM: configuración (tipo de máquina, metadatos, etiquetas, cuenta de servicio) y todos sus discos. Sirve para clonar o para copias completas de una VM.

gcloud compute machine-images create mi-origen \
  --source-instance=vm-origen --source-instance-zone=$ZONE \
  --storage-location=eu

INICIO=$(date +%s)
gcloud compute instances create vm-clon \
  --zone=$ZONE_B --source-machine-image=mi-origen
gcloud compute ssh vm-clon --zone=$ZONE_B --command='cat /datos/pedidos.log'
FIN=$(date +%s)
echo "Tiempo de clonado: $(( FIN - INICIO )) s"

Esta vez sí aparece el «pedido POSTERIOR», porque la machine image se tomó después.

Comprueba que funciona

• gcloud compute resource-policies describe diario-7d --region=$REGION muestra la programación y gcloud compute disks describe vm-origen --zone=$ZONE --format="value(resourcePolicies)" la tiene asociada.
• vm-dr en europe-west1-b muestra los datos hasta el snapshot (RPO = tiempo entre el snapshot y el desastre).
• vm-clon en europe-southwest1-b es una copia completa de la VM.
• Tienes anotado tu RTO medido.

Limpieza

Borra en este orden (las VMs primero; sus discos se borran con ellas):

gcloud compute instances delete vm-dr --zone=$DR_ZONE --quiet
gcloud compute instances delete vm-clon --zone=$ZONE_B --quiet
gcloud compute disks remove-resource-policies vm-origen --resource-policies=diario-7d --zone=$ZONE
gcloud compute instances delete vm-origen --zone=$ZONE --quiet
gcloud compute resource-policies delete diario-7d --region=$REGION --quiet
gcloud compute machine-images delete mi-origen --quiet
gcloud compute snapshots delete snap-origen-1 --quiet
# Por si la programación llegó a crear snapshots automáticos:
gcloud compute snapshots list --format="value(name)"

Si el último comando lista snapshots, bórralos con gcloud compute snapshots delete NOMBRE. O borra el proyecto completo.

Preguntas para pensar como arquitecto