1つのサイトに、2つの10G NICを備えたvSphereホストがあります。
スイッチはCisco C3850シリーズで、MPIOはチャームのように機能します-テスト済み(パスレベルでのフェイルオーバーなど)。
数日前に別のサイトに同様の構成を展開しました。同じvSphere構成、同じNIC。ただし、今回はこの構成は正しく機能しません。
イニシエーターは、同じスイッチ(そのイニシエーターが接続されている)のポートのターゲットにのみアクセスでき、他のスイッチのポートではアクセスできません。
Tcpdumpを使用すると、vmkernelポートがすべてのターゲット(ドキュメントに従ってvSphereによって行われます)を検出し、静的検出ターゲットが表示されます(SANはそれがポークされていることを確認します)が、パスは作成されず、esxcliは0x0004エラー(トランスポートエラー?)別のスイッチのターゲット用。これは調査が非常に難しく、HBAトラフィックを直接確認することもできません。ただし、ソフトウェアiSCSIはチャームのように機能します(同じvmkernelポートにバインドされます)。
今回はスイッチがCisco Nexusであり(知っている場合はモデルを更新します)、スタッキングはC3850ネイティブ(?)ではなくVCP(?)です。それ以外の場合、サイトはほとんど同じですが、IMHOの違いはわずかであるため、違いはありません。いくつか指摘するだけです:
VMwareのドキュメントを検索しましたが、統合ネットワークが機能しないという記述は見つかりませんでした。私たちはネットワーキングパートナーに相談しましたが、彼らはそれが現在どのように機能しているかを理解しておらず、まったく機能しないはずだと考えました。
この構成は正常ですか、それとも他のスイッチでは機能しないC3850の実装の癖に依存していますか?または、スイッチに明らかに何か問題がありますか?
私自身の質問に答えるために…LAGはポートボンディングで推奨/サポートされていません(「すべきではない」、「禁忌」-弱い表現):
LACPサポートは、ソフトウェアiSCSIマルチパスと互換性がありません。 iSCSIマルチパスは、通常の静的EtherChannelまたはLACPボンドでは使用しないでください。
LACPまたは他のリンク集約がpSwitchへのESXiホストアップリンクで使用される場合、ソフトウェアiSCSIポートバインディングも禁忌です
どうやら、Catalyst 3850 Stackwiseは、Nexus Virtual Port Channelとは非常に異なって動作します(動作します…)。トラフィックは通常の状態ではスイッチ間チャネルを通過しないため、ハードウェアiSCSIはパッケージを他のスイッチのSAN=ポートから戻すことはありません。解決策は、vSwitchでポートIDベースのバランシングに切り替え、LAGを無効にすることです。トラフィック10Gの場合、バランスはそれほど重要ではありません(1Gリンクが過負荷になりやすいIPハッシュが役立ちます)。
VCPがLACPが適切に機能することを要求するというGoogleからの出所のない弱い主張がいくつかあります。 Switch-> vSphere接続でパケット損失が発生しましたが、LAGを無効にしてポートIDバランシングに切り替えたときに消えていました。 vSwitchが誤ったアップリンクからのトラフィックをドロップすることを知っていました(VMはvmnic0にハッシュされますが、トラフィックはvmnic1から戻ってくる場合)がIPに適用されるかどうかはわかりませんハッシュバランシング。一方で、スイッチ側ではIP-SRC-DSTのみがサポートされているとドキュメントに記載されています。VPCが正しいIPハッシュベースのインターフェースではなく、スイッチローカルインターフェースを介してvSphereにトラフィックを送信した場合、「不正な」アップリンクと見なされる可能性があります繰り返しますが、LAGを無効にすることで問題は解決しました。