Copy page

Unidades

Políticas fija y autoescalada

La política de escalado de un Workload decide cuántas unidades se ejecutan. Un Workload al que nunca se le dio una política es fixed con una unidad.

Fija

fixed significa "ejecuta exactamente N unidades". Cambias N tú mismo y se aplica al instante: subirlo arranca unidades, bajarlo las elimina.

Usa fixed cuando sabes cuánta capacidad quieres, cuando quieres alta disponibilidad con un número constante de copias (por ejemplo dos, para que una pueda reiniciarse mientras la otra responde), o cuando quieres una factura predecible.

En la API una política fija tiene min_units igual a max_units. Si envías solo uno de los dos, el otro se iguala.

Autoescalada

autoescalada (autoscaled) significa "ejecuta entre min_units y max_units, y deja que Zaroz se mueva dentro de ese rango". Tú eliges qué la gobierna. Hace falta al menos una de estas:

• Un objetivo de CPU, como porcentaje de la CPU que puede usar cada unidad (cpu_target_percent).
• Un objetivo de memoria (memory_target_percent).
• Una regla de horario: una expresión cron de cinco campos, una zona horaria y unos nuevos límites que entran en vigor cuando se dispara y se mantienen hasta que se dispara la siguiente regla.

Cómo se elige el número

Cada unos 30 segundos Zaroz mira la carga media de tus unidades listas y calcula cuántas unidades devolverían la carga al objetivo:

Code
deseadas = ceil(unidades actuales x carga actual / objetivo)

Ejemplo: hay 2 unidades al 95 % de CPU con un objetivo del 60 %. ceil(2 x 95 / 60) = ceil(3,17) = 4, así que la política pide 4 unidades. Si fijas objetivos de CPU y de memoria, gana la respuesta mayor. El resultado siempre se mantiene dentro de min_units y max_units.

Una banda de alrededor del 10 % en torno al objetivo cuenta como "suficientemente cerca" y no cambia nada, para que el número no oscile.

Para que no oscile

Dos ajustes mantienen estable el número:

• scale_up_cooldown_seconds: tras añadir unidades, espera este tiempo antes de añadir más.
• scale_down_stabilisation_seconds: solo quita unidades cuando el número menor ha bastado durante este tiempo.

Subir es rápido a propósito; bajar es lento a propósito.

Un tope de gasto

spend_cap_cents es lo máximo, en céntimos, que pueden costar las unidades extra en un mes natural. Al llegar o pasarlo, el escalado se niega a crecer. Las unidades en marcha nunca se matan por el tope, así que la factura puede pasarse como mucho por lo que crezca un solo paso de evaluación (unos 30 segundos de las unidades añadidas en ese paso).

Cada decisión queda anotada

Cada vez que el evaluador cambia el número, o decide no hacerlo, registra una decisión con una frase clara: qué pasó y por qué. Por ejemplo "Scaled 2 to 4: CPU at 95% against a 60% target". Los motivos incluyen cpu_high, cpu_low, memory_high, schedule, cooldown, stabilising, spend_cap, org_limit, no_capacity, at_max y metrics_unavailable. Las decisiones idénticas consecutivas se pliegan en una sola entrada con un contador de repeticiones. Las decisiones se guardan 30 días y la consola las muestra como marcas en la gráfica del número de unidades.

Mira antes de confirmar

POST .../units/policy/quote recibe el mismo cuerpo que la actualización y devuelve lo que podría costar la política en el peor caso, sin guardar nada. Úsalo antes de cada cambio que suba max_units. La guía de escalado lo muestra.

Cambiar la política

• Cambiar una política con el Workload parado está permitido y se aplica al arrancarlo.
• Parar un Workload para todas sus unidades; arrancarlo las devuelve.
• Un cambio de plantilla (una imagen nueva, ajustes nuevos) llega a las unidades mediante un despliegue progresivo (rolling), de una en una, para que el Workload siga respondiendo.
• max_units nunca puede superar lo que permite el producto ni lo que permite el límite de tu organización (mira Límites).