リンクアグリゲーション（LAG）について、”Static LAG（静的LAG）”、”LACP”及び”roundrobin”の動作確認まで終えましたので、実際の物理インターフェース動作を確認して整理しておこうとおもいます。【注*1】
1.確認方法
NFSサーバー側での物理インターフェース動作を確認するために、
NFSクライアント（Ubuntu24.04）で、
を行い、NFSサーバーの、どの物理インターフェースが使われるかを確認します。
2.物理インターフェースの動作
(1)Static LAG（静的LAG）
- ”Static LAG”では、”１：１”の場合、物理インターフェース２つの内、一つだけ（re0）が使われています。
- ”１：ｎ”の場合、各クライアントからの要求量に合わせて、使う物理インターフェースが割り振られていきます。
(2)LACP（動的LAG）
- "LACP"も、”Static LAG”と同じく、”１：１”の場合、物理インターフェース２つの内、一つだけが使われています。
- ただし、”Static LAG”と異なり、（Ubuntuによる）NFS読み込み時には、re0／re1どちらの物理インターフェースもアクセスLEDが点滅しました。
- ”１：ｎ”の場合には、各クライアントからの要求量に合わせて、使う物理インターフェースが割り振られていきます。
- ”Static LAG”と異なり、"LACP"では受信エラー（Ierrs）が発生しています😅。
- 昔、”HPE DL380G7（FreeBSD8.4）"+"HPE 1GbE×4（PCIe×16）"＋"Netgear 24ポートL2スイッチ”を使ったLAGでは、”Ierrs”が出た記憶がありません😅。
- ”Static LAG”では”Ierrs”は出ていないので、”ケーブルの部分断線”や”スイッチの故障”等は考えにくいです。
- "LACP"では、”通信状態の監視を自動的に実施”するので、今回の安価なスイッチでは、性能が低くて、処理が追いついていない可能性がありそうです。
(3)roundrobin
- "roundrobin"では、送信データを500パケット毎（*2）にre0／re1の物理インターフェースを切り替えています。
- "roundrobin"では、スイッチ側から見ると、接続されている機器のMACアドレスが、500パケット毎（*3）に、2つのポートで順次変わっていることになります。
3.今後のLAGプロトコル選択
基本的に、今回、調達した安価なマネージスイッチ（*4）では、処理能力が不足していて、
”Static LAG（静的LAG）”以外では、パケットロスが多くなり、システム全体のパフォーマンス向上には役立たなそうな気がします😅。
NFSクライアントが多いのであれば、ビジネス用のL2スイッチを購入するのも手ですが、10万円近く（またはそれ以上）の投資をしても、小生の環境ではコスパは良くありません😅（*5）。
この後、メインファイルサーバーのメンテナンスが控えていますが、
メインファイルサーバーのメンテナンスの際には、基本、”Static LAG（静的LAG）”を使う事にしようと思います😅。
