Linuxボンディング：802.3ad（LACP）とbalance-albモード
これが状況です。フォールトトレランスと負荷分散の理由から、デュアルリンクを使用してLinuxサーバーを単一のネットワークに接続したいと思います。サーバーには2つ以上の1ギガNICがあり、それぞれを単一のスタックにある異なるスイッチ（つまり、単一の仮想スイッチ）に接続する予定です。すべてのスイッチはJuniper EX4200またはEX4500です。
Linuxのどのボンディングモードでも使用できることは知っていますが、何が最適なのでしょうか。一部のサーバーは非スタックスイッチに接続していたため、これまではアクティブバックアップモードを使用していましたが、現在は一貫した新しいネットワークがあり、フォールトトレランスに加えてロードバランシングを提供するボンディングモードを使用したいと考えています。
使用するのに最適なモードは802.3ad（LACP）だと思いました。これは、すべてのネットワーク機器で使用されている標準だからです。しかし、スイッチの側でLACPチャネルとしてポートのセットを構成した瞬間に、接続が切断されるまで接続が切れます。また、サーバー側を適切に構成します。新しいサーバーをインストールする前にスイッチのLACP構成を削除する必要があるため（PXEブートやネットワークインストールなどがLACPポートで機能しないため）、インストール後にスイッチを変更する必要があるため、システム管理タスクがはるかに困難になります。設定を再度行いますが、サーバーがLACPを使用するように構成された後でないと、接続が停止します。
Balance-albなどの他のボンディングモードは、スイッチ側で特別な構成を必要としませんが、紙の上では同じ利点があります。
Balance-albの代わりに802.3adを選択する理由はありますか？
私はジュニパーのスイッチにそれほど精通していませんが、LACPを構成する必要はありません。そのis LACPのポイント。そうでない場合は、スイッチ構成に問題があります。
LACPは、ポートを動的に集約するためのプロトコルのみを指定します。 （トラフィックが送受信される）ポートスケジューリングポリシーは指定しません。このポリシーは個別に設定されます。 Linuxでのプロセスを覚えていませんが、Linuxは、おそらくバランス-albと同様に、いくつかの異なるポリシーでの指定をサポートしていることを知っています。
Balance-albには特定の欠点があります。主に、それは新しい接続用の発信ポートを半インテリジェントに選択し、それらは接続の存続期間中その1つのポートにスタックします（ポートではなく、MACによって実際に行われ、ポートが失敗した場合、MACは別のポートに割り当てられます） 、したがって、接続を続行できます）。
ただし、接続は複数のポートを利用できないため、これはポートを正確に「集約」するものではありません。したがって、1 GbEポートが2つある場合でも、1つの接続は1 GbEに制限されます。 LACPは通常これを解決しますが、スケジューリングポリシーと両端でサポートされるアクティブポートの数によって異なります。
Balance-albでは、MACアドレスの変更のトリックを使用して、送信フレームと受信フレームの両方が負荷分散されます。これにより、アプリケーションレベルで問題が発生する可能性があります。すべてのアプリケーションがこのモードに対応しているわけではありません。
元の問題を処理します。これが私が以前やっていたことです。
- スイッチポートはデフォルトのままにします。
- Pxe-Kickstartインストールを実行します。
- KSインストール後のレベルまたは管理インフラストラクチャ "puppet/chef"のいずれかで、スイッチポートの構成をLACPに変更します "すべてのデバイスによってネットワーク上に信頼されたサーバーがあると仮定します"
チャクリ-
ボックスがLACPを使用するように接続するポートにLACPを設定した場合、ホスト側の唯一の「正しい」設定はLACPを使用することです。 EXは、イーサネットトラフィックのイーサネット送信元および宛先MACに従ってバランスをとり、フレームにIPパケットがある場合、IPトラフィックのIP送信元/宛先/ポートを考慮します。ハッシュアルゴリズムの詳細については、 Juniper KB2294 をお読みください。スイッチがクロススタックLACPをサポートしている場合（これは4XXX EXの場合です）、スタックがある場合はLACPを使用します。 VLANループなどを使用したより複雑なL2トポロジがある場合は、デバッグが容易になる場合もあります。
LACPは、それが機能する場合に最適であり、単一のNICのほぼ2倍のパフォーマンスを提供します。 NICが結合されているマシンが少数しかない場合は、それを試してください。
ただし、短所の1つは、予算が少なすぎるためにローエンドスイッチを使用すると、十分なLACPグループが不足し、MLAGまたはSMLT機能が不足する傾向があることです。最低でも、HPおよび類似のほとんどのスイッチは、半分のポート数と同じ数のボンディンググループしか提供しないようです。一部はさらに少ないを提供しています。ある時点で使用していた2kスーパーマイクロスイッチには、52個のポートがあるにもかかわらず、LACPグループは8つしかありませんでした。この数は比較的恣意的だと思います。スイッチポートの数が1/2を超える必要があるとは誰も考えていません。これはおそらくファームウェアにハードコードされた数値であり、おそらくもう少し多くのメモリを消費します。
しかし、SR-IOV、ボンディング、および仮想マシンを使用する場合、これは本当に大きな制限です。
ラックで数百または数千のマシンをホストするプロバイダーである場合、冗長性とパフォーマンスを提供するためだけに重要であるが不必要に高価なハイエンドスイッチに数万ドルを費やす必要はありません。マシンの単一ラック。 facebookのような企業が独自のスイッチを作成する理由を理解できます。
したがって、このタイプのシナリオでは、別のモード、おそらくバランスアルブを使用します。