Posted inVMware

停電時のVMware ESXiグレースフルシャットダウン：VMが破損しない正しい設定方法

VMware tutorial - IT technology blog
VMware tutorial - IT technology blog

会社でVMwareクラスターの8台のESXiホストを管理していますが、一番つらかった障害は、UPSのバッテリーが切れたときにグレースフルシャットダウンを設定していなかったことが原因でした——3台のデータベースVMのファイルが破損し、リカバリに6時間かかりました。それ以来、新しいESXiをインストールするたびに、グレースフルシャットダウンの設定が最初にやることになっています。絶対に省略しません。

5分ですぐ設定：ESXiでグレースフルシャットダウンを有効にする

基本的なグレースフルシャットダウンは2ステップで完了します。高度な設定（UPS連携）は後回しでも構いません。

ステップ1：すべてのVMでVMware Toolsを確認する

VMware Toolsがなければ、ESXiはゲストOSにシャットダウン命令を送れません——そのまま電源を強制切断します。ESXiホストにSSH接続して以下を実行してください：

# 実行中のすべてのVMのVMware Toolsステータスを確認する
for vmid in $(vim-cmd vmsvc/getallvms | awk 'NR>1 {print $1}'); do
  status=$(vim-cmd vmsvc/tools.getStatus $vmid 2>/dev/null \
    | grep toolsStatus | awk '{print $3}')
  name=$(vim-cmd vmsvc/getallvms | awk -v id=$vmid '$1==id {print $2}')
  echo "VM $vmid ($name): $status"
done

すべてのVMでtoolsOkと表示されることが理想です。toolsNotInstalledまたはtoolsNotRunningのVMは、停電時に容赦なく強制電源断されます——続ける前に、そのVMにVMware Toolsをインストールするか再起動してください。

ステップ2：ESXiでAutostart/Shutdownを設定する

https://<esxi-ip>/uiでESXi組み込みホストクライアントにアクセスします（vCenterがある場合はvSphere Clientでも可）：

  1. Host → Manage → System → Autostartを選択
  2. Edit Settingsをクリック
  3. EnabledをYesに設定
  4. Stop actionをGuest Shutdownに設定——重要：Power Offは絶対に選ばないこと
  5. Stop delayを120秒に設定（各VMのシャットダウン完了を待つ時間）
  6. OKをクリック

続いてVirtual Machinesタブで各VMをリストに追加し、優先順位を設定します。これで完了——管理者がホストをシャットダウンするか、UPSがシャットダウン命令を送ったときにグレースフルシャットダウンが機能します。

グレースフルシャットダウンと強制シャットダウンの正しい理解

ESXiにはVMをシャットダウンする2つの方法があり、その違いは単なる技術的な話ではありません——データが残るか失われるかを左右します：

  • Power Off：ケーブルを抜くように即座に電源を切断します。ファイルシステムがバッファをフラッシュできず、処理中のデータベーストランザクションが失われ、Windows NTFSは再起動時にchkdskが必要になる場合があります。
  • Guest Shutdown：VMware Toolsを通じてOSにシャットダウンシグナルを送り、OSが自らクリーンアップして正常終了するのを待ちます。ファイルシステムとデータベースにとって完全に安全です。

突然のPower Offを経験したとき、MySQL VMは再起動時にInnoDBリカバリーに20分かかりました——それでもまだ運が良いほうです。破損が自動修復できず、バックアップからリストアしなければならないケースもあります。

VMのシャットダウン順序は思っている以上に重要

ほとんどの本番スタックには依存関係チェーンがあります——アプリサーバーはデータベースに依存し、メッセージキューは実行中のコンシューマーに依存します。順序を間違えると、コネクションプールが途中で切断され、翌朝のエラーログが悲惨なことになります。私が使っているシャットダウン順序：

  1. アプリサーバー、Webサーバー（最初にシャットダウン）
  2. キャッシュサーバー（Redis、Memcached）
  3. メッセージキュー（RabbitMQ、Kafka）
  4. データベースサーバー——MySQL、PostgreSQL（シャットダウン順序の後半）
  5. インフラVM（AD、DNSなど）——存在する場合は最後にシャットダウン

ESXi Autostartでは、順序番号が小さいほど起動が早く、シャットダウンが遅くなります。データベースVMをOrder 1に設定して、最後にシャットダウンされるようにしましょう。

高度な設定：UPS連携でシャットダウンを自動トリガーする

ESXiでのグレースフルシャットダウン設定は、シャットダウンの方法を解決するだけです。残る課題は、停電時に誰がESXiにシャットダウンを命令するか——それがUPS管理ソフトウェアの役割です。

方法1：APC PowerChute Network Shutdown

APC UPSにNetwork Management Card（NMC）が搭載されている場合、PowerChute Network Shutdown（PCNS）が最も安定していて設定が少ない選択肢です。クラスター内のLinux VMにPCNSをインストールします：

# APC/Schneider ElectricのサイトからPCNSをダウンロード
# 展開してインストーラーを実行
tar -xzf PowerChute-Network-Shutdown-*.tar.gz
cd PowerChute-Network-Shutdown/
sudo ./install.sh

# インストール後、https://localhost:6547のWeb UIにアクセス
# 設定：Events → Add ESXi Host → IPとクレデンシャルを入力
# 閾値：バッテリー残量50%未満またはランタイム5分未満でシャットダウン開始

PCNSはVMware APIと直接通信し、設定済みのAutostart順序に従ってVMをシャットダウンしてからホストをシャットダウンします。追加スクリプトは不要です。

方法2：NUT + PowerCLIスクリプト（APC以外のUPS向け）

8台のホストのうち2台はCyberPower UPSを使用しており、PCNSが使えません。解決策はNUT（Network UPS Tools）とPowerShellスクリプトの組み合わせです：

# USBでUPSに接続されたLinuxサーバーにNUTをインストール
sudo apt install nut nut-client

# /etc/nut/ups.conf
[cyberpower]
  driver = usbhid-ups
  port = auto
  desc = "CyberPower 1500VA"

# /etc/nut/upsmon.conf — 以下の行を追加
MONITOR cyberpower@localhost 1 admin yourpassword master
SHUTDOWNCMD "/usr/local/bin/shutdown-vmware.sh"
MINSUPPLIES 1
#!/bin/bash
# /usr/local/bin/shutdown-vmware.sh
# UPSバッテリーが危険な閾値に達したときにNUTがこのスクリプトを呼び出す

ESXI_HOST="192.168.1.100"
ESXI_USER="root"
ESXI_PASS="your-password"

echo "$(date '+%Y-%m-%d %H:%M:%S') - UPS battery low, initiating graceful shutdown" \
  >> /var/log/ups-shutdown.log

# 順序に従ってVMをシャットダウンするPowerShellスクリプトを呼び出す
pwsh -NonInteractive -File /usr/local/bin/vmware-shutdown.ps1 \
  -Server "$ESXI_HOST" -User "$ESXI_USER" -Password "$ESXI_PASS"
# /usr/local/bin/vmware-shutdown.ps1
param([string]$Server, [string]$User, [string]$Password)

Connect-VIServer -Server $Server -User $User -Password $Password -Force

# VM名の順序でシャットダウン（タグ/メモによるカスタムソートも可）
$vms = Get-VM | Where-Object { $_.PowerState -eq "PoweredOn" } | Sort-Object Name -Descending

foreach ($vm in $vms) {
  if ($vm.ExtensionData.Guest.ToolsStatus -eq "toolsOk") {
    Write-Host "Graceful shutdown: $($vm.Name)"
    Shutdown-VMGuest -VM $vm -Confirm:$false
  } else {
    Write-Host "Force stop (no tools): $($vm.Name)"
    Stop-VM -VM $vm -Confirm:$false
  }
}

# すべてのVMがシャットダウンするまで待機、最大3分
$timeout = 180; $elapsed = 0
while ($elapsed -lt $timeout) {
  $running = (Get-VM | Where-Object { $_.PowerState -eq "PoweredOn" }).Count
  if ($running -eq 0) { break }
  Start-Sleep -Seconds 5; $elapsed += 5
  Write-Host "$running VMs still running... ($elapsed/$timeout sec)"
}

Set-VMHostState -VMHost $Server -State Shutdown -Confirm:$false
Disconnect-VIServer -Confirm:$false

6ヶ月の本番運用から得た実践的なヒント

定期的にテストする——実際に停電が起きてから動かないことを知っても遅い

毎月末の夜にテストを実施しています。ESXiシェルから以下のコマンドで現在のシャットダウン順序を確認し、ホストを実際にシャットダウンせずにロジックをテストできます：

# 設定済みのautostart/autostop順序を確認
vim-cmd hostsvc/autostartmanager/get_autostartsequence

# テスト用に手動でautostopをトリガー（設定順序でVMをシャットダウンする）
# ピーク時間帯ではなく、メンテナンスウィンドウ中に使用すること
vim-cmd hostsvc/autostartmanager/autostop

ワークロードの種類に応じたタイムアウトの設定

Windows VMは通常60〜90秒かかります。Linux VMは速く、15〜30秒です。書き込みが多いデータベースVMは、トランザクションログを完全にフラッシュするのに3〜5分かかる場合があります。デフォルトのstop delayは180秒に設定し、本番PostgreSQLだけはAutostart VM settingsで300秒に設定しています。

VMware Toolsの状態を定期的に監視する

VMware Toolsは、OSアップデートやカーネルアップグレード後に誰も気づかないうちにクラッシュすることがあります——実際に停電が起きたとき、すでに昨日から動いていない状態です。以下のスクリプトを管理VMのcronで毎晩実行しています：

#!/bin/bash
# ESXiシェルから実行——Toolsが正常に動作していないVMを警告する
for vmid in $(vim-cmd vmsvc/getallvms | awk 'NR>1 {print $1}'); do
  status=$(vim-cmd vmsvc/tools.getStatus $vmid 2>/dev/null \
    | grep toolsStatus | awk '{print $3}')
  name=$(vim-cmd vmsvc/getallvms | awk -v id=$vmid '$1==id {print $2}')
  [ "$status" != "toolsOk" ] && echo "WARNING: $name ($vmid): $status"
done

vSANや共有ストレージでは順序がさらに重要

vSANにはもう一つのステップが必要です：スプリットブレインを防ぐために、ホストをシャットダウンする前にデータストアをdismountすること。NFS/iSCSIの場合は、すべてのVMがシャットダウンした後にデータストアをunmountするだけで十分です。これはPCNSが手動スクリプトより優れている点です——ストレージの種類ごとに正しい順序を把握しています。

このセットアップを完全に展開してから、クラスターは実際の停電を3回経験しましたが、破損したVMは1台もありませんでした。設定に2〜3時間かかりましたが、データを失わずに済み、顧客にデータベースが壊れた理由を説明しなくて良くなりました。

Share:
Tags: