Show Table of Contents
8.13. teamd ランナーの設定
ランナーとは、デーモンのインスタンスが作成される際に、チームデーモンにコンパイルされるコードのユニットです。
teamd
ランナーについては、「ネットワークチーミングデーモンおよび「ランナー」について」を参照してください。
8.13.1. ブロードキャストランナーの設定
ブロードキャストランナーを設定するには、
root
でエディターを使用して、以下をチームの JSON 形式設定ファイルに追加します。
{ "device": "team0", "runner": {"name": "broadcast"}, "ports": {"em1": {}, "em2": {}} }
詳細情報は、man ページの
teamd.conf(5)
を参照してください。
8.13.2. ランダムランナーの設定
ランダムランナーは、ラウンドロビンランナーと同様の動作をします。
ランダムランナーを設定するには、
root
でエディターを使用して、以下をチームの JSON 形式設定ファイルに追加します。
{ "device": "team0", "runner": {"name": "random"}, "ports": {"em1": {}, "em2": {}} }
詳細情報は、man ページの
teamd.conf(5)
を参照してください。
8.13.3. ラウンドロビンランナーの設定
ラウンドロビンランナーを設定するには、
root
でエディターを使用して、以下をチームの JSON 形式設定ファイルに追加します。
{ "device": "team0", "runner": {"name": "roundrobin"}, "ports": {"em1": {}, "em2": {}} }これが、ラウンドロビンの非常に基本的な設定になります。
詳細情報は、man ページの
teamd.conf(5)
を参照してください。
8.13.4. アクティブバックアップランナーの設定
アクティブバックアップランナーは、リンク監視すべてを使用してチーム内のリンクのステータスを判断できます。以下のいずれかの例を JSON 形式の設定ファイルに追加できます。
{ "device": "team0", "runner": { "name": "activebackup" }, "link_watch": { "name": "ethtool" }, "ports": { "em1": { "prio": -10, "sticky": true }, "em2": { "prio": 100 } } }上の設定例では、ethtool のアクティブバックアップランナーをリンク監視として使用します。ポート em2 の優先度が高くなります。sticky フラグにより、em1 がアクティブになると、リンクが有効な間はずっと、このポートはアクティブのままになります。
{ "device": "team0", "runner": { "name": "activebackup" }, "link_watch": { "name": "ethtool" }, "ports": { "em1": { "prio": -10, "sticky": true, "queue_id": 4 }, "em2": { "prio": 100 } } }上の設定例では、queue ID
4
が追加されます。ethtool のアクティブバックアップランナーをリンク監視として使用します。ポート em2 の優先度が高くなりますが、sticky フラグにより、em1 がアクティブになると、リンクが有効な間はずっと、このポートはアクティブのままになります。
ethtool をリンク監視として使用するアクティブバックアップランナーを設定し、遅延を適用するには、
root
でエディターを使用して、以下をチームの JSON 形式設定ファイルに追加します。
{ "device": "team0", "runner": { "name": "activebackup" }, "link_watch": { "name": "ethtool", "delay_up": 2500, "delay_down": 1000 }, "ports": { "em1": { "prio": -10, "sticky": true }, "em2": { "prio": 100 } } }上の設定例では、ethtool のアクティブバックアップランナーをリンク監視として使用します。ポート em2 の優先度が高くなります。sticky フラグにより、em1 がアクティブになると、リンクが有効な間はずっと、このポートはアクティブのままになります。リンク変更はランナーに即座に反映されませんが、遅延は適用されます。
詳細情報は、man ページの
teamd.conf(5)
を参照してください。
8.13.5. 負荷分散ランナーの設定
このランナーは、アクティブとパッシブという 2 つのタイプの負荷分散に使用できます。アクティブモードでは、最近のトラフィックの統計値を使用して、トラフィックをできるだけ均一に共有することで、持続的なトラフィックの再分散が図られます。パッシブモードでは、トラフィックのストリームが利用可能なリンクにランダムに分配されます。この方法では処理オーバーヘッドが低くなることから、速度面で有利になります。トラフィックのボリュームが大きいアプリケーションでは、トラフィックは通常、利用可能なリンク間でランダムに分配される複数のストリームで構成されるため、この方法が好まれます。この方法により、
teamd
が介入することなく負荷共有が実施されます。
パッシブ送信 (Tx) 負荷分散機能向けに負荷分散ランナーを設定するには、
root
でエディターを使用して、以下をチームの JSON 形式設定ファイルに追加します。
{ "device": "team0", "runner": { "name": "loadbalance", "tx_hash": ["eth", "ipv4", "ipv6"] }, "ports": {"em1": {}, "em2": {}} }ハッシュベースのパッシブ送信 (Tx) 負荷分散の設定
アクティブ送信 (Tx) 負荷分散機能向けに負荷分散ランナーを設定するには、
root
でエディターを使用して、以下をチームの JSON 形式設定ファイルに追加します。
{ "device": "team0", "runner": { "name": "loadbalance", "tx_hash": ["eth", "ipv4", "ipv6"], "tx_balancer": { "name": "basic" } }, "ports": {"em1": {}, "em2": {}} }基本的ロードバランサーを使用したアクティブ送信 (Tx) 負荷分散の設定
詳細情報は、man ページの
teamd.conf(5)
を参照してください。
8.13.6. LACP (802.3ad) ランナーの設定
ethtool をリンク監視として使用する LACP ランナーを設定するには、
root
でエディターを使用して、以下をチームの JSON 形式設定ファイルに追加します。
{ "device": "team0", "runner": { "name": "lacp", "active": true, "fast_rate": true, "tx_hash": ["eth", "ipv4", "ipv6"] }, "link_watch": {"name": "ethtool"}, "ports": {"em1": {}, "em2": {}} }接続先が link aggregation control protocol (LACP) に対応している場合の接続の設定になります。LACP ランナーは ethtool を使用してリンクのステータスを監視します。ethtool だけが、リンク監視に使用できます。たとえば arp_ping の場合、リンクがアップにならないためです。この理由は、リンクが最初に確立される必要があり、その後でのみ、ARP を含むパケットが送信可能となるためです。ethtool は、リンク層を個別に監視するため、リンクが確立されていないために認識されないという事態を防ぎます。
このランナーでは、負荷分散ランナーを使用した場合と同様の方法でアクティブ負荷分散が可能になります。アクティブ送信 (Tx) 負荷分散を有効にするには、以下のセクションを追加します。
"tx_balancer": { "name": "basic" }
詳細情報は、man ページの
teamd.conf(5)
を参照してください。
8.13.7. リンクのステータス監視の設定
リンクのステータス監視は以下の方法があります。これらのいずれかを実装するには、
root
でエディターを使用して、JSON 形式の文字列をチームの JSON 形式設定ファイルに追加します。
8.13.7.1. リンクのステータス監視用の Ethtool 設定
リンクがアップになってからそれがランナーに通知されるまでの既存の遅延 (ミリ秒単位) を編集する、または追加するには、以下のセクションを追加もしくは以下のように編集します。
"link_watch": { "name": "ethtool", "delay_up": 2500 }
リンクがダウンになってからそれがランナーに通知されるまでの既存の遅延 (ミリ秒単位) を編集する、または追加するには、以下のセクションを追加もしくは以下のように編集します。
"link_watch": { "name": "ethtool", "delay_down": 1000 }
8.13.7.2. リンクのステータス監視用の ARP Ping の設定
チームデーモン
teamd
は、リンクがアップかどうかを判断するために、ARP 要求をリンクのリモート側のアドレスに送信します。使用される方法は arping ユーティリティーと同様ですが、このユーティリティーは使用しません。
以下のような JSON 形式の新規設定を含むファイルを準備します。
{ "device": "team0", "runner": {"name": "activebackup"}, "link_watch":{ "name": "arp_ping", "interval": 100, "missed_max": 30, "source_host": "192.168.23.2", "target_host": "192.168.23.1" }, "ports": { "em1": { "prio": -10, "sticky": true }, "em2": { "prio": 100 } } }この設定では、arp_ping をリンク監視として使用します。
missed_max
オプションは、実行されなかった返信 (たとえば ARP 返信) の最大許容数です。これは interval
オプションとともに選択し、リンクがダウンだと報告されるまでの合計回数を決定します。
JSON 設定を含んでいるファイルからチームポート em2 用に新規設定を読み込むには、
root
で以下のコマンドを実行します。
~]# teamdctl port config update em2 JSON-config-file古い設定は上書きされ、省略されたオプションはデフォルト値にリセットされることに注意してください。他のチームデーモンの制御ツールコマンド例については、
teamdctl(8)
man ページを参照してください。
8.13.7.3. リンクのステータス監視用の IPv6 NA/NS の設定
{ "device": "team0", "runner": {"name": "activebackup"}, "link_watch": { "name": "nsna_ping", "interval": 200, "missed_max": 15, "target_host": "fe80::210:18ff:feaa:bbcc" }, "ports": { "em1": { "prio": -10, "sticky": true }, "em2": { "prio": 100 } } }
NS/NA パケットの送信間隔を設定するには、以下のセクションを追加もしくは以下のように編集します。
"link_watch": { "name": "nsna_ping", "interval": 200 }ここでの値は、ミリ秒単位の正の数になります。これは
missed_max
オプションとともに選択して、リンクがダウンだと報告されるまでの合計回数を決定します。
リンクがダウンだと報告されるまでの、実行されなかった NS/NA 返信パケットの最大数を設定するには、以下のセクションを追加もしくは以下のように編集します。
"link_watch": { "name": "nsna_ping", "missed_max": 15 }実行されなかった NS/NA 返信パケットの最大数。この数を超えると、リンクがオフラインになっていると報告されます。
missed_max
オプションは、実行されなかった返信 (たとえば ARP 返信) の最大許容数です。これは interval
オプションとともに選択して、リンクがダウンだと報告されるまでの合計回数を決定します。
NS/NA パケットの
IPv6
ターゲットアドレスを解決するホスト名を設定するには、以下のセクションを追加もしくは以下のように編集します。
"link_watch": { "name": "nsna_ping", "target_host": "MyStorage" }「target_host」オプションには、
IPv6
アドレスに変換され、NS/NA パケットのターゲットアドレスとして使用されるホスト名が含まれます。IPv6
アドレスは、ホスト名の代わりとして使用できます。
詳細情報は、man ページの
teamd.conf(5)
を参照してください。
8.13.8. ポート選択上書きの設定
フレームを送信する物理的なポートは、通常、チームドライバーのカーネル部分が選択するもので、ユーザーまたはシステム管理者とは関係がありません。出力ポートは、選択されたチームモード (
teamd
ランナー) のポリシーを使用して選択されます。ただし場合によっては、送信トラフィックの特定クラスを、特定の物理的インターフェースに向けて、やや複雑なポリシーを実装することが役に立つこともあります。デフォルトでは、チームドライバーはマルチキューを認識し、ドライバーが初期化されると 16 のキューが作成されます。キューの数を増減する必要がある場合は、Netlink 属性 tx_queues
を使用して、チームドライバーのインスタンス作成中にこの値を変更できます。
ポートのキュー ID は、以下のようにポート設定オプション
queue_id
で設定できます。
{ "queue_id": 3 }これらのキュー ID を tc ユーティリティーと合わせて使うとマルチキューのキュー規範を設定でき、特定のポートデバイス上で特定のトラフィックが送信されるようにフィルターをかけることができます。たとえば、上記の設定を使用して
192.168.1.100
にバインドされたトラフィックすべてが出力デバイスとしてチームの enp1s0 を使用するように強制するには、以下の形式のコマンドを root
で実行します。
~]#トラフィックを特定ポートにバインドするためにランナー選択論理を上書きするこのメカニズムは、すべてランナーに使用できます。tc qdisc add dev team0 handle 1 root multiq
~]#tc filter add dev team0 protocol ip parent 1: prio 1 u32 match ip dst \
192.168.1.100 action skbedit queue_mapping 3
8.13.9. BPF ベースの Tx ポートセレクターの設定
負荷分散および LACP ランナーは、パケットのハッシュを使ってネットワークトラフィックのフローを分類します。ハッシュの計算メカニズムは、Berkeley Packet Filter (BPF) コードに基づいています。BPF コードは、送信パケットのポリシー判断の作成ではなく、ハッシュ生成のために使用されます。ハッシュの長さは 8 ビットで、256 バリアントになります。つまり、多くの異なる ソケットバッファー (SKB) は同じハッシュを持つことが可能で、このため同一リンクでトラフィックを渡すことになります。短いハッシュを使うと、複数のリンクに負荷を分散する目的でトラフィックを異なるストリームにすばやく分類できます。静的モードでは、トラフィックをどのポートに送信するかを判断するためだけにハッシュが使用されます。アクティブモードでは、ランナーは継続的にハッシュを異なるポートに割り当て、完全な負荷分散を試みます。
パケット Tx ハッシュの計算には、以下の断片化されたタイプまたは文字列が使用できます。
eth
: ソースおよび宛先 MAC アドレスを使用。vlan
: VLAN ID を使用。ipv4
- ソースおよび宛先IPv4
アドレスを使用。ipv6
- ソースおよび宛先IPv6
アドレスを使用。ip
:IPv4
とIPv6
のソースおよび宛先アドレスを使用。l3
:IPv4
とIPv6
のソースおよび宛先アドレスを使用。tcp
- ソースおよび宛先TCP
ポートを使用。udp
- ソースおよび宛先UDP
ポートを使用。sctp
- ソースおよび宛先SCTP
ポートを使用。l4
:TCP
、UDP
およびSCTP
のソースおよび宛先ポートを使用。
これらの文字列は、以下の形式で負荷分散ランナーに行を追加して使用できます。
"tx_hash": ["eth", "ipv4", "ipv6"]例については、「負荷分散ランナーの設定」を参照してください。