CodingBox Q&A Ask question

Brocade 200e entre Proxmox et FreeNAS : Buffer I/O error et isp0: Receive Error alors que tous les ports sont online

Asked Active Viewed 153 AI translation from Русский
5

Je gère une petite virtualisation : deux nœuds Proxmox 6 et une cible sur FreeNAS 11.2. Tant que les HBA étaient reliés directement à la cible, tout tournait pendant des mois sans une seule erreur. J'ai mis un Brocade 200e d'occasion entre eux pour ne pas tirer les câbles en croix, et ça a commencé.

  • deux nœuds Proxmox 6, HBA QLogic QLE2462 et QLE2432
  • cible FreeNAS 11.2
  • switch Brocade 200e, Fabric OS 6.1.0a
  • SFP et jarretières LC de vieux stocks, sans marquage

Sur les nœuds, dans le log :

Buffer I/O error on dev dm-5

et ensuite des réinitialisations constantes du périphérique. Côté cible - des timeouts firmware sur les commandes (CTIO7), et environ une fois par minute :

isp0: Receive Error

Après ça, la cible se déconnecte immédiatement des deux initiateurs, et ça ne se répare qu'en redémarrant le nœud.

Ce qui a déjà été fait :

  • retour au branchement direct - aucune erreur du tout, donc les HBA, les disques et la cible elle-même n'y sont pour rien
  • switchshow montre les trois ports online, un zonage minimal, une seule zone
  • rebranché les jarretières, redémarré le switch

Où regarder sur le switch lui-même ? online dans switchshow me trompe visiblement, mais je ne vois pas encore comment le vérifier.

Comments 4

Accepted answer

Tu as déjà tout trouvé toi-même : les crc_err et enc_out qui augmentent, c'est de la corruption de trames sur la ligne, qui se transforme ensuite plus haut dans la pile en timeouts firmware, réinitialisations de périphérique et isp0: Receive Error. Ni le noyau sur les nœuds, ni la cible n'y sont pour quoi que ce soit, ils rapportent honnêtement ce qui leur arrive.

Ce que tu as déjà relevé se lit ainsi :

  • tu as remis les compteurs à zéro et regardé sous charge, donc tu as vu la vitesse de croissance, pas le cumul depuis la mise sous tension du switch. Et les pics coïncident avec les Buffer I/O error sur les nœuds - c'est ça, le lien entre les erreurs de la fabric et ce que voient les disques
  • la réception dégradée dans sfpshow sur ces deux mêmes ports, avec des cordons de longueur identique, c'est une comparaison entre liens symétriques, pas avec une norme sortie de nulle part. Le troisième port, propre, te sert de référence

Il ne reste plus grand-chose. Lance fabriclog -s - on y voit les ports qui se rétablissent, même quand switchshow affiche online à ce moment-là. Et remplace sur les ports suspects le SFP en même temps que la jarretière LC, pas séparément. Chez moi, une histoire similaire s'est terminée exactement comme ça : remplacement des modules et des cordons sur les deux ports posant problème, après quoi porterrshow est resté à zéro pendant vingt-quatre heures sous charge, et la fabric ne s'est plus effondrée.

La logique est simple : en direct, il y a deux connecteurs sur le trajet, via le switch, il y en a quatre, plus deux modules supplémentaires. Un SFP à la limite de puissance ou un cordon poussiéreux, que la liaison directe tolérait encore, ne passe plus sur un tel trajet. Donc online dans switchshow n'est pas un diagnostic, c'est juste le constat d'une connexion établie.

4 Russialambdaops44RU Show original (Русский) AI translation

switchshow dit exactement une chose : le port a vu de la lumière et s'est connecté à la fabric. Il ne sait rien de la qualité du signal, donc lui faire confiance dans cette situation ne sert à rien.

Fais un portstatsclear sur les trois ports, mets de la charge et regarde ensuite porterrshow - ce qui intéresse, ce sont les crc_err et enc_out, s'ils augmentent et sur quels ports exactement. Fais aussi un sfpshow par port : puissance en réception et tension, ça vaut la peine de les comparer entre ports. Et montre ce que renvoie sysctl dev.isp.0 côté FreeNAS au moment où la cible se déconnecte.

0 KazakhstanlinkguruKZ Show original (Русский) AI translation

J'ai nettoyé les compteurs, mis de la charge, regardé. Le tableau est le suivant : sur deux ports, crc_err et enc_out augmentent par paquets, exactement au moment où les Buffer I/O error tombent sur les nœuds, et sur le troisième port, c'est à zéro.

sfpshow sur ces deux mêmes ports montre une réception nettement plus basse que sur le voisin, avec des cordons de longueur identique. sysctl dev.isp.0 au moment de la déconnexion montre que le HBA se réinitialise, donc il réagit à une coupure plutôt qu'il n'en crée une. On dirait bien que c'est physique, pas Proxmox ni la cible.

3 KazakhstannetopsKZ Show original (Русский) AI translation

Ce piège existe aussi hors FC, donc ça vaut le coup de regarder les compteurs dans tous les cas. Il y a eu une combinaison Intel X520-2 avec des modules 10Gtek SR à 850 nm et un Brocade FastIron CX 648S-PoE avec un module FCX-2XG et des XFP Brocade, cinq mètres de fibre entre les deux.

Le serveur montait bien le 10GbE et transmettait, mais il n'y avait aucune réception, et le port sur le switch restait Up avec une vitesse à None. On a regardé show media, comparé la longueur d'onde et la portée des deux côtés, désactivé la négociation de trunk sur le port - rien n'y a fait, la vitesse ne se fixe pas sur un XFP. La même fibre sur des ports SFP+ tournait tranquillement en gigabit. La morale est exactement la même que chez toi : Up sur le port ne veut pas dire que les trames arrivent.

3 Ukrainecoaxeng7UA Show original (Русский) AI translation
Log in to comment. Log in