Servidores dedicados RHEL

Un servidor dedicado RHEL es una máquina física de un solo inquilino que ejecuta Red Hat Enterprise Linux directamente sobre el hardware, sin ninguna capa de virtualización entre tu carga de trabajo y la CPU, la memoria y el NVMe. Obtienes root completo, todos los núcleos y la plataforma certificada y respaldada por soporte contra la que se escriben el software empresarial y los regímenes de cumplimiento.

RHEL se licencia por suscripción en lugar de venderse directamente, así que en bare metal el modelo es trae-tu-propia-licencia (BYOL): asocias tu entitlement de Red Hat existente a la máquina. Si quieres la plataforma RHEL sin una suscripción, AlmaLinux y Rocky Linux son reconstrucciones libres y compatibles con RHEL que aprovisionamos sin coste: los mismos binarios, sin la relación de soporte del proveedor.

¿Sopesando RHEL frente a las reconstrucciones libres? Lee nuestra guía de servidores dedicados Linux.

Cómo se asocia una suscripción de RHEL a un servidor físico

RHEL no es una compra única: el software se habilita mediante una suscripción de Red Hat, y esa suscripción es la que te da acceso a errata certificada, a un SLA de soporte y al ciclo de vida con soporte. En una máquina de Serverside traes la tuya: nosotros desplegamos el SO y te entregamos root, después registras la máquina en tu organización de Red Hat y empieza a traer actualizaciones desde el CDN de Red Hat.

El registro es un único comando —subscription-manager register con el ID de tu organización y una clave de activación—, tras el cual el sistema queda habilitado. El modelo actual de Red Hat es Simple Content Access (SCA), el predeterminado para las cuentas de hoy: una vez que un sistema está registrado tiene acceso al contenido sin un paso de attach explícito, de modo que el antiguo baile de subscription-manager attach ya no hace nada. Ten en cuenta que activar SCA en una organización es un cambio irreversible.

No estás limitado a nuestras imágenes: monta tu propia ISO de instalación de RHEL y ejecuta la instalación tú mismo desde la consola KVM, viendo arrancar el instalador gráfico o de texto exactamente como en el hardware que tienes delante. Es la vía limpia cuando quieres disponer la máquina según tu propio kickstart o tu estándar de particionado antes de asociar tu suscripción de Red Hat: trae tu propio instalador, trae tu propio entitlement.

Cada entitlement está ligado a un sistema, así que un host bare metal consume una suscripción por la máquina física con independencia de cuántos núcleos tenga: una máquina EPYC densa no cuesta más de habilitar que una pequeña. Como tienes root completo y el servidor es no gestionado por defecto, cómo lo registras, qué repositorios habilitas y cómo lo parcheas son enteramente cosa tuya.

Versiones actuales y el ciclo de vida de 10 años

RHEL 10 es la versión mayor actual, disponible de forma general desde mayo de 2025 y construida sobre un kernel y una toolchain modernos. RHEL 9 sigue en soporte completo (Full Support) hasta 2027, con mantenimiento hasta 2032, y RHEL 8 está en su fase de mantenimiento hasta 2029, de modo que las tres son objetivos viables según contra qué certifique tu pila de aplicaciones.

Cada versión mayor de RHEL recibe un ciclo de vida de diez años: unos cinco años de soporte completo (nuevas funcionalidades y habilitación de hardware), luego cinco años de soporte de mantenimiento (seguridad y correcciones de errores urgentes sobre la versión menor final), seguidos de una fase opcional de Extended Life. Esa ventana predecible de una década es una razón central por la que las cargas reguladas y de larga vida estandarizan en RHEL en lugar de en una distribución de movimiento más rápido.

Si necesitas congelar en una versión menor concreta —porque un ISV certifica solo contra, por ejemplo, RHEL 9.4— Extended Update Support (EUS) mantiene una versión menor dada parcheada durante 24 meses, y el flujo E4S orientado a SAP amplía eso a cuatro años. Estos complementos van sobre tu suscripción; el hardware por debajo es la misma máquina que desplegamos en menos de un minuto.

RHEL, AlmaLinux y Rocky tras el cambio de fuentes de 2023

A mediados de 2023 Red Hat convirtió CentOS Stream en el único repositorio público del código fuente relacionado con RHEL, poniendo fin a la práctica anterior de publicar las fuentes por versión en git.centos.org. Los clientes de pago de Red Hat siguen recibiendo las fuentes completas de RHEL a través del Customer Portal; el cambio afectó específicamente a las reconstrucciones downstream que se habían apoyado en esas fuentes públicas para producir copias binarias 1:1.

Las dos grandes reconstrucciones comunitarias respondieron de forma distinta. AlmaLinux desplazó su objetivo de «1:1 bit a bit» a la compatibilidad de interfaz binaria de aplicación (ABI): el software certificado para RHEL sigue funcionando, pero Alma ya no promete paquetes idénticos byte a byte. Rocky Linux, cuyos impulsores ayudaron a formar la Open Enterprise Linux Association (OpenELA) junto a Oracle y SUSE, sigue apuntando a la compatibilidad bit a bit con RHEL a través de fuentes de OpenELA. Ambas son libres, y aprovisionamos cualquiera de las dos sin coste.

Para la mayoría de las cargas autogestionadas, una reconstrucción es la elección pragmática: obtienes la plataforma y el ecosistema de RHEL sin una suscripción. Recurres a la RHEL genuina cuando lo que importa es la relación de soporte, la errata certificada o el visto bueno del proveedor, que es exactamente de lo que trata la siguiente sección.

Cuándo la RHEL de pago supera a una reconstrucción libre, y cuándo no

Las reconstrucciones son compatibles a nivel binario, así que el factor decisivo rara vez es el software en sí: es el papeleo y la relación con el proveedor a su alrededor. La RHEL genuina justifica su suscripción cuando hay un tercero con responsabilidad de por medio:

• Certificación de ISV: SAP, Oracle Database y buena parte del middleware comercial están certificados y con soporte solo en RHEL (o sus variantes SAP/E4S), y los proveedores pueden negarse a solucionar problemas en una reconstrucción
• Regímenes de cumplimiento que exigen un SO con soporte, respaldado por el proveedor, con un SLA y una errata trazable
• Certificación de hardware y plataforma, donde un servidor o acelerador concreto está validado contra RHEL
• Gestión de flotas mediante Red Hat Lightspeed (antes Insights) y Satellite para visibilidad de vulnerabilidades, parcheo y desviación (drift) a escala
• A la inversa: para una capa web autoalojada, hosts de contenedores, runners de CI o herramientas internas, AlmaLinux o Rocky te dan la misma plataforma gratis: sin suscripción que gestionar, una renovación menos

SELinux en modo enforcing por defecto

RHEL se distribuye con SELinux en modo enforcing de serie —control de acceso obligatorio que confina los procesos a una política etiquetada, de modo que un daemon comprometido queda encajonado en lo que su tipo tiene permitido tocar en lugar de heredar los derechos del invocador—. En Debian y Ubuntu la capa equivalente es AppArmor; en RHEL, SELinux es la postura nativa por defecto y las políticas del ecosistema asumen que está activo.

Operativamente, en un servidor dedicado eso significa reservar tiempo para ajustar contextos y booleanos en lugar de ponerlo en permissive por reflejo: etiqueta correctamente tus directorios de datos (restorecon, semanage fcontext), activa los sebooleans pertinentes para servicios como httpd o contenedores, y lee el registro de auditoría (ausearch, sealert) cuando algo se deniega. Dejar SELinux en enforcing es una parte importante de por qué se confía en RHEL en entornos regulados, así que merece la pena mantenerlo activo.

Segmenta la red como espera una auditoría

SELinux confina los procesos en el host; la capa de red confina lo que puede alcanzarlos, y las empresas que usan RHEL suelen necesitar ambas cosas. Puedes poner tus servidores en una red privada entre máquinas y ejecutar un verdadero despliegue multicapa: la capa de aplicación hablando con la capa de base de datos por la interfaz privada, con una interfaz pública solo en el front-end que tiene que dar la cara a los usuarios. La base de datos no necesita tener ninguna dirección pública.

Para una segmentación impulsada por el cumplimiento, puedes definir tu propia DMZ de red: expón solo la capa que debe ser alcanzable y mantén los sistemas internos aislados detrás de ella, que es exactamente la topología que un auditor espera ver documentada cuando tu carga de trabajo lleva obligaciones PCI, HIPAA o similares. Como defines tú mismo la segmentación, la frontera sigue tus controles en lugar de un valor por defecto compartido del proveedor.

Herramientas nativas de RHEL

La superficie de gestión del día a día es la pila de Red Hat que cabría esperar, y todo funciona igual en la RHEL genuina o en una reconstrucción:

• dnf y RPM para la gestión de paquetes y transacciones, con modularidad y application streams
• kpatch, parcheo de kernel en vivo para aplicar CVE críticos del kernel sin reiniciar —soportado desde RHEL 8.1—, que combina bien con un host bare metal de larga actividad
• Image Builder (osbuild) para producir imágenes de SO personalizadas y reproducibles que puedes redesplegar en toda una flota
• Red Hat Lightspeed y Satellite (funciones de suscripción) para avisos, orquestación de parcheo y despliegue de kpatch a escala
• System roles y contenido de Ansible para una configuración repetible en una máquina que es tuya de principio a fin