Users Guide
Table Of Contents
- 目次
- はじめに
- 1 機能と特徴
- 2 Windows Server でのチー ム化の設定
- 3 Windows での仮想 LAN
- 4 ハードウェアの取り付け
- 5 管理機能
- 6 Boot Agent ドライバソフト ウェア
- 7 Linux ドライバソフトウェア
- はじめに
- 制限
- パッケージング
- Linux ドライバソフトウェアのインストール
- 必要な iSCSI ソフトウェア コンポーネントをロード して実行する
- Linux ドライバのアンロードまたは削除
- PCI ファイルをパッチする(オプション)
- ネットワークインストール
- オプションプロパティのための値の設定
- ドライバのデフォルト
- ドライバメッセージ
- bnx2x ドライバメッセージ
- bnx2i ドライバメッセージ
- BNX2I ドライバのサインオン
- iSCSI トランスポート名前結合へのネットワークポート
- ドライバは、iSCSI オフロードを有効にした C-NIC デバイスとのハンドシェイクを完了します
- ドライバは、iSCSI オフロードが C-NIC デバイスで有効にされていないことを検出します
- 許可されている最大 iSCSI 接続オフロード制限を超えています
- ターゲットノードとトランスポート名前結合へのネットワークルートは、2 つの異なるデバイ スです
- どの C-NIC デバイスでもターゲットに到達できません
- ネットワークルートはダウンしているネットワークインタフェースに割り当てられています
- SCSI-ML が開始したホストのリセット(セッションリカバリ)
- C-NIC が iSCSI プロトコル違反を検出しました - 致命的エラー
- C-NIC が iSCSI プロトコル違反を検出しました — 致命的ではなく、警告です
- ドライバは、セッションをリカバリさせます
- ターゲットから受信した iSCSI PDU を拒否します
- Open-iSCSI デーモンがドライバにセッションを渡します
- bnx2fc ドライバメッセージ
- BNX2FC ドライバのサインオン
- ドライバは、FCoE オフロードを有効にした C-NIC デバイスとのハンドシェイクを完了します
- ドライバは、FCoE オフロードを有効にした C-NIC デバイスとのハンドシェイクに失敗します
- FCoE を起動するのに有効なライセンスがありません
- 許可された最大の FCoE オフロード接続制限またはメモリ制限を超過したため、セッションが 失敗しました
- セッションのオフロードが失敗しました
- セッションのアップロードが失敗しました
- ABTS を発行できません
- ABTS を使用して IO を復元できません(ABTS タイムアウトのため)
- セッションの準備ができていないため、I/O 要求を発行できません
- 正しくない L2 受信フレームを廃棄しました
- ホストバスアダプターと Iport 割り当てに失敗しました
- NPIV ポートの作成
- チャネル結合によるチーム化
- 統計
- Linux iSCSI オフロード
- 8 VMware ドライバソフトウェア
- 9 Windows ドライバソフト ウェア
- 10 Citrix XenServer ドライバ ソフトウェア
- 11 iSCSI プロトコル
- 12 Marvell チーム化サービス
- 13 NIC パーティション化と帯域 幅管理
- 14 ファイバーチャネルオーバー イーサネット
- 概要
- SAN からの FCoE ブート
- インストール後に SAN からブートする
- FCoE を設定する
- N_Port ID Virtualization(NPIV)
- 15 データセンターブリッジング
- 16 SR-IOV
- 17 仕様
- 18 規制情報
- 19 トラブルシューティング
- A 変更履歴
12–Marvell チーム化サービス
チーム化の仕組み
文書番号 BC0054508-04 リビジョン R
2021
年 1 月 21 日 165 ページ
Copyright © 2021 Marvell
インバウンド IP データグラムが到着する と、 IP データグラムのソース IP アドレスを
ハッシュすることによって適切なインバウン ド
フロー ヘッド エン ト リ が検索さ れます。
選択し たエン ト リ に格納 されている
2 つの統計カウンタ も更新されます。 これらのカウ
ンタは、 ロード
バランシング エンジンによってアウトバウンド カウンタと同じ方法で
定期的に使用 され、 フ ローが物理アダプ タ に再割り 当て されます。
インバウンド コード パスでは、 インバウン ド フロー ヘッ ド ハッシュ テーブルが同期
アクセスを許可するようにも設計されています。インバウンド
フロー エン ト リのリンク
リストは、 ARP パケ ッ ト の処理時 と定期的なロー ド バラ ン シ ング時にのみ参照されま
す。 インバウン ド
フロー エ ン ト リ へのパケ ッ ト 単位の参照はあ り ません。 リ ン ク リ ス ト
が紐付け られていない場合で も、
ARP 以外の各パケ ッ ト を処理するオーバーヘ ッ ド は常
に一定です。 ただ し、 イ ンバウン ド と アウ ト バウン ド両方の
ARP パケ ッ ト の処理は、
対応するリンクリスト内のリンク数に依存します。
インバウンド 処理パス では、 ブ ロー ド キャ ス ト パケ ッ ト が他の物理アダプ タから システ
ムを通じてループバッ クすることを防ぐために、 フ ィルタも採用されています。
プロトコルサポート
ARP
および IP/TCP/UDP フローは、 ロード バランシングに対応します。 パケッ トが、
ICMP や IGMP などの IP プ ロ ト コルのみの場合、 特定の IP アドレスへのすべてのデー
タ フ ローが同 じ物理アダプ タ ーを通 じ て送信さ れます。 パケ ッ ト がレ イヤ
4 プロト コル
に
TCP または UDP を使用し ている場合は、 ポー ト 番号がハ ッ シ ュ アルゴ リ ズムに追
加されるため、
2 つの異なる レ イヤ 4 フローが 2 つの異なる物理アダプ ターを通じて同
じ
IP アドレスに送信されます。
たとえば、 クライアントの IP アドレスが 10.0.0.1 であると します。 ハッ シュには IP
ア ド レ スのみ使用さ れるため、 すべての IGMP および ICMP ト ラ フ ィ ッ ク が同じ 物理
アダプ タ に送信されます。 フ ローは次のよ う にな り ます。
IGMP ------> PhysAdapter1 ------> 10.0.0.1
ICMP ------> PhysAdapter1 ------> 10.0.0.1
サーバーが、 同じ
10.0.0.1 アドレスに TCP および UDP フ ローも送信する場合、 こ れ
らは
IGMP および ICMP と同じ物理アダプタ上にあっても、 ICMP および IGMP とは
まったく異なる物理アダプタ上にあってもかまいません。 スト リームは次のようになり
ます。
IGMP ------> PhysAdapter1 ------> 10.0.0.1
ICMP ------> PhysAdapter1 ------> 10.0.0.1
TCP ------> PhysAdapter1 ------> 10.0.0.1
UDP ------> PhysAdatper1 ------> 10.0.0.1
または、 スト リームは次のようになります。
IGMP ------> PhysAdapter1 ------> 10.0.0.1
ICMP ------> PhysAdapter1 ------> 10.0.0.1
TCP ------> PhysAdapter2 ------> 10.0.0.1