Transceivers dans les réseaux de stockage · Systèmes de stockage · Technologies · Documentation · CodingBox
CodingBox Documentation

Transceivers dans les réseaux de stockage

Le stockage est l’environnement où l’optique pardonne le moins : baies, HBA et commutateurs SAN valident tous les modules, les liaisons doivent être sans perte, et un transceiver limite se manifeste par de la latence applicative plutôt que par un port hors service. Cette page couvre l’usage des transceivers dans les réseaux de stockage et ce à quoi il faut faire attention.

Où se trouve l’optique

EmplacementOptiques typiquesRemarques
Ports frontaux de baie16/32GFC SFP+/SFP28 ; Ethernet 25/100G SFP28/QSFP28les constructeurs de baies publient des listes de pièces qualifiées et livrent souvent l’optique préinstallée
HBA hôtes16/32GFC SFP+/SFP28les HBA sont livrés avec leur optique ; les modules tiers fonctionnent généralement mais compliquent le support
Ports de commutateur SAN et ISLSW pour l’intra-salle, LW/ELW pour la distancela validation la plus stricte — voir plus bas
NIC de stockage IP (iSCSI, NVMe/TCP, RoCE)optique Ethernet 25/100G ou DACles règles Ethernet standard s’appliquent
Liaisons de réplicationLW/ELW, ou FC/Ethernet sur DWDMbudgets de distance et de latence

Validation constructeur partout

Les plateformes de stockage vérifient l’identité des modules à trois niveaux :

  1. Commutateurs SAN — beaucoup affichent un état de port module invalid pour une optique non qualifiée et gardent le port hors service (optique FC).
  2. Baies — les contrôleurs peuvent journaliser une alerte SFP non supporté ou refuser d’activer un port.
  3. HBA — généralement tolérants, mais le support du constructeur peut exiger une optique qualifiée avant d’investiguer une panne.

La politique pratique vers laquelle convergent les opérateurs : optique qualifiée sur les ports de baie et de commutateur, tiers là où c’est toléré, et un outil de codage pour faire présenter à un remplaçant l’identité qu’un port strict attend (voir verrouillage constructeur).

Sans perte veut dire « lent », pas « en panne »

FC et RoCE ne perdent pas de trames. Une optique dégradée produit donc des erreurs CRC, des blocages de crédits (slow-drain) et une latence croissante sur les LUN qui se trouvent derrière — un ticket de performance de stockage, pas une coupure réseau. Le chemin de diagnostic est le même que pour toute liaison (niveaux → nettoyer → remplacer → OTDR), mais il faut partir du symptôme applicatif et remonter jusqu’au port.

Distance et réplication

  • La réplication synchrone est bornée par la latence — en pratique jusqu’à environ 100 km — c’est pourquoi les sites de secours métro utilisent une optique LW/ELW ou du FC sur DWDM.
  • Les ISL longs ont besoin de crédits de tampon supplémentaires en plus du budget optique ; voir fabrics SAN et distance.

Surveillance

Suivez la tendance du DDM sur chaque ISL et chaque port de baie : la dérive de la puissance Rx et la hausse du bias Tx sont l’alerte précoce d’un laser qui tombera en panne un vendredi soir. Établissez une référence pour chaque optique à l’installation.

Dans CodingBox

Lisez chaque optique au banc avant qu’elle n’entre dans un réseau de stockage : confirmez les codes de débit FC ou Ethernet, le type d’onde et l’identité constructeur, enregistrez le DDM comme référence, et — pour les ports stricts — codez le module avec l’identité qualifiée dans l'EEPROM editor, l’original étant conservé dans la code database.

Ce que l’Ethernet sans perte exige de chaque liaison — PFC, ECN, FEC, CRC nul : Ethernet sans perte pour le stockage ; les transports qui s’appuient dessus : NVMe over Fabrics.


Si vous trouvez une inexactitude ou une erreur dans cet article, sélectionnez le passage concerné et appuyez sur Ctrl+Enter pour .