Almacenamiento compartido vs local en clúster de conmutación por error de Windows Server para Active Directory

Elegir el tipo de almacenamiento adecuado es decisivo para que un clúster de controladores de dominio brinde alta disponibilidad real. A continuación se analiza en profundidad por qué el almacenamiento compartido (Cluster Shared Volumes) es la alternativa óptima frente al disco local.

Índice

Panorama de alta disponibilidad en Active Directory

Los controladores de dominio (DC) son la piedra angular del servicio de autenticación y autorización de una entidad bancaria. Su indisponibilidad compromete cajeros automáticos, aplicaciones de banca en línea y registros de auditoría. Para eliminar puntos únicos de falla, se suelen agrupar dos DC en un clúster de conmutación por error activo‑pasivo, mientras se mantienen réplicas adicionales en otros sitios y en la nube para contingencias extremas.

Cómo opera un clúster de conmutación por error de Windows Server

Windows Server Failover Clustering (WSFC) supervisa la salud de los nodos mediante latidos (heartbeat) y detecta fallas de hardware o del sistema operativo. Cuando el nodo activo deja de responder, el recurso de clúster —en este caso, el rol de controlador de dominio con los Flexible Single Master Operations (FSMO) críticos— se mueve al nodo pasivo. Este proceso debe ser automático y transparente; el usuario final no debe notar la transferencia.

Requisitos de persistencia de datos

Para que el traspaso funcione sin pérdida de información o de transacciones, ambos nodos deben poder acceder al mismo conjunto de datos de forma coherente. Aquí es donde surge la disyuntiva entre almacenamiento compartido y almacenamiento local.

Opciones de almacenamiento para el clúster

Almacenamiento compartido: Cluster Shared Volumes (CSV)

CSV permite que varios nodos monten simultáneamente un mismo volumen NTFS o ReFS alojado en una LUN de Fibre Channel, iSCSI o SAS. Cada nodo posee acceso de lectura‑escritura concurrente, mientras que el coordinador CSV gestiona el enrutamiento de metadatos para evitar corrupción.

Almacenamiento local en cada nodo

Con discos locales, cada servidor mantiene su propia copia de la base de datos NTDS.dit y de las particiones SYSVOL. En un escenario activo‑pasivo, el nodo secundario queda congelado hasta que recibe la señal de tomar el control; entonces debe montar su copia local, la cual puede estar desactualizada si no existe replicación síncrona.

CaracterísticaAlmacenamiento compartidoAlmacenamiento local
Coherencia de datosGarantizada; un solo volumen accesible por ambos nodosDepende de replicación; riesgo de divergencias
Tiempo de recuperación (RTO)Segundos; el nodo pasivo ya ve el discoMinutos u horas; montaje y convergencia
Complejidad operativaBaja; gestionado por WSFC y CSVAlta; requiere scripts o herramientas de réplica
EscalabilidadAlta; admite hasta 64 nodosBaja; cada nodo duplica almacenamiento
Coste de capacidadOptimizado; una sola LUNIncrementa linealmente por nodo

Beneficios operativos del almacenamiento compartido

Continuidad y objetivos de recuperación

Porque ambos nodos leen y escriben en la misma LUN, basta con un reinicio controlado del recurso de clúster para que el nodo pasivo asuma el rol. La conmutación finaliza en segundos y cumple con objetivos de RTO estrictos habituales en banca (≤ 15 segundos) y con un RPO de cero.

Integridad de los roles FSMO

El PDC Emulator mantiene los relojes de Kerberos y los bloqueos de contraseña. Al compartir el disco, la transacción inacabada se completa en el nodo sobreviviente, evitando inconsistencias de cuenta o hash.

Simplificación de la administración

Las tareas de parcheo o actualización del sistema operativo se vuelven más sencillas: bastará con colocar un nodo en mantenimiento, aplicar el parche y devolverlo al clúster. No hay que ejecutar sincronizaciones diferenciales complejas.

Riesgos y limitaciones del almacenamiento local

Replicación y obsolescencia de datos

La base de datos del directorio cambia con frecuencia: inicios de sesión, cambios de contraseña, políticas de grupo. Mantener réplicas locales perfectamente alineadas exige herramientas de replicación síncrona que, en muchos casos, no son compatibles con NTFS a nivel de bloque o introducen latencias elevadas. Un desfase de milisegundos puede traducirse en contraseñas rechazadas o tokens inválidos.

Split‑brain y conflictos de USN

Si los dos nodos creen ser propietarios del mismo rol tras una falla en la red, surgirán conflictos de Update Sequence Number. Resolverlos implica esfuerzo manual y posible restauración autoritativa, un proceso delicado que las auditorías bancarias observan con lupa.

Buenas prácticas al implementar CSV

Red de almacenamiento dedicada

Separe el tráfico iSCSI/Fibre Channel de la LAN de producción. Use VLAN o redes físicas distintas para eliminar congestión y latencia. Limite la latencia a menos de 5 ms entre nodos.

Multipath I/O

Configure al menos dos rutas físicas hacia la cabina. Si una HBA o puerto de switch falla, el nodo mantiene la conectividad. WSFC lo interpreta como una mera degradación, no como caída total.

Modelo de quórum adecuado

Para clústeres de dos nodos, el método recomendado es Cloud Witness alojado en Azure Blob Storage, eliminando la necesidad de un tercer sitio físico. Con tres nodos o más se puede usar Node Majority + Disk Witness.

Backups consistentes con VSS

CSV es compatible con VSS Backup. Programe copias diarias y verifique su restauración en un entorno de laboratorio. Recuerde que CSV incrementa la dependencia de una única LUN; un fallo lógico (por ejemplo, una eliminación accidental de objetos) debe poder revertirse.

Pruebas de conmutación periódicas

Simule fallos de hardware mediante el cmdlet Test‑Cluster y conmutaciones manuales con Stop‑ClusterNode ‑Drain. Valide que los clientes Kerberos mantengan sesiones y que los servicios financieros sensibles (SWIFT, PCI DSS) no pierdan conectividad.

Consideraciones regulatorias en el sector financiero

Las normas de continuidad de negocio para bancos (por ejemplo, ISO 22301, Basilea III) exigen evidencia de que el RTO y RPO se cumplen. Al usar CSV podrá documentar tiempos de conmutación medibles y reproducibles. Además, la cabina SAN permite cifrado en reposo y control de acceso a prueba de auditorías.

Escenarios híbridos y sitio de contingencia en Azure

Para desastres regionales, conviene mantener un DC en Azure IaaS. Este nodo puede actuar como Cloud Witness y, si se usa Storage Replica o Azure Site Recovery, también recibir una réplica de la LUN CSV. Ante la pérdida total del centro de datos, se puede re‑crear el clúster en la nube importando el storage pool y colocando el nuevo nodo como propietario de los roles FSMO.

Pasos de migración de almacenamiento local a CSV

  1. Instalar la función de clúster en ambos nodos y validar con Test‑Cluster.
  2. Provisionar la LUN en la SAN y presentarla a ambos nodos con el mismo LUN ID.
  3. Crear el volumen NTFS/ReFS y habilitarlo como CSV desde el administrador de clúster.
  4. Detener el servicio AD DS en el nodo secundario y copiar la base NTDS.dit y SYSVOL al CSV.
  5. Cambiar la ruta de la base de datos del servicio en ambos nodos para que apunte al CSV.
  6. Reiniciar los servicios, ejecutar Validate‑Cluster y registrar el clúster en DNS.
  7. Realizar una conmutación manual y comprobar que los clientes se re‑autenticen sin errores.

Conclusión

El propósito de un clúster de conmutación por error es garantizar la continuidad inmediata del negocio. En un entorno bancario, donde cada segundo de indisponibilidad se traduce en pérdidas económicas y riesgos regulatorios, el almacenamiento compartido mediante Cluster Shared Volumes es la opción más segura y eficiente. Proporciona integridad de datos, RTO mínimos y simplifica la operación diaria. El almacenamiento local, aunque tentador por su aparente simplicidad, introduce complejidad oculta, riesgos de corrupción y tiempos de recuperación más largos, lo que contradice los objetivos de alta disponibilidad y cumplimiento normativo.

Índice