vSAN 7U3 の Intelligent Cluster Shutdown&PowerUp と VxRail Cluster Shutdown＆PowerUpを比較してみた。

 vSAN 7U3 での Shutdownに関するエンハンスメント

何が変わったか

それまで煩雑だったvSAN Cluster の Shutdown 手順が vSAN 7U3 の新機能によって簡易化されました。
参考： https://core.vmware.com/blog/vsan-7-update-3-whats-new 

 
従来のやり方（Manual Shutdown）では、vSAN Cluster上のすべての仮想マシンを停止したのちに、ESXiをメンテナンスモードに入れる前に、手動でScriptを実行する必要がありました。
また、PowerUp の際も、ESXi をメンテナンスモード解除した後で、同様に手動で Script を実行する必要がありました。vSAN 6.7U3 より未満の Version では、すべての ESXi でこれを実施しなくてはならず、かつ Script も VMware のサイトからダウンロードし全 ESXi に配置し、かつそれを時刻同期した状態で Cron で実行する必要がありました。

vSAN 6.7U3 以降では、Script が更改され、自動化が進み、かつデフォルトで ESXi に内蔵されました。しかも、vSAN Cluster 内の任意の1ホストで実行するだけでよいため、それまでと比べて非常に簡易化されましたが、依然として CLI ベースの対応が必要であり、エンドユーザにとっては難しい場合もありました。


今回の vSAN 7.0 U3 では、従来の CLI ベースの Shutdown 手順から、GUI での Shutdown が可能になりました。自動化も大きく進み、Shutdown と PowerUp の両手順において、わずか数クリックで完了できます。


そもそもなぜ CLI ベースの Shutdown が必要だったか。

vSAN には、以下の KB で説明される不具合があり、過去すべての Version で該当します。この不具合は2018年に報告されていますが、最新版でも直っていません。

A simultaneous reboot of all hosts in the vSAN cluster may result in data unavailability after a single failure (60424)
https://kb.vmware.com/s/article/60424


この不具合を要約すると、非 vSAN Cluster と同じ手順で vSAN Cluster を Shutdown してしまうと、起動時に Disk 障害や Host 障害が発生した場合、それが単一障害であったとしても DU （ Data Unavailable ） になってしまう可能性がある、というものです。


恒久的な修正がないため、暫時的な WorkAround が必要になったわけですが、それが上記の煩雑な Shutdown 手順というわけです。

今回の Release で GUI にまで組み込まれてしまい、手順も KB から VMware Doc に昇格しているので、おそらく vSAN の不具合への対応としては、手順によってカバーされ、不具合自体が修正されることはないと思われます。


どれくらい簡単なのか試してみた。


起動方法は非常に簡単です。事前準備はほとんどいりません。せいぜい vSAN Cluster 上の仮想マシンを停止しておくくらいです。
ただし、該当 Cluster を管理する vCenter Server は残してください。 vSAN Cluster 上に、 vCenter Server がある場合は、vCenter Server も含めて自動で Shutdown してくれます。


vCenter 以外の VM の停止が完了したら、vSphere Client から以下のボタンをクリックして Shutdown を開始します。




ボタンをクリックすると、Shutdown 前の事前チェックが開始されます。
停止し忘れていた VM の存在や、Shtudown 前に解決すべき問題があればこの段階で気づくことができます。

問題なく事前チェックが完了したらそのまま Shutdown に進みます。
vCenter Server 自身が該当の vSAN Cluster 上で稼働していた場合は、この段階で通してくれます。
Shutdown シーケンスの中で、 vCenter Server 自体も自動で停止してしまうため、途中からタスクの進捗を確認できなくなってしまいますが、その場合は、ESXi のタスクから確認可能です。

Shutdown を開始すると、以下のように vSphere Client からタスクが確認できます。




vCenter が停止してしまった後は、以下のように ESXi からタスクを確認できます。





5~10分くらいで、すべての ESXi が自動で メンテナンスモードに入り、Shutdown まで完了します。


起動時は、普通に ESXi を Power Up すればよいです。
通常の ESXi Shutdown の場合は、 メンテナンスモードで Shutdown した場合は、 メンテナンスモードのまま起動されますが、vSAN Cluster Shutdown を実施した後の最初の起動では、自動的に全 ESXi のメンテナンスモードが解除されて、しかも vCetner まで自動で起動してくれます。

vCenter が起動したら、 vSphere Client に入ってvSAN サービスの再起動ボタンを押すと、自動で停止されていた、vSAN Performance Service や、もろもろの vSAN/vSphere関連の設定がリストアされます。




きづいたこと

簡単に試しただけなので、ログなどを細かく見てはいませんが、もともと CLI で実施していた Shutdown 手順が見事に自動化されているといえます。
VMware KB# 70650 に即した以下の挙動が自動化されていることを確認できました。


Shutodwn時
    • vSAN Cluster のヘルスチェック（事前チェック）
    • vSphere HA の無効化
    • vCLA の Retreat Mode 
    • vCenter Server VM の停止（vSAN Cluster上にいる場合のみ）
    • /VSAN/IgnoreClusterMemberListUpdates の設定
    • 不具合のWorkAroundの実行 ※
    • 全ESXi の メンテナンスモードの移行
    • 全ESXi の Shutdown 実行
PowerUp時
    • ESXi の PowerOn（ここは手動）
    • 不具合のWorkAroundの戻し ※
    • vCenter Server の起動
vSAN Service 再起動後（vSphere Client より操作）
    • /VSAN/IgnoreClusterMemberListUpdates の戻し
    • vCLSの Retreat Mode 解除
    • vSphere HA の再有効化

不具合の WorkAround については、従来の reboot_helper とは違う挙動のようです。
従来の reboot_helper やそれ以前のスクリプトでは、vSAN用の vmkernel port を vSAN から外していましたが、今回私が ESXi#1 を観察した限りでは、vSAN vmkernel port はずっと維持されていたため、何か別の方法で対策をしていたと思われます。
途中から vSAN vmkernel port での vSAN network への Pingが通らなくなっていました。この辺りについても追加の情報がわかり次第 Update したいと思います。


VxRail Shutdown との違い

Dell Technologies の製品である VxRail という HCI では、vSAN 7.0 U3 以前より同等の機能を提供していました。

きちんと評価したわけではないですが、以下の違いがあると思います。

  1. VxRail Shutdown では、VxRail Manager は System VM 扱いになる
  2. VxRail Shutdown は ESXi の タスクから進捗を確認できない
  3. VxRail Shutdown では DRS をマニュアルに変更している（起動時に戻す）
  4. VxRail Shutdown は、7.0 U3 未満のVersionでも利用できる（VxRail  4.7.520/7.0.130 or later）
  5. VxRail Shutdown では、起動後の vSAN サービス再起動が不要となる
  6. VxRail Shutdown は API から実施可能
  7. VxRail はどっちの手順で Shutdown してもよい


１については大きな違いにもなりえます。
VxRail Shutdown でも今回の Intelligent vSAN Shutdown でも、User  VM を事前に停止しなくてはならない、という点に関しては共通なのですが、Intelligent vSAN Shutdown の場合は、DNSサーバが User VMとして存在する場合、DNS を先にShutdown しなくてはならないため、vCenter Server や ESXi による名前解決ができずに Shutdown が失敗（開始できない）ということになりそうです。
DNS必須は VxRail でも同様なのですが、 VxRail の場合は、VxRail Manager を簡易 DNS とする Internal DNS の構成が可能なため、その点は勝ると思います。（ただし個人的には可用性の観点で Internal DNS は非推奨。かつ External DNS構成の場合は Internal DNS へ変更することは不可）

一方で、VxRail の場合は、外部 vCenter (VxRailに同梱されない vCenterで管理する構成) を利用していると、VxRail Shutdownが使えません。Intelligent vSAN Shutdown であれば、そもそもVxRail のような内部とか外部などという VxRail 管理上の差異は存在しないため、この点は  Intelligent vSAN Shutdown が勝る、と言いたいですが、 VxRail も 外部 VC 構成の場合は、 Intelligent vSAN Shutdown を利用すればよいだけなので、劣っているというよりも、メリットが減る、といった感じになると思います。


２は現場作業員からすると大きな違いになると思います。
VxRail Shutdown は vSphere Client から開始した後は進捗を確認できません。
どの ESXi のどのログを見ろ、などと書いてあればまだ親切ですが、VxRail Shutdown ではそういったこともありません。
現場レベルでは、本当はだいぶ前に Shutdown は失敗していたのに、進捗が確認できないため30分くらい失敗していたことに気づかなかった、ということもあります。

３については、VxRail でのみ、自動化手順中で DRS が Manual になりますが、これは vCenter Server や VxRail Manager といった System VM が自動で他の ESXi に vMotion されないようにするための措置です。しかしながら、そもそも vCLS を Retreat Mode にしているので、DRS を Manual にする必要がありません。
VxRail が無駄なことをしている？と考えることもできますが、VMware KB# 60424 では、DRS を Manual にせよ、との記載がありますし、VxRail は vCLS が存在しない vSphere 6.7環境でも同じ機能を提供していますので、ソースコードの流用の観点でそういった動作をするようになっているのだと思われます。

６については、現時点で Intelligent vSAN Shutdown を API から実施する方法は確認できませんでした（見逃していたらすみません。）。VxRail では可能です。ただし、vSAN 側もそのうちに実装されるのではないかと思います。現時点では UPS 連携をする際などは VxRail のほうが簡単そうですね。



コメント

コメントを投稿

このブログの人気の投稿

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