ESXiクラスターの実際の運用課題
社内で8台のESXi hostで構成されるVMwareクラスターを管理していますが、VMwareがセキュリティパッチをリリースするたびにチーム全員が頭を抱えていました。従来の標準手順は、vMotionですべてのVMを別ホストにマイグレーションし、ホストをMaintenance Modeに移行してパッチを適用、rebootし、ホストが復帰するのを待ってからVMを戻す、というものでした。8台のホストがあると、1回のパッチ作業で4〜6時間かかり、マイグレーション中のリスクも無視できません。
さらに以下のような状況では問題はより深刻になります:
- パッチ適用中のホストからVMを受け入れるリソースが不足しているホストがある
- 「固定」されたVM(GPUパススルー、SR-IOV、USBパススルー)がありマイグレーションできない
- 顧客が24/7のアップタイムを要求しており、数分のダウンタイムも許容されない
- ゼロデイの緊急パッチを業務時間中に即座に展開する必要がある
従来のESXiパッチ適用がなぜ時間がかかるのか
ESXiはベアメタルハイパーバイザーであり、ハードウェア上で直接動作します。パッチ適用時、ほとんどの修正プログラムは稼働中のカーネルモジュールを上書きする必要があります。VMが稼働中にカーネルモジュールをホットスワップすることはできないため、システム全体をrebootするしかありません。
ESXi hostのフルhardware rebootには通常10〜15分かかり、さらに以下が加算されます:
- vMotionによるVMの移動:VMの数とRAM容量によって10〜30分
- Maintenance Mode移行の待機:2〜5分
- vMotionによるVMの復帰:10〜30分
1台あたり合計30〜60分かかり、8台分では午前中まるごと費やすことになります。
解決策
方法1: Maintenance Mode + フルReboot(従来の方法)
これは定番の方法です。vSphere Lifecycle Managerまたはesxcliでパッチをインストールしてrebootします:
# ホストにインストールされているVIBを確認
esxcli software vib list | grep -i vmware
# オフラインバンドルからパッチをインストール
esxcli software vib update -d /vmfs/volumes/datastore/patch.zip
# インストール完了後にホストを再起動
reboot
明らかな欠点:Maintenance Modeが必要で、rebootも必要、マイグレーションできないVMにはダウンタイムが発生します。
方法2: Quick Boot(ESXi 6.7以降)
VMwareはESXi 6.7でQuick Bootを導入しました。ハードウェア全体のreboot(POST、BIOS、ディスクスキャン)の代わりに、ESXiカーネルレイヤーのみを再起動するため、フルrebootより50〜70%高速です。
# Quick Bootがサポートされているか確認
/usr/lib/vmware/loadesx/bin/loadESX.py --check
# 期待される結果: quickboot: supported
# Quick Bootを有効化
vim-cmd hostsvc/quickboot/enable
# ステータスを確認
vim-cmd hostsvc/quickboot/status
Maintenance Modeは依然として必要ですが、reboot時間が15分から4〜6分に短縮されます。
方法3: VMware vSphere 8 Live Patching — Maintenance Mode不要
これはvSphere 8で最も待ち望んでいた機能です。Live Patchingを使用すると、一部のパッチ(特にセキュリティパッチや重大なバグ修正)を、ホストをMaintenance Modeに移行することなく、VMをマイグレーションすることなく適用できます。
動作の仕組み:vSphere 8はカーネルのlive patching技術(Linuxのkpatchと同様)を採用しており、パッチは稼働中のカーネルのメモリに直接インジェクトされ、どのプロセスも再起動することなく特定の関数を置き換えます。
推奨方法: vSphere 8でLive Patchingを展開する
前提条件
- vSphere 8.0 Update 1以降 — vCenterとESXi hostの両方がvSphere 8である必要があります
- ライセンス:vSphere Enterprise PlusまたはvSphere+(Live PatchingはStandardには含まれません)
- ハードウェアがVMwareのHardware Compatibility List(HCL)に掲載されていること
- クラスターがvSphere Lifecycle Manager(vLCM)のImageモードで設定されていること
手順1: ホストがLive Patchingをサポートしているか確認
# ESXi hostにSSH接続
# バージョンを確認
vmware -v
# Live Patching機能を確認
esxcli software component list | grep -i livepatch
# プラットフォームの詳細情報を表示
esxcli hardware platform get
# PowerCLI(ワークステーションから)— クラスター全体を確認
Connect-VIServer -Server vcenter.company.com
$cluster = Get-Cluster -Name "Production-Cluster"
Get-VMHost -Location $cluster | Select Name, Version, Build | Sort Name
手順2: クラスターがvLCM Imageモードを使用していることを確認
vLCMには2つのモードがあります:Baselines(旧式)とImage(新式)。Live PatchingはImageモードでのみ動作します:
- vSphere Clientを開き、Clusterを選択
- 「Updates」タブ → 「vSphere Lifecycle Manager」
- 「Manage with a single image」と表示されていればImageモードを使用中(問題なし)
- まだBaselineの場合 → Live Patchingを使用する前にImageモードへの移行が必要
# PowerCLI: クラスターがImageモードかBaselineモードかを確認
$clusterView = Get-Cluster "Production-Cluster" | Get-View
$clusterView.ConfigurationEx.VsanConfigInfo
手順3: コンプライアンスを確認し、Live Installをサポートするパッチを特定
vLCMはどのパッチをLiveで適用できるか、どのパッチにrebootが必要かを自動的に分析します。事前に全体を把握するためにPowerCLIをよく使います:
# PowerCLI: クラスター全体のコンプライアンスを確認
$complianceResult = Test-Compliance -Entity (Get-Cluster "Production-Cluster")
# Non-Compliantなホストを表示
$complianceResult | Where-Object {$_.Status -ne "Compliant"} |
Select Entity, Status
# 詳細確認: Liveで適用できるパッチとrebootが必要なパッチ
$complianceResult | ForEach-Object {
Write-Host "Host: $($_.Entity.Name)"
$_.PatchResults | Select PatchName, LiveInstall, RequiresReboot
}
手順4: vSphere ClientでLive Patchを適用
これが実行ステップです。本番環境にrebootが必要なパッチを誤って適用しないよう、順序通りに実施してください:
- 「Cluster → Updates → vSphere Lifecycle Manager」に移動
- 「Check Compliance」をクリック — 2〜3分待機
- Non-Compliantなホストを選択し、「Remediate」をクリック
- Remediationウィンドウで「Remediation Impact」セクションを確認
- パッチがLive Patchingをサポートしている場合、「Apply patches without reboot (Live Patching)」オプションが表示されるのでチェックを入れる
- 「Remediate」をクリックして開始
# ESXi host上で、ログからlive patchの進行状況を監視
tail -f /var/log/esxupdate.log
# 正常に適用されたlive patchを確認
esxcli software vib list | grep -i patch
Live Patching実行中:
- ホストはMaintenance Modeに移行しない
- VMはマイグレーションも再起動もされない
- パッチ適用時間:サイズによって2〜5分
- vCenterにはホストがオンライン、VMが正常稼働中として表示される
手順5: パッチ適用後の確認
# ESXi hostにSSH接続し、バージョンが更新されているか確認
vmware -v
# VMが正常に稼働していることを確認
esxcli vm process list
# エラーがないことをログで確認
cat /var/log/esxupdate.log | tail -30
# PowerCLI: 修復後のコンプライアンスを確認
Test-Compliance -Entity (Get-Cluster "Production-Cluster") |
Select Entity, Status, LastCheckedTime
6ヶ月の実運用から得た注意点
8台のホストクラスターを運用した経験から、実際に押さえておくべきポイントがあります:
- すべてのパッチがLive適用に対応しているわけではない:各パッチのVMware Release Notesに「Supports Live Install: Yes/No」と明記されています。メジャーバージョンのアップデート(8.0 → 8.0 U2)は常にフルrebootが必要です。
- 重大なセキュリティパッチは通常Live Patchingをサポート:これがメインのユースケースです — ダウンタイムなしでCVEパッチを迅速に適用できます。
- 定期的なメンテナンスウィンドウは依然として必要:Live Patchingは小さなパッチを処理しますが、メジャーアップデートにはrebootが必要です。大規模パッチのために四半期ごとにメンテナンスをスケジュールしています。
- パッチ適用後30分間モニタリング:rebootなしでも、Live Patch後は異常がないことを確認するためにクラスターを監視する習慣を維持しています。
- まず非本番環境でテスト:迅速で便利であっても、本番環境に適用する前にdev/stagingクラスターでテストすること — これは変わらない原則です。
vSphere 8のLive Patchingは、私の働き方を大きく変えました。以前は1回のパッチ作業に半日かかり、業務時間外にスケジュールを組む必要がありましたが、今では重要なセキュリティパッチを業務時間中に5分で適用でき、誰も気づかないほどです — 特に、以前はホストにパッチを当てるたびにシャットダウンを強いられていたGPUパススルーやSR-IOVを使用するVMにとって、この恩恵は計り知れません。

