8.13. teamd ランナーの設定

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

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

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

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

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

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

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

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

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

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

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

アクティブバックアップランナーは、リンク監視すべてを使用してチーム内のリンクのステータスを判断できます。以下のいずれかの例を JSON 形式の設定ファイルに追加できます。

{
   "device": "team0",
   "runner": {
      "name": "activebackup"
   },
   "link_watch": {
      "name": "ethtool"
   },
   "ports": {
      "em1": {
         "prio": -10,
         "sticky": true
      },
      "em2": {
         "prio": 100
      }
   }
}

この設定例では、ethtool でアクティブバックアップランナーをリンク監視として使用します。ポート em2 に高い優先度が設定されています。スティッキーフラグにより、 em1 がアクティブになると、リンクが起動している限りアクティブな状態が維持されます。

{
   "device": "team0",
   "runner": {
      "name": "activebackup"
   },
   "link_watch": {
      "name": "ethtool"
   },
   "ports": {
      "em1": {
         "prio": -10,
         "sticky": true,
         "queue_id": 4
      },
      "em2": {
         "prio": 100
      }
   }
}

この設定例では、4 のキュー ID を追加します。ethtool でアクティブバックアップランナーをリンク監視として使用します。ポート em2 に高い優先度が設定されています。ただし、スティッキーフラグにより、 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 に高い優先度が設定されています。ただし、スティッキーフラグにより、 em1 がアクティブになると、リンクが起動している限りアクティブな状態が維持されます。リンク変更はランナーに即座に反映されませんが、遅延は適用されます。

詳細は、man ページの teamd.conf (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) を参照してください。

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) を参照してください。

リンクのステータス監視は以下の方法があります。メソッドのいずれかを実装するには、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
             }
         }
}

~]# teamdctl 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 にバインドされているすべてのトラフィックを強制的に使用させる場合 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

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

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

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

これらの文字列は、負荷分散ランナーに行を追加することによって使用できます。

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

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