Nombre d’adresses IP pour un cluster de basculement Windows Server à 2 nœuds : guide complet et cas concrets

Combien d’adresses IP faut‑il vraiment pour un cluster de basculement Windows Server à 2 nœuds ? Voici le décompte minimal, les variantes (réseaux dédiés, multi‑sous‑réseaux, iSCSI, SQL…), des exemples concrets et des check‑lists pour planifier vos VLAN, DNS et dépendances sans mauvaises surprises.

Sommaire

Contexte et portée

Un cluster de basculement (WSFC) à deux nœuds a besoin d’un petit nombre d’adresses IP pour fonctionner et exposer un point d’entrée aux clients. Ce guide détaille le strict minimum et les scénarios qui augmentent le nombre d’IP : réseaux séparés (production, heartbeat, sauvegarde/réplication), multi‑sous‑réseaux, rôles applicatifs (fichiers, SQL FCI), iSCSI, Cloud/hybride et IPv6.

Réponse rapide : le décompte des IP

Fonction	Adresse(s) IP requise(s)	Commentaires pratiques
Accès hôte (production)	1 IP par nœud (donc 2)	Adresse habituelle de l’OS, inscrite en DNS. Statique recommandée pour les serveurs.
Adresse « Cluster Name Object » (CNO)	1 IP partagée	Point d’entrée client du cluster (`\\NomDuCluster`). Une seule IP (ou une par sous‑réseau si multi‑site ; voir plus bas).
Réseau dédié « heartbeat » (optionnel)	1 IP par nœud (donc 2)	Non routable. Pas d’IP partagée. Souvent remplacé par de la redondance NIC (Teams/SET) sur le réseau de production.
Réseau de sauvegarde / réplication (optionnel)	1 IP par nœud (donc 2)	Utile pour isoler les flux de sauvegarde, de réplication applicative ou Live Migration.
Témoin (witness)	Aucune IP supplémentaire	Disque/partage/cloud witness : l’IP relève du serveur/du service existant, pas d’une ressource cluster.

Totaux typiques

Configuration minimale (réseau unique, pas de heartbeat dédié, pas de réseau de sauvegarde) : 3 IP (2 hôtes + 1 cluster).
Configuration classique avec réseaux séparés : 7 IP (2 production + 2 heartbeat + 2 sauvegarde + 1 CNO).

À retenir : la seule IP véritablement « partagée » côté cluster est celle du CNO. Tout réseau supplémentaire (heartbeat, sauvegarde, réplication, iSCSI) ajoute une IP par nœud.

Décomposition détaillée et bonnes pratiques

Accès hôte (production)

Préférez des adresses statiques et des enregistrements DNS A (ou AAAA en IPv6).
Ouvrez les ports nécessaires au cluster (notamment 3343/UDP pour le cœur de cluster) au niveau du pare‑feu, côté profil Domaine.
Si vous utilisez la redondance NIC, choisissez LBFO Teaming (général) ou SET (environnements Hyper‑V modernes).

Adresse « Cluster Name Object » (CNO) et « Cluster Name »

Le CNO est l’objet ordinateur Active Directory du cluster. Il porte un nom réseau et une ou plusieurs ressources IP.
En mono‑sous‑réseau, une seule IP suffit. En multi‑sous‑réseau, il y aura une IP par sous‑réseau (voir « multi‑site »).
Cette IP ne doit exister que sur le réseau client (production). N’assignez pas d’IP « cluster » sur un réseau privé/isolé.
Activez les mises à jour DNS sécurisées afin que le CNO enregistre/actualise son enregistrement A/AAAA automatiquement.

Réseau « heartbeat » (optionnel)

Non routé, sans passerelle, métrique plus faible que la production (le cluster privilégiera ce réseau pour son trafic interne).
Si vous n’avez pas d’exigence d’isolement, privilégiez la redondance NIC sur la production plutôt qu’un réseau dédié heartbeat.

Réseau de sauvegarde / réplication (optionnel)

Ajoutez 1 IP par nœud si vous isolez ces flux.
Selon l’outil (sauvegarde, Hyper‑V Live Migration, réplication applicative), ajustez la QoS et les métriques réseau.

Témoin (quorum)

Node & File Share Majority : pas d’IP supplémentaire côté cluster.
Cloud Witness : pas d’IP supplémentaire ; veillez simplement à la connectivité sortante.
Pour un cluster à 2 nœuds, un témoin est fortement recommandé pour éviter les splits‑brain.

Ce qui peut changer le compte d’IP

Rôles applicatifs et Client Access Point (VCO)

Chaque rôle clusterisé exposé aux clients (par ex. « File Server pour usage général », SQL Server FCI, impression) crée un VCO (Virtual Computer Object) avec son propre nom réseau et son IP (ou un ensemble d’IP en multi‑sous‑réseau). Cela s’ajoute à l’IP du CNO.

Rôle	IP supplémentaires	Remarques
File Server (usage général)	+1 IP (par CAP)	Un partage de fichiers accessible via un nom réseau dédié.
SQL Server FCI	+1 IP (par instance)	Chaque instance FCI possède un nom réseau client distinct.
Impression, autres rôles	+1 IP (par rôle)	Un CAP par rôle = une IP supplémentaire.
Rôles « sans IP dédiée »	0 IP	Certains scénarios modernes (ex. nom distribué) n’ajoutent pas d’IP ; vérifiez la compatibilité client.

Clusters multi‑sous‑réseaux / multi‑sites

Le CNO et chaque VCO ont une IP par sous‑réseau. On utilise des dépendances « OR » : une seule IP est en ligne à la fois.
DNS peut publier plusieurs enregistrements (un par IP). Réglez un TTL bas pour accélérer la convergence lors d’un basculement inter‑site.

Stockage : iSCSI, SMB, S2D

iSCSI : souvent plusieurs liens redondants par nœud pour le MPIO, chacun avec sa propre IP non routée (par sous‑réseau iSCSI). Ces IP ne sont pas « cluster », mais elles s’additionnent dans votre plan d’adressage.
SMB / S2D : liens est‑ouest intensifs ; on privilégie des réseaux dédiés ou convergés (QoS). Pas d’IP « partagée » supplémentaire, mais 1 IP par nœud et par réseau.

Environnements cloud et virtualisés

Selon le cloud, la ressource « IP Address » peut être remplacée par un mécanisme de load balancer pour le nom réseau d’un rôle (ex. SQL FCI). Dans ce cas, vous ne consommez pas d’IP supplémentaire côté machines, mais une ressource LB côté plateforme.
Dans Hyper‑V, prévoyez des VLAN/ports vSwitch dédiés ou une convergence avec QoS (Live Migration, CSV, SMB, management).

Clusters sans AD (AD‑Detached / Workgroup)

Pas d’objet CNO dans AD, mais le nom réseau du cluster demeure et nécessite une IP sur le réseau client (enregistrement DNS manuel ou dynamique selon le design).

IPv6 et double pile

En IPv6, le cluster publie un AAAA. Le principe ne change pas : 1 IP par nœud et 1 IP partagée (par sous‑réseau si multi‑site).
En double pile, maîtrisez la préférence (IPv6 vs IPv4) côté clients et durcissez la configuration DNS.

Exemples concrets d’adressage

Exemple A — Minimaliste (3 IP)

VLAN10 Production
  NODE1  : 10.10.10.11/24  GW 10.10.10.1
  NODE2  : 10.10.10.12/24  GW 10.10.10.1
  CLUSTER (CNO) : 10.10.10.50/24

Total : 3 IP

Exemple B — Classique (7 IP)

VLAN10 Production
  NODE1  : 10.10.10.11/24  GW 10.10.10.1
  NODE2  : 10.10.10.12/24  GW 10.10.10.1
  CLUSTER (CNO) : 10.10.10.50/24

VLAN20 Heartbeat (pas de GW)
NODE1  : 10.20.20.11/24
NODE2  : 10.20.20.12/24

VLAN30 Sauvegarde (optionnel)
NODE1  : 10.30.30.11/24
NODE2  : 10.30.30.12/24

Total : 7 IP

Exemple C — + Rôle applicatif (File Server) (8 IP)

Base exemple B (7 IP)
+ VCO "FS-PROD" : 10.10.10.60/24 (Client Access Point du rôle File Server)

Total : 8 IP

Exemple D — Multi‑sous‑réseaux (10 IP pour CNO + VCO)

Site A (VLAN10)
  NODE1           : 10.10.10.11/24  GW 10.10.10.1
  CLUSTER (CNO)   : 10.10.10.50/24
  VCO "FS-PROD"   : 10.10.10.60/24

Site B (VLAN110)
NODE2           : 10.110.110.12/24 GW 10.110.110.1
CNO (2e IP)     : 10.110.110.50/24   (dépendance OR)
VCO "FS-PROD"   : 10.110.110.60/24   (dépendance OR)

* éventuels VLAN heartbeat/sauvegarde (1 IP par nœud et par réseau)
  Total pour CNO+VCO en 2 sous-réseaux : 4 IP partagées + 2 IP hôtes = 6 IP (hors réseaux dédiés)
  Total global selon réseaux dédiés : typiquement 10 à 12 IP

Sécurité et DNS : points d’attention

Pas de passerelle sur les réseaux privés (heartbeat, iSCSI). Évitez toute fuite de routage.
DNS dynamique : autorisez le CNO/VCO à créer/mettre à jour ses enregistrements. Sinon, précréez les enregistrements A/AAAA et autorisez la mise à jour sécurisée.
TTL réduit pour les noms publiés sur plusieurs sous‑réseaux ; cela accélère la bascule inter‑site côté clients.
SPN/Authentification : si des services (SMB/SQL/HTTP) s’adossent à un CAP, assurez‑vous que les SPN sont cohérents (évite des erreurs Kerberos).

PowerShell : créer et régler proprement

Création du cluster avec IP statique

New-Cluster -Name CLUS01 -Node SRV1,SRV2 -StaticAddress 10.10.10.50

Ajout d’une IP pour un second sous‑réseau + dépendance « OR »

# Ajouter une IP supplémentaire (ex. sur VLAN110)
Add-ClusterResource -Name "IP-CNO-110" -ResourceType "IP Address" -Group "Cluster Group"
# Définir l'adresse/mask/GW si besoin (adapté à votre réseau)
Set-ClusterParameter -InputObject (Get-ClusterResource "IP-CNO-110") -Name "Address" -Value "10.110.110.50"
Set-ClusterParameter -InputObject (Get-ClusterResource "IP-CNO-110") -Name "SubnetMask" -Value "255.255.255.0"

# Lier le nom réseau du cluster à "IP-Prod OR IP-110"

\$ip1 = "IP Address 10.10.10.50"
\$ip2 = "IP-CNO-110"
Set-ClusterResourceDependency "Cluster Name" "\[\$ip1] or \[\$ip2]"

Réseaux de cluster : rôles et métriques

# Visualiser les réseaux vus par le cluster
Get-ClusterNetwork | Select Name, Role, Metric

# Interdire l'usage cluster sur iSCSI

Set-ClusterNetwork -Name "iSCSI-1" -Role 0

# Autoriser uniquement le trafic cluster (pas clients)

Set-ClusterNetwork -Name "Heartbeat" -Role 1

Bonnes pratiques DNS (selon vos besoins)

# Exemple : publier toutes les IP de fournisseurs (multi-sous-réseaux)
Get-ClusterResource "Cluster Name" | Set-ClusterParameter RegisterAllProvidersIP 1

# Exemple : ajuster le TTL du nom réseau (en secondes)

Get-ClusterResource "Cluster Name" | Set-ClusterParameter HostRecordTTL 300

Check‑list de planification

VLAN/Subnets : listez les réseaux (production, heartbeat, sauvegarde, iSCSI, inter‑site).
IP nécessaires par réseau :
- Hôtes : 1 IP/nœud et par réseau utilisé (production, heartbeat, sauvegarde, iSCSI).
- CNO (cluster) : 1 IP sur le réseau client par sous‑réseau concerné.
- Rôles (VCO/CAP) : +1 IP par rôle et par sous‑réseau concerné.
Passerelles : seulement sur les réseaux routés destinés aux clients/sortie. Aucune passerelle sur heartbeat/iSCSI.
DNS : enregistrements A/AAAA, TTL, mises à jour sécurisées, droits du CNO/VCO.
Quorum : témoin (disque, partage ou cloud) ; pas d’IP cluster supplémentaire.
Firewall : règles entrantes/sortantes (profil Domaine).
Validation : exécutez l’assistant Validate a Configuration avant la mise en production.

FAQ éclair

Peut‑on utiliser DHCP pour l’IP du cluster ?

Techniquement oui (ressource « IP Address (DHCP) »), mais en production il est fortement recommandé d’utiliser une IP statique pour garantir la stabilité DNS et des SPN.
Dois‑je conserver un réseau « heartbeat » dédié ?

Pas obligatoire : la tendance actuelle est la redondance NIC (Teams/SET) et la QoS sur un réseau convergé. Un heartbeat dédié reste pertinent si vous avez des contraintes d’isolement ou de performance spécifiques.
Le témoin nécessite‑t‑il des IP supplémentaires côté cluster ?

Non. Le témoin utilise l’IP du serveur de fichiers (file share witness), du SAN (disk witness) ou un service externe (cloud witness).
Quid des IP pour les machines virtuelles Hyper‑V ?

Chaque VM a son adresse IP, indépendante des IP du cluster. N’intégrez pas les IP des VM dans le décompte « cluster ».
En multi‑site, combien d’IP pour le même nom de cluster ?

Une IP par sous‑réseau. La ressource « Cluster Name » dépend de ces IP en OR. Une seule IP est en ligne à un instant donné.
Et l’IPv6 ?

Même logique. Les adresses et enregistrements DNS passent en IPv6 (AAAA). En double pile, assurez-vous de l’ordre de préférence et de la cohérence DNS.

Erreurs fréquentes (et correctifs)

Passerelle définie sur le heartbeat : retirez‑la pour éviter le routage indésirable.
IP « cluster » configurée sur un réseau non client : conservez l’IP du CNO uniquement sur le réseau accessible aux clients.
Métriques réseau inadaptées : vérifiez/ajustez avec Get-ClusterNetwork et Set-ClusterNetwork.
DNS figé (pas de mises à jour) : accordez les droits au CNO/VCO ou passez par une précréation des enregistrements.
Oubli des IP iSCSI/MPIO dans le plan d’adressage : réservez des blocs dédiés par nœud et par chemin.

Récapitulatif clair

Minimum absolu (2 nœuds, 1 réseau client) : 3 IP (2 hôtes + 1 CNO).
Avec réseaux séparés (production + heartbeat + sauvegarde) : 7 IP.
Par rôle exposé (File Server, SQL FCI…) : +1 IP (par rôle et par sous‑réseau).
Multi‑sous‑réseaux : le CNO et chaque rôle ont 1 IP par sous‑réseau (dépendances OR).
Témoin : 0 IP supplémentaire côté cluster.

Annexe : modèle de calcul rapide

Soit :

N = nombre de nœuds (ici 2)
R = nombre de réseaux utilisés par les nœuds (production = toujours 1 ; ajouter heartbeat, sauvegarde, iSCSI…)
S = nombre de sous‑réseaux clients (mono‑site = 1, multi‑site ≥ 2)
A = nombre de rôles exposés (CAP/VCO)

Alors :

Total_IP_Hôtes = N × R
Total_IP_CNO   = S
Total_IP_Rôles = A × S
Total_Général  = (N × R) + S + (A × S)

En configuration minimale : N=2, R=1, S=1, A=0 ⇒ 3 IP.

Conclusion

Pour un cluster WSFC à 2 nœuds, 3 adresses IP suffisent si vous restez sur un seul réseau client : une par hôte et une partagée pour le CNO. Chaque réseau supplémentaire ajoute 1 IP par nœud et chaque rôle exposé (CAP/VCO) ajoute 1 IP partagée (par sous‑réseau). En planifiant avec méthode — VLANs, DNS dynamique, dépendances OR, pas de passerelle sur les réseaux privés — vous évitez les pièges classiques et obtenez un cluster propre, stable et prêt pour la production.

Nombre d’adresses IP pour un cluster de basculement Windows Server à 2 nœuds : guide complet et cas concrets