OCe14000 LoM、ケーブルを抜いてもlink upと報告しESXiのチーミングがフェイルオーバーしない
小規模なvSphereクラスタで、各ホストから1組のトップオブラックスイッチへ10Gアップリンクを2本ずつ引いています。ToRをファームウェア更新のために再起動した後、1台のホスト上の一部のVMが応答しなくなり、vMotionも両方のアップリンクで失敗しました。それなのにESXiは何もdownとしてマークせず、アダプタのLEDもずっと点灯したままでした。
- Fujitsu Primergy RX2540 M1
- Emulex OneConnect OCe14000オンボードLANアダプタ(VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- ToRへはSFP+オプティクス、vSwitchは単純なアクティブ/スタンバイのチーミング
これがスイッチ側の問題ではないと確信した理由は、アダプタからファイバーを完全に抜いても、生きているように見え続けたことです。
esxcli network nic get -n vmnic2 (cable physically removed)
Link Status: Up
Firmware Version: 11.2.1194.36
esxcli software vib list | grep elxnet
elxnet 10.2.309.6vすでに試したこと:
- オプティクスとファイバーを挿し直し、パッチコードも交換した
- アップリンクをもう一方のToRスイッチに移したところ、そちらのポートは期待通りdownになる
- ホストの管理エージェントを再起動した
ホストがアップリンクは生きていると信じているせいで、チーミングポリシーには何かを動かす理由がなく、VMは死んだポートに固定されたままになります。これはOneConnectでよく知られたドライバとファームウェアの不一致問題なのでしょうか、それともLoMのハードウェアを疑うべきでしょうか。
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 6
その組み合わせがまさに原因で、ESXi 6.0向けのサポート対象ペアとしては掲載されていません。アダプタは半分生きている状態になります。トラフィックは流さなくなるのに、ポートは接続中だと言い続けるので、チーミングポリシーは動くために必要なdownイベントを一切受け取れません。だからこれは正直なNIC故障ではなく、両アップリンクでvMotionが死んだ部分的な隔離という形であなたのところに届いたわけです。きちんと死ぬカードのほうが、嘘をつくカードよりずっと生き延びやすいものです。
ドライバを11.2.1149.0まで上げてください。これはVMwareの互換性リストでファームウェア11.2.1194.36に対して認定されているelxnetのレベルなので、カードを巻き戻すのではなく、ドライバをファームウェアに合わせて進める形になります。作業後は、すでに手元にある2つのコマンドで確認してください。
vibの行には新しいバージョンが表示されるはずで、ホストが復旧すればLink Statusも再びケーブルの状態に追従するはずです。クラスタを信頼して任せる前に、そのアップリンクでVMを動かした状態でファイバーを抜いてテストしてください。
ここから持ち帰るべき習慣は、OneConnectではドライバとファームウェアがペアで動くということです。メンテナンスバンドルが片方だけを勝手に進めてしまわないよう、両方をまとめてスケジュールしてください。この2行を比較するのはコマンド1つで済み、オプティクスを抜いたりスイッチを疑ったりするよりずっと前にやるべきことです。
あなたが貼った2行こそが興味深い部分です。elxnet 10.2.309.6vの下でファームウェア11.2.1194.36が動いています。そのファームウェアはどこかの時点で、ドライバとは別にサーバーのメンテナンスバンドルと一緒に入ったものですか。
その組み合わせは「最新なら問題ないはず」ではなく、ESXi 6.0の互換性リストと照合してください。OneConnectはドライバとファームウェアがペアで認定されるファミリーの1つで、不一致のペアは必ずしも派手に失敗するわけではありません。半分だけ動く、というほうがずっとたちが悪いです。
アダプタの2つ目のポートも、ケーブルを抜いたときに同じ挙動をするかどうかも教えてください。
はい、そのファームウェアはサーバーのメンテナンスバンドルで入りました。ドライバはホストを構築して以来一度も触っていません。
両方のLoMポートがまったく同じ挙動をします。ケーブルを抜いてもesxcli network nic getはLink Status: Upと報告し続け、LEDは点いたままで、vSwitchはアップリンクをアクティブリストに残したままです。スイッチ側は問題なく、抜いた瞬間にそちらのポートは落ちます。
つまりこのホストで噛み合っていないのは、ファームウェア11.2.1194.36に対するelxnetのバージョンだけということです。
別のファミリーですが教訓は同じです。長らく何も触らず動いていたEmulex LPe31000/LPe32000のFCポートのペアが、Proxmoxのカーネルが5.15.64、続けて5.15.74に上がった後、LUNをまったく見なくなりました。配線もオプティクスも一切触っていません。ログにはこうありました。
これはオプティクスの故障ではなく、ホスト側のlpfcのリグレッションです。5.15.60より後のカーネルで発生するようになりました。ブートカーネルを巻き戻すのが、本番環境で通用した回避策でした。
5.15系統を離れても構わない人向けには、オプトインの5.19カーネルも効果がありました。修正は5.15.77で入るはずでしたが、自分はそのビルドを実際に試す機会がなかったので、伝聞として扱ってください。要点は変わりません。今まで動いていたリンクがホスト側の何かの変更の直後に死んだら、トランシーバに近づく前にホストの変更履歴を読んでください。
同じ反射神経を鍛える話として、この鏡写しのケースも付け加えておきます。インジケータはソフトウェアであり、ソフトウェアはどちらの方向にも間違えます。
EX3400とEX2300には、SFP+とSFPポートのLEDが、リンクが実際にはupでトラフィックも流れているのに消えたままになるJunosの不具合PR1428703があります。15.1X53から18.1系や19.x系に移行した人たちが、主にDACで踏んでいます。CLIとパネルの言うことが食い違います。
は物理LEDが消えている間もGreenと報告します。修正済みと報告されたビルドもあれば、別のビルドでは相変わらずLEDが暗いという報告も続いていて、きれいに解決済みとは言い切れません。
あなたのケースはリンクなしで点灯、こちらのケースはリンクありで消灯です。どちらにしても、信じるべきは対向側とカウンタであって、インジケータではありません。
両方のホストでドライバは11.2.1149.0になりました。ケーブルを抜くとLEDが消え、esxcliはリンクダウンを報告し、スタンバイのアップリンクが本来あるべき形で引き継ぎます。テストとして各アップリンクを個別に使ってvMotionも問題なく動きました。
ドライバとファームウェアのペアはサーバーメンテナンスのチェックリストに追加しました。次のバンドルが黙って両者を引き離すことのないようにです。