朝から昼寝

ITや家計、身近なことの整理

[お知らせ]
当サイトは、2024年1月1日に
新URL(happynap.net)に引っ越しました





このページの内容は、最新ではない場合がありますので、新URLをご確認ください。






当サイトには広告を含みます。"オススメ"として紹介している商品やサービスは、個人的にそう思えたものだけです。
共感、興味をもっていただけるものがあればご利用ください (広告掲載ポリシー)。

ESXiサーバのLAG設定

概要

VMware vSphere環境において、ESXiサーバの性能向上のためLAGを使用することがあります。リンクアグリゲーション、IEEE802.3ad(IEEE802.1AX-2008)のことです。呼び方は、ポートチャネルや、CiscoではEtherChannel、HPEではトランク等…。
本記事は、ESXiサーバにおけるLAG設定の概要をまとめたものです。 主な対象はESXi 6系、7系です。

本記事の目的

  • ESXiサーバのLAG設定の概要を把握する。
  • 設定のポイントや、接続先の物理スイッチと一致させる設定箇所を把握する。


目次

基本

ESXiサーバで利用可能なLAG構成

使用する仮想スイッチの種類により、サポートされるLAG構成が異なります。

仮想スイッチ種別 サポートされるLAG構成
標準仮想スイッチ(vSS) static LAG(静的)のみ
分散仮想スイッチ(vDS) static LAG(静的)、およびLACP(動的)

vDSは、vSphere Enterprise Plus相当で利用可能です。vSphere Standardでは利用できません。
当然ですが、ESXiサーバの接続先となる物理スイッチでも使用するLAG構成をサポートしている必要性があります。

ESXiサーバにおけるLAGの用途や基本構成

LAGを構成することで、より大きなネットワーク帯域の確保や、ネットワーク障害時にも運用継続するためのNIC冗長性の確保ができます。
例えば、以下のトラフィック用にLAGを適用する構成が考えられます。

  • 仮想マシン(ゲスト)がESXiサーバの外と通信する際のトラフィック
  • ESXiホストがストレージと通信する際のトラフィック
    ※ただし、iSCSIマルチパスとの併用は未サポート(後述)

LAG構成では、必要に応じて以下の構成も検討します。

  • 10Gbps NIC (もしくはより大きな帯域:40Gbps等)
  • ジャンボフレーム
  • ESXiサーバ側でLAGを構成する物理ポートは、複数のネットワークカードから構成(1つのネットワークカード障害時の運用継続)
  • 物理スイッチ側でLAGを構成する物理ポートは、複数の筐体から構成(1つの筐体の障害時の運用継続)
    ※スタック構成やマルチシャーシLAG(MLAG)等

static LAGの設定

標準仮想スイッチもしくは分散仮想スイッチにて対象NICのチーミングを構成し、物理スイッチのstatic LAGを設定したポートと接続します。

static LAGの場合、仮想スイッチ側の設定におけるポイントは以下です。

  • 仮想スイッチのロードバランシングモードは「IPハッシュに基づいたルート」
  • ネットワーク障害検出ポリシーは「リンクステータスのみ」
  • すべてのNICを「アクティブ」

以下、参考になるVMwareのdocsです。

LACPの設定

分散仮想スイッチにて対象NICのチーミング(LAGという設定項目)を構成し、物理スイッチのLACPを設定したポートと接続します。
LACPの場合、仮想スイッチ側の設定におけるポイントは以下です。

  • 仮想スイッチのLAGのロードバランシングモード(ハッシュアルゴリズム)は物理スイッチ側のハッシュアルゴリズムと一致
  • 物理NICでなく作成したLAGを「アクティブ」なアップリンクに設定

以下、参考になるVMwareのdocsです。

詳細

注意点

LAGとiSCSIマルチパスの併用は未サポート

ESXiにてLAGを構成するNICを、iSCSIマルチパスに使用することはVMware社にてサポートされていません(iSCSIマルチパス:複数のvmnicをそれぞれiSCSI用にポートバインドさせるソフトウェアベースの冗長パス構成)。
異なるレイヤの冗長化機能を同時に使用することになるためと思われます。
分かりやすい説明が見当たりませんでしたが、VMware社のKBに、「iSCSI ソフトウェアのマルチパスには使用しないでください」といった記載があります。

LAGの動作確認、通信不可時の切り分け

LAGを構成したポートが意図通りに動作しているか動作確認の観点についてです。

うまく通信ができない場合や、あるいはうまく通信できているように見えても実は設定が間違っている場合があるかもしれません。例えば、設定が間違っている場合、パケットロスが一部発生して通信が不安定になる等、ハッキリとしたトラブルとして捉えづらい現象が発生する可能性もあります。
本稼働後のトラブルを防ぐために、本番運用における負荷や利用形態を想定した動作確認をお勧めします。

以下のような観点が挙げられます。

  • ESXiサーバ側(あるいは物理スイッチ側)の対象NICを一部切断し冗長性の確認
  • 物理スイッチ側のログやステータス確認コマンドにて、LAGのネゴシエーションが意図通りに成功していることの確認(特にLACP使用時)
  • 動作確認用にトラフィックを発生させ、スループットの十分性や、遅延やロスが無いことの確認
    • スループット:大きな/多くのファイルコピー等によるトラフィック発生
    • 遅延やロス:ping等の遅延やロスを集計可能なツールの使用
    • その他:本番運用を想定したアプリケーション動作によるトラフィック発生
    • さらに上記の冗長性の確認と組み合わせ、NICの冗長性が失われた際にもアプリケーションレベルで動作に影響が無いことの確認
  • ジャンボフレームを使用している場合は、ジャンボフレーム疎通の十分性
    • ジャンボフレームのping疎通確認方法については、別記事に記載あり