Hiperconvergencia: Qué Es y Cuándo Tiene Sentido

La hiperconvergencia lleva años vendiéndose como el futuro del centro de datos, y como todo lo que se vende así, funciona muy bien en unos escenarios y sale cara en otros. La decisión no es tecnológica: es de tamaño, de crecimiento previsto y de cómo es vuestro equipo de sistemas.

Este artículo explica qué es en términos comprensibles, qué problema resuelve de verdad y en qué casos es mejor no meterse.

El modelo tradicional: tres capas

Durante veinte años, una infraestructura virtualizada seria se ha montado con tres piezas separadas:

1. Servidores que aportan CPU y memoria.
2. Una cabina de almacenamiento (SAN) que aporta los discos.
3. Una red de almacenamiento —fibra o iSCSI— que une las dos cosas.

Funciona, es sólida y está muy probada. Sus inconvenientes: son tres tecnologías distintas con tres consolas, tres contratos de soporte y, muchas veces, tres proveedores que se señalan entre ellos cuando algo va lento. Y la cabina es un punto de concentración de riesgo y de coste: se compra grande «para que dure», con lo que se paga por adelantado capacidad que no se usará hasta dentro de tres años.

Qué es la hiperconvergencia

La hiperconvergencia —o HCI, *Hyper-Converged Infrastructure*— elimina la cabina. Los discos vuelven al interior de los servidores, y una capa de software convierte el almacenamiento local de todos los nodos en un único almacén compartido y replicado entre ellos.

El resultado es un clúster de nodos idénticos donde cada uno aporta a la vez cómputo y almacenamiento, gestionado desde una sola consola.

	Tres capas	Hiperconvergencia
Almacenamiento	Cabina externa (SAN)	Discos internos de los nodos
Escalado	Por capas, independiente	Por nodos completos
Gestión	Varias consolas	Una sola
Compra inicial	Grande, dimensionada a futuro	Menor, se amplía nodo a nodo
Especialización necesaria	Alta (SAN, fibra, virtualización)	Menor
Rendimiento máximo	Muy alto y ajustable	Alto, con menos margen de ajuste

Qué resuelve de verdad

• Simplifica la operación. Una consola, un fabricante, un soporte. Para un equipo de sistemas pequeño, esto no es un detalle: es la diferencia entre poder mantenerlo y depender siempre de terceros.
• Escala de forma predecible. ¿Necesitas más? Añades un nodo. El crecimiento es lineal y fácil de presupuestar, sin el salto de coste que supone cambiar de cabina.
• Reduce la inversión inicial. Se compra lo que hace falta ahora en lugar de dimensionar a cinco años vista.
• Acorta los despliegues. Un clúster HCI se pone en marcha en días, no en semanas.
• Facilita el disaster recovery. La replicación entre ubicaciones suele venir integrada en la propia plataforma.

Cuándo NO compensa

Aquí es donde conviene ser honesto, porque es lo que no cuenta ningún folleto:

• Cargas de trabajo muy desequilibradas. Si necesitas mucha capacidad de disco y poca CPU —un archivo documental grande, videovigilancia—, la hiperconvergencia te obliga a comprar nodos completos, con procesadores y licencias que no vas a usar. Sale caro.
• Entornos muy pequeños. Por debajo de tres nodos, la mayoría de plataformas pierden sus garantías de redundancia. Para dos servidores y diez máquinas virtuales, un clúster tradicional o incluso un par de servidores con réplica es más sensato.
• Rendimiento extremo con requisitos muy específicos. Una base de datos con exigencias de latencia muy concretas puede seguir necesitando una cabina con la que se pueda afinar cada parámetro.
• Si ya tenéis una cabina reciente y amortizándose. Tirar una SAN de dos años para adoptar HCI raramente sale a cuenta.
• Presupuesto ajustado en licencias. El software de HCI se licencia y no es barato. En clústeres grandes, el coste de licenciamiento puede superar al ahorro de hardware.

Lo que hay que mirar antes de decidir

• El factor de replicación. El almacén distribuido guarda cada dato en dos o tres nodos. Eso significa que de la capacidad bruta instalada usarás aproximadamente la mitad o un tercio. Es la sorpresa más frecuente al comparar presupuestos: no compares terabytes brutos, compara capacidad útil.
• El modelo de licenciamiento. Por nodo, por socket, por núcleo o por capacidad. Cambia mucho el coste total y ha sido un terreno movido en los últimos años.
• Qué pasa al perder un nodo. El clúster tiene que seguir funcionando y tener espacio para reconstruir la redundancia. Hay que dejar ese margen libre de serie.
• La red. La hiperconvergencia mueve mucho tráfico entre nodos. 10 GbE es el punto de partida razonable, con conmutadores redundados. Escatimar aquí arruina el proyecto.
• El bloqueo con el fabricante. Salir de una plataforma HCI es más costoso que salir de una cabina, porque el formato del almacén es propietario.
• La ruta de actualización. Cómo se actualiza el clúster sin parar servicio y durante cuántos años habrá soporte.

Cómo elegir entre HCI y tres capas

Una regla práctica, sin entrar en marcas:

Tu situación	Opción más razonable
3-8 nodos, cargas mixtas, equipo pequeño	Hiperconvergencia
Crecimiento gradual y difícil de predecir	Hiperconvergencia
Delegaciones remotas con poco personal técnico	Hiperconvergencia
Necesidad de mucha capacidad y poca CPU	Tres capas
Cabina reciente sin amortizar	Tres capas
Bases de datos con latencia crítica	Tres capas o híbrido
Menos de tres nodos	Ni una ni otra: servidores con réplica

Cómo se comporta la hiperconvergencia cuando algo falla

Es la pregunta que más importa y la que menos se hace en la fase comercial. Estos son los escenarios reales:

Qué falla	Qué pasa en un clúster HCI
Un disco	El almacén distribuido reconstruye la redundancia usando espacio libre del resto de nodos
Un nodo completo	Las máquinas virtuales se reinician en los nodos restantes; el clúster queda degradado
Dos nodos a la vez	Depende del factor de replicación: con réplica doble puede haber pérdida
La red entre nodos	El peor escenario: riesgo de *split brain* si no hay red redundada
El clúster entero	Solo se recupera desde la copia de seguridad, como en cualquier infraestructura

De esa tabla se deducen dos reglas de diseño que conviene no negociar. La primera: la red entre nodos se redunda siempre, con dos conmutadores y doble enlace por nodo. Un clúster de hiperconvergencia con un único conmutador es un punto único de fallo disfrazado de alta disponibilidad.

La segunda: hay que reservar capacidad libre equivalente, como mínimo, a un nodo entero. Si el clúster está lleno al 90 %, cuando caiga un nodo no habrá espacio para reconstruir la redundancia y quedarás operando sin protección hasta que llegue el repuesto.

Qué preguntar al proveedor antes de firmar

1. ¿Cuál es la capacidad útil real tras aplicar el factor de replicación y el margen de reconstrucción?
2. ¿Cómo se licencia y qué pasa con el coste si añado un nodo dentro de dos años?
3. ¿Qué red exige la plataforma y está incluida en el presupuesto?
4. ¿Cómo se actualiza el clúster sin parar servicio, y cada cuánto?
5. ¿Cuántos años de soporte tiene el hardware propuesto y qué cuesta renovarlo?
6. ¿Qué pasa si quiero salir? Cómo se exportan las máquinas virtuales a otra plataforma.

Preguntas frecuentes

¿La hiperconvergencia sustituye a la virtualización?

No, la contiene. Sigue habiendo un hipervisor ejecutando máquinas virtuales; lo que cambia es de dónde sale el almacenamiento que esas máquinas usan.

¿Necesito comprar hardware certificado?

Las plataformas comerciales tienen listas de compatibilidad estrictas, y salirse de ellas suele significar quedarse sin soporte. Existen alternativas de código abierto con almacenamiento distribuido más flexibles en hardware, pero exigen bastante más conocimiento interno.

¿Es más segura?

Ni más ni menos. Aporta redundancia frente a fallos de hardware, que es una cosa; frente a ransomware o a un borrado, hace falta exactamente el mismo plan de copias e inmutabilidad que en cualquier otra infraestructura.

¿Puedo empezar pequeño?

Sí, y es una de sus virtudes: arrancar con tres nodos y añadir según crece la necesidad. Lo que conviene planificar desde el principio es la red, porque ampliarla después es lo caro.

¿Y si mi problema es solo que la cabina se me ha quedado corta?

Entonces quizá no necesites cambiar de modelo, solo ampliar. La hiperconvergencia tiene sentido cuando el problema es de operación y crecimiento, no cuando es de capacidad puntual.

En resumen

La hiperconvergencia es la opción acertada cuando el equipo de sistemas es reducido, el crecimiento es difícil de predecir y las cargas son razonablemente equilibradas. Deja de serlo cuando necesitas mucho disco y poca CPU, cuando ya tienes una cabina que amortizar o cuando el clúster es tan pequeño que no llega a tres nodos.

Antes de pedir presupuestos, mide dos cosas: capacidad útil —no bruta— y coste de licenciamiento a cinco años. Son las dos variables que deciden si el proyecto sale a cuenta.