SMB Multichannel : quand il aide (et quand il nuit)

Ce que fait réellement SMB Multichannel (et ce qu’il ne fait pas)

SMB Multichannel est une fonctionnalité de SMB 3.x où une seule session SMB peut utiliser plusieurs connexions TCP en parallèle. Ces connexions peuvent emprunter différentes cartes réseau, différentes adresses IP, et dans certains cas des chemins physiques différents. L’objectif est simple : agréger la bande passante et améliorer la résilience sans nécessiter d’agrégation de liens sur le commutateur.

La grande promesse : bande passante et redondance sans les drames LACP

Dans une bonne conception, Multichannel réalise deux choses très pratiques :

• Mise à l’échelle du débit : plusieurs connexions SMB peuvent lire/écrire simultanément, poussant plus de données qu’un flux TCP unique ne pourrait en atteindre.
• Basculement transparent : si une carte réseau/chemin tombe, SMB peut continuer sur les connexions restantes (selon le type et le timing de la panne).

Ce n’est pas magique. Ça ne répare pas des disques lents. Ça n’annule pas une perte de paquets. Ça n’améliore pas la latence sur un commutateur congestionné. En revanche, cela rend vos schémas de trafic plus complexes — ce qui veut dire, poliment : vos hypothèses se confrontent à la réalité.

Ce que Multichannel n’est pas

• Ce n’est pas du NIC teaming : le teaming agrège les liens au niveau L2/L3 ; SMB Multichannel est un comportement au niveau application. Ils peuvent coexister, mais c’est souvent ainsi que surgissent des pannes intéressantes.
• Ce n’est pas un « équilibrage parfait » garanti : les flux peuvent ne pas se répartir également. Un chemin peut encore supporter la majorité de la charge.
• Ce n’est pas un substitut au QoS : si vous partagez le même uplink congestionné, vous ajoutez simplement plus de flux dans le même embouteillage.

Comment il choisit ce qu’il utilise

Multichannel découvre plusieurs « interfaces client-serveur » basées sur les adresses IP, les propriétés des cartes réseau et (sous Windows) la capacité RSS (Receive Side Scaling) et la capacité RDMA. Ensuite il crée une ou plusieurs connexions par interface, influencé par des éléments comme le nombre de files RSS et la disponibilité de RDMA.

La conclusion opérationnelle : Multichannel est une fonctionnalité réseau + pilote + OS. Les ingénieurs stockage l’adorent traiter comme une fonctionnalité de stockage. Les ingénieurs réseau l’adorent traiter comme une application. C’est les deux. C’est pourquoi il peut sembler être un fantôme dans la machine.

Une idée paraphrasée attribuée à John Allspaw (opérations/fiabilité) : l’échec est rarement un seul bug ; c’est une propriété émergente des systèmes complexes. SMB Multichannel est un excellent moyen d’ajouter de la complexité — parfois de la bonne complexité.

Quand Multichannel aide : le chemin heureux

1) Vous avez du parallélisme réel à exploiter

Multichannel brille lorsque la charge de travail peut réellement consommer plus de bande passante : lectures/écritures séquentielles volumineuses, copies multi‑threads, stockage de VM sur SMB (Hyper-V), flux de sauvegarde, workflows média, fermes de compilation. Si votre charge est une application mono‑thread lisant de petits fichiers, vous verrez peut‑être aucune amélioration et plein de nouvelles variables.

2) Vous avez plusieurs chemins réels, pas juste des adresses IP en double

Deux cartes réseau branchées sur le même commutateur top-of-rack avec un seul uplink 10Gb ne sont pas « deux chemins ». Ce sont deux bretelles vers la même autoroute. Multichannel aide toujours contre les goulots côté hôte (limitations d’un flux unique), mais il ne résoudra pas la congestion en amont.

Les meilleurs gains proviennent de :

• Cartes NIC duales sur client et serveur
• Commutateurs séparés (ou au moins chemins ASIC séparés)
• VLANs/sous‑réseaux distincts pour éviter une asymétrie de routage accidentelle
• Ethernet propre et à faible perte (surtout si RDMA est utilisé)

3) RSS est activé et fonctionne réellement

Pour SMB non‑RDMA, vous voulez RSS afin que plusieurs cœurs CPU puissent traiter la pile de réception. Si RSS est désactivé, un seul cœur peut devenir le goulot, et Multichannel peut créer plus de travail sans élever le plafond.

4) RDMA (SMB Direct) est présent et stable

Avec des cartes RDMA (RoCE ou iWARP), SMB peut utiliser SMB Direct, contournant des parties de la pile TCP/IP pour réduire la charge CPU et améliorer la latence. Multichannel devient alors un moyen d’utiliser plusieurs interfaces RDMA et d’obtenir à la fois débit et résilience.

Si RDMA est stable, Multichannel est souvent un gros gain. Si RDMA est instable, Multichannel peut créer une maison hantée : pauses intermittentes, comportement de repli et billets « ça n’arrive que le mardi ».

5) Vous vous souciez du comportement de basculement plus que du débit maximal

Même si vous n’avez pas besoin d’un débit agrégé, Multichannel peut être une fonctionnalité de résilience. Un simple flap de lien ne devrait pas interrompre un partage de fichiers occupé. Ce n’est pas un substitut à une haute disponibilité correcte, mais c’est une couche utile dans l’empilement.

Quand Multichannel nuit : modes de panne reproductibles

1) Routage asymétrique ou équipements réseau « aidants »

Multichannel ouvre plusieurs connexions. Si vos politiques de routage ou de pare‑feu traitent les chemins différemment, vous aurez une latence incohérente, des retransmissions ou des pertes nettes. Les dispositifs à état peuvent aussi être confus si des flux traversent différents middleboxes de façon inattendue.

Symptômes : pauses aléatoires, débit inégal, latence avec longue queue pour les opérations fichier. Le réseau semble « correct » jusqu’à ce que vous décomposiez par flux.

2) Vous avez activé à la fois le NIC teaming et Multichannel sans plan

Ce n’est pas toujours mauvais, mais c’est fréquemment inutile ou contre‑productif. Le teaming fournit déjà une interface unique à SMB ; Multichannel voit alors moins d’interfaces distinctes. Pire, certains modes de teaming interagissent mal avec RSS, les offloads ou le hachage du commutateur.

Si vous le faites parce que « plus, c’est mieux », arrêtez. Concevez d’abord.

3) Perte de paquets, micro‑bursts ou mauvais réglage DCB/PFC (surtout RDMA)

RDMA veut une voie propre. Sur RoCE, on utilise souvent DCB/PFC pour éviter les pertes. Mal configurer PFC peut créer un blocage head-of-line où une classe de priorité congestionnée bloque les autres. Multichannel peut amplifier le rayon d’impact en poussant plus de trafic en parallèle.

Blague #1 : RDMA, c’est comme une voiture de course — rapide, coûteuse, et elle vous punira si vous la conduisez comme une voiture de location.

4) Surcharge CPU et tempêtes d’interruptions dues aux « bonnes intentions en trop grand nombre »

Plus de canaux signifie plus de connexions, plus d’interruptions, plus d’état par connexion, plus de contention de verrous dans le noyau. Si le pilote NIC ou le firmware n’est pas heureux, Multichannel peut transformer un serveur confortable en machine liée au CPU qui donne malgré tout l’impression d’être « lente ».

Cela est courant avec :

• Pilotes/firmware anciens
• VMs avec vCPU contraints et voisins bruyants
• Mauvais réglage du nombre de files RSS

5) La latence du stockage devient visible (Multichannel ne l’a pas causée — vos utilisateurs l’ont juste découverte)

Quand vous retirez un goulot réseau, vous exposez le suivant. Peut‑être que c’est le pool de disques, peut‑être les IOPS de métadonnées, peut‑être l’antivirus sur le serveur de fichiers. Multichannel est accusé parce que c’était le dernier changement. Parfois il est coupable. Souvent il est le messager.

6) « Ça marchait en labo » (parce que le labo n’avait pas d’entropie)

Multichannel en production est sensible au bazar du monde réel : flaps de lien, pression sur les buffers de commutateur, bizarreries de firmware, clients non uniformes, et ce périphérique legacy qui trafique les timestamps TCP.

Blague #2 : Le labo, c’est l’endroit où les designs vont se sentir bien dans leur peau.

Faits intéressants et contexte historique

• SMB 3.0 est apparu avec Windows Server 2012, apportant Multichannel et SMB Direct au mainstream pour les serveurs de fichiers Windows.
• Multichannel a été conçu en partie pour la virtualisation : Hyper‑V sur SMB avait besoin à la fois d’un haut débit et de résilience sans obliger chaque infrastructure à maîtriser l’agrégation de liens.
• SMB Direct (RDMA) est une capacité séparée que Multichannel peut utiliser ; Multichannel est la logique « chemins multiples », RDMA est le transport « voie rapide ».
• La capacité RSS influence le nombre de connexions créées sous Windows ; Multichannel peut ouvrir plusieurs connexions par interface pour paralléliser le traitement des réceptions.
• Multichannel ne nécessite pas de configuration de commutateur comme le fait LACP, ce qui le rend attractif dans des environnements avec un contrôle de changement réseau strict.
• Le chiffrement SMB peut réduire le débit et augmenter l’utilisation CPU ; Multichannel peut aider à récupérer du débit, mais vous pouvez rapidement devenir limité par le CPU.
• SMB over QUIC existe (Windows plus récent), mais c’est une histoire de transport différente ; le comportement classique de Multichannel est lié à SMB sur TCP.
• Linux Samba a ajouté le support SMB3 Multichannel plus tard que Windows ; pendant des années, c’était un avantage Windows-first dans les environnements mixtes.

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

Premier : décidez si vous avez un problème réseau, hôte ou stockage

1. Vérifiez si SMB utilise réellement Multichannel (ne supposez pas). S’il ne l’utilise pas, arrêtez de chasser des « bugs Multichannel ».
2. Vérifiez la perte de paquets/retransmissions. S’il y a de la perte, l’optimisation des performances est du théâtre.
3. Vérifiez la saturation CPU et la pression d’interruptions sur le client et le serveur. Si un cœur est saturé, votre « 10GbE » est décoratif.
4. Vérifiez la latence de stockage sur le serveur de fichiers. Si vos disques sont lents, le parallélisme réseau ne fait que mettre en file d’attente plus vite.

Deuxième : isolez une variable à la fois

1. Testez NIC unique vs Multichannel (désactiver/activer) pour confirmer la causalité.
2. Testez client unique vs plusieurs clients. Certains problèmes n’apparaissent qu’en concurrence.
3. Testez séquentiel large vs aléatoire petit. Le goulot change.

Troisième : validez la symétrie de chemin et la sélection d’interface

1. Confirmez quelles IP sont utilisées pour les connexions SMB.
2. Confirmez que le design VLAN/sous‑réseau empêche un routage inattendu.
3. Confirmez que le teaming, le bridging ou les commutateurs virtuels ne cachent pas des interfaces à SMB.

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

Ces tâches supposent que vous dépannez SMB Multichannel entre un client Windows et un serveur Windows, avec quelques outils Linux là où ils sont utiles. Les commandes sont montrées depuis un jump host Linux et PowerShell Windows. Oui, l’invite est une tromperie ; c’est un habillage cohérent pour que les blocs de code correspondent au format requis. Exécutez les commandes PowerShell dans PowerShell.

Task 1: Verify Multichannel is enabled on Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientConfiguration | Select EnableMultiChannel"
EnableMultiChannel
------------------
True

Ce que cela signifie : Le client est autorisé à utiliser Multichannel.

Décision : Si False, activez‑le pour les tests (Set-SmbClientConfiguration -EnableMultiChannel $true) ou laissez‑le désactivé volontairement et ne vous attendez pas à un comportement multichannel.

Task 2: Verify Multichannel is enabled on the server

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select EnableMultiChannel"
EnableMultiChannel
------------------
True

Ce que cela signifie : Le serveur négociera Multichannel.

Décision : Si False, l’activer est généralement sans risque sur des serveurs modernes — sauf si vous êtes dans un environnement de pilotes connus pour être problématiques. Si vous dépannez une instabilité, désactivez temporairement pour confirmer la causalité.

Task 3: See what SMB thinks the interfaces are (client-side)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientNetworkInterface | Sort-Object InterfaceIndex | Format-Table InterfaceIndex,IPAddress,RssCapable,RdmaCapable,LinkSpeed"
InterfaceIndex IPAddress      RssCapable RdmaCapable LinkSpeed
-------------- ---------      ---------- ----------  ---------
12             10.10.10.21    True       False       10 Gbps
13             10.10.20.21    True       False       10 Gbps

Ce que cela signifie : SMB voit deux interfaces client, toutes deux compatibles RSS. Bon point de départ.

Décision : Si l’une affiche RssCapable False ou un LinkSpeed incorrect, vous n’aurez peut‑être pas de parallélisme. Corrigez le pilote NIC/la configuration RSS avant de blâmer SMB.

Task 4: Confirm the server’s SMB network interfaces

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerNetworkInterface | Sort-Object InterfaceIndex | Format-Table InterfaceIndex,IPAddress,RssCapable,RdmaCapable,LinkSpeed"
InterfaceIndex IPAddress      RssCapable RdmaCapable LinkSpeed
-------------- ---------      ---------- ----------  ---------
9              10.10.10.10    True       False       10 Gbps
10             10.10.20.10    True       False       10 Gbps

Ce que cela signifie : Le serveur est lui aussi doublement connecté pour SMB.

Décision : Si le serveur ne liste qu’une interface, vérifiez si l’autre NIC est en team, down, sur un profil différent ou filtrée par les métriques d’interface SMB.

Task 5: Confirm an SMB session is using multiple channels

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbMultichannelConnection | Format-Table ServerName,ClientIPAddress,ServerIPAddress,ClientRSSCapable,State"
ServerName ClientIPAddress ServerIPAddress ClientRSSCapable State
---------- -------------- -------------- --------------- -----
FS01       10.10.10.21    10.10.10.10    True            Active
FS01       10.10.20.21    10.10.20.10    True            Active

Ce que cela signifie : Deux canaux actifs existent. Multichannel est réel, pas théorique.

Décision : Si vous ne voyez qu’une connexion, vous ne faites pas de multichannel. Examinez la découverte d’interfaces, DNS, routage, contraintes SMB ou la charge qui ne déclenche pas de canaux supplémentaires.

Task 6: Check whether SMB is falling back from RDMA to TCP (if RDMA is expected)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbMultichannelConnection | Select ServerName,ClientIPAddress,ServerIPAddress,RdmaCapable | Format-Table"
ServerName ClientIPAddress ServerIPAddress RdmaCapable
---------- -------------- -------------- ----------
FS01       10.10.30.21    10.10.30.10    True
FS01       10.10.40.21    10.10.40.10    True

Ce que cela signifie : Les interfaces sont RDMA‑capables. C’est nécessaire, pas suffisant.

Décision : Si RdmaCapable est False de façon inattendue, confirmez le modèle/driver NIC et que RDMA est activé au niveau OS et commutateur (et que VLAN/MTU/DCB correspondent).

Task 7: Observe TCP retransmits from a Linux host near the path

cr0x@server:~$ ss -ti dst 10.10.10.10 | head -n 12
ESTAB 0 0 10.10.10.21:49822 10.10.10.10:445
	 cubic wscale:7,7 rto:204 rtt:1.22/0.41 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:10 bytes_acked:1294832 segs_out:985 segs_in:902 send 95.0Mbps lastsnd:12 lastrcv:12 lastack:12 pacing_rate 190Mbps retrans:0/0

Ce que cela signifie : Des compteurs retrans à 0 suggèrent aucune perte visible sur ce flux.

Décision : Si les retransmissions augmentent pendant les blocages, réparez d’abord le réseau : optiques défaillantes, buffers congestionnés, MTU incohérent ou policing.

Task 8: Confirm MTU consistency (Linux example)

cr0x@server:~$ ip link show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff

Ce que cela signifie : MTU 9000 sur une interface. Si d’autres sont à 1500, vous avez une discordance.

Décision : Maintenez la MTU cohérente bout en bout par VLAN. Les frames jumbo partiellement déployées sont une source classique de « ça marche jusqu’à ce que ça casse ».

Task 9: Spot RSS state on Windows NICs

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

Ce que cela signifie : RSS est activé, 8 files actives.

Décision : Si RSS est désactivé, activez‑le. Si les files sont trop peu nombreuses pour votre CPU/NIC, vous pouvez être lié côté réception. Si elles sont trop nombreuses, vous gaspillerez du CPU et augmenterez la contention. Tondez délibérément.

Task 10: Measure per-NIC throughput to see whether traffic is actually split

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Network Interface(*)\Bytes Total/sec' -SampleInterval 1 -MaxSamples 3 | Select -ExpandProperty CounterSamples | Sort-Object InstanceName | Select InstanceName,CookedValue"
InstanceName                         CookedValue
------------                         -----------
Intel[R] Ethernet 10G 2              485000000
Intel[R] Ethernet 10G 1              512000000

Ce que cela signifie : Les deux NIC transportent du trafic significatif. Multichannel fournit une bande passante agrégée.

Décision : Si une NIC est proche de zéro, vous pouvez avoir des problèmes de métriques d’interface, d’asymétrie de routage ou un chemin dégradé (SMB peut l’éviter).

Task 11: Check SMB client-side connection details (including dialect)

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

Ce que cela signifie : Le dialecte 3.1.1 indique un SMB moderne. Bien. La disponibilité continue dépend des réglages du partage/cluster.

Décision : Si vous voyez SMB 2.x, vous êtes privé de fonctionnalités et pouvez être coincé dans un comportement legacy à cause de politiques, d’un serveur ancien ou de paramètres de compatibilité.

Task 12: Check server CPU pressure quickly (Linux or Windows Server Core via typeperf is fine; here’s Linux top as proxy)

cr0x@server:~$ mpstat -P ALL 1 1
Linux 6.5.0 (fs01) 	02/05/2026 	_x86_64_	(32 CPU)

02:14:29 PM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
02:14:30 PM  all   18.2  0.0   9.4  1.1     0.6  3.0   0.0    67.7

Ce que cela signifie : Beaucoup de CPU libre. Si ceci était saturé, SMB pourrait être lié au CPU.

Décision : Si le CPU est élevé sur %soft/%irq, suspectez une pression d’interruptions, des problèmes d’offload ou une mauvaise configuration RSS. Si %iowait est élevé, suspectez la latence stockage.

Task 13: Check disk latency on a Windows file server (Perf counter snapshot)

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

Ce que cela signifie : Les lectures sont ~4 ms, les écritures ~21 ms. Les écritures peuvent être le facteur limitant si les utilisateurs se plaignent lors de périodes d’écriture intense.

Décision : Si la latence est élevée, ne comptez pas sur Multichannel pour la corriger. Examinez le cache, la disposition RAID, la profondeur des files, le tiering ou la saturation du backend.

Task 14: Confirm DNS resolves to the intended IPs (avoid “wrong interface” surprises)

cr0x@server:~$ nslookup fs01
Server:		10.10.0.53
Address:	10.10.0.53#53

Name:	fs01.corp.example
Address: 10.10.10.10
Name:	fs01.corp.example
Address: 10.10.20.10

Ce que cela signifie : Deux enregistrements A, correspondant probablement aux deux interfaces SMB.

Décision : Si DNS ne renvoie qu’une IP, Multichannel peut encore fonctionner via la découverte d’interfaces, mais la résolution de nom influence quelle IP serveur est « primaire » et peut affecter les politiques de routage/pare‑feu. Corrigez l’enregistrement DNS et les priorités d’interface si nécessaire.

Task 15: Validate SMB port reachability across both subnets

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.10.10.10 -Port 445 | Select ComputerName,RemotePort,TcpTestSucceeded"
ComputerName RemotePort TcpTestSucceeded
------------ ---------- ----------------
10.10.10.10   445       True

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.10.20.10 -Port 445 | Select ComputerName,RemotePort,TcpTestSucceeded"
ComputerName RemotePort TcpTestSucceeded
------------ ---------- ----------------
10.10.20.10   445       True

Ce que cela signifie : Les deux interfaces sont joignables sur TCP/445.

Décision : Si l’une échoue, Multichannel ne peut pas l’utiliser. Réparez les règles de pare‑feu, le routage ou les ACLs. Ne pas activer à moitié Multichannel en espérant qu’il trouve un chemin.

Trois mini-récits du monde entreprise (réalistes, anonymisés)

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

Ils avaient un nouveau couple de serveurs de fichiers pour les répertoires utilisateurs de l’ingénierie. Dual 10GbE, beaux commutateurs, VLANs propres. Le plan de déploiement était conservateur : activer SMB Multichannel (par défaut), vérifier que les deux liens s’allument, et passer à autre chose.

Dans la semaine, les utilisateurs CAO ont commencé à signaler des « gels » à l’ouverture d’assemblages. Pas un chargement lent — des gels. L’application cessait de répondre et Windows semblait réfléchir pendant 10–20 secondes. L’équipe Ops a regardé le serveur de fichiers et a vu que le débit moyen était correct. Le CPU correct. La latence disque correcte. Les graphes réseau ennuyeux. Les tickets continuaient d’arriver.

L’hypothèse erronée était subtile : ils supposaient que les deux chemins SMB étaient équivalents parce qu’ils étaient tous deux en 10GbE. Un chemin, cependant, traversait un cluster de pare‑feu à cause d’un VLAN mal tagué sur un port de commutateur. Il passait toujours du trafic. Il introduisait juste de la gigue et des pertes occasionnelles sous charge parce que le pare‑feu faisait de l’inspection d’état et du logging sur un chemin qui n’était pas prévu pour le trafic est‑ouest de fichiers.

Multichannel a aggravé la situation en utilisant les deux chemins. Certaines lectures empruntaient le chemin propre, d’autres le chemin « accidentellement via pare‑feu ». L’application a vécu une latence incohérente et l’a interprétée comme des blocages I/O.

La correction n’a pas été héroïque : corriger le tagging VLAN, retirer le pare‑feu du chemin de données et retester. Ils ont aussi ajouté une validation standard : traceroute et vérification des ACL pour chaque sous‑réseau SMB, pas seulement « ping OK ». La leçon est restée car l’incident était embarrassant d’une manière très précise : le réseau était « up » et l’application était « down ».

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

Une autre société avait un cluster Hyper‑V utilisant SMB pour le stockage des VM. Les performances étaient correctes mais pas excellentes. Quelqu’un a proposé un « gain facile » : augmenter les files RSS et activer toutes les options d’offload dans les propriétés avancées du NIC. Plus de files, plus d’offloads, plus de vitesse. C’est comme ça que ça marche, non ?

Pendant environ 48 heures, les graphes avaient l’air meilleurs. Puis des pauses intermittentes sont apparues : des migrations à chaud bloquaient parfois quelques secondes, et le trafic SMB similaire à CSV du cluster montrait des pics de latence périodiques. Rien de suffisamment cohérent pour crier « cassé », juste assez pour rendre la plateforme peu fiable.

Le retour de bâton était un cas limite pilote/firmware. Avec les nouveaux réglages, la NIC redistribuait parfois les flux entre les files d’une manière qui aggravait la contention de verrous dans la pile réseau de l’hôte. SMB Multichannel a multiplié le nombre de flux actifs, augmentant la probabilité de tomber sur le coin instable.

Ils ont restauré une baseline connue : un nombre modéré de files RSS, offloads par défaut sauf ceux recommandés pour leur modèle NIC spécifique, et ont mis à jour le firmware dans une fenêtre contrôlée. Les performances étaient légèrement inférieures au pic éphémère, mais la plateforme a cessé de « regarder dans le vide » en pleine migration.

Le postmortem recommandait, de façon rafraîchissante ennuyeuse : traiter le tuning NIC comme le tuning stockage. Un changement à la fois, mesurer et garder un plan de retour arrière. Multichannel n’a pas cassé le système. Il a exposé une optimisation instable.

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

Une société de production média exploitait un cluster de fichiers Windows avec Multichannel et (dans certains segments) RDMA. Leurs réseaux étaient rapides et leurs deadlines encore plus. Ils avaient déjà été brûlés, alors ils ont adopté une pratique dont personne ne se vantait : chaque trimestre, ils exécutaient un « health check » scripté des chemins pendant une période de faible trafic.

Le script vérifiait : les deux sous‑réseaux SMB joignables, MTU cohérente, absence de routage inattendu, connexions SMB Multichannel actives et retransmissions sous un seuil pendant un test de copie contrôlé. Il enregistrait aussi les versions de pilotes et de firmware. Si quelque chose dérivait, ça créait un ticket. Pas de panique. Un ticket.

Un trimestre, le script a détecté une légère mais constante augmentation des retransmissions sur un VLAN SMB. Pas encore de plaintes utilisateurs. Ils ont tracé cela jusqu’à un port de commutateur qui commençait à logguer des erreurs correctibles — une optique qui défaillait lentement. Ils l’ont remplacée en fenêtre de maintenance.

Deux semaines plus tard, une autre équipe a saturé le système de fichiers toute la journée. Pas d’incident. C’était le but : le travail « ennuyeux » a évité la panne spectaculaire. Multichannel a continué à faire son travail — répartir la charge et absorber les problèmes mineurs — parce que les chemins sous‑jacents étaient maintenus propres.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: Only one NIC carries traffic even though Multichannel is “enabled”

• Cause racine : SMB ne voit qu’une interface adaptée (l’autre est en team, sans RSS, filtrée ou DNS/routage la rend injoignable pour le port 445).
• Correction : Utilisez Get-SmbClientNetworkInterface/Get-SmbServerNetworkInterface et Test-NetConnection -Port 445 pour valider les deux chemins. Corrigez la joignabilité, retirez le teaming accidentel, activez RSS.

2) Symptom: Random stalls, “freezes,” long tail latency

• Cause racine : Routage asymétrique, middleboxes stateful sur un chemin, ou perte de paquets intermittente sur un lien.
• Correction : Confirmez que chaque sous‑réseau SMB est pur L2/L3 sans pare‑feu dans le chemin de données. Vérifiez les retransmissions. Réparez les erreurs physiques, la congestion des buffers ou les politiques de routage.

3) Symptom: Throughput improved, but CPU jumped and the server feels slower

• Cause racine : Pression d’interruptions/softirq, mauvais réglage RSS, ou problèmes d’offload/driver. Multichannel a augmenté la charge parallèle de réception et la surcharge.
• Correction : Validez que RSS est activé et de taille appropriée. Mettez à jour pilotes/firmware NIC. Envisagez de réduire les canaux en corrigeant les files RSS plutôt que de désactiver Multichannel globalement.

4) Symptom: RDMA environment shows periodic pauses under load

• Cause racine : Mauvaise configuration RoCE DCB/PFC provoquant un head‑of‑line blocking ; ou MTU incohérente ; ou problème de micro‑burst sur les buffers du commutateur.
• Correction : Validez la MTU bout en bout, assurez la cohérence des réglages DCB sur NICs et commutateurs, et testez avec RDMA temporairement désactivé pour confirmer. Réparez le fabric, ne masquez pas le problème.

5) Symptom: After enabling Multichannel, storage latency “suddenly got worse”

• Cause racine : Le goulot réseau a été supprimé ; le stockage est maintenant saturé. Les profondeurs de files augmentent, la latence monte, les utilisateurs blâment le dernier changement.
• Correction : Mesurez la latence disque et l’utilisation du backend. Mettez à niveau le stockage, ajustez le cache ou réduisez la concurrence. Multichannel n’est pas une fonctionnalité de QoS pour le stockage.

6) Symptom: Works from some clients, not others

• Cause racine : Versions OS mixtes, différences de politiques, différences de pilotes NIC, ou sous‑réseaux clients non symétriques.
• Correction : Comparez Get-SmbClientConfiguration, la capacité RSS/RDMA et la résolution de nom par client. Standardisez pilotes et politiques pour les clients à haut débit.

Listes de contrôle / plan étape par étape

Enable Multichannel safely (greenfield or planned change)

1. Inventaire des interfaces : listez NICs, IPs, VLANs, vitesses de lien et ports de commutateur pour client et serveur.
2. Confirmez l’indépendance des chemins : idéalement commutateurs séparés ou au moins uplinks/ASIC distincts.
3. Confirmez la joignabilité : TCP/445 doit être joignable sur chaque interface que vous attendez que SMB utilise.
4. Normalisez la MTU : 1500 partout ou jumbo partout sur ce VLAN, bout en bout.
5. Assurez‑vous que RSS est activé et que le nombre de files est raisonnable pour le nombre de cœurs CPU.
6. Hygiène pilotes/firmware : mettez à jour vers un ensemble stable connu, pas « la dernière version un vendredi ».
7. Métriques de base : débit par NIC, retransmissions, CPU, latence disque.
8. Test de charge : lancez une copie multi‑threads contrôlée ou un benchmark adapté à la charge.
9. Déploiement : activez pour un groupe pilote d’abord ; surveillez la latence en queue et les compteurs d’erreur.

When to disable Multichannel (intentionally, not as superstition)

• Vous avez un routage asymétrique connu que vous ne pouvez pas corriger rapidement et vous avez besoin de stabilité plus que de débit.
• Vous êtes dans un environnement avec middleboxes stateful traitant différemment les chemins et la réalité politique empêche une refonte.
• Vous avez des bugs de pilotes/firmware et avez besoin d’une atténuation pendant que vous planifiez des mises à jour.
• Votre charge est sensible à la latence et à faible débit, et Multichannel ajoute de l’overhead sans avantage mesurable.

Step-by-step troubleshooting plan (repeatable)

1. Confirmez le dialecte SMB négocié et que Multichannel est activé des deux côtés.
2. Confirmez que SMB utilise réellement plusieurs connexions.
3. Vérifiez la joignabilité et les règles pare‑feu/ACL pour chaque IP d’interface SMB.
4. Vérifiez la perte de paquets et les retransmissions pendant la fenêtre problématique.
5. Vérifiez la distribution du débit par NIC pendant la fenêtre problématique.
6. Vérifiez le CPU (en particulier IRQ/softirq) sur client et serveur.
7. Vérifiez la latence disque et l’utilisation du backend stockage.
8. Si RDMA : validez MTU/DCB/PFC et testez RDMA désactivé vs activé.
9. Changez une chose à la fois ; validez ; documentez la nouvelle baseline.

FAQ

1) Does SMB Multichannel replace NIC teaming?

Non. Il résout un problème similaire « utiliser plus d’un lien » à un niveau différent. Utilisez le teaming lorsque vous avez besoin des sémantiques L2/L3 (une IP/MAC) pour d’autres applications. Utilisez Multichannel lorsque l’objectif est le débit/la résilience SMB et que vous pouvez garder les chemins propres.

2) Should I enable Multichannel on a file server by default?

Sur des serveurs Windows modernes avec un réseau sain, oui. Mais « par défaut » inclut « avec validation ». Si vous ne pouvez pas valider la symétrie des chemins, la MTU et la perte de paquets, vous jouez avec la complexité.

3) Why does Multichannel sometimes not use all NICs?

Parce que SMB n’utilise que les interfaces qu’il considère adaptées et joignables, et il pondère selon les capacités (RSS/RDMA) et les métriques. De plus, certaines charges ne génèrent pas assez d’I/O parallèle pour justifier plusieurs connexions.

4) Is Multichannel useful on 1GbE?

Parfois. Il peut améliorer le débit agrégé pour des charges multi‑flux, mais le coût opérationnel peut ne pas en valoir la peine. Sur des réseaux 1GbE, la perte de paquets et les problèmes de buffers sont souvent des limites plus importantes que « le manque de canaux ».

5) Multichannel is on, but performance didn’t improve. What now?

Supposez que le goulot a bougé. Vérifiez le CPU (RSS/interrupts), puis la latence stockage. Vérifiez aussi que la charge est suffisamment parallèle — les copies mono‑thread ne scalent pas forcément.

6) Can Multichannel make performance worse?

Oui. Surtout avec perte de paquets, routage asymétrique, pilotes instables ou mauvaise configuration RDMA. Il peut augmenter l’overhead et amplifier la gigue parce que vous avez maintenant plusieurs chemins dont le comportement doit correspondre.

7) Do I need separate subnets/VLANs for Multichannel?

C’est fortement recommandé pour la clarté et pour éviter les surprises de routage. Des sous‑réseaux séparés facilitent la réflexion sur les chemins, l’application de politiques et la vérification que « interface A » correspond vraiment à « chemin switch A ».

8) How does SMB encryption interact with Multichannel?

Le chiffrement ajoute un coût CPU et peut réduire le débit. Multichannel peut aider à regagner du débit en parallélisant, mais vous pouvez vite devenir limité par le CPU. Mesurez le CPU et envisagez des CPU compatibles AES‑NI et des suites de chiffrement modernes.

9) If I use RDMA, do I still want Multichannel?

Souvent oui — plusieurs NICs RDMA peuvent fournir à la fois débit et résilience. Mais RDMA rend vos exigences de fabric plus strictes. Si votre configuration lossless est fragile, commencez par un seul chemin RDMA, stabilisez‑le, puis scalez.

Conclusion : prochaines étapes pratiques

Si vous ne retenez que trois choses, retenez celles‑ci :

1. Vérifiez que Multichannel est réellement utilisé avant de diagnostiquer quoi que ce soit d’autre. Ne déboguez pas des fantômes.
2. Éliminez la perte de paquets et l’asymétrie des chemins avant de courir après les performances. Multichannel déteste les réseaux « presque fiables ».
3. Mesurez le nouveau goulot après avoir amélioré le débit. La couche stockage accueillera volontiers votre nouvelle concurrence et vous répondra par de la latence.

Prochaines étapes réalisables cette semaine :

• Exécutez les commandes d’interface et de connexion sur un client et un serveur représentatifs ; capturez des captures d’écran pour votre runbook.
• Choisissez un partage critique et réalisez un test de charge contrôlé tout en suivant le débit par NIC, les retransmissions, le CPU et la latence disque.
• Décidez votre politique : Multichannel activé par défaut avec une checklist de validation, ou désactivé par défaut avec processus d’exception justifié. Les deux sont acceptables. « Peu importe » ne l’est pas.

SMB Multichannel est un outil puissant. Utilisé correctement, il est plus rapide et plus sûr que les anciennes astuces. Utilisé à la légère, c’est un excellent moyen de découvrir quelles parties de votre réseau tiennent ensemble par optimisme.