Notre entreprise (basée à Paris) a été chargée de mettre en place une solution de sauvegarde pour un client situé à Houston (États-Unis), avec pour objectifs:
- Sauvegarde de l'Hyper-V du client vers une baie de stockage Dell EMC DataDomain située dans notre datacenter de Paris.
- Sauvegarde locale sur un disque USB branché directement sur l’Hyper-V du client.
- Le proxy Veeam est l'Hyper-V du client
Lors de la première sauvegarde complète (Full Backup), nous avons constaté des temps de transfert extrêmement longs, dépassant largement les attentes.
Solution technique : Optimisation de la fenêtre TCP
Méthode de calcul de la fenêtre TCP optimale
Pour maximiser le débit, nous avons appliqué la formule suivante :
Fenêtre TCP optimale (en octets) = Bande passante (octets/s) × Latence (secondes)
Données du lien:
Bande passante : 1 Gbps = 131 072 000 octets/s
Latence mesurée : 123 ms (0,123 s)
Calcul:
Fenêtre optimale = 131 072 000 × 0,123 ≈ **16 121 856 octets**
Nous avons arrondi à 16 776 960 octets (soit 16 Mo) pour une marge de sécurité.
À noter :
La fenêtre TCP par défaut sous Windows est de 65 536 octets (64 Ko).
La fenêtre TCP (ou TCP Window Size) est un paramètre critique qui détermine combien de données peuvent être envoyées avant d’attendre un accusé de réception (ACK).
Sur un lien à haute latence (comme Houston → Paris), une fenêtre trop petite (comme celle par défaut) devient un goulot d’étranglement majeur, car elle empêche le réseau de fonctionner à pleine capacité.
Modification de la fenêtre TCP via la base de registre:
Pour appliquer cette modification, nous avons suivi ces étapes :
Création d’une clé de registre sur le serveur Hyper-V (proxy) :Clé : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowsSize
Valeur : TcpWindowSize
Type : REG_DWORD
Donnée : 16776960 (en décimal)
Redémarrage du serveur pour appliquer les changements.
L'augmentation de la TCP Windows Size peut générer un impact réseau et avoir une incidence sur les autres services en augmentant la latence ou en générant de la perte de paquets (VoIP, applications métiers, etc.). Pour éviter ça nous avons mis en place un throttling pour limiter le débit pendant les heures ouvrées et éviter tout impact en journée.
Ces modifications nous on permit de réduire de 65% le temps de la première full.
Si vous avez rencontré des problèmes similaires avec Veeam ou des solutions de sauvegarde longue distance, n’hésitez pas à me partager vos retours en commentaires !
