¿Quieres alta disponibilidad con dos servidores físicos Windows Server 2019, sin cabina externa ni hipervisor y, además, sin dominio? Sí se puede. Aquí tienes una guía práctica y accionable para montar un clúster de conmutación por error (WSFC) en workgroup, definiendo testigo, replicación de datos y pruebas de failover reales.
Índice
Resumen de la pregunta
- Dos servidores físicos idénticos con Windows Server 2019 ejecutando una app 24/7.
- Se solicita conmutación por error entre ambos, sin almacenamiento externo ni hipervisor.
- Preferencia por mantenerlos fuera de Active Directory (workgroup).
Respuesta corta
Sí, es posible. Desde Windows Server 2016 puedes crear un Failover Cluster en workgroup. En un clúster de dos nodos, es obligatorio un testigo (witness) para mantener el quórum al caer un nodo. Para la replicación de datos sin almacenamiento compartido, usa Storage Replica o, si tu aplicación lo soporta, su propia replicación.
Arquitectura recomendada (sin AD, sin almacenamiento externo)
[Nodo A] <--- Storage Replica (sync/async) ---> [Nodo B]
│ │
└── Rol de clúster (Servicio/Aplicación Genérica)
con IP/Nombre de clúster para clientes
│
[Quórum]
File Share Witness (FSW) en tercer equipo/NAS
o Cloud Witness (Azure) sin hardware adicional
Elementos clave de la solución
Tipo de clúster
- Workgroup cluster: sin AD, válido desde WS2016. Adecuado cuando no puedes unir servidores a un dominio.
- Con AD (opcional): también funciona. Si más adelante te unes a un dominio, mantienes el diseño y puedes ampliar capacidades.
Quórum y Testigo (obligatorio en 2 nodos)
| Opción de Testigo | Descripción | Ventajas | Cuándo elegirla |
|---|---|---|---|
| File Share Witness (FSW) | Carpeta compartida accesible por ambos nodos. | Sencillo, reutiliza un tercer equipo/NAS. | Ya tienes un servidor o NAS estable en la misma red. |
| Cloud Witness | Usa Azure Storage como testigo. | Sin hardware extra; resiliencia fuera del sitio. | No quieres depender de un tercer servidor local. |
| Disk Witness | Disco compartido al clúster. | — | No aplica si no hay almacenamiento compartido. |
Sin almacenamiento externo: ¿cómo replico mis datos?
| Opción | Cómo funciona | Licenciamiento | Pros | Contras / Consideraciones |
|---|---|---|---|---|
| Storage Replica (SR) | Replica bloques entre volúmenes (sync/async). | En Standard: 1 asociación, 1 volumen ≤ 2 TB. En Datacenter: sin límites de ese tipo. | No requiere cabina; integra con WSFC; consistente a nivel de bloque. | Requiere discos separados para datos y log; planificar RPO/RTO. |
| Storage Spaces Direct (S2D) | Aglutina discos locales y expone volúmenes compartidos al clúster. | Requiere Datacenter. | Performance y simplicidad de consumo una vez desplegado. | En WS2019 suele requerir dominio (AD); mayor complejidad inicial. Si tu escenario debe permanecer en workgroup, prioriza SR. |
| Replicación a nivel de aplicación | La propia app sincroniza estado/datos. | Depende del producto. | Conciencia de consistencia de la app, failover más limpio. | Atado al fabricante; complejidad si mezcla roles. |
Compatibilidad de la carga
- Comprueba si tu aplicación es cluster-aware (tiene rol específico) o si funciona como Servicio/Aplicación Genérica en WSFC.
- Si mantiene estado local (archivos, colas, cachés), planifica su replicación; sin eso, el rol levantará la app en el nodo pasivo pero faltará el estado.
Requisitos previos
- Dos servidores físicos idénticos (CPU, memoria, discos) con Windows Server 2019 y parches al día.
- IPs estáticas en cada nodo y una IP para el nombre del clúster.
- Reloj sincronizado (NTP), DNS resolviendo correctamente entre nodos.
- Usuarios locales administradores con mismas credenciales en ambos nodos (para workgroup).
- Definir testigo: FSW en tercer equipo/NAS o Cloud Witness.
- Volúmenes dedicados: al menos un volumen de datos y un volumen de log (SR).
Puertos y firewall recomendados
| Servicio | Puerto | Protocolo | Uso |
|---|---|---|---|
| Failover Cluster | 3343 | UDP/TCP | Latido (heartbeat) y control del clúster. |
| RPC Endpoint Mapper | 135 | TCP | Gestión remota. |
| RPC dinámicos | 49152–65535 | TCP | Llamadas RPC de servicios. |
| SMB | 445 | TCP | Tráfico de Storage Replica y accesos a recursos. |
Instalar las características de Failover Clustering y Storage Replica crea reglas de firewall locales. Si hay firewalls perimetrales, ábrelos explícitamente.
Pasos de implementación (alto nivel)
- Preparación: IPs, DNS, NTP, cuentas locales admin, volúmenes de datos/log, elección de witness.
- Instalar características: Failover Clustering y (opcional) Storage Replica.
- Validación:
Test-Clusterpara red, sistema y almacenamiento. - Crear el clúster en workgroup con punto de acceso DNS.
- Configurar quórum con FSW o Cloud Witness.
- Configurar replicación (SR o la de la app).
- Agregar la aplicación como rol de clúster (Generic Service/Application).
- Probar y documentar: failover manual, caída simulada, RTO/RPO, consistencia de datos.
Implementación detallada (PowerShell)
Instalar características
# En ambos nodos (ejecutar en PowerShell elevado)
Install-WindowsFeature Failover-Clustering -IncludeManagementTools
Si vas a usar Storage Replica
Install-WindowsFeature Storage-Replica
Validar la configuración
# Ejecuta las pruebas de validación
Test-Cluster -Node Srv1,Srv2
Revisa el reporte y corrige advertencias críticas antes de crear el clúster.
Crear el clúster en workgroup
En clústeres sin AD, usa un punto de acceso DNS. Crea o reserva la A-record del nombre del clúster si no hay actualización dinámica.
# IP virtual de ejemplo: 10.0.0.50
New-Cluster -Name APPCLUSTER `
-Node Srv1,Srv2 `
-StaticAddress 10.0.0.50 `
-AdministrativeAccessPoint DNS
Configurar quórum y testigo
# File Share Witness (FSW)
Set-ClusterQuorum -FileShareWitness \\ServidorWitness\FSW
Alternativa: Cloud Witness (requiere cuenta de Azure ya creada)
Set-ClusterQuorum -CloudWitness -AccountName "miCuentaStorage" -AccessKey "Clave..." -Endpoint "core.windows.net"
Preparar Storage Replica (SR)
Asegúrate de tener un volumen de datos y un volumen de log en cada nodo (por ejemplo, D: para datos, L: para log). El log debe estar en un disco rápido y dedicado.
# Crear grupos SR (opcional si no existen)
New-SRGroup -ComputerName Srv1 -Name "SRV1-Group" -VolumeName D: -LogVolumeName L:
New-SRGroup -ComputerName Srv2 -Name "SRV2-Group" -VolumeName D: -LogVolumeName L:
Crear la asociación SR (sincrónica; RPO≈0 en LAN)
New-SRPartnership ` -SourceComputerName Srv1 -SourceRGName "SRV1-Group" -SourceVolumeName D:`
-DestinationComputerName Srv2 -DestinationRGName "SRV2-Group" -DestinationVolumeName D: \`
-LogVolumeName L: -ReplicationMode Synchronous
Ver estado
Get-SRGroup -ComputerName Srv1 | Get-SRPartnership
Get-SRGroup -ComputerName Srv2 | Get-SRPartnership Si la latencia es elevada, usa modo asíncrono:
Set-SRPartnership -SourceComputerName Srv1 -SourceRGName "SRV1-Group" `
-DestinationComputerName Srv2 -DestinationRGName "SRV2-Group" `
-ReplicationMode Asynchronous
Agregar la aplicación como rol del clúster
Si no hay rol específico para tu software, usa un rol genérico. Ejemplos:
# Servicio genérico (reemplaza "MiServicio" por el nombre del servicio de Windows)
Add-ClusterGenericServiceRole -Cluster APPCLUSTER -ServiceName "MiServicio" -Name "App-HA"
Aplicación genérica (ejecutable con su ruta)
Add-ClusterGenericApplicationRole -Cluster APPCLUSTER -CommandLine "C:\Rutas\MiApp\MiApp.exe" -Name "App-HA"
Dependencias típicas: IP y Nombre de red de clúster
Get-ClusterResource -Cluster APPCLUSTER
Define orden de inicio y dependencias según necesidades de la app
Pruebas de conmutación
# Failover manual del rol para medir RTO
Move-ClusterGroup -Name "App-HA" -Node Srv2
Simula caída (detén servicio de clúster SOLO en entorno de pruebas)
Stop-Service -Name ClusSvc -Force
Vuelve a iniciarlo al terminar la prueba:
Start-Service -Name ClusSvc
Revisión de eventos y cluster logs
Get-ClusterLog -UseLocalTime -Destination C:\Temp\ClusterLogs Buenas prácticas
- Witness siempre en clúster de 2 nodos para evitar split-brain y pérdida de servicio.
- Red: NICs redundantes; separa tráfico cliente y latido si es posible; desactiva ahorro de energía en NICs de servidor.
- DNS: planifica el nombre del clúster que usarán los clientes; TTL razonable (por ejemplo, 60–300 s) para acelerar convergencia.
- Licenciamiento: verifica edición Standard vs Datacenter según límites de SR y uso de S2D.
- Documenta todo: topología, dependencias, tiempos de conmutación, procedimientos de DR.
- Monitorea: métricas de latencia SR, cola de replicación, eventos de clúster y de la app.
Diseño de red y parámetros de clúster útiles
- Redes de clúster: marca cuáles son para cliente y cuáles para comunicaciones internas. Ajusta el rol de cada red si es necesario.
- Heartbeats (entornos inestables): puedes ajustar
SameSubnetDelayySameSubnetThresholdpara tolerar picos de latencia. - Jumbo frames: solo si todo el camino los soporta y está validado; de lo contrario, usa MTU por defecto.
Seguridad y autenticación en workgroup
- Usa cuentas locales admin idénticas (mismo usuario/contraseña) en ambos nodos para operaciones iniciales.
- Para accesos de cliente a recursos de red del clúster en workgroup, la autenticación será NTLM. Si necesitas Kerberos, evalúa unir al dominio.
- Minimiza los privilegios: crea cuentas de servicio dedicadas para la aplicación si procede.
RTO/RPO y modo de replicación
| Modo | RPO | RTO | Uso típico |
|---|---|---|---|
| Sincrónico | ≈ 0 (transaccional) | Bajo | Misma sala/sitio, latencia baja, prioridad a consistencia. |
| Asíncrono | > 0 (segundos/minutos) | Medio | Sitios remotos con latencia mayor; prioridad a continuidad. |
Solución de problemas frecuentes
- El clúster no se crea por DNS: crea manualmente el registro A del nombre del clúster o revisa permisos de actualización dinámica.
- Falla Test-Cluster por almacenamiento compartido: es normal si no hay cabina. Revisa advertencias y confirma que SR cubre los volúmenes de datos.
- SR sin iniciar: verifica que el volumen de log esté dedicado, que el tráfico SMB (445) no esté bloqueado y que los volúmenes tengan la misma letra y tamaño (o aceptable) en ambos nodos.
- Failover lento: revisa dependencias del rol, latencia de red, eventos de la app y parámetros de heartbeat.
- Quórum perdido al caer un nodo: confirma que el FSW/Cloud Witness esté operativo y accesible desde el nodo superviviente.
Checklist de verificación
- ❑ IPs estáticas y DNS resolviendo nodos y nombre de clúster.
- ❑ Failover Clustering y Storage Replica instalados en ambos nodos.
- ❑
Test-Clusterejecutado y advertencias críticas resueltas. - ❑ Clúster creado con
-AdministrativeAccessPoint DNS. - ❑ Quórum configurado con FSW o Cloud Witness.
- ❑ Volúmenes de datos y log preparados; SR en estado Healthy.
- ❑ Rol de la aplicación creado (servicio o app genérica) con dependencias correctas.
- ❑ Pruebas de failover (manual y simulada) documentadas con tiempos RTO/RPO.
Ejemplo completo (script orientativo)
# VARIABLES
$Nodes = "Srv1","Srv2"
$ClusterName = "APPCLUSTER"
$ClusterIP = "10.0.0.50"
$FSW = "\\ServidorWitness\FSW"
$RG1 = "SRV1-Group"; $RG2 = "SRV2-Group"
$DataVol = "D:"; $LogVol = "L:"
$SvcName = "MiServicio" # O ruta a exe si es app genérica
1) Instalación de características
Install-WindowsFeature Failover-Clustering -IncludeManagementTools
Install-WindowsFeature Storage-Replica
2) Validación
Test-Cluster -Node \$Nodes
3) Crear clúster (workgroup, punto de acceso DNS)
New-Cluster -Name \$ClusterName -Node \$Nodes -StaticAddress \$ClusterIP -AdministrativeAccessPoint DNS
4) Quórum con FSW
Set-ClusterQuorum -FileShareWitness \$FSW
5) Storage Replica
New-SRGroup -ComputerName \$Nodes\[0] -Name \$RG1 -VolumeName \$DataVol -LogVolumeName \$LogVol
New-SRGroup -ComputerName \$Nodes\[1] -Name \$RG2 -VolumeName \$DataVol -LogVolumeName \$LogVol
New-SRPartnership -SourceComputerName \$Nodes\[0] -SourceRGName \$RG1 -SourceVolumeName \$DataVol ` -DestinationComputerName $Nodes[1] -DestinationRGName $RG2 -DestinationVolumeName $DataVol`
-LogVolumeName \$LogVol -ReplicationMode Synchronous
6) Rol de aplicación (servicio genérico)
Add-ClusterGenericServiceRole -Cluster \$ClusterName -ServiceName \$SvcName -Name "App-HA"
7) Pruebas
Move-ClusterGroup -Name "App-HA" -Node \$Nodes\[1]
Get-ClusterLog -UseLocalTime -Destination C:\Temp\ClusterLogs Preguntas frecuentes
¿Puedo hacerlo totalmente sin AD? Sí. Crea el clúster con -AdministrativeAccessPoint DNS, define un FSW o Cloud Witness y usa Storage Replica o replicación de app para los datos.
¿Qué edición de Windows Server necesito? Con Standard puedes usar SR con limitaciones (1 asociación, 1 volumen hasta 2 TB). Datacenter elimina esas restricciones y habilita S2D, aunque este último suele requerir dominio.
¿Mi app debe ser consciente de clúster? No necesariamente. Si no tiene rol propio, puedes usar Servicio/Aplicación Genérica. Lo crítico es asegurar la replicación del estado y archivos.
¿Qué pasa si no configuro witness? En un clúster de dos nodos, sin testigo podrías perder el servicio ante la caída de un nodo debido a pérdida de quórum o split-brain.
¿SR sincrónico o asíncrono? En la misma sede y con baja latencia, sincrónico te da RPO≈0. Entre sitios con latencia relevante, asíncrono preserva rendimiento a costa de un RPO>0.
Conclusión
Con Windows Server 2019 puedes alcanzar alta disponibilidad real entre dos servidores físicos sin cabina y sin hipervisor, incluso en workgroup. La clave está en: quórum con testigo, replicación de datos fiable (Storage Replica o la propia de la app) y pruebas de failover bien diseñadas. Con esta guía tendrás una base sólida para llevar tu aplicación a 24/7 con interrupciones mínimas.
Notas finales de diseño
- Si en el futuro unes los nodos a un dominio, puedes mantener el clúster y ampliar con roles que requieren AD.
- Si consideras S2D por simplicidad operativa, recuerda que en WS2019 suele requerir AD y la edición Datacenter.
- Automatiza respaldos de configuración del clúster y exporta informes de validación tras cada cambio físico o de red.