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 サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できたが名前解決ができなかった場合はそこで終了となる。
この動作を利用して、いくつの DNS サーバまで問い合わせをしてくれるのかを調べた。
具体的な方法は以下である。
  1. ESXi に存在しない（到達不可能な）DNS サーバ IP を登録し、一番最後に到達可能な DNS サーバの IP を記載する。
  2. ESXi で nslookup で名前解決を試みる。ここで試みる名前解決は、一番最後に記載した DNS サーバで解決可能でなくてもよい。
  3. 名前解決に応答があるかどうかを確認する。すなわち、一番最後に記載した DNS サーバに問い合わせをしたかどうかを確認する
一番最後に記載した DNS サーバから応答が確認できた場合は、すなわちそれよりも上の行に記載されていた DNS サーバのすべてに対し問い合わせを試みたと判断できる。
nslookup は time コマンドを利用することで所要時間を計測し、DNS サーバとの関係性を調べた。
結果は以下の通りになった。 

 



ここまででわかる通り、DNS サーバの数が1つ増えるごとに時間が5 秒増えている
つまり、１つの DNS サーバへの問い合わせがタイムアウトするまで 5 秒かかっていると判断できる。
以後これを 5 秒則とよぶ。

 

DNS サーバクエリの限界値探索 

また、数を増やしていった際にどこまで本当に名前解決可能なのかを調べてみた。
試しに、60 個の DNS サーバを登録したところ、300 秒後にきちんと応答があった。
255 個の DNS まで試したが、nslookup で確認する限りきちんと応答が得られた。

今回の実験では 255 個の DNS 登録までで打ち切りとした。現実的に 255 個の DNS を登録することは考えにくく、タイムアウトの総計は 20 分超になるためである。かつこれ以上増やした場合は、メモリやストレージや関連プロセスの制限などが先に飽和することが予想され、vSphere の仕様確認という意図からは外れるためである。


すべての DNS に到達不可だった場合の挙動確認 

次に DNS を複数登録し、すべて到達不可能だった場合の挙動について調べた。
この場合も当然ながら 5 秒則が当てはまり、最終的に失敗にはなるものの、nslookup コマンド自体は返ってくることになる。


考察と検討

この段階で気になるのが、ESXi は名前解決の遅延をどこまで許容できるかという点である。
実際のところは、名前解決を必要とするプロセスなどに依存すると思われるので、明確な指標を出すのは困難である。
ESXi の DNS Requirement の資料も探してみたが、目安となる数値は確認できなかった。
そこで、今回は以下の KB を基準にすることとする。
DNS name resolution using nslookup takes up to 40 seconds on an ESXi host (2070192)
上記の KB を要約すると、DNS の逆引き設定がない場合に nslookup や SSH のログインに時間がかかる、という事象である。
40 秒かかったことによるシステム的な影響については言及されていないが、この KB が作られているということは、40秒という遅延は ESXi として想定されたものではないのだろう。
これを上記の 5 秒則に当てはめると、40 秒以内に名前解決可能な DNS の数は 8 個までとなる。（9 個にすると 40 秒をわずかに超える）
もちろん、35 秒だとしても、IT 業界に従事する人間の感覚的には長すぎる。
では、アプリケーション観点ではどうか。
標準的かつ広く利用される HTTP で調べてみた。 
Hypertext Transfer Protocol (HTTP) Timeouts
もちろん、ウェブサーバの実装や設定などにより変わってくると思われるが、上記の記事によると HTTP の Timeout は 30 ~ 120 秒らしい。
HTTP を利用するアプリケーションやプロセスも同様の想定をしていると仮定すると、DNS による名前解決は当然ながらこの Time Out 値に収まらなくてはならない。
したがって、DNS の名前解決遅延は 120 秒以内ということになり、5 秒則に当てはめると 24 個までとなる。

本記事の結論

とはいえ、上記の帰結は現実的かと問われれば否定せざるを得ない。
実際に 100 秒以上名前解決に時間を要するのであれば、何らかの問題が発生すると考えるのが自然だろう。

また、「どうせ失敗するのであれば早く失敗したほうが良い」という状況も存在するため、到達負荷の DNS サーバが多い場合には 5 秒則に従って、失敗までの時間がリニアに増えてしまが、あらかじめ少なめにしておけば名前解決失敗 or 呼び出し元プロセスのタイムアウトによる失敗までの上限時間が短縮されることになり、例外処理をすぐに実行出来たり、別の方針に切り替えたりといった柔軟な対応が可能になる。

結局のところ、他ベンダーの製品がそうであるように、また vSphere Client や DCUI がそうであるように、現実的な DNS サーバの登録数は、2 ~ 3 であり、その範囲で稼働できるように DNS サーバの可用性を設計すべきということになる。

 

コメント

コメントを投稿

このブログの人気の投稿

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に対して転送
続きを読む

障害で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をリブート
続きを読む