Migrar Cloud Witness a nueva Storage Account via Private Endpoint

Contexto

En entornos de produccion con Windows Server Failover Cluster (WSFC), el quorum basado en Cloud Witness utiliza una Azure Storage Account como testigo. Cuando se migra la infraestructura a una nueva suscripcion o se refuerza la seguridad mediante Private Endpoints, es necesario reconfigurar el Cloud Witness para apuntar a la nueva Storage Account.

Este procedimiento documenta paso a paso como realizar esta migracion de forma segura y sin indisponibilidad del servicio, dado que el witness no participa activamente en el I/O del cluster salvo en situaciones de split-brain.

Escenario

Prerequisitos

• Acceso administrativo a los nodos del cluster
• Access Key de la nueva Storage Account (Azure Portal > Storage Account > Security + networking > Access keys)
• Private Endpoint configurado en la nueva Storage Account
• Reglas de firewall que permitan la comunicacion

Paso 1: Verificar la configuracion actual

Antes de realizar cualquier cambio, documentamos el estado actual del quorum:

Get-ClusterQuorum

Cluster              QuorumResource
-------              --------------
SQLCLUSTER01         Cloud Witness

Verificamos los parametros del Cloud Witness actual:

Get-ClusterResource | Where-Object {$_.ResourceType -eq "Cloud Witness"} | Get-ClusterParameter

Object        Name         Value                    Type
------        ----         -----                    ----
Cloud Witness AccountName  oldcloudwitness          String
Cloud Witness EndpointInfo  core.windows.net        String

Paso 2: Revisar reglas de firewall

Para la migracion a Private Endpoint, necesitamos asegurar conectividad desde ambos nodos del cluster hacia las IPs privadas de la nueva Storage Account:

Nota: Si se dispone de varias Storage Accounts candidatas, validar conectividad a todas antes de decidir cual utilizar como nuevo witness.

Paso 3: Validar resolucion DNS y conectividad

Verificar resolucion DNS desde los nodos

Desde cada nodo del cluster, comprobamos que el FQDN de la nueva Storage Account resuelve a la IP del Private Endpoint (no a la IP publica):

# Resolucion del storage account actual (publica)
Resolve-DnsName "oldcloudwitness.blob.core.windows.net"

# Resolucion de las nuevas storage accounts (deben resolver a IP privada)
Resolve-DnsName "newazurestorage01.blob.core.windows.net"
Resolve-DnsName "newazurestorage02.blob.core.windows.net"

Resultado esperado - La nueva storage debe resolver via privatelink:

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
newazurestorage01.blob.core.wi CNAME  9     Answer     newazurestorage01.privatelink.blob.core.windows.net
ndows.net

Name       : newazurestorage01.privatelink.blob.core.windows.net
QueryType  : A
TTL        : 9
Section    : Answer
IP4Address : 10.20.5.10

Si la resolucion devuelve una IP publica en lugar de la privada, revisar la configuracion de la zona DNS privada en Azure (privatelink.blob.core.windows.net).

Test de conectividad

Verificamos que los nodos alcanzan el puerto 443 de la nueva Storage Account:

# Test contra nueva storage account
Test-NetConnection -ComputerName "newazurestorage01.blob.core.windows.net" -Port 443
Test-NetConnection -ComputerName "newazurestorage02.blob.core.windows.net" -Port 443

Resultado esperado:

ComputerName     : newazurestorage01.blob.core.windows.net
RemoteAddress    : 10.20.5.10
RemotePort       : 443
InterfaceAlias   : Ethernet0
SourceAddress    : 10.10.1.11
TcpTestSucceeded : True

Importante: El campo TcpTestSucceeded debe ser True en ambos nodos para ambas Storage Accounts. Si es False, revisar reglas de NSG, firewall on-premise o UDR.

Paso 4: Configurar el nuevo Cloud Witness

Una vez validada la conectividad, procedemos a reconfigurar el Cloud Witness. Existen dos metodos:

Opcion A: PowerShell (recomendado)

Set-ClusterQuorum -CloudWitness `
    -AccountName "newazurestorage01" `
    -AccessKey "TU_ACCESS_KEY_BASE64_AQUI=="

Nota: La Access Key se obtiene de Azure Portal > Storage Account > Security + networking > Access keys (key1 o key2).

Opcion B: Failover Cluster Manager (GUI)

1. Abrir Failover Cluster Manager
2. Click derecho sobre el cluster > More Actions > Configure Cluster Quorum Settings...
3. En el wizard, seleccionar Select the quorum witness > Configure a cloud witness
4. Introducir:

• Azure Storage account name: nombre de la nueva Storage Account
• Azure Storage account key: key1 o key2 de la nueva SA

1. Finalizar el wizard

El cluster crea automaticamente un blob container llamado msft-cloud-witness en la nueva Storage Account.

Paso 5: Verificacion post-cambio

Tras aplicar la configuracion, verificamos que el cluster ha adoptado la nueva Storage Account:

Get-ClusterResource "Cloud Witness" | Get-ClusterParameter

Resultado esperado:

Object        Name         Value                    Type
------        ----         -----                    ----
Cloud Witness AccountName  newazurestorage01        String
Cloud Witness EndpointInfo  core.windows.net        String

Ademas, verificar en el portal de Azure que el container msft-cloud-witness ha sido creado en la nueva Storage Account.

Ventana de cambio

Consideraciones de seguridad

• Private Endpoint: Al usar Private Endpoint, el trafico entre los nodos y la Storage Account no sale a Internet, permaneciendo dentro de la red privada de Azure
• Rotacion de claves: Planificar rotacion periodica de las Access Keys de la Storage Account
• Monitorizar el witness: Configurar alertas en caso de que el Cloud Witness quede inaccesible (evento 1562 en el Event Log del cluster)

Conclusiones

La migracion del Cloud Witness entre Storage Accounts es una operacion de bajo riesgo que no genera indisponibilidad en el servicio. La clave esta en la preparacion previa: validar reglas de firewall, confirmar la resolucion DNS via Private Endpoint y verificar la conectividad TCP 443 desde todos los nodos antes de ejecutar el cambio.