Beacon Probing についてのメモ

概要

Beacon Probingについての相談があったので、調べた内容をメモ。

基本的には利用は避けるべきと判断しています。

 

Beacon Probingってなんだっけ？

Beacon Probingは仮想スイッチのUplinkのリンク障害検知手法の一つです。

https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-networking-8-0/networking-policies/teaming-and-failover-policy.html

 

デフォルトはLink Status Onlyとなっており、いわゆる物理ポートのUp/Downでのみ判断をする方法です。

ただしこの方法だと直接接続のスイッチ（TOR）とのLink状態しかわからないため、TORスイッチと上位スイッチとのリンク障害時にはなにもできないため、

そのための対策としてBeacon Probingという機能があります。

What is beacon probing?

 

Beacom Probingはその仕様上、ドキュメントにもある通り、3ポート以上でないと想定通りの動作となりません。

かつ、TORスイッチがそもそも冗長化されていない場合や、複数のTORスイッチが論理スイッチ構成（StackやvPC、VLTなど）をとっている場合は不要です。

 

 

Beacon Probingを検討する際の注意事項

 

ビーコン検知は3ポート/3 switch以上の構成を想定してデザインされていますので、2ポート/2 スイッチでは普通は利用されません。（下記KB参照）

What is beacon probing?

 

一応2ポート以下でも設定することは可能ではありますが、以下のドキュメントにもある通り、2ポート以下での利用は不安定な動作を誘発する可能性があり、単純なLink DownにとどまらずFlappingなどのさらなる悪質な障害につながる恐れがあるため、Link Status Onlyで利用いただくことを推奨します。

What is Teaming and Failover Policy

 

なお、vSANで利用するポートに関しては、Basic NIC TeamingにおいてBeacon Probingを利用するなと公式に記載があります。

Configure Load Balancing for NIC Teams

 

なお、LACPを利用する場合においてもBeacon Probingは非サポートです。

Configuration 3: Dynamic LACP

Understanding IP Hash load balancing

 

2ポート構成時の補足

２ポートでのBeacon Probingの場合、TORスイッチと上位スイッチとの疎通切断が起きた場合、障害検知のためのビーコンパケットがいずれのポートでも検知できなくなります。そのため、どちらのポート（の上流）で障害が発生したのかを区別することができないため、Shot gun modeという挙動になります。こ
のモードでは２つのポートから同じパケットが送信される挙動となります。（どちらが障害かわからないので両方から送信している）


 

まとめ

個人的な結論として、Beacon Probingは基本的に採用するべきではないと考えています。

そもそも3ポート/3スイッチ以上の構成は現代では稀です。

一昔前であれば1GbEポートをたくさん束ねるような構成もあったかとおもいますが、近年では10GbE/25GbEといった高速なUplinkを複数のトラフィックでシェアするような構成が一般的であるため、特定のポートグループが利用するのはほとんどが２つのUplink Portで事足りますし、TORスイッチで10GbEや25GbEといったスイッチを3台以上利用する構成はほとんどありません。

 

さらに、近年のVMwareの傾向としてシンプルな構成への誘導が目立ちますので、基本的にはデフォルト構成で利用することが推奨されます。

上記で触れた通り、vSANやLACPではBeacon Probingは使わない方が良いですし、複雑な動作が既存のvSphereやネットワーク側の機能と競合するリスクもありますので、よほど限られた要件でない限りはLink Status Onlyを利用するのが良いです。

 


コメント

コメントを投稿

このブログの人気の投稿

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を...
続きを読む

NTPと同期してくれないときのトラブルシューティング

ラボ環境や検証環境だと、用意したNTPサーバーとESXi/VCSAが同期してくれないことがしばしばあると思います。 多くの場合はちょっとした設定の追加で解決できることが多いので、今回はその方法についてご説明します。 NTPサーバとの疎通確認 何はともあれ、まずはNTP側との疎通と動作確認が必要です。 以下のコマンドを実行してください。 ※ESXiにはntpdateコマンドはないのでスキップしてください。
続きを読む

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 サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた...
続きを読む