iDRACの仮想コンソールにJavaで接続できない

※本投稿は2020年に別のブログサービス（現在アクセス不可）に投稿した記事の再掲です
情報的に古い内容となっております。

 VxRailなど、PowerEdge上にESXiをInstallしている場合、トラブルシューティングや初期構築などでiDRACの仮想コンソールに接続することはしばしばあると思います。

先日、ESXiのInstall用途で、iDRACの仮想コンソールにJavaで接続しようとしたら、エラーになって接続できないことがありました。

 

結論からいうと、iDRACのFWをUpdateするか、Javaのセキュリティファイルの設定を書き換えることで解決できました。

その時のトラブルシューティングを記します。

 

 

事象

キャプチャをとればよかったのですが、残念ながら取り損ねてしまいました。

英語でのキャプチャが欲しかったので後で事象を再現させて取ればよい、と楽観していたところ再現しなくなってしまったので取れずじまいです。

 

事象としては、idracの仮想コンソールにJavaで接続しようとした際に、Javaのアプレット（？）が起動した直後に「ビューワが切断された～」みたいなメッセージがでて接続できないという事象でした。

 

トラブルシューティング

Javaのコンソールやトレースを有効化する

Javaのエラーを見れば何かわかる、と思ったのでJavaのコンソールやロギングを有効化しました。

有効化は、コンパネからJavaのコントロールパネルを開き、AdvancedタブからConsoleやLoggingやTracingのチェックを入れればいいだけです。



 

事象を再現してログをみる

コンソールとロギング・トレーシングの設定をしたら、もう一度事象を再現させて、ログを見ればよいです。

実際に記録されていたログは以下です。

2020年2月19日

4:07

 

 

Java Web Start 11.241.2.07

Using JRE version 1.8.0_241-b07 Java HotSpot(TM) Client VM

JRE expiration date: 20/05/17 0:00

console.user.home = C:\Users\Administrator

----------------------------------------------------

c:   clear console window

f:   finalize objects on finalization queue

g:   garbage collect

h:   display this help message

m:   print memory usage

o:   trigger logging

p:   reload proxy configuration

q:   hide console

r:   reload policy configuration

s:   dump system and deployment properties

t:   dump thread list

v:   dump thread stack

0-5: set trace level to <n>

----------------------------------------------------

Missing Application-Name manifest attribute for: https://ip.ex.am.ple:443/software/avctKVM.jar

replace numpad

** Max Size: W = 1920 H = 1040

** Window Pref Size: W = 1040 H = 823

** Max Size: W = 1920 H = 1040

** Window Pref Size: W = 1040 H = 823

JNLPClassLoader: Finding library VMAPI_DLL.dll

JNLPClassLoader: Finding library jawt.dll

JNLPClassLoader: Finding library avctKVMIO.dll

ProtocolAPCP.receieveSessionSetup : v1.2 APCP = true

APCP Version = 259

 

 

 

 

Supported protocols: [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]

 

 

 

 

Enabled protocols: [TLSv1, TLSv1.1, TLSv1.2]

 

 

 

 

Supported ciphers: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]

 

 

 

 

Enabled ciphers: [SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5]

 

 

 

 

Exception in server handshake

javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

at sun.security.ssl.Handshaker.activate(Unknown Source)

at sun.security.ssl.SSLSocketImpl.kickstartHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at com.avocent.d.a.a.a(Unknown Source)

at com.avocent.d.a.a.a(Unknown Source)

at com.avocent.d.a.a.b(Unknown Source)

at com.avocent.d.d.b.a(Unknown Source)

at com.avocent.a.b.w.g(Unknown Source)

at com.avocent.a.b.w.a(Unknown Source)

at com.avocent.app.c.l.m(Unknown Source)

at com.avocent.app.c.l.e(Unknown Source)

at com.avocent.idrac.kvm.a.e(Unknown Source)

at com.avocent.idrac.kvm.Main.a(Unknown Source)

at com.avocent.idrac.kvm.Main.main(Unknown Source)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at com.sun.javaws.Launcher.executeApplication(Unknown Source)

at com.sun.javaws.Launcher.executeMainClass(Unknown Source)

at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)

at com.sun.javaws.Launcher.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

at sun.security.ssl.Handshaker.activate(Unknown Source)

at sun.security.ssl.SSLSocketImpl.kickstartHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at com.avocent.d.a.a.a(Unknown Source)

at com.avocent.d.a.a.a(Unknown Source)

at com.avocent.d.a.a.b(Unknown Source)

at com.avocent.d.d.b.a(Unknown Source)

at com.avocent.a.b.w.g(Unknown Source)

at com.avocent.a.b.w.a(Unknown Source)

at com.avocent.app.c.l.m(Unknown Source)

at com.avocent.app.c.l.e(Unknown Source)

at com.avocent.idrac.kvm.a.e(Unknown Source)

at com.avocent.idrac.kvm.Main.a(Unknown Source)

at com.avocent.idrac.kvm.Main.main(Unknown Source)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at com.sun.javaws.Launcher.executeApplication(Unknown Source)

at com.sun.javaws.Launcher.executeMainClass(Unknown Source)

at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)

at com.sun.javaws.Launcher.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

CoreSessionListener : connection failed

in CoreSessionListner : fireOnSessionStateChanged

KVM session state SESSION_FAILED

Javaのログを見慣れない人でも何となく赤くした部分を最初に見るのではないかと思います。

その部分を見ると何やらProtocalだか、Cipher Suiteだかが適切でないように思えてきますね。

 

Javaのセキュリティ設定を緩めにしてみる

Googleで、「Java Cipher Legacy」とかでググってみたところ、どうやら設定ファイルをいじると古いプロトコルも使えるようです。

以下の場所ファイルを編集して、ProtocolとかCipherをDisableにしている行を片っ端からコメントアウトしてみました。

もちろん編集前にバックアップを取っておくべきことは言うまでもありません

 

C:\Program Files (x86)\Java\<java version>\lib\security\java.security

 

実際には以下の項目をコメントアウトしました。

※コメントアウトした行のみを抜粋

##jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \

##    RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224

 

##jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024

 

##jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \

##    EC keySize < 224, 3DES_EDE_CBC, anon, NULL

 

 

コメントアウトしたのちに、再度接続を試みました。

 

接続成功！！

今度はエラーで切断されることなく接続することができました。

その際のJavaコンソールの出力は以下（ProtocalとCipherの部分のみ抜粋）でした

 

Supported protocols: [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]

 

Enabled protocols: [SSLv3, TLSv1, TLSv1.1, TLSv1.2]

 

Supported ciphers: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV, TLS_DH_anon_WITH_AES_256_GCM_SHA384, TLS_DH_anon_WITH_AES_128_GCM_SHA256, TLS_DH_anon_WITH_AES_256_CBC_SHA256, TLS_ECDH_anon_WITH_AES_256_CBC_SHA, TLS_DH_anon_WITH_AES_256_CBC_SHA, TLS_DH_anon_WITH_AES_128_CBC_SHA256, TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_DH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_ECDH_anon_WITH_RC4_128_SHA, SSL_DH_anon_WITH_RC4_128_MD5, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_DH_anon_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, TLS_RSA_WITH_NULL_SHA256, TLS_ECDHE_ECDSA_WITH_NULL_SHA, TLS_ECDHE_RSA_WITH_NULL_SHA, SSL_RSA_WITH_NULL_SHA, TLS_ECDH_ECDSA_WITH_NULL_SHA, TLS_ECDH_RSA_WITH_NULL_SHA, TLS_ECDH_anon_WITH_NULL_SHA, SSL_RSA_WITH_NULL_MD5, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_RC4_128_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5]

 

Enabled ciphers: [SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5]

失敗していた時とのログを見比べると、Enabled ProtocalでSSLv3が増え、Supported Cipherの項目も内容が大きく増えていることがわかります。

その結果、Enabled cipherとSupported Cipherで共通するCipherが現れました。

 

想像ですが、JavaのCipherに関する設定を緩くしたことでEnabled とSupportedの内容で一致するものが出てきたことで接続できるようになったものと思われます。

 

iDRACをFWのUpdateをしたら再現しなくなった

ESXiのInstallとFWのUpgrade作業を終えた後に再度事象を再現させようとしたところ、設定ファイルを戻しても再現しませんでした。

おそらく、FWのUpgradeにiDRACのUpdateが含まれており、それによりJavaのアプレットも更新されたことでCipherの問題が出なくなったと想像してます。

 

JavaのVersionにも依存？

きちんと切り分けをしたわけじゃないですが、いくつかの端末では設定ファイルをいじらなくても接続できるものがありました。（iDRAC Update前）

おそらくは、端末にインストールされているJavaのVersionによってはセキュリティ設定のデフォルト値などの関係で影響を受けずに接続できるものと思われます。

（そうじゃないといろいろおかしい）

 

まとめ

新しいJavaと古いiDRAC FWの組み合わせで、仮想コンソールにJavaアプレットで接続できない場合があることがわかりました。

解決方法としては、iDRAC FWをUpdateするか、Javaのセキュリティファイルをいじって古いプロトコルや暗号方式を有効化することで回避できます。

JavaのVersionを古いもの（理想はiDRAC FWのリリース当時のJava）にすることでも解消できそうですが、未検証です。

コメント

コメントを投稿

このブログの人気の投稿

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