Ciclo de vida de la instancia
Una instancia siempre está en exactamente uno de ocho estados. El estado en el que se encuentra determina tres cosas que le importan: si puede conectarse a ella, si le está facturando y qué acciones están disponibles.
La máquina de estados
La ruta normal es creating → running → stopping → stopped → starting → running. El desmontaje siempre es destroying → destroyed, y puede comenzarlo desde cualquier estado excepto el propio destroyed, incluso mientras la instancia todavía se está creando, iniciando o deteniendo. Las flechas punteadas son la plataforma devolviendo una instancia a donde estaba cuando el host no hizo lo que se le pidió; se explican más abajo.
Pedir un movimiento que el estado actual no permite —iniciar una instancia que ya está en ejecución, detener una que todavía se está creando— se rechaza, y la instancia se queda donde estaba.
Todos los estados
| Estado | Transitorio | Facturación | Qué significa |
|---|---|---|---|
creating | sí | ninguna | El bloque ya está reservado y su carga de trabajo se está levantando por primera vez. |
starting | sí | ninguna | Una instancia detenida vuelve a encenderse en la misma máquina, con el mismo disco. |
running | no | GPU, por segundo | La carga de trabajo está activa. SSH, JupyterLab y los puertos que publicó son accesibles. |
stopping | sí | ninguna | El contenedor se está apagando. Su disco se conserva. |
stopped | no | disco, por GB y por hora | No se ejecuta nada. El disco se conserva, y la ranura de GPU también, salvo que la plataforma la haya liberado: vea Detener vs. destruir. |
destroying | sí | ninguna | El contenedor y el disco se están desmontando. |
destroyed | no | ninguna | Final. El disco desapareció y la oferta volvió al mercado. |
error | no | ninguna | La carga de trabajo no pudo levantarse, falló o terminó por su cuenta. Vea más abajo. |
Los estados transitorios son los cuatro que la plataforma está resolviendo activamente; la consola los muestra con una insignia parpadeante y actualiza con más frecuencia mientras uno está en curso. Se resuelven solos: no hay nada que reintentar, aunque puede destruir la instancia en lugar de esperar.
Los estados no transitorios son estables. Una instancia permanece en running, stopped, destroyed o error hasta que usted, el sistema de facturación o el propio reporte del host la mueva.
Qué provoca cada transición
| Transición | Disparador |
|---|---|
→ creating | Usted despliega: POST /v1/instances con una oferta, una plantilla y un tamaño de disco. |
creating/starting → running | La carga de trabajo se reportó activa. El medidor de GPU arranca aquí, no al desplegar. |
creating → error | La carga de trabajo no pudo levantarse. |
running → stopping | Usted la detiene, o su saldo llega a $0. Su propia detención mantiene las GPU reservadas, salvo que una disputa de pago tenga congelados los pagos de la organización: entonces las libera, como la de $0. Una liberación solo ocurre donde la máquina lo permite. |
stopping → stopped | El apagado terminó. El medidor de disco arranca aquí. |
stopping → running | El host no confirmó la detención en 30 minutos. El contenedor sigue activo, así que el medidor de GPU vuelve a encenderse y la detención se sigue reintentando. Su error_code indica stop_timed_out. |
stopped → starting | Usted la inicia. Requiere un saldo que cubra una hora de todo lo que la organización tiene en marcha, esta instancia incluida. Una instancia cuyas GPU se liberaron debe recuperar las mismas GPU: si alguna está en uso, el inicio se rechaza con 409 CAPACITY_UNAVAILABLE y la instancia sigue en stopped. |
starting → stopped | El host rechazó la reanudación o no se pudo contactar, o no la confirmó en 30 minutos (start_timed_out). En una instancia cuyas GPU se liberaron, un rechazo suele significar que ahora las tiene otro cliente (gpus_unavailable). La instancia vuelve a estar detenida, con su disco, y puede iniciarla de nuevo. |
stopped → error | La máquina informó de que el contenedor de la instancia detenida ya no existe: terminó o desapareció mientras estaba detenida, y el disco se fue con él (workload_gone). No queda nada que iniciar. |
running → error | La carga de trabajo falló, el host la perdió, o un trabajo terminó por su cuenta (workload_completed). La GPU se libera. |
error → running o stopped | La plataforma encontró la carga de trabajo sana después de todo —en ejecución, o retenida con su disco— y devolvió la instancia a ese estado. |
cualquier estado salvo destroyed → destroying | Usted la destruye. La destrucción automática hace lo mismo con las instancias detenidas y en error una vez que el saldo ha permanecido bajo el tiempo suficiente. |
destroying → destroyed | El desmontaje terminó. El disco se elimina y la oferta se libera. |
Dos de esos disparadores no son suyos. Cuando el saldo de la organización llega a cero, las instancias en ejecución se detienen automáticamente, y las instancias detenidas liberan sus GPU donde la máquina lo permite. Si después el saldo permanece en cero o por debajo durante 24 horas y está en −$5 o por debajo, las instancias detenidas y en error se destruyen. Las instancias en ejecución nunca se destruyen directamente: primero se detienen. Una disputa de pago abierta también libera las GPU de las instancias detenidas, aunque el saldo sea positivo. Todo esto se cubre en Detención y destrucción automáticas.
Desplegar e iniciar requieren que el saldo cubra una hora del consumo total de la organización —la GPU y el disco de cada instancia en ejecución, iniciándose o en creación, el disco de cada una detenida, y la GPU y el disco de la instancia que está desplegando o iniciando—, no solo que sea mayor que cero. Detener y destruir nunca lo requieren: siempre puede apagar algo, sea cual sea su saldo.
La facturación sigue al estado
Los cargos se liquidan a la tarifa del estado en el que la instancia estuvo realmente, y cada cambio de estado liquida lo adeudado antes de que el cambio surta efecto. El medidor de GPU corre solo en running. El medidor de disco corre solo en stopped. Los cuatro estados transitorios, error y destroyed son gratuitos.
Por eso un despliegue que tarda dos minutos en levantarse no factura esos dos minutos, y por eso una instancia detenida sigue generando un cargo cada minuto en su libro contable.
Qué significa "error"
error significa que la carga de trabajo no se está ejecutando y que la plataforma no la retiene para usted: la imagen falló al descargarse, el contenedor se negó a iniciar, el host dejó de reportar durante el lanzamiento, la carga de trabajo falló o se perdió mientras se ejecutaba, un trabajo terminó por su cuenta, o el contenedor de una instancia detenida desapareció de su máquina. La página de la instancia indica cuál fue bajo Qué salió mal, y la API lo informa como error_code y error_message de la instancia. Vea Por qué falló una instancia.
De ahí se derivan cuatro cosas:
- No se le factura. El medidor está apagado en
error, y nada se acumula mientras la instancia permanece ahí. - No se reintenta. No hay relanzamiento automático. La única salida distinta de destruirla es una recuperación: si la plataforma encuentra más tarde la carga de trabajo en ejecución, o retenida con su disco, devuelve la instancia a
runningostopped. - Puede limpiarse por usted. Una instancia que entró en error antes de llegar a ejecutarse, o cuya carga de trabajo se sabe que terminó, se destruye automáticamente alrededor de una hora después de entrar en
error, disco incluido. Una instancia que llegó a ejecutarse y cuya carga de trabajo puede seguir retenida no se destruye: espera a que la plataforma averigüe qué le pasó, o a usted. - Destruir es la única acción que puede tomar. No puede iniciar, detener ni reparar una instancia con error. Destrúyala, corrija la causa y vuelva a desplegar.
Las causas habituales de un fallo de lanzamiento están en la plantilla y no en el hardware: un nombre o una etiqueta de imagen que no existe, o un registro privado con credenciales incorrectas. Una plantilla ssh o jupyter cuya imagen no esté construida sobre la imagen base de Superheat tampoco puede levantarse, porque esos modos dependen del entrypoint de la imagen base.
Un trabajo que llegó a su fin —una plantilla en modo args cuyo comando termina— queda en error con error_code workload_completed. Su GPU se libera de inmediato y no se factura; destrúyala cuando tenga lo que necesita de ella.
Una instancia que nunca llegó a running no tiene registros que leer, así que depure desde la plantilla y no desde la instancia. Solución de problemas recorre los fallos concretos.
No cuesta nada. En cuanto la plataforma ve que su carga de trabajo terminó —falló, se perdió o acabó—, sus GPU vuelven al mercado de inmediato. Un despliegue que falló antes de que su carga de trabajo llegara al host sigue reteniendo el bloque hasta que la instancia se destruye, por usted o automáticamente alrededor de una hora después. En cualquier caso cuenta para el límite de 25 instancias de la organización hasta que se destruye.
Dónde ve los estados
La página Instancias lista todo excepto las instancias destruidas. A través de la API, GET /v1/instances?include_destroyed=true las devuelve.
La página de cada instancia muestra el estado actual como una insignia, solo las acciones que el estado actual permite —Iniciar en una instancia detenida, Detener en una en ejecución, Destruir en todos los estados salvo destroyed— y, una vez que la carga de trabajo está activa, los datos de conexión en su pestaña Conectar. La API devuelve la misma lista como allowed_actions de la instancia.