Windows Server 2025 / Cómo planificar un clúster de conmutación por error

Windows Server Failover Clustering (WSFC), la agrupación en clúster de conmutación por error de Windows Server, coordina roles compatibles entre servidores y puede reiniciarlos o trasladarlos tras un fallo. Tener dos servidores no basta: la aplicación, el almacenamiento, la red, el cuórum, la validación y los objetivos de recuperación deben formar un diseño coherente.

Definir los fallos que debe soportar

Un nodo es un servidor participante; un rol en clúster es un conjunto de recursos de servicio o máquina virtual gestionado por el clúster. Detectar un fallo y trasladar el rol puede interrumpir conexiones. Por eso debe comprobarse cuándo el cliente vuelve a conectarse y cuándo la aplicación vuelve a estar utilizable, no solo cuándo el administrador ve el recurso en línea.

La alta disponibilidad no sustituye copias de seguridad ni recuperación ante desastres. Dos máquinas virtuales en el mismo host físico pueden detenerse juntas si falla ese host; incluso en hosts separados pueden compartir una cabina, alimentación o conmutador que afecte a ambas. Activar la característica de clúster en servidores IIS corrientes no hace automáticamente que sus sitios sean altamente disponibles. Primero confirme qué arquitectura admite la aplicación.

Defina el rol que protegerá, el objetivo de tiempo de recuperación (Recovery Time Objective, RTO) y el objetivo de punto de recuperación (Recovery Point Objective, RPO). El RTO expresa cuánto tiempo de recuperación resulta aceptable; el RPO, cuánta pérdida de datos se admite respecto a un punto recuperable. Registre dónde empieza y termina la medición y qué evidencia la demostrará. No dé por supuesto tiempo de interrupción o pérdida de datos nulos.

Revisar nodos, red y capacidad restante

Compare los requisitos de hardware y almacenamiento del clúster con versión de Windows Server, equipos compatibles, controladores y firmware. Para un diseño nuevo use nodos comparables con Windows Server 2025 y compruebe soporte y validación del conjunto. En el despliegue de dominio ordinario los nodos deben ajustarse a las condiciones de misma versión y dominio; las configuraciones de grupo de trabajo tienen requisitos distintos. No mezcle ambos procedimientos.

• Dibuje tráfico de administración, clúster, almacenamiento y migración de máquinas virtuales cuando corresponda. Estime ancho de banda y competencia de tráfico durante fallo y recuperación.
• Identifique puntos únicos de fallo en tarjetas de red, conmutadores, alimentación y rutas de almacenamiento. Registre dependencias compartidas aunque los nodos tengan nombres diferentes.
• Calcule CPU, memoria y almacenamiento disponibles tras perder un nodo, incluyendo cargas que asumirán los supervivientes y trabajo de resincronización. Una suma suficiente en funcionamiento normal no demuestra capacidad durante el fallo.
• En un despliegue de dominio, verifique DNS interno, sincronización horaria, identidad del clúster y permisos de registro de nombres. Mantenga separados los nodos y los controladores de dominio según el método de implantación.

Guarde direcciones, nombres, redes de área local virtuales (VLAN) y requisitos de firewall en un plan compartido. Varias tarjetas conectadas al mismo conmutador o recorrido de cableado no crean rutas independientes. Por ejemplo, si se pierde un host, indique qué nodo asume la carga y con qué recursos libres; si se pierde la cabina compartida, documente por qué los nodos supervivientes siguen o dejan de tener datos. Distinga estos escenarios antes de comprar capacidad.

Elegir almacenamiento compatible con el rol

Discos compartidos, almacenamiento Server Message Block (SMB) y Storage Spaces Direct tienen condiciones de rol, hardware, edición y compatibilidad. No todos sirven para cualquier carga. Carpetas locales con el mismo nombre en dos nodos no proporcionan datos compartidos; DFS Namespaces tampoco crea automáticamente replicación o almacenamiento de clúster. La elección debe permitir al nodo que asume el rol acceder a los datos actuales de forma compatible.

Use un entorno de prueba separado antes de presentar discos operativos a configuración o validación de almacenamiento. Documente propietario de los discos, reservas, rutas y condiciones de licencia de la arquitectura. No interprete que un disco visible está libre para apropiárselo ni conecte datos de producción a una prueba de almacenamiento sin un plan que proteja servicio y datos.

Planificar el cuórum y la ubicación del testigo

El cuórum decide si el clúster puede seguir funcionando, incluso cuando una partición de red separa sus componentes, y ayuda a evitar propietarios simultáneos de los mismos recursos. Un testigo participa en esa decisión; no contiene una copia de los datos del servicio ni es otro nodo que ejecute la carga. Poder alcanzar el testigo no implica poder acceder al almacenamiento o a la aplicación.

Compare testigo de disco, recurso compartido de archivos y nube con la guía de implementación de testigos de cuórum. Valore ubicación, permisos, particiones de red y conectividad externa, además del número de nodos. Cada tipo tiene requisitos propios; por ejemplo, la opción de nube depende de recursos de Azure aprobados y conectividad HTTPS desde los nodos. El cuórum dinámico no garantiza superar cualquier combinación o secuencia de fallos.

Un testigo en el mismo dominio de fallo puede desaparecer junto con los dos nodos. Separarlo físicamente tampoco basta si depende de las mismas rutas o carece de autorización. Prepare una matriz con pérdida de nodo, enlace entre nodos, ruta de almacenamiento y ubicación completa; para cada caso anote participantes disponibles, ubicación del testigo, acceso a datos y comportamiento esperado. Revise esa matriz con la guía del tipo de testigo elegido antes de dar por aprobada la continuidad.

Exigir validación antes de decidir el despliegue

1. Documente nodos, redes, almacenamiento, cuentas, nombres y roles protegidos. Asigne responsables y vincule cada dependencia al fallo que puede provocar.
2. Alinee características, actualizaciones, controladores y requisitos de soporte. Confirme la compatibilidad de la configuración completa, no solo de cada pieza aislada.
3. Planifique la validación de configuración antes de crear el clúster. Resuelva o explique cada advertencia y fallo con su impacto y acción; no considere una advertencia revisada por el mero hecho de guardarla.
4. Pruebe movimientos planificados por separado de fallos inesperados en un entorno autorizado. Un movimiento correcto no demuestra que la detección y recuperación automática funcionen igual.
5. Mida reconexión de clientes, coherencia de datos, tiempo de recuperación y entrega de alertas. Compare los resultados observados con RTO y RPO y registre las diferencias sin inventar medidas.
6. Valide por separado la restauración de copias y la pérdida completa de un dominio de fallo. Incluya orden de recuperación, dependencias, responsables y criterios para devolver el servicio al funcionamiento normal.

Siga la guía de creación y validación de clústeres correspondiente a la arquitectura. Las pruebas de almacenamiento pueden afectar al servicio: no ejecute todas indiscriminadamente sobre producción. Conserve el informe e identifique causa, impacto y acción para cada hallazgo. En una implantación de dominio, planifique permisos para administrar los nodos y crear o preaprovisionar los objetos de equipo necesarios; no conceda administración de todo el dominio solo para evitar un error de permisos.

Este ejercicio no convierte DC1, FS1 ni los demás servidores del curso en un clúster. Su resultado es un diseño de roles compatibles, necesidades de recursos, mapa de dominios de fallo, objetivos de interrupción y plan de validación con responsables. Si no puede explicar qué ocurre cuando desaparece el almacenamiento o cómo se restaura un archivo borrado, registre la decisión pendiente: añadir otro nodo por sí solo no resuelve esas condiciones.