El caso
El proyecto estaba listo. Solo faltaba elegir el servidor.
Con los proyectos organizados, Isaac abrió la pantalla para crear la primera VM de la tienda y encontró decenas de tipos de máquina, varios tipos de disco y una lista de sistemas operativos.
Elegir demasiado grande era un desperdicio. Elegir demasiado pequeño tiraría la tienda abajo en el Black Friday.
Este post parte de Máquinas virtuales, de Modelos de servicio en la nube y de Google Cloud.
El problema
Una VM a medida
Cada carga de trabajo pide una combinación distinta de procesador, memoria, disco y red. Una VM con recursos de más desperdicia dinero, y una con recursos de menos se atasca en el pico.
Y una sola VM es un punto único de falla: si se cae, la tienda se cae con ella.
La solución
Compute Engine
Compute Engine es el servicio de VM de Google Cloud. Es IaaS, como vimos en Modelos de servicio en la nube: Google se encarga del hardware y de la virtualización, y tú te encargas del sistema operativo hacia arriba. Las VMs viven en un proyecto, en una zona de una región, conectadas a una red VPC.
Al crear una VM, eliges cuatro cosas:
Zona (zone)
Dónde corre la VM, dentro de una región. Cerca de los clientes, para reducir la latencia.
En la tienda: São Paulo, southamerica-east1.
Tipo de máquina (machine type)
Cuántos procesadores (vCPU) y cuánta memoria tiene la VM.
En la tienda: suficiente para el pico, sin que sobre mucho.
Imagen (image)
El sistema operativo y el software de partida de la VM, como una versión de Linux o de Windows.
En la tienda: una imagen de Linux con el sistema de pedidos instalado.
Disco (disk)
Donde viven el sistema operativo y los datos. Hay varios tipos, que veremos a continuación.
En la tienda: un disco que sobrevive si la VM se borra.
La facturación es por segundo, con un mínimo de un minuto. Si la VM se apaga, dejas de pagar por el procesador y la memoria, pero el disco sigue cobrando.
Una función propia de Google es la migración en vivo (live migration): cuando Google hace mantenimiento en el servidor físico, la VM en ejecución se mueve a otro sin reiniciarse.
Tipos de máquina
Familias de máquinas
Los tipos de máquina se agrupan en familias, cada una pensada para un perfil de carga:
| Familia | Para qué sirve | En la tienda |
|---|---|---|
| Uso general (general-purpose) | Equilibrio entre procesador y memoria, el punto de partida para la mayoría de las cargas | El sitio y el sistema de pedidos |
| Optimizada para cómputo (compute-optimized) | El mayor rendimiento por núcleo, para cálculo pesado | El cálculo de flete por lotes |
| Optimizada para memoria (memory-optimized) | Mucha memoria por núcleo, para datos que caben en la RAM | Una base de datos en memoria |
| Optimizada para almacenamiento (storage-optimized) | Mucho disco local, con lectura y escritura rápidas | Una base con muchas escrituras |
| Optimizada para aceleradores (accelerator-optimized) | GPU y otros aceleradores, para aprendizaje automático | Recomendación de productos |
En algunas series, en lugar de un tamaño prefabricado, armas un tipo de máquina personalizado: eliges la cantidad de vCPU y de memoria que necesita la carga, y pagas solo por eso.
Datos
Discos e imágenes
La VM parte de una imagen: una plantilla con el sistema operativo. Google ofrece imágenes públicas, y puedes crear imágenes personalizadas con tu software ya instalado, para crear VMs idénticas en minutos.
Los datos viven en discos, como el almacenamiento en bloque que vimos antes. Compute Engine tiene tres opciones:
- Persistent Disk: disco en red, replicado y duradero. Es el disco clásico de las VMs, muy usado como disco de arranque.
- Hyperdisk: disco en red, también duradero, con más rendimiento y tamaño, y con velocidad ajustable.
- Local SSD: disco conectado físicamente al servidor. Es el más rápido, pero los datos se pierden si la VM se detiene.
Una copia del disco en un momento dado es un snapshot, la forma de hacer una copia de seguridad.
No confundas
Disco persistente × Local SSD
Persistent Disk e Hyperdisk
“¿Los datos necesitan sobrevivir a la VM?”
- Ejemplo
- La base de datos de pedidos de la tienda.
- Foco
- Duradero: los datos siguen aunque la VM se detenga o se borre.
Local SSD
“¿Necesito la lectura y escritura más rápidas, y los datos son descartables?”
- Ejemplo
- Una caché temporal, que la tienda recrea cuando hace falta.
- Foco
- Muy rápido, pero pierde los datos cuando la VM se detiene.
Escala
Escala y disponibilidad
Para no depender de una sola VM, creas una plantilla de instancia (instance template), que guarda la receta de la VM: tipo de máquina, imagen y disco. Con ella formas un grupo administrado de instancias (MIG, de managed instance group), que cuida varias VMs idénticas como si fueran una sola.
El grupo ofrece:
- Autoscaling: agrega VMs cuando sube la demanda y las quita cuando baja. Es la elasticidad en la práctica.
- Autohealing: una verificación de estado revisa cada VM, y la que falla se recrea automáticamente.
- Distribución por zonas: un grupo regional reparte las VMs entre varias zonas, y la falla de una zona no tira todo abajo.
- Actualización automática (rolling update): reemplaza las VMs por una versión nueva de la plantilla, poco a poco.
Precio
Cómo pagar por la VM
Los modelos de precio de Costos en la nube tienen nombres propios en Compute Engine:
| Modelo | En Compute Engine | Cuándo usar |
|---|---|---|
| Bajo demanda (on-demand) | Precio estándar, cobrado por segundo | Carga impredecible |
| Uso sostenido (sustained use) | Descuento automático para VMs que permanecen encendidas buena parte del mes, en algunos tipos de máquina | Carga que corre mucho, sin planificarla |
| Compromiso de uso (committed use) | Committed Use Discounts, por 1 o 3 años | Carga constante y predecible |
| Capacidad ociosa (spot) | Spot VMs, con descuento de hasta cerca del 90%, que Google puede interrumpir | Carga que tolera interrupciones |
El descuento por uso sostenido es una característica destacada de Google Cloud: es automático, sin compromiso ni contrato.
Términos clave
Seis términos para recordar
Toca la tarjeta para ver la definición.
Prueba rápida
Tres preguntas, estilo examen
01
Una carga de trabajo necesita mucha memoria por núcleo, como una base de datos que mantiene sus datos en RAM. ¿Qué familia de máquina elegir?
02
Una VM de un grupo administrado falla en la verificación de estado. ¿Qué hace el grupo?
03
Los datos de una VM deben sobrevivir si se detiene o se borra. ¿Dónde guardarlos?
En el examen, Compute Engine es la respuesta cuando la carga necesita una VM con control sobre el sistema operativo. Lo que cambia de una pregunta a otra es el detalle: la familia según el perfil de carga, el disco según la durabilidad, el grupo administrado para crecer y recuperarse, y el modelo de precio según la previsibilidad. Para Isaac, el siguiente paso es ejecutar la tienda sin administrar VMs.