IT or War

 イントロ VxRail は、VxRail クラスタShutdown機能を利用してクラスタをシャットダウンすると次回起動時に自動的にメンバーノードのメンテナンスモードが解除され、vSANが再度有効化されたのちにSystemVMが自動で起動するようになっている。 起動時に上記の動作を提供するスクリプトが仕込まれており、それは以下のスクリプトファイルである。 /etc/rc.local.d/998.start_vm.py このスクリプトには上記の動作を安定化させるためにいくつかの待機フェーズが仕込まれている。この記事では、スクリプト内で利用される各待機フェーズにおけるタイムアウト値を調査した 免責 本記事内容は、7.0.320 で稼働するノードの該当スクリプトを解析しています。 調査結果についてはベストエフォートであり、必ずしもその正確性や網羅性を保証するものではありません。 スクリプトの動作を確認 スクリプト内で以下の部分がメイン関数であるとわかる      546 def main():     547     parser = argparse.ArgumentParser()     548     parser.add_argument('-d', dest='debug', help='Debug mode (no run in background)', action='store_true')     549     550     args = parser.parse_args()     551     if not args.debug:     552         daemonize()     553     do_start_vms() do_start_vms という関数が呼び出されている     422 def do_start_vms():...

 VxRail LCM VxRailを代表する優秀な機能です。VxRail ManagerがvCenter（内部型に限る）とESXi とハードウェア関連（Driver/Firmware）のコンポーネントを一元管理のもとUpgradeします。Upgrade前後の互換性やUpgrade手順はすべてDellによって動作検証済みであり、ユーザによる事前の動作検証や手順確認を必要としません。 一方でvSphere/vSAN観点では、VxRail LCM から遅れること約4年後の2020年にvSphere LCMという機能をリリーしました。vSphereで管理できないハードウェア関連コンポーネントは、各サーバベンダが提供するHSM（Hardware Support Manager）と連携することで一元バージョン管理を実現しています。 しかしながら、vLCMはvCenterやHSM自体のUpgradeが含まれません。手順の最適化やUpgradeファイルのパッケージ化など様々な面でVxRail LCMのほうが機能面・品質面でも先行し続けています。 vSAN Cluster Shutdown こちらもVxRailが当初から提供している機能です。VxRail 上の管理VM（VxRail Manager や vCenter）を含め、vSAN Clusterを安全に正しい手順でシャットダウンします。 VxRailのリリース初期のころは、またVMwareのvSAN自体がそれほど世間から認知・浸透しておらず、通常の３Tierと同じ手順でShutdownしてしまった結果、Shtudownできなくなったり、アクセス不可となるような事例もしばしば目にしました。しかしながらVxRailであればそういった心配なく誰でも簡単に正しい手順でShutdownができます。 あまり知られていませんが、VxRail Shutdown機能はShutdownだけでなく、PowerUp時にも活躍します。Shutdown時と同様にPowerUp時もvSAN特有の手順や考慮事項が必要になりますが、VxRailであれば、サーバの電源ボタンを押すだけで自動的に、① ESXi の起動の待ち合わせ~②メンテナンスモード解除～③vSANの有効化～④管理VMの起動、が実行されます。 一方で、vSphere/vSAN観点でこの機能...

 VxRailのスイッチ要件？ VxRailのスイッチ要件や互換性についてしばしば質問をされる。結論から言ってしまうと、VxRailとしてL2 スイッチに対する細かい要求は存在しない。極論でいえば、バカハブでよい。 したがって、必要な通信規格（10GBase-Tなど）を満たすポートが必要数あればよい。 タグVLANは必須だと勘違いされやすいところだが、なくてもいける。そのため、VxRail観点でいえば、L2 スイッチのベンダ、モデル、バージョンは問わない。 上記の内容はNetwork Guide にも書かれているはずだが、質問されることがおおいので再度確認してみた。 Network Guideをみてみる VxRailのNetwork Planning Guide は以下。 VxRail Network Planning Guide (delltechnologies.com Basic Switch Requirements として以下の記載がある。 要約すると、VxRailが利用する Top of Rack Switch においては、L3 Switchingの機能は不要であり、かつVLANもなし（flat）でも可能。ただしVLAN flat な構築は本番環境では推奨しない、という旨で記載されいてる。 要件と言いながら、必要なことが何一つとして書かれていないため、結局何が必要なのかがわかりにくい。そのため、質問が増えていると考えられる。 なぜこのような記載になっているのかを知るためにはVxRailとvSANの歴史を振り返る必要がある。 Requirementの文面の変遷 VxRailがリリースされた2016年では、同じ項目に以下の内容の記載があった。 ・IPv4 のマルチキャスト機能が必要（vSAN6.2で必須） ・IPv6のマルチキャスト機能が必要（VxRailの自動検知で必須） ・L3 Switching機能は不要 ・VLANはなくてもよい 上記のうち、1つ目のIPv4 Multicastは vSAN 6.6 (VxRail 4.5)以降で不要となったため削除された。 2つ目のIPv6 Multicast は、VxRail 7.0.130以降で手動検知が機能追加されたため、要件から外れた。 そのため、L3とVLANに関する記載だけが残り、要件なのに必要な...

 事象 DCUIの機能で管理ネットワーク設定（IPやVLANなど）を設定した後に、サービスリスタートをして再度最初の画面を見てみたら設定が反映されていない、ということがある。 あれれ？とおもって再度設定をしたら、なんだかわけのわからない状態になってしまったということがある。 原因 どうやら、管理ポートのタグを付与されているvmk ポートが複数ある場合、サービス再起動によってDCUIで管理されるポートがトグルされるらしい。 つまり、vmk0とvmk2にManagement Tagがつけられているとして、デフォルトの段階ではvmk0の情報がDCUI上に表示され編集が可能であるが、サービス再起動によってvmk2が管理対象に変わってしまうため、DCUI上でvmk2の情報が表示されるために、設定が反映されていないように見えてしまうということ。 そのため、再設定をした際に想定外の動作や挙動となることがある。 結論 初期設定時などの場合、DCUIからの編集は便利ではあるが、上記のような挙動によって問題を引き起こす場合があるため、ネットワーク設定はesxcli から実施する方が無難。 DCUIから実施する際も、確認作業はesxcli で実施したほうが良い。

 背景 トラブルシューティングの際に、TCPの疎通確認をしたいことは多々あります。TCPの疎通確認といえば、Telnetやcurlコマンドで実施するのが非常に簡単です。  しかし、ESXiには残念ながらこのどちらも含まれておらず、そのほかのマイナーなコマンドやecho >/dev/tcp/<HOST>/<PORT> などでも実施できないため、手段に窮してしまいます。 そこで本記事ではESXiに標準搭載されるpython を利用した確認方法を紹介します      

 背景 過去の記事 でもご紹介していますが、vSAN環境はvSAN7U3 から GUI での Shutdown が可能になっています。 とはいえ、まだまだ旧来の reboot_helper.py を利用したShutdownも行われていると思います。 このスクリプトの中では、PrepareClusterRebootWithNAMM が実行され、その結果によっては、Shutdownが先に進まないことがあります。 例えば、稼働中の 仮想マシンがいる場合や、何らかの理由でUnsupported Host となってしまう場合などです。 reboot_helper.py  の出力から原因がわかればよいのですがそうでない場合は、製品サポート窓口に問い合わせることになるでしょう。 しかしながら、 PrepareClusterRebootWithNAMM を直接実行することで、スクリプトでは切り捨てられている部分のメッセージを確認することができますので、それをきっかけに原因特定につながることもあるかもしれません。 この記事では手動で簡単に PrepareClusterRebootWithNAMM  を実行する方法を紹介します。 手順 ESXiにログインして以下のコマンドを実行してください。 cd /usr/lib/vmware/vsan/bin/ python import reboot_helper vvchs = reboot_helper.ConnectClusterHealthSystem() clusterRef = reboot_helper.vim.ClusterComputeResource('ha-cluster') vvchs.PrepareClusterRebootWithNAMM(clusterRef) 2行目のpython コマンドを実行したタイミングで python の対話モードに入りますが、そのまま以降のコマンドを実行することで、PrepareClusterRebootWithNAMM  を実行し、その結果を直接得ることができます。                 

 なんの役に立つのかわからないが、とりあえず見つけたので備忘めも １．VCにSSHで接続 ２．rvc を起動 ３．rvc で接続先を求められたら接続したユーザとホストを指定。     VCの場合は、administrator@vsphere.local@localhost     ESXiの場合は、 root@<ESXi IP> ４．パスワードを入力して接続完了 ５．ls で 1 のところに localhost or ESXi IPが表示されるのを確認する ６．vsan.debug.mob --start 1 で、vsan mob を有効化する ７． https://<vc or esx ip >/vsan/mob でブラウザから接続可能。 ------ 2022/08/24 補足 ------ ESXi にSSHでログインして、 esxcli vsan debug mob start でも有効化できる模様。