Guida completa e pratica per configurare un fail‑over tra due server fisici Windows Server 2019 identici, senza storage esterno, senza hypervisor e senza dominio Active Directory. Soluzione adatta ai piccoli ambienti che richiedono alta disponibilità con costi e complessità contenuti.
Obiettivo e scenario
L’obiettivo è garantire la continuità operativa di un’applicazione installata su due server fisici gemelli, membri di un workgroup, sfruttando Windows Server Failover Clustering (WSFC) in modalità senza Active Directory e senza storage condiviso. Il cluster gestirà il punto di accesso client (IP/nome) e il ruolo applicativo, mentre i dati verranno mantenuti coerenti tramite replica applicativa o, in alternativa, con Storage Spaces Direct (S2D) basato su dischi locali.
Architettura di riferimento
- Nodi:
Srv1eSrv2con Windows Server 2019 (edizione Standard o Datacenter). - Reti:
- Rete client/gestione (≥ 1 GbE; consigliato 10 GbE per S2D/replica).
- Rete di heartbeat e traffico cluster (dedicata o VLAN separata).
- IP del cluster:
192.168.10.50(statico) pubblicato tramite record DNS A statico sul resolver che usano i client. - Quorum witness (obbligatorio in un cluster a 2 nodi):
- File Share Witness su terzo server/NAS:
\\NAS01\Witness, oppure - Cloud Witness su Azure Storage.
- File Share Witness su terzo server/NAS:
- Storage dati:
- Shared‑nothing: replica a cura dell’applicazione o di job di sincronizzazione.
- Storage Spaces Direct (S2D): pool condiviso creato aggregando i dischi locali (edizione Datacenter).
Prerequisiti e note importanti
| Requisito | Dettagli | Note operative |
|---|---|---|
| Edizione OS | Windows Server 2019 Standard o Datacenter su entrambi i nodi | WSFC è incluso a partire da Standard; S2D richiede Datacenter |
| Rete | Almeno 1 GbE; NIC dedicate per heartbeat/replica consigliate | Per S2D o repliche intense, preferire ≥10 GbE (RDMA opzionale) |
| Workgroup | Cluster senza AD supportato da Windows Server 2016 in poi | Autenticazione intra‑cluster con certificati auto‑generati |
| DNS | Record A statico per il nome del cluster (es. CLU-SRV) | In assenza di AD, il cluster non registra record in modo sicuro |
| Account locali | Stesso utente/password su Srv1 e Srv2 se richiesti dall’app | Necessario anche per accedere a un File Share Witness su NAS/terzo server |
| Firewall | Abilitare le regole “Failover Clustering” e condivisione file | Aprire anche RPC/WMI e WinRM per gestione remota |
| Tempo | Sincronizzazione NTP coerente su entrambi i nodi | Evita falsi positivi di heartbeat e problemi di certificati |
Tabella riassuntiva della soluzione
| Passo | Cosa fare | Dettagli utili |
|---|---|---|
| Verifica prerequisiti | Confermare edizione OS, rete e DNS | WSFC incluso da Standard |
| Abilitare il ruolo Failover Clustering | Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools su entrambi i nodi | Richiede riavvio |
| Validare l’ambiente | Test-Cluster -Node Srv1,Srv2 | Ignorare i test su Domain Controller se in workgroup |
| Creare il cluster workgroup | New-Cluster -Name CLU-SRV -Node Srv1,Srv2 -StaticAddress 192.168.10.50 -NoStorage | Autenticazione interna tramite certificati auto‑generati |
| Configurare il quorum (witness) | Set-ClusterQuorum -FileShareWitness "\\NAS01\Witness" oppure Set-ClusterQuorum -CloudWitness -AccountName <AzureStorage> | Testa l’assenza di “split‑brain” in un cluster a 2 nodi |
| Gestire lo storage dati | Replica applicativa o S2D con dischi locali | Senza SAN; garantire coerenza dati al cambio nodo |
| Creare il ruolo applicativo | Da Failover Cluster Manager → Ruoli → Configura ruolo | “Servizio/Applicazione generica” o ruolo specifico (IIS, File Server, …) |
| Testare il failover | Spostare a caldo e simulare fault | Move-ClusterGroup e spegnimento nodo |
Procedura passo‑passo (PowerShell + GUI)
Abilitare WSFC e riavviare
# Su ciascun nodo (o in remoto se WinRM è abilitato)
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
Restart-Computer
Validare i nodi
Esegui la validazione ufficiale del cluster. In workgroup vedrai avvisi legati all’assenza di controller di dominio: non sono bloccanti per il nostro scenario.
Test-Cluster -Node Srv1,Srv2 -Verbose
Creare il cluster senza storage
New-Cluster -Name CLU-SRV -Node Srv1,Srv2 -StaticAddress 192.168.10.50 -NoStorage
DNS: crea un record A statico per CLU-SRV => 192.168.10.50 nel DNS utilizzato dai client (oppure, per test, aggiungilo temporaneamente al file hosts dei client). In un cluster senza AD il CNO non esiste e la registrazione DNS sicura non è automatica.
Impostare il quorum con witness
In un cluster a 2 nodi il witness è indispensabile per garantire il mantenimento del servizio in caso di perdita di connettività tra i nodi.
- File Share Witness (su NAS/terzo server):
- Creare la share
\\NAS01\Witnesscon permessi di lettura/scrittura a un utente locale (es.clusvc). - Su ciascun nodo, salvare le credenziali verso il NAS (necessario in workgroup):
cmdkey /add:NAS01 /user:clusvc /pass:Password!Fort3 - Applicare la configurazione:
Set-ClusterQuorum -FileShareWitness "\\NAS01\Witness"
- Creare la share
- Cloud Witness (Azure Storage):
- Disporre di un account di archiviazione e della relativa access key.
- Eseguire:
Set-ClusterQuorum -CloudWitness -AccountName "mystorageacct" -AccessKey "xxxxxxxxxxxxxxxx"
Ottimizzare rete e heartbeat
Verifica e assegna i ruoli alle reti: una per i client (Cluster and Client), una per heartbeat (Cluster Only).
Get-ClusterNetwork | Format-Table Name, Address, Role, Metric
Esempio: segnare “HB” come rete solo cluster
(puoi farlo anche da GUI: Proprietà della rete → “Consenti comunicazioni cluster”)
Consigliato: disabilita NetBIOS legacy sulle NIC non necessarie, lascia attive le regole firewall “Failover Clustering” e “File and Printer Sharing”.
Gestione dei dati: replica o S2D
Opzione A — Replica shared‑nothing
Il cluster gestisce il punto di accesso e il processo/servizio, mentre la coerenza dei dati è responsabilità dell’applicazione o di un meccanismo di sincronizzazione file. Opzioni tipiche:
- Replica integrata dell’applicazione (database o middleware che mantengono copie coerenti).
- Robocopy pianificato con mirror e retry ridotti per contenuti file‑based:
robocopy D:\Dati \\Srv2\Dati$ /MIR /R:1 /W:1 /FFT /Z /XD temp *.bak - Soluzioni di replica di terze parti (sincrone o asincrone) con supporto a failover controllato.
Attenzione: tecnologie come DFS Replication richiedono un dominio AD e non sono disponibili in workgroup. Anche alcune funzionalità di database con failover automatico (es. determinati profili di Always On Availability Groups) prevedono dipendenze da AD; in workgroup valuta alternative supportate dall’edition del DB (repliche clusterless/read‑scale, log shipping, repliche sincrone del vendor, ecc.).
Opzione B — Storage Spaces Direct (S2D)
S2D aggrega i dischi locali dei due nodi in un pool condiviso gestito dal cluster. Requisiti chiave:
- Edizione Datacenter.
- Almeno un SSD/NVMe per nodo come cache; traffico interno preferibilmente ≥10 GbE.
- Con 2 nodi, resilienza a 2‑way mirror (overhead di capacità ~50%).
Sequenza di massima (semplificata, eseguire solo se hardware convalidato):
# Verifica dischi candidati al pool (nessuna partizione)
Get-PhysicalDisk | Where-Object CanPool -eq $true
Abilita S2D sul cluster
Enable-ClusterS2D -Confirm:$false
Crea volume CSV ReFS (esempio 500 GB)
$pool = Get-StoragePool -FriendlyName "S2D on CLU-SRV"
New-Volume -StoragePoolFriendlyName $pool.FriendlyName -FriendlyName "Vol-Dati" -FileSystem CSVFS_ReFS -Size 500GB
Controllo stato
Get-ClusterStorageSpacesDirect
Get-Volume | Where-Object FileSystemLabel -eq "Vol-Dati" Le cartelle applicative andranno create sul volume CSV (es. C:\ClusterStorage\Volume1\AppData) e referenziate nel ruolo cluster.
Creare il ruolo applicativo
Apri Failover Cluster Manager → Ruoli → Configura ruolo e scegli:
- Servizio o applicazione generica se il software non è cluster‑aware (tipico per servizi Windows custom).
- Ruolo specifico se disponibile (IIS, File Server generico, ecc.).
Esempio con servizio Windows generico:
# Crea un ruolo cluster che monitora un servizio esistente “MyService”
Add-ClusterGenericServiceRole -ServiceName "MyService" -Name "APP-Role"
Configura l’indirizzo IP del punto di accesso client creato dal wizard
$ip = Get-ClusterResource | Where-Object {$_.ResourceType -eq "IP Address"}
$ip | Set-ClusterParameter -Multiple @{ Address="192.168.10.60"; SubnetMask="255.255.255.0" }
(Opzionale) Imposta preferenze di proprietà e failover
- tentativi di restart prima del failover
(Get-ClusterResource -Name "APP-Role").SetPrivateProperty("RestartThreshold", 3)
(Get-ClusterResource -Name "APP-Role").SetPrivateProperty("RestartPeriod", 900)
- limite di failover del gruppo in un intervallo di tempo
Set-ClusterGroup -Name "APP-Role" -FailoverThreshold 2 -FailoverPeriod 7200 Imposta eventuali dipendenze (nome rete → IP → servizio) e verifica che la cartella dati punti a una posizione replicata/coerente (replica propria o CSV se usi S2D).
Test di failover e collaudo
- Failover pianificato: sposta il ruolo in modo controllato.
Move-ClusterGroup -Name "APP-Role" -Node Srv2 - Fault simulato: arresta temporaneamente
Srv1o blocca la NIC di gestione. Il ruolo deve avviarsi suSrv2e mantenere la raggiungibilità del punto di accesso (IP/nome cluster). - Verifica client: i client devono rimanere connessi o riconnettersi automaticamente all’IP/nome del cluster senza cambiare configurazioni locali.
Per indagini approfondite:
# Genera i log del cluster (ultime 1 ora) in locale
Get-ClusterLog -UseLocalTime -TimeSpan 1 -Destination C:\ClusterLogs
Stato risorse e gruppi
Get-ClusterResource
Get-ClusterGroup Punti di attenzione e limiti (workgroup)
- Assenza di AD: autenticazione intra‑cluster via certificati; niente Kerberos. Alcuni ruoli avanzati non sono supportati (es. Scale‑Out File Server, scenari multi‑sito avanzati) o richiedono dominio.
- Witness obbligatorio: in un cluster a 2 nodi il terzo voto evita lo split‑brain; senza witness, un’interruzione di rete porta all’arresto del cluster.
- Replica dati: evitiamo il data loss. In assenza di S2D, la replica dev’essere garantita dall’app o da job affidabili (e con quiescing quando serve).
- Licensing: S2D richiede Datacenter; per cluster “solo servizio” è sufficiente Standard. Verifica anche i requisiti di licenza dell’applicazione (edizioni HA).
- Prestazioni di rete: separare client e replica/heartbeat e, se possibile, usare NIC/stack dedicati (QoS/RDMA) per evitare colli di bottiglia.
- Backup: il clustering non è una strategia di backup. Pianifica backup consistenti di dati e configurazioni (incluso System State e bare‑metal).
- DNS e SPN: in workgroup, i client usano NTLM/SMB; cura le autorizzazioni e la sicurezza degli accessi alle risorse condivise.
Best practice operative
- Allineamento patch: applica gli aggiornamenti su un nodo per volta, spostando i ruoli prima del riavvio.
- Manutenzione programmata: usa Pause del nodo in Cluster Manager prima dei lavori (drain dei ruoli) e poi Resume.
- Health check: monitora Cluster Validation Report, eventi FailoverClustering e saturazioni NIC/disco.
- Metriche di failover: imposta soglie di restart/failover coerenti con i tempi di warm‑up della tua app (cache, pool, cold start).
- Documentazione: registra IP, reti, dipendenze risorse, posizione witness, versioni e procedure di DR.
Checklist di messa in produzione
- [ ] Entrambi i nodi hanno WSFC e riavvio completato.
- [ ] Report Test‑Cluster senza errori bloccanti.
- [ ] Cluster creato con
-NoStoragee IP statico assegnato. - [ ] Record DNS A per il nome del cluster creato e risolvibile dai client.
- [ ] Witness operativo (File Share o Cloud) con test di disconnessione riuscito.
- [ ] Replica dati verificata (o S2D attivo e CSV montati).
- [ ] Ruolo applicativo creato con dipendenze e soglie corrette.
- [ ] Test di failover pianificato e di fault riusciti.
- [ ] Piano di backup e ripristino aggiornato e testato.
Domande frequenti
Posso usare questo cluster per un file server scalabile?
Il ruolo Scale‑Out File Server richiede AD e Kerberos; in workgroup non è supportato. Puoi usare il File Server generico ma verifica attentamente autenticazioni e permessi.
Serve per forza il witness con 2 nodi?
Sì. Senza terzo voto, alla perdita di connettività il cluster non può determinare chi mantiene il servizio e si arresta per sicurezza.
La mia applicazione non è cluster‑aware: posso comunque proteggere il servizio?
Spesso sì: usa il ruolo Servizio/Applicazione generica, cura i prerequisiti (path dati, dipendenze, script di start/stop), e testa bene il riavvio su nodo alternativo.
Quando ha senso S2D a 2 nodi?
Quando vuoi eliminare la replica dati a carico dell’app e centralizzare su CSV/ReFS. Richiede Datacenter, hardware validato e rete performante; considera l’overhead di capacità (mirror 2‑way).
Come gestisco il DNS senza dominio?
Crea un record A statico per il nome del cluster sul DNS che usano i client. In assenza di server DNS, valuta un piccolo resolver locale o, per test, il file hosts dei client.
Esempio completo: dal nulla al fail‑over funzionante
- Prepara i nodi: patch, driver storage/NIC, NTP e hostname (
Srv1,Srv2). - Installa WSFC e riavvia.
- Valida con
Test-Cluster. - Crea cluster
CLU-SRVcon IP192.168.10.50e record DNS A statico. - Configura quorum con File Share Witness su
\\NAS01\Witness(credenziali salvate concmdkey). - Se usi S2D: abilita e crea un volume CSV ReFS per i dati applicativi.
- Crea il ruolo “APP-Role” per il tuo servizio, con restart/failover policy adeguate.
- Esegui i test:
Move-ClusterGroup, simulazione di fault e verifica trasparenza lato client. - Produzione: monitora eventi, prestazioni, backup; definisci mantenimento periodico.
Ottimizzazioni e suggerimenti avanzati
- Dipendenze intelligenti: se l’app usa un listener TCP dedicato, crea la dipendenza del servizio dall’IP e dal nome rete per evitare avvii “a metà”.
- Script di salute: molte app non espongono esiti d’avvio realistici; usa Generic Script o azioni PostStart per verifiche applicative (es. richiesta HTTP di check).
- Log centralizzati: esporta regolarmente
Get-ClusterLoge gli eventi applicativi per accelerare il troubleshooting. - Sicurezza: disabilita SMBv1, usa NTLMv2, restringi gli scope di firewall alle subnet richieste, ruota periodicamente le password degli account locali condivisi.
Approfondimenti consigliati (titoli)
- Workgroup and Multi‑domain clusters in Windows Server 2016/2019
- Create a failover cluster – guida passo‑passo
- Configure and manage the quorum in a failover cluster
- Storage Spaces Direct overview – requisiti e resilienza
Conclusioni
Con la configurazione proposta ottieni un cluster a 2 nodi senza dominio e senza storage esterno capace di ridurre drasticamente i tempi di inattività dell’applicazione. Il cluster fornisce un punto di accesso stabile (IP/nome), orchestra l’avvio e il riavvio del servizio e gestisce il failover; la coerenza dei dati è garantita dalla replica applicativa o, se preferisci, dall’adozione di S2D. Con un witness esterno e una rete ben dimensionata, la soluzione è robusta, ripetibile e sostenibile per ambienti SMB e dipartimentali.