Linux Ethernet Bonding Driver HOWTO 最終更新：2007年11月12日 初期リリース：Thomas Davis 修正、高可用性拡張：2000/10/03-15 : - Willy Tarreau - Constantine Gavrilov - Chad N. Tindel - Janice Girouard - Jay Vosburgh 再構成と更新：2005年 2月 Jay Vosburgh sysfs 情報追加：2006年 4月24日 - Mitch Williams 日本語訳：吉山あきら はじめに ======== Linux bonding ドライバは複数のネットワークインターフェースを単一の論理的な「結合 された」インターフェースに統合する手段を提供します。結合されたインターフェースの 動作はモードに依存します。※一般に言われる事ですが、モードはホットスタンバイまた は負荷分散サービスを提供します。加えて、リンクの保全監視が実現されます。 bonding ドライバは元々 Donald Becker のカーネル 2.0 用 Beowulf パッチから来まし た。これはその後少々変更され、Extreme-Linux と Beowulf のサイトにあるオリジナル のツールは、このバージョンのドライバでは動作しないでしょう。 新しいバージョンのドライバ、更新されたユーザ空間のツール、問い合わせ先は、このファ イルの末尾にあるリンク先を参照して下さい。 【訳注：ユーザ空間 (userspace) はカーネル空間 (kernelspace) との対比語で、前者が シェルやコマンドなどのユーザ／一般プロセスが操作し得る世界、後者がデバイスドラ イバやスケジューラなどのユーザ／一般プロセスが操作できないカーネル内の世界を意 味します】 目次 ==== 1. bonding ドライバのインストール 2. bonding ドライバのオプション 3. bonding デバイスの設定 3.1 sysconfig サポートにおける設定 3.1.1 sysconfig における DHCP の使用 3.1.2 sysconfig における複数の bond の設定 3.2 initscripts サポートにおける設定 3.2.1 initscripts における DHCP の使用 3.2.2 initscripts における複数の bond の設定 3.3 ifenslave による bonding の手動設定 3.3.1 手動での複数の bond の設定 3.4 sysfs 経由の手動での bonding の設定 4. bonding の設定の確認 4.1 bonding の設定 4.2 ネットワークの設定 5. スイッチの設定 6. 802.1q VLAN サポート 7. リンク監視 7.1 ARP 監視操作 7.2 複数の ARP ターゲットの設定 7.3 MII 監視操作 8. 潜在的な問題源 8.1 ルーティングでの冒険 8.2 イーサネットデバイスの名前変更 8.3 miimon による悲惨な遅さ あるいは リンク失敗検知せず 9. SNMP エージェント 10. Promiscuous モード 11. 高可用性用の bonding 設定 11.1 単一スイッチトポロジにおける高可用性 11.2 複数スイッチトポロジにおける高可用性 11.2.1 複数のスイッチトポロジにおける高可用性 bonding モードの選択 11.2.2 複数のスイッチトポロジにおける高可用性リンク監視 12. 最大スループットの為の bonding の設定 12.1 単一スイッチトポロジにおける最大スループット 12.1.1 単一スイッチトポロジにおける最大スループットの bonding モードの選択 12.1.2 単一スイッチトポロジにおける最大スループットのリンク監視 12.2 複数のスイッチトポロジにおける最大スループット 12.2.1 複数のスイッチトポロジにおける最大スループットの bonding モードの選択 12.2.2 複数のスイッチトポロジにおける最大スループットのリンク監視 13. スイッチの挙動問題 13.1 リンク確立とフェールオーバー遅延 13.2 重複した内向きパケット 14. ハードウェア別の考察 14.1 IBM BladeCenter 15. よくある質問 16. 資料とリンク 1. bonding ドライバのインストール ============================ ほとんどの主要なディストリビューションのカーネルは bonding ドライバをモジュール として既に利用可能にして提供されていますし、ifenslave ユーザレベル制御プログラム も利用できるようインストールされて準備されています。もしあなたのディストリビュー ションが上記のとおりでないなら、もしくはbonding ドライバをソースからコンパイル (つまり、kernel.org から入手したメインラインカーネルを設定してインストール)する 必要があるのなら、下記手順の通りに行なわなければならないでしょう。 1.1 bonding ドライバ付きカーネルの設定と構築 -------------------------------------------- 現在のバージョンの bonding ドライバは最新のカーネルソース(http://kernel.org で入 手可能)の drivers/net/bonding サブディレクトリ中にあります。「自分達でやっちゃう」 ほとんどのユーザは kernel.org の最新のカーネルを使いたがるでしょう。 「make menuconfig」(または「make xconfig」、「make config」)でカーネルを設定し、 「Network device support」セクションの「Bonding driver support」を選択して下さい。 bonding ドライバはモジュールにする事をお薦めします。なぜなら、bonding ドライバに パラメータを渡したり、複数の bonding デバイスを設定する今のところ唯一の手段だか らです。 新しいカーネルとモジュールを構築・インストールし、引き続き下記の手順で ifenslave コマンドをインストールします。 1.2 ifenslave 制御ユーティリティのインストール ---------------------------------------------- ifenslave ユーザレベル制御プログラムはカーネルソースツリー (Documentation/networking/ifenslave.c ファイル)に含まれております。一般に、使用 カーネルに適した(同じカーネルソースツリーからの物や、ディストリビューションで提 供されている) ifenslave の使用をお薦めしますが、それでも、より古いカーネルからの ifenslave の実行ファイルも機能するでしょう(但し、その ifenslave バージョンより新 しい機能はサポートされません)。カーネルより新しい ifenslave の実行はサポートされ ていませんし、動くか動かないかも定かではありません。 inenslave をインストールする為に、下記のコマンドを実行して下さい: # gcc -Wall -O -I/usr/src/linux/include ifenslave.c -o ifenslave # cp ifenslave /sbin/ifenslave カーネルソースが「/usr/src/linux」にない場合は、上記の「/usr/src/linux/include」 をカーネルソースの include ディレクトリのフルパスで置き換えて下さい。 既存の /sbin/ifenslave をバックアップするか、(テストや非公式の利用の為に) ifenslave にタグを付けたい(例えば、ifenslave コマンドに /sbin/ifenslave-2.6.10 という名前を付ける)と思うかも知れません。 重要な注意： 「-I」を省略したり、間違ったディレクトリを指定した場合、目的のカーネルと互換性の ない ifenslave が出来てしまうかも知れません。いくつかのディストリビューション(例： Red Hat Linux 7.1 以降)はカーネルソースの include ディレクトリへのシンボリックリ ンク /usr/include/linux を作らなくなりました。 ２つめの重要な注意： sysfs を使用して bonding の設定を行う場合、ifenslave コマンドは使う必要がありま せん。 2. bonding ドライバのオプション =============================== bonding ドライバのオプションは bonding モジュールのロード時にパラメータとして提 供する、または sysfs を介して指定されます。 モジュールオプションは insmod または modprobe コマンドのコマンドライン引数として 与えても良いですが、通常は /etc/modules.conf または /etc/modprobe.conf 設定ファ イルのどちらか、あるいはディストリビューション固有の設定ファイル(これらの幾つか は次のセクションで説明します)で指定されます。 sysfs 用 bonding サポートの詳細は、後述の「sysfs 経由の手動での bonding の設定」 セクションで提供されます。 利用可能な bonding ドライバのパラメータを以下に示します。パラメータが指定されな かった場合は、デフォルト値が使用されます。最初に bond を設定する際は、bonding ド ライバのエラーメッセージを見るために、別のウインドウで「tail -f /var/log/messages」を実行する事をお薦めします。 miimon パラメータまたは arp_interval と arp_ip_target パラメータの指定は必須です。 指定しなければ、リンク失敗※の間に深刻なネットワークの性能低下が発生します。ほと んどのデバイスは少なくとも miimon をサポートしているので、こちらを使用しない理由 は本当にありません。 ※訳注：ネットワークインターフェース間、あるいはネットワークインターフェースと HUB 間 の通信が断絶している状態 テキスト値によるオプションはテキスト名か(後方互換性の為)オプション値のどちらかを 受け付けます。例えば、「mode=802.3ad」と「mode=4」は同じモードをセットします。 パラメータは以下の通り： arp_interval ARP リンク監視頻度をミリ秒単位で指定します。 ARP 監視はスレーブデバイスが最近通信を送受信したかどうかを検出する為に、 スレーブデバイスを定期的にチェックする事により機能します(厳密な基準は bonding モード、スレーブデバイスの状態に依存します)。arp_ip_target オプ ションによって指定されたアドレスへの ARP プローブによって定期的な通信が 発生します。 この動作は後述の arp_validate オプションで変更可能です。 ARP 監視をイーサチャネル互換モード(モード 0 と 2)で使用した場合、スイッ チング HUB は全リンクを渡って均等にパケットを分散するモードに設定されな ければなりません。スイッチが XOR 形式でパケットを配信するよう設定された 場合、ARP ターゲットからの応答は全て同じリンク経由で受信され、他のチーム メンバが受信できない原因になります。ARP 監視は miimon と一緒に使用すべき ではありません。0 値は ARP 監視を無効化します。既定値は 0 です。 arp_ip_target arp_interval が 0 より大きい場合、ARP 監視対象として使用する IP アドレス を指定します。これらは リンクの接続状態を判断する為に送られる ARP リクエ ストのターゲットです。これらの値は ddd.ddd.ddd.ddd フォーマットで指定し ます。複数の IP アドレスをコンマで区切りながら指定すべきです。ARP 監視が 機能するためには、少なくても 1 つの IP アドレスが与えられなければなりま せん。指定可能なターゲットの最大数は 16 です。既定値では IP アドレスが指 定されていません。 arp_validate active-backup モードで ARP 問い合わせと応答が検証されるかどうかを指定し ます。これは ARP 監視に対し、入ってくる ARP 要求と応答を検証し、適切な ARP トラフィックが受信されたスレーブデバイスのみがリンクアップしていると 判断するように設定します。 設定可能な値は： none または 0 検証しません。これが既定値です。 active または 1 アクティブなスレーブのみ検証を実行します。 backup または 2 バックアップのスレーブのみ検証を実行します。 all または 3 全てのスレーブに対して検証を実行します。 active-slave において、この検証では arp_ip_target の１つで生成されたもの であるかを確認する為に ARP 応答をチェックします。典型的にバックアップの スレーブはこれらの応答を受信しないので、バックアップのスレーブの為に実行 される検証は ARP 要求をアクティブなスレーブから送信します。バックアップ スレーブが ARP 要求を受け取らない状況で、いくつかのスイッチまたはネット ワーク設定が結果を出す事が可能です。※このような状況下では、バックアップ スレーブの検証は無効化すべきです。 このオプションは共通のスイッチを越えて複数の bonding ホストが 1 つまたは 複数のターゲットに同時に ARP を出しているネットワーク設定に便利です。も し (スイッチ自体の障害ではなく) スイッチとターゲット間のリンクが障害にな れば、複数の bonding インスタンスにより生じたプローブトラフィックにより 生じたプローブ通信によって、リンクがまだアップしているように標準の ARP 監視が誤認識します。arp_validate オプションの使用は、ARP 監視が自身の bonding インスタンスと関連付けられた ARP 要求および応答だけを考慮する事 でこれを解決します。 このオプションは bonding バージョン 3.1.0※ で追加されました。 ※訳注：Red Hat Enterprise Linux 5.1 の bonding ドライバのバージョンは 3.1.2 です。 downdelay リンク失敗が検出された後、スレーブを無効にする前に待つ時間を指定する(ミ リ秒単位)。このオプションは miimon リンク監視でのみ有効です。 downdelay 値は miimon 値の倍数値であるべきす。※倍数値でない場合、最も近い倍数値に 切り捨てられます。デフォルト値は 0 です。 fail_over_mac active-backup モードが、全スレーブに同じ MAC アドレスを設定すべき(旧来の 挙動)か、(有効時)アクティブなインターフェースの変更時に bond の MAC アド レスを変更(つまり、MAC アドレス自体をフェールオーバ)すべきかのどちらかを 指定します。 MAC フェールオーバは、未だに MAC アドレスを変更できないデバイス、あるい は(ARP 監視のインターフェースで)自身の送信元 MAC アドレスを持つ受信ブロー ドキャストを拒否するデバイスで便利です。 フェールオーバ MAC の欠点は、伝統的な方法による１スイッチまたはスイッチ 群の更新(スイッチが自身のテーブルを更新する為に受信トラフィックを傍受し ている場合、ARP 通信だけではなく任意の通信でしばしば発生する)に対して、 ネットワーク上の全デバイスが gratuitous ARP を介して更新しなければならな い事です。(スイッチが自身のテーブルを更新する為に受信トラフィックを傍受 している場合、ARP 通信だけではなく任意の通信でしばしば発生する) gratuitous ARP が失われた場合、通信は分断するかも知れません。 フェールオーバ MAC が MII 監視を用いた接続で使用される際、実際に送受信が 可能になる前にリンクアップしたと断言するデバイスは、特に gratuitous ARP の失敗が推測され、適切な updelay 設定が必要になります。 0 値はフェールオーバ MAC を無効にし、これがデフォルトです。1 値はフェー ルオーバ MAC を有効にします。最初に加えられたスレーブが MAC アドレスを変 更できなかった場合、このオプションは自動的に有効になります。bond 中にス レーブが１つもない時、このオプションは sysfs 経由でのみ修正する事が出来 ます。 このオプションは bonding バージョン 3.2.0 で追加されました。 lacp_rate 802.3ad モードにおける LACPDU パケットを送出するために我々のリンク相手に 問い合わせる頻度を指定するオプション。設定可能な値は: slow または 0 30 秒毎に LACPDU 送出をパートナーに要求する。 fast または 1 1 秒毎に LACPDU 送出をパートナーに要求する。 デフォルトは slow です。 max_bonds bonding ドライバのインスタンス用に作成する bonding デバイスの数を指定し ます。例えば、max_bonds が 3 で、bonding ドライバがまだロードされていな い場合は、bond0、bond1、bond2 が作成されます。デフォルト値は 1 です。 miimon MII リンクの監視頻度をミリ秒単位で指定します。これはリンク障害の為にどの 位の頻度で各スレーブのリンク状態を点検するかを決定します。0 は MII リン ク監視を無効にします。100 は最初に設定するのに良い値です。後述の use_carrier オプションは、リンク状態をどのように判断するかに影響します。 その他の情報については高可用性の章を見て下さい。デフォルト値は 0 です。 mode bonding ポリシーの１つを設定します。デフォルトは balance-rr (ラウンドロ ビン)です。設定可能な値は： balance-rr または 0 ラウンドロビンポリシー：利用可能なスレーブ群の最初から最後までの 一連の順番でパケットを送出します。このモードは負荷分散と耐障害性 を提供します。 active-backup または 1 アクティブバックアップポリシー：bond 中の１スレーブのみアクティ ブです。別のスレーブはアクティブなスレーブが障害になった場合のみ アクティブになります。ネットワークスイッチの混乱を避ける為、bond の MAC アドレスは外部からは単一のポート(ネットワークアダプタ)に 見えます。 bonding バージョン 2.6.2※ 以降、active-backup モードでフェイル オーバが発生した場合、bonding は新しくアクティブになったスレーブ 上で１つまたはそれ以上の gratuitous (無意味な) ARP を発行します。 bonding マスタインターフェースとその上に設定された各 VLAN インター フェースの為に 1 つの gratuitous ARP が発行され、そのインターフェー スが少なくても 1 つの設定済み IP アドレスを持つようになります。 VLAN インターフェース宛の複数の gratuitous ARP は適切な VLAN ID でタグ付けされています。 ※訳注：Red Hat Enterprise Linux 4 Update 4、CentOS 4.4 以降はバー ジョン 2.6.3 以降の bonding ドライバを使用しています。 このモードは耐障害性を提供します。primary オプション(後述)はこの モードの挙動に影響します。 balance-xor または 2 XOR(排他論理和)ポリシー：選択された転送ハッシュポリシーに基づい て転送します。デフォルトのポリシーは単純です [(送信元の MAC アド レスと送信先の MAC アドレスの排他論理和)をスレーブカウントで割っ た余り]。別の転送ポリシーは xmit_hash_policy オプション(後述)経 由で選択できます。 このモードは負荷分散と耐障害性を提供します。 broadcast または 3 ブロードキャストポリシー：全スレーブインターフェースから全てのパ ケットを送出します。このモードは耐障害性を提供します。 802.3ad または 4 IEEE 802.3ad 動的リンク集合です。同速度および同じ二重設定を共有 する集合グループを作成します。802.3ad 仕様に従い、アクティブな集 合の全スレーブを利用します。 外への通信のスレーブ選択が送信ハッシュポリシーにしたがって行われ ます。このポリシーはデフォルトの単純 XOR ポリシーから後述の xmit_hash_policy オプションによって変更できます。全ての送信ポリ シーが 802.3ad 準拠(特に 802.3ad 標準のセクション 43.2.4 で要求 されたパケットの順番ミスに関して)である訳ではない事に注意して下 さい。異なるピア実装は非準拠の変容許容性があります。 前提条件： 1. 各スレーブの速度と全／半二重を回復するためのベースドライバに おける Ethtool サポート 2. IEEE 802.3ad 動的リンクアグリゲーションをサポートするスイッチ ほとんどのスイッチは 802.3ad モードを有効にする為の何らかの設定 が必要になります。 balance-tlb または 5 適応転送負荷分散: 特別なスイッチサポートを必要としないチャネル結 合です。送信は各スレーブの現在の負荷(速度に関連して計算されます) に従って分散されます。受信は現在のスレーブによって行われます。受 信しているスレーブが障害を起こした場合、別のスレーブが障害した受 信スレーブの MAC アドレスを引き継ぎます。 前提条件: 各スレーブの通信速度を得る為のベースドライバの ethtool サポート balance-alb または 6 適応負荷分散: IPV4 通信の為の balance-tlb と受信負荷分散 (rlb) を含み、特別なスイッチのサポートを要求しません。受信負荷分散は ARP ネゴシエーションにより実現されます。bonding ドライバはローカ ルシステムによって送信された ARP 応答の送信を出口で遮り、bond 内 のスレーブの１つの単独のハードウェアアドレスで (ARP 応答の）送信 元ハードウェアアドレスを上書きします。これにより、このサーバへの 異なる通信相手が異なるハードウェアアドレスを使うようになります。 サーバによって作成された接続からの受信トラフィックも負荷分散され ます。ローカル システムが ARP要求を送信する場合、bonding ドライ バは ARP パケットから IP 情報をコピーして保存します。通信相手か ら ARP 応答が到着する場合、そのハードウェアアドレスは復元され、 bonding ドライバは bond 中のスレーブの１つを割り当てて、この通信 相手に ARP 応答を作成します。バランス化の為の ARP ネゴシエーショ ン使用の問題の結果は ARP 要求が毎回ブロードキャストされる際に ARP 要求が bond のハードウェアアドレスを使用するという事です。そ れゆえ、通信相手は bond のハードウェアアドレスを学習し、受信の負 荷分散は現在のスレーブを失敗させてしまいます。これは、通信を再分 散するようなハードウェアアドレスをそれら各々に割り当てられた更新 (ARP 応答)を全ての通信相手に送信する事で扱われます。新しいスレー ブが bond に加わった場合や非アクティブなスレーブが再度アクティブ 化された場合にも、受信トラフィックが再分散されます。受信負荷は bond 中の最高速のスレーブのグループ間で逐次的(ラウンドロビン)に 分散されます。 リンクが再接続されるか新しいスレーブが bond に加わる場合、各クラ イアントに向けて選択された MAC アドレスを付けて ARP 応答を発信す る事で、bond 中の全アクティブスレーブ間で受信トラフィックが再分 散されます。updelay パラメータ(下記に詳細)をスイッチの転送遅延と 同じかそれ以上に設定しなければなりません。これにより、通信相手に 送られた ARP 応答がスイッチにブロックされなくなります。 前提条件: 1. 各スレーブの速度を得るための、ベースドライバにおける Ethtool サポート 2. オープン中、デバイスのハードウェアアドレスが設定される為のベー スドライバサポート。これは、bond 中の各スレーブが単一のハードウェ アアドレスを持つ間、チーム中の１つのスレーブが常に bond のハード ウェアアドレス(curr_active_slave)になるようにする為に必要です。 curr_active_slave が失敗した場合、そのハードウェアアドレスは新し く選択された curr_active_slave で置き換えられます。 primary どのスレーブが最初のデバイスかを指定する文字列(eth0、eth2、他)。指定され たデバイスは、それが利用可能な場合は常にアクティブなスレーブになります。 最初のデバイスがオフラインになった時のみ、別のデバイスが選択されます。こ のオプションは、１つのスレーブが別のものよりも優先される場合、例えば、１ スレーブが別スレーブより速度が速い場合に便利です。 primary オプションは active-backup モードでのみ有効です。 updelay リンク復旧が検知された後、スレーブが有効になる前に待つ時間をミリセカンド で指定します。このオプションは miimon リンク監視でのみ有効です。updelay 値は miimon 値の倍数であるべきです。※倍数でない場合、最も近い倍数に丸め られます。デフォルト値は 0 です。 use_carrier リンク状態を検知する為に、miimon が MII または ETHTOOL の ioctl を使うか、 または netif_carrier_ok() を使うかどうかを指定します。MII または ETHTOOL ioctl は効率が悪く、カーネル内では推奨されていない呼出シーケンスを利用し ます。netif_carrier_ok() は状態を netif_carrier_on/off で管理する為に、 デバイスドライバに頼っています。※これを書いている時点では、ほとんど(で も全てではない)のデバイスドライバがこの機能をサポートしています。 リンクがダウンしているべき時にリンクアップしていると bonding が主張する 場合、ネットワークデバイスドライバは netif_carrier_on/off をサポートして いないかも知れません。netif_carrier のデフォルト状態は "carrier on" です ので、ドライバが netif_carrier をサポートしていない場合、常にリンクアッ プしているようにドライバが示します。この場合、use_carrier を 0 に設定す る事で、bonding のリンク状態の検知方法を MII/ETHTOOL ioctl に戻せます。 設定値 1 は netif_carrier_ok() の使用を有効にし、設定値 0 は非推奨の MII/ETHTOOL ioctl を使用します。デフォルト値は 1 です。 xmit_hash_policy balance-xor または 802.3ad モードでのスレーブ選択に使用する転送ハッシュ ポリシーを選択します。利用可能な値は: layer2 ハッシュの生成にハードウェアの MAC アドレスの排他論理和を使用し ます。この計算式は、 (送信元 MAC と送信先 MAC の排他論理和) をスレーブ数で割った余り このアルゴリズムは、特定のネットワーク通信相手への全トラフィック を同じスレーブ上に置きます。 このアルゴリズムは 802.3ad 準拠です。 layer2+3 このポリシーはハッシュの生成に layer2 と layer3 プロトコル情報の 組合せを使用します。 ハッシュの生成にハードウェア MAC アドレスと IP アドレスの論理排 他和を使用します。この式は (((送信元 IP と送信先 IP の論理排他和)と 0xfff の積)と (送信元 MAC と送信先 MAC の排他論理和))の論理排他和を スレーブ数で割った余り このアルゴリズムは特定のネットワークピアへの全通信を同じスレーブ 上に配置します。非 IP 通信では、この式は layer2 転送ハッシュポリ シーと同じになります。 このポリシーは、特にほとんどの目的地への到達の為に layer3 ゲート ウェイデバイスが要求される環境において、layer2 単独より平滑化さ れた通信分散の提供を意図しています。 このアルゴリズムは 802.3ad 準拠です。 layer3+4 このポリシーは(利用可能な場合)ハッシュの生成に上位レイヤのプロト コルの情報を使用します。これは特定のネットワーク通信相手への通信 のために、複数のスレーブで順繰りにする事を許可しますが、単一接続 は複数のスレーブに順繰りされません。 断片化していない TCP と UDP パケットの為の式は ((送信元と送信先のポート番号の排他論理和) と ((送信元と送信先の IP アドレスの排他論理和) と 0xffff の論理積) の排他論理和) をスレーブ数で割った余り 断片化した TCP または UDP パケットとその他全ての IP プロトコル通 信には、送信元と送信先のポート情報が省略されます。非 IP 通信には、 この式は layer2 送信ハッシュポリシと同じです。 このポリシーは、ある種のスイッチ、Foundry と IBM の製品と同様、 特に PFC2 付きの Cisco のスイッチの挙動を真似するように意図され ています。 このアルゴリズムは完全な 802.3ad 準拠ではありません。フラグメン トしたパケットとしていないパケットの両方を含む単一の TCP または UDP 通信では、パケットが２つのインターフェースを跨いで互い違いに なるでしょう。これは順番通りでない配送の結果になるかも知れません。 ほとんどの通信タイプではこのようなことにはならないでしょう。なぜ なら TCP は稀にしか通信を断片化せず、ほとんどの UDP 通信は長話に 含まれないからです。802.3ad の他の実装はこの非互換を我慢するかも 知れませんし、我慢しないかもしれません。 デフォルト値は layer2 です。このオプションは bonding バージョン 2.6.3 で 追加されました。より前のバージョンの bonding ではこのパラメータは存在せ ず、layer2 ポリシーが唯一のポリシーでした。layer2+3 値は bonding バージョ ン 3.2.2 で追加されました。 3. Bonding デバイスの設定 ========================= ディストリビューションのネットワーク初期化スクリプトか、ifenslave または sysfs インターフェースのどちらかを手動で使用して、bonding を設定する事ができます。一般 に、ディストリビューションはネットワーク初期化スクリプトの為の２つのパッケージ (initscripts または sysconfig)のうちの１つを使用します。これらのパッケージの最近 のバージョンでは bonding をサポートしていますが、一方で古いバージョンではサポー トしていません。 最初に、各ディストリビューションで bonding の完全または部分サポート付きバージョ ンの initscripts と sysconfig を使用して bonding を設定するオプションを説明し、 それから、ネットワーク初期化スクリプト(つまり、古いバージョンの initscripts また は sysconfig)からのサポートなしに bonding を有効にする情報を提供します。 あなたのディストリビューションが sysconfig または initscripts のどちらを使ってい るか不明な場合、あるいはそれが十分に新しいか知らない場合、心配する事はありません。 この判別は実に率直です。 最初に、このコマンドを実行します： $ rpm -qf /sbin/ifup これは、「initscripts」あるいは「sysconfig」のどちらかで始まり、後に数字が続く１ 行のテキストで応答します。これがお使いのネットワーク初期化スクリプトを提供してい るパッケージです。 次に、このインストールされたものが bonding をサポートするかどうかを調べる為に、 このコマンドを実行します： $ grep ifenslave /sbin/ifup これでいくらかのマッチが返されれば、その initscripts または sysconfig は bonding をサポートしています。 3.1 sysconfig サポートにおける設定 ---------------------------------- このセクションは、bonding をサポートした sysconfig のバージョンを使ったディスト リビューション(例：SuSE Linux Enterprise Server 9)に適用します。 SuSE SLES 9 のネットワーク設定システムは bonding をサポートしますが、しかしなが ら、これを書いている時点では、 YaST システム設定フロントエンドは bonding デバイ スを動作させる機能を何も提供していません。しかしながら、後述のように、bonding デ バイスを手動で管理する事が出来ます。 最初に、これらがまだ設定されていない場合、スレーブデバイスを設定します。SLES9 で は、これは yast2 sysconfig 設定ユーティリティを実行する事で実に簡単に行われます。 ゴールは各スレーブデバイス毎に１つの ifcfg-id ファイルを作成する事です。これを実 現する一番簡単な方法は、各デバイスを DHCP で設定する事です(これは、作成された ifcfg-id ファイルを得るためだけです。※DHCP のいくつかの問題については下記を参照 して下さい)。各デバイスの設定ファイルの名前はこのような形式になります： ifcfg-id-xx:xx:xx:xx:xx:xx 「xx」部分は、デバイスの常設 MAC アドレスの 16 進数で置換されます。 一旦 ifcfg-id-xx:xx:xx:xx:xx:xx ファイルのセットが作成されたら、スレーブデバイス 用に設定ファイルを編集する必要があります(MAC アドレスはスレーブデバイスのものに 一致します)。編集の前、このファイルは複数の行を含み、このような感じに見えるでしょ う。 BOOTPROTO='dhcp' STARTMODE='on' USERCTL='no' UNIQUE='XNzu.WeZGOGF+4wE' _nm_name='bus-pci-0001:61:01.0' BOOTPROTO 行と STARTMODE 行を次のように変更します。 BOOTPROTO='none' STARTMODE='off' UNIQUE 行や _nm_name 行を変更してはなりません。他の行(USERCTL 等)は削除してくだ さい。 一旦 ifcfg-id-xx:xx:xx:xx:xx:xx ファイルを修正したら、bonding デバイス自身の設定 ファイルを作成する番です。このファイルは ifcfg-bondX という名前で、X は 作成する bonding デバイスの番号で、0 からはじまります。このようなファイルの１番めは ifcfg-bond0、２番めは ifcfg-bond1、等々。sysconfig ネットワーク設定システムは複 数の bonding インスタンスを正しくスタートします。 ifcfg-bondX ファイルの中身は次のようなものです： BOOTPROTO="static" BROADCAST="10.0.2.255" IPADDR="10.0.2.10" NETMASK="255.255.0.0" NETWORK="10.0.2.0" REMOTE_IPADDR="" STARTMODE="onboot" BONDING_MASTER="yes" BONDING_MODULE_OPTS="mode=active-backup miimon=100" BONDING_SLAVE0="eth0" BONDING_SLAVE1="bus-pci-0000:06:08.1" サンプルの BROADCAST、IPADDR、NETMASK、NETWORK 値をあなたのネットワークの適切な 値で置き換えて下さい。 STARTMODE はデバイスがいつオンラインになるかを指定します。可能な値は： onboot: デバイスは起動時に開始されます。よく分からなければ、多分これがあ なたの希望するものです。 manual: デバイスは手動で ifup が呼ばれた時のみ開始されます。何らかの理由 で、起動時に自動的に bonding デバイスを開始したくない場合にこの 方法で設定できます。 hotplug: デバイスは hotplug イベントによって開始されます。これは bonding デバイスにとって妥当な選択ではありません。 off または ignore: デバイス設定は無視されます。 BONDING_MASTER='yes' 行は、デバイスが bonding マスターデバイスである事を示してい ます。唯一の有効な値は「yes」です。 BONDING_MODULE_OPTS の内容は、このデバイスの bonding モジュールインスタンスに提 供されます。bonding モード、リンク監視等々のオプションをここで指定します。 max_bonds bonding パラメータを含めないでください。※これは、複数の bonding デバ イスがある場合、設定システムを混乱させます。 最後に、各スレーブ毎に「BONDING_SLAVEn="スレーブデバイス"」を１つ付与します。「n」 の箇所は各スレーブ毎に 1つずつ増加する値です。「スレーブデバイス」は「eth0」等の インターフェース名か、ネットワークデバイスのデバイス指示子のどちらかです。インター フェース名は見つけ易いですが、ethN 名は起動時の変更(例えば、一連のうち初期化の早 いデバイスが失敗する)が問題になります。デバイス指示子(上記の例では bus-pci-0000:06:08.1)は物理的なネットワークデバイスを表わし、そのデバイスのバス の位置が変更(例えば、１つの PCI スロットから別のスロットに移動される)されない限 り変わりません。上記の例では、デモの目的で各タイプの1つを使っています。※ほとん どの設定は全てのスレーブデバイスにどちらか1つを選択します。 全ての設定ファイルが修正または作成された時、設定変更を反映する為にネットワークを 再起動しないといけません。これは、次を介して実行できます。 # /etc/init.d/network restart ネットワーク制御スクリプト(/sbin/ifdown)はネットワーク停止処理の一部として bonding モジュールを削除するので、例えばモジュールのパラメータが変更された場合に 手動でモジュールを削除する必要がない事に注意して下さい。 また、この文章の執筆時では、YaST/YaST2 は bonding デバイスを管理しません(これら はネットワークデバイスの一覧で bonding インターフェースを表示しません)。bonding の設定変更の為に、手動で設定ファイルを編集する必要があります。 追加的な一般オプションと ifcfg ファイルフォーマットの詳細は、ifcfg テンプレート ファイルの例で見られます： /etc/sysconfig/network/ifcfg.template このテンプレートは上記で説明した様々な BONDING_ 設定のドキュメントではありません が、その他のオプションの多くを説明している事に注意して下さい。 3.1.1 sysconfig を用いた DHCP の使用 ------------------------------------ sysconfig 下では、BOOTPROTO='dhcp' によるデバイスの設定によって IP アドレス情報 の為に DHCP 問い合わせが行われます。執筆時点では、このオプションは bonding デバ イスでは機能しません。※スクリプトはスレーブデバイスのいずれかを加える前に DHCP からデバイスのアドレスを取得しようとします。アクティブなスレーブがないと、DHCP リクエストはネットワークに送信されません。 3.1.2 sysconfig における複数の bond の設定 ------------------------------------------ sysconfig ネットワーク初期化システムは複数の bonding デバイスの取扱いが可能です。 必要なのは、(上記で説明した通り)各 bonding インスタンスの為に適切に設定された ifcfg-bondX ファイルがある事だけです。sysconfig が混乱するので、どの bonding イ ンスタンスにも「max_bonds」パラメータを指定しないで下さい。個々のパラメータを持 つ複数の bonding デバイスが必要な場合は、複数の ifcfg-bondX ファイルを作成して下 さい。 sysconfig スクリプトが ifcfg-bondX ファイル中に bonding モジュールオプションを提 供するので、これらのオプションをシステムの /etc/modules.conf あるいは /etc/modprobe.conf 設定ファイルに追加する必要はありません。 3.2 initscripts サポートにおける設定 ------------------------------------ このセクションは、bonding サポートがある initscripts の最近のバージョンを使用し たディストリビューション(例：Red Hat Linux 9 または Red Hat Enterprise Linux バー ジョン 3 以降、Fedora、他)に適用されます。これらのシステムでは、ネットワーク初期 化スクリプトは bonding をある程度理解し、bonding デバイス制御の為に設定する事が できます。initscript パッケージのより古いバージョンは bonding の為のより低いレベ ルのサポートしかない事に注意して下さい。※この点は追って該当する箇所に記述します。 これらのディストリビューションは、ethX デバイスが IP アドレスをもって設定されな い限り、自動的にはネットワークアダプタドライバをロードしません。この制約の為、ユー ザは bondX リンクのメンバになる全ての物理アダプタに ネットワークスクリプトファイ ルを手動で設定する必要があります。ネットワークスクリプトファイルは以下のディレク トリに配置されます： /etc/sysconfig/network-scripts ファイル名は「ifcfg-eth」で始まり、そのアダプタの物理アダプタ番号で終わらなけれ ばなりません。例えば、eth0 用のスクリプトは /etc/sysconfig/network-scripts/ifcfg-eth0 という名前になります。そのファイル中に 次のテキストを置きます。 DEVICE=eth0 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none DEVICE= 行は全ての ethX デバイスで異なり、ファイル名に一致しなければなりません。 つまり、ifcfg-eth1 は DEVICE=eth1 のデバイス行がなければなりません。MASTER= 行の 設定も、あなたの bond に付けた最終的な bonding インターフェース名に依存します。 他のネットワークデバイスでも、これらは通常 0 からはじまり、各デバイス毎に 1 ずつ 増えていきます。つまり、最初の bonding インスタンスは bond0、２番めは bond1、等々 となります。 次に、bond のネットワークスクリプトを作成します。このスクリプトのファイル名は /etc/sysconfig/network-scripts/ifcfg-bondX (X は bond の番号) になります。bond0 用のファイルは「ifcfg-bond0」という名前、bond1 用は「ifcfg-bond1」という名前、 等々…になります。このファイルの内に、次のテキストを配置します： DEVICE=bond0 IPADDR=192.168.1.1 NETMASK=255.255.255.0 NETWORK=192.168.1.0 BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no ネットワーク固有行(IPADDR、NETMASK、NETWORK、BROADCAST)をあなたのネットワーク設 定に一致するように確実に変更して下さい。 Fedora 7 や Red Hat Enterprise Linux バージョン 5 (または以降)で見られるような initscripts の最新バージョンでは、ifcfg-bond0 ファイル中で bonding オプションを 指定する事が可能で、実際、むしろ好ましいです。例えば、このフォーマットの行 BONDING_OPTS="mode=active-backup arp_interval=60 arp_ip_target=+192.168.1.254" は指定されたオプションで bond を設定します。BONDING_OPTS 中で指定されたオプショ ンは、arp_ip_target フィールドを除いて bonding モジュールパラメータと同一です。 各ターゲットは個別のオプションとして含めるべきで、問い合わせられるターゲットのリ ストに加える事を示す為に、'+' を先に付けるべきです。例えば、 arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2 は複数のターゲットを指定する為の適切な書式です。BONDING_OPTS を介したオプション の指定時、/etc/modules.conf または /etc/modprobe.conf を編集する必要はありません。 BONDING_OPTS をサポートしない initscripts のより古いバージョンでは、bond0 インター フェースが起動した際、あなたが希望するオプションをもって bonding モジュールがロー ドされるよう、/etc/modules.conf(または /etc/modprobe.conf。ディストリビューショ ンに依存します)を編集する必要があります。/etc/modules.conf (あるいは modprobe.conf) 中の次の行は bonding モジュールをロードし、そのオプションを選択し ます： alias bond0 bonding options bond0 mode=balance-alb miimon=100 サンプルパラメータをあなたの設定に適切なオプションのセットで置き換えて下さい。 最後に、root で「/etc/rc.d/init.d/network restart」を実行してください。これでネッ トワークサブシステムを再起動し、bond リンクが起動して稼働します。 3.2.1 initscripts における DHCP の使用 -------------------------------------- initscripts の最近のバージョン(Fedora Core 3 と Red Hat Enterprise Linux 4、ある いは以降のバージョンは動作が報告されています)は DHCP を介して bonding デバイスに IP 情報を割り当てる為のサポートがあります。 DHCP 用に binding を設定するために、「BOOTPROTO=none」を「BOOTPROTO=dhcp」で置き 換える以外は上記で説明したように設定し、「TYPE=Bonding」を含む行を追加します。 TYPE 値は大小文字を区別する事に注意して下さい。 3.2.2 initscripts における複数の bond の設定 -------------------------------------------- Fedora 7 と Red Hat Enterprise Linux 5 に含まれている initscript パッケージは、 単に ifcfg-bondX (X は bond の番号)中で適切な BONDING_OPTS= を指定する事で複数の bonding インターフェースをサポートしています。このサポートはカーネル中の sysfs サポートと bonding ドライババージョン 3.0.0 以降が必要です。他の環境では、この複 数の bonding インターフェースの指定方法をサポートしていません。※その場合は、後 述の「手動での複数の bond の設定」章を参照して下さい。 3.3 ifenslave による bonding の手動設定 ----------------------------------------- このセクションは、ネットワーク初期化スクリプト(sysconfig 又は initscripts パッケー ジ)に bonding 関連の理解がないディストリビューションに適応します。このようなディ ストリビューションの１つは SuSE Linux Enterprise Server バージョン 8 です。 これらのシステムでの一般的な方法は、bonding モジュールパラメータを /etc/modules.conf または /etc/modprobe.conf (インストールしたディストリビューショ ンに適切に)に配置し、それから modprobe あるいは ifenslave コマンドをシステムの全 般的な init スクリプトに記述する事です。全般的な init スクリプトの名前は異なりま す。※sysconfig では /etc/init.d/boot.local、initscripts では /etc/rc.d/rc.local です。 例えば、2 つの e100 デバイス(eth0、eth1 と仮定します)の簡単な bond を作成し、再 起動を経ても持続するようにしたい場合、適切なファイル(/etc/init.d/boot.local ある いは /etc/rc.d/rc.local)を編集し、次を追加します： modprobe bonding mode=balance-alb miimon=100 modprobe e100 ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up ifenslave bond0 eth0 ifenslave bond0 eth1 この例の bonding モジュールパラメータと bond0 ネットワーク設定(IP アドレス、ネッ トマスク等)をあなたの設定に適切な値で置き換えて下さい。 あいにく、この方法は bond デバイスでの ifup と ifdown スクリプトのサポートが提供 されないでしょう。bonding 設定をリロードする為に、初期化スクリプトを実行する必要 があります。例えば、 # /etc/init.d/boot.local または # /etc/rc.d/rc.local このようなケースで、bonding 設定の初期化だけを行う個別スクリプトを作成し、その個 別スクリプトを boot.local 内から呼び出す事もできます。これで、全般的な init スク リプト全体を再実行せずに、bonding を有効にする事ができます。 bonding デバイスを停止する為に、最初に bonding デバイス自体をダウンさせ、次に適 切なデバイスドライバモジュールを削除する必要があります。上記の例では、次の通り実 行できます： # ifconfig bond0 down # rmmod bonding # rmmod e100 先程と同様、便宜の為に、これらのコマンドをもつスクリプトを作成する事もできます。 3.3.1 手動での複数の bond の設定 -------------------------------- この章では、ネットワーク初期化スクリプトが複数の bond の設定用をサポートしていな いシステムの為に、異なるオプションを持つ複数の bonding デバイスの設定についての 情報を含んでいます。 複数の bonding デバイスを要求するが、全て同じオプションを持つ場合、上記の 「max_bonds」モジュールパラメータを使用しても構いません。 異なるオプションを持つ複数の bonding デバイスを作成する為には、sysfs でエクスポー トされた bonding パラメータを使用する方が好ましいです(後述の章で記述)。 sysfs サポートのない bonding のバージョンでは、異なるオプションを持つ bonding の 複数インスタンスを提供する唯一の方法は bonding ドライバを複数回ロードする事です。 現在のバージョンの sysconfig ネットワーク初期化スクリプトはこれを自動的に扱う事 に注意して下さい。※あなたのディストリビューションがこれらのスクリプトを使用する 場合、特別なアクションは必要ありません。ネットワーク初期化スクリプトについてよく 分からない場合、先述の「bonding デバイスの設定」を参照して下さい。 複数のモジュールインスタンスをロードする場合、各インスタンスに異なる名前を指定す る必要があります(モジュールロードシステムは、同じモジュールの複数インスタンスで さえ、各々ロードされるモジュールに個別の名前がある事を要求します)。これは、 /etc/modprobe.conf に bonding オプションを複数セット提供する事で実現されます。例 えば： alias bond0 bonding options bond0 -o bond0 mode=balance-rr miimon=100 alias bond1 bonding options bond1 -o bond1 mode=balance-alb miimon=50 は bonding モジュールを２回ロードします。１つめのインスタンスは bond0 という名前 で、balance-rr モード、miimon=100 の bond0 デバイスを作成します。２つめのインス タンスは bond1 という名前で、balance-alb モード、miimon=50 の bond1 デバイスを作 成します。 幾つかの環境(典型的には古いディストリビューション)では、上記は動作せず、２つめの bonding インスタンスにこのオプションが決して現れません。このケースでは、２つめの オプション行を次のように代えます： install bond1 /sbin/modprobe --ignore-install bonding -o bond1 \ mode=balance-alb miimon=50 これは、個々の連続するインスタンス用に、bond1 の場所に新しく個別な名前を指定しな がら、何回でも繰り返す事ができます。 いくつかの Red Hat 提供のカーネルは、モジュールのロード時に(「-o bond1」の部分で) 名前を変えられないと言われています。modprobe にこのオプションを渡す試みは 「Operation not permitted」エラーを生じます。これはいくつかの Fedora Core カーネ ルで報告され、RHEL 4 でも同様に見られます。この問題が見られるカーネルでは、異な るパラメータを持つ複数の bond を設定する事は不可能です(カーネルが古く、また sysfs サポートがないため)。 3.4 sysfs 経由の bonding の手動設定 ------------------------------------- バージョン 3.0.0 から、チャネル結合は sysfs インターフェースを介して設定できます。 このインターフェースは、モジュールのアンロードなしにシステム中の全 bond の動的な 設定が出来ます。これはまた、実行中に bond の追加と削除が可能です。ifenslave は最 早必要ありませんが、それでもまだサポートされています。 sysfs インターフェースの使用により、モジュールの再ロードの必要なしに異なる設定を 持つ複数の bond を使用できます。これはまた、カーネル組み込みで bonding がコンパ イルされた際も、複数の異なる設定の bond を使用できます。 この方法で bonding を設定する為には、マウントされた sysfs ファイルシステムがなけ ればなりません。このドキュメントの例は、sysfs の標準的なマウントポイント、つまり /sys を使用している事を前提にしています。あなたの sysfs ファイルシステムが別の場 所にマウントされている場合、適宜例示のパスを合わせる必要があります。 bond の作成と破壊 ----------------- 新しい bond「foo」の追加： # echo +foo > /sys/class/net/bonding_masters 既存の bond「bar」の削除： # echo -bar > /sys/class/net/bonding_masters 既存の全 bond の表示： # cat /sys/class/net/bonding_masters 注意：sysfs ファイルの 4KB のサイズ制限により、数百以上の bond がある場合にこの リストは切り詰められるかも知れません。通常の操作状況では、これはほとんど起こらな いでしょう。 スレーブの追加と削除 -------------------- インターフェースは /sys/class/net//bonding/slaves ファイルを使って bond の スレーブにする事が出来ます。このファイルの方法は bonding_masters ファイルと同じ です。 インターフェース eth0 を bond (bond0) のスレーブ化： # ifconfig bond0 up # echo +eth0 > /sys/class/net/bond0/bonding/slaves bond (bond0) からスレーブ eth0 を開放： # echo -eth0 > /sys/class/net/bond0/bonding/slaves インターフェースが bond のスレーブになる際、２つの間のシンボリックリンクが sysfs ファイルシステムに作成されます。この場合、/sys/class/net/bond0/slave_eth0 は /sys/class/net/eth0 を指し、/sys/class/net/eth0/master は /sys/class/net/bond0 を指します。 これは、あるインターフェースがその master ディレクトリのシンボリックリンク先のス レーブかどうかを即座に伝えられることを意味します。従って、 # echo -eth0 > /sys/class/net/eth0/master/bonding/slaves は、bond インターフェースの名前に関わらず、eth0 がスレーブになっている何らかの bond から eth0 を開放します。 bond の設定の変更 ----------------- /sys/class/net//bonding にあるファイルを操作する事で、各 bond を別々に設 定できます。 これらのファイルの名前は、このファイルの別の場所で説明したコマンドラインパラメー タと直接一致し、そして、arp_ip_target を除いて、これらは同じ値を受け付けます。現 在の設定を見るためには、単に適切なファイルを cat して下さい。 ２、３の例をここで挙げましょう。※各パラメータ用の特定の使用ガイドラインには、こ のドキュメントの適切な章を見てください。 bond0 を balance-alb モードに設定： # ifconfig bond0 down # echo 6 > /sys/class/net/bond0/bonding/mode - または - # echo balance-alb > /sys/class/net/bond0/bonding/mode 注意：bond インターフェースはモードを変更する前にダウンされていなければなりませ ん。 bond0 で MII 監視を１秒間隔で有効化： # echo 1000 > /sys/class/net/bond0/bonding/miimon 注意：ARP 監視が有効な場合、MII 監視を有効にした際に ARP 監視は無効化されます。 逆も同様です。 ARP ターゲットを追加： # echo +192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target # echo +192.168.0.101 > /sys/class/net/bond0/bonding/arp_ip_target 注意：最大 10 ターゲットアドレスを指定できます。 ARP ターゲットの削除： # echo -192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target 設定の例 -------- sysfs を使い、ifenslave なしで 3.3 章で示したのと同じ例で始めてみましょう。 e100 デバイス２つ(eth0,eth1 と仮定)の単純な bond を作成し、再起動後も bond の設 定が持続するようにする為に、適切なファイル(/etc/init.d/boot.local または /etc/rc.d/rc.local)を編集し、次を追加します： modprobe bonding modprobe e100 echo balance-alb > /sys/class/net/bond0/bonding/mode ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up echo 100 > /sys/class/net/bond0/bonding/miimon echo +eth0 > /sys/class/net/bond0/bonding/slaves echo +eth1 > /sys/class/net/bond0/bonding/slaves e1000 インターフェース２つで、active-backup モード、ARP 監視の２つめの bond を追 加する為に、次の行を init スクリプトに追加します： modprobe e1000 echo +bond1 > /sys/class/net/bonding_masters echo active-backup > /sys/class/net/bond1/bonding/mode ifconfig bond1 192.168.2.1 netmask 255.255.255.0 up echo +192.168.2.100 /sys/class/net/bond1/bonding/arp_ip_target echo 2000 > /sys/class/net/bond1/bonding/arp_interval echo +eth2 > /sys/class/net/bond1/bonding/slaves echo +eth3 > /sys/class/net/bond1/bonding/slaves 4. bonding 設定の確認 ===================== 4.1 bonding の設定 ------------------ 各 bonding デバイスには /proc/net/bonding ディレクトリに置かれる読み取り専用のファ イルがあります。このファイルの内容は bonding 設定、オプション、各スレーブの状態 に関する情報を含んでいます。 例えば、mode=0, miimon=1000 のパラメータでドライバがロードされた後、 /proc/net/bonding/bond0 の内容は一般に次のようになります： Ethernet Channel Bonding Driver: 2.6.1 (October 29, 2004) Bonding Mode: load balancing (round-robin) Currently Active Slave: eth0 MII Status: up MII Polling Interval (ms): 1000 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth1 MII Status: up Link Failure Count: 1 Slave Interface: eth0 MII Status: up Link Failure Count: 1 正確なフォーマットや内容は bonding の設定、状態、bonding ドライバのバージョンに 依存して変化します。 4.2 ネットワークの設定 ---------------------- ネットワーク設定は ifconfig コマンドを使って調べられます。bonding デバイスには MASTER フラグセットがあります。※bonding スレーブデバイスには SLAVE フラグセット があります。ifconfig 出力にはどのスレーブがどのマスターに関連するかの情報が含ま れていません。 下記の例では、bond0 インターフェースはマスター(MASTER)で、一方 eth0 と eth1 はス レーブ(SLAVE)です。bond0 の全スレーブは、各スレーブに独自の MAC アドレスを必要と する TLB と ALB 以外の全てのモードで bond0 と同じ MAC アドレス(HWaddr) を持つ事 に注意して下さい。 # /sbin/ifconfig bond0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0 UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:7224794 errors:0 dropped:0 overruns:0 frame:0 TX packets:3286647 errors:1 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:0 eth0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:3573025 errors:0 dropped:0 overruns:0 frame:0 TX packets:1643167 errors:1 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:100 Interrupt:10 Base address:0x1080 eth1 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:3651769 errors:0 dropped:0 overruns:0 frame:0 TX packets:1643480 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:9 Base address:0x1400 5. スイッチの設定 ================= このセクションでは、「スイッチ」はbond 化されたデバイスが直接接続された(つまり、 ケーブルのもう一方の端に接続された)どんなシステムにも関係します。これは実際接続 されたデバイスかも知れませんし、他の通常システム(例えば、Linux が動いている別の コンピュータ)かも知れません。 active-backup、balance-tlb、balance-alb モードはスイッチの特別な設定を必要としま せん。 802.3ad モードは、スイッチが 802.3ad 集合として適切なポート設定を持っている事を 要求します。これを設定する為に使用する正確な方法はスイッチ毎に異なりますが、例え ば、Cisco 3550 シリーズのスイッチは、最初に単一イーサチャネルインスタンスに一緒 にグループ化され、それからこのイーサチャネルが(標準のイーサチャネルの代わりに) 802.3adを有効にするために「lacp」モードに設定される事を要求します。 balance-rr、balance-xor、broadcast モードは一般に、スイッチがグループ化された適 切なポート群を持つ事を要求します。このようなグループの専門用語はスイッチ間で異な りますが、(上記の Cisco の例にあるように)「イーサチャネル(etherchannel)」と呼ば れるかも知れませんし、「トランクグループ(trunk group)」あるいは他の何らかの似た ようなバリエーションで呼ばれるかも知れません。これらのモードでは、bond へのスイッ チの通信ポリシーの為に、各スイッチにも独自の設定オプションがあります。典型的な選 択は MAC または IP アドレスのどちらかの排他論理和が含まれます。両端の通信ポリシー は一致する必要がありません。これら３つのモードでは、bonding モードは実際にイーサ チャネルグループ用の転送ポリシーを選択します。※３つ全てが他のイーサチャネルグルー プと相互作用します。 6. 802.1q VLAN サポート ======================= 8021q ドライバを用いて bond インターフェース越しに VLAN デバイスを設定する事が出 来ます。しかしながら、8021q ドライバから来て bonding を通ったパケットのみ、デフォ ルトでタグづけされます。自己生成したパケット(例えば、ALB モードか ARP 監視機構の いずれかで生成された bonding の学習パケットや ARP パケット)は bonding 自身では内 部でタグづけされません。その結果、bonding はその上で設定された VLAN ID を「学習」 しなければならず、自己生成したパケットをタグづけするためにこれらの ID を使用しな ければなりません。 単純な理由の為、そして VLAN ハードウェアアクセラレーションオフローディング※が出 来るアダプタの使用をサポートする為、bonding インターフェースは完全にハードウェア オフローディング対応としてそれ自身を宣言しており、必要な情報を集めるために add_vid/kill_vid 通知を受け取り、スレーブにこれらのアクションを広げます。アダプ タのタイプが混成の場合では、オフローディングに対応していないアダプタを通過したハー ドウェアでアクセラレーションされたタグつきパケットは、bonding ドライバで「アクセ ラレーションされない」ものであり、VLAN タグは通常の位置のままになります。 ※訳注：VLAN のプロトコル処理の一部をネットワークインターフェース(ハー ドウェア)側で行う事。 VLAN インターフェースは、少なくても１つのスレーブをスレーブ化した後でのみ bonding インターフェースの一番上で追加されなければ「なりません」。bonding インター フェースは、最初のスレーブを追加するまで、ハードウェアアドレス 00:00:00:00:00:00 を持っています。最初のスレーブ化の前に VLAN インターフェースが作成された場合、 VLAN インターフェースは全て 0 のハードウェアアドレスを拾ってしまいます。一旦最初 のスレーブが bond に加わると、bond デバイス自身はそのスレーブのハードウェアアド レスを拾い、これがその後 VLAN デバイスのものとして利用できます。 また、bond インターフェースの一番上に１つあるいは複数の VLAN インターフェースが まだある状態で、全てのスレーブが bond から開放された場合、同様の問題が起こりうる 事を意識してください。新しいスレーブが追加されると、bonding インターフェースは最 初のスレーブからハードウェアアドレスを獲得します。これは VLAN インターフェースの ハードウェアアドレス(結局のところ、以前のスレーブからコピーされたものです)とは一 致しません。 １つの bond インターフェースから全てのスレーブが削除された場合、VLAN デバイスが 適切なハードウェアアドレスを扱う事を保証する方法が２つあります。 1. 全ての VLAN インターフェースを削除し、再作成する 2. VLAN インターフェースのハードウェアアドレスに一致するように bonding インターフェースのハードウェアアドレスを設定する。 VLAN インターフェースのハードウェアアドレスを変更する事は、根底のデバイス−つま り bonding インターフェース−を(あなたが望まないかもしれない) プロミスカスモード に設定する事に注意して下さい。 7. リンク監視 ============= 現在の bonding ドライバはスレーブデバイスのリンク状態を監視する方式を２つサポー トしています：ARP 監視と MII 監視です。 現時点では、bonding ドライバ自体の実装上の制限の為、ARP 監視と MII 監視を同時に 有効にする事は出来ません。 7.1 ARP 監視操作 ---------------- ARP 監視はその名前が示すように作動します：リンクが作動している事を示す為に、ネッ トワーク上の１つまたは複数の指定された対象システムに ARP 問い合わせを送信し、リ ンクが作動している事を示すその ARP 応答を使います。これにより、ローカルネットワー ク上の１つあるいは複数の対象へ／から通信が実際に流れている事が確実になります。 ARP 監視は、通信が流れている事を検証する為に、デバイスドライバ自体に依存していま す。特に、ドライバが最後に受信した時の時刻(dev->last_rx)と送信を開始した時間 (dev->trans_start)を保持しなければなりません。これらがドライバによって更新されな い場合、ARP 監視はこのドライバを使用しているスレーブはどれも即座に失敗し、これら のスレーブはダウン状態のままになります。ネットワーク監視(tcpdump 等)がネットワー ク上の ARP 要求と応答を表示する場合、デバイスドライバが last_rc と trans_start を更新していない可能性があります。 7.2 複数の ARP ターゲットの設定 ------------------------------- ARP 監視が単一ターゲットで実施可能である一方、高可用性設定で ARP 監視に複数のター ゲットを持つようにする事は便利です。単一ターゲットの場合、ターゲット自体がダウン したり ARP 要求に応答できなくなる問題があるかも知れません。1つ(あるいは複数)の追 加のターゲットがある事は、ARP 監視の信頼性を向上します。 複数の ARP ターゲットは次のようにコンマで区切らなければなりません： # example options for ARP monitoring with three targets alias bond0 bonding options bond0 arp_interval=60 arp_ip_target=192.168.0.1,192.168.0.3,192.168.0.9 単一ターゲットでは、オプションは似たようなものになります： # example options for ARP monitoring with one target alias bond0 bonding options bond0 arp_interval=60 arp_ip_target=192.168.0.100 7.3 MII 監視操作 ---------------- MII 監視はローカルのネットワークインターフェースのキャリア状態のみ監視します。 これは３つの方法のいずれかで実施されます：キャリア状態の管理をデバイスドライバに 依存する方法、デバイスの MII レジスタに問い合わせを行う方法、ethtool 問い合わせ をデバイスに行う方法です。 use_carrier モジュールパラメータが１(デフォルト値)の場合、MII 監視はキャリア状態 情報の為に(netif_carrier サブシステムを介して)ドライバに頼ります。上記の user_carrier パラメータ情報で説明した通り、MII 監視がデバイスのキャリアロスの検 知に失敗した場合(例えば、ケーブルが物理的に切断された時)、ドライバが netif_carrier をサポートしないかも知れません。 user_carrier が 0 の場合、MII 監視は最初に(ioctl 経由で)デバイスの MII レジスタ を問い合わせ、リンク状態をチェックします。この要求が失敗した場合(単にキャリアダ ウンを返すのとは異なる)、MII 監視は同じ情報を得ようとして ethtool ETHOOL_GLINK 要求を行います。両方の方法とも失敗した場合(つまり、ドライバが MII レジスタと ethtool リクエストの両方の処理をサポートしないか何らかのエラーが発生した場合)、 MII 監視はリンクがアップしているものと仮定します。 8. 潜在的な問題源 ================= 8.1 ルーティングでの冒険 ------------------------ bonding が設定された場合、スレーブデバイスがマスタのルートを入れ換えるルートを持っ ていない(あるいは、一般に何もルートを持っていない)事が重要です。例えば、bonding デバイス bond0 が２つのスレーブ eth0, eth1 を持ち、ルーティングテーブルが次のよ うな状態を仮定します： Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth0 10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth1 10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 bond0 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo このルーティング設定は(ARP 監視に必要な)ドライバの受信/送信時にまだ更新されそう ですが、bonding ドライバを迂回するかも知れません(なぜなら、この場合、ネットワー ク 10 上の別のホストへの外行き送信が bond0 の前に eth0 または eth1 を使うので)。 ARP 監視(と ARP 自体)はこの設定では混乱するかもしれません。なぜなら(ARP 監視で生 成された) ARP 要求が１つのインターフェース(bond0)に送信されますが、該当する応答 は異なるインターフェース(eth0)に届きます。この応答は、(ARP はインターフェースベー スで応答をマッチさせるので)要求されていない ARP 応答として ARP に見られ、破棄さ れます。MII 監視はルーティングテーブルの状態に影響されません。 この解決方法は単にスレーブが自身のルートを持たない事を保証する事で、何らかの事情 でルーティングが必要な場合、これらのルートがマスターのルートに取って代わらないよ うにします。普通はこの状態になるはずですが、通常でない設定や間違った手動もしくは 自動的な静的ルート追加は、トラブルを引き起こすかも知れません。 8.2 イーサネットデバイスの名前変更 ---------------------------------- 物理デバイスを直接ネットワークインターフェース名に関連付ける(同じ物理デバイスが 常に同じ「ethX」名になる)ことがないネットワーク設定スクリプトのシステムでは、 /etc/modules.conf または /etc/modprobe.conf (システムにインストールされたものに 依存します)のどちらかに何らかの特別なロジックを追加する必要があるかも知れません。 例えば、次を含む modules.conf が与えられた場合： alias bond0 bonding options bond0 mode=some-mode miimon=50 alias eth0 tg3 alias eth1 tg3 alias eth2 e1000 alias eth3 e1000 eth0、eth1 のどちらも bond0 のスレーブでない場合、bond0 インターフェースが起動し た際、デバイスの番号が並び替わってしまうかも知れません。これは、bonding が最初に 読み込まれ、次にそのスレーブデバイスのドライバがロードされる事によります。他のド ライバがロードされる前に、e1000 ドライバがロードされた場合、そのデバイスに eth0、 eth1 が付与されますが、bonding 設定は eth2 と eth3 (これらは後ほど tg3 デバイス に付与されます)をスレーブにしようとします。 次の追加は： add above bonding e1000 tg3 bonding がロードされる際、e1000 をロードしてから tg3 をロードするように(この順序 で) modprobe に指示します。このコマンドは modules.conf マニュアルページで完全に 文書化されています。 modprobe.conf (または modprobe.conf.local)を利用するシステムでは、同様の問題が起 こります。この場合、次のように(全て１行で※ここでは明示的に分割しています) modprobe.conf (または modprobe.conf.local、適切に)に追加する事ができます。 install bonding /sbin/modprobe tg3; /sbin/modprobe e1000; /sbin/modprobe --ignore-install bonding これにより、bonding モジュールをロードする際、通常の動作を行うのではなく、代わり に与えられたコマンドを実行します。このコマンドはデバイスドライバを必要な順序でロー ドし、それから通常のアクションを行う為に --ignore-install 付きで modprobe をコー ルします。この完全なドキュメント modprobe.conf と modprobe のマニュアルページに あります。 8.3. miimon による悲惨な遅さ あるいは リンク失敗検知せず -------------------------------------------------------- デフォルトでは、bonding は use_carrier オプションを有効にし、これによりキャリア 状態を管理するのにドライバを信用するよう bonding に指示します。 上記オプションの章で議論したように、いくつかのドライバは netif_carrier_on/_off リンク状態追跡システムをサポートしていません。use_carrier を有効にすると、実際の リンク状態に関わらず、bonding は常にこれらのリンクがアップされていると見ます。 加えて、他のドライバは netif_carrier をサポートするが、これをリアルタイムで管理 しない事があります(例えば、何らかの固定間隔でリンク状態をポーリングするのみ)。こ の場合、miimon は失敗を検知しますが、何らかの長い時間を超過した後でのみになりま す。リンク失敗の検知で miimon が非常に遅いように思われる場合、use_carrier=0 を指 定してを試し、失敗検知時間を改善するか見てください。もし改善するなら、ドライバは キャリア状態を固定間隔でチェックしていますが、MII レジスタ値をキャッシュしていな い(よって、レジスタを直接問い合わせる use_carrier=0 方法が機能します)かも知れま せん。use_carrier=0 がフェイルオーバを改善しない場合、ドライバはレジスタをキャッ シュしているか、他のどこかに問題があります。 また、miimon がデバイスのキャリア状態のみチェックする事を覚えていて下さい。それ が、スイッチの他のポート上あるいは向こうのデバイスの状態なのか、あるいはスイッチ がキャリアオンの管理中に通信が渡される事を拒否している場合かを判断する方法はあり ません。 9. SNMP エージェント ==================== SNMP エージェントを実行している場合、何らかのネットワークドライバが bond に参加 する前に bonding ドライバがロードされていなければなりません。この要件は、与えら れた IP アドレスのある最初のインターフェースが関連付けられるインターフェースイン デックス(ipAdEntIfIndex)の為です。これは、各 IP アドレス用に唯一の ipAdEntIfIndex があるという事です。例えば、eth0 と eth1 が bond0 のスレーブであ り、eth0 のドライバが bonding ドライバの前にロードされる場合、その IP アドレスの 為のインターフェースは eth0 インターフェースに関連付けられます。この設定は以下の ように示され、IP アドレス 192.168.1.1 は、ifDesc テーブル中の eth0 の ID (ifDescr.2) であるインターフェースインデックス 2 番を持ちます。 interfaces.ifTable.ifEntry.ifDescr.1 = lo interfaces.ifTable.ifEntry.ifDescr.2 = eth0 interfaces.ifTable.ifEntry.ifDescr.3 = eth1 interfaces.ifTable.ifEntry.ifDescr.4 = eth2 interfaces.ifTable.ifEntry.ifDescr.5 = eth3 interfaces.ifTable.ifEntry.ifDescr.6 = bond0 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 5 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 4 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 この問題は bond に参加するどのネットワークドライバより先に bonding ドライバをロー ドする事で回避できます。下記は bonding ドライバを最初にロードした例で、IP アドレ ス 192.168.1.1 は適切に ifDescr.2 に割り当てられています。 interfaces.ifTable.ifEntry.ifDescr.1 = lo interfaces.ifTable.ifEntry.ifDescr.2 = bond0 interfaces.ifTable.ifEntry.ifDescr.3 = eth0 interfaces.ifTable.ifEntry.ifDescr.4 = eth1 interfaces.ifTable.ifEntry.ifDescr.5 = eth2 interfaces.ifTable.ifEntry.ifDescr.6 = eth3 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 6 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 5 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 いくつかのディストリビューションで ifDescr のインターフェース名が報告されないか も知れませんが、一方 IP アドレスと IfIndex 間の関係は残り、Interface_Scan_Next のような SNMP 機能はその関係を報告します。 10. Promiscuous モード ====================== ネットワーク監視ツール(例：tcpdump)の実行時、一般にデバイス上で promiscuous モー ドが有効になり、これによって(ローカルホストに向かっている通信のみ見える代わりに) 全ての通信が見えます。bonding ドライバは bonding マスターデバイス(例：bond0)の promiscuous モードの変更を扱い、スレーブデバイスの設定に広めます。 balance-rr、balance-xor、broadcast、802.3ad モードでは、promiscuous モード設定は 全てのスレーブに広められます。 active-backup、balance-tlb、balance-alb モードでは、promiscuous モード設定はアク ティブなスレーブにのみ広げられます。 balance-tlb モードでは、アクティブなスレーブは現在内向きの通信を受信しているスレー ブになります。 balance-alb モードでは、アクティブスレーブは「１番め(primary)」として使用される スレーブです。このスレーブは、未割り当ての通信対象への送信や通信負荷が不均等な場 合のモード固有の制御通信に使用されます。 active-backup、balance-tlb、balance-alb モードでは、アクティブスレーブが変更され た際(例：リンク失敗の為)、promiscuous 設定は新しいアクティブスレーブに広げられます。 11. 高可用性用の bonding 設定 ============================= 高可用性とは、そのホストとそれ以外の世界との間に、冗長またはバックアップデバイス、 リンクあるいはスイッチがある事で、最大限のネットワーク可用性を提供する設定を指し ます。この目的は、他の設定による高いスループットを犠牲にしたとしても、ネットワー クの接続性を最大限提供する事です(つまり、ネットワークが常に機能している)。 11.1 単一スイッチトポロジにおける高可用性 ----------------------------------------- ２つのホスト(あるいは単一ホストと単一スイッチ)が複数の物理的リンクを介して直接接 続されている場合、最大バンド幅の為の最適化による可用性ペナルティはありません。こ のケースでは、単一のスイッチ(あるいは通信相手)のみあるので、それが失敗した場合、 フェールオーバーする代替アクセスがありません。加えて、bonding ロードバランスモー ドはメンバーのリンク監視を提供するので、独立したリンクが失敗した場合、負荷は残さ れたデバイスの中で再度均等化されます。 １つのピアデバイスでの bonding 設定の情報は 13 章「最大スループットの為の bonding 設定」を参照してください。 11.2 複数のスイッチトポロジにおける高可用性 ------------------------------------------- 複数のスイッチでは、bonding の設定とネットワークは劇的に変化します。複数のスイッ チトポロジではネットワークの可用性と利用できるバンド幅の間にはトレードオフがあり ます。 下記は、ネットワークの可用性を最大化するよう設定されたネットワークの例です。 | | |ポート3 ポート3| +-----+----+ +-----+----+ | |ポート2 ISL ポート2| | |スイッチA +--------------------------+スイッチB | | | | | +-----+----+ +-----+----+ |ポート1 ポート1| | +-------+ | +-------------+ホスト1+---------------+ eth0 +-------+ eth1 この設定では、２つのスイッチ間にリンク(ISL、またはスイッチ間リンク: inter switch link)と、外の世界につながる複数のポート(各スイッチの「port3」)があります。３番め のスイッチに拡張できない技術的な理由はありません。 11.2.1 複数のスイッチトポロジにおける高可用性 bonding モードの選択 ------------------------------------------------------------------ 上記の例のようなトポロジでは、可用性に最適化した際に active-backup と broadcast モードのみが有用な bonding モードです。※他のモードは、全てのリンクが合理的に振 る舞うために同じ通信対象に接続されている事を要求します。 active-backup: 一般にはこれがお薦めのモードで、特にスイッチに ISL があり、一緒に うまく動いている場合はそうです。１つのスイッチが特にバックアップスイッチ (例：低い容量、高いコスト、等)であるようなネットワーク設定の場合、優先リ ンクが利用できる場合に常に使用される事を保証する為に primary オプション を使用できます。 broadcast: このモードは本当に特殊な目的のモードで、非常に特殊なニーズにのみ適当 です。例えば、２つのスイッチが接続されておらず(ISL なし)、これらの向こう のネットワークが全く独立している場合です。このようなケースでは、いくつか の特別な片道通信で両方の独立したネットワークで受信する事が必要な場合、 broadcast モードは適当かも知れません。 11.2.2 複数のスイッチトポロジにおける高可用性リンク監視 ------------------------------------------------------- リンク監視の選択は、結局スイッチに依存します。スイッチが他の失敗への応答において ポートが確実に失敗する場合、MII 監視あるいは ARP 監視のどちらも機能するでしょう。 例えば、上記の例で、反対側の終端で「port3」リンクが失敗する場合、MII 監視にはこ の失敗を検出する直接の手段がありません。ARP 監視は port3 の反対側の終端にあるター ゲットに監視を設定できます。従ってスイッチのサポートなしに失敗を検知します。 しかしながら、一般に、複数のスイッチトポロジでは、ARP 監視は端から端への接続性の 失敗(これは、何らかの理由で通信を渡す為の任意の独立したコンポーネントの失敗に起 因するかも知れません)の検知において、さらに高レベルの信頼性を提供します。加えて、 ARP 監視は複数のターゲットを(少なくとも、ネットワーク中の各スイッチ毎に１つ)設定 できます。これは、どのスイッチがアクティブであるかに関わらず、ARP 監視が問い合わ せる適切なターゲットがある事を保証します。 また、最近の多くのスイッチは今、「トランクフェールオーバ(trunk failover)」として 一般に言われる機能をサポートしています。これは、別のスイッチポートの状態がダウン (またはアップ)した際、特定のスイッチポートのリンク状態がダウン(またはアップ)を引 き起こすというスイッチの機能です。この目的は、論理的に「外部の」ポートのリンク失 敗が、bonding が miimon を介して監視できる、論理的に「内部の」ポートに広められる 事です。トランクフェイルオーバの可用性と設定はスイッチによって変わりますが、適切 なスイッチを使用する際、これは ARP 監視の実用的な代替策になります。 12. 最大スループットの為の bonding 設定 ======================================= 12.1 単一スイッチトポロジにおける最大スループット ------------------------------------------------- 単一スイッチ設定では、スループットを最大化する最良な方法は、アプリケーションとネッ トワーク環境に依存します。様々な負荷分散モードは、下記に説明するように、異なる環 境においてそれぞれ長所と短所があります。 この議論では、トポロジを２つのカテゴリに分けます。ほとんどの通信の送信先によって、 トポロジを「ゲートウェイ経由」設定と「ローカル」設定のどちらかに分類します。 ゲートウェイ経由の設定では、「スイッチ」は主にルータとして機能し、通信の大部分は このルータを通って他のネットワークへ渡されます。例は次の通りです： +----------+ +----------+ | |eth0 ポート1| | 他のネットワークへ | ホストA +---------------------+ ルーター +-------------------> | +---------------------+ | ホストB と C は | |eth1 ポート2| | ここの外のどこか +----------+ +----------+ ルーターはルーター専用デバイスかも知れませんし、ゲートウェイとして振る舞う別のホ ストかも知れません。我々の議論では、重要なポイントは、ホスト A からの通信の大部 分が最終的な目的地に到達する前に、いくつかの他ネットワークへのルータを通過する事 です。 ゲートウェイ経由のネットワーク設定では、例えホスト A が多くの他のシステムと通信 できたとしても、そのトラフィックは全てローカルネットワークの１つの通信相手、すな わちルーターを介して送受信されます。 複数の物理的リンクを介して直接接続された２つのシステムの場合は(bonding を設定す る目的だと)ゲートウェイ経由の設定と同じである事に注意して下さい。この場合、全て の通信はゲートウェイの向こうの他のネットワーク宛ではなく「ゲートウェイ」宛に送信 されます。 ローカルの設定では、「スイッチ」は主にスイッチとして機能し、通信の大部分は同じネッ トワーク上の他のステーションに到着する為にこのスイッチを通過します。一例は次の通 りです： +----------+ +----------+ +--------+ | |eth0 ポート1| +---------+ホストB | | ホストA +------------+ スイッチ |ポート3 +--------+ | +------------+ | +--------+ | |eth1 ポート2| +------------------+ホストC | +----------+ +----------+ポート4 +--------+ ここでは、スイッチはスイッチ専用デバイスかもしれませんし、ゲートウェイとして振る 舞う別のホストかも知れません。我々の議論では、重要なポイントはホスト A からの通 信の大部分が同じローカルネットワークの他のホスト(上記の例ではホスト B と ホスト C)宛だという事です。 要は、ゲートウェイ経由の設定では、bond 化されたデバイスから行き来する通信は最終 的な宛先にかかわらず、ネットワーク上の同じ MAC レベルの通信相手(ゲートウェイ自身、 つまりルータ)向けであるという事です。ローカル設定では、通信は最終目的地と直接行 き来します。よって各目的地(ホスト B、ホスト C)はこれらの独立した MAC アドレスに よって直接位置付けられます。 ゲートウェイ経由の設定とローカルネットワークの設定を区別するのは重要です。なぜな ら、利用可能な負荷分散モードの多くが、負荷分散の決定を行う為にローカルネットワー クの送信元と送信先の MAC アドレスを使用するからです。各モードの振る舞いは下記の 通りです。 12.1.1 単一スイッチトポロジにおける最大スループットの bonding モードの選択 -------------------------------------------------------------------------- この設定は、設定や理解がもっとも簡単です。でも、どの bonding モードがあなたのニー ズに最も適しているかを決めなくてばなりません。各モードのトレードオフの詳細を下記 に挙げます： balance-rr: このモードは、通信を複数のインターフェースに渡してストライピングする ために単一 TCP/IP 接続を許可する唯一のモードです。従って、単一 TCP/IP ス トリームが単一インターフェースのスループット量以上を利用する唯一のモード です。これにはコストがかかります。しかしながら：ストライピングは一般に、 (TCP/IP の密集制御システムに起因し)再送セグメントによって対象システムに パケットが順番を外れて届く結果になります。 net.ipv4.tcp_reordering sysctl パラメータの変更により、TCP/IP の輻輳制限 を調整する事ができます。通常のデフォルト値は 3 で、使用可能な最大値は 127 です。４つのインターフェースの balance-rr bond では、tcp_reordering を調整した後でさえ、単一 TCP/IP ストリームはおおよそ 2.3 インターフェー スのスループット量以下の利用になる事が予想されます。 順序外で配送されるパケットの比率は非常に変わりやすく、また 0 になりそう もない事に注意して下さい。パケットの再整列のレベルはネットワークインター フェース、スイッチ、設定のトポロジを含む様々な要因に依存します。一般的な 条件を言えば、より高速のネットワークカードは(パケット融合などの要因によ り)より多くの再整列を生じ、「多対多」トポロジは「多遅対一速(many slow to one fast)」設定より高い比率で再整列します。 多くのスイッチは、(IP または MAC レベルのアドレスを基にしたポート選択の 代わりに)通信をストライプ(順繰り)する何らかのモードをサポートしていませ ん。※これらのデバイスでは、スイッチを通じて balance-rr bond に流れる特 定のコネクション用の通信は、１つのインターフェースのバンド幅以上に利用す る事はありません。 TCP/IP 以外のプロトコル(例：UDP)を利用しており、アプリケーションが順序外 配信に耐える場合、このモードはbond に加えられたインターフェース群の性能 にほぼ線形にスケールする単一ストリームデータグラム性能が得られます。 このモードは、「イーサチャネル」または「トランキング」用の適切なポート設 定がスイッチにある事を要求します。 active-backup: アクティブでないバックアップデバイスが全て同じ通信相手に primary として接続されている為、active-backup モードは、このネットワークトポロジ における利点があまりありません。この場合、(リンク監視有りの)負荷分散モー ドは同レベルのネットワーク可用性を提供しますが、使用可能なバンド幅が増加 します。プラス面では、active-backup モードはスイッチに何らかの設定を要求 しないので、利用可能なハードウェアが負荷分散モードを何もサポートしない場 合に価値があります。 balance-xor: このモードは、特定の通信相手に運命付けられたパケットが常に同じイン ターフェースを経由して送信されるよう通信を制限します。目的地は MAC アド レスで決定される為、このモードは(上記で説明したような) 同じローカルネッ トワーク上に全ての目的地がある状態の「ローカル」ネットワーク設定で最も良 く動作します。このモードは、全ての通信が単一のルータを通過する場合(つま り、上記で説明した「ゲートウェイ経由」ネットワーク設定)には不完全になり そうです。 balance-rr と同様、スイッチポートは「イーサチャネル」または「トランキン グ」に設定される必要があります。 broadcast: active-backup に似て、このタイプのネットワークトポロジではこのモード はあまり利点がありません。 802.3ad: このモードはこのタイプのネットワークトポロジでは良い選択肢になります。 802.3ad モードは IEEE 標準なので、802.3ad を実装した全ての通信相手とはう まく相互運用できます。802.3ad プロトコルは集合の自動設定を含んでいるので、 スイッチの最低限の手動設定が必要です(典型的には、デバイスの何らかのセッ トが 802.3ad で利用できるよう指定する事のみ)。802.3ad 標準はまた、フレー ムを順番(ある制限内)に配信するよう指示を出しますので、一般には単一接続は パケットの順番ミスに遭遇しません。802.3ad モードはいくつかの欠点がありま す：この標準は、集合中の全てのデバイスに同じスピードと同じ全半二重で操作 するよう指示を出します。また、balance-rr 以外の全ての bonding 負荷分散モー ドの場合と同様に、単一接続は１つのインターフェースのバンド幅より広くを利 用できません。 加えて、Linux の bonding 802.3ad 実装は、通信を通信相手で分散します(MAC アドレスの排他論理和を使用)ので、「ゲートウェイ経由」の設定では、全ての 外行き通信は一般に同じデバイスを使用します。内向き通信も最終的には単一デ バイスを通過するかも知れませんが、通信相手の 802.3ad 実装の負荷分散ポリ シーに依存します。「ローカル」設定において、通信は bond 中のデバイス群を 渡って負荷分散されます。 最後に、802.3ad モードは MII 監視の使用を指示しますので、このモードで ARP 監視は利用できません。 balance-tlb: balance-tlb モードは、外向きの通信を通信相手で負荷分散します。MAC アドレスに従って負荷分散が行われますので、「ゲートウェイ経由」設定では (上記で説明した通り)、このモードは単一のデバイスを渡って全ての通信が送信 されます。しかしながら、「ローカル」ネットワーク設定では、このモードは、 漠然としたインテリジェントマナー(balance-xor や 802.3ad モードのような単 純な XOR ではなく)でデバイスを渡って複数のローカルネットワークの通信相手 を負荷分散しますので、数学的には不幸な MAC アドレス(つまり、XOR が同じ値 になるもの)が単一のインターフェース上で全て「束になる」事がありません。 802.3ad と異なり、インターフェースは異なるスピードでも良く、特別なスイッ チ設定が必要ありません。欠点としては、このモードでは全ての内向きの通信が 単一インターフェースを越えて到着することと、このモードはスレーブインター フェースのネットワークデバイスドライバに特定の ethtool サポートを要求す ること、ARP 監視が利用できないことです。 balance-alb: このモードは balance-tlb の全て以上です。balance-tlb の全機能(と制 限)があり、そのうえ(上記の bonding モジュールオプション章で説明したよう な)ローカルネットワークの通信相手からの内向き通信も負荷分散します。 このモードに唯一追加された欠点は、ネットワークデバイスドライバが、デバイ スがオープンされている間のハードウェアアドレスの変更をサポートしなければ ならない事です。 12.1.2 単一スイッチトポロジにおける最大スループットのリンク監視 --------------------------------------------------------------- リンク監視の選択は、どのモードを使用するかの選択に主に依存しています。より進んだ 負荷分散モードは ARP 監視の使用をサポートしておらず、このため MII 監視の使用に制 限されてしまいます(これは ARP 監視ほど、端から端への確実性を高いレベルで提供しま せん)。 12.2 複数のスイッチトポロジにおける最大スループット --------------------------------------------------- ２つ以上のシステムの間にある独立したネットワークの部分を並列に設定する際、スルー プットを最適化する為に複数のスイッチを利用できます。例えば： +-----------+ | ホスト A | +-+---+---+-+ | | | +--------+ | +---------+ | | | +------+---+ +-----+----+ +-----+----+ |スイッチA | |スイッチB | |スイッチC | +------+---+ +-----+----+ +-----+----+ | | | +--------+ | +---------+ | | | +-+---+---+-+ | ホスト B | +-----------+ この設定では、スイッチ群は互いに独立しています。このようなトポロジを使う１つの理 由は、多くのホストがある独立したネットワークの為で(例えば、高速計算用に設定され たクラスタ)、複数の小さなスイッチの使用で単一の大きなスイッチよりもコスト効果を 高くできます(例えば、24 ホストがあるネットワークでは、3 つの 24 ポートスイッチが 単一の 72 ポートスイッチより極めて低価格で利用できます)。 ネットワークの向こうとアクセスする必要がある場合、外部のネットワークに接続された 追加ネットワークデバイスを独立したホストに装備する事が出来ます。※従って、このホ ストはその後さらにゲートウェイとしても振る舞います。 12.2.1 複数のスイッチトポロジにおける最大スループットの bonding モードの選択 ---------------------------------------------------------------------------- 実際の現場では、このタイプの設定で典型的に用いられる bonding モードは balance-rr です。歴史的に、このネットワーク設定では、順序外のパケット配送に関する通常の注意 はあらゆる種類のパケット融合(NAPI 使用を介して、あるいはデバイス自体がある程度の パケットが到着しないと割り込みを生成しない事により)を行わないネットワークアダプ タの使用により緩和されます。この形式を用いた場合、１インターフェースのバンド幅以 上を効果的に利用する為に、balance-rr モードで２ホスト間の独立した接続が可能にな ります。 12.2.2 複数のネットワークトポロジにおける最大スループットのリンク監視 --------------------------------------------------------------------- 再度、実際の現場では、性能を可用性より優先させる為、この設定では MII 監視が最も 多用されています。このトポロジで ARP 監視は機能するでしょうが、システムの数につ れて必要なプローブの量が複雑に成長する事により、MII 監視に対する ARP 監視の優位 性は低くなります(ネットワーク中の各ホストが bonding で接続される事を思い出してく ださい)。 13. スイッチの挙動問題 ======================== 13.1 リンク確立とフェイルオーバ遅延 ----------------------------------- いくつかのスイッチは、スイッチが報告するリンクアップ／ダウンのタイミングに関して 望ましくない挙動を示します。 第一に、リンクがアップした時、いくつかのスイッチはリンクがアップ(キャリアを利用 可能)した事を示しても、ある程度の期間インターフェースを越えて通信ができないかも 知れません。この遅延は、典型的には数タイプのオートネゴシエーションやルーティング プロトコルの為ですが、スイッチの初期化の間にも発生するかも知れません(例えば、ス イッチ失敗後のリカバリの間)。これが問題になる事を見つけた場合、関連したインター フェースの使用を遅延させる為、bonding モジュールオプション updelay に適切な値を 指定します。 第二に、いくつかのスイッチはリンクが状態を変更する間、１回あるいは複数回リンクの 状態を「跳ね返す(bounce)」かも知れません。これは、スイッチの初期化中に最もよく発 生します。この場合も、適切な updelay 値が救いになるかも知れません。 bonding インターフェースにアクティブなリンクがない場合、updelay パラメータが指定 されていたとしても、bonding ドライバは最初にアップしたリンクを即座に再利用します (この場合、updelay は無視されます)。updelay タイムアウトを待っているスレーブイン ターフェースがあれば、最初にその状態になったインターフェースが即座に再利用されま す。これは、updelay の値が過大に見積られている場合に、ネットワークのダウンタイム を削減しますし、接続されていない場合のみで発生する事であるため、updelay を無視す ることによるペナルティが加わることはありません。 スイッチタイミング関連で加えると、スイッチがバックアップモードになるのに長い時間 がかかる場合、リンクがダウンした後に即時にバックアップインターフェースをアクティ ブにしない事が望まれるかも知れません。フェールオーバは bonding モジュールオプショ ン downdelay で遅延できます。 13.2 重複した内向きパケット --------------------------- 注意：バージョン 3.0.2 以降、bonding ドライバは重複パケットを抑制するロジックが あります。これは、この問題を大いに取り除きます。以下の説明は参考の為に保持します。 bonding デバイスが最初に使用される際、あるいは bonding がある程度の期間待機状態 だった後で、突発的な重複通信が見られる事は珍しくありません。これは、ネットワーク 上の他のホストに「ping」を打ち、ping が出力する「重複(duplicate)」フラグ(典型的 には、スレーブ毎に1つ)に気づく事でごく簡単に観測できます。 例えば、全て１つのスイッチに接続された5つのスレーブがある active-backup モードの bond では、出力は次のようになるかも知れません： # ping -n 10.0.4.2 PING 10.0.4.2 (10.0.4.2) from 10.0.3.10 : 56(84) bytes of data. 64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.7 ms 64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!) 64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!) 64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!) 64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!) 64 bytes from 10.0.4.2: icmp_seq=2 ttl=64 time=0.216 ms 64 bytes from 10.0.4.2: icmp_seq=3 ttl=64 time=0.267 ms 64 bytes from 10.0.4.2: icmp_seq=4 ttl=64 time=0.222 ms これは bonding ドライバにおけるエラーの為ではなく、正しくは、多くのスイッチがそ れらの MAC 転送テーブルを更新する方法の副作用です。はじめに、スイッチは特定のス イッチポートにパケットの MAC アドレスを関連付けておらず、このため MAC 転送テーブ ルが更新されるまで全てのポートに通信を送る可能性があります。bond に所属するイン ターフェースが単一スイッチの複数のポートを占めるかもしれないので、スイッチが(一 時的に)全てのポートに通信を送る際、bond デバイスは同じパケットの複数のコピー(1ス レーブデバイスに1つ)を受信します。 重複パケットの挙動はスイッチに依存し、この挙動を示すスイッチもあれば、示さないス イッチもあります。この挙動を示すスイッチでは、MAC 転送テーブルのクリアがこれを誘 発する事があります(ほとんどの Cisco スイッチでは、特権コマンド「clear mac address-table dynamic」がこれを実行します)。 14. ハードウェア別の考慮 ======================== このセクションは、特定ハードウェアプラットフォーム上の bonding 設定、あるいは特 定のスイッチや他のデバイスとの bonding 接続についての追加情報を含みます。 14.1 IBM BladeCenter -------------------- これは JS20 と、同様のシステムに適用されます。 JS20 ブレードでは、bonding ドライバは balance-rr、active-backup、balance-tlb、 balance-alb モードのみサポートします。これは主に、下記で説明する BladeCenter 内 部のネットワークトポロジによるものです。 JS20 ネットワークアダプタ情報 ----------------------------- 全てのJS20 には、planar (これが IBM の言う「マザーボード」です)上に統合された Broadcom のギガビットイーサネットポートが２つあります。BlaceCenter のシャーシで は、全 JS20 ブレードの eth0 ポートはI/O モジュール１番に直接配線(hard wired)され ています。※同様に、全ての eth1 ポートは I/O モジュール２番に配線されています。 あと２つのギガビットイーサネットポートを提供する為、追加の Broadcom ドータカード を JS20 上に導入できます。これらのポート、eth2 と eth3 は I/O モジュール３番と４ 番にそれぞれ配線されています。 各 I/O モジュールは１つのスイッチか(ポートを直接外部のスイッチに接続する)パスス ルーモジュールのどちらかを含みます。いくつかの bonding モードは、機能するために 特定の BladeCenter 内部ネットワークモジュールトポロジを要求します。※これらは下 記で紹介します。 追加の BladeCenter に特化したネットワーク情報は IBM レッドブック (www.ibm.com/redbooks)にあります。 "IBM eServer BladeCenter Networking Options" "IBM eServer BladeCenter Layer 2-7 Network Switching" BladeCenter ネットワーク設定 ---------------------------- BladeCenter が非常に多くの方法で設定できるので、この議論では基本的な設定の説明に 制限します。 通常、イーサネットスイッチモジュール(ESM)は I/O モジュール１番と２番を使用します。 この設定では、JS20 の eth0 と eth1 ポートは(それぞれの I/O モジュールにある)異な る内部スイッチに接続されます。 パススルーモジュール(OPM(光学)または CPM(銅線)パススルーモジュール)は I/O モジュー ルを直接外部スイッチに接続します。I/O モジュール１番と２番のパススルーモジュール の使用により、JS20 の eth0 と eth1 インターフェースを外部の世界にリダイレクトし、 一般的な外部スイッチに接続する事が出来ます。 ESM とパススルーモジュール(PM)の混成により、ネットワークは単一スイッチトポロジ (全 PM)か複数ネットワークトポロジ(1つ以上の ESM、0 以上の PM)のいずれかとして bonding から見えます。これはまた、ESM を一緒に接続し、結果として上記の「複数スイッ チトポロジの高可用性」での例によく似た設定にする事もできます。 特定のモードの要件 ------------------ balance-rr モードは、bond 中のデバイス用に、共通の外部スイッチへすべてが接続され たパススルーモジュール群の使用を要求します。このスイッチは、適切なポートを「イー サチャネル」又は「トランキング」に設定する必要があります。balance-rr 用にはそう するのが普通です。 balance-alb と balance-tlb モードはスイッチモジュールとパススルーモジュールのど ちらか(あるいは混成)で機能します。これらのモードで唯一固有の要件は、全てのネット ワークインターフェースが、bonding デバイス経由で送られる通信の為に、全ての目的地 に到着できなくてはならない事です(つまり、ネットワークは BladeCenter の外側のどこ かに集中している必要があります)。 active-backup モードには追加要件はありません。 リンク監視問題 -------------- イーサネットスイッチモジュールが組み込まれている時、ARP 監視のみが外部のスイッチ とのリンクロスを確実に検知します。これは特別な事ではなく、BladeCenter の箱の説明 にあるように、「外部」ネットワークポートはこのシステムのイーサネットポートであり、 「外部」ポートと JS20 システム自体のデバイスとの間にはスイッチが１つあるという事 です。MII 監視はESM と JS20 システム間のリンク失敗の検知のみ可能です。 パススルーモジュールが組み込まれている場合、MII 監視は JS20 システムに直接接続さ れた「外部」ポートの失敗を検知します。 他の関連事項 ------------ シリアル Over LAN (SoL) リンクはひとつ目のイーサネット(eth0)上でのみ確立します。 従って、eth0 へのリンクロスは SoL 接続を失う結果になります。SoL システムには bonding ドライバの制御が及ばないので、他のネットワーク通信にフェールオーバしませ ん。 bonding 使用時にフェールオーバ遅延問題を回避する為には、(内部の ESM と外部のスイッ チのどちらかで)スイッチのスパニングツリーの無効化が望ましいかもしれません。 15. よくある質問 ================ 1. bonding は SMP セーフですか？ はい。古い 2.0.xx チャネル結合パッチは SMP セーフではありませんでした。新しいド ライバは最初から SMP セーフになるよう設計されました。 2. どのタイプのカードが bonding で機能しますか？ どのイーサネットタイプのカードでも機能します(カードの混成でもできます。例えば、 Intel EtherExpress PRO/100 と 3com 3c905b)。ほとんどのモードでは、デバイスは同じ 速度である必要がありません。 バージョン 3.2.1 より、bonding は active-backup モードで Infiniband スレーブもサ ポートします。 3. bonding デバイスはいくつ作れますか？ 無制限です。 4. １つの bonding デバイスにはスレーブをいくつ加えられますか？ Linux がサポートするネットワークインターフェース数、あるいはシステムに組み込める ネットワークカード数でのみ制限されます。 5. スレーブリンクが死んだ時に何が起こりますか？ リンク監視が有効な場合、失敗したデバイスは無効化されます。active-backup モードで はバックアップリンクにフェールオーバし、他のモードでは失敗したリンクが無視されま す。リンク監視は継続され、その後リンクが復旧した場合、リンクは bond に再度加えら れます(モードにふさわしい何らかの方法で)。これ以上の情報は高可用性の章と各モード のドキュメントを参照してください。 リンク監視は(上記モジュールパラメータ章で説明した) miimon または arp_interval パ ラメータのどちらかで有効にできます。一般に、miimon は根底のネットワークデバイス により検知されたキャリア状態を監視し、ARP 監視(arp_interval)は LAN 上の他のホス トとの接続性を監視します。 リンク監視が設定されていない場合、bonding ドライバはリンク失敗を検知できず、全て のリンクが常に利用可能であると仮定します。これはパケットロスや性能低下の結果にな りかねません。厳密な性能低下は bonding モードとネットワーク設定に依存します。 6. bonding は高可用性用に使用できますか？ はい。詳細は高可用性の章を参照下さい。 7. どのスイッチ／システムが bonding と一緒に使えますか？ これの完全な回答は希望するモードに依存します。 基本的な負荷分散モード(balance-rr と balance-xor)では、イーサチャネル(トランキン グとも呼ばれる)をサポートするどのシステムとでも機能します。現在利用できるほとん どの設定可能スイッチはこのサポートがあり、多くの自動スイッチでも同様です。 先進負荷分散モード(balance-tlb、balance-alb)は特別なスイッチの要件がありませんが、 特定の機能をサポートしたデバイスドライバが必要です(上記のモジュールパラメータ下 の適切なセクションで説明しています)。 802.3ad モードでは、IEEE 802.3ad 動的リンク集合をサポートしたシステムと一緒に動 作します。現在、ほとんどの設定可能なスイッチと多くの自動スイッチは 802.3ad をサ ポートします。 active-backup モードはレイヤー２スイッチと一緒に動作します。 8. bonding デバイスはどこから MAC アドレスを取得しますか？ 固定 MAC アドレスを持つスレーブデバイス使用時、あるいは fail_over_mac オプション 有効時、bonding デバイスの MAC アドレスはアクティブスレーブの MAC アドレスです。 他の設定では、(ifconfig または ip link で)明示的に設定していない場合、bonding デ バイスの MAC アドレスはその最初のスレーブデバイスから得られます。この MAC アドレ スはその後に続くスレーブ全てに渡され、bonding デバイスがダウンになるか再設定され るまで(最初のスレーブが取り除かれた場合でも)永続的に残ります MAC アドレスを変更したい場合、ifconfig または ip link で設定できます。 # ifconfig bond0 hw ether 00:11:22:33:44:55 # ip link set bond0 address 66:77:88:99:aa:bb また、デバイスのダウンアップと、それからスレーブ(あるいはスレーブの順序)が変更さ れた場合にも MAC アドレスは変更されます。 # ifconfig bond0 down ; modprobe -r bonding # ifconfig bond0 .... up # ifenslave bond0 eth... この方法は、追加された次のスレーブからアドレスを自動的に取得します。 スレーブの MAC アドレスを復元する為には、bond からスレーブを取り外す必要がありま す(`ifenslave -d bond0 eth0`)。これにより、bonding ドライバはスレーブ化される前 にスレーブが持っていた MAC アドレスを復元します。 16. 資料とリンク ================ bonding ドライバの最新バージョンは http://kernel.org にある最新の Linux カーネル 中にあります。 このドキュメントの最新バージョンも、最新のカーネルソース中 (Documentation/networking/bonding.txt という名前)か、bonding sourceforge サイト のいずれかにあります。 http://www.sourceforge.net/projects/bonding bonding ドライバに関する議論は、sourceforge.net でホスティングされている bonding-devel メーリングリストで主に行われています。質問や問題があれば、それをメー リングリストに投稿してください。アドレスはこちら： bonding-devel@lists.sourceforge.net メーリングリストの管理インターフェース(加入あるいは脱退)はこちら： https://lists.sourceforge.net/lists/listinfo/bonding-devel Donald Becker のイーサネットドライバと検査プログラムはこちら： - http://www.scyld.com/network/ イーサネット、NWay、MII 等に関する大量の情報が www.scyld.com にあります。 -- END --