閲覧
ヘルプ
サインイン
Solved!
piroshiki
1 Rookie
•
28 メッセージ
0
51
2024年1月30日 01:30
VxRailを接続するスイッチを2台でリンクアグリゲーションしようと検討しています。
その場合、分散仮想スイッチ側の設定はどのようなものがありますでしょうか?
ロードバランシングのポリシーをIPハッシュに基づいたルートにするのかと思いましたが、ネットワークデザインガイドに下記のような記載があり気にしています。
VxRail does not support the route based on IP hash policy.
レスポンス(3)
DELL-Naoyuki K
4 Operator
1.7K メッセージ
1
2024年1月30日 03:20
Dynamic LAG (LACP)であれば明示的にサポートとされており、各種VxRailドキュメントやSolve Onlineの手順書からも確認できます。
IP Hashによるロードバランシングを検討ということはStatic LAGの利用を想定でしょうか?
Static LAGは7.0.130以降でサポートされ、一時期ドキュメントにも記載がありましたが、最新の資料と過去資料を比較するとStatic LAGの記載が消えていました。Dynamic LAGと異なり、Static LAGの場合はVxRailは構成を管理せず、完全に手動のプロセスになるためドキュメントにないという解釈もできますが、記載が消えている点は気がかりです。
Dynamic LAGやその他のロードバランシングポリシーで問題なければそちらでよいと思いますし、Static LAG(IP Hashベース)が必要ということであればRPQなどで確認したほうが無難と思われます。
なお、vSANネットワークのロードバランシングや各種ロードバランシングオプションの障害時の挙動などについては以下の記事もご参考にしてください。
https://itorwar.blogspot.com/2023/11/blog-post.html
https://itorwar.blogspot.com/2023/09/vsan-nic.html
2024年1月30日 08:52
>物理NICの負荷に基づいたルートや仮想ポートに基づいたルートはLAGの設定が不要な認識です。
はい。ご認識の通りです。
> LAGの設定が弊社で実績が少ないのと、手間もかかりそうなので利用しない方向で検討しようと思います。
VMware観点でも、VCFでLAGが利用できなかったりしてあまり推奨していない印象を受けますので、使わずに済むのであればそのほうが無難かと思います。
仮想マシンのトラフィックで利用する分にはある程度の仮想マシン数があれば、仮想ポートベースのポリシーでも問題なく負荷分散と帯域向上のメリットが得られます。
vSAN観点ではLAGを組んだほうが帯域を有効に使えるので、障害時のリビルドでは恩恵を受けやすかったり、高負荷(IOPS)においても遅延が安定したりというメリットもありますが、逆に障害時の性能低下が顕著になってしまったりもしますし、LAGで帯域を増やしてもネットワークの遅延は変わらないため、平時のIO遅延の改善という観点においては逆に25GbE/100GbEなどの高速なネットワークに集約してしまったほうが良いケースもあります。
2024年1月30日 08:42
ご丁寧にありがとうございます。
物理NICの負荷に基づいたルートや仮想ポートに基づいたルートはLAGの設定が不要な認識です。
LAGの設定が弊社で実績が少ないのと、手間もかかりそうなので利用しない方向で検討しようと思います。
デル サポート リソース
もっと見る
すべて表示
Top
DELL-Naoyuki K
4 Operator
4 Operator
•
1.7K メッセージ
1
2024年1月30日 03:20
Dynamic LAG (LACP)であれば明示的にサポートとされており、各種VxRailドキュメントやSolve Onlineの手順書からも確認できます。
IP Hashによるロードバランシングを検討ということはStatic LAGの利用を想定でしょうか?
Static LAGは7.0.130以降でサポートされ、一時期ドキュメントにも記載がありましたが、最新の資料と過去資料を比較するとStatic LAGの記載が消えていました。
Dynamic LAGと異なり、Static LAGの場合はVxRailは構成を管理せず、完全に手動のプロセスになるためドキュメントにないという解釈もできますが、記載が消えている点は気がかりです。
Dynamic LAGやその他のロードバランシングポリシーで問題なければそちらでよいと思いますし、Static LAG(IP Hashベース)が必要ということであればRPQなどで確認したほうが無難と思われます。
なお、vSANネットワークのロードバランシングや各種ロードバランシングオプションの障害時の挙動などについては以下の記事もご参考にしてください。
https://itorwar.blogspot.com/2023/11/blog-post.html
https://itorwar.blogspot.com/2023/09/vsan-nic.html
DELL-Naoyuki K
4 Operator
4 Operator
•
1.7K メッセージ
1
2024年1月30日 08:52
>物理NICの負荷に基づいたルートや仮想ポートに基づいたルートはLAGの設定が不要な認識です。
はい。ご認識の通りです。
> LAGの設定が弊社で実績が少ないのと、手間もかかりそうなので利用しない方向で検討しようと思います。
VMware観点でも、VCFでLAGが利用できなかったりしてあまり推奨していない印象を受けますので、使わずに済むのであればそのほうが無難かと思います。
仮想マシンのトラフィックで利用する分にはある程度の仮想マシン数があれば、仮想ポートベースのポリシーでも問題なく負荷分散と帯域向上のメリットが得られます。
vSAN観点ではLAGを組んだほうが帯域を有効に使えるので、障害時のリビルドでは恩恵を受けやすかったり、高負荷(IOPS)においても遅延が安定したりというメリットもありますが、逆に障害時の性能低下が顕著になってしまったりもしますし、LAGで帯域を増やしてもネットワークの遅延は変わらないため、平時のIO遅延の改善という観点においては逆に25GbE/100GbEなどの高速なネットワークに集約してしまったほうが良いケースもあります。
piroshiki
1 Rookie
1 Rookie
•
28 メッセージ
0
2024年1月30日 08:42
ご丁寧にありがとうございます。
物理NICの負荷に基づいたルートや仮想ポートに基づいたルートはLAGの設定が不要な認識です。
LAGの設定が弊社で実績が少ないのと、手間もかかりそうなので利用しない方向で検討しようと思います。