CodingBox Q&A Ask question

ProxmoxとFreeNAS間のBrocade 200e、全ポートonlineなのにBuffer I/O errorとisp0: Receive Error

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

小規模な仮想化環境を運用しています。Proxmox 6のノードが2台と、FreeNAS 11.2のターゲットです。HBAをターゲットに直結していた間は、何か月もエラー1つなく動いていました。配線をたすき掛けにしないよう、間に中古のBrocade 200eを入れたところ、そこから始まりました。

  • Proxmox 6のノード2台、HBAはQLogic QLE2462とQLE2432
  • FreeNAS 11.2のターゲット
  • Brocade 200eスイッチ、Fabric OS 6.1.0a
  • 古い在庫からのSFPとLCパッチコード、識別表記なし

ノード側のログには:

Buffer I/O error on dev dm-5

その後デバイスのリセットが続けざまに起きます。ターゲット側ではコマンド(CTIO7)のファームウェアタイムアウトが発生し、だいたい1分に1回のペースで:

isp0: Receive Error

この後ターゲットは両方のイニシエータから同時に落ち、直すにはノードの再起動しかありません。

すでにやったこと:

  • 直結に戻したところエラーは一切なし。つまりHBAもディスクもターゲット自体も無関係
  • switchshowでは3ポートすべてonlineで、ゾーニングは最小限、ゾーンは1つ
  • パッチコードを挿し直し、スイッチを再起動した

スイッチ自体のどこを見ればいいでしょうか。switchshowのonlineは明らかに自分を欺いていますが、それを何で検証すればいいのか、今のところ分かりません。

Comments 4

Accepted answer

もうあなた自身がすべて見つけています。増え続けるcrc_errとenc_outは回線上でのフレーム破損で、それがスタックを上に伝わってファームウェアのタイムアウト、デバイスのリセット、isp0: Receive Errorに姿を変えます。ノード側のカーネルもターゲットも悪くなく、飛んできたものを正直に報告しているだけです。

あなたがすでに取得したデータはこう読めます。

  • カウンタをリセットしてから負荷をかけて見ているので、スイッチ投入以来の累計ではなく増加速度を見ていたことになる。そしてその急増はノード側のBuffer I/O errorと一致していた。これこそがファブリックのエラーとディスクが見ているものを結びつける証拠
  • 長さが同じケーブルなのに同じ2ポートだけsfpshowの受信レベルが落ちているのは、頭の中の基準値とではなく、対称なリンク同士を比較したものになっている。問題のない3つ目のポートが基準として機能している

残っている作業はもうわずかです。fabriclog -sを実行してください。switchshowがその瞬間onlineと表示していても、ポートが暴れている様子がそこには見えます。そして疑わしいポートではSFPとLCパッチコードを個別にではなく一緒に交換してください。自分の似たケースもまさにそれで決着しました。問題のある2ポートでモジュールとケーブルを交換したら、丸1日負荷をかけてもporterrshowはゼロのままになり、ファブリックも二度と崩れなくなりました。

理屈は単純です。直結ならコネクタは2個、スイッチを経由すると4個、それに余分なモジュールが2個加わります。直結ならぎりぎり持ちこたえていた、パワーが境界線上のSFPや埃っぽいケーブルは、この経路ではもう持ちません。つまりswitchshowのonlineは診断結果ではなく、単にログインしたという事実にすぎません。

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

switchshowが言っているのはただ一つ、ポートが光を検出してファブリックにログインしたということだけです。信号品質については何も知らないので、この状況でそれを信じても意味がありません。

3ポートすべてでportstatsclearを実行し、負荷をかけてからporterrshowを見てください。気になるのはcrc_errとenc_outが増えるかどうか、どのポートで増えるかです。ついでに各ポートでsfpshowも、受信パワーと電圧をポート間で比較すると役に立ちます。それとFreeNAS側でターゲットが落ちる瞬間にsysctl dev.isp.0が何を返すかも見せてください。

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

カウンタをクリアして負荷をかけて見てみました。状況はこうです。2つのポートでcrc_errとenc_outがまとまって増え、それはちょうどノード側でBuffer I/O errorが出ているのと同じタイミングで、3つ目のポートはゼロのままです。

同じ長さのケーブルなのに、この2ポートのsfpshowは隣のポートよりかなり低い受信レベルを示しています。落ちている最中のsysctl dev.isp.0はHBAが再初期化されていることを示していて、つまりHBAは断絶に反応しているだけで、それを作り出しているわけではありません。どうやらこれはProxmoxでもターゲットでもなく、物理層の話のようです。

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

似たような落とし穴はFC以外でもあるので、カウンタはどのみち確認しておく価値があります。Intel X520-2に850nmの10Gtek SRモジュールを挿した構成と、モジュールFCX-2XGとBrocade純正XFPを挿したBrocade FastIron CX 648S-PoEの組み合わせで、間を5メートルのファイバーでつないでいたケースがありました。

サーバー側は正直に10GbEを上げて送信していたのに、受信はまったくなく、スイッチ側のポートは速度Noneのままupに張り付いていました。show mediaを見て、両側の波長と対応距離を照合し、ポートのトランクネゴシエーションを切ってみましたが、何も解決せず、XFPでは速度を固定できません。同じファイバーをSFP+ポートで使うと、ギガビットで問題なく動きました。教訓はあなたとまったく同じです。ポートがUpだからといって、フレームが届いているとは限りません。

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