La pregunta que más recibimos no es técnica. Es «¿cuántas suscripciones necesito comprar?». Y la respuesta honesta es que casi todo el mundo la calcula mal la primera vez, en las dos direcciones: unos compran de más por miedo, otros de menos y quedan expuestos en una auditoría.
Nota: esto es el criterio general. Tu contrato de partner y la documentación vigente de Red Hat mandan siempre. Verificá cada punto contra tu acuerdo antes de dimensionar.
Qué se cuenta
No se cuentan usuarios ni aplicaciones. Se cuenta capacidad de cómputo de los nodos worker. Los nodos de control no entran en la cuenta.
Cores físicos, no hilos
El error número uno: contar vCPUs o hilos de hyper-threading. Se cuentan cores físicos. Un servidor de 2×16 cores son 32, no 64.
Bare metal vs. virtualizado
Cambia la cuenta y cambia el precio por unidad. Si corrés OpenShift sobre un hipervisor, el criterio de conteo es distinto que sobre metal desnudo. Definilo antes de dimensionar, no después.
La suscripción es por capacidad, no por uso
Cubrís el hardware que tenés disponible para la plataforma, esté al 20% o al 90%. Por eso el sobredimensionamiento de infraestructura se paga dos veces.
Producción y no-producción
Acá está el ahorro que más se pasa por alto. Los entornos de desarrollo y prueba tienen caminos de licenciamiento distintos al de producción. Si estás pagando dev igual que prod, revisalo esta semana.
Los niveles de soporte cuestan distinto
Standard y Premium no son lo mismo, y la diferencia real está en el tiempo de respuesta y en la cobertura horaria. No lo elijas por default: elegilo por tu ventana de criticidad.
El error caro: dimensionar por el pico
Mucha gente licencia para el peor día del año. Casi siempre conviene licenciar para la operación normal y tener un camino de expansión acordado de antemano.
¿Querés que revisemos tu cuenta con tu inventario a la vista? Si estás pagando de más te lo decimos, aunque vendamos la suscripción. Coordiná 30 minutos.