☰

LACP バインディングは、複数の同時プロセスがデータを送信するときに 1 つのインターフェイスを好むようです。

tag-icon • tag-icon networking bonding lacp
LACP バインディングは、複数の同時プロセスがデータを送信するときに 1 つのインターフェイスを好むようです。

これはおそらく非常に単純な問題です（つまり、根本的に何かが欠けており、これは私の誤り/知識の欠如/家庭です）。

したがって、2つのVLANを持つLACP（Ciscoスイッチ）を介してbond0にバインドされた2つの25GbEファイバを備えたシステムがあります。

あるソースからターゲットパスにさまざまなデータを転送するために5〜6個の同時rsyncを起動したとき、データはほぼ完全に1つの物理インターフェイス（〜900MiB / s）を好むという事実に少し驚きました。私は、ボンドを構成する2つのインターフェイス間に負荷がある程度分散すると仮定します。インターフェイスごとのネットワークトラフィックを示すGrafanaチャートイメージ

私はパケットがインターフェイス全体で別々のストリームに分割されていないことをよく知っていますが、私のrsyncはすべて別々のプロセスなので、少なくとも1つまたは2つが2番目の物理インターフェイスを使用すると予想しています。

参考として使用されているネットプラン構成の「おおよその」概要（つまり、機密情報が削除されたと見なされる情報を含む）：

network:
 version: 2
 renderer: networkd
 ethernets:
  eno1:
   dhcp4: false
   dhcp6: false
   optional: true
   link-local: []
  ens5f0np0:
   dhcp4: false
   dhcp6: false
   optional: true
  ens5f1np1:
   dhcp4: false
   dhcp6: false
   optional: true   
 bonds:
  bond0:
   dhcp4: false
   dhcp6: false
   interfaces: [ens5f0np0, ens5f1np1]
   mtu: 9000
   parameters:
    mode: 802.3ad
    lacp-rate: fast
    mii-monitor-interval: 100
 vlans:
  bond0.xxx:
   id: xxx
   link: bond0
   addresses: [ip]
   gateway4: ip
   mtu: 1500
   nameservers:
    search: [domains]
    addresses: [ips]
  bond0.xxx:
   id: xxx
   link: bond0
   addresses: [ip]
   mtu: 9000
   routes:
   - to: random subnet
     via: local subnet ip
   - to: random subnet
     via: local subnet ip
   - to: random subnet
     via: local subnet ip

問題は、rsyncが異なるプロセスですが、ソースと宛先IPが同じであり（各rsyncは1つの場所から大きなサブフォルダを読み取り、共通の場所にコピーする）、バインドで実行されることです。ハッシュは基本的にすべてを処理することを意味します。これは同じトラフィックですか？送信元データは1つのVLANにあるサーバーにあり、宛先サーバーは別のVLANにあります。

これが私の間違った/間違った仮定であれば、他のrsyncが別のデータ「ストリーム」を構成すると思うので、まだ同じ内容をすべて学びたいと思います。

ベストアンサー1

基本的にLACPレイヤ 2 XOR が使用されます。ポリシー:

発信トラフィックのスレーブ選択は、以下で選択できるトランスポートハッシュポリシーに基づいて行われます。基本的な単純XOR戦略xmit_hash_policy以下のオプションを見てください。

ステップ2

ハッシュ値は、ハードウェアMACアドレスとパケットタイプIDフィールドのXORを使用して生成されます。式は

hash = 送信元 MAC XOR 宛先 MAC XOR パケットタイプ ID スレーブ
番号 = ハッシュモードスレーブ数

このアルゴリズムは、同じスレーブデバイスの特定のネットワークピアにすべてのトラフィックを配置します。。

単一送信元MACアドレスで解決される単一送信元IPアドレスから単一宛先MACアドレスで解決される単一宛先IPアドレスへのトラフィックは、常に同じインターフェイスになりますlayer2。layer2+3

使用する必要がありますlayer3+4アルゴリズムにはインターフェイスの計算にポートが含まれます。

3+4階

このポリシーは、上位層のプロトコル情報（使用可能な場合）を使用してハッシュ値を生成します。これにより、特定のネットワークピアへのトラフィックが複数のスレーブにまたがる可能性があります。ただし、単一の接続が複数のスレーブにまたがるわけではありません。

ip linkオプションxmit_hash_policyに変換ネットワーク計画~のtransmit_hash_policy範囲。したがって、構成に次の追加パラメーターを追加する必要があります。

    transmit_hash_policy: layer3+4

トラフィックが同じ宛先に対して単一のアドレスにトンネリングされる場合、代わりに考慮することencap3+4ができます。

もっと興味が必要ですこの方針断片化があると、LACPに完全に準拠していないためです。レイヤ 4 のプロトコル (TCP/UDP...) ポートがフラグメントに含まれていないため、最初とそれ以降のフラグメントは異なるインターフェイスを使用し、到着時に不要なパケットへの接続を並べ替えることができます。関連するすべてのシステムが同じMTU（9000）を持つ限り、TCPは断片化を防止しようとするため、問題になりません。

このアルゴリズムは802.3adと完全に互換性がありません。断片化されたパケットと断片化されていないパケットを含む単一のTCPまたはUDPセッションでは、両方のインターフェイスでパケットストライピングが表示されます。これにより、誤った配送が発生する可能性があります。 [...]

おすすめ記事