Réseau Windows : SMB lent — la fonctionnalité que vous avez oubliée d’activer

février 17, 2026 • février 17, 2026 • Lecture : 25 min • Views: 0

Cet article vous a aidé ?

Vos utilisateurs disent « le serveur de fichiers est lent ». Vous vous connectez en RDP, lancez une copie et la regardez traîner à 80–120 MB/s sur un réseau 10GbE qui devrait atteindre 900+ MB/s sans sourciller. Quelqu’un suggère « peut-être c’est le DNS ». Un autre propose « redémarrez le switch ». Vous envisagez une reconversion en poterie.

La plupart du temps, SMB est lent pour une raison peu glamour : vous utilisez un réseau moderne avec un goulot d’étranglement en forme d’héritage. La fonctionnalité que les gens oublient d’activer — ou d’authentifier — est SMB Multichannel. C’est la différence entre un flux TCP unique et plusieurs, entre un cœur CPU saturé et une machine qui exploite réellement le matériel pour lequel vous avez payé.

La fonctionnalité oubliée : SMB Multichannel (et pourquoi c’est important)

SMB (Server Message Block) est le protocole derrière le partage de fichiers Windows. Sur les versions modernes de Windows, « SMB » signifie essentiellement SMB 3.x, qui apporte de véritables fonctionnalités d’entreprise : chiffrement, signature, basculement transparent et (crucial ici) Multichannel.

SMB Multichannel permet à une seule session SMB d’utiliser plusieurs connexions réseau en parallèle. Cela peut signifier plusieurs cartes réseau, plusieurs adresses IP sur une même carte, ou plusieurs files/chemins sur une seule carte rapide lorsque les bonnes fonctionnalités matérielles (RSS) sont présentes. Il améliore le débit, la résilience et souvent la latence sous charge parce que vous ne forcez pas tout à passer par un seul et unique flux.

Sans Multichannel, de nombreux transferts se comportent comme un flux TCP unique. Et un flux TCP unique a des limites prévisibles :

Une seule fenêtre de congestion à faire grandir et réduire.
Un seul traitement des paquets qui peut peser lourdement sur un seul cœur CPU.
Un seul chemin qui peut être interrompu par un seul incident.

Lorsque vous activez Multichannel et qu’il s’active effectivement, vous observez généralement :

Un débit supérieur sur 10/25/40/100GbE
Une meilleure utilisation du CPU sur plusieurs cœurs
De meilleures performances pour plusieurs clients simultanés
Une certaine tolérance aux pannes lorsqu’un lien échoue (selon la configuration)

La vérité inconfortable : Multichannel peut être « activé » et ne rien faire. C’est une fonctionnalité avec des prérequis. Si RSS est désactivé, si la carte est mal configurée, si vous forcez accidentellement SMB sur une interface, si vos règles de pare-feu sont « créatives », Multichannel restera poli et inactif.

Que faire : Traitez Multichannel comme une dépendance de production : vérifiez qu’il est activé, qu’il est négocié et que plusieurs connexions sont réellement utilisées sous charge.

Plan de diagnostic rapide (premier/deuxième/troisième)

Ceci est la voie rapide : vous avez un ticket, une plainte, une copie qui rampe. Vous voulez trouver le goulot sans passer l’après-midi à vous disputer avec un switch.

Premier : prouver si SMB Multichannel est actif

Vérifiez si la fonctionnalité est activée sur le client et le serveur.
Vérifiez si la session SMB a plusieurs connexions.
Si c’est une seule connexion, supposez que vous êtes en mode flux unique jusqu’à preuve du contraire.

Deuxième : vérifier RSS / distribution CPU et réalité du lien NIC

Vérifiez la vitesse du lien et le duplex (oui, ça arrive encore).
Vérifiez que RSS est activé et dispose de plusieurs files.
Surveillez le CPU : si un cœur est saturé pendant le transfert, vous ne parallélisez probablement pas le traitement des paquets.

Troisième : isoler réseau vs stockage vs surcharge des fonctionnalités SMB

Lancez un test de débit réseau brut pour enlever le stockage de l’équation.
Vérifiez l’état du chiffrement/signature SMB ; le chiffrement peut être nécessaire, mais il n’est pas gratuit.
Examinez la latence disque et la profondeur de file sur le serveur pendant la copie.

Une citation qui devrait trôner sur tous les murs des équipes ops, parce que c’est un sauveur de carrière :

« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

Faits intéressants et brève histoire (pour comprendre le comportement étrange)

Les problèmes de performance SMB semblent aléatoires jusqu’à ce que vous vous rappeliez ce que SMB a traversé : des décennies de compatibilité, des chocs de sécurité et des changements matériels. Quelques faits concrets aident à ancrer le dépannage.

SMB est né dans les années 1980 et a accumulé des fonctionnalités au fil du temps, d’où des comportements très différents entre SMB1, SMB2 et SMB3.
SMB2 (époque Vista/Server 2008) était une refonte majeure : moins d’allers-retours, lectures/écritures plus grandes, meilleur pipelining. Si vous avez déjà comparé SMB1 et SMB2, vous avez vu le saut.
SMB3 (Windows 8/Server 2012) a introduit Multichannel et SMB Direct (RDMA), déplaçant SMB du « partage de fichiers de bureau » vers le « transport de stockage en datacenter ».
Après WannaCry, SMB1 a été largement désactivé dans les entreprises. Bonne décision de sécurité ; aussi un moteur pour adopter les fonctionnalités SMB modernes.
Le scaling de la fenêtre TCP et les algorithmes modernes de congestion importent davantage sur les liaisons haute latence. Un flux unique sur un réseau « long et large » peut sous-utiliser la bande passante si le tuning et le RTT sont défavorables.
La signature SMB et le chiffrement ne sont pas la même chose : la signature valide l’intégrité ; le chiffrement assure la confidentialité. Les deux ajoutent une charge CPU ; le chiffrement en particulier peut devenir lié au CPU sur des processeurs plus anciens ou sous forte charge.
Multichannel n’est pas du « teaming ». Le teaming NIC est une agrégation/failover au niveau NIC/driver ; SMB Multichannel se situe au niveau protocole/session et peut fonctionner sans teaming.
Receive Side Scaling (RSS) est le héros discret sur des serveurs de fichiers chargés : il permet de répartir le traitement des paquets sur plusieurs cœurs CPU. Sans lui, un seul cœur peut brider un lien 25GbE comme si c’était 2009.
Les jumbo frames ne sont pas une baguette magique. Elles peuvent réduire la charge CPU, mais des incohérences créent des pertes et des retransmissions mystérieuses qui rendent SMB « lent et instable ».

Blague #1 : SMB, c’est comme une réunion d’entreprise — une personne parle à la fois, c’est poli, mais ce n’est pas comme ça qu’on finit quoi que ce soit avant vendredi.

Comment SMB devient lent en production

« SMB est lent » n’est pas un problème unique. C’est un symptôme. Les principales causes observées en production tombent dans quelques catégories.

1) Sessions SMB à connexion unique sur des liens rapides

Un lien 10GbE peut transporter ~1.1 GB/s de charge utile dans des conditions idéales. Mais un flux TCP unique peut être limité par :

le traitement des paquets sur un seul cœur (surtout si RSS est désactivé ou mal configuré)
les pertes/retransmissions (optiques défectueuses, pression de buffer, mismatch duplex, mismatch MTU)
la latence (un RTT élevé ralentit la croissance de la fenêtre)
le comportement de crédit SMB sous certaines charges

Multichannel aide parce qu’il répartit le travail sur plusieurs connexions et peut utiliser plusieurs chemins/files NIC.

2) Chiffrement/signature CPU-bound

Les fonctionnalités de sécurité valent le coût. Mais si vous activez le chiffrement SMB partout sans vérifier la marge CPU, vous pouvez vous « améliorer » vers un plafond de débit. Sur des CPU modernes avec AES-NI, c’est souvent acceptable. Sur des machines plus anciennes, ou sur des liens très rapides, ce ne l’est pas.

3) Le stockage est le goulot, pas le câble

SMB est un transport. Si le stockage du serveur de fichiers ne peut pas fournir les IOPS ou le débit, la vitesse de copie correspondra aux disques, pas à la NIC. Cela devient compliqué quand le stockage est « rapide parfois » (hits de cache) et « lent parfois » (miss de cache, écritures RAID en miroir, snapshots, antivirus).

4) Antivirus, filtrage de fichiers et drivers filtres

La protection en temps réel sur les serveurs de fichiers peut transformer des écritures séquentielles en une parade stop-and-go. Si vos copies ont des pauses périodiques, et que les pics de latence disque coïncident, examinez l’analyse en temps réel et les drivers filtres.

5) « Optimisations » réseau qui ne le sont pas

Désactiver les offloads parce que « quelqu’un a lu un article », activer les jumbo frames sur la moitié du chemin, activer LACP alors que vous aviez besoin de SMB Multichannel, ou forcer une interface SMB unique pour le « contrôle » — voici comment les bonnes intentions deviennent des pannes.

Tâches pratiques : 12+ commandes, sorties et décisions

Ci‑dessous se trouvent des tâches réelles que j’exécute quand SMB est lent. Chacune inclut une commande, un exemple de sortie réaliste, ce que cela signifie et la décision à prendre.

Remarque : Ces commandes s’exécutent sur Windows (PowerShell / CMD). Le format des blocs de code ci‑dessous reste inchangé ; traitez le prompt comme une étiquette.

Task 1: Confirm SMB Multichannel is enabled on the client

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientConfiguration | Select EnableMultichannel,EnableSecuritySignature,RequireSecuritySignature"
EnableMultichannel EnableSecuritySignature RequireSecuritySignature
----------------- ----------------------- ------------------------
True              False                   False

Ce que cela signifie : Le client tentera Multichannel. La signature n’est pas requise ici.

Décision : Si EnableMultichannel est False, activez‑le (Task 3). Si c’est True, ne célébrez pas encore — vérifiez la négociation (Task 5).

Task 2: Confirm SMB Multichannel is enabled on the server

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select EnableMultichannel,EncryptData,RejectUnencryptedAccess"
EnableMultichannel EncryptData RejectUnencryptedAccess
----------------- ----------- ------------------------
True              False       False

Ce que cela signifie : Le serveur autorise Multichannel et n’impose pas le chiffrement.

Décision : Si le Multichannel du serveur est désactivé, activez‑le (Task 4). Si le chiffrement est forcé, planifiez de vérifier l’impact CPU et débit (Task 10).

Task 3: Enable SMB Multichannel on the client (if disabled)

cr0x@server:~$ powershell -NoProfile -Command "Set-SmbClientConfiguration -EnableMultichannel $true -Force; Get-SmbClientConfiguration | Select EnableMultichannel"
EnableMultichannel
-----------------
True

Ce que cela signifie : Le côté client est configuré.

Décision : Répétez sur les serveurs/images VDI via GPO/state desired. Puis vérifiez les connexions actives (Task 5).

Task 4: Enable SMB Multichannel on the server (if disabled)

cr0x@server:~$ powershell -NoProfile -Command "Set-SmbServerConfiguration -EnableMultichannel $true -Force; Get-SmbServerConfiguration | Select EnableMultichannel"
EnableMultichannel
-----------------
True

Ce que cela signifie : Le serveur de fichiers négociera Multichannel quand les clients le supporteront.

Décision : Si les performances étaient mauvaises, retestez les transferts et vérifiez les connexions SMB actives (Task 5/6).

Task 5: Verify the SMB session is actually using multiple connections

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbMultichannelConnection | Select ServerName,ClientInterfaceIndex,ServerInterfaceIndex,ClientIPAddress,ServerIPAddress,RSSCapable | Format-Table -AutoSize"
ServerName ClientInterfaceIndex ServerInterfaceIndex ClientIPAddress ServerIPAddress RSSCapable
---------- -------------------- -------------------- ------------- ------------- ----------
FS01       12                   9                    10.10.20.51   10.10.20.10   True
FS01       13                   10                   10.10.21.51   10.10.21.10   True

Ce que cela signifie : Deux connexions sont actives et compatibles RSS. C’est la configuration souhaitée.

Décision : Si vous ne voyez qu’une seule ligne, vous êtes en pratique en canal unique. Passez aux vérifications RSS/NIC (Task 7–9).

Task 6: Check SMB connections and dialect (are we on SMB3?)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select ServerName,ShareName,Dialect,NumOpens,Encrypted | Format-Table -AutoSize"
ServerName ShareName Dialect NumOpens Encrypted
---------- --------- ------- -------- ---------
FS01       data      3.1.1   42       False

Ce que cela signifie : Le client utilise SMB 3.1.1 (bien). Le chiffrement est désactivé pour ce partage/session.

Décision : Si le dialecte est plus bas que prévu, vous pourriez être soumis à des contraintes de politique/compatibilité. Si Encrypted=True et que les performances sont mauvaises, validez la marge CPU (Task 10).

Task 7: Verify NIC link speed and status on client/server

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select Name,Status,LinkSpeed | Format-Table -AutoSize"
Name           Status LinkSpeed
----           ------ ---------
Ethernet0      Up     10 Gbps
Ethernet1      Up     10 Gbps

Ce que cela signifie : Les liens sont actifs à la vitesse attendue.

Décision : Si vous voyez 1 Gbps sur un lien censé être 10GbE, arrêtez. Corrigez le câblage/optique/config du port du switch avant d’accuser SMB.

Task 8: Check RSS is enabled and has queues (client and server)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterRss | Select Name,Enabled,NumberOfReceiveQueues,MaxNumberOfReceiveQueues | Format-Table -AutoSize"
Name      Enabled NumberOfReceiveQueues MaxNumberOfReceiveQueues
----      ------- --------------------- ------------------------
Ethernet0 True    8                     16
Ethernet1 True    8                     16

Ce que cela signifie : RSS est activé avec plusieurs files. C’est fondamental pour un haut débit SMB sur une seule NIC rapide et utile pour Multichannel.

Décision : Si RSS est désactivé ou si les files = 1, activez RSS (Task 9). Retestez ensuite et surveillez la distribution CPU.

Task 9: Enable RSS (carefully) on an adapter

cr0x@server:~$ powershell -NoProfile -Command "Enable-NetAdapterRss -Name Ethernet0; Get-NetAdapterRss -Name Ethernet0 | Select Name,Enabled,NumberOfReceiveQueues"
Name      Enabled NumberOfReceiveQueues
----      ------- ---------------------
Ethernet0 True    8

Ce que cela signifie : RSS est désormais activé sur cette NIC.

Décision : Si l’activation de RSS provoque une instabilité (rare, spécifique au driver), mettez à jour les drivers/firmware NIC. Ne « réglez » pas le problème en désactivant RSS définitivement à moins d’aimer les escalades à 2 h du matin.

Task 10: Check if SMB encryption is required and estimate CPU risk

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare | Select Name,EncryptData | Format-Table -AutoSize"
Name    EncryptData
----    -----------
data    False
secure  True

Ce que cela signifie : Seul le partage secure impose le chiffrement.

Décision : Si « tout est lent » et que le chiffrement est activé partout, mesurez le CPU pendant les copies. Si le CPU est le plafond, envisagez du chiffrement sélectif (selon classification), une mise à niveau CPU ou des NIC avec offload—ne désactivez pas le chiffrement simplement parce que c’est commode.

Task 11: Watch CPU hotspots during a copy (server-side)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(*)\% Processor Time' -SampleInterval 1 -MaxSamples 5 | Select -ExpandProperty CounterSamples | Sort CookedValue -Descending | Select -First 5 Path,CookedValue"
Path                                              CookedValue
----                                              -----------
\\FS01\processor(3)\% processor time               96.8125
\\FS01\processor(7)\% processor time               22.125
\\FS01\processor(5)\% processor time               18.4375
\\FS01\processor(_total)\% processor time          31.020
\\FS01\processor(1)\% processor time               14.625

Ce que cela signifie : Un cœur est saturé tandis que le CPU total ne l’est pas. C’est le territoire classique du « file unique / flux unique / mauvaise distribution ».

Décision : Revérifiez RSS, les files et les connexions Multichannel. Si le chiffrement est activé, vous pourriez atteindre une surcharge crypto mono‑threadée dans des parties de la pile selon la charge et le système.

Task 12: Check SMB client network interface selection and capabilities

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientNetworkInterface | Select InterfaceIndex,IPAddress,RSSCapable,LinkSpeed | Format-Table -AutoSize"
InterfaceIndex IPAddress     RSSCapable LinkSpeed
-------------- ---------     ---------- ---------
12             10.10.20.51   True       10 Gbps
13             10.10.21.51   True       10 Gbps

Ce que cela signifie : Le client voit deux interfaces compatibles SMB, toutes deux compatibles RSS et rapides.

Décision : Si les interfaces attendues n’apparaissent pas ici, SMB ne pourra pas les utiliser pour Multichannel. Corrigez le routage, le binding NIC ou les règles de pare‑feu pour rendre les interfaces éligibles.

Task 13: Measure raw network throughput (remove disks from the story)

cr0x@server:~$ iperf3 -c fs01 -P 4 -t 10
Connecting to host fs01, port 5201
[  5] local 10.10.20.51 port 53122 connected to 10.10.20.10 port 5201
[  7] local 10.10.20.51 port 53124 connected to 10.10.20.10 port 5201
[  9] local 10.10.20.51 port 53126 connected to 10.10.20.10 port 5201
[ 11] local 10.10.20.51 port 53128 connected to 10.10.20.10 port 5201
[SUM]   0.00-10.00  sec  10.6 GBytes  9.10 Gbits/sec  0             sender
[SUM]   0.00-10.00  sec  10.6 GBytes  9.09 Gbits/sec                receiver

Ce que cela signifie : Le réseau peut atteindre ~9.1 Gbps. Le câble n’est pas votre problème aujourd’hui.

Décision : Si iperf est aussi lent, corrigez le chemin réseau/MTU/pertes. Si iperf est rapide mais SMB lent, concentrez‑vous sur les réglages SMB, le CPU, le chiffrement et le stockage.

Task 14: Check retransmits and errors (quick sniff without Wireshark)

cr0x@server:~$ powershell -NoProfile -Command "netstat -s -p tcp | Select-String -Pattern 'Retransmitted|Segments Retransmitted|Errors'"
Segments Retransmitted          = 1842

Ce que cela signifie : Des retransmissions existent. Certaines sont normales, mais beaucoup durant une seule copie est suspect.

Décision : Si les retransmissions augmentent fortement pendant les transferts, vérifiez les mismatches MTU, le duplex, les optiques, les drops de buffer sur le switch et les problèmes de driver NIC. SMB paraîtra « lent » parce que TCP répare les dégâts.

Task 15: Validate MTU/jumbo frames consistency (Windows side)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Where-Object {$_.InterfaceAlias -like 'Ethernet*' -and $_.AddressFamily -eq 'IPv4'} | Select InterfaceAlias,NlMtu | Format-Table -AutoSize"
InterfaceAlias NlMtu
-------------- -----
Ethernet0      9000
Ethernet1      1500

Ce que cela signifie : Vous avez un mismatch MTU entre interfaces. Si SMB Multichannel répartit le trafic sur les deux, vous pouvez observer un comportement imprévisible.

Décision : Standardisez l’MTU de bout en bout selon le design réseau. Si ce n’est pas possible, contraignez les interfaces que SMB peut utiliser (avec précaution), ou corrigez la deuxième interface.

Task 16: Check disk latency on the server during the copy

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write' -SampleInterval 1 -MaxSamples 5 | Select -ExpandProperty CounterSamples | Format-Table -AutoSize Path,CookedValue"
Path                                         CookedValue
----                                         -----------
\\FS01\physicaldisk(_total)\avg. disk sec/read 0.0021
\\FS01\physicaldisk(_total)\avg. disk sec/write 0.0385

Ce que cela signifie : Des écritures moyennes ~38 ms ne sont pas « stockage rapide ». Cela plafonnera les performances SMB d’écriture indépendamment des capacités réseau.

Décision : Si les pics de latence disque coïncident avec SMB lent, vous faites face à une contention stockage, une pénalité RAID, un overhead snapshot, un antivirus ou un backend bridant les I/O.

Trois mini-récits en entreprise (ce qui arrive réellement)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Le ticket était simple : « Les partages de l’équipe engineering sont lents ; les builds expirent. » C’était un lundi, bien sûr, et l’astreint avait déjà subi des notifications Slack depuis une heure. Le serveur de fichiers disposait de deux ports 10GbE. Les ports du switch semblaient ok. Le tableau de bord du stockage était au vert. Tout le monde supposait que le réseau et le stockage allaient bien, donc ce devait être « SMB qui fait son SMB ».

La mauvaise hypothèse : « Deux NIC signifient que la copie utilisera automatiquement les deux. » Quelqu’un avait configuré du NIC teaming des années plus tôt, puis l’avait retiré lors d’une mise à jour de driver sans revoir le profil de performance. Multichannel SMB était désactivé sur le serveur de fichiers parce qu’une ancienne baseline de durcissement l’avait coupé et personne ne l’avait remarqué.

Les symptômes étaient classiques : un flux TCP unique épinglait un seul cœur CPU, le débit plafonnait à ce qu’un cœur occupé pouvait traiter, et plusieurs clients se retrouvaient poliment mis en file d’attente. Le serveur disposait de beaucoup de CPU au total, mais le travail n’était pas réparti.

La correction fut douloureusement banale : activer SMB Multichannel, vérifier que RSS était activé, et valider que plusieurs connexions SMB apparaissaient pour les clients actifs. Le débit a doublé pour de nombreux clients immédiatement, et le chœur « le réseau est lent » s’est tu jusqu’au prochain incident, comme de tradition.

La leçon n’était pas « Multichannel est magique ». C’était : ne supposez pas que vous utilisez les fonctionnalités matérielles que vous avez achetées. Vérifiez le comportement négocié, pas juste la case cochée.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Autre lieu, autre saveur de douleur. Une initiative sécurité a décidé que tous les partages de fichiers devaient exiger le chiffrement SMB. Objectif raisonnable. Le déploiement fut rapide, massif et validé par plusieurs comités — ce qui veut dire que personne n’a fait de bench.

En quelques jours, les utilisateurs se sont plaints que les copies volumineuses étaient « saccadées ». Le CPU du serveur n’était pas saturé globalement, mais le système semblait étrangement contraint pendant les heures de pointe. L’équipe stockage pointait l’équipe réseau. L’équipe réseau pointait l’équipe stockage. Pendant ce temps, les développeurs copiaient les données en local, ce qui n’est jamais la victoire conformité souhaitée.

La cause racine était prévisible : le chiffrement ajoutait une charge CPU qui déplaçait le goulot de la NIC vers le CPU, et sous certaines charges le coût crypto se concentrait de façon non linéaire par cœurs. Multichannel a aidé un peu, RSS un peu, mais le plafond fondamental avait bougé.

L’équipe a retiré la politique globale et l’a remplacée par un chiffrement au niveau des partages sensibles, plus un plan de renouvellement matériel pour les serveurs nécessitant un chiffrement omniprésent à haut débit. La sécurité a obtenu des améliorations réelles. Les opérations ont retrouvé des performances. Personne n’a prétendu que la physique était optionnelle.

Blague #2 : Activer le chiffrement partout sans tester, c’est comme coller un sticker « turbo » sur votre voiture en espérant que le moteur se sente motivé.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation, autre plateforme de fichiers. Ils faisaient des « contrôles ennuyeux » trimestriels sur leurs serveurs Windows : exporter les configs SMB, capturer les versions des drivers NIC, valider l’état RSS et exécuter un test de débit standardisé depuis un jump host. Pas de héros. Pas de surprises à minuit. Juste un rituel.

Pendant un trimestre, le test a montré une baisse de débit sur un nœud du cluster. Rien n’était « down ». Les utilisateurs ne s’étaient pas encore plaints. Mais la tendance était évidente : le nœud était plus lent que ses pairs de manière significative.

Parce qu’ils disposaient de baselines, ils ont comparé les configurations et ont découvert qu’après une mise à jour firmware la NIC avait RSS désactivé sur ce nœud seulement. C’était un simple toggle. La mise à jour vendeur n’avait pas « cassé SMB » ; elle avait modifié un comportement NIC critique pour la performance.

Ils ont réactivé RSS, relancé le test et le nœud est revenu dans la moyenne. Pas d’incident. Pas d’e-mails exécutifs. Les meilleures pannes sont celles qu’on n’a pas eues.

Erreurs fréquentes : symptôme → cause racine → correction

Cette section est directe parce que votre temps est précieux.

1) Débit coincé autour de 80–200 MB/s sur 10GbE

Symptôme : Une copie séquentielle volumineuse n’approche jamais le débit du lien ; le CPU montre un cœur chaud.

Cause racine : Session SMB à connexion unique et/ou RSS désactivé (traitement mono‑cœur des paquets).

Correction : Activez SMB Multichannel des deux côtés ; vérifiez plusieurs connexions multichannel ; activez RSS et assurez plusieurs files de réception ; mettez à jour drivers/firmware NIC si RSS se comporte mal.

2) Multichannel « activé » mais une seule connexion apparaît

Symptôme : EnableMultichannel=True, mais Get-SmbMultichannelConnection n’affiche qu’une ligne.

Cause racine : Une seule interface/IP éligible ; la liste d’interfaces client SMB n’inclut pas la seconde NIC ; pare‑feu/routage empêche le chemin parallèle ; interfaces non compatibles RSS.

Correction : Vérifiez Get-SmbClientNetworkInterface et Get-SmbServerNetworkInterface ; assurez‑vous que les deux côtés ont des IP atteignables sur chaque interface ; confirmez la compatibilité RSS ; corrigez les règles de pare‑feu pour SMB (TCP 445) sur chaque interface.

3) Les copies sont rapides en lecture, terribles en écriture

Symptôme : Téléchargement depuis le partage ok ; téléversement rame ; latence d’écriture disque en pic.

Cause racine : Pénalité/latence du backend stockage sur écritures (RAID, snapshots, thin provisioning, contention) ou analyse antivirus sur les écritures.

Correction : Mesurez la latence d’écriture pendant la copie ; vérifiez les exclusions/tuning antivirus ; validez la santé du pool et le comportement du cache d’écriture ; évitez de diagnostiquer cela comme « réseau ».

4) Performance saccadée : rapide puis blocage

Symptôme : Le débit oscille ; les utilisateurs décrivent des « blocages ».

Cause racine : Retransmissions dues à mismatch MTU, microbursts, drops de buffer sur switch, ou offloads problématiques ; parfois drivers filtres.

Correction : Vérifiez les retransmissions ; standardisez l’MTU de bout en bout ; validez les compteurs de port switch ; envisagez de désactiver seulement la fonctionnalité d’offload problématique après preuve (pas sur des impressions).

5) SMB lent seulement pour un subnet/VLAN

Symptôme : Même serveur, réseau client différent, débits très différents.

Cause racine : MTU de chemin différent, ACLs, politique QoS, ou asymétrie de routage ; parfois un accélérateur WAN « utile ».

Correction : Comparez les résultats iperf par subnet ; vérifiez MTU et retransmissions ; confirmez la symétrie du routage ; auditez les politiques QoS.

6) Tout est plus lent après un « durcissement »

Symptôme : Après le déploiement d’une baseline, le débit SMB baisse et le CPU augmente.

Cause racine : Signature requise partout ; chiffrement forcé partout ; Multichannel désactivé ; paramètres de compatibilité legacy.

Correction : Inspectez les deltas de configuration SMB client/serveur ; appliquez le chiffrement de façon sélective ; conservez la signature si nécessaire ; réactivez Multichannel avec validation.

Listes de contrôle / plan pas à pas

Checklist A: Retrouver le débit attendu sur un LAN 10/25GbE

Confirmer la vitesse du lien sur les NIC client et serveur (Get-NetAdapter).
Confirmer le dialecte SMB est 3.x (Get-SmbConnection).
Activer et vérifier SMB Multichannel sur les deux extrémités (Get-Smb*Configuration, Get-SmbMultichannelConnection).
Vérifier RSS est activé avec plusieurs files (Get-NetAdapterRss).
Exécuter iperf pour valider que le débit réseau brut correspond aux attentes.
Surveiller la distribution CPU pendant un transfert soutenu (compteurs Perf).
Vérifier la latence disque pendant le même transfert (compteurs Perf).
Ce n’est qu’ensuite que vous touchez aux offloads, jumbo frames et autres réglages avancés.

Checklist B: Vérifier que Multichannel fait réellement le travail (pas seulement activé)

Sur le client, lister les interfaces clients SMB (Get-SmbClientNetworkInterface). Vous voulez plusieurs interfaces éligibles.
Sur le serveur, lister les interfaces serveur SMB (utilisez Get-SmbServerNetworkInterface quand disponible) et confirmer les IP correspondantes.
Démarrer un transfert soutenu (gros fichier, pas un répertoire de petits fichiers).
Vérifier Get-SmbMultichannelConnection pendant que le transfert s’exécute.
Si vous voyez toujours une connexion, investiguez pare‑feu/routage/MTU/éligibilité RSS.

Checklist C: Décider si le chiffrement est votre goulot

Confirmer si le chiffrement est activé par partage/session (Get-SmbShare, Get-SmbConnection).
Réaliser la même copie avec chiffrement désactivé sur un partage test (si la politique le permet) pour comparer.
Pendant la copie chiffrée, surveiller le CPU et les hotspots par cœur.
Si le CPU est limitant, choisir une option : plus de CPU, chiffrement sélectif, ou RDMA (SMB Direct) quand approprié.

FAQ

1) SMB Multichannel est‑il la même chose que le NIC teaming ?

Non. Le teaming est une construction NIC/driver ; Multichannel est SMB utilisant plusieurs connexions au niveau protocole/session. Vous pouvez utiliser Multichannel sans teaming, et souvent vous devriez.

2) Si j’ai une seule NIC 25GbE, Multichannel peut‑il aider ?

Parfois. Multichannel peut créer plusieurs connexions sur une même interface, mais le gain majeur sur une NIC unique et rapide vient généralement de RSS et d’un nombre suffisant de files de réception et de CPU pour traiter les paquets.

3) Pourquoi une seule copie SMB n’atteint‑elle pas le débit maximal ?

Parce qu’un flux TCP unique peut être limité par le traitement des paquets sur un cœur, le contrôle de congestion, la perte et la latence. Multichannel et RSS réduisent ces goulots en parallèleisant le travail.

4) SMB Multichannel s’active‑t‑il automatiquement quand il est activé ?

Il négocie automatiquement, mais seulement si les deux côtés le supportent et voient plusieurs chemins/interfaces éligibles. « Activé » n’est pas synonyme d’« actif ». Vérifiez toujours avec Get-SmbMultichannelConnection.

5) Dois‑je activer les jumbo frames pour corriger la lenteur SMB ?

Pas comme premier geste. Les jumbo frames peuvent améliorer l’efficacité CPU, mais un déploiement partiel cause des pertes/retransmissions et rend SMB pire. Corrigez Multichannel/RSS et confirmez l’absence de pertes d’abord.

6) Le chiffrement SMB va‑t‑il ruiner les performances ?

Ça dépend des capacités CPU, de la charge et de la vitesse du lien. Sur des CPU modernes, c’est souvent acceptable ; sur des serveurs plus anciens ou des liens très rapides, ça peut devenir lié au CPU. Mesurez avant/après et envisagez le chiffrement sélectif.

7) Pourquoi copier beaucoup de petits fichiers est‑il plus lent qu’un gros fichier ?

Les opérations de métadonnées, l’énumération de répertoires et les coûts d’ouverture/fermeture par fichier dominent. Multichannel aide le débit, mais il n’élimine pas la bavarderie et l’overhead métadonnées inhérents aux « millions de petits fichiers ».

8) Un antivirus sur le serveur de fichiers peut‑il ralentir SMB ?

Oui, surtout sur les écritures. L’analyse en temps réel peut ajouter une latence par opération et transformer un débit régulier en rafales. Coordonnez les exclusions et modes d’analyse avec les équipes sécurité et validez avec les compteurs de latence disque.

9) Quelle est la différence entre SMB Multichannel et SMB Direct ?

Multichannel utilise plusieurs connexions TCP. SMB Direct utilise RDMA (NICs et configuration spécifiques) pour contourner des parties de la pile TCP/IP et réduire latence et usage CPU. Excellent quand on peut l’utiliser ; Multichannel est le gain le plus courant.

10) Quel est le moyen le plus rapide de prouver que ce n’est pas le réseau ?

Exécutez iperf entre les mêmes hôtes sur les mêmes interfaces et comparez. Si iperf atteint le débit attendu mais SMB ne l’atteint pas, le goulot est probablement la configuration SMB, le CPU, le chiffrement ou le stockage.

Conclusion : prochaines étapes à faire aujourd’hui

Si SMB est lent, cessez de le traiter comme un problème mystique de Windows. C’est un système : NICs, files CPU, comportement TCP, surcharge de sécurité et latence stockage se retrouvent tous dans le résultat final.

Vos prochaines étapes pratiques :

Vérifier que SMB Multichannel est activé sur le client et le serveur, puis vérifier qu’il est actif avec Get-SmbMultichannelConnection.
Valider RSS et le nombre de files sur les NIC qui transportent le trafic SMB.
Mesurer le débit réseau brut avec iperf pour séparer réseau et SMB/stockage.
Mesurer CPU et latence disque pendant le même transfert ; identifiez quel sous‑système limite réellement.
Être délibéré concernant le chiffrement : l’appliquer là où c’est requis et provisionner le CPU en conséquence.

Faites cela, et « SMB est lent » devient généralement un goulot concret et corrigeable. Le meilleur type de problème : celui qui se termine.