Owners Manual

Broadcom チーム化サービス：Broadcom NetXtreme IIｨ ネットワーク アダプタ ユーザー ガイド
file:///C¦/Users/Nalina_N_S/Documents/NetXtremeII/Japanese/teamsvcs.htm[9/5/2014 3:58:29 PM]
通有中継 (FEC/GEC)/802.3ad-Draft Static
Smart Load Balancing (スマート ロード バランス) およびフェイルオーバー
Smart Load Balancing™ およびフェイルオーバー チーム タイプは、ロード バランシング用に設定されている場合はロード バランシングと
フェイルオーバーの両方を提供し、フォルト トレランス用に設定されている場合にはフェイルオーバーのみを提供します。このチーム タイプ
は、どのイーサネット スイッチでも動作し、スイッチのトランキング設定は不要です。チームは、複数の MAC アドレスおよび 1 つまたは複
数の IP アドレスを通知します (セカンダリ IP アドレスを使用している場合)。チーム MAC アドレスは、[Load Balanceメンバー] のリスト
から選択されます。システムで ARP 要求が受信されると、ソフトウェア ネットワーキング スタックは常に ARP 応答とチーム MAC アドレス
を送信します。ロード バランシング プロセスを開始するには、チーム化ドライバでソース MAC アドレスをいずれかの物理アダプタと一致す
るように変更して、この ARP 応答を修正します。
Smart Load Balancing は、レイヤ 3/レイヤ 4 IP アドレスと TCP/UDP ポート番号に基づいて、伝送と受信の両方のロード バランシングを
有効にします。すなわち、ロード バランシングはバイトまたはフレーム レベルではなく、TCP/UDP セッション ベースで実行されます。この
方法は、同じソケットの通信に属するフレームを順序正しく配信し続けるために必要です。ロード バランシングは 2 ～ 8 個のポートでサポー
トされます。これらのポートには、アドイン アダプタや LAN on Motherboard (LOM) デバイスの組み合わせが含まれます。伝送のロード バ
ランシングは、発信元および宛先の IP アドレスと TCP/UDP ポート番号を使用してハッシュ テーブルを作成することにより実現されます。発
信元および宛先の IP アドレスと TCP/UDP ポート番号の組み合わせが同じ場合には、通常同じハッシュ インデックスが作成されるため、チー
ム内の同じポートを指し示すことになります。指定されたソケットのすべてのフレームを搬送するようにポートが選択されている場合、チーム
MAC アドレスではなく、物理アダプタの一意の MAC アドレスがフレームに含められます。これは、IEEE 802.3 規格に準拠するために必要で
す。2 つのアダプタで同じ MAC アドレスを使用して伝送した場合、スイッチで処理できない MAC アドレスの重複状態が発生します。
注： ARP は IPv6 の機能ではないため、IPv6 アドレスを指定されたトラフィックは、SLB によってロード バランシングが行われます。
受信のロード バランシングは、各クライアントのユニキャスト アドレスを ARP 要求の宛先アドレスとして使用して (Directed ARP とも呼ば
れる)、クライアント別に無償 ARP を送信することにより、中間ドライバで実現されます。これはクライアント ロード バランシングと見なさ
れ、トラフィック ロード バランシングとは見なされません。中間ドライバは、SLB チーム内の物理アダプタ間で深刻なロード インバランスを
検出すると、受信フレームを再分配するために G-ARP を生成します。中間ドライバ (BASP) は ARP 要求に応答しません。ソフトウェア プロ
トコル スタックが必要な ARP 応答を提供するだけです。受信のロード バランシングが、チーム インターフェイスでシステムに接続している
クライアントの数と相関関係にあることを、理解することが重要です。
SLB の受信のロード バランシングは、チーム内の物理ポート全体でクライアント マシンの受信トラフィックのロード バランスを行おうとしま
す。修正された G-ARP を使用して、送信者の物理アドレスとプロトコル アドレスに含まれるチーム IP アドレスの別の MAC アドレスを通知
します。この G-ARP は、対象の物理アドレスとプロトコル アドレスのそれぞれに、クライアント マシンの MAC アドレスと IP アドレスを使
用するユニキャストです。これにより、対象クライアントはその ARP キャッシュを、チーム IP アドレスへの新しい MAC アドレス マップで
更新します。G-ARP はブロードキャストではありません。なぜなら、すべてのクライアントが同じポートにそのトラフィックを送信すること
になるからです。結果として、クライアント ロード バランシングで得られる利点はなくなり、フレーム配信の順序が狂う可能性があります。
この受信のロード バランシングのスキームは、すべてのクライアントとチーム化されたシステムが同じサブネットまたはブロードキャスト ド
メインにある限り作用します。
クライアントとシステムが別のサブネットにあり、受信トラフィックがルーターを越えなければならない場合、システムに向かう受信トラ
フィックはロード バランスされません。中間ドライバで IP フローを搬送するよう選択された物理アダプタは、すべてのトラフィックを搬送し
ます。ルーターはチーム IP アドレスにフレームを送信するときに、ARP 要求をブロードキャストします (ARP キャッシュにない場合)。サー
バー ソフトウェア スタックはチーム MAC アドレスを使用して ARP 応答を生成しますが、中間ドライバがその ARP 応答を修正して特定の物
理アダプタに送信し、そのセッションのフローを確立します。
これは、ARP がルータブル プロトコルではないためです。ARP には IP ヘッダがありません。そのため、ルーターまたはデフォルト ゲート
ウェイには送信されません。ARP はローカル サブネット プロトコルに過ぎません。さらに、G-ARP はブロードキャスト パケットではないた
め、ルーターはそれを処理せず、それ自身の ARP キャッシュも更新しません。
ルーターが別のネットワーク デバイス向けの ARP を処理するするのは、代理 ARP が有効になっていて、ホストにデフォルト ゲートウェイが
ない場合のみです。このような状態は非常にまれであり、大部分のアプリケーションにはお勧めできません。
ルーターを経由する伝送トラフィックはロード バランスされます。これは、伝送のロード バランシングが発信元および宛先の IP アドレスと
TCP/UDP ポート番号に基づいているためです。ルーターでは発信元と宛先の IP アドレスが変更されないため、ロード バランシングのアルゴ
リズムは意図したとおりに動作します。
HSRP (Hot Standby Routing Protocol) のルーターの設定では、アダプタ チーム内の受信のロード バランシングは発生しません。一般的に
HSRP では、2 つのルーターが 1 つのルータとして動作して、仮想 IP アドレスと仮想 MAC アドレスを通知します。1 つの物理ルーターがア
クティブ インターフェイスになっているときには、もう片方がスタンバイになります。HSRP では (ホスト ノードにそれぞれ異なるデフォル
ト ゲートウェイを使用して) HSRP グループの複数のルーターに共有ノードをロードすることもできますが、常にチームのプライマリ MAC ア
ドレスを示します。