Manual de consola — Arquitectura elástica

Este manual construye el laboratorio completo desde la consola de OCI, haciendo clic. No usa Terraform ni la CLI para crear nada. Los pocos comandos que aparecen son verificaciones opcionales que complementan lo que se ve en pantalla.

El lector esperado es un ingeniero de infraestructura que conoce AWS o Azure y no conoce OCI. Cada pantalla que hay que tocar tiene su paso.

Todo lo que sigue se hace en un compartimento del laboratorio, desechable, sobre un tenancy de prueba. Nunca sobre un ambiente con datos.

---

1. Qué se construye y para qué

El laboratorio responde una pregunta concreta: ¿cuánto tarda realmente la plataforma en darme capacidad nueva cuando la carga sube, y cuánto en quitármela cuando baja?

La respuesta no se estima: se mide. Y el número medido —casi doce minutos hasta que la capacidad nueva atiende tráfico— es lo que permite decidir si una arquitectura elástica sirve para el patrón de carga que usted tiene, o si su pico llega y se va antes de que la elasticidad alcance a reaccionar.

De esa medición salen dos decisiones que el laboratorio ayuda a tomar:

1. Escalar horizontal contra escalar vertical. Redimensionar una máquina virtual cuesta una ventana de indisponibilidad. Agregar instancias a un grupo, no. Pero agregar instancias tarda, y ese retraso tiene que caber dentro de su tolerancia.
2. Cuánta capacidad base dejar encendida. Si el ciclo de escalamiento tarda doce minutos, el mínimo del grupo no se define por el promedio de carga: se define por lo que debe poder absorber sin ayuda durante esos doce minutos.

Los componentes

                          Internet
                             │
                    ┌────────▼─────────┐
                    │  Load balancer   │  flexible 10–100 Mbps
                    │  listener :80    │  health check GET /health
                    │  backend set     │  round robin · retries 3
                    └────────┬─────────┘
                             │
        ┌────────────────────┼────────────────────┐
        │                    │                    │
   ┌────▼────┐          ┌────▼────┐          ┌────▼────┐
   │  app-1  │          │  app-2  │   ...    │  app-N  │
   │ E4.Flex │          │ E4.Flex │          │ E4.Flex │
   │ 1 OCPU  │          │ 1 OCPU  │          │ 1 OCPU  │
   └────┬────┘          └────┬────┘          └────┬────┘
        │                    │                    │
        └────────────────────┴────────────────────┘
             Instance pool  ·  tamaño 2 → 6
             creado desde una Instance configuration
                             │
              métrica CpuUtilization (oci_computeagent)
                             │
                    ┌────────▼─────────┐
                    │   Autoscaling    │  CPU > 55 %  →  +2  (máx. 6)
                    │   configuration  │  CPU < 20 %  →  −1  (mín. 2)
                    └──────────────────┘  enfriamiento 300 s

   Red: VCN 10.30.0.0/16 · subred pública 10.30.1.0/24 · internet gateway
   FinOps: presupuesto mensual de 150 USD con avisos al 50 / 75 / 90 %
           y un aviso adicional por gasto proyectado

La aplicación que corre en cada instancia es un servidor HTTP escrito con la librería estándar de Python, sin dependencias externas. Expone tres rutas:

No descarga nada de internet al arrancar. Eso es deliberado: hace predecible el tiempo que tarda una instancia nueva en empezar a servir tráfico, que es justamente uno de los tramos que el laboratorio mide.

Lo que este laboratorio simplifica a propósito

La capa de aplicación está en una subred pública, con IP pública en cada instancia. En una arquitectura real va en subred privada, detrás del balanceador, y el acceso administrativo pasa por un bastión. Aquí se simplifica para que el laboratorio quepa en el tiempo disponible y para que el diagnóstico sea directo cuando algo falla.

Dígalo en voz alta antes de que alguien lo pregunte. Un laboratorio que esconde sus simplificaciones pierde credibilidad cuando lo notan; uno que las declara, la gana.

---

2. Equivalencias con otras nubes

Solo los servicios que aparecen en este manual.

Tres diferencias que sorprenden a quien viene de otra nube:

• El compartimento no es una etiqueta, es una frontera. Las políticas de acceso, los límites de servicio, el análisis de costo y el borrado masivo se apoyan en él. Crear el laboratorio en el compartimento raíz hace que todo eso sea más difícil después.
• Los presupuestos viven en el compartimento raíz, aunque apunten a un compartimento hijo. Si intenta crearlos parado en el compartimento del laboratorio, no los verá.
• El grupo de instancias y la política de escalamiento son dos recursos distintos. En AWS el Auto Scaling group lleva la política adentro. En OCI el instance pool solo mantiene un tamaño; quien cambia ese tamaño es una autoscaling configuration aparte, que se crea después y se puede desactivar sin tocar el grupo.

---

3. Prerrequisitos

3.1 Cuenta y permisos

3.2 Límites de servicio — el paso que más gente se salta

Este es, con diferencia, el motivo más común por el que un laboratorio sobre una cuenta de prueba no llega a la fecha. Los aumentos de límite no son inmediatos: se piden con días de anticipación.

Consola de OCIGovernance & Administration › Limits, Quotas and Usage

1. Abra Limits, Quotas and Usage.
2. En Service, elija Compute. Filtre por el ámbito de la región y busque el contador de cores del shape E4. Confirme que el límite no es 0 y que el disponible cubre los 6 cores.
3. Cambie Service a LBaaS y confirme el cupo de balanceadores flexibles.
4. Cambie Service a Block Volume y confirme los GB disponibles.
5. Si algún límite aparece en 0, use Request a service limit increase el mismo día. No continúe asumiendo que se aprobará a tiempo.

3.3 Compartimento del laboratorio

Consola de OCIIdentity & Security › Compartments › Create Compartment

1. Abra Compartments y pulse Create Compartment.
2. Llene Name y Description con los valores de la tabla.
3. En Tag namespace, deje None para usar etiquetas de forma libre y agregue las tres parejas clave/valor de la tabla.
4. Pulse Create Compartment.
5. Abra el compartimento recién creado y copie su OCID. Lo va a necesitar en el capítulo del presupuesto. Tendrá una forma parecida a ocid1.compartment.oc1..aaaaEJEMPLO.

Las etiquetas no son decoración: son lo que permite filtrar el costo del laboratorio en Cost Analysis sin separarlo a mano. Aplíquelas desde el principio, porque el análisis de costo necesita cerca de 24 horas de datos acumulados para mostrar algo útil.

3.4 Qué debe tener a mano antes de empezar

• El OCID del compartimento.
• El contenido de la llave pública SSH (el texto completo, no la ruta al archivo).
• Un correo electrónico para recibir las alertas de presupuesto.
• El archivo de configuración de arranque de la aplicación, que está transcrito completo en el capítulo 9 de este manual.

---

4. Presupuesto y alertas de costo

Este capítulo va primero, antes de crear un solo recurso. Por dos razones.

La primera es práctica: el crédito de una cuenta de prueba es finito y se consume solo. Un balanceador olvidado un fin de semana cuesta más que todo el laboratorio bien apagado.

La segunda es que el presupuesto es material del laboratorio. Es el control de FinOps más barato que existe: se activa en cinco minutos, no necesita proyecto ni herramienta adicional, y su alerta de proyección avisa antes de que el presupuesto se supere, no después. Lo que no hace es frenar el gasto; el alcance exacto está al final del capítulo.

Consola de OCIBilling & Cost Management › Budgets › Create Budget

1. Cambie el selector de compartimento de la esquina izquierda al compartimento raíz del tenancy. Los presupuestos se crean ahí aunque vigilen un compartimento hijo. Si no lo hace, el botón de creación no le dejará avanzar o el presupuesto quedará donde no debe.
2. Abra Budgets y pulse Create Budget.
3. En el ámbito del presupuesto, elija la opción que apunta a un compartimento (la alternativa apunta a una etiqueta de seguimiento de costo, que sirve cuando el gasto está repartido en varios compartimentos).
4. Seleccione lab-01-elasticidad como compartimento vigilado.
5. Llene Name y Description.
6. En el monto mensual escriba 150.
7. En la sección de la regla de alerta, elija Threshold metric = Actual, Threshold type = Percentage y Threshold = 50.
8. Escriba su correo en los destinatarios y el mensaje de la tabla.
9. Pulse Create.

Faltan tres avisos más. Se agregan sobre el presupuesto ya creado.

Consola de OCIBilling & Cost Management › Budgets › lab01-presupuesto-laboratorio › Alert Rules › Create Alert Rule

1. Abra el presupuesto y, en el menú de recursos de la izquierda, entre a las reglas de alerta.
2. Pulse Create Alert Rule y llene los campos de la tabla.
3. Repita el paso anterior para el aviso del 90 %, con nombre lab01-alerta-90pct y umbral 90.
4. Cree una cuarta regla, distinta de las anteriores: con nombre lab01-alerta-proyeccion, Threshold metric = Forecast, Threshold type = Percentage y Threshold = 100.
5. Verifique que las cuatro reglas aparecen listadas y habilitadas.

Las tres primeras avisan de gasto ya ocurrido. La cuarta avisa de gasto proyectado: dispara cuando la tendencia del mes indica que va a superar el presupuesto, aunque todavía no lo haya superado. Es la única de las cuatro que llega a tiempo de servir para algo.

De los tres umbrales, el útil es el del 50 %: llega cuando todavía hay margen para corregir. El del 90 % ya solo sirve para apagar cosas.

Una advertencia sobre el alcance de este control: los presupuestos de OCI avisan, no cortan. Son un límite informativo —un soft limit, en los términos de la documentación—: nada se apaga solo cuando se cruza un umbral. Y el aviso tampoco es instantáneo: OCI evalúa las reglas de alerta cada 24 horas, así que un descuido de la tarde puede tardar un día en llegar al correo. Por eso el control real sigue siendo el hábito de apagar el laboratorio todos los días y la revisión periódica de Cost Analysis.

En el ensayo de referencia, el laboratorio completo registró 0,13 USD de cómputo y el presupuesto proyectó 2,10 USD para el mes contra un límite de 150. El orden de magnitud importa: lo que arruina el crédito de una cuenta de prueba no es este laboratorio, es olvidarlo encendido.

---

5. Red: VCN, internet gateway y tabla de rutas

A partir de aquí, todo se crea dentro del compartimento lab-01-elasticidad. Cambie el selector de compartimento en la parte izquierda de cada pantalla antes de crear cada recurso. Es el error de navegación más frecuente en OCI y no avisa: el recurso queda creado, pero en otro sitio.

La consola ofrece un asistente (Start VCN Wizard) que crea de un golpe la VCN, una subred pública, una privada, el gateway y las rutas. No lo use aquí. Este laboratorio crea cada pieza por separado, porque el objetivo es ver qué hay debajo y porque la topología que necesitamos no es la del asistente.

5.1 La VCN

Consola de OCINetworking › Virtual Cloud Networks › Create VCN

1. Abra Virtual Cloud Networks y confirme que el compartimento seleccionado a la izquierda es lab-01-elasticidad.
2. Pulse Create VCN (no el asistente).
3. Escriba el nombre lab01-vcn.
4. En el bloque CIDR escriba 10.30.0.0/16.
5. Deje habilitada la resolución de nombres y escriba la etiqueta DNS lab01.
6. Agregue las tres etiquetas de la tabla.
7. Pulse Create VCN.

El rango 10.30.0.0/16 no tiene nada de mágico, pero elija uno que no choque con sus redes existentes si algún día va a conectarlas. Cambiar el CIDR de una VCN después implica recrearla.

5.2 El internet gateway

Consola de OCINetworking › Virtual Cloud Networks › lab01-vcn › Internet Gateways › Create Internet Gateway

1. Abra la VCN recién creada.
2. En el menú de recursos de la izquierda, entre a Internet Gateways.
3. Pulse Create Internet Gateway, escriba el nombre y confirme.

El gateway por sí solo no hace nada. Sin una ruta que lo apunte, la subred sigue sin salida. Ese es el siguiente paso, y es el que más gente olvida.

5.3 La tabla de rutas

Consola de OCINetworking › Virtual Cloud Networks › lab01-vcn › Route Tables › Create Route Table

1. En el menú de recursos de la VCN, entre a Route Tables.
2. Pulse Create Route Table y escriba el nombre lab01-rt-public.
3. En la regla de ruta, elija Target Type = Internet Gateway.
4. Escriba 0.0.0.0/0 como destino y seleccione lab01-igw como objetivo.
5. Pulse Create.

No use la tabla de rutas por defecto que la VCN trae. Una tabla propia hace explícito qué sale a internet y permite cambiar la topología después sin tocar lo que la VCN creó sola.

---

6. Security list: las cuatro reglas

La security list es el filtro de red que se aplica a toda la subred. OCI también tiene Network Security Groups, que se aplican por interfaz de red y son el mecanismo que se recomienda en ambientes reales. Aquí usamos una security list porque el laboratorio tiene una sola subred y una sola clase de máquina, y porque así la regla que se abre queda a la vista de todos en una sola pantalla.

Consola de OCINetworking › Virtual Cloud Networks › lab01-vcn › Security Lists › Create Security List

Las reglas quedan así:

1. En el menú de recursos de la VCN, entre a Security Lists.
2. Pulse Create Security List y escriba el nombre lab01-sl-app.
3. En Allow Rules for Egress, agregue una regla con Destination Type = CIDR, Destination CIDR = 0.0.0.0/0 e IP Protocol = All Protocols.
4. En Allow Rules for Ingress, agregue la primera regla: Source Type = CIDR, Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Destination Port Range = 80. Deje el rango de puertos de origen vacío.
5. Agregue la segunda regla de ingreso: Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Destination Port Range = 22. Lea el recuadro antes de aceptar este valor.
6. Agregue la tercera regla de ingreso: Source CIDR = 10.30.1.0/24, IP Protocol = All Protocols. Sin esta regla el balanceador no alcanza a las instancias y todos los backends quedan en estado crítico.
7. Deje sin marcar la casilla de regla sin estado (stateless) en las cuatro. Las reglas con estado permiten automáticamente el tráfico de respuesta, que es lo que se quiere aquí.
8. Pulse Create Security List.

---

7. La subred pública

La subred se crea al final de la red porque referencia las tres piezas anteriores: la tabla de rutas, la security list y, a través de ellas, el gateway.

Consola de OCINetworking › Virtual Cloud Networks › lab01-vcn › Subnets › Create Subnet

1. En el menú de recursos de la VCN, entre a Subnets.
2. Pulse Create Subnet y escriba el nombre.
3. Elija el tipo Regional. Una subred regional abarca todos los dominios de disponibilidad de la región; una específica de un dominio, solo uno. Para un grupo de instancias, regional es lo razonable.
4. Escriba 10.30.1.0/24 como bloque CIDR. Debe estar contenido en el 10.30.0.0/16 de la VCN.
5. Seleccione lab01-rt-public como tabla de rutas.
6. En el acceso de la subred, elija Public Subnet. Si elige privada, las instancias no podrán recibir IP pública y la configuración de instancia del capítulo 9 fallará al pedirla.
7. Escriba public como etiqueta DNS.
8. En las security lists, quite la lista por defecto y agregue lab01-sl-app. Dejar las dos puestas funciona, pero deja reglas invisibles activas y hace más difícil explicar qué está permitido.
9. Agregue las etiquetas del laboratorio y pulse Create Subnet.

En producción esta capa va en subred privada. El balanceador vive en la subred pública; las instancias de aplicación, en una privada sin IP pública. El único camino hacia ellas es el balanceador para el tráfico y un bastión para la administración. Aquí se usa una sola subred pública para acortar el laboratorio y para que el diagnóstico sea directo: se puede entrar por SSH a cualquier instancia del grupo sin saltos intermedios.

La diferencia de esfuerzo entre las dos topologías es de una subred, una tabla de rutas con NAT gateway y un bastión. No es grande, y conviene decir eso también.

---

8. Balanceador flexible, backend set y health check

El balanceador se crea antes que el grupo de instancias, porque el grupo se va a enganchar a su backend set. Y el listener se crea antes de enganchar el grupo, porque un backend set sin listener no recibe tráfico y el health check da resultados confusos.

El orden es: balanceador con su backend set y su health check → listener → (más adelante) grupo de instancias enganchado.

Consola de OCINetworking › Load Balancers › Load Balancer › Create Load Balancer

8.1 Detalles y ancho de banda

1. Abra Load Balancers y confirme el compartimento lab-01-elasticidad.
2. Pulse Create Load Balancer. Cuando la consola pregunte el tipo, elija el balanceador de capa 7 (Load Balancer), no el balanceador de red.
3. Escriba el nombre y elija visibilidad Public.
4. Deje la IP pública efímera. Una IP reservada solo hace falta si va a apuntar un nombre DNS estable, que no es el caso de un laboratorio que se destruye a diario.
5. En el ancho de banda, elija el shape flexible y escriba 10 de mínimo y 100 de máximo. El mínimo es capacidad garantizada y es lo que se factura de base; el máximo es el techo hasta donde puede crecer solo. Un balanceador flexible con mínimo alto cuesta más aunque no pase tráfico.
6. Seleccione la VCN lab01-vcn y la subred lab01-subnet-public.
7. Pase a la siguiente pantalla.

8.2 Backend set y política de salud

1. En la política de balanceo, elija la de round robin ponderado. Con todos los backends del mismo peso equivale al round robin simple, que es lo que este laboratorio quiere: las peticiones se reparten en orden entre todas las instancias, incluidas las nuevas.
2. No agregue backends. El grupo de instancias los va a registrar y a dar de baja solo. Un backend agregado a mano aquí sobrevive al escalamiento y queda apuntando a una instancia que ya no existe.
3. En la política de health check, elija protocolo HTTP y puerto 80.
4. Escriba /health como ruta y 200 como código esperado.
5. Escriba 10000 en el intervalo, 3000 en el tiempo de espera y 3 en los reintentos.
6. Pase a la siguiente pantalla.

El intervalo de 10 segundos es corto a propósito: hace que un backend nuevo aparezca rápido en pantalla. En producción se usan valores más conservadores, porque un health check agresivo multiplica las peticiones contra toda la flota y puede sacar de servicio un backend sano que solo estaba lento.

Estos tres números tienen consecuencia directa en el tiempo del ciclo: un backend nuevo necesita tres respuestas correctas separadas 10 segundos antes de recibir tráfico. Son 30 segundos como mínimo teórico, y forman parte de los casi doce minutos del capítulo 12.

8.3 Listener

1. Escriba el nombre del listener.
2. Elija tráfico HTTP y puerto 80. Sin certificado: este laboratorio no hace TLS, y agregarlo no cambia nada de lo que se quiere medir.
3. Confirme que el backend set asociado es el que acaba de definir.
4. En la pantalla de registro (logging), deje los registros de acceso y de error como vengan. No hacen falta para el laboratorio y generan volumen.
5. Pulse Submit y espere. El balanceador es lo más lento de crear de todo el laboratorio: entre 5 y 8 minutos hasta que queda activo.
6. Cuando el estado pase a activo, anote la IP pública que aparece en la página de detalle. Es la dirección que va a usar para todo lo demás.

Si el backend set no quedó con el nombre lab01-bset, córrijalo ahora o anote el nombre real: lo va a necesitar al enganchar el grupo de instancias.

En este punto el balanceador está vivo y sin backends. Si abre su IP en un navegador, responderá con un error del propio balanceador. Es lo esperado: todavía no hay a quién mandarle el tráfico.

---

9. Instance configuration: la plantilla de la máquina

La instance configuration es la plantilla que el grupo usa para crear cada instancia nueva. Es el equivalente de un launch template de AWS o del modelo de un scale set de Azure.

Dos detalles de esta pantalla deciden si el laboratorio funciona o no: el script de inicialización y el plugin de monitoreo. Los dos están explicados abajo, y los dos son fallos medidos, no advertencias teóricas.

Consola de OCICompute › Instance Configurations › Create instance configuration

1. Abra Instance Configurations en el menú de Compute y confirme el compartimento.
2. Pulse Create instance configuration. El formulario que abre es prácticamente el mismo de crear una instancia, pero no crea nada: solo guarda la plantilla.
3. Escriba el nombre lab01-instance-config.
4. En la sección de ubicación, deje el dominio de disponibilidad que la consola propone. Si la región tiene varios y quiere repartir el grupo, eso se configura después, en el grupo de instancias, no aquí.
5. En la imagen, pulse el botón de cambiar imagen y elija Oracle Linux, versión 9, la compilación más reciente que ofrezca la lista.
6. En el shape, elija la familia Virtual machine, serie AMD, y el shape VM.Standard.E4.Flex. Ponga 1 OCPU y 8 GB de memoria.
7. En la red, seleccione la VCN lab01-vcn y la subred lab01-subnet-public, y marque la asignación de dirección IPv4 pública.
8. En el volumen de arranque, especifique 50 GB.
9. Pegue el contenido completo de su llave pública SSH en el campo de llaves.

9.1 El script de inicialización

1. Abra las opciones avanzadas del formulario y ubique la pestaña de administración, donde está el initialization script.
2. Elija pegar el contenido (la alternativa es subir un archivo; las dos sirven) y pegue literalmente el bloque completo que sigue, empezando por #cloud-config.

#cloud-config
# Aplicacion minima de demostracion del laboratorio.
#
#   GET /              -> nombre del host que atendio, hora y CPUs
#   GET /health        -> 200 OK. Lo consulta el health checker del balanceador.
#   GET /burn?ms=250   -> quema CPU durante ms milisegundos. Es lo que hace subir
#                         la metrica y disparar el autoescalamiento.
#
# Deliberadamente sin dependencias externas: solo la libreria estandar de Python.
# Una instancia nueva del grupo queda sirviendo trafico sin descargar nada de
# internet, que es justo lo que hace predecible el tiempo de arranque.

write_files:
  - path: /opt/lab/app.py
    permissions: "0755"
    content: |
      import os
      import socket
      import time
      from http.server import BaseHTTPRequestHandler, HTTPServer
      from socketserver import ForkingMixIn
      from urllib.parse import urlparse, parse_qs

      HOSTNAME = socket.gethostname()
      CPUS = os.cpu_count()
      STARTED = time.time()

      def burn(ms):
          end = time.perf_counter() + (ms / 1000.0)
          x = 0
          while time.perf_counter() < end:
              x += 1
          return x

      class Handler(BaseHTTPRequestHandler):
          protocol_version = "HTTP/1.1"

          def _send(self, code, body, ctype="text/plain; charset=utf-8"):
              data = body.encode("utf-8")
              self.send_response(code)
              self.send_header("Content-Type", ctype)
              self.send_header("Content-Length", str(len(data)))
              self.end_headers()
              self.wfile.write(data)

          def do_GET(self):
              parsed = urlparse(self.path)

              if parsed.path == "/health":
                  self._send(200, "ok")
                  return

              if parsed.path == "/burn":
                  qs = parse_qs(parsed.query)
                  ms = int(qs.get("ms", ["250"])[0])
                  ms = max(1, min(ms, 5000))
                  burn(ms)
                  self._send(200, "burned {}ms on {}".format(ms, HOSTNAME))
                  return

              uptime = int(time.time() - STARTED)
              self._send(200,
                  "Laboratorio de arquitectura elastica\n"
                  "Atendido por : {}\n"
                  "OCPUs        : {}\n"
                  "Uptime       : {}s\n"
                  "Hora         : {}\n".format(
                      HOSTNAME, CPUS, uptime,
                      time.strftime("%Y-%m-%d %H:%M:%S")))

          def log_message(self, *args):
              pass  # sin ruido en el journal

      # Servidor que BIFURCA procesos, no hilos. Ver el recuadro del manual.
      class ServidorConProcesos(ForkingMixIn, HTTPServer):
          max_children = 64
          daemon_threads = True

      if __name__ == "__main__":
          ServidorConProcesos(("0.0.0.0", 80), Handler).serve_forever()

  - path: /etc/systemd/system/lab-app.service
    permissions: "0644"
    content: |
      [Unit]
      Description=Aplicacion de demostracion del laboratorio
      After=network-online.target
      Wants=network-online.target

      [Service]
      ExecStart=/usr/bin/python3 /opt/lab/app.py
      Restart=always
      RestartSec=2

      [Install]
      WantedBy=multi-user.target

runcmd:
  # Oracle Linux trae firewalld activo y bloquea el 80. Sin esto el health check
  # nunca pasa y el backend queda permanentemente en CRITICAL.
  - firewall-cmd --permanent --add-port=80/tcp
  - firewall-cmd --reload
  - systemctl daemon-reload
  - systemctl enable --now lab-app.service

Tres cosas de este archivo merecen atención, y las tres son fallos que costaron tiempo antes de quedar documentados.

La segunda: la línea de firewall-cmd. Oracle Linux trae firewalld activo y el puerto 80 cerrado. Sin abrirlo, la instancia arranca bien, el servicio corre bien, y el health check nunca pasa: el backend queda permanentemente en estado crítico y el balanceador nunca le manda tráfico. Es el síntoma más común y el más confuso, porque todo parece estar bien.

La tercera: la aplicación se instala como servicio de systemd con Restart=always. Si se cae, vuelve sola. Eso importa cuando una instancia del grupo tiene un mal momento bajo carga: sin reinicio automático, el health check la sacaría y el grupo escalaría para compensar algo que era un proceso caído.

9.2 El plugin de monitoreo

1. En las opciones avanzadas, abra la pestaña del Oracle Cloud Agent.
2. Confirme que el plugin de monitoreo de la instancia de cómputo está habilitado. En las imágenes de plataforma suele venir activo por defecto, pero confírmelo con los ojos: es gratis confirmarlo y caro descubrirlo después.
3. Pulse Create para guardar la configuración de instancia.

---

10. Instance pool: el grupo de instancias

El grupo toma la plantilla del capítulo anterior, crea N instancias idénticas y las mantiene. Si una se cae o se borra, la repone. Y —esta es la parte que importa— se engancha al backend set del balanceador, de modo que cada instancia que entra o sale del grupo se registra o se da de baja en el balanceador sola.

Consola de OCICompute › Instance Pools › Create instance pool

1. Abra Instance Pools y confirme el compartimento.
2. Pulse Create instance pool y escriba el nombre lab01-pool.
3. Seleccione lab01-instance-config como configuración de instancia. Si no aparece, revise que está mirando el compartimento correcto.
4. Pase a la pantalla de ubicación del grupo.
5. Escriba 2 en el número de instancias. Este es el tamaño con el que arranca; a partir de que exista la política de autoescalamiento, el tamaño lo gobierna ella.
6. Elija el dominio de disponibilidad y, como subred de la VNIC principal, lab01-subnet-public.
7. Active la opción de enganchar un balanceador.
8. Seleccione el balanceador lab01-lb, el backend set lab01-bset, el puerto 80 y la VNIC principal como origen de la dirección a registrar.
9. Agregue las etiquetas del laboratorio.
10. Revise y pulse Create.

El grupo pasa a estado de aprovisionamiento y crea las dos instancias. Tardan unos minutos en arrancar, ejecutar el script de inicialización y empezar a responder.

10.1 Verificar que el grupo quedó sirviendo

1. Abra la página de detalle del grupo y confirme que aparece en estado de ejecución con dos instancias.
2. Abra el balanceador y entre a su backend set. Debe ver dos backends, y al cabo de unos minutos los dos en estado correcto. Recuerde que el health check necesita tres respuestas buenas separadas 10 segundos.
3. Abra http://<IP-del-balanceador>/ en el navegador. Debe ver el nombre del host que atendió.
4. Recargue varias veces. El nombre del host debe alternar entre las dos instancias. Si siempre responde el mismo, uno de los dos backends no está sano.

Verificación equivalente por línea de comandos, si la prefiere:

LB=<IP-del-balanceador>

curl -s "http://$LB/health"      # -> ok
curl -s "http://$LB/"            # -> muestra el host que atendio
curl -s "http://$LB/" ; curl -s "http://$LB/"   # el hostname debe alternar

Si los backends no se ponen sanos, no siga al capítulo siguiente. Un grupo que no sirve tráfico tampoco va a escalar de forma útil, y estará depurando dos cosas a la vez. El capítulo 15 tiene la tabla de diagnóstico.

---

11. Autoescalamiento: las dos mitades

Aquí es donde el grupo deja de ser un tamaño fijo. La autoscaling configuration es un recurso aparte que se engancha al grupo y le cambia el tamaño según una métrica.

La política tiene dos reglas, y las dos son obligatorias para que el laboratorio tenga sentido: una que agrega capacidad cuando la CPU sube, y otra que la quita cuando baja.

Consola de OCICompute › Autoscaling Configurations › Create autoscaling configuration

11.1 Detalles y grupo asociado

1. Abra Autoscaling Configurations y confirme el compartimento.
2. Pulse Create autoscaling configuration y escriba el nombre.
3. Seleccione el grupo lab01-pool como recurso a escalar.
4. Pase a la pantalla de la política.

11.2 La política

1. Elija el tipo de política basada en métrica. La alternativa es basada en horario, que sirve para cargas predecibles por calendario y no es lo que se mide aquí.
2. Escriba el nombre de la política.
3. En el enfriamiento, escriba 300 segundos. Es el mínimo que la consola acepta, y también el mínimo práctico: por debajo, el grupo oscila —sube, baja, vuelve a subir— y ese es exactamente el antipatrón que este laboratorio existe para no mostrar.
4. Elija CPU utilization como métrica de rendimiento.
5. En la regla de escalamiento hacia afuera, ponga operador mayor que, umbral 55 y 2 instancias a agregar.
6. En la regla de escalamiento hacia adentro, ponga operador menor que, umbral 20 y 1 instancia a quitar.
7. Escriba 2 como mínimo, 6 como máximo y 2 como número inicial de instancias. El número inicial debe estar entre el mínimo y el máximo, y conviene que coincida con el tamaño con que creó el grupo.
8. Deje la configuración habilitada.
9. Revise y pulse Create.

11.3 Por qué esos números

Umbral de salida en 55 %. Tiene que estar por debajo del techo real que su carga puede producir. Con el servidor de hilos el techo medido era 48 % y el umbral de 55 % nunca se cruzaba; con procesos, la carga llega a 76 % y lo cruza con margen. El umbral se elige mirando la métrica bajo carga, no en abstracto.

Paso de salida de +2. Agregar de dos en dos hace el cambio visible y llega antes al tamaño donde la carga se reparte. Agregar de a uno, con un enfriamiento de 300 segundos entre acciones, multiplica el tiempo hasta tener capacidad suficiente.

Umbral de entrada en 20 %. Lejos del de salida, a propósito. Umbrales cercanos producen oscilación: el grupo crece, la CPU baja al repartirse, cruza el umbral de bajada, el grupo encoge, la CPU vuelve a subir. Esa banda muerta entre 20 % y 55 % es lo que mantiene el sistema quieto.

Paso de entrada de −1. Más pequeño que el de salida, también a propósito. Se baja con más cautela de la que se sube, para no recortar capacidad justo antes de un pico nuevo. Equivocarse escalando hacia arriba cuesta unos centavos; equivocarse escalando hacia abajo cuesta una caída de servicio.

11.4 El scale-in es la mitad que casi nadie configura

Casi todas las configuraciones de autoescalamiento que uno encuentra en la práctica tienen solo la regla de subida. Es entendible: la regla de subida es la que protege el servicio, y es la que alguien escribió el día que el sitio se cayó.

Pero un grupo que sube y no baja es un grupo que queda permanentemente en su tamaño máximo después del primer pico. Toda la promesa de la elasticidad —pagar por lo que se usa— depende de la regla que casi nadie escribe.

En este laboratorio, la bajada se puede ver porque el generador de carga golpea a través del balanceador. Como el balanceador reparte en round robin, la misma carga total se divide entre más instancias a medida que el grupo crece: más instancias repartiéndose el mismo trabajo significa menos CPU por instancia. El grupo sube porque la CPU sube, y después la propia subida hace bajar la CPU. Ese es el ciclo completo, no la mitad.

Medido tras cortar la carga: la CPU cayó a 0,6 % y el primer paso de bajada, de 6 a 5 instancias, ocurrió 251 segundos después (4 minutos y 11 segundos). Los pasos siguientes van uno a uno, con 300 segundos de enfriamiento entre cada uno, hasta llegar al mínimo de 2. Bajar de 6 a 2 toma varios ciclos y es notablemente más lento que subir: es la consecuencia directa de haber elegido un paso de bajada de 1 y uno de subida de 2.

---

12. El ciclo completo, medido

Este capítulo no crea nada. Es el resultado del laboratorio: la medición real del ciclo, y de dónde sale cada tramo.

12.1 Los números

Medición sobre esta misma configuración —VM.Standard.E4.Flex de 1 OCPU, grupo 2–6, subida con CPU > 55 % en pasos de +2, bajada con CPU < 20 % en pasos de −1, enfriamiento de 300 s— con una carga de 40 procesos concurrentes pidiendo 1500 ms de CPU cada uno, generada desde fuera de la región.

El número que hay que decir en voz alta es 11 minutos 47 segundos. Casi doce minutos desde que la carga empieza hasta que la capacidad nueva atiende peticiones.

12.2 De dónde sale cada tramo

  t=0                                                        t=707 s
   │                                                            │
   ├──────────────┬──────────────────────┬──────────────────────┤
   │   < 140 s    │       ~270 s         │       ~297 s         │
   │              │                      │                      │
   │  la CPU sube │  la métrica se       │  las instancias      │
   │  y cruza el  │  agrega, se evalúa   │  arrancan, corren    │
   │  umbral      │  y la política       │  cloud-init y pasan  │
   │              │  dispara             │  el health check     │
   │              │                      │                      │
   └──────────────┴──────────────────────┴──────────────────────┘
      carga →         decisión →               capacidad util
                   (410 s: el grupo
                    pasa de 2 a 4)

Tramo 1 — menos de 140 segundos: la carga tiene que llegar a la métrica. La CPU de la máquina sube casi de inmediato, pero lo que importa no es la CPU: es la métrica. El agente de la instancia publica CpuUtilization en intervalos de un minuto, de modo que el primer punto que refleja la carga aparece hasta un minuto después de que la carga empiece. Medido: menos de 140 segundos hasta ver la métrica por encima del umbral en Metrics Explorer.

Tramo 2 — del cruce del umbral a los 410 segundos: el servicio decide. Aquí ocurren tres cosas. La métrica se agrega a nivel del grupo, no de una instancia. El servicio de autoescalamiento evalúa esa serie contra el umbral y no actúa con un solo punto: exige que la condición se sostenga, que es lo que evita que un pico de tres segundos dispare una acción. Y, si hubo una acción de escalamiento reciente, el enfriamiento de 300 segundos bloquea la siguiente. En la medición, el grupo cambió de 2 a 4 instancias a los 410 segundos.

Tramo 3 — de los 410 a los 707 segundos: la capacidad nueva tiene que estar lista. Este tramo, de casi cinco minutos, es el que más sorprende y el que menos se puede recortar. Contiene, en orden: el aprovisionamiento de las dos instancias nuevas, el arranque de Oracle Linux 9, la ejecución del script de inicialización —escribir la aplicación, abrir el puerto 80 en firewalld, habilitar y arrancar el servicio—, el registro de cada instancia como backend del balanceador, y tres health checks correctos separados 10 segundos antes de que el backend reciba tráfico. Solo ese último paso son 30 segundos de mínimo teórico. El resto es arranque de sistema operativo.

Los tramos internos no se cronometraron por separado; el reparto entre arranque y health check es una lectura de la configuración, no una medición. [VALIDAR] si va a citar el desglose fino del tercer tramo; el total de 707 s sí está medido.

La bajada, 251 segundos: llama la atención que sea menor que el enfriamiento de 300 segundos. La explicación es que el reloj del enfriamiento corre desde la última acción de escalamiento, no desde el momento en que la carga se detiene. Cuando la carga se cortó, el grupo llevaba ya un rato en 6 instancias sin cambios, así que el enfriamiento estaba cumplido y lo único que faltaba era que la métrica bajara y se evaluara.

12.3 Qué se hace con este número

El criterio que este laboratorio propone es sencillo: si el ciclo completo cabe en menos de ocho minutos, una demostración en vivo funciona; si no, hay que arrancar la carga antes de empezar. Con 11 minutos 47 segundos, la respuesta es la segunda. La carga se arranca unos quince minutos antes y lo que se muestra es el ciclo ya en marcha.

Trasladado a una decisión de arquitectura, el mismo número dice esto: la capacidad base del grupo no se define por la carga promedio, se define por lo que hay que poder absorber sin ayuda durante doce minutos. Si su pico de tráfico llega y se va en cinco minutos, el autoescalamiento reactivo no lo va a atender: llegará cuando el pico ya pasó, y le cobrará las instancias nuevas mientras la carga baja. Para ese patrón las alternativas son otras: capacidad base mayor, escalamiento por horario si el pico es predecible, o una arquitectura donde el pico se absorba en una cola en vez de en instancias.

Esa conversación es el producto real del laboratorio. La demostración solo es la prueba de que los números son verdad.

12.4 Cómo reproducir la medición

Necesita tres cosas a la vez: una fuente de carga, una vista del grupo y del balanceador, y un reloj.

1. Abra Metrics Explorer en otra pestaña, con namespace oci_computeagent y métrica CpuUtilization, agrupada por el identificador del recurso. Esta es la métrica que la política está leyendo: si aquí no ve nada, la política tampoco.
2. Abra la página del grupo de instancias y la del backend set del balanceador.
3. Genere carga contra http://<IP-del-balanceador>/burn?ms=1500 desde varias conexiones simultáneas. Cuarenta concurrentes es lo que produjo los números de arriba.
4. Anote la hora de inicio. Anote la hora de cada cambio: cruce del umbral, cambio de tamaño del grupo, instancia nueva en ejecución, backend nuevo sano.
5. Corte la carga y anote la hora. Anote la hora del primer paso de bajada.
6. Repita la medición dos veces. La primera pasada incluye el arranque en frío de la métrica y no es representativa.

Un detalle que costó una medición perdida: al cortar el generador de carga, asegúrese de que se cortó de verdad. En el ensayo, los procesos hijos del generador quedaron huérfanos y siguieron golpeando el balanceador después de un corte aparentemente limpio. La CPU se mantuvo al 80 %, el paso de bajada no llegó nunca, y el tiempo se fue en buscar un problema de autoescalamiento que no existía. Verifique en Metrics Explorer que la CPU efectivamente cayó antes de empezar a contar.

---

13. Cambiar la aplicación sin bloquear el borrado

Tarde o temprano va a querer cambiar el script de inicialización: corregir la aplicación, cambiar el shape, agregar un paquete. Y aquí hay una trampa que en la consola se resuelve con un orden de operaciones concreto.

Una instance configuration no se puede editar. Al abrirla verá que no hay botón de edición de sus parámetros: la plantilla es inmutable. Cambiarla significa crear una nueva.

Y una instance configuration no se puede borrar mientras un grupo la referencia. El borrado falla.

Puestas las dos restricciones juntas, el orden equivocado deja el laboratorio trabado: si intenta borrar la configuración vieja para poner la nueva, el borrado falla porque el grupo la está usando; y si intenta cambiar el grupo sin tener la nueva creada, no hay a qué apuntarlo.

El procedimiento completo, paso a paso:

Consola de OCICompute › Instance Configurations › Create instance configuration

1. Cree la configuración nueva repitiendo el capítulo 9 completo, con el nombre lab01-instance-config-v2 y el cambio que necesita. Sí, hay que volver a llenar todo el formulario: no hay clonado del formulario en esta pantalla. Si va a iterar mucho sobre el script de inicialización, guárdelo en un archivo aparte y súbalo en vez de pegarlo.

Consola de OCICompute › Instance Pools › lab01-pool › Edit

1. Abra el grupo lab01-pool y pulse Edit.
2. Cambie la configuración de instancia a lab01-instance-config-v2 y guarde.
3. Entienda qué acaba de pasar: las instancias que ya existen no cambian. El grupo usará la configuración nueva para las instancias que cree de ahora en adelante. Las viejas siguen corriendo la aplicación vieja.
4. Para que el cambio llegue a todas, hay dos caminos. El brusco: reducir el tamaño del grupo hasta el mínimo y volver a subirlo, de modo que las instancias nuevas nazcan con la configuración nueva. El ordenado: terminar las instancias una por una desde la página del grupo, dejando que el grupo las reponga, y esperar entre cada una a que el backend nuevo esté sano antes de tocar la siguiente. En un laboratorio, el brusco basta y es más rápido; en algo con tráfico real, el ordenado es el único aceptable.
5. Verifique que el grupo volvió a su tamaño y que todos los backends están sanos.

Consola de OCICompute › Instance Configurations › lab01-instance-config › Delete

1. Solo ahora, borre la configuración vieja. Si el borrado falla con un mensaje de recurso en uso, es que algún grupo todavía la referencia: vuelva al paso 2 y confirme que el cambio quedó guardado.

Una nota sobre el tamaño del grupo y el autoescalamiento: mientras la política de autoescalamiento esté habilitada, cualquier tamaño que usted fije a mano será corregido por ella en la siguiente evaluación. Si necesita que el grupo se quede quieto durante una intervención, deshabilite primero la configuración de autoescalamiento y vuelva a habilitarla al terminar. Es una casilla en la página de la configuración, y es reversible.

---

14. Validación de extremo a extremo

Recorra esta lista antes de dar el laboratorio por bueno. En orden: cada punto asume que el anterior pasó.

14.1 La red

Consola de OCINetworking › Virtual Cloud Networks › lab01-vcn

1. La VCN existe, con CIDR 10.30.0.0/16.
2. La subred lab01-subnet-public existe, es pública y usa la tabla de rutas lab01-rt-public y la security list lab01-sl-app.
3. La tabla de rutas tiene una regla 0.0.0.0/0 hacia el internet gateway.
4. La security list tiene las cuatro reglas del capítulo 6, incluida la de 10.30.1.0/24.

14.2 El balanceador y el grupo

Consola de OCINetworking › Load Balancers › lab01-lb

1. El balanceador está activo y tiene una IP pública.
2. El backend set lab01-bset tiene tantos backends como instancias haya en el grupo.
3. Todos los backends están en estado correcto. Uno solo en estado crítico indica que esa instancia no está sirviendo, y el grupo va a escalar para compensar algo que es un problema de arranque.
4. Abra http://<IP-del-balanceador>/ y recargue cinco veces. El nombre del host debe alternar entre todas las instancias vivas.

Equivalente por línea de comandos:

# Salud del backend set. Ojo: el subcomando es backend-set-health get.
# «oci lb backend-health list» no existe, aunque suene plausible.
oci lb backend-set-health get \
  --load-balancer-id "<ocid-del-balanceador>" \
  --backend-set-name "lab01-bset" \
  --query 'data.{estado:status,total:"total-backend-count",criticos:"critical-state-backend-names"}'

# Tamaño actual del grupo
oci compute-management instance-pool get \
  --instance-pool-id "<ocid-del-grupo>" --query 'data.size'

14.3 La métrica

Consola de OCIObservability & Management › Monitoring › Metrics Explorer

1. Abra Metrics Explorer y arme la consulta con los valores de la tabla.
2. Debe ver una serie por cada instancia del grupo. Si no ve ninguna, el plugin de monitoreo está deshabilitado o las instancias todavía no publicaron su primer punto. Espere entre 5 y 10 minutos antes de concluir que hay un problema.
3. Con carga aplicada, las series deben cruzar el 55 %. Si se quedan pegadas cerca del 50 %, revise el recuadro del capítulo 9 sobre procesos e hilos: es exactamente ese síntoma.

14.4 El ciclo

14.5 El presupuesto

Consola de OCIBilling & Cost Management › Budgets › lab01-presupuesto-laboratorio

1. El presupuesto existe, apunta al compartimento lab-01-elasticidad y tiene las cuatro reglas de alerta.
2. En Cost Analysis, filtre por el compartimento del laboratorio y agrupe por servicio. Necesita cerca de 24 horas de datos acumulados para mostrar algo: si acaba de crear todo, vuelva mañana.
3. Confirme que el gasto observado está en el orden esperado. En el ensayo de referencia fueron 0,13 USD de cómputo, con una proyección mensual de 2,10 USD contra el límite de 150.

---

15. Qué puede salir mal

Todos los síntomas de esta tabla ocurrieron de verdad durante la construcción y el ensayo del laboratorio. Ninguno es hipotético.

---

16. Limpieza

El laboratorio se destruye todos los días. No es una recomendación de higiene: es la diferencia entre gastar centavos y gastar el crédito de la cuenta de prueba. Un balanceador flexible y seis instancias olvidadas un fin de semana cuestan más que toda la semana de preparación bien apagada.

Predicar FinOps en el capítulo 4 y dejar el laboratorio encendido se nota.

16.1 El orden correcto

El orden importa porque cada recurso bloquea el borrado del anterior.

  1. Deshabilitar la autoscaling configuration
        └─ si no, repone instancias mientras usted las borra
  2. Borrar la autoscaling configuration
  3. Borrar el instance pool
        └─ termina sus instancias y las quita del backend set
  4. Borrar la instance configuration
        └─ ahora sí se deja: ya nadie la referencia
  5. Borrar el load balancer
        └─ es lo que cobra por hora aunque no pase trafico
  6. Borrar la subred, la security list, la route table y el
     internet gateway
  7. Borrar la VCN
  8. (Opcional) Borrar el compartimento
        └─ solo cuando este vacio; el borrado tarda

Consola de OCICompute › Autoscaling Configurations › lab01-autoscaling

1. Abra la configuración de autoescalamiento y deshabilítela antes de tocar nada más. Si borra instancias con la política activa, el grupo las repone y usted persigue su propia cola.
2. Espere unos segundos y bórrela.

Consola de OCICompute › Instance Pools › lab01-pool › Terminate

1. Abra el grupo y termínelo. Esto apaga y borra todas sus instancias, y las da de baja del backend set. Espere a que el grupo desaparezca de la lista antes de seguir.

Consola de OCICompute › Instance Configurations › lab01-instance-config › Delete

1. Borre la configuración de instancia. Ahora sí se deja, porque ya no hay grupo que la referencie.

Consola de OCINetworking › Load Balancers › lab01-lb › Delete

1. Borre el balanceador. Este es el recurso que hay que borrar sí o sí: cobra por hora por su ancho de banda mínimo garantizado, pase o no pase tráfico por él.

Consola de OCINetworking › Virtual Cloud Networks › lab01-vcn

1. Dentro de la VCN, borre en este orden: la subred, la security list, la tabla de rutas y el internet gateway. Una subred con VNICs adentro no se borra; si se resiste, es que quedó una instancia viva o el balanceador todavía existe.
2. Borre la VCN.
3. Opcionalmente, borre el compartimento. Solo se deja borrar cuando está vacío, y el borrado tarda un rato en completarse. Si va a repetir el laboratorio, consérvelo.

16.2 Qué se queda cobrando si lo hace mal

Después de limpiar, vuelva a Cost Analysis filtrando por el compartimento del laboratorio y confirme que el gasto diario cae a cero en las siguientes 24 horas. Los datos de consumo tardan horas en consolidarse, así que la cifra del día del borrado seguirá subiendo un rato. El que importa es el día siguiente.

---

17. Documentación oficial

Los enlaces apuntan a la sección general de cada servicio. Las rutas profundas de docs.oracle.com cambian con las versiones de la consola; desde la página general siempre se llega.

Si alguno de estos enlaces devuelve un error, busque el nombre del servicio en docs.oracle.com/en-us/iaas/ y entre por el índice. Es más rápido que adivinar la ruta.