これがシナリオです。@Chopper3 がコメントしてくれることを期待しています。SAN ファブリックには、3 つの EMC フレームと 4 つの Cisco UCS ドメインが直接接続された 1 組の Cisco MDS 9513 FC スイッチがあります。
私たちが目にしている動作は、ファブリック インターコネクトが FCoE 一時停止フレームを送信した結果、ブレード上の CNA が FC アボートを送信しているというものです。Cisco TAC は、この動作はアップストリームの輻輳または遅延の結果であると説明しています。環境内の 200 台ほどの ESXi サーバーからのデータでは、100 ミリ秒から 2000 ミリ秒の遅延スパイクが報告されており、対応するスパイクが見られます。一部のフレームとパスは他のものよりも少し影響を受けているようで、1 つ以上のリンクがホットスポットになっていると考えられます。
ブレードは、B200M2、B200M3、および B420M3 サーバーで使用されています。M2 シリーズでは「Palo」アダプタ M81KR が使用され、M3 シリーズでは VIC1240 アダプタが使用されます。
私は FC についてあまり詳しくないので、これを探し出す方法についていくつか提案していただければ幸いです。
答え1
それで、これに関する話は次の通りです:
私は間違った視点からそれを見ていました。アダプタの中止は、どこかのコンポーネントが追いついていないことを示す通常の症状です。この場合、アダプタの中止は、SAN フロントエンド ポートがビジー状態すぎて要求を処理できないことの症状でした。これは、いくつかの異なる条件によって複雑化していました。
1) 不良ドライバー - UCS ファームウェア レベルは、中止からの回復に関する既知の問題を持つ ESXi 内の一致するドライバーを指定し、再起動によってのみクリアできるループに陥らせます。
2) 変数が多すぎる - 3 つの異なる問題を抱えた 3 つの SAN はすべて、アダプタの中止によって表されます。
3) SAN のバグ - EMC VNX コードのバグにより問題が発生したため、VAAI を無効にする必要がありました。
2015 編集:
多くの新しい情報が明らかになったため、このスレッドを更新したいと思いました。検出は確かに困難です。この投稿が、何人かの人々を正しい方向に導くことを願っています。
1) 上記のすべては実際にはまだ関連しているので、できるだけ早くすべてを整理してサポート マトリックスに組み込んでください。
2) UCS 2.1 の一部のバージョンでは、優先フロー制御が誤ってオフになり (NXOS では優先フロー制御を行うように設定されているにもかかわらず)、一部の FCoE トラフィックが他のトラフィックと同様に扱われるため、FC フレームの順序が乱れることがあります。
3) UCS 2.1 コードの途中で、IO スロットリング設定が表面的なフィールドからアクティブなフィールドになりました。古い「焼き付け」ファームウェア設定は、すべてのホストがほぼ使用していた 256 の IO スロットル数でしたが、Windows ドライバーではこれを調整できました。このコードの途中で、ハードウェアに「256」をインストールするために使用されていた元のデフォルト値「16」が無効な設定になり、UCSM コードはこれを最大値である「2048」として解釈し始めました。その結果、単一の UCS VIC アダプタが、ストレージ アレイを完全に破壊するように構成されました。
リリース ノートを読んでください。教訓を生かして、ようやくこの問題を修正しました。
IO スロットル バグ:https://tools.cisco.com/quickview/bug/CSCum10869