Red Hat plantea tres rutas para modernizar SQL Server: RHEL, VMs y contenedores

Red Hat ha publicado un análisis sobre la modernización de Microsoft SQL Server en el que sostiene que no hay una única decisión técnica correcta. La empresa describe tres rutas —ejecutar el motor directamente sobre Red Hat Enterprise Linux, trasladar las máquinas virtuales existentes a OpenShift Virtualization o desplegarlo en contenedores gestionados por OpenShift— y subraya que no compiten entre sí: se puede empezar por una y pasar a otra después.

Tres caminos que no se excluyen

La primera ruta es la más conservadora. Mantiene el modelo de servidor tradicional y no introduce Kubernetes: SQL Server corre sobre RHEL como base Linux soportada, y Microsoft da soporte a despliegues de producción del motor en esa distribución. Encaja en organizaciones que quieren estandarizar su infraestructura en Linux sin añadir una plataforma de orquestación.

La segunda ataca el parque instalado. Muchas empresas arrastran bases de datos en máquinas virtuales atadas a aplicaciones antiguas y a requisitos de disponibilidad que se han ido acumulando durante años. OpenShift Virtualization permite crear, desplegar y gestionar esas VM desde OpenShift, compartiendo plataforma con las cargas en contenedores. Red Hat lo plantea como un primer paso: una vez allí, cada base de datos decide si se queda en la VM o se migra más adelante. No obliga a transformar todo el parque a la vez.

La tercera es la más cercana al modelo de nube nativa. SQL Server sobre Linux puede correr en contenedores o pods bajo OpenShift, que se encarga del despliegue, la seguridad y el ciclo de vida. Meter una base de datos en una imagen no basta: hay que resolver alta disponibilidad, datos persistentes, configuración, red, failover y gestión del ciclo de vida.

Contenedores con operador

Ahí entra DH2i. Su DxOperator automatiza en Kubernetes el ciclo de vida de los grupos de disponibilidad Always On de SQL Server, despliega los contenedores y los configura, mientras DxEnterprise aporta el clustering y la alta disponibilidad por debajo. DxOperator está certificado para OpenShift y, según el artículo, Microsoft lo señala como el operador preferido para despliegues de SQL Server en Kubernetes. La afirmación es de las partes implicadas, no de un tercero independiente.

Hay además un catálogo de SQL Server para RHEL para quien quiera revisar las imágenes soportadas.

Red Hat enumera los factores que deberían decidir la ruta: arquitectura y antigüedad de la aplicación, tamaño y complejidad del parque de SQL Server, requisitos de disponibilidad y recuperación, los conocimientos de Linux, virtualización y Kubernetes del equipo, licencias y coste total, el apetito de cambio operativo y el tiempo disponible para la migración.

Nada de esto es el anuncio de un producto: es el argumento comercial de Red Hat, que gana si el parque acaba en RHEL u OpenShift. Lo aprovechable para quien administra estas bases es el recordatorio de que virtualización y contenedores pueden convivir en la misma migración, y que el operador —con sus certificaciones y su soporte— pesa tanto como la decisión de empaquetar SQL Server en un contenedor.