Réplication ZFS sur WAN : accélérer les envois sur des liaisons lentes

janvier 19, 2026 • février 3, 2026 • Lecture : 27 min • Views: 8

Cet article vous a aidé ?

La réplication sur WAN est le moment où ZFS cesse d’être une simple fonctionnalité de système de fichiers et devient un test de personnalité opérationnel. Localement, zfs send | zfs recv ressemble à un tapis roulant. Sur une liaison à 50–200 ms avec perte de paquets et des middleboxes « utiles », cela devient une machine à flipper : le débit s’effondre, le CPU monte en charge, SSH cale et votre RPO commence à négocier avec la réalité.

Ceci est un guide de terrain pour rendre les envois ZFS rapides sur des liaisons lentes sans transformer votre plateforme de stockage en foire scientifique. Il est écrit pour ceux qui transportent des octets pour vivre : SRE, ingénieurs stockage et le malheureux en astreinte qui a hérité une « réplication simple » qui ne marche que quand personne ne regarde.

1. Le modèle mental de la réplication WAN

Les performances de réplication ZFS ne se résument pas à un seul réglage. C’est un pipeline avec des contraintes concurrentes : I/O disque sur l’expéditeur, CPU pour compression/chiffrement, mémoire et buffers, comportement de congestion TCP en fonction de la latence, overhead SSH et comportement d’écriture sur le récepteur. Si vous ne réglez qu’un composant, vous déplacez souvent le goulot d’étranglement ailleurs — et parfois vous le rendez plus difficile à voir.

La façon la plus simple de rester sain d’esprit est de traiter la réplication comme un service de production avec des SLO :

RPO : combien de données vous pouvez vous permettre de perdre (définit la fréquence des snapshots et la taille des envois).
RTO : à quelle vitesse vous pouvez restaurer (définit la rétention, les tests et si vous avez besoin que les propriétés reçues par zfs receive soient correctes).
Budget : bande passante, marge CPU et quelle complexité opérationnelle vous pouvez tolérer à 3 h du matin.

Puis définissez le pipeline dans votre tête :

Sélection des snapshots : qu’est-ce qui a changé depuis la dernière fois ?
Send : ZFS lit les blocs et émet un flux.
Transform : compression optionnelle, chiffrement optionnel (natif ZFS ou SSH).
Transport : TCP à travers un chemin à haute latence.
Receive : ZFS écrit les blocs, met à jour les métadonnées, commit les TXG.

Sur un LAN, le disque et le CPU dominent. Sur un WAN, la latence et la perte de paquets amplifient chaque petite inefficacité. Une liaison avec 100 ms de RTT n’est pas juste « un peu plus lente qu’en local » — elle change la façon dont TCP monte en charge, la vitesse à laquelle les buffers se vident et combien peut coûter une simple retransmission.

Première blague (obligatoire et méritée) : la réplication WAN, c’est comme déménager un appartement en scooter — techniquement possible, mais chaque sangle manquante devient un choix de vie.

2. Faits intéressants et contexte historique

Six à dix points concrets de contexte qui comptent en pratique :

zfs send/receive est plus ancien que beaucoup de produits « cloud-native » de sauvegarde. Le design original de ZFS dans OpenSolaris a fait de la réplication par snapshot une opération de première classe, pas un ajout.
Les envois incrémentaux se basent sur les blocs, pas sur les fichiers. C’est pourquoi ils peuvent être extrêmement efficaces — mais aussi pourquoi certaines charges (images VM avec churn) peuvent générer des deltas étonnamment grands.
Le débit TCP est borné par le bandwidth-delay product (BDP). Si vos buffers de socket sont plus petits que le BDP, vous laissez de la capacité inutilisée même lorsque tout le reste est parfait.
Les réglages par défaut de SSH sont conservateurs pour les sessions interactives. Ils ne sont pas faits pour des transferts massifs soutenus de plusieurs heures, surtout sur des latences élevées.
OpenZFS a ajouté le support des envois reprenables afin qu’une réplication interrompue puisse continuer sans recommencer depuis le début — l’une des meilleures améliorations pour la qualité de vie opérationnelle.
La compression est passée de mode plusieurs fois. Avec les CPU modernes, une compression légère (comme LZ4) est souvent suffisamment « gratuite » et peut faire la différence entre saturer un lien ou ramper.
Les décisions recordsize et volblocksize résonnent dans la réplication. Les gros blocs séquentiels répliquent efficacement ; les petits blocs aléatoires augmentent métadonnées et overhead — particulièrement visible sur WAN.
La réplication est sensible au comportement d’écriture du récepteur. Un pool récepteur avec un SLOG saturé, des attentes ashift incohérentes ou des charges sync lourdes peut brider tout le pipeline.

3. Base : ce que « lent » signifie vraiment

Avant d’optimiser ZFS, déterminez ce que votre lien peut réellement faire. On entend souvent « nous avons un circuit 1 Gbps » puis la réplication tourne à 30–80 Mbps et on blâme ZFS. La moitié du temps le circuit est réel ; le débit utilisable ne l’est pas — parce que QoS, overhead VPN, perte de paquets ou une mauvaise configuration du BDP grignotent votre performance.

Ce que vous devez savoir :

RTT : 20 ms, ce n’est pas la même planète que 120 ms.
Perte : 0,1% de perte peut écraser le débit TCP sur certains chemins.
MTU/MSS : la fragmentation et le blackholing sont des tueurs silencieux.
BDP : bande passante × RTT ; comparez-le aux tailles de buffer de socket.

Ce n’est qu’après avoir compris le réseau que vous interprétez les chiffres de réplication. Sinon vous optimisez un système de fichiers pour compenser un pare-feu qui considère les gros paquets comme une faute morale.

4. Le pipeline de réplication : où la vitesse meurt

4.1 Stratégie de snapshots : des deltas moins nombreux et plus intelligents

Sur les liens WAN, la réplication est un jeu de cohérence et de taille de delta. Beaucoup de petits snapshots réduisent la taille maximale du delta et le risque qu’un « envoi énorme » bouche la tuyauterie — mais trop de snapshots augmentent le churn métadonnées et la charge de gestion.

Opérationnellement, le schéma gagnant est :

Snapshots fréquents pour un RPO court (par ex. 5–15 minutes) sur les datasets critiques.
Snapshots moins fréquents pour les datasets volumineux / peu prioritaires.
Rétention qui conserve au moins une baseline connue bonne pour chaque cible de réplication.

4.2 Expéditeur : pattern de lecture, CPU et options de zfs send

zfs send peut être assez rapide pour saturer des NVMe localement et rester néanmoins mal adapté au WAN. Les grands leviers :

Envois incrémentaux : -i ou -I, plus une convention de nommage de snapshots sensée.
Envois raw : -w conserve les blocs chiffrés/compressés tels qu’ils sont stockés (lorsque le dataset est chiffré) et évite le retraitement ; souvent un gros gain CPU.
Gros blocs : la réplication profite de lectures séquentielles plus larges ; si votre charge est intrinsèquement aléatoire, le buffering compte davantage.
Inclure les propriétés : les choix -p ou -R affectent l’exactitude, pas seulement la vitesse — une erreur ici crée des réplications « rapides » qui ne restaurent pas correctement.

4.3 Transformation : choix de compression et chiffrement

Sur les liaisons lentes, la compression achète souvent plus qu’elle ne coûte — jusqu’à un certain point. La contrainte est la marge CPU aux deux bouts. LZ4 est le choix par défaut « probablement sûr » ; une compression lourde peut devenir un goulot CPU, et la double-compression peut gaspiller des cycles pour aucun gain.

Chiffrement : vous allez chiffrer sur le WAN. La seule question est où. Si vous utilisez déjà le chiffrement natif ZFS, zfs send -w (raw) vous évite de décrypter/re-chiffrer. Si vous comptez sur SSH pour le chiffrement, ajustez SSH pour les transferts en bloc et choisissez des ciphers rapides sur votre matériel.

4.4 Transport : latence, buffers et pourquoi votre débit plafonne

TCP a besoin de données en vol pour garder la tuyauterie pleine. Sur un lien 200 Mbps avec 100 ms de RTT, le BDP est d’environ 2,5 MB (200 megabits/sec ≈ 25 MB/sec ; × 0,1 s ≈ 2,5 MB). Si vos buffers de socket expéditeur/récepteur sont plus petits que cela, vous ne pouvez physiquement pas atteindre le débit maximum.

Ajoutez maintenant la perte. TCP interprète la perte comme de la congestion, réduit la fenêtre et remonte lentement. Sur de longs RTT, la remontée est lente. C’est pourquoi un lien qui « semble correct » pour du trafic web peut être misérable pour une réplication soutenue.

4.5 Récepteur : écritures, TXG et le mystère « mon receive est plus lent que le send »

La performance côté récepteur est souvent le goulot invisible. Coupables courants :

Contention du pool : d’autres workloads provoquant des écritures aléatoires et de la pression sync.
Comportement sync : datasets avec sync=always ou un dispositif SLOG stressé peuvent brider les commits.
Petit recordsize : le récepteur doit faire plus de travail métadonnées pour la même quantité de données utilisateur.
Attentes ashift mal alignées : ce n’est pas un réglage de réplication, mais un facteur de conception de pool qui affecte l’amplification d’écriture.

5. Tâches pratiques (commandes + interprétation)

Ce sont des tâches réelles que vous pouvez lancer sur des systèmes OpenZFS-on-Linux typiques. Adaptez les noms de dataset et d’interfaces. Chaque tâche inclut quoi observer, parce que « lancer la commande » n’est pas de l’exploitation.

Tâche 1 : Confirmer l’inventaire des datasets et snapshots

cr0x@sender:~$ zfs list -t filesystem,volume -o name,used,avail,refer,mountpoint
cr0x@sender:~$ zfs list -t snapshot -o name,creation,used -s creation | tail -n 20

Interprétation : Vous vérifiez ce que vous êtes sur le point de répliquer et si les snapshots existent dans une chaîne cohérente. Si des snapshots manquent ou sont irréguliers, les envois incrémentaux échoueront ou forceront des envois complets coûteux.

Tâche 2 : Estimer la taille du delta entre snapshots

cr0x@sender:~$ zfs list -t snapshot -o name,used,refer -s creation tank/app
cr0x@sender:~$ zfs send -nPv -i tank/app@snaphourly-001 tank/app@snaphourly-002
total estimated size is 38.2G
send from @snaphourly-001 to tank/app@snaphourly-002 estimated size is 38.2G

Interprétation : Si votre delta « horaire » est de 38 GB, vous n’avez pas un problème de réplication — vous avez un mismatch entre la charge ou la cadence des snapshots. Cette sortie est votre vérification de réalité pour le RPO.

Tâche 3 : Mesurer le débit brut du send localement (enlever le WAN)

cr0x@sender:~$ zfs send -Pv tank/app@snaphourly-002 | pv > /dev/null
  12.5GiB 0:00:18 [ 702MiB/s] [         <=>  ]

Interprétation : Si le send local est rapide, l’I/O expéditeur et zfs send lui-même ne sont pas votre goulot. Si c’est lent, corrigez le pool expéditeur, la pression ARC ou la structure des snapshots avant de blâmer le réseau.

Tâche 4 : Mesurer le débit brut du receive localement

cr0x@receiver:~$ zfs create -o mountpoint=none tank/replica-test
cr0x@sender:~$ zfs send -Pv tank/app@snaphourly-002 | ssh receiver 'pv | sudo zfs recv -u tank/replica-test/app'

Interprétation : Ceci teste bout à bout mais toujours pas votre WAN. Si le receive est lent ici, votre pool récepteur est le coupable (ou le CPU pour décompression/chiffrement).

Tâche 5 : Confirmer RTT TCP, signaux de perte et sanity du route

cr0x@sender:~$ ping -c 20 receiver
cr0x@sender:~$ ip route get receiver
cr0x@sender:~$ ss -ti dst receiver | head -n 40

Interprétation : Ping donne un RTT grossier. ss -ti montre l’état TCP incluant retransmits, congestion window et pacing. Si vous voyez des retransmits augmenter pendant la réplication, corrigez le chemin réseau ou le MTU avant d’ajuster ZFS.

Tâche 6 : Vérifier le MTU et détecter les douleurs PMTUD courantes

cr0x@sender:~$ ip link show dev eth0
cr0x@sender:~$ tracepath receiver | head -n 20

Interprétation : Si vous êtes sur un VPN, votre MTU effective est souvent plus petite que vous ne le pensez. tracepath indiquera des changements PMTU. Les bizarreries de Path MTU se manifestent souvent par des « stalls » aléatoires ou un débit incohérent.

Tâche 7 : Inspecter CPU expéditeur et récepteur pendant la réplication

cr0x@sender:~$ mpstat -P ALL 1 10
cr0x@sender:~$ pidstat -t 1 -p $(pgrep -n "zfs|ssh|mbuffer|pv" | tr '\n' ',')

Interprétation : Si un seul cœur est saturé (souvent SSH crypto ou compression), vous êtes CPU-bound. Le tuning WAN n’aidera pas si votre pipeline ne peut pas générer ou consommer les octets assez vite.

Tâche 8 : Utiliser mbuffer pour lisser le jitter WAN et garder la tuyauterie pleine

cr0x@sender:~$ zfs send -Pv -i tank/app@snapA tank/app@snapB | mbuffer -q -m 1G -s 128k | ssh receiver 'mbuffer -q -m 1G -s 128k | sudo zfs recv -u tank/replica/app'

Interprétation : mbuffer découple le pacing expéditeur/récepteur et absorbe le jitter. Si cela améliore matériellement le débit, votre goulot est probablement la variabilité du transport ou des stalls d’écriture sur le récepteur, pas zfs send lui-même.

Tâche 9 : Activer les envois reprenables et capturer le token de reprise

cr0x@sender:~$ zfs send -v -s -i tank/app@snapA tank/app@snapB | ssh receiver 'sudo zfs recv -s -u tank/replica/app'
cr0x@receiver:~$ zfs get -H -o value receive_resume_token tank/replica/app
1-ETcK...truncated...GQ

Interprétation : Si le lien tombe, vous pouvez reprendre au lieu de recommencer. C’est indispensable sur des WAN instables. Un token non vide signifie qu’un receive reprenable est en attente.

Tâche 10 : Reprendre une réplication interrompue

cr0x@receiver:~$ token=$(zfs get -H -o value receive_resume_token tank/replica/app)
cr0x@sender:~$ zfs send -v -t "$token" | ssh receiver 'sudo zfs recv -s -u tank/replica/app'

Interprétation : Si la reprise fonctionne et que le débit revient, vous avez prouvé que l’interruption était due au transport ou à un incident distant transitoire, pas à une corruption de chaîne de snapshots.

Tâche 11 : Vérifier l’intégrité de la réplication en comparant les snapshots

cr0x@receiver:~$ zfs list -t snapshot -o name,creation -s creation tank/replica/app | tail -n 5
cr0x@sender:~$ zfs list -t snapshot -o name,creation -s creation tank/app | tail -n 5

Interprétation : Les noms et l’ordre des snapshots doivent correspondre à l’ensemble de réplication prévu. S’ils ne correspondent pas, vous pourriez silencieusement ne pas répliquer ce que vous pensez.

Tâche 12 : Confirmer quelles propriétés sont reçues et si elles doivent être locales

cr0x@receiver:~$ zfs get -o name,property,value,source compression,encryption,keylocation,atime,recordsize tank/replica/app

Interprétation : Les propriétés peuvent impacter les performances et le comportement de restauration. Par exemple, forcer atime=on sur un replica utilisé pour des tests DR peut créer du bruit d’écriture en arrière-plan au pire moment.

Tâche 13 : Déterminer si le récepteur est bloqué sur sync ou pression TXG

cr0x@receiver:~$ zpool iostat -v 1 10
cr0x@receiver:~$ cat /proc/spl/kstat/zfs/arcstats | head -n 5
cr0x@receiver:~$ cat /proc/spl/kstat/zfs/txgs | head -n 50

Interprétation : zpool iostat montre si le pool est saturé et si un vdev particulier prend du retard. Les stats TXG peuvent indiquer des délais de commit. Si le pool est le goulot, vous pouvez optimiser le réseau indéfiniment et rester lent.

Tâche 14 : Tuner SSH pour les transferts massifs (prudemment) et observer l’impact CPU

cr0x@sender:~$ zfs send -Pv -i tank/app@snapA tank/app@snapB | \
ssh -T -o Compression=no -o IPQoS=throughput receiver 'pv | sudo zfs recv -u tank/replica/app'

Interprétation : Désactiver la compression SSH évite la double-compression de données déjà compressées. IPQoS=throughput peut empêcher certains réseaux de traiter le flux comme du trafic interactif. Mesurez toujours CPU et débit avant/après ; « tuner » peut être une façon coûteuse de se sentir productif.

Tâche 15 : Valider que le côté receive n’est pas monté et indexé par erreur

cr0x@receiver:~$ zfs get -o name,property,value mounted,mountpoint canmount tank/replica/app
cr0x@receiver:~$ zfs recv -u tank/replica/app < /dev/null

Interprétation : Pour les replicas DR, vous voulez souvent canmount=off ou mountpoint=none et zfs recv -u pour éviter le montage automatique qui déclenche scanners, indexeurs ou agents de monitoring « utiles » qui créent des écritures pendant la réplication.

6. Playbook de diagnostic rapide

Quand la réplication est lente, ne commencez pas par changer des flags au hasard. Utilisez un court playbook qui isole le goulot en quelques minutes.

Étape 1 : Est-ce limité par le réseau ou par les hôtes ?

Vérifiez RTT et retransmits pendant qu’une réplication tourne.
Vérifiez la saturation CPU expéditeur et récepteur.
Vérifiez zpool iostat du récepteur pour une utilisation soutenue et latence.

cr0x@sender:~$ ss -ti dst receiver | sed -n '1,25p'
cr0x@sender:~$ mpstat -P ALL 1 5
cr0x@receiver:~$ zpool iostat -v 1 5

Décision : Si retransmits et effondrement de cwnd apparaissent, traitez-le d’abord comme un problème réseau. Si le CPU est saturé, traitez-le comme un problème CPU/crypto/compression. Si le pool récepteur est à 90–100% avec de longs temps d’attente, traitez-le comme un problème de stockage.

Étape 2 : La taille du send est-elle inattendue ?

cr0x@sender:~$ zfs send -nPv -i tank/app@last tank/app@now

Décision : Si la taille du delta est plus grande que prévu, corrigez la cadence des snapshots, le churn de la charge ou votre choix de snapshot de base incrémental (-i vs -I). Le tuning WAN ne réduira pas le delta.

Étape 3 : Le buffering stabilise-t-il le débit ?

cr0x@sender:~$ zfs send -Pv -i tank/app@last tank/app@now | mbuffer -m 1G -s 128k | \
ssh receiver 'mbuffer -m 1G -s 128k | sudo zfs recv -u tank/replica/app'

Décision : Si le débit devient plus régulier et plus élevé, vous observiez des stalls de pipeline (commits récepteur, jitter réseau ou pacing SSH). Gardez mbuffer puis investiguez le comportement d’écriture du récepteur.

Étape 4 : Pouvez-vous reprendre de façon fiable ?

cr0x@receiver:~$ zfs get -H -o value receive_resume_token tank/replica/app

Décision : Si vous ne pouvez pas reprendre sur des liens instables, vous êtes à un incident transitoire d’un reenvoi complet et d’un week-end désagréable. Corrigez la résumabilité avant de chasser des gains marginaux de vitesse.

7. Trois mini-histoires du monde d’entreprise

Histoire 1 : L’incident causé par une mauvaise hypothèse

La configuration paraissait raisonnable sur un tableau blanc : répliquer les datasets de production vers un site DR chaque nuit sur un circuit privé. L’équipe a supposé que « circuit privé » impliquait « débit stable » et que « chaque nuit » impliquait « suffisant ». Personne n’a écrit un RPO ; c’était un ressenti.

Puis un lancement produit est arrivé. La charge est passée d’écritures de base de données régulières à beaucoup de blobs orientés objet et churn d’images VM. Les deltas incrémentaux ont grandi silencieusement, parce que ZFS a fait exactement ce qu’on lui avait demandé : capturer les changements, puis les expédier plus tard. Le job de réplication a commencé à durer plus longtemps, débordant vers le matin. Les gens l’ont remarqué mais ont haussé les épaules — après tout, c’était « en train de s’exécuter ».

Pendant une maintenance non liée, le site primaire a eu une panne nécessitant la promotion du DR. Le dataset DR était beaucoup plus en retard que prévu. Ils avaient répliqué « chaque nuit », mais l’envoi nocturne n’était pas fini. Leur RPO n’était pas 24 heures ; c’était « quand l’envoi a fini », ce qui n’est pas un chiffre qu’on peut mettre dans un registre de risques sérieusement.

La solution n’était pas un tuning ingénieux. Ce fut de l’ingénierie ennuyeuse : augmenter la fréquence des snapshots pour réduire les deltas, ajouter du monitoring pour « retard de réplication en snapshots/temps », et établir une politique que la réplication doit se terminer dans une fenêtre définie — ou déclencher une alerte. Ils ont aussi commencé à exécuter zfs send -nPv comme estimation lors des revues de changements pour les grosses variations de charge.

Histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre entreprise avait un lien transcontinental lent et un mandat : « rendre la réplication plus rapide ». Quelqu’un a décidé d’augmenter la compression partout — sur les datasets, dans le pipeline d’envoi et dans SSH. Ça avait l’air bien dans un test rapide : les premières minutes montraient un meilleur débit et moins d’octets sur le lien.

Puis la réalité est revenue. Le CPU sur l’expéditeur a monté, mais pire, le CPU sur le récepteur est devenu en rafales. Le débit de réplication oscillait : des pics de progression suivis de longs plateaux. L’équipe a interprété les plateaux comme des « problèmes réseau » et a demandé un circuit plus large. L’équipe réseau, prévisible, a demandé des preuves.

La preuve est apparue dans mpstat et pidstat : quelques cœurs étaient occupés par la compression et la crypto, et la pipeline d’écriture du récepteur ne suivait pas. La double-compression gaspillait des cycles car une grande partie des données (blobs applicatifs compressés) ne compressait pas plus. La compression SSH, en particulier, ajoutait latence et coût CPU pour aucun gain.

La correction fut contre-intuitive : désactiver la compression SSH, garder la compression dataset légère (LZ4) et utiliser du buffering pour lisser les stalls du récepteur. Le débit s’est amélioré, le CPU a refroidi et — meilleur de tout — le système est redevenu prévisible. La leçon : si vous ne pouvez pas expliquer où vont les cycles CPU, vous n’optimisez pas ; vous jouez.

Histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

La troisième organisation avait une habitude douloureusement conservatrice : toutes les tâches de réplication WAN devaient être reprenables, journalisées et testées mensuellement avec une interruption de lien simulée. Ils gardaient aussi un petit runbook dans leur canal incident : « token de reprise d’abord, panique ensuite ». Ce n’était pas glamour et personne n’en a tiré d’avancement.

Un trimestre, un fournisseur a eu une perte de paquets intermittente pendant des jours. Pas une panne totale — juste assez pour déstabiliser les flux TCP longue durée et réinitialiser parfois les sessions. Les jobs de réplication ont commencé à échouer en cours de route. Mais comme les jobs utilisaient des envois reprenables, ils ont repris automatiquement ou avec une seule commande opérateur. Personne n’a été forcé de « recommencer depuis le début » des transferts qui auraient saturé le lien pendant des semaines.

Pendant la même période, l’équipe sécurité a resserré des timeouts de firewall qui tuaient les sessions SSH « inactives ». Le pipeline de réplication pausait pendant la pression TXG du récepteur, semblait inactif pour le firewall et se faisait couper. Là encore : la réplication reprenable a transformé une crise en une nuisance.

Quand la direction a demandé pourquoi le DR est resté sain pendant « l’instabilité réseau », la réponse honnête n’était pas « nous avons parfaitement tuni TCP ». C’était « nous avons supposé que le WAN est peu fiable et avons conçu pour ça ». En exploitation entreprise, c’est cela la compétence : c’est discret.

8. Erreurs courantes (symptômes + corrections)

Erreur 1 : Ne considérer que le débit

Symptôme : Vous célébrez une réplication rapide, puis découvrez des snapshots manquants, des propriétés non répliquées ou des restaurations qui échouent.

Correction : Définissez la correction : quels datasets, quels snapshots, récursif ou non, propriétés incluses et si c’est du raw encrypted. Utilisez zfs list -t snapshot pour comparer et faites des tests de restauration périodiques.

Erreur 2 : Faire des envois complets sur le WAN parce que « les incrémentaux sont durs »

Symptôme : La réplication ne finit jamais après la première seed ; le lien est saturé pendant des jours ; le RPO dérive sans fin.

Correction : Utilisez des conventions de nommage de snapshots et des envois incrémentaux. Si vous devez initialiser la seed, faites-le une fois (idéalement en expédiant des disques ou via un chemin temporaire à haute bande passante), puis exécutez des incrémentaux.

Erreur 3 : Double-compression (dataset + pipeline + SSH)

Symptôme : Pics CPU, débit en oscillation et des réglages « plus rapides » ralentissent en réalité.

Correction : Choisissez un seul endroit pour compresser. Souvent : LZ4 sur les datasets, compression SSH désactivée. Mesurez avec des outils CPU.

Erreur 4 : Pas de buffering face à un WAN jittery

Symptôme : Le débit ressemble à une dent de scie : rafales puis stalls ; les sessions SSH tombent parfois pendant les phases « calmes ».

Correction : Ajoutez du buffering (mbuffer) aux deux extrémités avec une mémoire sensée. Cela lisse les courts stalls récepteur et le jitter réseau.

Erreur 5 : Ignorer la santé du pool récepteur

Symptôme : L’expéditeur semble rapide localement, mais le bout à bout WAN est lent même quand le lien n’est pas saturé.

Correction : Vérifiez zpool iostat -v, latence et contention. La réplication est une charge d’écriture lourde sur le récepteur ; traitez-la comme telle.

Erreur 6 : Ne pas utiliser d’envoi reprenable sur des liens peu fiables

Symptôme : Un transfert de 6 heures meurt à 5:45 et redémarre depuis le début. Le moral chute plus vite que le débit.

Correction : Utilisez zfs send -s et zfs recv -s. Capturez et surveillez les tokens de reprise.

Erreur 7 : Jobs de réplication qui se chevauchent et se combattent

Symptôme : Plusieurs datasets répliquent « en parallèle », mais le débit total est pire et les apps sensibles à la latence se plaignent.

Correction : Sérialisez les gros flux ou contrôlez la concurrence. Votre lien WAN et le pool récepteur ne deviennent pas plus rapides parce que vous avez ajouté des tuyaux ; vous avez juste ajouté de la contention.

Erreur 8 : Supposer « le WAN va bien » parce que les speedtests vont bien

Symptôme : Les tests de vitesse dans un navigateur passent, mais les flux longue durée de réplication rament.

Correction : Observez le comportement TCP (ss -ti), les retransmits et MTU/PMTUD. Les flux longs révèlent des problèmes de chemin que les tests courts cachent.

Deuxième blague (obligatoire) : si vous pensez que la perte de paquets WAN est « pratiquement nulle », j’ai un pont à vous vendre — via VPN, avec un MTU de 9000.

9. Checklists / plan étape par étape

9.1 Plan étape par étape pour une nouvelle réplication WAN

Définir l’intention : objectifs RPO/RTO par classe de dataset (critique, important, best-effort).
Normaliser le nommage des snapshots : noms prévisibles, cadence cohérente et politique de rétention.
Initialiser la baseline : faire un envoi complet une fois pendant une fenêtre de maintenance ou via un chemin alternatif ; confirmer la disposition côté receive.
Rendre reprenable par défaut : zfs send -s et zfs recv -s.
Ajouter du buffering : déployer mbuffer avec une mémoire conservatrice (ex. 512MB–2GB) selon la RAM hôte.
Choisir la stratégie de compression : généralement LZ4 sur les datasets, pas de compression SSH. Si vous utilisez le chiffrement natif, préférez les envois raw quand approprié.
Throttler si nécessaire : éviter d’écraser le trafic business ; la limitation de débit est parfois une fonctionnalité, pas une concession.
Vérifier l’exactitude : assurer que les chaînes de snapshots, les propriétés et les datasets attendus arrivent. Garder les receives démontés sauf si besoin.
Instrumenter le retard de réplication : mesurer « âge du dernier snapshot répliqué » et alerter quand il dépasse les seuils.
Tester les restaurations : monter un clone répliqué ou promouvoir un environnement de test selon un calendrier. Une réplication dont vous n’avez jamais restauré est une théorie.

9.2 Checklist opérationnelle « la réplication est lente aujourd’hui »

Vérifier la contention du pool récepteur : zpool iostat -v 1 5.
Vérifier les retransmits/cwnd TCP : ss -ti dst receiver.
Vérifier le pinning CPU : mpstat et pidstat.
Estimer la taille du delta : zfs send -nPv -i.
Essayer le buffering si non utilisé : ajouter mbuffer.
Vérifier le token reprenable ; reprendre au lieu de redémarrer.

10. FAQ

Q1 : Dois‑je utiliser l’envoi raw (`zfs send -w`) sur le WAN ?

Si vous utilisez le chiffrement natif ZFS et souhaitez répliquer des datasets chiffrés sans les décrypter, l’envoi raw est généralement la bonne option. Il peut aussi réduire l’overhead CPU car ZFS peut transmettre les blocs stockés chiffrés/compressés. Opérationnellement, il préserve les frontières de chiffrement, ce que vous voulez pour des copies hors site.

Q2 : `mbuffer` est‑il obligatoire ?

Pas obligatoire, mais c’est un des outils avec le meilleur ROI pour la réplication WAN car il lisse les rafales et les stalls. Si votre débit est en dents de scie ou si vos sessions SSH meurent pendant des phases « calmes », le buffering est une solution pratique.

Q3 : Pourquoi la réplication bloque au même endroit à chaque fois ?

Souvent c’est la pression du pool côté récepteur ou un timeout agressif d’un middlebox réseau. Vérifiez zpool iostat du récepteur pour un vdev qui atteint 100% d’utilisation ou de longs temps d’attente, et vérifiez si votre firewall/NAT a des timeouts d’inactivité qui tuent les sessions longues.

Q4 : Dois‑je lancer plusieurs sends en parallèle pour mieux utiliser le lien ?

Parfois, mais prudence. Les flux parallèles aident si un flux unique ne peut pas remplir le tuyau à cause de limites par‑flux, mais ils augmentent aussi la contention disque et CPU et peuvent empirer la latence de queue pour les applications. Essayez d’abord un flux bien réglé ; s’il ne peut pas saturer et que les hôtes sont inactifs, testez un parallélisme contrôlé.

Q5 : Quelle fréquence de snapshot est la meilleure pour la réplication WAN ?

Celle qui garde vos deltas incrémentaux confortablement dans votre fenêtre de réplication avec marge pour les reprises. Si votre lien peut déplacer X GB/heure de façon fiable et votre workload change Y GB/heure, votre cadence de snapshots doit maintenir chaque delta en dessous de ce que vous pouvez expédier plus les overheads.

Q6 : Dois‑je répliquer récursivement avec `-R` ?

-R est correct quand vous avez besoin d’une hiérarchie complète (enfants, snapshots, propriétés) répliquée de manière cohérente. C’est aussi la façon dont on réplique accidentellement plus que prévu. Utilisez‑le quand vous le voulez réellement et vérifiez l’arbre de datasets sur le récepteur.

Q7 : Comment savoir si je suis limité CPU par le chiffrement SSH ?

Lancez une réplication et surveillez mpstat/pidstat. Si un ou plusieurs cœurs sont saturés par le processus ssh et que votre lien est sous‑utilisé, la crypto SSH est un suspect prioritaire. Envisagez les envois raw avec chiffrement natif (si applicable) ou ajustez les options SSH et la capacité CPU de la machine.

Q8 : Est‑il sûr de mettre `sync=disabled` sur le récepteur pour accélérer `zfs recv` ?

C’est rapide, et c’est risqué. Pour un replica DR où vous pouvez tolérer de perdre quelques secondes de données reçues en cas de crash, les équipes le choisissent parfois en connaissance de cause. Mais ne le faites pas à la légère : vous changez la sémantique de durabilité côté récepteur. Si vous le faites, documentez‑le, délimitez le périmètre et testez le comportement en cas de panne.

Q9 : Pourquoi l’estimation de `zfs send -nPv` ne correspond‑elle pas à ce que j’envoie réellement ?

C’est une estimation et elle peut varier selon le partage de blocs, les métadonnées et les caractéristiques du flux. Elle reste utile pour détecter les tendances et se demander « ce delta est‑il fou ? », pas pour une comptabilité facturable.

Q10 : Quelle est la meilleure façon d’éviter les reenvois catastrophiques ?

Réplication reprenable plus surveillance des tokens de reprise et du lag. Les liens WAN vont tomber ; votre plan doit supposer cela et conserver les progrès.

Conclusion

La réplication ZFS rapide sur un WAN lent n’est pas une question d’un flag magique. Il s’agit de rendre le pipeline ennuyeux : cadence de snapshots prévisible, flux incrémentaux, buffering pour le jitter, choix corrects de chiffrement/compression et un récepteur capable d’écrire ce que vous envoyez. Les meilleures configurations ne vont pas seulement vite les bons jours — elles continuent d’avancer les mauvais jours, reprennent après les interruptions et vous préviennent tôt quand la réalité s’écarte de votre RPO.

Si vous ne retenez qu’une leçon opérationnelle : mesurez chaque étape, isolez rapidement le goulot et optimisez la contrainte que vous avez réellement — pas celle qui vous semble familière.