コミュニティソリューション

ZimaOSにおけるイーサネットリンクアグリゲーション:LACP、ボンディング、ブリッジの混同、そして現在の制限

An October 2025-July 2026 feature discussion from a TrueNAS migrant who wanted to bond two 2.5GbE ports. Community members distinguished bridging from LACP, tried NetworkManager-style manual bonding without success, and continued requesting native GUI support. Current public ZimaOS networking docs still document ports individually rather than exposing a bonding workflow.

2つのEthernetポートを組み合わせる方法には、大きな違いがあります。元のユーザーが求めていたのは、2つの2.5GbEインターフェースでLACP/リンクアグリゲーションを構成し、NASの合計帯域幅と冗長性を高めることでした。一方、別のコミュニティスレッドでは、インターフェース間でトラフィックを転送するLinuxブリッジについて議論されていました。これらは同等の構成ではありません。

2025~2026年の元の議論では、検証済みの永続的なZimaOS LACP構成は確立されませんでした。ユーザーからはWebUIにボンディングの設定項目がないとの報告があり、元の投稿者はNetworkManager形式の設定を応用しようとしましたが、NetworkManagerの再起動やシステム全体の再起動を行っても、ボンドは機能しなかったと述べています。

ブリッジはLACPと同じではない

Linuxブリッジはレイヤー2でネットワークセグメントを接続し、ホストをある程度スイッチのように動作させます。ただし、2本のアップリンクを自動的に1本の論理5Gbps接続へ統合するわけではありません。

LACP/802.3adはボンディングされた論理インターフェースを作成し、通常はNASと管理対象スイッチの双方で互換性のある設定が必要です。

元のユーザーは2つの2.5GbEポートを1つのボンドにしたかった

システムにはオンボードの1GbE NICと、拡張カード上の2つの2.5GbEインターフェースがありました。ユーザーは、2つを単に別々のアドレスで使用するのではなく、集約することを望んでいました。

また、別の選択肢として、単一の10GbE NICを取り付け、対応するスイッチを使用する方法も認識していました。

元のユーザーはZimaOSのUIにLACP設定がないことを確認した

最初の返信では、WebUIからリンクアグリゲーションを利用できないと説明されました。その後も、2026年7月までユーザーからネイティブなボンディング対応を求める声が続いていました。

現在公開されているZimaOSのネットワークに関するドキュメントでは、物理ポートごとにリンク状態、速度、DHCP/手動IP、ゲートウェイ、DNS設定が示されています。LACP/ボンドの作成手順は記載されていません。

サポート対象の基準として、現在のZimaOSネットワークインターフェースモデルを使用してください。

NetworkManager形式の手動ボンディングが動作したことは確認されていない

元の投稿者は、ZimaOSが従来のDebianの/etc/network構成を使用しておらず、NetworkManager関連の設定が使われていることを確認しました。ボンドを作成するために接続ファイルをコピーして編集しましたが、NetworkManagerの再起動でも完全な再起動でも、望んだ結果は得られなかったと報告しています。

これは元の情報に基づく否定的な証拠です。動作するCLIチュートリアルとして扱うべきではありません。

スイッチ側だけのLACPでは不十分

管理対象スイッチがポートを集約できるのは、サーバー側も同じLACP/ボンディング構成に参加している場合だけです。ホスト側でボンディングを設定せずに、通常のZimaOSインターフェース2つを1つのLACPグループへ接続すると、MACアドレス学習が不安定になったり、接続が失われたりする可能性があります。

2本の2.5GbEリンクで1回のファイルコピーが5Gbpsになるわけではない

動作するLACP環境でも、トラフィックは通常、フローハッシュによって分散されます。1つのSMB/TCPフローは通常、1本のメンバーリンクを使い続けます。一方、複数のクライアントやセッションは、異なるリンクに分散される可能性があります。

そのため、リンクアグリゲーションは、複数クライアントによる合計帯域幅の向上やフェイルオーバーには最適ですが、1台のワークステーションによる単一ストリームの転送速度を確実に2倍にする方法ではありません。

単一の高速NICのほうがシンプルな場合が多い

実際の目的が、1台のクライアントで2.5Gbpsを超える速度で転送することなら、LACPよりも単一の10GbE経路のほうが理解しやすい場合があります。フローハッシュや管理対象スイッチのLAG設定に依存しないためです。

ただし、ストレージプールとクライアントが、そのリンクへ十分な速度でデータを供給できる必要があります。

このスレッドは機能要望のままだった

この元スレッドでは、IceWhaleのスタッフからネイティブなLACP対応を発表する返信はありませんでした。また、2026年7月の参加者も、公式の管理インターフェースにボンディング設定を追加するよう求めていました。

ZimaOSがサポート対象のボンディング手順を公開するまでは、ローカルコンソールへのアクセス手段と復旧方法を確保できない限り、リモートまたはヘッドレスのNASで永続的なホストネットワーク変更を行うのは避けてください。

リンクアグリゲーションに関するFAQ

ネットワークブリッジはLACPと同じですか?

いいえ。ブリッジはレイヤー2のトラフィックを転送します。LACPは、スイッチとの連携により、複数のリンクを1つの論理インターフェースへボンディングします。

元のスレッドでは、永続的に動作するZimaOSのボンドが確認されましたか?

いいえ。元の投稿者によるNetworkManagerの手動設定は動作しませんでした。

2本の2.5GbEによるLACPで、1回のSMBコピーは5Gbpsで動作しますか?

通常は動作しません。LACPは、複数の同時フローと冗長性に最も有効です。