ロードバランシング設定とリンク障害～復旧時の挙動について

 

リンク障害とActive/Standbyの挙動について

Active/Standby、つまりNIC Teamingのロードバランシングで「明示的なFailover順序の使用」を選択し、ネットワーク障害検出で「リンク状態のみ」を選んだ場合の挙動について確認する





 

この場合は非常にシンプルな挙動となる。

つまり、平時は常にActiveに設定されたUplinkを利用し、Link Downが発生するとStandbyのUplinkに切り替わる。

そして、Link復旧後は元のUplinkに戻ってくる（※Failbackが有効）

 

 

リンク障害とActive/Active ”発信元の仮想ポートに基づいたルート”について

次に、「発信元の仮想ポートに基づいたルート」を利用した場合の以下の挙動について確認する



 

該当のロードバランシング設定については以下のドキュメントに説明がある

発信元の仮想ポートに基づいたルート (vmware.com)

 

上記の設定においては、各仮想ポートに対し、Uplink利用の優先順位が基本的に固定的に割り当てられるため、Linkダウン時にもう片方のUplinkにFailoverした場合、Link復旧後には元のUplinkに戻ってくる挙動となることを実機で確認した。

 

 

 

リンク障害とActive/Active ”物理NICの負荷に基づいたルート”について

次に「物理NICの負荷に基づいたルート」の挙動について確認した。

 

 

物理 NIC 負荷に基づいたルート (vmware.com)

 

 

この設定の場合、ドキュメントの説明にもある通り、物理NICの負荷に応じて利用するUplinkを動的に決めるため、

「仮想ポートに基づくルート」のように各仮想ポート毎に個別優先順位が設定されているわけではない、

そのため、リンク障害時にFailoverしたのち、リンクが復旧したとしても、その際に物理NICの使用率が75％を超えていなければ、

Uplinkの再アサインが発生しないため、自動的にFailbackすることはない。（実機で確認）

 

というか、今まで気づいていなかった（というかこのポリシーを使っていなかった）のだが、このポリシーにするとNIC チーミングの自動Failbackの設定項目自体がなくなっている。

 

 

スタンバイアップリンクがあるとどうなるのか

「物理NICの負荷に基づいたルート」のパターンにてスタンバイアップリンクがあるとどうなるのかを調べた。

 

パターン①：ActiveとStandbyが1本ずつの場合

以下の構成で確認した。

 

 

この条件では平常時のUplinkは常にアクティブに寄っていた。

アクティブアップリンクのリンクダウン時はすべてスタンバイ側に寄っていた。

アクティブアップリンクのリンクが復旧すると、すべてアクティブアップリンクに戻ってきた。

※実機で確認

 

 

パターン②：Activeが2本、Standbyが1本の場合

以下の構成で確認した



この条件では平常時は該当PGの仮想ポートはUplink1とUplink2で分散されていた。（初期状態）

Uplink1を落としたらすべてがUplink2に寄った。

Uplink1を復旧してもUplink2にに寄ったままだった。

Uplink2を落としたらUplink1とUplink3で分散された

Uplink2を復旧したらUplink3を利用していたポートのみがUplink2を使用する状態にかわった（初期状態にもどった）

※実機で確認

 

 

パターン③：Active2本、Standby2本の場合

以下の構成で確認した


 

この条件では平常時は該当PGの仮想ポートはUplink1とUplink2で分散されていた。（初期状態）

Uplink1を落としたらすべてがUplink2に寄った。

Uplink1を復旧してもUplink2にに寄ったままだった。

Uplink2を落としたらUplink1とUplink3で分散された

Uplink2を復旧したらUplink3を利用していたポートのみがUplink2を使用する状態にかわった（初期状態にもどった）

※実機で確認

 

パターン②と全く同じ結果となった。今回の検証ではUplink4は利用されなかった。

 

パターン④：Active1本、Standby2本の場合

以下の構成で確認



 

この条件では平常時は該当PGの仮想ポートはすべてUplink1を利用している（初期状態）

Uplink1を落としたらすべてがUplink2に寄った。

さらにUplink2も落としたらUplink3にすべて寄った

その状態でUplink2を復旧させたらUplink2にすべて寄った（Standby同士ではFailbackのような動作になる）

最後にUplink1を復旧させたらすべてUplink1に寄った（初期状態に戻った）

※実機で確認

 

「物理NICの負荷に基づいたルート」の場合、Active アップリンク間でのFailbackは発生しないが、

Standby アップリンク間ではFailbackのような挙動となることが分かった。

 

 

パターン⑤：Active1本、Standby2本の場合（順序入れ替え）

以下の構成で確認（Uplink2とUplink3の順序が逆）



 

この条件では平常時は該当PGの仮想ポートはすべてUplink1を利用している（初期状態）

Uplink1を落としたらすべてがUplink3に寄った。

さらにUplink3も落としたらUplink2にすべて寄った

その状態でUplink3を復旧させたらUplink3にすべて寄った（Standby同士ではFailbackのような動作になる）

最後にUplink1を復旧させたらすべてUplink1に寄った（初期状態に戻った）

※実機で確認

 

Standby アップリンクの挙動がパターン④と逆になった。

このことから、ロードバランシングポリシーはActiveアップリンクにのみ適用され、Standby アップリンクに関しては「明示的なFailover順序」 ＆自動Failbackと同等の挙動になると考えられる。

 

コメント

コメントを投稿

このブログの人気の投稿

vSwitchにSTPが不要な理由

イメージ
  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを受信した際の動作を示しています。 Broadcast Packetは仮想スイッチに接続されるVMに対して転送
続きを読む

ESXi に DNS サーバを何個まで登録できるか

イメージ
ESXi の DNS サーバの最大登録可能数を調べる vSphere 構築経験のある多くの方は2つまでとお答えになるかもしれない。 なぜならば、DCUI や vSphere Client から設定した場合、Primary DNS と Alternative DNS の2つまでしか設定できないからだ。 GUI から設定する場合、苦し紛れにカンマ区切りなどで3つ以上登録しようと試みても無駄である。GUI でエラーになってはじかれるだけだ。 ならば、CLI はどうか。 /etc/resolv.conf に手動で追記していくだけであればストレージの許す限り記載することはできるだろうが、 この方法は当然ながら標準的な手順ではない。 esxcli を利用して DNS を登録することも可能である。具体的には以下のコマンドを利用する esxcli network ip dns server add -s <ip_address> 上記のコマンドを利用してどこまで登録可能かを試してみた。 具体的には以下のコマンドを用いて255個のDNSサーバを追加してみた for i in `seq 1 255`; do esxcli network ip dns server add -s 192.0.2.$i ;done なお、本ブログで記載される IP Address は例示用に予約されたものであり、RFC5737 から拝借している。 結果として、少々時間はかかるが登録自体は問題なく成功した。 実環境においてこれほど多くの DNS の登録をすることはあり得ないので、事実上制限なしと考えられる。 なお、参考のために他ベンダーも含める形で DNS 登録数の最大数を調べたところ、2 か 3 にしているところが多いようだ。 DNS を大量に登録した際の動作を調べる DNS クエリのタイムアウト時間：5 秒則 ESXi の DNS Client は最近の systemd-resolved などではなく、レガシーなソフトウェアであるため、 resolv.conf の上から順番に問い合わせていき、問合せ先の DNS に到達できなかった場合に次の DNS サーバに問い合わせる動作になる。 次の DNS サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた
続きを読む

障害でVDSから切断されたVCSAの復旧方法

この投稿は vExpert Advent Calendarの10日目です。 https://adventar.org/calendars/6689 本記事では以下の状況と、簡易な復旧方法について説明します。 環境 vCSAは自身が管理するvSphere Cluster上に存在する。 vCSAは自身が管理する vDSに接続される vCSAが接続されるdvportgroupはEphemeralではない 該当のvCSA以外にvSphere Clusterを管理できる vCSA は存在しない  障害状況 vCSAは何らかの理由により、もともと存在していたESXiから、別のESXiに再登録されている。 vCSAはvDSから切断されてしまっている。 解説 上記の状況は、ESXiの障害などによって副次的に発生しうる状況です。もともと、vCSA は vDS に接続されていましたが、ESXi の障害などにより、いったん Guest OS から Shutdown され、Host Client を利用して別の ESXi に再登録したうえで起動しています。 この場合、もともとvCSAが接続されていたdvportは別の ESXi 上のポートであるため、起動時にvCSAはvNICを接続することができず、切断状態となります。 vCSAが切断状態になり、かつESXiのHost Clientからは仮想マシンをvDSに接続することができないため（Ephemeral Port を除く）、vCSAの復旧が困難となります。  この状況において有効な解決策としては事前に用意しておいたEphemeral Port を利用するか、もしくは一時的にVSSを作成して復旧する方法が一般的な方法です。 事前にEphemeral Port の準備がない場合には、VSSを作成することになりますが、Uplinkに空きがない場合は、Uplinkを付け替える必要があり、手順は複雑になります。 今回はVSSを利用しない簡易な復旧方法についてご紹介します。 簡易な復旧方法 完結に手順を示すと以下です。 vNICが切断されているVCSAをShutdown  vCSAが存在する ESXi を Maintenance Mode～Reboot  vCSA を再度起動～vNICが接続状態であることを確認  上記に示した通り、ESXiをリブート
続きを読む