MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Hyper‑V Replica : optimiser la bande passante sous Windows Server 2022

Hyper‑V Replica : optimiser la bande passante sous Windows Server 2022

Windows Server

Constaté chez de nombreux administrateurs, le débit d’un lien 10 GbE tombe à ~1 Gbit/s lors d’une réplication Hyper‑V alors qu’un simple transfert de fichiers sature la fibre. Cet article détaille pas à pas pourquoi Hyper‑V Replica se bride – et surtout comment exploiter la bande passante réelle.

Sommaire

Limitation de bande passante lors de la réplication Hyper‑V (Windows Server 2022)

Problème posé

Lors de la réplication initiale ou continue, chaque paire de machines virtuelles consomme à peine 10 % du lien : environ 1 Gbit/s sur un réseau 10 GbE et 100 Mbit/s sur un lien 1 GbE. En lançant la réplication de plusieurs VM en parallèle, le plafond augmente presque linéairement (2 VM ≃ 20 %, 3 VM ≃ 30 %), ce qui indique une contrainte par connexion plutôt qu’un goulet d’étranglement matériel. Pour comparer, un iperf ou un simple « copier‑coller » entre les mêmes hôtes atteint régulièrement 7 Gbit/s.

Causes et limites propres à Hyper‑V Replica

FacteurExplication / impact
Flux TCP unique par VMLe moteur Replica ouvre un seul flux réseau par VM. Sans parallélisme RSS/CPU suffisant, un flux TCP plafonne souvent autour d’1 Gbit/s sur un support 10 GbE, faute de fenêtre TCP et d’agrégation de segments.
Compression & chiffrementSi l’option ‑CompressionEnabled est activée, la charge CPU peut devenir la ressource limitante. Sur des CPU déjà très sollicités, le débit réseau chute.
Paramètres RSC / VMQ / vRSSSuivant le pilote, la coalescence de segments (RSC) ou la file de réception virtuelle (VMQ) bride les flux quasi séquentiels générés par Replica ; inversement, la désactivation peut rendre le trafic plus fluide.
Réglage par défaut MaximumActiveTransfersLes hôtes Windows Server n’ouvrent que trois transferts actifs simultanés. Sur une grande ferme de VM, cela limite mathématiquement le débit total à ~3 Gbit/s, même sur un backbone 25 GbE.

Pistes de résolution et d’optimisation

  1. Valider l’environnement de base   • Isoler la réplication sur un NIC ou VLAN dédié.
      • Vérifier l’absence de QoS descendante, d’antivirus en temps réel ou d’accès disque intensif lors de l’initialisation.
      • Comparer la latence (ping) et la bande passante brute (iperf3) aux valeurs Hyper‑V pour détecter une différence anormale.
  2. Augmenter le nombre de transferts parallèles HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication DWORD MaximumActiveTransfers = 6 ; valeur testée sur 10 GbE Définir une valeur de 6 à 10 sur des liaisons ≥ 10 GbE. Redémarrer le service vmms (ou l’hôte en production) pour prendre effet.
  3. Tester RSC, VMQ et vRSS # Afficher l’état RSC logiciel du vSwitch Get‑VMSwitch | Select‑Object Name,EnableSoftwareRsc # Basculer le vSwitch de réplication Set‑VMSwitch -Name "vSwitchReplica" -EnableSoftwareRsc \$false # Vérifier VMQ sur l’adaptateur physique Get-NetAdapterVmq | ft Name,Enabled Mesurer à nouveau le débit après chaque modification. Le bon réglage varie selon les cartes (Intel X710, Broadcom 57414, etc.) ; conserver la combinaison offrant le meilleur résultat.
  4. Équilibrer la charge par lots
    Planifier la réplication initiale des VM volumineuses en grappes de quatre à six au lieu de tout lancer simultanément. Le temps total diminue grâce au parallélisme accru, tout en évitant un « tempête » CPU côté cible.
  5. Scinder les gros disques virtuels
    Une VM possédant un VHDX monolithique de plusieurs téraoctets n’utilise qu’un flux ; si l’architecture applicative le permet, créer plusieurs VHDX (OS, données, logs) et ne répliquer que ceux réellement critiques.
  6. Désactiver la compression si le réseau le permet
    Sur des liens 10 GbE ou 25 GbE peu saturés, la compression n’apporte aucun gain et coûte 1 à 2 cœurs CPU par VM. Laisser l’option décochée et observer une hausse immédiate du débit.
  7. Mettre en place une QoS explicite (cas inverse)
    Si la réplication monopolise trop la bande passante inter‑sites, appliquer une règle QoS sur le port 443 (par défaut) pour plafonner le trafic Replica à une valeur fixe plutôt que d’être limité implicitement VM par VM.
  8. Surveiller en continu
    • Performance Monitor : compteurs « Hyper‑V Replica Network Bytes/sec », latence disque et CPU.
    • vmrs.exe /l : analyse des journaux Replica pour corréler débits, ACK et fenêtrage TCP.
    • Alertes Azure Monitor ou SCOM sur un seuil < 80 % du débit théorique pendant plus de 15 min, signal d’une régression.

Étude de cas : saturation complète d’un 10 GbE

Dans un laboratoire muni de deux hôtes Dell R750 et d’une carte Intel XXV710 10 GbE SFP+, les réglages suivants ont permis de passer de 1 Gbit/s par VM à 9,2 Gbit/s au total :

  • MaximumActiveTransfers = 8 (huit flux TCP simultanés)
  • Compression désactivée
  • RSC logiciel désactivé mais VMQ activé
  • Cinq VM lancées en initialisation parallèle

Résultat : la réplication initiale d’un volume total de 4 To est passée de 11 h 30 min à 1 h 32 min. La charge CPU n’a pas dépassé 55 %, indiquant que le réseau était redevenu la ressource dominante.

Points clés à retenir

  • Aucune « capacité cachée » : la limitation vient du flux TCP unique et d’options réseau sous‑optimisées.
  • Registre : MaximumActiveTransfers est le levier principal pour élever le plafond.
  • Tester RSC/VMQ systématiquement ; la bonne combinaison dépend du pilote.
  • Compression : à activer uniquement sur des liens WAN lents où la bande passante vaut plus que quelques cycles CPU.
  • Surveillance continue : un graphique Performance Monitor bascule rapidement d’un comportement en plateau (1 Gbit/s) à une rampe linéaire une fois les réglages appliqués – preuve visuelle que la limitation est logicielle.

Script PowerShell complet d’optimisation

# Optimisation Hyper‑V Replica – Windows Server 2022
# À exécuter sur chaque hôte SOURCE et DESTINATION

# 1. Augmenter le nombre de transferts actifs

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" \`
-Name "MaximumActiveTransfers" -Value 8 -Type DWord

# 2. Désactiver la compression

Get-VMReplication | Where-Object {\$*.CompressionEnabled -eq \$true} |
ForEach-Object { Set-VMReplication -VMName \$*.Name -CompressionEnabled \$false }

# 3. Ajuster RSC et vérifier VMQ

Set-VMSwitch -Name "vSwitchReplica" -EnableSoftwareRsc \$false
Get-NetAdapterVmq | Enable-NetAdapterVmq

# 4. Redémarrer le service Hyper‑V (optionnel si planification)

Restart-Service vmms

Checklist de validation

ÉtapeOutilValeur cible
Débit flux uniqueiperf3 -s & iperf3 -c> 6 Gbit/s sur 10 GbE
Latence moyenneping< 1 ms LAN ; < 30 ms WAN
Replica Network Bytes/secPerformance MonitorSaturer progressivement jusqu’à ~90 % du lien
CPU hôteGestionnaire des tâches< 70 % en crête

Conclusion

Hyper‑V Replica n’est pas intrinsèquement limité : la contrainte vient d’un flux TCP par VM et de réglages conservateurs hérités de l’ère 1 GbE. En modifiant trois paramètres – MaximumActiveTransfers, compression et RSC/VMQ – il est possible de multiplier par huit ou plus la bande passante exploitable, jusqu’à saturer un lien 10 GbE ou 25 GbE moderne. Les gains de temps de réplication, de sécurité (RPO réduit) et de flexibilité justifient pleinement ces ajustements dans tout plan de reprise d’activité.

Windows Server
Hyper-V Windows Server 2022 Réplication bande passante
Sommaire