iSCSIの802.3adチームではなくMPIOを使用する理由

最初のサーバーでiSCSIターゲットを実行すると、サーバー（従来の802.3adチーム）でNICをチーム化することで、実行を開始できると思いました。

ただし、多くのオンラインソースから、これは推奨されておらず、代わりにMPIOを使用する必要があることがわかりました（この推奨事項には特定のサイズ設定がなく、3ノードクラスターから数十ノード以上の大規模クラスターに適用されるようです）。

MPIOは独立したルートを介して転送を集約するので（従来のNICチームが同じスイッチに向かうのに対し）MPIOの方が優れていることを知っていますが、これに加えて、Microsoftおよびトレーニングマテリアルの状態がチーミングではなくMPIOを使用する理由が他にもある（データ破損のリスク） ？

iSCSIアーキテクチャを少し拡張できますか？作業しているイニシエーター/ターゲットアドレスの数、物理スイッチの数、すべて1つのサブネットまたは複数ですか？

基本的な答えは次のとおりです。MPIOはエンドツーエンドの接続パスを管理し、ストレージ接続の負荷分散と接続の復元力が、一般的なネットワークの冗長性と負荷分散メカニズムよりも優れているためです。

これの具体的な技術的理由はアーキテクチャに依存するため、iSCSIネットワークのセットアップに追加の詳細を提供すると、より具体的になる可能性があります。いくつかの一般的な例：

• MPIOがなければ、イニシエーターからターゲットへのIP会話は1つの会話にすぎません。802.3adは、会話内のパケットの順序を変更しないように（そして、iSCSIトラフィックの順序を乱したくない）ことを義務付けているため、1つのリンクの帯域幅に制限されています。
• MPIOはパス障害を検出して処理しますが、802.3adはリンク障害のみを補償できます-リンク障害が正しく検出された場合のみ。NICカードがハングしていても良好なリンクが報告されている場合、または特定のポートのスイッチ構成がねじ込まれている場合は、2番目のリンクがまだ機能しているにもかかわらず、ストレージ接続が失われる可能性があります。
• ホストのNICを別のスイッチにアップリンクするのではなく、単一の物理スイッチに関連付けられています。