UCSFCアダプターが異常終了
これがシナリオです。@ Chopper3がここでチャイムを鳴らすことができることを願っています。 SANファブリックの場合、3つのEMCフレームと4つのCiscoUCSドメインが直接接続されたCiscoMDS 9513FCスイッチのペアがあります。
私たちが見ている動作は、ファブリックインターコネクトがFCoEポーズフレームを送信した結果として、ブレード上のCNAがFCアボートを送信していることです。 Cisco TACは、この動作はアップストリームの輻輳または遅延の結果であると説明しています。環境内の200台ほどのESXiサーバーからのデータに対応するスパイクが見られ、100ミリ秒から2000ミリ秒の遅延スパイクが報告されています。一部のフレームとパスは他のフレームとパスよりも少し強くヒットしているように見えます。そのため、1つ以上のリンクをホットスポットしていると思います。
ブレードは、を使用するB200M2、B200M3、およびB420M3サーバーです。 M2シリーズは「Palo」アダプターM81KRを使用し、M3シリーズはVIC1240アダプターを使用します。
私はFCの知識があまりないので、これを追い詰める方法についていくつかの提案をいただければ幸いです。
だからここにこれに関する話があります：
私はそれを間違った視点から見ていました。アダプタは、どこかのコンポーネントが追いついていないことを示す通常の症状を中止します。この場合、アダプターのアボートは、SANフロントエンドポートがビジーで要求を処理できないことの症状でした。これは、いくつかの異なる条件によって悪化しました。
1）不良ドライバー-UCSファームウェアレベルは、アボートからの回復に既知の問題があるESXiの一致するドライバーを示し、再起動によってのみクリアできるループに送信します。
2）変数が多すぎます-3つのSANがあり、3つの異なる問題があり、すべてアダプターの異常終了によって表されます。
3）SANバグ-EMCVNXコードのバグが原因で問題が発生したため、VAAIを無効にする必要がありました。
2015年編集：
このスレッドを更新したかったのは、多くの新しい情報も明らかになり、検出が非常に難しいためです。この投稿が何人かの人々を正しい方向に導くことを願っています。
1）上記のすべては実際にはまだ関連しています。できるだけ早く、そのすべてを2乗してサポートマトリックス内に入れてください。
2）一部のUCS 2.1バージョンは、（NXOSがまだそれを行うように構成されているにもかかわらず）誤って優先フロー制御をオフにします。これにより、一部のFCoEトラフィックが他のトラフィックと同様に扱われるため、FCフレームの順序が狂うことがあります。
3）UCS 2.1コードの途中で、IOスロットル設定がコスメティックフィールドからアクティブフィールドになりました。古い「バーンイン」ファームウェア設定はIOスロットル数は256で、すべてのホストがほぼ使用していましたが、Windowsドライバーではこれを調整できました。このコードの途中で、「256」のインストールに使用された元のデフォルト値「16」ハードウェアへの接続が無効な設定になり、UCSMコードはこれを最大値である「2048」として解釈し始めました。その結果、単一のUCSVICアダプターがストレージアレイを完全に破壊するように構成されました。
だから、あなたのリリースノートを読んでください。学んだ教訓、私たちはついにこれを修正しました。