Discos y grupos de instancias administrados

Se paga la capacidad aprovisionada desde que se crea el disco hasta que se borra, aunque esté conectado a una VM detenida o a ninguna. En Hyperdisk y PD Extreme también se paga el rendimiento aprovisionado.

Cómo elegir el disco

Google Cloud Hyperdisk

El disco duradero más rápido de Compute Engine, basado en la tecnología Titanium. Admite compartir un volumen entre VM, Storage Pools para comprar capacidad y rendimiento en bloque, protección contra escrituras incompletas y Asynchronous Replication a otra región.

Persistent Disk zonal

Disco de red cuyos datos se reparten entre varios discos físicos. Úsalo cuando tu serie no admita Hyperdisk.

Persistent Disk regional y alta disponibilidad

El Persistent Disk regional y Hyperdisk Balanced High Availability replican los datos de forma síncrona entre dos zonas de la misma región y aguantan la caída de una zona. Si la zona principal falla, se fuerza la conexión (force attach) del disco a una VM de reserva en la otra zona, en segundos.

• La aplicación, el sistema de archivos y el SO deben tolerar caídas abruptas.
• Se ahorra arrancando la VM secundaria solo cuando hace falta la conmutación.
• Durabilidad: el PD regional tiene el doble de réplicas que el zonal. Ni los discos regionales ni los snapshots protegen por sí solos contra la corrupción de datos de la aplicación.

Local SSD

• Cada disco Local SSD da 375 GiB en las series que usan ese tamaño.
• No se replica: los datos pueden perderse si la VM se detiene o termina por cualquier motivo.
• Se conservan en ciertos casos: VM que se reinician en el mismo host tras un mantenimiento, o si eliges conservarlos al detener o suspender la VM (vista previa).
• Tras un error del host, Compute Engine intenta recuperar los datos durante el tiempo configurado; si no lo consigue, se pierden.
• Para conservar los datos, cópialos a un Persistent Disk o Hyperdisk.
• Con Spot VMs, los Local SSD también tienen precio Spot.

Plantillas de instancia

Guardan la configuración de una VM: tipo de máquina, imagen del disco de arranque, labels, script de inicio y otras propiedades. Sirven para crear VM sueltas, reservas y, obligatoriamente, grupos de instancias administrados.

• No se pueden modificar después de crearlas: se crea una nueva a partir de una VM o de otra plantilla.
• Si incluyen un recurso zonal (por ejemplo, un disco de solo lectura de us-central1-a), solo valen en esa zona.
• Las plantillas deterministas fijan versiones concretas del software que instala el script de inicio para que todas las VM sean idénticas.

gcloud compute instance-templates create web-tpl-v1 \
  --instance-template-region=us-central1 --machine-type=e2-medium \
  --image-family=debian-13 --image-project=debian-cloud \
  --metadata-from-file=startup-script=startup.sh

Un MIG ejecuta varias VM idénticas creadas desde una plantilla, con autoescalado, autoreparación, despliegue en varias zonas y actualizaciones automáticas. Los grupos no administrados solo sirven para balancear carga entre VM que gestionas tú; no admiten autoescalado.

• Si una VM se detiene, falla, es interrumpida (Spot) o la borra alguien ajeno al MIG, el MIG la vuelve a crear con el mismo nombre y plantilla.
• Los MIG con estado conservan el nombre, los discos y los metadatos de cada VM al recrearla: sirven para bases de datos o aplicaciones heredadas.
• Se integran con los balanceadores de carga como backend.

gcloud compute instance-groups managed create web-mig \
  --region=us-central1 --size=3 --template=web-tpl-v1 \
  --health-check=web-hc --initial-delay=120

Autoescalado

El autoescalador añade VM cuando sube la carga y las elimina cuando baja, según la política del grupo. Usa el agente de servicio de Compute Engine, que se crea al habilitar la API. Solo funciona con MIG.

• Con varias señales, el grupo toma el mayor de los tamaños recomendados.
• Con CPU, capacidad del balanceador o métricas por instancia no puede bajar a cero. Con otras métricas o programaciones sí, si el mínimo es 0.
• Periodo de inicialización (antes cool down): por defecto 60 s; durante ese tiempo no se usan los datos de la VM nueva para escalar hacia fuera.
• Periodo de estabilización: por defecto 10 minutos (0 a 3600 s); evita eliminar VM demasiado pronto tras un pico.
• Autoescalado predictivo: prevé la carga con el histórico y escala antes. Útil si la app tarda más de 2 minutos en arrancar y la carga sigue ciclos diarios o semanales.
• Scale-in controls: limitan cuántas VM se pueden quitar en una ventana de tiempo.

gcloud compute instance-groups managed set-autoscaling web-mig \
  --region=us-central1 --min-num-replicas=2 --max-num-replicas=20 \
  --target-cpu-utilization=0.60 --cool-down-period=90 --stabilization-period=240

Autoreparación y health checks

La autoreparación basada en la aplicación usa un health check que comprueba que la app responde en cada VM; si no responde, el MIG recrea la VM. Es más preciso que comprobar solo que la VM está en marcha.

• El retraso inicial (initial delay) es el tiempo que tarda una VM nueva en arrancar y ejecutar su script; durante él, el MIG ignora los health checks fallidos.
• Hay que permitir en el firewall el tráfico de los health checks desde 130.211.0.0/22 y 35.191.0.0/16.

Actualizar un MIG

Escenarios de examen

Trampas frecuentes del examen