手册

目次のページに戻る

Broadcom Gigabit Ethernet のチーム化サービス： Broadcom NetXtreme II ネットワーク アダプタ ユーザーガイド

要旨

チーム化の仕組み

チーム化とその他の高度なネットワーク プロパティ

全般的なネットワークに関する考慮事項

アプリケーションに関する考慮事項

チーム化に関する問題のトラブルシューティング

よくある質問

付録 A： イベント ログのメッセージ

要旨

用語集

チーム化の概念

ソフトウェア コンポーネント

ハードウェア要件

チーム化のサポート (プロセッサ別)

チームの設定

サポートされる機能 (チーム タイプ別)

チーム タイプの選択

このセクションでは、ネットワーク チーム化サービスを使用する際の技術および実装の考慮事項について説明します。このサービスは、Dell 製サーバーおよびストレージ製品に同梱されている Broadcom ソフトウェアによって提供されます。Broadcom のチーム化サービスの目的は、複数のアダプタからなるチーム全体にフォルト トレランスとリンク集約を提供することです。本書の内容は、IT プロフェッショナルが、ネットワーク フォルト トレランスとロード バランシングを必要とするシステム アプリケーションを導入しトラブルシューティングする際に役立ちます。

用語集

チーム化の概念

ネットワーク アドレス指定

チーム化とネットワーク アドレス

チーム タイプの説明

TOE のチーム化

複数の物理デバイスをグループ化してフォルト トレランスとロード バランシングを提供するという概念は、新しいものではありません。数年前から存在している概念です。記憶デバイスでは、RAID テクノロジーを使用して個々のハード ドライブをグループ化します。スイッチ ポートは、Cisco Gigabit EtherChannel、IEEE 802.3ad リンク集約、Bay Network Multilink Trunking、および Extreme Network Load Sharing などのテクノロジーを使用してグループ化できます。Dell サーバーのネットワーク インターフェイスは、仮想アダプタと呼ばれる物理ポートのチームにグループ化できます。

ネットワーク アドレス指定

チーム化の動作方法を理解するには、イーサネット ネットワークにおけるノード通信の動作方法を理解することが重要です。本書では、読者に IP およびイーサネット ネットワーク通信の基礎知識があることを前提としています。以下では、イーサネット ネットワークで使用されるネットワーク アドレス指定の概念について、高度な概要を説明します。コンピュータ システムのようなホスト プラットフォームのイーサネット ネットワーク インターフェイスは、どれもグローバルに一意なレイヤ 2 アドレスを 1 つと、グローバルに一意なレイヤ 3 アドレスを少なくとも 1 つ必要とします。OSI モデルで定義されているように、レイヤ 2 はデータ リンク レイヤで、レイヤ 3 はネットワーク レイヤです。レイヤ 2 アドレスはハードウェアに割り当てられ、多くの場合 MAC アドレスまたは物理アドレスと呼ばれます。このアドレスは工場出荷時にあらかじめプログラムされ、ネットワーク インターフェイス カードの NVRAM、または内蔵 LAN インターフェイス用のシステム マザーボードの NVRAM に格納されます。レイヤ 3 アドレスはプロトコル アドレスまたは論理アドレスと呼ばれ、ソフトウェア スタックに割り当てられます。レイヤ 3 プロトコルの例としては、IP や IPX が挙げられます。また、レイヤ 4 (トランスポート レイヤ) では Telnet や FTP などのネットワーク上位プロトコルごとにポート番号を使用します。これらのポート番号は、アプリケーション全体のトラフィック フローを識別するのに使用されます。TCP または UDP などのレイヤ 4 プロトコルは、今日のネットワークで最も一般的に使用されています。IP アドレスと TCP ポート番号の組み合わせは、ソケットと呼ばれます。

イーサネット デバイスは、IP アドレスではなく MAC アドレスを使用して他のイーサネット デバイスと通信します。ただし、大部分のアプリケーションは、WINS や DNS などのネーミング サービスによって IP アドレスに変換されるホスト名で動作します。そのため、IP アドレスに割り当てられている MAC アドレスの識別方法が必要です。IP ネットワークの ARP (Address Resolution Protocol) はこのメカニズムを提供します。IPX の場合、MAC アドレスはネットワーク アドレスの 1 部なので ARP は不要です。ARP は ARP 要求および ARP 応答フレームを使用して実装されます。ARP 要求は一般的にブロードキャスト アドレスに送信され、ARP 応答は一般的にユニキャスト トラフィックとして送信されます。ユニキャスト アドレスは単一の MAC アドレスまたは単一の IP アドレスに対応します。ブロードキャスト アドレスは、ネットワーク上のすべてのデバイスに送信されます。

チーム化とネットワーク アドレス

アダプタのチームは単一の仮想ネットワーク インターフェイスとして機能し、チーム化されていないアダプタのネットワーク デバイスと同じように見えます。仮想ネットワーク アダプタは、単一のレイヤ 2 アドレスと 1 つまたは複数のレイヤ 3 アドレスを通知します。チーム化ドライバは、初期化の際に、チームを構成する物理アダプタのいずれかから、チーム MAC アドレスとなるMAC アドレスを 1 つ選択します。一般的にこのアドレスは、ドライバが最初に初期化するアダプタから取得されます。チームを管理しているシステムは、ARP 要求を受信すると、チーム内の物理アダプタの中から MAC アドレスを 1 つ選択して、ARP 応答のソース MAC アドレスとして使用します。Windows オペレーティング システムでは、IPCONFIG /all コマンドは個々の物理アダプタではなく仮想アダプタの IP アドレスと MAC アドレスを表示します。プロトコル IP アドレスは、個々の物理アダプタではなく仮想ネットワーク インターフェイスに割り当てられます。

スイッチ独立型のチーム化モードの場合、データ伝送時には、仮想アダプタを構成するすべての物理アダプタが、物理アダプタに割り当てられている一意の MAC アドレスを使用します。すなわち、チーム内の各物理アダプタで送信されるフレームは、一意の MAC アドレスを使用して IEEE に準拠する必要があります。ARP キャッシュ エントリが、受信フレームからではなく、ARP 要求および ARP 応答からのみ情報を得ることに注意することが重要です。

チーム タイプの説明

Smart Load Balancing (スマート ロード バランス) およびフェイルオーバー

通有中継

リンク集約 (IEEE 802.3ad LACP)

スマート ロード バランス (SLB) (自動フォールバックはディスエーブル)

サポートされているチーム タイプの分類方法は 3 つあります。

表 2 はチーム タイプとそれらの分類の要約を示しています。

表 2:利用可能なチーム タイプ

チーム タイプ	スイッチ依存型 (スイッチが特定のチーム タイプをサポートしている必要がある)	スイッチに Link Aggregation Control Protocol のサポートが必要	ロード バランシング	フェイルオーバー
Smart Load Balancing (スマート ロード バランス) およびフェイルオーバー (ロード バランスのチーム メンバーは 2 ～ 8)
スマート ロード バランス (SLB) (自動フォールバックはディスエーブル)
リンク集約 (802.3ad)
通有中継 (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 要求の宛先アドレスとして使用して (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 アドレスを示します。

通有中継

通有中継は、リンクの両端 (サーバー インターフェイスとスイッチ ポート) でポートの設定を必要とするスイッチ支援のチーム タイプです。これはよく Cisco Fast EtherChannel または Gigabit EtherChannel と呼ばれます。さらに通有中継は、Extreme Networks Load Sharing および Bay Networks のような他のスイッチ OEM や、IEEE 802.3ad リンク集約の静的モードによる同様の実装をサポートします。このモードでは、プロトコル スタックが ARP 要求に応答するときに、チームは 1 つの MAC アドレスと 1 つの IP アドレスを通知します。また、チーム内の各物理アダプタは、フレーム伝送時に同じチーム MAC アドレスを使用します。これが可能になるのは、リンクの反対側の端にあるスイッチがチーム モードを認識して、チーム内のすべてのポートによる単一 MAC アドレスの使用を処理するからです。スイッチの転送先テーブルは、中継を単一の仮想ポートとして示します。

このチーム化モードでは、中間ドライバは発信トラフィックのロード バランシングとフェイルオーバーのみを制御し、受信トラフィックはスイッチのファームウェアとハードウェアで制御されます。Smart Load Balancing の場合のように、BASP 中間ドライバは IP/TCP/UDP の発信元および宛先アドレスを使用して、サーバーの伝送トラフィックのロード バランスを行います。大部分のスイッチは、発信元および宛先 MAC アドレスの XOR ハッシュを実装しています。

メモ： 通有中継は、iSCSI オフロード アダプタではサポートされていません。

リンク集約 (IEEE 802.3ad LACP)

リンク集約は、Link Aggregation Control Protocol (LACP) を使用してチームを構成するポートをネゴシエートすることを除けば、通有中継と似ています。チームを使用できるようにするには、リンクの両端で LACP を有効にする必要があります。LACP がリンクの両端で利用可能になっていない場合、802.3ad はリンクの両端がリンクアップ状態であることのみを要求する手動集約を提供します。手動集約は LACP メッセージ交換を実行せずにメンバー リンクをアクティブ化するため、LACP ネゴシエート リンクと同程度に堅固で信頼できるとみなすことはできません。LACP は、どのメンバー リンクが集約可能であるかを自動的に判断して、それらを集約します。リンク集約用の物理リンクの追加と削除を制御して、フレームが失われたり複製されたりしないようにします。集約リンク メンバーの削除は、LACP 対応の集約リンクに対して、オプションとして使用可能なマーカー プロトコルで提供されます。

リンク集約グループは、中継内のすべてのポートに対して単一の MAC アドレスを通知します。集約先の MAC アドレスは、グループを構成するいずれかの MAC アドレスである可能性があります。LACP とマーカー プロトコルは、マルチキャスト宛先アドレスを使用します。

リンク集約制御機能は集約されるリンクを特定して、システムの集約機能にポートをバインドし、状況を監視して集約グループに変更が必要かどうかを判断します。リンク集約は複数のリンクの個々の能力を合わせて、高性能の仮想リンクを形成します。LACP トランク内のリンクの障害または交換で、接続性が失われることはありません。中継内の残りのリンクにトラフィックがフェイル オーバーされるだけです。

スマート ロード バランス (SLB) (自動フォールバックはディスエーブル)

このチーム タイプは、スマート ロード バランスおよびフェイルオーバー チーム タイプと同一です。ただし、スタンバイ メンバーがアクティブな状態であり、プライマリ メンバーが動作を再開した場合、チームはプライマリ メンバーに切り替えずにスタンバイ メンバーをそのまま使用するところが異なります。このチームは、ネットワーク ケーブルが外されてネットワーク アダプタに再接続されたときにのみサポートされます。アダプタがデバイス マネージャまたはホット プラグ PCI を介して取り外し/取り付けられた場合にはサポートされません。

チームに割り当てられたプライマリ アダプタがディスエーブルされた場合、チームは自動フォールバックが発生する Smart Load Balancing (スマート ロード バランス) およびフェイルオーバー チーム タイプとして機能します。

TOE のチーム化

4 つの標準チーム化モードはすべて、不良のあるアダプタから正しく動作しているアダプタへのトラフィックのフェイルオーバーをサポートしています。また、双方向の TCP/IP トラフィックのロードバランシングもサポートしています。各モードの主な違いは、SLB モードが Broadcom 独自のアルゴリズムを使用して、チーム内のネットワーク インターフェイス全体におけるアウトバウンド トラフィックおよびインバウンド トラフィックのバランシング方法を制御している点です。これにはいくつか利点があります。第一に、通有中継またはリンク集約モードを使用すると、チームに属するネットワーク アダプタは、その特定のチーム化モードをサポートするように設定されたスイッチに接続する必要があります。通有中継またはリンク集約を使用しているときにはスイッチとホスト チーム コンフィギュレーションとの間に依存性があるため、設定上の問題が発生しやすくなります。これは、両端を正しく設定し、同期させる必要があるためです。第二に、通有中継またはリンク集約モードを使用すると、スイッチがアダプタ全体におけるチームへのインバウンド トラフィックのバランシング方法を決定し、BASP はアウトバウンド トラフィックのバランシングを制御するだけです。これは TOE 環境で問題となります。TOE を動作させるために、特定の TCP 接続に関する状態情報が特定のオフロードされたアダプタ上のハードウェアに格納されますが、チームの全メンバー上のハードウェアには格納されないためです。このため、チーム化ソフトウェアが特定の TCP 接続向けの状態情報を含み、更新するアダプタに受信 TCP/IP トラフィックを誘導できない場合、チーム化と TOE は共存できません。

Broadcom の SLB モードは、アダプタ全体におけるアウトバウンド パケットとインバウンド パケットのバランシング方法を制御できるので、SLB モードは、特定の TCP 接続向けのオフロードされた TCP トラフィックをすべて、特定のアダプタを介して送受信させることが可能です。このアーキテクチャ機能により、SLB モードは TOE がイネーブルであるアダプタ上のロードバランシングをサポートすることもできます。これは、BASP が特定の TCP 接続上のトラフィックを、その TCP 接続向けのオフロードされた状態情報を含む アダプタ ハードウェアに誘導できるためです。BASP は TCP オフロードとチーム化の SLB モードとを併用できます。その他のチーム化モード (通有中継またはリンク集約) も TOE 対応デバイスで使用できますが、これらのモードがイネーブルされている場合、TOE 機能はディスエーブルされます。

TOE のオフロードされた状態情報はチームのメンバーのうち 1 つにしか格納されないため、BASP が TOE チーム上のフェイルオーバーをサポートする方法についてはわかりにくいかもしれません。TOE 接続が特定のアダプタにオフロードされ、そのネットワーク インターフェイスが何らかの方法で失敗した場合 (つまり、ケーブルが外れたことでネットワーク リンクを失うということです)、BASP はエラーを検出し、そのアダプタ上にある以前オフロードされた各 TCP 接続向けのオフロードされた TCP 状態情報をホストにアップロードするよう強制します。以前オフロードされた状態情報がすべてアップロードされたら、BASP は最近アップロードされた TCP 接続を再度バランシングし、これらの接続をチームの残りのメンバーに均等にオフロードします。基本的に、TOE 対応アダプタでエラーが発生した場合、そのアダプタにオフロード済みの任意の TCP 接続がチームのエラーの発生していない残りのメンバーに移行されます。

Broadcom NetXtreme II アダプタの場合、TOE を BASP で使用するための特別なセットアップ要件はありません。個々のアダプタを設定して TOE をイネーブルすると、アダプタをチームに追加でき、BASP 側からはオフロードが見えなくなります。TOE の設定については、リソース予約を表示および設定するを参照してください。

オフロードでのチーム化の各種制限

ソフトウェア コンポーネント

Windows オペレーティング システム環境では、チーム化は NDIS 中間ドライバによって実装されます。このソフトウェア コンポーネントがミニポート ドライバ、NDIS レイヤ、およびプロトコル スタックで動作して、チーム化アーキテクチャを可能にします (図 2 を参照)。ミニポート ドライバはホスト LAN コントローラを直接制御して、送受信および割り込みの処理などの機能を有効にします。中間ドライバはミニポート ドライバとプロトコル レイヤの間に位置し、複数のミニポート ドライバ インスタンスを多重化して、NDIS レイヤに対し単一アダプタのように見える仮想アダプタを作成します。NDIS は一連のライブラリ機能を提供して、ミニポート ドライバまたは中間ドライバとプロトコル スタック間の通信を有効にします。プロトコル スタックは IP、IPX、および ARP を実装します。IP アドレスなどのプロトコル アドレスは各ミニポート デバイス インスタンスに割り当てられますが、中間ドライバがインストールされている場合、プロトコル アドレスは仮想チーム アダプタに割り当てられ、チームを構成する個々のミニポート デバイスには割り当てられません。

Broadcom が提供するチーム化サポートは、協調して動作しパッケージとしてサポートされる 3 つの個別のソフトウェア コンポーネントによって実現します。1 つのコンポーネントをアップグレードする場合には、他のすべてのコンポーネントもサポートされている バージョンにアップグレードする必要があります。 表 3 では、4 つのソフトウェア コンポーネントと、サポートしているオペレーティング システム用の関連ファイルについて説明します。

ハードウェア要件

リピータ ハブ

スイッチング ハブ

ルーター

本書で説明されているさまざまなチーム化モードでは、クライアントをチーム化されたシステムに接続するためのネットワーク機器に、ある制限を設けています。各タイプのネットワーク インターコネクト テクノロジーがチーム化に与える影響に関してはこれ以降のセクションで説明します。

リピータ ハブ

リピータ ハブを使用すると、ネットワーク管理者はイーサネット ネットワークを個々のセグメントの限界以上に拡張することができます。リピータは 1 つのポートで受信した入力信号を接続されている他のすべてのポートで再生成して、単一の衝突ドメインを形成します。これは、リピータに接続されているステーションから別のステーションにイーサネット フレームを送信すると、同じ衝突ドメイン内のすべてのステーションでそのメッセージを受信するということです。2 つのステーションで同時に伝送を開始した場合、衝突が発生し、伝送中の各ステーションは任意の時間が経過した後に再度そのデータを伝送します。

リピータを使用するには、衝突ドメインに属している各ステーションが半二重モードで動作している必要があります。半二重モードは IEEE 802.3 仕様のギガビット イーサネット アダプタでサポートされていますが、ギガビット イーサネット アダプタ メーカーの大部分ではサポートされていません。そのため、半二重モードはここでは考慮しません。

複数のハブにまたがるチーム化は、SLB チームに対してのみトラブルシューティング (ネットワーク アナライザの接続など) の目的でサポートされています。

スイッチング ハブ

リピータ ハブとは異なり、スイッチング ハブ (さらに簡単に言えば、スイッチ) を使用すると、イーサネット ネットワークを複数の衝突ドメインに分けることができます。スイッチは、イーサネット MAC アドレスだけに基づいて、ホスト間でイーサネット パケットを転送する役割を果たします。スイッチに接続されている物理ネットワーク アダプタは、半二重または全二重モードで動作する場合があります。

通有中継と 802.3ad リンク集約をサポートするには、スイッチでこのような機能を明確にサポートしている必要があります。スイッチでこれらのプロトコルをサポートしていない場合でも、Smart Load Balancing で使用できる場合があります。

ルーター

ルーターはレイヤ 3 以上のプロトコルに基づいてネットワーク トラフィックをルーティングするよう設計されていますが、スイッチング機能を持つレイヤ 2 デバイスとして動作することもよくあります。ルーターに直接接続されるポートのチーム化は、サポートされません。

チーム化のサポート (プロセッサ別)

すべてのチーム タイプが、IA-32 および EM64T プロセッサでサポートされます。

チームの設定

Broadcom Advanced Control Suite 3 ユーティリティは、サポートされるオペレーティング システム環境でチーム化の設定に使用されます。

BACS (Broadcom Advanced Control Suite 3) は、以下のような 32 ビットおよび 64 ビットの Windows OS のいずれかで動作するよう設計されています。Microsoft Windows Server 2003 および Windows Server 2008。BACS 3 はロード バランシングおよびフォルト トレランスのチーム化の設定と、VLAN の設定に使用されます。さらに MAC アドレス、ドライバ バージョン、および各ネットワーク アダプタのステータス情報を表示します。BACS 3 には、ハードウェア診断、ケーブル テスト、およびネットワーク トポロジー テストなど数多くの診断ツールも含まれています。

サポートされる機能 (チーム タイプ別)

表 4 は、Dell でサポートされているチーム タイプの機能の比較を示しています。この表を使用して、アプリケーションに最適なチーム タイプを確認してください。チーム化ソフトウェアは、1 つのチームで最大 8 ポート、また 1 つのシステムで最大 4 チームをサポートします。4 つのチームにはサポートされるチーム化タイプを任意に組み合わせて使用できますが、各チームは別々のネットワークまたはサブネット上にある必要があります。

^a 1 つのプライマリ メンバーと 1 つのスタンバイ メンバーがある SLB。

^b チームには少なくとも 1 つの Broadcom アダプタが必須。

c TOE 機能は、すべて Broadcom TOE 対応のアダプタで構成される SLB チームによってのみ実現可能。

チーム タイプの選択

次のフロー チャートでは、レイヤ 2 のチーム化を計画するときの意思決定フローを示します。TOE のチーム化では、Smart Load Balancing™ (スマート ロード バランス) およびフェイルオーバー タイプ チームのみがサポートされます。チーム化を行う第 1 の理由は、ネットワーク帯域幅の増加とフォルト トレランスの向上が必要であることです。チーム化により、この両方の要件を満たすためのリンク集約とフォルト トレランスが提供されます。優先するチーム化は次の順序で選択する必要があります。最初の選択としてリンク集約、第 2 の選択として通有中継、さらに、管理されていないスイッチまたは最初の 2 つのオプションをサポートしないスイッチを使用する場合は第 3 の選択として SLB チーム化。スイッチのフォルト トレランスが必要な場合は、SLB が唯一の選択肢です (図 1を参照)。

チーム化の仕組み

アーキテクチャ

チーム タイプ

各チーム タイプと関連する各種機能の属性

各チーム タイプにサポートされる速度

アーキテクチャ

Broadcom Advanced Server Program は、NDIS 中間ドライバとして実装されます (図 2 を参照)。TCP/IP や IPX などのプロトコル スタックの下で動作し、仮想アダプタとして表示されます。この仮想アダプタは、チームで最初に初期化されたポートの MAC アドレスを継承します。レイヤ 3 アドレスも、仮想アダプタに対して設定する必要があります。BASP の主要機能は、チーム化することを選択されたシステムに取り付けられている物理アダプタ間で、インバウンド トラフィック (SLB の場合) とアウトバウンド トラフィック (すべてのチーム化モードの場合) のバランスをとることです。インバウンド アルゴリズムとアウトバウンド アルゴリズムは相互に独立し、直交しています。特定のセッションに対するアウトバウンド トラフィックを特定のポートに割り当て、対応するインバウンド トラフィックを別のポートに割り当てることができます。

アウトバウンド トラフィック フロー

Broadcom 中間ドライバは、すべてのチーム化モードのアウトバウンド トラフィック フローを管理します。アウトバウンド トラフィックの場合、すべてのパケットは最初にフローに分類され、選択された物理アダプタに配分されて伝送されます。フロー分類では、既知のプロトコル フィールドに対して効率的なハッシュ計算が行われます。結果のハッシュ値を使用して、アウトバウンド フロー ハッシュ テーブルにインデックスが作成されます。選択したアウトバウンド フロー ハッシュ エントリには、このフローの伝送を行う選択済み物理アダプタのインデックスが含まれています。パケットのソース MAC アドレスは、選択した物理アダプタの MAC アドレスに変更されます。変更されたパケットは、選択した物理アダプタに渡されて伝送されます。

アウトバウンド TCP および UDP パケットは、レイヤ 3 およびレイヤ 4 ヘッダ情報を使用して分類されます。このスキームにより、HTTP や FTP などの well-known ポートを使用した一般的なインターネット プロトコル サービスの負荷分散が向上します。このため BASP は、パケットごとではなく TCP セッション単位でロード バランシングを実行します。

アウトバウンド フロー ハッシュ エントリでは、分類後に統計カウンタも更新されます。ロードバランシング エンジンは、これらのカウンタを使用して、チーム化されたポート間にフローを定期的に配分します。アウトバウンド コード パスは、アウトバウンド フロー ハッシュ テーブルへの複数の同時アクセスが許可される最善の同時性を実現するように設計されています。

TCP/IP 以外のプロトコルでは、最初の物理アダプタが常にアウトバウンド パケットに対して選択されます。例外は、インバウンドのロード バランシングを実現するために別の方法で処理される Address Resolution Protocol (ARP) です。

インバウンド トラフィック フロー (SLB のみ)

Broadcom 中間ドライバは、SLB チーム化モードのインバウンド トラフィック フローを管理します。アウトバウンドのロード バランシングとは異なり、インバウンドのロード バランシングは、ロード バランシングされたサーバーと同じサブネット内にある IP アドレスにのみ適用できます。インバウンドのロード バランシングでは、Address Resolution Protocol (RFC0826) に固有の特性を利用します。各 IP ホストは独自の ARP キャッシュを使用して、IP データグラムを Ethernet フレームにカプセル化します。BASP は ARP 応答を慎重に操作し、インバウンド IP パケットを目的の物理アダプタに送信するよう各 IP ホストに指示します。このため、インバウンドのロード バランシングはインバウンド フローの統計履歴に基づいた事前計画スキームです。クライアントからサーバーへの新規接続は、常にプライマリ物理アダプタ上で行われます (オペレーティング システム プロトコル スタックによって生成された ARP 応答は常に論理 IP アドレスをプライマリ物理アダプタの MAC アドレスに関連付けるため)。

アウトバウンドの場合と同様に、インバウンド フロー ヘッド ハッシュ テーブルがあります。このテーブル内の各エントリには、単一リンクのリストがあり、各リンク (インバウンド フロー エントリ) は同じサブネット内にある IP ホストを表します。

インバウンド IP データグラムが到着すると、IP データグラムのソース IP アドレスをハッシュすることによって適切なインバウンド フロー ヘッド エントリが検索されます。選択したエントリに格納されている 2 つの統計カウンタも更新されます。これらのカウンタは、ロード バランシング エンジンによってアウトバウンド カウンタと同じ方法で定期的に使用され、フローが物理アダプタに再割り当てされます。

インバウンド コード パスでは、インバウンド フロー ヘッド ハッシュ テーブルが同期アクセスを許可するようにも設計されています。インバウンド フロー エントリのリンク リストは、ARP パケットの処理時と定期的なロード バランシング時にのみ参照されます。インバウンド フロー エントリへのパケット単位の参照はありません。リンク リストがバインドされていない場合でも、ARP 以外の各パケットの処理のオーバーヘッドは常に一定です。ただし、インバウンドとアウトバウンド両方の ARP パケットの処理は、対応するリンク リスト内のリンク数に依存します。

インバウンド 処理パスでは、ブロードキャスト パケットが他の物理アダプタからシステムを通じてループバックすることを防ぐために、フィルタも採用されています。

プロトコル サポート

ARP および IP/TCP/UDP フローは、ロード バランシングに対応します。パケットが、ICMP や IGMP などの IP プロトコルのみの場合、特定の IP アドレスへのすべてのデータ フローが同じ物理アダプタを介して送信されます。パケットが L4 プロトコルに TCP または UDP を使用している場合は、ポート番号がハッシュ アルゴリズムに追加されるため、2 つの異なる L4 フローが 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

UDP------> PhysAdatper3 ------> 10.0.0.1

アダプタ間の実際の割り当ては、時間の経過につれて変化する場合がありますが、ハッシュでは IP アドレスのみ使用されるため、TCP/UDP ベースでないプロトコルは同じ物理アダプタを通過します。

パフォーマンス

最近のネットワーク インターフェイス カードには、特定の CPU 集中型の操作のオフローディングを行うことで CPU 利用率を軽減する多くのハードウェア機能があります (チーム化とその他の高度なネットワーク プロパティを参照)。対照的に、BASP 中間ドライバは完全なソフトウェア機能であり、プロトコル スタックから受信した各パケットを調べて、内容に対処してから特定の物理インターフェイスを通じて送信する必要があります。BASP ドライバはほぼ一定の時間で各発信パケットを処理できますが、CPU を限界まで使用している一部のアプリケーションは、チーム化されたインターフェイスで動作している場合に悪影響を受けるおそれがあります。このようなアプリケーションは、ロード バランシング機能よりも中間ドライバのフェイルオーバー機能を利用する方が適切な場合があります。または、Large Send Offload (大量送信オフロード) などの特定のハードウェア機能を提供する単一の物理アダプタで、より効率的に動作する場合があります。

チーム タイプ

スイッチ非依存型

Broadcom Smart Load Balancing チーム タイプでは、2 ～ 8 の物理アダプタが単一の仮想アダプタとして動作できます。SLB チーム タイプの最大の利点は、任意の IEEE 準拠スイッチで動作し、特別な設定が不要なことです。

Smart Load Balancing (スマート ロード バランス) およびフェイルオーバー

SLB は、スイッチに依存しない双方向のフォルト トレラント チーム化およびロード バランシングを提供します。スイッチに依存しないということは、スイッチ内でこの機能をサポートしている必要がなく、SLB がすべてのスイッチと互換になることを意味します。SLB では、チーム内のすべてのアダプタに個別に MAC アドレスが与えられます。ロード バランシング アルゴリズムは、ソースおよび宛先ノードのレイヤ 3 アドレスで動作します。これにより、SLB は受信トラフィックと発信トラフィックの両方のロード バランシングを行うことが可能になります。

BASP 中間ドライバは、チーム内の物理ポートでリンク ロスを継続的に監視します。いずれかのポートでリンク ロスが発生した場合、トラフィックはチーム内の他のポートに自動的に転送されます。SLB チーム化モードは、異なるスイッチが同じ物理ネットワークまたはブロードキャスト ドメイン上にあれば、それらのスイッチ間のチーム化を許可することによりスイッチのフォルト トレランスをサポートします。

ネットワーク通信

次に、SLB の主要属性を示します。

アプリケーション

SLB アルゴリズムは、コストが考慮される、または市販のスイッチング装置が使用される家庭および小規模企業環境に最も適しています。SLB チーム化は、管理されていないレイヤ 2 スイッチで動作し、サーバーの冗長性とリンク集約を確保する費用対効果の高い方法となっています。Smart Load Balancing は、リンク容量が異なる物理アダプタのチーム化もサポートします。また、SLB は、チーム化したスイッチのフォルト トレランスが必要な場合にお勧めします。

推奨される設定

SLB では、ハブとスイッチが同じブロードキャスト ドメインにある場合に、そのハブとスイッチへのチーム化されたポートの接続がサポートされます。ポートは同じサブネット上にある必要があるため、ルーターまたはレイヤ 3 スイッチへの接続はサポートしていません。

スイッチ依存型

通有静的中継

アダプタ リンク パートナーで占有のトランキング メカニズムをサポートするよう静的に設定されている場合、このモードでさまざまな環境がサポートできます。このモードを使用して、Lucent の Open Trunk、Cisco の Fast EtherChannel (FEC)、および Cisco の Gigabit EtherChannel (GEC) をサポートできます。通有リンク集計の場合と同様に、静的モードでは、スイッチ管理者がポートをチームに割り当てる必要があります。また、Link Aggregation Control Protocol (LACP) フレームの交換がないため、この割り当ては BASP で変更できません。

このモードでは、チーム内のすべてのアダプタが同じ MAC アドレスの受信パケットに設定されます。トランキングはレイヤ 2 アドレスで動作し、インバウンド/アウトバウンド トラフィックのロード バランシングとフェイルオーバーをサポートしています。BASP ドライバは前述のレイヤ 4 プロトコルを使用してアウトバウンド パケットのロード バランシング スキームを決定するのに対し、チームのリンク パートナーはインバウンド パケットのロード バランシング スキームを決定します。

接続されているスイッチは、この動作モードに適したトランキング スキームをサポートする必要があります。BASP とスイッチはどちらもそれぞれのポートでリンク ロスを継続的に監視します。いずれかのポートでリンク ロスが発生した場合、トラフィックはチーム内の他のポートに自動的に転送されます。

ネットワーク通信

次に、通有静的中継の主要属性を示します。

アプリケーション

通有中継は、Cisco Fast EtherChannel、Cisco Gigabit EtherChannel、Extreme Networks Load Sharing、および Bay Networks または IEEE 802.3ad リンク集約静的モードをサポートするスイッチで動作します。ロード バランシングはレイヤ 2 アドレスに実装されているため、IP、IPX、NetBEUI などのすべての上位プロトコルがサポートされます。したがって、これはスイッチが SLB 上での通有中継モードをサポートしている場合に推奨されるチーム化モードです。

推奨される設定

静的中継では、スイッチが同じブロードキャスト ドメインにあり、通有中継をサポートしている場合に、そのスイッチへのチーム化されたポートの接続がサポートされます。ポートは同じサブネット上にある必要があるため、ルーターまたはレイヤ 3 スイッチへの接続はサポートしていません。

動的中継 (IEEE 802.3ad リンク集約)

このモードは、Link Aggregation Control Protocol (LACP) を介した静的および動的設定によるリンク集約をサポートします。このモードでは、チーム内のすべてのアダプタが同じ MAC アドレスの受信パケットに設定されます。チーム内の最初のアダプタの MAC アドレスが使用され、別の MAC アドレスで置換することはできません。BASP ドライバは前述のレイヤ 4 プロトコルを使用してアウトバウンド パケットのロード バランシング スキームを決定するのに対し、チームのリンク パートナーはインバウンド パケットのロード バランシング スキームを決定します。ロード バランシングはレイヤ 2 に実装されているため、IP、IPX、NetBEUI などのすべての上位プロトコルがサポートされます。接続されているスイッチは、この動作モードに対して 802.3ad リンク集約標準をサポートする必要があります。スイッチがアダプタへのインバウンド トラフィックを管理し、BASP がアウトバウンド トラフィックを管理します。BASP とスイッチはどちらもそれぞれのポートでリンク ロスを継続的に監視します。いずれかのポートでリンク ロスが発生した場合、トラフィックはチーム内の他のポートに自動的に転送されます。

ネットワーク通信

次に、動的中継の主要属性を示します。

アプリケーション

動的中継は、LACP を使用した IEEE 802.3ad リンク集約の動的モードをサポートしているスイッチで動作します。インバウンドのロード バランシングはスイッチに依存します。一般に、スイッチ トラフィックは L2 アドレスに基づいてロード バランシングに対応します。この場合、IP、IPX、NetBEUI などのすべてのネットワーク プロトコルのロード バランシングが行われます。したがって、スイッチのフォルト トレランスが必要な場合を除き、これはスイッチが LACP をサポートしている場合に推奨されるチーム化モードです。SLB は、スイッチ フォルト トレランスをサポートする唯一のチーム化モードです。

推奨される設定

動的中継では、スイッチが同じブロードキャスト ドメインにあり、IEEE 802.3ad LACP 中継をサポートしている限り、そのスイッチへのチーム化されたポートの接続がサポートされます。ポートは同じサブネット上にある必要があるため、ルーターまたはレイヤ 3 スイッチへの接続はサポートしていません。

LiveLink™

LiveLink™ は BASPの機能の 1 つで、Smart Load Balancing (SLB) と SLB (自動フォールバックはディスエーブル) のチーム タイプで動作します。LiveLink は、スイッチで発生したリンク ロスを検出し、リンクが有効になっているチーム メンバーのみのトラフィックをルーティングします。この機能は、チーム化ソフトウェアでも使用することができます。チーム化ソフトウェアは、各チーム メンバーからリンク パケットを発行して、1 つまたは複数の特定ネットワーク デバイスのプローブ (検査) を行います。プローブ対象は、リンク パケットを受信すると応答を返します。チーム メンバーが一定時間内に応答を検出しない場合、リンクは損失しており、チーム化ソフトウェアはそのチーム メンバーとのトラフィックの送受信を中断します。その後、そのチーム メンバーがプローブ対象からの応答を検出した場合、リンクは復元され、チーム化ソフトウェアはそのチーム メンバーとのトラフィックの送受信を自動的に再開します。LiveLink は、TCP/IP でのみ動作します。

LiveLink™ 機能は、32/64 ビット Windows オペレーティング システムでサポートされています。Linux オペレーティング システムに備わっている同様の機能については、Red Hat の文書類のチャネル結合に関する情報を参照してください。

各チーム タイプと関連する各種機能の属性

各チーム タイプと関連する各種機能の属性は、表 5 にまとめられています。

^a 中継接続間で正しくネゴシエートするには、リンク速度が一致していることが必要なスイッチもあります。

^b Port Fast または Edge Port が有効になっていることを確認してください。

各チーム タイプにサポートされる速度

各チーム タイプにサポートされるさまざまなリンク速度を 表 6 にリストします。混合速度とは、チーム化アダプタが異なるリンク速度で稼動できることを示します。

チーム化とその他の高度なネットワーク プロパティ

Checksum Offload（チェックサム オフロード）

IEEE 802.1p QoS タギング

Large Send Offload (大量送信オフロード)

TCP Offload Engine (TOE)

ジャンボ フレーム

IEEE 802.1Q VLAN

Wake On LAN

Preboot Execution Environment：プリブート実行環境

チームの作成、チーム メンバーの追加や削除、またはチーム メンバーの詳細設定の変更を行う前に、各チーム メンバーが同じように構成されていることを確認してください。確認する設定として、VLAN および QoS パケット タギング、ジャンボ フレーム、および各種オフロードがあります。詳細なアダプタ プロパティとチーム化サポートを 表 7 に示します。

^a チーム上のすべてのアダプタがこの機能をサポートしている必要があります。一部のアダプタは、ASF/IPMI も有効になっている場合にこの機能をサポートしないことがあります。

^b チーム内のすべてのアダプタによってサポートされている必要があります。

^c Broadcom アダプタのみ。

^d クライアントとしてではなく PXE サーバーとしてのみ。

チームは必ずしもアダプタ プロパティを引き継ぐわけではなく、具体的な機能に応じて、さまざまなプロパティを備えています。たとえば、フロー コントロールは、物理的なアダプタ プロパティで BASP とは関係ありませんが、アダプタのミニポート ドライバでフロー コントロールがイネーブルされていれば、そのアダプタではフロー コントロールがイネーブルされます。

メモ： チームがプロパティをサポートするために、チームのすべてのアダプタは、表 7 にリストされているプロパティをサポートする必要があります。

Checksum Offload（チェックサム オフロード）

Checksum Offload (チェックサム オフロード) は Broadcom ネットワーク アダプタのプロパティであり、送受信トラフィックの TCP/IP/UDP チェックサムをホスト CPU ではなくアダプタ ハードウェアで計算できるようにします。トラフィック量が多い状況では、これにより、システムはホスト CPU がチェックサムの計算を強制される場合よりも効率的に接続を処理できます。このプロパティは本質的にハードウェア プロパティであり、ソフトウェアのみの実装では利点を生かせません。Checksum Offload (チェックサム オフロード) をサポートするアダプタは、チェックサムをプロトコル スタックで計算する必要がないように、この機能をオペレーティング システムに公示します。チェックサム オフロードは、現時点で IPv4 に対してのみサポートされています。

IEEE 802.1p QoS タギング

IEEE 802.1p 標準には、トラフィックの優先順位づけを可能にする 3 ビットのフィールド (最大 8 つの優先順位レベルをサポート) が含まれています。BASP 中間ドライバは、IEEE 802.1p QoS タギングをサポートしていません。

Large Send Offload (大量送信オフロード)

Large Send Offload (LSO、大量送信オフロード) は、Broadcom ネットワーク アダプタが提供している機能であり、TCP などの上位レベル プロトコルによって大きなデータ パケットがヘッダを付加した小さな一連のパケットに分割されるのを回避します。プロトコル スタックは最大 64 KB のデータ パケットに対して単一のヘッダのみ生成する必要があり、アダプタ ハードウェアが、(最初に提供された単一ヘッダに基づいて) 正しく並べられたヘッダを持つ適切なサイズの Ethernet フレームにデータ バッファを分割します。

TCP Offload Engine (TOE)

TCP/IP プロトコル スイートは、インターネット、LAN、ファイル転送など、幅広い用途で転送サービスを提供するために使用されます。TCP/IP Offload Engine (TOE) がない場合、TCP/IP プロトコル スイートは、ホスト CPU 上で動作して、リソースの使用率の多くを消費するので、アプリケーションで使用できるリソースは大幅に減少します。Broadcom NetXtreme II アダプタを使用すると、TCP/IP の処理はハードウェアに移行されて CPU が解放されるため、アプリケーションの処理など、重要なタスクにリソースを使用できるようになります。

Broadcom NetXtreme II アダプタの TOE 機能では、完全にオフロードされた TCP 接続を同時に 1024 まで確立できます。アダプタでの TOE サポートにより、オペレーティング システム スタックの実装を保護すると同時に、ホスト CPU の使用率を大幅に削減します。

ジャンボ フレーム

ジャンボ フレームの使用は、元来は 1998 年に Alteon Networks, Inc. によって提案されたもので、Ethernet フレームの最大サイズを最大 9,000 バイトに増やします。正式には IEEE 802.3 Working Group によって採用されていませんが、ジャンボ フレームのサポートは Broadcom NetXtreme II アダプタで実装されています。チーム内のすべての物理アダプタがジャンボ フレームをサポートして、チーム内のすべてのアダプタに同じサイズが設定されていれば、BASP 中間ドライバもジャンボ フレームをサポートします。

IEEE 802.1Q VLAN

1998 年に、IEEE は 802.3ac 標準を承認しました。この標準は、IEEE 802.1Q 仕様で指定されている、Ethernet ネットワーク上での Virtual Bridged Local Area Network (VLAN) タギングをサポートするフレーム形式拡張を定義しています。VLAN プロトコルでは、フレームが属する VLAN を識別するための Ethernet フレームへのタグの挿入が許可されます。現在は、4 バイトの VLAN タグが Ethernet フレームのソース MAC アドレスと長さ/タイプ フィールドの間に挿入されます。VLAN タグの最初の 2 バイトは IEEE 802.1Q タグ タイプで構成され、次の 2 バイトにはユーザー優先順位フィールドと VLAN 識別子 (VID) が含まれます。仮想 LAN (VLAN) を利用すると、ユーザーは物理 LAN を論理的なサブパーツに分割できます。定義済みの VLAN は、そのトラフィックやブロードキャストがその他の VLAN から分離されるため、それぞれが独自の分離されたネットワークとして機能します。これにより各論理グループ内の帯域幅の効率が向上します。VLAN を利用すると、管理者は適切なセキュリティおよび QoS (Quality of Service、サービス品質) ポリシーを実施することもできます。BASP では、チームまたはアダプタあたり 64 個の VLAN の作成をサポートしています。63 個がタグ付きで、1 つはタグなしです。ただし、オペレーティング システムとシステム リソースによって、実際の VLAN 数が制限されます。VLAN サポートは、IEEE 802.1Q に従って提供され、チーム化環境と単一アダプタでサポートされます。VLAN は、同種のチーム化でのみサポートされ、Broadcom 以外の製品を使用したチーム化環境ではサポートされないことに注意してください。BASP 中間ドライバは、VLAN タギングをサポートしています。1 つ以上の VLAN を中間ドライバの単一インスタンスにバインドできます。

Wake On LAN

Wake on LAN (WOL) は、イーサネット インターフェイスから特定のパケットを受信すると、システムがスリープ状態から復帰できるようにする機能です。仮想アダプタは、ソフトウェア専用デバイスとして実装されるので、Wake on LAN の実装に必要なハードウェア機能がなく、仮想アダプタではスリープ状態からシステムを始動させることができません。ただし、物理アダプタでは、アダプタがチームの一部である場合でも、このプロパティをサポートします。

Preboot Execution Environment：プリブート実行環境

Preboot Execution Environment (PXE) では、ネットワークを使用して、システムをオペレーティング システム イメージから起動できます。定義上、PXE はオペレーティング システムをロードする前に呼び出されるため、BASP 中間ドライバがチームをロードしてイネーブルする機会はありません。したがって、オペレーティング システムのロード時にチームに入れられる物理アダプタは、PXE クライアントとして使用できますが、チーム化機能のアダプタは PXE クライアントとしてサポートされません。チーム化されたアダプタは PXE クライアントとして使用できませんが、Dynamic Host Control Protocol (DHCP) と Trivial File Transfer Protocol (TFTP) を使用して PXE クライアントにオペレーティング システム イメージを提供する PXE サーバーではこのアダプタを使用できます。これらのプロトコルは両方とも IP に対応しており、すべてのチーム化モードによってサポートされます。

全般的なネットワークに関する考慮事項

Microsoft Virtual Server 2005 とのチーム化

複数のスイッチにまたがるチーム化

スパニング ツリー アルゴリズム

レイヤ 3 ルーティング/スイッチング

ハブによるチーム化 (トラブルシューティングの目的のみ)

Microsoft NLB とのチーム化

Microsoft Virtual Server 2005 とのチーム化

Microsoft Virtual Server 2005 使用時にサポートされる BASP チーム コンフィギュレーションは、単一のプライマリ Broadcom アダプタおよびスタンバイ Broadcom アダプタで構成される Smart Load Balancing (TM) チームタイプのみです。Microsoft Virtual Server で、チームを作成する前、および仮想ネットワークを作成する前に、「仮想マシン ネットワーク サービス」を各チーム メンバーからバインド解除または選択解除する必要があります。また、仮想ネットワークをこのソフトウェアに作成し、その後、チームによって作成された仮想アダプタにバインドする必要があります。ゲスト オペレーティング システムをチームの仮想アダプタに直接バインドすると、期待する結果が得られない場合があります。

メモ： 本書作成の時点では、Windows Server 2008 は Microsoft Virtual Server 2005 でサポートされていません。そのため、この組み合わせの場合、チーム化が正常に動作しないことがあります。

複数のスイッチにまたがるチーム化

SLB のチーム化は、複数のスイッチにまたがって設定できます。ただし、スイッチ同士を接続する必要があります。通有中継とリンク集約は、複数のスイッチにまたがって動作できません。その理由は、これらの実装では、チームに含まれるすべての物理アダプタで同じイーサネット MAC アドレスを使用する必要があるためです。SLB がリンク ロスを検出できるのは、チームに含まれるポート間の接続や、直接のリンク パートナーとの接続に限られるという点に注意することが重要です。SLB には、スイッチで生じる他のハードウェア障害に対応する機能がなく、他のポートのリンク ロスを検出できません。

スイッチリンクのフォルト トレランス

以下の図では、フォルト トレランス対応のスイッチ構成でどのように SLB チームが動作するかを説明します。SLB チームにアクティブな 2 つのメンバーがある構成で、ping リクエストと ping 応答メッセージのマッピングを説明します。すべてのサーバー (Blue、Gray、Red) は、継続的に ping の送受信を相互に行っています。 図 3 は、2 つのスイッチ間に相互接続ケーブルがない構成です。 図 4 では相互接続ケーブルがあります。図 5 は相互接続ケーブルがある状態でのフェイルオーバー イベントの例です。これらのシナリオでは、2 つのスイッチ間でのチーム化の動作を説明して、相互接続リンクの重要性を理解します。

この図では、ICMP エコー要求 (黄色の矢印) を送信する第 2 のチーム メンバーと、ICMP エコーの応答メッセージ (青い矢印) を受信する第 1 のチーム メンバーを示します。この図は、チーム化ソフトウェアの重要な特性を表しています。ロード バランシング アルゴリズムは、フレームの送受信時に、フレームのロード バランスを同期しません。言い換えると、特定の接続でのフレームは、チーム内の異なるインターフェイスで送信され、受信される可能性があります。これは、Broadcom がサポートするすべての タイプのチーム化で共通しています。したがって、同じチーム内のポートに接続するスイッチの間では、相互接続リンクを提供する必要があります。

相互接続していない構成では、Blue から Gray への ICMP 要求は、ポート 82:83 から Gray のポート 5E:CA に向けて送信されますが、Top Switch には、この要求を送信する方法がありません。なぜなら、この要求は、Gray の 5E:C9 ポートを通過できないからです。Gray が Blue に ping の送信を試行する場合にも、同じような問題が発生します。ICMP 要求は、5E:C9 から Blue の 82:82 に向けて送信されますが、この要求が受信されることはありません。Top Switch は、CAM テーブル内に 82:82 エントリを持っていません。なぜなら、2 つのスイッチの間に相互接続していないからです。ただし、ping は Red と Blue の間、Red と Gray の間では送受信されます。

さらにフェイルオーバー イベントによって、接続が切断される場合もあります。Top Switch のポート 4 でケーブル接続の切断が生じたと仮定します。この場合、Gray は ICMP 要求を 49:C9 に送信しますが、Bottom Switch は CAM テーブル内に 49:C9 エントリを持っていないので、フレームをこれらの全ポートに配信しても、49:C9 に接続するリンクは検出できません。

スイッチ間にリンクを設定すると、Blue と Gray の間で何の問題もなく、相互にトラフィックを送受信できます。両方のスイッチの CAM テーブルを参照して、追加されたエントリに注目してください。チームが適切に機能するには、このリンクの相互接続が重要です。したがって、2 つのスイッチを相互接続して可用性の高い接続を保証するために、リンク集約中継を使用することを強くお勧めします。

図 5 は、Top Switch のポート 4 でケーブルが外れた場合のフェイルオーバー イベントを表しています。接続が切断されずに、すべてのステーションが相互に ping を送受信できるので、これは適切なフェイルオーバーです。

スパニング ツリー アルゴリズム

トポロジー変更通知 (TCN)

Port Fast/Edge Port

イーサネット ネットワークの場合、2 つのブリッジ間またはスイッチ間では、アクティブなパスが 1 つだけ存在します。スイッチ間にアクティブなパスが複数存在していると、ネットワーク内にループが生じる可能性があります。ループが発生すると、一部のスイッチは、スイッチの両側でステーションを認識するようになります。この状況では、転送アルゴリズムが正常に機能できず、重複フレームが転送される可能性があります。スパニング ツリー アルゴリズムでは、拡張ネットワーク内の全スイッチにまたがるツリーを定義して、特定の冗長データ パスを強制的にスタンバイ (ブロック) 状態に切り替えることで、パスの冗長性を実現します。ネットワーク内のスイッチは、パスの識別に使用するスパニング ツリー パケットを定期的に送受信します。1 つのネットワーク セグメントが到達不能になった場合、あるいはスパニング ツリーのコストが変わった場合、スパニング ツリー アルゴリズムは、スパニング ツリー トポロジーを再設定し、スタンバイ パスをアクティブ化することでリンクを再設定します。エンド ステーション側では、スパニング ツリーの動作は見えません。したがって、これらのステーションでは、1 つの LAN セグメントに接続したのか、複数のセグメントで構成されたスイッチ LAN に接続したのかわかりません。

Spanning Tree Protocol (STP) は、ブリッジ間やスイッチ間での動作を目的としたレイヤ 2 プロトコルです。STP の仕様は、IEEE 802.1d で定義されています。STP の主な目的は、ネットワーク内に冗長パスがあるときにループに陥らないようにすることです。STP は、ネットワーク ループの検出/ディスエーブルを行い、スイッチまたはブリッジの間にバックアップ リンクを提供します。このプロトコルを使用すると、デバイスは、ネットワーク内の 2 つのステーションの間で 1 つのパスのみを使用するように、ネットワークにある他の STP 準拠デバイスと相互操作を行うことが可能になります。

安定したネットワーク トポロジーを確立すると、すべてのブリッジはルート ブリッジから送信される hello BPDU (Bridge Protocol Data Units) を待つ状態になります。あらかじめ定義された時間 (最大経過時間) が経過しても、ブリッジが hello BPDU を受信しない場合、ブリッジはルート ブリッジへのリンクがダウンしたと判断します。次にこのブリッジは、他のブリッジとのネゴシエーションを開始して、ネットワークを再設定して、有効なネットワーク トポロジーを再び確立します。新しいトポロジーを作成するプロセスは、最大 50 秒かかります。この間、エンドツーエンドの通信は中断されます。

エンド ステーションに接続したポートに対しては、スパニング ツリーは使用しないことをお勧めします。その理由は、定義上、エンド ステーションは、イーサネット セグメント内でループを作成しないからです。さらにチーム化したアダプタを、スパニング ツリーをイネーブルしたポートに接続すると、接続上の不測の問題が発生する可能性があります。たとえば、チーム化したアダプタが物理アダプタの 1 つでリンクを失ったと仮定します。物理アダプタが再接続された場合 (フォールバックとも呼びます)、中間ドライバはリンクが再び確立され、ポートでトラフィックの送受信が開始されたと認識します。しかし、スパニング ツリー プロトコルによってポートが一時的にブロックされると、トラフィックが失われることになります。

トポロジー変更通知 (TCN)

ブリッジ/スイッチは、特定のポートで受信したソース MAC アドレスから、MAC アドレスとポート番号の転送テーブルを作成します。このテーブルは、すべてのポートにフレームを配信するのではなく、特定のポートにフレームを転送するために利用します。テーブル エントリの最大の格納時間は、一般的に 5 分です。ホストでアクティビティが 5 分間ないと、エントリはテーブルから削除されます。エントリの格納時間を短くすると、効果がある場合もあります。たとえば、転送リンクがブロック状態になったときに、異なるリンクをブロック状態から転送状態に切り替えるときです。この変更には、最大 50 秒かかります。STP の再計算が完了すると、エンド ステーション間の通信で、新しいパスが利用可能になります。ただし、転送テーブルには依然として古いトポロジーのエントリがあるので、5 分が経過して影響を受けるポート エントリがテーブルから削除されるまで、通信が再確立されない可能性があります。そして、トラフィックはすべてのポートに配信されて、再び取得されます。このような場合は、格納時間を短くすると効果があります。これがトポロジー変更通知 (Topology Change Notice、TCN) BPDU の目的です。TCN は、影響を受けるブリッジ/スイッチからルート ブリッジ/スイッチに送信されます。ブリッジ/スイッチはトポロジーの変更 (リンクのダウンまたは転送状態へのポートの切り替え) を検出すると、すぐにルート ポートを経由して TCN をルート ブリッジに送信します。次にルート ブリッジは、トポロジーの変更を通知する BPDU をネットワーク全体に配信します。この情報を受けて、すべてのブリッジは、MAC テーブルの格納時間を 15 秒に変更します。この手順により、STP の再収束の後、スイッチはすぐに MAC アドレスを再び取得できます。

TCN BPDU は、ポートが転送状態でからブロック状態に切り替わったとき、あるいはブロック状態から転送状態に切り替わったときに送信されます。TCN BPDU では、STP の再計算は開始されません。この通知は、スイッチ内の転送テーブル エントリの格納時間にのみ影響を及ぼし、ネットワーク トポロジーの変更や、ループの作成は行いません。サーバーまたはクライアントなどのエンド ノードの場合は、電源のオフ/オン時にトポロジーの変更が開始されます。

Port Fast/Edge Port

ネットワーク上で TCN の影響 (たとえば、スイッチ ポートで配信が増えるなど) を軽減するには、電源のオン/オフの頻度が高いエンド ノードに対して、接続先になるスイッチ ポートで Port Fast または Edge Port を設定する必要があります。Port Fast または Edge Port は、特定のポートに適用されるコマンドであり、以下の効果があります。

レイヤ 3 ルーティング/スイッチング

チーム化したポートを接続するスイッチは、レイヤ 3 スイッチまたはルーターである必要があります。チーム内のポートは、同じネットワークに属す必要があります。

ハブによるチーム化 (トラブルシューティングの目的のみ)

チーム化ネットワーク構成でのハブの利用

SLB チーム

単一ハブに接続された SLB チーム

通有中継と動的中継 (FEC/GEC/IEEE 802.3ad)

10/100 ハブでは、SLB のチーム化機能を使用できますが、スイッチ ポートのミラーリングが使用できないときに、ネットワーク アナライザに接続する場合など、トラブルシューティングの目的のみに限定することをお勧めします。

チーム化ネットワーク構成でのハブの利用

状況によって、ネットワーク トポロジーでハブを使用できますが、使用する場合は、パフォーマンスに対する影響を考慮することが重要です。ネットワーク ハブの場合、半二重モードでは最大 100 Mbps の転送速度になりますが、ギガビット または 100 Mbps のスイッチ ネットワーク構成では、パフォーマンスが大幅に低下します。ハブの帯域幅は、接続されているすべてのデバイスによって共有されます。したがって、ハブに接続するデバイスが多くなると、ハブに接続したデバイス数に比例して、ハブに接続した各デバイスが使用できる帯域幅が狭くなります。

チーム メンバーをハブに接続することはお勧めできません。チーム化したポートに接続する場合は、スイッチのみを使用する必要があります。ただし、トラブルシューティングを目的として、SLB チームを直接的にハブに接続することができます。その他のチーム タイプは、特定の障害が発生すると接続が失われる可能性があるので、ハブには使用しないでください。

SLB チーム

SLB チームは、スイッチの設定に依存しない唯一のチーム タイプです。サーバーの中間ドライバは、スイッチからの支援がなくても、ロード バランシングとフォルト トレランス メカニズムを制御します。SLB にはこれらの要素があるため、チーム ポートをハブに直接的に接続した場合でも、フェイルオーバーとフォールバックの特性を維持できる唯一のチーム タイプになっています。

単一ハブに接続された SLB チーム

図 6 のように構成された SLB チームでは、フォルト トレランスの属性が維持されます。どちらかのサーバー接続が切断された場合でも、ネットワーク機能はそのまま維持されます。クライアントをハブに直接接続することはできませんが、フォルト トレランスは維持されます。ただし、この場合、サーバーのパフォーマンスは低下します。

通有中継と動的中継 (FEC/GEC/IEEE 802.3ad)

FEC/GEC と IEEE 802.3ad チームは、ハブの構成には接続できません。これらのチーム タイプは、そのチーム タイプ用に設定したスイッチに接続する必要があります。

Microsoft NLB とのチーム化

チーム化の SLB モードは、Microsoft の ネットワーク負荷分散 (NLB) ユニキャスト モードでは動作しません。マルチキャスト モードのみで動作します。NLB サービスで使用されるメカニズムでは、ロード バランシングが NLB によって管理されるため、この環境のチーム化設定はフェイルオーバー (スタンバイ NIC のある SLB) にすることをお勧めします。チーム化の TOE 機能は NLB では動作しません。

アプリケーションに関する考慮事項

チーム化とクラスタリング

チーム化とネットワーク バックアップ

チーム化とクラスタリング

Microsoft クラスタ ソフトウェア

高性能コンピューティング クラスタ

Oracle

Microsoft クラスタ ソフトウェア

Dell サーバー クラスタ ソリューションは、Microsoft Cluster Services (MSCS) と PowerVault SCSI、または Dell/EMC Fibre-Channel ベースのストレージ、Dell サーバー、ストレージ アダプタ、ストレージ スイッチ、ネットワーク アダプタを統合して、高可用性 (HA) ソリューションを実現します。HA クラスタリングは、サポート対象である Dell サーバーで使用できるすべてのアダプタをサポートします。

Windows Server 2003 を使用している場合は、MSCS クラスタは最高 8 個のノードをサポートします。各クラスタ ノードでは、カスタマが最低 2 ネットワーク アダプタ (オンボード アダプタでも可能) を取り付けることを強くお勧めします。これらのインターフェイスは、2 つの目的に使用します。1 つのアダプタは、クラスタ内のハートビート通信専用に使用されます。これはプライベート アダプタと呼ばれ、通常、独立したプライベート サブネットワークに含まれます。その他のアダプタはクライアント通信に使用され、パブリック アダプタと呼ばれます。

プライベートなクラスタ内通信と、パブリックな外部クライアント通信のために、 それぞれの目的に合わせて複数のアダプタを使用できます。Microsoft クラスタ ソフトウェアでは、パブリック アダプタに限り、すべての Broadcom チーム化モードがサポートされます。プライベート ネットワーク アダプタのチーム化はサポートされません。Microsoft の発表によると、サーバー クラスタでは、プライベートな相互接続にチーム化を使用できません。これは、ノード間でハートビート パケットを送受信するために遅延が発生する可能性があるからです。プライベートな相互接続に冗長性を確保して、同時に優れたパフォーマンスも実現するには、チーム化をディスエーブルして、使用可能なポートでプライベートな第 2 の相互接続を確立します。この方法でも機能的には同じ効果があり、複数のノードが通信に使用できる二重の堅牢な通信パスが実現されます。

クラスタ環境でチーム化を行う場合は、同じブランドのアダプタを使用することをお勧めします。

図 7 は、2 ノードのファイバチャネル クラスタであり、クラスタ ノード当たり 3 つのネットワーク インターフェイスがあります。クラスタ ノードの構成は、 1 つのプライベートと、2 つのパブリックとなっています。各ノードでは、2 つのパブリック アダプタがチーム化され、プライベート アダプタはチームに含まれていません。同じスイッチ内、または 2 つのスイッチ間で、チーム化がサポートされます。 図 8 は、この構成で設定した同じ 2 ノード ファイバチャネル クラスタです。

メモ： Microsoft ネットワーク負荷分散は、Microsoft クラスタ ソフトウェアではサポートされません。

高性能コンピューティング クラスタ

ギガビット イーサネットは、一般的に、高性能コンピューティング クラスタ (HPCC) アプリケーションで以下の 3 つの目的で使用されます。

当社の現在の HPC では、1 つのオンボード アダプタのみが使用されます。Myrinet または IB がある場合は、このアダプタは I/O と管理の目的に使用されます。それ以外の場合、IPC の目的にも使用されます。アダプタで障害が発生した場合、管理者は Felix パッケージを使用して、アダプタ 2 を簡単に設定できます。ホスト側でアダプタのチーム化を行うと、HPCC ではテストにもサポートにも対応できません。

高度な機能

PXE は、クラスタの導入のために広範に使用されます (コンピューティング ノードのインストールとリカバリ)。通常、チーム化はホスト側では使用されず、標準的な構成の一部にはなりません。一般的には、特に大規模な構成では、リンク集約がスイッチ間で使用されます。ジャンボ フレームは、標準的な構成では使用しませんが、CPU のオーバーヘッドを軽減することで、一部のアプリケーションでパフォーマンスを改善できます。

Oracle

当社の Oracle Solution Stacks では、クライアントまたはデータベース レイヤの上位にあるアプリケーション レイヤを対象として、プライベート ネットワーク (RAC ノード間の相互接続) とパブリック ネットワークの両方でアダプタのチーム化をサポートします。

チーム化とネットワーク バックアップ

ロード バランシングおよびフェイルオーバー

フォルト トレランス

チーム化していない環境で、ネットワーク バックアップを実行すると、バックアップ サーバー アダプタの全体的な転送速度は、過剰なトラフィックとアダプタの大きな負荷によってすぐに影響を受けます。バックアップ サーバーの数、データ ストリーム、テープ ドライブの速度によって変わりますが、バックアップ トラフィックは、ネットワーク リンクの帯域幅の大部分を簡単に消費するので、実稼動環境のデータ処理速度やテープ バックアップのパフォーマンスに影響が出ます。ネットワーク バックアップは、通常、NetBackup、Galaxy または Backup Execなど、テープ バックアップ ソフトウェアを実行する専用のバックアップ サーバーで構成されます。バックアップ サーバーに接続するデバイスは、直接 SCSI テープ バックアップ ユニット、またはファイバ チャネルのストレージ エリア ネットワーク (SAN) で接続したテープ ライブラリです。ネットワークを通じてバックアップされるシステムは、一般的に、クライアント システムまたはリモート サーバーと呼ばれ、テープ バックアップ ソフトウェア エージェントがインストールされています。 図 9 は、テープ バックアップ実装を使用する典型的な 1 Gbps の非チーム化ネットワーク環境です。

4 つのクライアント サーバーがあるので、バックアップ サーバーは、マルチドライブ オートローダに対して、同時に 4 つのバックアップ ジョブ (クライアントごとに 1 ジョブ) を実行できます。ただし、スイッチとバックアップ サーバーの間のリンクは 1 つなので、4 ストリームのバックアップでは、アダプタとリンクが簡単にリソース不足の状態になる可能性があります。バックアップ サーバーのアダプタが 1 Gbps (125 MB/秒) で動作しており、各クライアントがテープ バックアップ時に 20 MB/秒でデータを転送できる場合、バックアップ サーバーとスイッチの間のスループットは、80 MB/秒 (20 MB/秒 x 4) になります。これは、ネットワークの帯域幅の 64 % に相当します。この数値は、ネットワークの帯域幅の中に収まっていますが、他のアプリケーションと同じリンクを共有している場合、64 % は高い割合と考えられます。

ロード バランシングおよびフェイルオーバー

バックアップ ストリームの数が増えると、全体的なスループットも増加します。ただし、各データ ストリームは、25 MB/秒 の 1つのバックアップ ストリームと同じパフォーマンスを維持できない場合があります。言い換えると、バックアップ サーバーは 25 MB/秒 の単一クライアントのデータ ストリームには対応できますが、100 MB/秒 (25 MB/秒 x 4 ストリーム) で 4 つの同時実行バックアップ ジョブに対応することは困難です。バックアップ ストリームの数が増えると全体的なスループットが増加しますが、各バックアップ ストリームはテープ ソフトウェアまたはネットワーク スタックの制限に影響を受ける可能性があります。

クライアントのバックアップを実行するときに、テープ バックアップ サーバーでアダプタの最適なパフォーマンスを引き出し、高い信頼性でネットワークの帯域幅を使用するには、ネットワーク インフラストラクチャでロード バランシングやフォルト トレランスなど、チーム化を実装する必要があります。データ センターは、フォルト トレランス対応ソリューションの一部として、冗長スイッチ、リンク集約、およびトランキングを組み込みます。チーム化されたデバイス ドライバは、チーム化されたインターフェイスとフェイルオーバー パスをデータが流れる方法を制御しますが、この処理はテープ バックアップ アプリケーション側からは見えません。また、ネットワークを通じて、リモート システムをバックアップするときに、テープ バックアップ プロセスがこの処理の干渉を受けることもありません。 図 10では、Broadcom のチーム化環境でテープ バックアップをデモンストレーションするネットワーク トポロジーであり、Smart Load Balancing がチーム化したアダプタの間で、どのようにテープ バックアップ データのロード バランスを行うかを示します。

クライアントサーバーがバックアップ サーバーへのデータ送信に使用できるパスは 4 つありますが、データ転送時にはこれらのパスの 1 つだけが指定されます。バックアップ サーバーへのデータ送信にクライアントサーバー Red が使用できるパスは以下のとおりです。

パスの例： クライアントサーバー Red は、アダプタ A、スイッチ 1、バックアップ サーバー アダプタ A を通じてデータを送信します。

指定されたパスは、以下の 2 つの要素によって決まります。

バックアップ サーバーのチーム化インターフェイスは、クライアントサーバー Red への転送に G-ARP (gratuitous address resolution protocol) を使用します。そして今後は、クライアント サーバーの ARP キャッシュがバックアップ サーバーの MAC アドレスで更新されるようになります。チーム化インターフェイス内のロード バランシング メカニズムによって、G-ARP に組み込まれる MAC アドレスが決定されます。選択された MAC アドレスは、基本的にクライアント サーバーがデータの転送先として使用するアドレスです。クライアントサーバー Red では、SLB チーム化アルゴリズムによって、2 つのアダプタ インターフェイスから、実際にデータ転送に使用するインターフェイスが決定されます。この例では、クライアントサーバー Red からのデータが、バックアップ サーバーのアダプタ A インターフェイスで受信されます。チーム化したインターフェイスにさらに負担がかかったときに SLB が機能する仕組みをデモンストレーションするため、バックアップ サーバーが第 2 のバックアップ処理を開始するシナリオを考えてみます。具体的には、クライアントサーバー Red へのバックアップに加えて、クライアントサーバー Blue に対して第 2 のバックアップを開始します。バックアップ サーバーへのデータ送信にクライアントサーバー Blue が使用するルートは、バックアップ サーバーの MAC アドレスを指定する ARP キャッシュによって決定されます。バックアップ サーバーのアダプタ A では、すでにクライアントサーバー Red のバックアップ処理で負担がかかっているため、バックアップ サーバーは、SLB アルゴリズムを呼び出します。そして、ARP キャッシュをバックアップ サーバーのアダプタ B の MAC アドレスに変更するように、クライアントサーバー Blue に (G-ARP を通じて) 通知メッセージを送信します。クライアントサーバー Blue は、データを転送する必要があるとき、SLB アルゴリズムによって決定されたいずれかのアダプタ インターフェイスを使用します。重要な点は、クライアントサーバー Blue からのデータが、バックアップ サーバーのアダプタ A インターフェイスではなく、アダプタ B インターフェイスで受信されることです。これが重要とされる理由は、両方のバックアップ ストリームが同時に実行されており、バックアップ サーバーは、異なるクライアントからのデータ ストリームに対してロード バランスを実行する必要があるからです。両方のバックアップ ストリームを実行している場合、バックアップ サーバーの各アダプタ インターフェイスは同等の負荷を担っており、ロード バランス対象のデータは、両方のアダプタ インターフェイスで均等に処理されることになります。

バックアップ サーバーが第 3、第 4 のバックアップ処理を開始した場合も、同じアルゴリズムが適用されます。バックアップ サーバーでチーム化したインターフェイスは、ユニキャスト G-ARP を転送して、バックアップ クライアントに ARP キャッシュを更新するように通知します。そして、各クライアントは、バックアップ サーバー上のターゲット MAC アドレスに至るルートで、バックアップ データを転送します。

フォルト トレランス

テープ バックアップの実行中にネットワーク リンクで障害が発生した場合、バックアップ サーバーとクライアントの間のすべてのトラフィックが停止して、バックアップ ジョブが失敗します。しかし、Broadcom SLB とスイッチ フォルト トレランスの両方に対応するように、ネットワーク トポロジーを設定した場合、リンクに障害が発生しても、滞りなくテープ バックアップを続行することができます。ネットワーク内のすべてのフェイルオーバー プロセスは、テープ バックアップ ソフトウェア アプリケーション側では見えません。ネットワーク フェイルオーバー プロセスで、バックアップ データ ストリームの送信先を決定する方法を理解するには、図 10 のトポロジーを理解してください。クライアントサーバー Red は、パス 1 を通じてバックアップ サーバーにデータを転送しますが、リンク障害はバックアップ サーバーとスイッチの間で発生します。データは、スイッチ #1 からバックアップ サーバーのアダプタ A インターフェイスへ送信できなくなったので、このデータは、スイッチ #1 からスイッチ #2 を介して、バックアップ サーバーのアダプタ B インターフェイスにリダイレクトされます。フォルト トレランス対応の動作はすべてアダプタ チームのインターフェイスとスイッチ上の中継の設定によって処理されるので、リダイレクトはバックアップ アプリケーションに認識されずに実行されます。クライアント サーバー側から見ると、元のパスを介してデータを送信しているように動作します。

チーム化に関する問題のトラブルシューティング

チーム化の設定のヒント

トラブルシューティングのガイドライン

仮想アダプタのチーム化インターフェイス上でプロトコル アナライザ を実行すると、送信されたフレームに示される MAC アドレスは正確でない場合があります。アナライザは、BASP で構築したフレームを表示せず、フレームを転送するインターフェイスの MAC アドレスでなく、チームの MAC アドレスを表示します。以下の手順でチームを監視することをお勧めします。

チーム化の設定のヒント

ネットワーク接続またはチーム化機能のトラブルシューティングをするときは、次の説明が指定した設定に当てはまることを確認します。

トラブルシューティングのガイドライン

システムでアダプタのチーム化を使用している場合は、Dell サポートへ問い合わせる前に、以下に示すネットワーク接続に関する問題のトラブルシューティングを実行してください。

よくある質問

質問： どのような状況だと、トラフィックのロード バランシングは行われないのでしょうか。チームのすべてのメンバー間で均等にロード バランシングが行われないのはなぜですか。

対応策： 大量のトラフィックが IP/TCP/UDP を使用していないか、多くのクライアントが別のネットワークに接続しています。受信のロード バランシングはトラフィック負荷に対する機能ではなく、サーバーに接続するクライアントの数に対して実行される機能です。

質問： チーム内でロード バランシングが行われるネットワーク プロトコルを教えてください。

対応策： Broadcom のチーム化ソフトウェアは IP/TCP/UDP トラフィックのみをサポートします。それ以外のトラフィックはすべてプライマリ アダプタに転送されます。

質問： SLB でロード バランシングが行われるプロトコルと、行われないプロトコルを教えてください。

対応策： 送信と受信の両方向でロード バランシングが行われるのは、IP/TCP/UDP プロトコルに対してのみです。IPX に対しては送信のみロード バランシングが行われます。

質問： 100 Mbps で動作するポートと 1000 Mbps で動作するポートをチーム化できますか。

対応策： 異なるリンク速度のポートの混在は、Smart Load Balancing™ のチームと 802.3ad チームでのみサポートします。

質問： ファイバ アダプタと銅線 Gigabit Ethernet アダプタをチーム化できますか。

対応策： SLB では可能です。スイッチが FEC/GEC および 802.3ad に対応する場合も可能です。

質問： アダプタのロード バランシングと Microsoft ネットワーク負荷分散 (NLB) との違いは何ですか。

対応策： アダプタのロード バランシングはネットワーク セッション レベルで行われますが、NLB はサーバー アプリケーション レベルで行われます。

質問： チーム化されたアダプタをハブに接続できますか。

対応策： チーム化されたポートはトラブルシューティングを目的とする場合にのみハブに接続できます。ただし、この方法はハブの制限によってパフォーマンスが低下するため、通常の運用ではお勧めできません。チーム化されたポートはスイッチに接続してください。

質問： チーム化されたアダプタをルーターのポートに接続できますか。

対応策： いいえ。チーム内のポートはすべて同一のネットワーク上に存在する必要がありますが、ルーターでは定義上各ポートが個別のネットワークにあります。チーム化のすべてのモードでは、リンク パートナーがレイヤー 2 スイッチであることが必要です。

質問： Microsoft Cluster Services でチーム化を使用できますか。

対応策： はい。チーム化は、パブリック ネットワーク上でのみサポートされます。ハートビート リンクで使用するプライベート ネットワークではサポートされません。

質問： PXE は仮想アダプタ (チーム) 上で動作しますか。

対応策： PXE クライアントは、オペレーティング システムがロードされる前の環境、つまり、仮想アダプタはまだ有効になっていない状態で動作します。物理アダプタが PXE をサポートする場合は、オペレーティング システムのロード時に仮想アダプタの要素になるかどうかにかかわらず、これを PXE クライアントとして利用できます。PXE サーバーは仮想アダプタ上で動作します。

質問： WOL は仮想アダプタ (チーム) 上で動作しますか。

対応策： Wake-on-LAN 機能は、オペレーティング システムがロードされる前の環境で動作します。WOL は、システムが停止またはスタンバイの状態で起動するので、チームは設定されません。

質問： ポートは最大何個までチーム化できますか。

対応策： 最大 8 個のポートをチームに割り当てることができます。

質問： 同一のサーバー上で設定できるチームは最大何個ですか。

対応策： 同一のサーバー上で最大 4 個のチームを設定できます。

質問： プライマリ アダプタを元に戻して (フォールバック) から 30 ～ 50 秒間チームの接続が失われるのはなぜですか。

対応策： Spanning Tree Protocol が、ポートをブロックから転送に移行させているためです。STP 遅延を考慮するには、チームに接続されたスイッチ ポート上で Port Fast または Edge Port を有効にするか、LiveLink を使用する必要があります。

質問： 複数のスイッチにまたがってチームを接続できますか。

対応策： Smart Load Balancing では、システム内の個々の物理アダプタが一意の Ethernet MAC アドレスを使用するので、複数のスイッチを使用できます。リンク集約と通有中継は、すべての物理アダプタが同一の Ethernet MAC アドレスを共有するので、スイッチにまたがって動作することはできません。

質問： 中間ドライバ (BASP) をアップグレードする方法を教えてください。

対応策： [ローカルエリア接続のプロパティ] では中間ドライバをアップグレードできません。Setup インストーラを使用してアップグレードする必要があります。

質問： 仮想アダプタ (チーム) のパフォーマンス統計を確認するにはどうすればよいですか。

対応策： Broadcom Advanced Control Suite 3 で、仮想アダプタの [統計] タブをクリックします。

質問： NLB とチーム化を同時に設定できますか。

対応策： はい。ただし、NLB がマルチキャスト モードで動作する場合に限ります (NLB は MS Cluster Services ではサポートされません)。

質問： バックアップ サーバーとバックアップされるクライアント サーバーの両方をチーム化する必要がありますか。

対応策： バックアップ サーバーは多くのデータをロードするので、常にチーム化してリンク集約とフェイルオーバーを実現する必要があります。ただし、冗長性の十分なネットワークでは、スイッチとバックアップ クライアントの両方をチーム化してフォルト トレランスとリンク集約を実現する必要があります。

質問： バックアップ処理中に、アダプタのチーム化アルゴリズムではバイトレベルまたはセッションレベルのロード バランシングを行いますか。

対応策： アダプタのチーム化を使用すると、データのロード バランシングはセッションレベルでのみ行われ、フレームの順序が狂うことを防ぐためにバイトレベルでは実行されません。アダプタのチーム化のロード バランシングは、EMC PowerPath などの他のストレージのロード バランシング メカニズムと同様には機能しません。

質問： テープ バックアップ ソフトウェアまたはハードウェアには、アダプタのチーム化で動作するための特別な設定が必要ですか。

対応策： テープ ソフトウェアにはチーム化で動作するための特別な設定は必要ありません。テープ バックアップ アプリケーション側からはチーム化は見えません。

質問： 現在使用しているドライバを確認するにはどうすればよいですか。

対応策： すべてのオペレーティング システムにおいて、ドライバのバージョンを確認する最も確実な方法は、ドライバ ファイルを実際に探して、そのプロパティを確認することです。

質問： SLB は、スイッチのフォルト トレランスの設定でスイッチの障害を検出できますか。

対応策： いいえ。SLB で検出できるのは、チーム化されたポートとその直接のリンク パートナーの間で発生するリンク ロスだけです。それ以外のポートのリンク障害を検出できません。

質問： サポートされる最新のドライバはどこで入手できますか。

対応策： Dell サポート (http://support.dell.com) でドライバ パッケージのアップデートとサポート ドキュメントを入手できます。

質問： プライマリ アダプタを元に戻して (フェイルオーバー後のフォールバック) から 30 ～ 50 秒間チームの接続が失われるのはなぜですか。

対応策： フォールバック イベントの間、リンクが復元され、転送状態に移行できると判断するまで、Spanning Tree Protocol はポートにブロックを設定します。STP が原因で通信が途絶えないようにするには、チームに接続されたスイッチ ポート上で Port Fast または Edge Port を有効にする必要があります。

質問： Windows サーバーでアダプタ チームの統計をリアルタイムに監視するには、どうしたらよいでしょうか。

対応策： Broadcom Advanced Control Suite 3 (BACS) を使用して IEEE 802.3 の一般的なカウントとカスタム カウンタを監視できます。

付録 A： イベント ログのメッセージ

Windows システムのイベント ログのメッセージ

ベース ドライバ (物理アダプタ/ミニポート)

中間ドライバ (仮想アダプタ/チーム)

Windows システムのイベント ログのメッセージ

既知のベース ドライバおよび中間ドライバの Broadcom NetXtreme II アダプタに関する Windows システムのイベント ログのステータス メッセージを、表 8 と 表 9 に一覧表示します。Broadcom アダプタ ドライバがロードされると、Windows はシステム イベント ビューアにステータス コードを表示します。こうしたイベント コードには、両方のドライバがロードされたかどうかに応じて (1 つはベース ドライバまたはミニポート ドライバ用、もう 1 つは中間ドライバまたはチーム化ドライバ用)、最大 2 つのクラスがあります。

ベース ドライバ (物理アダプタ/ミニポート)

表 8 に、ベース ドライバでサポートするイベント ログ メッセージを一覧表示し、メッセージの原因を説明します。また、推奨される対応策も示します。

中間ドライバ (仮想アダプタ/チーム)

中間ドライバは、ベース ドライバのバージョンにかかわらず、 BLFM によって特定されます。 表 9 に、中間ドライバでサポートするイベント ログ メッセージを一覧表示し、メッセージの原因を説明します。また、推奨される対応策も示します。

各種制限および免責条項の項目にはすべて目を通してください。

目次のページに戻る