ブロードキャストランナーを設定するには、root でエディターを使用して、以下をチームの JSON 形式設定ファイルに追加します。

{
 "device": "team0",
 "runner": {"name": "broadcast"},
 "ports": {"em1": {}, "em2": {}}
}

詳細情報は、teamd.conf(5) man ページを参照してください。

ランダムランナーは、ラウンドロビンランナーと同様の動作をします。

ランダムランナーを設定するには、root でエディターを使用して、以下をチームの JSON 形式設定ファイルに追加します。

{
 "device": "team0",
 "runner": {"name": "random"},
 "ports": {"em1": {}, "em2": {}}
}

詳細情報は、teamd.conf(5) man ページを参照してください。

ラウンドロビンランナーを設定するには、root でエディターを使用して、以下をチームの JSON 形式設定ファイルに追加します。

{
 "device": "team0",
 "runner": {"name": "roundrobin"},
 "ports": {"em1": {}, "em2": {}}
}

これが、ラウンドロビンの非常に基本的な設定になります。

詳細情報は、teamd.conf(5) man ページを参照してください。

アクティブバックアップランナーは、リンク監視すべてを使用してチーム内のリンクのステータスを判断することができます。以下のいずれかの例を 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 がアクティブになると、リンクが有効な間はずっと、このポートはアクティブのままになります。リンク変更はランナーに即座に反映されませんが、遅延は適用されます。

詳細情報は、teamd.conf(5) man ページを参照してください。

このランナーは、アクティブとパッシブという 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) 負荷分散の設定

詳細情報は、teamd.conf(5) man ページを参照してください。

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"
}

詳細情報は、teamd.conf(5) man ページを参照してください。

リンクのステータス監視は以下の方法があります。これらのいずれかを実装するには、root でエディターを使用して、JSON 形式の文字列をチームの JSON 形式設定ファイルに追加します。

"link_watch": {
       "name": "ethtool",
       "delay_up": 2500
}

"link_watch": {
       "name": "ethtool",
       "delay_down": 1000
}

{
       "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
             }
         }
}

~]# port config update em2 JSON-config-file

{
  "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
        }
      }
}

"link_watch": {
    "name": "nsna_ping",
    "interval": 200
}

"link_watch": {
    "name": "nsna_ping",
    "missed_max": 15
}

"link_watch": {
    "name": "nsna_ping",
    "target_host": "MyStorage"
}

フレームを送信する物理的なポートは通常、チームドライバーのカーネル部分が選択するもので、ユーザーまたはシステム管理者とは関係がありません。出力ポートは、選択されたチームモード (teamd ランナー) のポリシーを使用して選択されます。ただし場合によっては、送信トラフィックの特定クラスを特定の物理的インターフェースに向けて、やや複雑なポリシーを実装することが役に立つこともあります。デフォルトでは、チームドライバーはマルチキューを認識し、ドライバーが初期化されると 16 のキューが作成されます。キューの数を増減したい場合は、Netlink 属性 tx_queues を使って、チームドライバーのインスタンス作成中にこの値を変更することができます。

ポートのキュー ID は、以下のようにポート設定オプション queue_id で設定できます。

{
  "queue_id": 3
}

これらのキュー ID を tc ユーティリティーと合わせて使うとマルチキューのキュー規範を設定することができ、特定のポートデバイス上で特定のトラフィックが送信されるようにフィルターをかけることができます。たとえば、上記の設定を使用して 192.168.1.100 にバインドされたトラフィックすべてが出力デバイスとしてチームの eth1 を使用するように強制するには、以下の形式のコマンドを 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

トラフィックを特定ポートにバインドするためにランナー選択論理を上書きするこのメカニズムは、すべてランナーに使用できます。

負荷分散および LACP ランナーは、パケットのハッシュを使ってネットワークトラフィックのフローを分類します。ハッシュの計算メカニズムは、Berkeley Packet Filter (BPF) コードに基づいています。BPF コードは、送信パケットのポリシー判断の作成ではなく、ハッシュ生成のために使用されます。ハッシュの長さは 8 ビットで、256 バリアントになります。つまり、多くの異なる ソケットバッファー (SKB) は同じハッシュを持つことが可能で、このため同一リンクでトラフィックを渡すことになります。短いハッシュを使うと、複数のリンクに負荷を分散する目的でトラフィックを異なるストリームにすばやく分類できます。静的モードでは、トラフィックをどのポートに送信するかを判断するためだけにハッシュが使用されます。アクティブモードでは、ランナーは継続的にハッシュを異なるポートに割り当て、完全な負荷分散を試みます。

パケット Tx ハッシュの計算には、以下の断片化されたタイプまたは文字列が使用できます。

これらの文字列は、以下の形式で負荷分散ランナーに行を追加して使用できます。

"tx_hash": ["eth", "ipv4", "ipv6"]

例については、「負荷分散ランナーの設定」を参照してください。