Cómo diseñar un cluster Hyper‑V económico con almacenamiento compartido para pymes

Problema

Muchas pymes operan con servidores físicos aislados, sin respaldo ni estrategia de recuperación. Cuando el número de usuarios supera los 30‑50, la gestión de actualizaciones, fallos de hardware y la expansión de capacidad se vuelve costosa y arriesgada. El reto típico es migrar esas cargas –controlador de dominio, servidores de archivos y aplicaciones críticas como CAD – a una infraestructura virtual que ofrezca:

• Alta disponibilidad (HA) mínima sin romper el presupuesto.
• Almacenamiento compartido que permita mover máquinas virtuales (VM) entre nodos.
• Un plan de respaldo centralizado y sencillo de administrar.

En la práctica, los administradores deben decidir entre comprar un SAN tradicional, usar un NAS con iSCSI o aprovechar Storage Spaces Direct (S2D) integrado en Windows Server. Cada opción tiene implicaciones de coste, complejidad y rendimiento que varían según el perfil de la carga (I/O intensivo vs. solo archivos) y el margen de crecimiento esperado.

Causa

Los fallos habituales que empujan a buscar una solución de cluster son:

1. Puntos únicos de falla – Un servidor de archivos que se cae deja sin acceso a datos críticos.
2. Crecimiento descontrolado del almacenamiento – Los discos locales de los servidores no escalan bien y la gestión se vuelve manual.
3. Ausencia de backups consistentes – Sin un repositorio compartido, los snapshots de VM son imposibles o poco fiables.
4. Limitaciones de presupuesto – Los presupuestos de pymes rara vez alcanzan los niveles de un SAN de gama empresarial, pero la necesidad de HA sigue presente.

Estas causas aparecen con frecuencia en entornos que todavía dependen de hardware “legacy” y que intentan modernizarse sin una planificación clara del almacenamiento.

Solución

1. Evaluar la carga de trabajo

• AD/DC y servidores de terminal – I/O ligero, latencia no crítica.
• Servidor de archivos (4 TB) – Operaciones mixtas (lectura/escritura) y picos de transferencia cuando los ingenieros abren proyectos CAD.
• Aplicación CAD (Autodesk Vault) – Acceso a archivos grandes, pero no necesita latencias de milisegundo como bases de datos transaccionales.

Con este perfil, una arquitectura basada en NAS con iSCSI o S2D suele ser suficiente. Un SAN de gama alta aporta ventajas solo cuando se necesita IOPS extremadamente altas o conectividad Fibre Channel, lo cual no es el caso típico de 30‑100 usuarios.

2. Opción A – NAS con iSCSI

1. Hardware: Un chasis NAS de 2‑4 bahías con discos SAS de 10 TB configurados en RAID‑6. Modelos de Synology, QNAP o TrueNAS ofrecen conectividad 10 GbE y soporte nativo de iSCSI.
2. Configuración:
   • Crear un LUN de 8 TB (deja margen para snapshots y crecimiento).
   • Habilitar CHAP para autenticación.
   • Mapear el LUN a ambos nodos Hyper‑V mediante MPIO (Multipath I/O) para redundancia de red.
3. Ventajas:
   • Costo inicial bajo (≈ CAD 15‑20 K).
   • Gestión sencilla vía GUI.
   • Snapshots de nivel de bloque integrados (para backups rápidos).
4. Desventajas:
   • Dependencia de un único punto de red; se necesita al menos dos NICs de 10 GbE y conmutador con LACP.
   • Rendimiento limitado por la capacidad del controlador NAS (generalmente < 2 GB/s).

3. Opción B – Storage Spaces Direct (S2D)

1. Requisitos mínimos:
   • 2 nodos con al menos 4 TB de SSD para caché y 8 TB de HDD para capacidad.
   • Conexión de red 10 GbE o 25 GbE entre nodos.
2. Pasos clave:
   • Habilitar la característica Failover-Clustering y FS-Cluster.
   • Ejecutar el cmdlet Enable-ClusterS2D con los discos deseados.
   • Configurar un Scale‑out File Server (SOFS) para exponer los volúmenes a las VM.
3. Ventajas:
   • No se necesita hardware de almacenamiento dedicado; los discos se consumen directamente del servidor.
   • Escalado lineal: añadir nodos aumenta capacidad y IOPS.
   • Integración nativa con Hyper‑V, lo que simplifica la migración de VM.
4. Desventajas:
   • Consumo de RAM y CPU mayor (se recomienda 128 GB RAM por nodo para 50 usuarios).
   • Curva de aprendizaje más pronunciada; la monitorización de salud del clúster es crucial.

4. Decisión práctica

Para la mayoría de pymes con 50 usuarios, NAS con iSCSI es suficiente y permite cumplir con el presupuesto. Si se prevé crecimiento rápido o se quiere eliminar el hardware de almacenamiento como punto único de falla, S2D es la ruta a seguir, siempre que el CAPEX adicional sea aceptable.

5. Implementación paso a paso (NAS + iSCSI)

1. Preparar el NAS

   • Configurar LUN y habilitar CHAP.
   • Crear dos VLAN separadas: una para gestión y otra para tráfico de iSCSI.

2. Configurar los nodos Hyper‑V

   • Instalar la característica Failover-Clustering y Hyper‑V en ambos servidores.
   • Añadir ambas NICs al team LACP para redundancia.

3. Conectar el LUN

   • En cada nodo, abrir el iSCSI Initiator, añadir el objetivo del NAS y habilitar Multipath I/O (MPIO) con el Microsoft MPIO driver.

4. Crear el clúster

   • Ejecutar New-Cluster -Name "SMB-Cluster" -Node "Node01","Node02" -StaticAddress "10.0.0.100"
   • Validar con Test-Cluster.

5. Crear el disco compartido

   • En el Failover Cluster Manager, crear un Cluster Shared Volume (CSV) sobre el LUN conectado.

6. Desplegar las VM

   • Al crear cada VM, seleccionar el CSV como disco de almacenamiento.
   • Configurar Live Migration entre nodos usando la red de 10 GbE.

6. Implementación paso a paso (S2D)

# Instalar características necesarias
Install-WindowsFeature -Name Failover-Clustering,Hyper-V,FS-Cluster -IncludeManagementTools

# Crear el clúster
New-Cluster -Name "S2D-Cluster" -Node "Node01","Node02" -StaticAddress "10.0.0.101"

# Habilitar Storage Spaces Direct
Enable-ClusterS2D -CimSession "S2D-Cluster" -Verbose

# Crear un volumen de capacidad (ejemplo 8TB)
New-Volume -StoragePoolFriendlyName "S2D on Cluster" -FriendlyName "DataVol" -FileSystem CSVFS_ReFS -Size 8TB

# Exportar el volumen como CSV
Add-ClusterSharedVolume -Name "DataVol"

Cuándo aplicar esta solución

• Aplicable:

  • Entornos de 30‑150 usuarios con cargas mixtas (archivos, AD, RDS).
  • Presupuesto limitado pero con requerimientos de HA y backups centralizados.
  • Infraestructura de red ya cuenta con 10 GbE o superior.

• No aplicable:

  • Aplicaciones que exigen latencias < 1 ms o IOPS > 50 k (bases de datos OLTP críticas).
  • Escenarios donde la normativa obliga a almacenamiento certificado (SAN de clase empresarial).
  • Empresas que ya poseen un SAN y el coste de migración supera los beneficios.

Código

# Verificar salud del clúster después de la configuración
Test-Cluster -Node "Node01","Node02" -Include "Storage","Network","SystemConfiguration"

Verificación

1. Estado del clúster: Get-ClusterGroup | ft Name,State,OwnerNode. Todos los grupos deben estar en Online.
2. CSV salud: Get-ClusterSharedVolume | ft Name,State,OwnerNode. El estado debe ser Online.
3. Failover test: mover manualmente una VM con Move-ClusterGroup -Name "VMName" -Node "Node02" y confirmar que sigue operativa.
4. Rendimiento: usar Performance Monitor o Resource Monitor para observar IOPS y latencia del LUN/CSV bajo carga típica de CAD.
5. Backup: crear un snapshot del CSV y restaurarlo en un entorno de pruebas para validar la integridad de los datos.

Notas adicionales

• Redundancia de red: siempre configure al menos dos NICs por nodo y habilite LACP; la pérdida de una conexión no debe afectar al tráfico iSCSI o a la migración en vivo.
• Snapshots vs. backups: los snapshots son útiles para cambios rápidos, pero no sustituyen a una solución de backup basada en Veeam, Altaro o Windows Server Backup que copie los CSV a un medio externo.
• Monitoreo: habilite alertas de Cluster Log y Event Viewer para detectar fallos de disco o de MPIO antes de que provoquen downtime.
• Licenciamiento: la edición Datacenter de Windows Server es necesaria para usar S2D y para crear un número ilimitado de VM con licencias de Core.
• Plan de expansión: reserve al menos 20 % de capacidad libre en el LUN o en el pool S2D; los volúmenes CSV no pueden crecer más allá del 80 % sin