Cómo un micro-MSP checo reemplazó la reventa de AWS con Apache CloudStack para aumentar los márgenes de hosting del 5% al 60%

4

Leer 17 min.

Cuando una empresa no vende servidores, sino el resultado —los sistemas operativos de los clientes—, su infraestructura debe tener unos costes predecibles y poder gestionarse sin trabajo manual innecesario. Este caso práctico muestra cómo un proveedor de servicios de TI gestionados de la República Checa trasladó los sistemas de sus clientes de un hiperescalador a un único servidor dedicado alquilado con una nube privada Apache CloudStack. La empresa consiguió una factura fija, el aislamiento de los clientes y un seguimiento integrado del uso, al tiempo que redujo los costes de infraestructura entre cuatro y cinco veces.

Contexto

El cliente es un proveedor de servicios de TI gestionados de la República Checa. La empresa presta servicio a varias docenas de clientes B2B de la región y gestiona todo su entorno de TI: soporte técnico para estaciones de trabajo y servidores, copias de seguridad, supervisión, correo electrónico, sistemas de contabilidad, VPN y aplicaciones internas. Los recursos informáticos son una herramienta más que un producto: los sistemas de los clientes se ejecutan en máquinas virtuales, y el proveedor de servicios gestionados (MSP) se hace responsable de ellos en virtud de los contratos de soporte.

Los sistemas del lado del servidor de los clientes estaban alojados en la nube pública de AWS en la región de Fráncfort. El MSP aprovisionaba la infraestructura por separado para cada cliente e incluía su coste en la cuota mensual de soporte con un margen de beneficio de aproximadamente el 5 % de media, según el cliente.

Objetivos y resultados

Los objetivos del proyecto piloto eran:

El problema

Para el MSP, la infraestructura de la nube pública era un coste de traspaso. La factura constaba de docenas de partidas y variaba de un mes a otro: tarifas por hora por CPU y memoria, tarifas separadas por tráfico saliente, almacenamiento e instantáneas. Era imposible comunicar al cliente el importe exacto antes de que acabara el mes. Los cambios en los precios los asumía el MSP, mientras que los beneficios de la parte de los contratos correspondiente a la infraestructura se limitaban a un margen de beneficio de aproximadamente el 5 %.

El segundo problema era la gestión. Algunos clientes querían crear, detener y revertir sus propias máquinas virtuales sin ponerse en contacto con los empleados del MSP. Dar a los clientes acceso a la infraestructura de nube compartida del MSP era inaceptable, mientras que las cuentas independientes para cada cliente requerían configuraciones de permisos individuales, facturación separada y contabilidad independiente para cada cliente.

El MSP se puso en contacto con INTROSERV para solicitar un proyecto piloto: alquilar un servidor dedicado en un centro de datos europeo e implementar en él una nube privada lista para usar como sustituto del hiperescalador para los sistemas típicos de los clientes, con la opción de ampliarla a varios nodos más adelante.

Configuración de la infraestructura

INTROSERV proporcionó un servidor dedicado alojado en un centro de datos de nivel III en los Países Bajos con una disponibilidad de red garantizada del 99,99 %.

Servidor principal:

• CPU: 2 procesadores Intel Xeon Gold 6130 — 32 núcleos físicos, 64 hilos, frecuencia base de 2,10 GHz, turbo de hasta 3,70 GHz

• RAM: 256 GB REG ECC DDR4, ampliable hasta 1 TB

• NVMe: 2 x 3,84 TB en RAID 1 por software — 3,84 TB de almacenamiento local para discos de máquinas virtuales

• SATA: 4 x 14 TB en RAID 10 por software — 28 TB para copias de seguridad y almacenamiento secundario

• Red: dos puertos de 25 Gbps, tráfico ilimitado; red VLAN privada de 10 Gbps

• Gestión: iDRAC

• Protección contra DDoS: 20 Gbps

• Fuente de alimentación redundante

Un servidor de respaldo para máquinas virtuales está conectado al servidor principal a través de una red VLAN privada de 10 Gbps.

El servicio de copia de seguridad de INTROSERV, basado en NAKIVO Backup & Replication, cuesta 49 € al mes por 5 TB. Se realiza una copia de seguridad de todo el servidor: el sistema operativo del host, la configuración de CloudStack y la base de datos del servidor de gestión. Si el servidor falla, el sistema se implementa en un nuevo hardware a partir de esta copia de seguridad, tras lo cual se restauran las máquinas virtuales desde el servidor de copias de seguridad.

La configuración cumple los requisitos de tolerancia a fallos a nivel de una sola máquina:

• Red: dos puertos independientes de 25 Gbps se agrupan en un enlace tolerante a fallos. El fallo de un puerto o enlace no interrumpe el funcionamiento de las máquinas virtuales.
• Alimentación: dos fuentes de alimentación. El fallo de una de ellas no provoca el apagado del servidor.
• Discos: todas las unidades están configuradas en matrices RAID. El fallo de una unidad NVMe o SATA no provoca pérdida de datos ni tiempo de inactividad del servidor.
• Almacenamiento: los discos de las máquinas virtuales se almacenan en una matriz NVMe local, sin almacenamiento en red entre el hipervisor y los datos. Esto proporciona una latencia de E/S mínima para las bases de datos y los sistemas de contabilidad de los clientes.
• Copias de seguridad: las copias de seguridad de las máquinas virtuales se transfieren a un servidor físico independiente a través de una red privada de 10 Gbps, sin utilizar puertos externos ni incurrir en costes de tráfico. Se almacena una copia de seguridad completa del servidor en el almacenamiento del servicio de copias de seguridad de 5 TB.

La factura del servidor cubre todo lo que un hiperescalador cobraría por separado: tráfico, red y alimentación redundantes, tolerancia a fallos de disco, almacenamiento local de alta velocidad, una red privada al servidor de copias de seguridad y gestión remota a través de iDRAC. Las dos partidas relacionadas con las copias de seguridad son partidas de coste fijo.

La solución

El equipo de INTROSERV implementó Apache CloudStack en el servidor con una configuración de un solo nodo: el servidor de gestión y el host KVM se ejecutan en la misma máquina. El trabajo se llevó a cabo como parte de un servicio de administración de sistemas por horas, tras lo cual la gestión de la plataforma pasó a manos del cliente.

¿Por qué Apache CloudStack en lugar de Proxmox VE?

Ambas plataformas son de código abierto y se ejecutan en KVM. Proxmox VE se distribuye bajo la licencia AGPLv3 y funciona de forma gratuita; solo se requiere una suscripción de pago por zócalo de CPU para acceder al repositorio de actualizaciones empresariales y al soporte técnico del proveedor. Apache CloudStack se distribuye bajo la Licencia Apache 2.0 sin cuotas por zócalos, núcleos o máquinas virtuales. La licencia no fue el factor decisivo. Los factores clave fueron cuatro funciones integradas en CloudStack que requieren herramientas externas en Proxmox VE:

• Multitenencia. Dominios, cuentas y proyectos con límites de recursos y cuotas para cada cliente. Los clientes que deseaban gestionar su propio parque de máquinas virtuales recibían su propia cuenta con un rol específico: solo pueden ver sus propios recursos, crear y detener máquinas virtuales, así como realizar instantáneas y reversiones dentro de la cuota que se les ha asignado. La aplicación de las cuotas la gestiona la plataforma, en lugar de mediante un proceso manual.
• Seguimiento del uso. El servidor de uso integrado registra el consumo de CPU, memoria, disco y tráfico de cada cuenta; el complemento de cuotas mantiene los saldos en función de los planes de precios. Los datos para los cálculos de costes internos y la facturación a los clientes se obtienen directamente de la plataforma, en lugar de recopilarse manualmente.
• Kubernetes. El servicio CloudStack Kubernetes implementa y actualiza clústeres de Kubernetes para los clientes desde la consola o a través de la API, con escalado de nodos y la posibilidad de conectar discos de CloudStack como volúmenes del clúster. Los clientes que ejecutan aplicaciones en contenedores reciben un clúster sin necesidad de una plataforma independiente.
• Servicios de red. Redes aisladas con un enrutador virtual para cada cliente: cortafuegos, NAT, equilibrio de carga y VPN.

Añadir un nuevo cliente se ha convertido en una operación estandarizada: crear un dominio y una cuenta, una red aislada con un router virtual, una cuota y máquinas virtuales a partir de una plantilla ya preparada. Todo se puede realizar desde la consola o a través de la API y el proveedor de Terraform en cuestión de minutos, en lugar de las horas que requiere la configuración manual en la consola de un hiperescalador. Las instantáneas proporcionan puntos de restauración antes de las actualizaciones del sistema del cliente, mientras que las plantillas ofrecen imágenes base idénticas para todos los clientes.

Nivel de tolerancia a fallos

La disponibilidad del sistema es importante para los clientes del MSP, pero la carga de trabajo —sistemas de contabilidad, correo electrónico y aplicaciones internas— no requiere una alta disponibilidad con reinicio automático de la máquina virtual en otro host en cuestión de minutos. El primer grupo de clientes no cuenta con sistemas de funcionamiento continuo en los que varias horas de inactividad supongan pérdidas directas; para ellos, es aceptable una ventana de mantenimiento planificada o la recuperación a partir de una copia de seguridad.

Por lo tanto, se consideró que un clúster de alta disponibilidad era excesivo para la fase piloto: requiere múltiples nodos y almacenamiento compartido. Se seleccionó un único nodo con redundancia a nivel de máquina, y esta configuración resultó ser suficiente. Los fallos de los componentes se cubren a nivel de hardware: dos puertos de 25 Gbps agrupados, dos fuentes de alimentación y todos los discos en matrices RAID. La degradación de las matrices y la insuficiencia de recursos del host se supervisan de forma proactiva, y las unidades se sustituyen antes de que un problema afecte a las máquinas virtuales.

Un fallo completo del servidor queda cubierto por dos niveles de copias de seguridad: la copia de seguridad del host en NAKIVO restaura el sistema operativo y CloudStack en un nuevo servidor sin necesidad de reconfiguración, mientras que las copias de seguridad de las máquinas virtuales restablecen el funcionamiento de los sistemas de los clientes. Se ha previsto una alta disponibilidad para la fase de expansión, cuando la infraestructura crezca hasta abarcar varios nodos: se añadirán hosts adicionales al mismo CloudStack sin cambiar de plataforma.

Trabajo realizado

1. Preparación del servidor: instalación del sistema operativo, matrices RAID de software (RAID 1 en NVMe, RAID 10 en SATA), agrupación de dos puertos de 25 Gbps en un enlace tolerante a fallos y configuración de una red VLAN privada hacia el servidor de copias de seguridad.

2.Instalación del servidor de gestión de CloudStack y del agente KVM en un único nodo, configuración de la base de datos y de las máquinas virtuales del sistema.

3. Creación de la zona, el pod y el clúster; almacenamiento primario en la matriz NVMe y almacenamiento secundario en la matriz SATA.

4. Modelo de red: redes aisladas con un enrutador virtual para cada cliente, un rango de direcciones IP públicas, reglas de cortafuegos y NAT.

5. Plantillas de sistema operativo (Ubuntu, Debian, AlmaLinux, Windows Server) y ofertas de servicios para tres tamaños estándar de máquinas virtuales.

6. Copia de seguridad de las máquinas virtuales en un servidor de copias de seguridad independiente a través de una red privada de 10 Gbps; conexión del servidor al servicio de copias de seguridad de INTROSERV basado en NAKIVO, con una programación para realizar copias de seguridad completas del servidor.

7. Dominios y cuentas para clientes MSP, roles y límites de recursos, activación del servidor de uso y del complemento de cuotas; activación del servicio CloudStack Kubernetes y registro de imágenes ISO que contienen binarios de Kubernetes.

8. Supervisión proactiva: estado del sistema operativo del host (CPU, memoria, espacio en disco, interfaces de red, servicios del sistema) y matrices de discos (estado RAID, métricas SMART de las unidades), con notificaciones enviadas a los ingenieros de INTROSERV.

9. Pruebas: máquinas virtuales de prueba de los tres tamaños, instantáneas y reversiones, acceso a la red externa, pruebas de copias de seguridad de máquinas virtuales y pruebas de copias de seguridad completas del servidor.

10. Entrega al cliente: consola de CloudStack, claves de API, documentación de configuración y acceso a iDRAC.

El alcance total del trabajo fue de 16 horas. Tras la entrega, INTROSERV proporciona asistencia en función de las alertas de supervisión o de las solicitudes de los clientes: sustitución de unidades, actualizaciones del hipervisor y del servidor de gestión, y ampliación de la configuración.

Ubicación de máquinas virtuales

Durante la fase piloto, se migraron al nodo 20 máquinas virtuales que dan soporte a los sistemas de los clientes, distribuidas en tres tamaños estándar. La memoria se asigna sin sobreasignación: quedan 64 GB disponibles para el servidor de gestión, las máquinas virtuales del sistema y los siguientes sistemas de los clientes. Todos los discos de las máquinas virtuales se encuentran en la matriz NVMe local del servidor, lo que proporciona a cada máquina virtual el rendimiento de disco que habría requerido un cargo adicional según la política de precios de almacenamiento del hiperescalador para garantizar las IOPS.

Las CPU virtuales se asignan con un sobreasignamiento mínimo —72 vCPU para 64 subprocesos—, mientras que la utilización real de la CPU durante el horario laboral no supera el 50 %. Quedan aproximadamente 700 GB libres en la matriz NVMe. El proyecto es piloto, y esta reserva de capacidad fue intencionada: se pueden añadir sistemas de clientes adicionales al mismo nodo sin cambiar la configuración, mientras que ampliar la memoria a 1 TB y añadir unidades multiplica varias veces la capacidad del nodo.

La infraestructura como ventaja estratégica

La solución implementada por el equipo de INTROSERV sustituyó al hiperescalador como proveedor de recursos informáticos para los sistemas de los clientes del MSP. Un único servidor alquilado con Apache CloudStack se hizo cargo del primer grupo de 20 máquinas virtuales con margen de crecimiento y un nivel de tolerancia a fallos adecuado a la carga de trabajo.

El cliente obtuvo capacidades que no estaban disponibles en la nube pública: aislamiento de clientes y seguimiento del uso a nivel de plataforma, autoservicio para clientes con sus propias cuentas, clústeres de Kubernetes desde la misma consola y supervisión proactiva del host y de las matrices de discos. La redundancia de red y alimentación, los discos protegidos por RAID, el almacenamiento NVMe local, los puertos ilimitados de 25 Gbps y la protección contra DDoS están incluidos en el coste del servidor.

Aspectos económicos

La mayor parte del tráfico pasa por los servidores VPN de los clientes: el tráfico saliente del nodo es de entre 20 y 35 TB al mes. Un conjunto equivalente de recursos del proveedor anterior —20 máquinas virtuales con el mismo perfil, almacenamiento, instantáneas y este volumen de tráfico saliente a las tarifas actuales de la región de Fráncfort— cuesta aproximadamente entre 4.000 y 5.100 € al mes, es decir, unos 54.000 € al año. Entre 1 500 y 2 600 € de esta cantidad corresponden al tráfico: en el hiperescalador, cada gigabyte enviado a través de la VPN a los empleados de los clientes se cobra por separado.

INTROSERV cuesta 1.017 € al mes: 671 € por el servidor principal, 157 € por el servidor de copia de seguridad, 49 € por la copia de seguridad completa del servidor, y el resto cubre la administración bajo demanda y la amortización de la implementación inicial. El alquiler del servidor incluye dos puertos de 25 Gbps con tráfico ilimitado, por lo que el tráfico saliente generado por los sistemas de los clientes no afecta a la factura, ya sea de 35 o de 50 TB al mes.

La base de costes es entre cuatro y cinco veces inferior, la cantidad es fija y se conoce antes de que comience el mes. Esto permitió al cliente incluir la infraestructura en una cuota de soporte fija, ofrecer a sus clientes condiciones más favorables y aumentar la rentabilidad de la parte de infraestructura de sus contratos. A medida que crece la cartera de clientes, la diferencia con respecto a los hiperescaladores aumenta: la factura de los servidores no depende del tráfico ni de los cambios en los precios de las instancias. El cliente quedó plenamente satisfecho con el coste de la solución.

Próximos pasos

La plataforma abierta sin cuotas de licencia resolvió la cuestión del escalado: ampliar la memoria a 1 TB multiplica varias veces la capacidad del nodo, mientras que se puede añadir un segundo nodo al clúster de CloudStack existente sin cambiar de herramientas. Los datos de los clientes permanecen en servidores dedicados en un centro de datos europeo, dentro de un perímetro controlado por el cliente. Para una empresa que presta servicio a clientes de la UE bajo los requisitos del RGPD, esta es una condición obligatoria. Tras la fase piloto, el MSP decidirá si migra grupos adicionales de sistemas de clientes a CloudStack.

¿Tu infraestructura te cuesta más de lo que debería en un hiperescalador, mientras que la factura sigue siendo imposible de predecir? Confía la migración al equipo de INTROSERV: seleccionaremos la configuración de servidor adecuada, implementaremos Apache CloudStack y te entregaremos una nube privada lista para usar .