なぜiSCSI用の802.3adチームではなくMPIOなのか
最初のサーバーをiSCSIターゲットに接続し、サーバー上でNIC（従来の802.3adチーム）をチーム化することで、実行を開始できると思いました。
ただし、多くのオンラインソースから、これは推奨されておらず、代わりにMPIOを使用する必要があることがわかります（この推奨には特定のサイズ設定はなく、3ノードクラスターから数十ノード以上の大規模クラスターに適用されるようです）。
MPIOは、独立したルートを介して転送を集約するので優れていることを私は知っています（従来のNICチームは同じスイッチになります）が、これは別として、Microsoftと他の理由（データ破損のリスク）がありますチーム化の代わりにMPIOを使用するためのトレーニング資料の状態？
ISCSIアーキテクチャを少し拡張できますか？使用しているイニシエーター/ターゲットアドレスの数、物理スイッチの数、すべて1つのサブネットまたは複数ですか？
基本的な答えは次のとおりです。MPIOはエンドツーエンドの接続パスを管理し、一般的なネットワークの冗長性と負荷分散メカニズムよりも、ストレージ接続の負荷分散と接続の復元力に優れているためです。
これの具体的な技術的理由はアーキテクチャによって異なるため、iSCSIネットワークのセットアップについてさらに詳細を提供すると、さらに具体的になります。いくつかの一般的な例：
- MPIOがない場合、イニシエーターからターゲットへのIP会話は1つの会話にすぎません。 802.3adは、会話内のパケットの順序を変更しないことを義務付けているため（iSCSIトラフィックの順序を狂わせたくない）、単一リンクの帯域幅に制限されます。
- MPIOはパス障害を検出して処理しますが、802.3adはリンク障害を補正することしかできず、そのリンク障害が正しく検出された場合に限ります。 NICカードがハングしたが、それでも良好なリンクを報告する場合、またはスイッチ構成が特定のポートで失敗した場合、2番目のリンクがまだ機能しているにもかかわらず、ストレージ接続が失われる可能性があります。
- ホストのNICを別のスイッチにアップリンクするのではなく、単一の物理スイッチに縛られています。