Resumen

  • La guía RHEL incluye la réplica activa, síncrona o asíncrona, de volúmenes entre sistemas en la recuperación en caliente, que requiere suscripciones de pago.
  • OpenShift autogestionado mantiene una regla propia para la réplica mediante almacenamiento externo y separa mantenimiento, pruebas y ejecución de cargas. Las etiquetas de reserva no sustituyen al diseño.

Apagar la actividad visible de un clúster parece una forma sencilla de adelgazar la factura. La guía de OpenShift autogestionado tiene una respuesta más exigente: un clúster en hibernación que no esté diseñado y configurado expresamente para recuperación templada o fría sigue necesitando suscripciones. El documento cita los clústeres de nube que descansan temporalmente porque ha caído la demanda.

La distinción pone orden en una discusión comercial. Menos uso, capacidad de reserva y recuperación ante desastres describen decisiones diferentes. La casilla «inactivo» puede ahorrar explicaciones en una presentación; para comprar software resulta demasiado espaciosa.

La copia ya está haciendo un trabajo

La guía RHEL de Red Hat, fechada el 21 de julio de 2026, considera calientes los sistemas con réplica activa de volúmenes, tanto síncrona como asíncrona. En su clasificación de recuperación, el respaldo caliente requiere suscripciones de pago. Recibir tráfico normal de clientes deja de ser la única pregunta útil.

El respaldo caliente funciona en paralelo con la producción y está preparado para recibir tráfico inmediatamente si falla el entorno principal. El templado está preparado para alojar cargas semejantes, pero carece de cargas de clientes procedentes del origen y no debe participar en réplica activa de volúmenes. Para recuperar necesita restaurar datos desde fuera del sistema de origen sobre hardware existente. Al frío todavía le falta parte de la tecnología necesaria para restablecer el servicio.

Las suscripciones del entorno principal pueden trasladarse al templado o frío cuando ocurre el desastre. Quedan por ejecutar la restauración, el arranque y la recuperación del servicio. Trasladar un derecho de uso y volver a trabajar son hitos distintos.

El comprador elige cuánto trabajo prepara ahora y cuánto deja para después. Una réplica alimentada durante la operación principal compra preparación. Una restauración posterior consume personas, secuencia y tiempo cuando se activa. Si compras solo ve la suscripción y operaciones solo ve la tarea pendiente, cada departamento puede optimizar su fila mientras la empresa pierde la comparación.

OpenShift mira dónde vive la réplica

La guía de OpenShift autogestionado, del 23 de enero de 2026, también exige suscripciones de pago para recuperación caliente. Describe la réplica activa entre clústeres mediante almacenamiento definido por software alojado en OpenShift. Su regla de respaldo templado contempla asimismo que el destino monte los datos replicados en cargas de contenedores activas.

La réplica realizada por dispositivos de almacenamiento externos sigue siendo templada en esa guía. Para recuperar en templado con almacenamiento definido por software alojado en OpenShift, los datos deben restaurarse desde fuera del clúster sobre el hardware ya disponible.

La ubicación es así una variable de compra. Una propuesta con almacenamiento externo debe sumar ese almacenamiento y su operación, además de las condiciones de la plataforma. Contar servidores y multiplicar una tarifa imaginaria borraría precisamente la diferencia publicada.

La regla de almacenamiento externo de OpenShift pertenece a ese producto. Pasarla a RHEL por compartir proveedor mezclaría ámbitos; clasificar toda réplica de cualquier producto como caliente eliminaría la excepción. El sombrero rojo puede viajar entre las diapositivas. Las condiciones necesitan llevar su apellido.

Despertar para ensayar tiene otra función

Cuando los clústeres templados o fríos de OpenShift se despiertan para ejecutar cargas, requieren suscripciones. Si se despiertan temporalmente para mantenimiento rutinario o pruebas, la guía no pide una suscripción adicional para los componentes de las ofertas de software OpenShift.

Ese espacio permite mantener y ensayar la reserva. La prueba debe revelar qué falta después de activar: recuperar datos, montar almacenamiento, iniciar aplicaciones y comprobar el servicio. Una máquina inmóvil puede quedar muy bien en el presupuesto y guardar intactas todas las sorpresas.

También hace falta identificar el propósito real del arranque. La provisión de mantenimiento y pruebas tiene un alcance concreto. No incluye por arte de vocabulario cualquier carga que alguien prefiera llamar ensayo.

Faltan el recorrido real de almacenamiento y cargas del comprador, sus tiempos de recuperación medidos y la oferta aplicable; esos datos pueden cambiar qué diseño sale mejor.

El cálculo debe reunir preparación, trabajo diferido, infraestructura externa y tolerancia a la interrupción. Desactivar protección para reducir solo la línea de suscripción cambia la apuesta operativa al mismo tiempo. La persona que responde por el servicio tiene que participar en esa elección.

La compra útil es una capacidad de volver a funcionar. Parte se paga antes y parte se ejecuta después. Un sistema puede ser barato mientras espera y caro en el único momento para el que fue adquirido.

Fuentes