Stai progettando un cluster di failover a due nodi in Windows Server e vuoi capire quanti indirizzi IP sono davvero necessari? In breve: per partire bastano tre IP statici. Il resto dipende da reti dedicate e dai ruoli che pubblicherai in rete.
Panoramica rapida: quanti indirizzi IP servono
Nel caso più semplice (due nodi sulla stessa rete di produzione) gli indirizzi indispensabili sono solo tre: uno per ciascun nodo e uno per l’oggetto cluster. Tutto il resto è opzionale o dipende dai servizi che intendi esporre.
| Scopo | IP indispensabili | Note operative |
|---|---|---|
| Gestione dei nodi | 1 IP statico per ciascun nodo (tot. 2) | Connettività normale verso AD, DNS, RDP, gestione remota e aggiornamenti. È l’IP primario della NIC “di produzione”. |
| Indirizzo del cluster | 1 IP statico | Associato al Cluster Name Object (CNO). Serve per amministrare l’intero cluster e per la risoluzione del nome del cluster. |
| Reti aggiuntive (heartbeat, backup, storage, replica) | Facoltativi | Se hai NIC dedicate, è consigliato separare il traffico di heartbeat e quello di backup/storage, ma non è un requisito. In assenza di reti dedicate, il cluster usa la rete di produzione per tutto. |
Totale minimo obbligatorio: 3 indirizzi IP statici (2 per i nodi + 1 per il cluster).
Perché bastano tre IP e quando ne servono altri
Windows Server Failover Clustering (WSFC) rileva automaticamente tutte le reti disponibili e seleziona quelle utilizzabili per il traffico di cluster (cluster communications) e, se permesso, anche per il traffico client. Se esiste una sola rete, quella viene usata sia per client/server traffic sia per il heartbeat. Per questo motivo non è richiesto un IP “dedicato” al solo heartbeat.
Al contrario, ogni ruolo in cluster che debba essere raggiungibile dai client (File Server, SQL Server FCI, DHCP, MSMQ, ecc.) avrà bisogno di un proprio indirizzo IP virtuale (VIP), e spesso anche di un proprio nome DNS. Questi IP sono aggiuntivi rispetto ai tre minimi e vanno calcolati a parte in base al numero di ruoli/istanze che pianifichi.
Sfatiamo alcuni equivoci comuni
- IP heartbeat dedicato: non serve. Il cluster usa una o più reti esistenti per i pacchetti di monitoraggio, senza bisogno di un indirizzo “in più”.
- IP rete di backup “unico”: se crei una rete di backup dedicata, in genere ogni nodo riceve un IP su quella rete (quindi due IP, non uno); il cluster di solito non espone un VIP su quella rete.
- Witness: file share witness, disk witness o cloud witness non richiedono un nuovo IP del cluster. Il file server che ospita il witness ha i propri IP già esistenti.
Schemi di rete tipici
Scenario base su singola rete
Due nodi sulla stessa VLAN/subnet di produzione. È lo scenario più diffuso e più semplice da gestire.
- IP necessari: 2 (nodi) + 1 (cluster) = 3 IP.
- Il traffico di heartbeat e di gestione passa sulla stessa rete.
Scenario con rete dedicata per heartbeat e backup
Oltre alla rete di produzione, aggiungi una seconda VLAN dedicata a cluster heartbeat e, facoltativamente, ai job di backup.
- IP necessari: 2 IP di produzione (nodi) + 1 IP del cluster + 2 IP sulla rete dedicata (uno per nodo) = 5 IP totali nel sistema, di cui sempre 3 indispensabili per il cluster vero e proprio.
- Non si crea normalmente un VIP del cluster sulla rete di heartbeat; si imposta la rete come “Cluster Only”.
Scenario con storage iSCSI dedicato
Se il quorum o i dischi condivisi sono su iSCSI, normalmente usi NIC e subnet dedicate, una o più per nodo, senza default gateway.
- Ogni NIC iSCSI riceve un IP per nodo (non è un IP del cluster).
- La/e rete/i iSCSI devono essere marcate come “None” per evitare traffico client o cluster su questi segmenti.
Scenario multi subnet o geograficamente esteso
Se i due nodi si trovano in subnet diverse, il nome del cluster può avere più IP (uno per subnet) con dipendenza logica OR. Il cluster attiva l’IP della subnet corrente e disattiva gli altri; i client risolvono più record A in DNS e raggiungono quello attivo.
- IP necessari: 2 (nodi) + uno per ogni subnet per il nome cluster.
- I ruoli applicativi multi subnet richiedono a loro volta un IP per subnet.
Pianificazione degli indirizzi: esempi pratici
Scenario base
| Elemento | Esempio indirizzo | Subnet/VLAN | Note |
|---|---|---|---|
| Nodo 1 | 10.10.10.21 | 10.10.10.0/24 | IP statico, default gateway presente |
| Nodo 2 | 10.10.10.22 | 10.10.10.0/24 | IP statico, default gateway presente |
| Cluster (CNO) | 10.10.10.30 | 10.10.10.0/24 | VIP del cluster, registrato in DNS |
Scenario con rete dedicata per heartbeat/backup
| Elemento | Esempio indirizzo | Subnet/VLAN | Note |
|---|---|---|---|
| Nodo 1 produzione | 10.10.10.21 | 10.10.10.0/24 | Default gateway presente |
| Nodo 2 produzione | 10.10.10.22 | 10.10.10.0/24 | Default gateway presente |
| Cluster (CNO) | 10.10.10.30 | 10.10.10.0/24 | VIP del cluster |
| Nodo 1 heartbeat/backup | 10.20.20.21 | 10.20.20.0/24 | Senza default gateway |
| Nodo 2 heartbeat/backup | 10.20.20.22 | 10.20.20.0/24 | Senza default gateway |
Scenario multi subnet
| Elemento | Esempio indirizzo | Subnet/VLAN | Note |
|---|---|---|---|
| Nodo 1 | 10.10.10.21 | 10.10.10.0/24 | Sito A |
| Nodo 2 | 10.30.30.22 | 10.30.30.0/24 | Sito B |
| Cluster (CNO) – IP Sito A | 10.10.10.30 | 10.10.10.0/24 | Dipendenza OR |
| Cluster (CNO) – IP Sito B | 10.30.30.30 | 10.30.30.0/24 | Dipendenza OR |
Guida operativa con PowerShell
Prerequisiti
- Entrambi i nodi con Windows Server supportato, patch aggiornate, driver di rete allineati.
- IP di gestione dei nodi configurati come statici o con prenotazione DHCP permanente.
- Nodi uniti al dominio Active Directory e correttamente risolvibili in DNS.
- Se presenti reti iSCSI o di backup, NIC su subnet dedicate e senza default gateway (usa route statiche se serve).
- Permessi per creare il Cluster Name Object e i relativi record DNS, oppure oggetti pre-staged.
Creazione del cluster
# Esegui dal nodo che preferisci
Import-Module FailoverClusters
Validazione (fortemente consigliata)
Test-Cluster -Node SRVCL01, SRVCL02
Creazione del cluster con IP statico del CNO
New-Cluster -Name CLUS-FS01 -Node SRVCL01, SRVCL02 -StaticAddress 10.10.10.30 -NoStorage
Verifica stato e nome
Get-Cluster
Get-ClusterNetwork | Format-Table Name, Address, Role, Metric Impostazione dei ruoli delle reti
Definisci cosa può transitare su ogni network: ClusterAndClient (traffico client e cluster), ClusterOnly (solo cluster/heartbeat), None (niente traffico cluster né client, tipico di iSCSI).
# Esempio: rete di produzione = ClusterAndClient
Set-ClusterNetwork -Name "Produzione" -Role 3
Esempio: rete dedicata heartbeat/backup = ClusterOnly
Set-ClusterNetwork -Name "HB-Backup" -Role 1
Esempio: rete iSCSI = None (evita traffico cluster su iSCSI)
Set-ClusterNetwork -Name "iSCSI" -Role 0
Controllo metriche e priorità
Get-ClusterNetwork | Sort-Object Metric | Format-Table Name, Role, Metric
Il cluster sceglie la rete con metrica più bassa per le comunicazioni interne: assicurati che la rete dedicata all’heartbeat abbia metrica più favorevole rispetto alla produzione. Se necessario, regola le proprietà delle reti dal Failover Cluster Manager.
Creazione di un ruolo che espone un VIP
Ogni servizio che deve essere raggiunto dai client ottiene il proprio IP virtuale. Esempio con un file server in cluster:
# Aggiunta di un File Server generale con VIP dedicato
Add-ClusterFileServerRole -Name "FS-Virtual" -StaticAddress 10.10.10.60
Verifica
Get-ClusterResource Per SQL Server FCI o altri ruoli, la logica è la stessa: prevedi uno o più VIP (uno per subnet in presenza di cluster estesi).
Best practice di rete
- Almeno due reti migliorano la resilienza: produzione + heartbeat/backup, oppure produzione + storage iSCSI. In assenza di NIC dedicate, il cluster funziona comunque con una sola rete.
- IP statici o riservati: evita il rinnovo DHCP sugli IP del cluster e dei nodi per non innescare failover indesiderati.
- Priorità dell’heartbeat: assegna “ClusterOnly” alla rete dedicata e mantieni la produzione come “ClusterAndClient”. In caso di more rete, il cluster userà la rete di produzione come fallback.
- DNS e firewall: il VIP del cluster e i VIP dei ruoli devono registrare record A e poter comunicare sulle porte richieste (RPC dinamiche, SMB, WMI, ecc.).
- Gateway e metriche di OS: impostare un solo default gateway sulla rete di produzione; sulle reti di servizio (iSCSI, HB) usa route statiche se serve raggiungere host specifici.
Come calcolare correttamente il fabbisogno IP
Puoi ragionare così:
- Base cluster: 2 IP per i nodi + 1 IP per il CNO = 3 IP.
- Reti dedicate: per ogni rete aggiuntiva, aggiungi 1 IP per nodo su quella subnet (di solito senza VIP).
- Ruoli applicativi: 1 VIP per ciascun ruolo che espone un nome/servizio in rete; in cluster multi subnet, 1 VIP per ciascuna subnet.
Esempio: cluster con due nodi, rete di produzione + rete heartbeat/backup, un file server in cluster.
- Base cluster: 3 IP.
- Rete heartbeat/backup: 2 IP (uno per nodo) → totale 5.
- File server: 1 VIP → totale 6 IP.
Domande frequenti
Serve davvero un IP per il solo heartbeat?
No. Il cluster usa una o più reti già presenti; non c’è un “IP heartbeat” distinto. Se imposti una rete dedicata, saranno gli IP delle NIC dei nodi su quella rete a veicolare l’heartbeat.
Devo per forza creare una rete di backup separata?
No. È una scelta d’infrastruttura, non un requisito del cluster. Se esegui job di backup pesanti e puoi isolare il traffico, conviene. Ricorda che su quella rete assegnerai un IP a ciascun nodo e nessun VIP del cluster.
I ruoli in cluster condividono l’IP del cluster?
No. Ogni ruolo che espone un servizio ai client usa un proprio VIP (e un proprio nome). Questo permette al cluster di muovere il servizio tra i nodi senza cambiare indirizzo lato client.
Il witness richiede un altro IP del cluster?
No. Il witness sfrutta risorse già esistenti (file share, LUN o storage in cloud). Non aggiunge VIP al cluster.
Posso usare DHCP?
È supportato con riservazioni permanenti, ma per stabilità e prevedibilità la raccomandazione è usare IP statici sia per i nodi sia per il VIP del cluster e per i VIP dei ruoli.
Errori comuni e come evitarli
- DHCP senza riserva: può generare rinnovi che innescano failover o perdita temporanea di connettività. Usa statici o prenotazioni.
- DNS non aggiornato: il VIP del cluster deve registrarsi in DNS; verifica creazione/permessi del CNO e dei relativi record.
- Gateway su reti di servizio: non impostare default gateway sulle reti iSCSI/heartbeat; usa al massimo route statiche verso target specifici.
- Rete iSCSI usata dal cluster: marca le reti iSCSI come “None” per non far passare traffico cluster/client su quei segmenti.
- Priorità reti non ottimizzata: se la rete di produzione ha metrica più favorevole, l’heartbeat la userà per prima. Imposta correttamente le metriche o i ruoli delle reti.
- VIP mancanti per i ruoli: ricordati di calcolare e prenotare in anticipo i VIP per i servizi che intendi clusterizzare.
- Subnet multi sito non pianificate: in ambienti estesi prevedi un IP per subnet sia per il CNO sia per i ruoli, con dipendenze OR.
Checklist di validazione
- IP statici dei nodi configurati e raggiungibili, con DNS inversa quando possibile.
- VIP del cluster definito e registrato in DNS.
- Failover Cluster Manager: reti correttamente classificate (ClusterAndClient, ClusterOnly, None).
- Test-Cluster completato senza errori bloccanti.
- Firewall aggiornato per RPC/WMI/SMB e porte richieste dai ruoli.
- Failover di prova dei ruoli tra i nodi con verifica di tempi e continuità lato client.
Appendice su porte e protocolli
Il cluster usa comunicazioni RPC dinamiche, SMB e WMI per varie funzioni di controllo e gestione; i ruoli aggiuntivi (ad esempio file server o SQL Server) richiedono le proprie porte applicative. In ambienti segmentati, pianifica regole firewall tra i nodi e verso i client affinché VIP cluster e VIP dei ruoli siano raggiungibili.
Riepilogo
Per creare un cluster di failover a due nodi in Windows ti bastano tre IP statici: uno per ciascun nodo e uno per il cluster. Tutto il resto — reti dedicate per heartbeat/backup, IP per storage iSCSI e VIP dei ruoli — dipende dalla topologia e dai servizi che vuoi pubblicare. Se aggiungi una rete, aggiungi un IP per nodo su quella rete; se aggiungi un ruolo che espone un nome/servizio, aggiungi un VIP. Con questa griglia di lettura, puoi dimensionare in modo affidabile il fabbisogno di indirizzi senza sprechi e senza sorprese in fase di messa in esercizio.
Riferimento utile: consulta la documentazione ufficiale su requisiti hardware e opzioni di rete per Failover Clustering in Microsoft Learn per confermare linee guida, limiti supportati e migliori pratiche aggiornate.
Conclusione operativa: per partire con un cluster a due nodi è sufficiente prenotare tre indirizzi IP statici (nodo 1, nodo 2, cluster). Pianifica poi, secondo necessità, gli IP aggiuntivi per NIC dedicate e i VIP per i ruoli applicativi che intendi clusterizzare.