ESXi ホストにパッチを適用する前に

パッチを適用する準備が終わったところで、後は vCenter の GUI 上で、ESXi ホストにパッチを適用するだけですが、その前に以下の言葉の意味を先に理解しておくと良いです。

  • スキャン
  • ステージ
  • 修正

スキャン は言葉通りでパッチのスキャンを意味しますが、 ステージ修正 という言葉はパッと見た感じだと分かりにくい感があります。

スキャン は、クラスタ内の全ての ESXi ホスト、または特定の ESXi ホストに適用するパッチが存在するかどうかチェックすることです。

ステージ は、グローバル、またはプロキシ経由でパッチデータをダウンロードし、クラスタ内の全ての ESXi ホスト、または特定の ESXi ホストに配布することです。

修正 は、クラスタ内の全ての ESXi ホスト、または特定の ESXi ホストにパッチを適用することです。

それぞれの意味が分かったところで、後は実際に vSphere Update Manager (以下、VUM) を用いて ESXi ホストにパッチ適用を実施します。

主に以下の作業を実施します。

  • 新規ベースラインの作成
  • ベースラインの添付
  • スキャン (パッチスキャン)
  • ステージ (パッチダウンロード、及び配布)
  • 修正 (パッチ適用)
  • パッチ適用時の注意点 (必読)

新規ベースラインの作成

ベースラインについては、前回の記事で説明したつもりですが、ここでも簡単に説明します。

ベースラインとは

VUM では、パッチの重要度 として以下の 5つのレベルが用意されています。

・ 任意

・ 低

・ 中程度

・ 重要

・ 最重要

また、パッチのカテゴリ には以下の 5つのカテゴリが存在します。

・ 任意

・ セキュリティ

・ バグ修正

・ 機能拡張

・ その他

これに加えて、VMware、Cisco、HPE のような パッチ ベンダー と ESX 5.0、5.5、6.0 等の 製品のバージョン をクラウド管理者が環境に合わせて、一つのルールとして設定・定義し、クラスタ単位、あるいは、個々の ESXi ホストにパッチを適用することができます。

これらの設定一式のことを ベースライン と言います。

実際に ESXi ホストにパッチを適用するためには、事前にベースラインを定義・作成しておく必要があります。

Step 1. 管理ビューへ移動

vCenter 上の左ペインにて vCenter ルート階層、または クラスタ、または ESXi ホスト どれでも良いので、一つをクリックし、右側に表示される Update Manager (タブ) をクリックします。

クラスタのコンプライアンスビューへ移動

そうすると以下のように コンプライアンスビュー が表示されるので、管理ビュー をクリックします。

ベースラインを作成するために「管理ビュー」へ移動

Step 2. ベースライン作成ウィザードの起動

管理ビュー が表示されます。

ベースラインおよびグループ (タブ) > (画面の空白部分にカーソルを合わせて) 右クリック > 新規ベースライン をクリックします。

新規ベースライン追加

Step 3. ベースラインの名前およびタイプ

新規ベースライン ウィザードの ベースラインの名前およびタイプ 画面が表示されます。

この例では、ESXi ホストに重要なパッチのみを適用するために、以下のように設定しています。

項目備考
名前重要以上ベースラインの名前 (一意の名前) を入力
ホストのベースラインホストのパッチベースラインのタイプを選択

ベースラインの名前を入力 > ベースラインのタイプを選択 > 次へ をクリックします。

ベースラインの名前およびタイプ選択

Step 4. パッチのオプション

パッチのオプション が表示されます。

パッチのベースラインタイプには以下の二種類があります。

  • 固定
  • 動的

固定 (固定ベースライン) の場合には、新しいパッチがリリースされても作成したベースラインに新しいパッチが追加されません。

動的 (動的ベースライン) の場合には、新しいパッチがリリースされると作成したベースラインに新しいパッチが追加されます。

この例では、新しいパッチが出た場合に、作成したベースラインに自動的にパッチが追加されるように 動的 ベースラインを作成します。

動的 > 次へ をクリックします。

使用するベースラインのタイプ選択

Step 5. 動的ベースラインの基準

動的ベースラインの基準 が表示されます。

ここでは、動的ベースラインに含まれるパッチ一式を具体的に決めるための項目を指定します。

以下の項目を選択 > 次へ をクリックします。

項目
パッチベンダー任意
製品任意
重要度重要、最重要
カテゴリ任意
リリース日

ピンポイントでベンダーと製品の種類を選んでも良いですが、特にこだわりがなければ 任意 でも構いません。

また、複数選択する場合には、Ctrl + クリック で複数選択できます。

ベースラインに含まれるパッチの規定

Step 6. 除外するパッチ

除外するパッチ が表示されます。

パッチを当てようとしている ESXi ホストと関係ないパッチは適用されないので、特に除外しなくても構いませんが、危険と思われるパッチがあれば除外してください。

永久に除外したい パッチを選択 > 次へ をクリックします。

除外したいパッチがなければ、そのまま 次へ をクリックします。

永久的に除外するパッチの選択

ここで追加したパッチは、永久的に除外される

Step 7. 追加のパッチ

追加のパッチ が表示されます。

永久的に追加したい パッチを選択 > 次へ をクリックします。

特になければ、そのまま 次へ をクリックします。

永久的にベースラインに含めるパッチの選択

ここで追加したパッチは、永久的に追加される

Step 8. 設定が完了しました

設定が完了しました が表示されます。

今まで設定した内容が表示されるので、確認して問題なければ 終了 をクリックします。

ベースライン設定の確認

ベースラインの添付

ベースラインの作成が完了すると 管理ビュー が表示されるので、ベースラインが作成されていることを確認します。

確認が終わったら作成したベースラインをクラスタに追加するために、コンプライアンスビュー をクリックします。

ベースライン作成されたか確認

そうすると前の コンプライアンスビュー 画面に戻りますが、この例では、クラスタにベースラインを追加するために、明示的に クラスタ > Update Manager (タブ) > 追加されたベースライン項目 (右クリック) > 添付 をクリックしています。

クラスタのコンプライアンスビューへ移動
ベースラインの添付

ベースラインまたはグループの添付 が表示されたら先ほど作成した ベースライン (にチェックを入れ) > 添付 をクリックします。

作成したベースラインの添付

そうすると以下のように コンプライアンスビュー 画面上でクラスタにベースラインが追加されていることクラスタ内の各 ESXi ホストのパッチ状態が確認できるようになります。

ベースラインが添付されたか確認

スキャン (パッチスキャン)

パッチ状態について

パッチ状態には以下の 3種類があります。

不明 : スキャンされてない状態 (パッチが存在するかしないか分からない状態)

準拠 : パッチが当たってる状態、かつ適用するパッチが存在しない状態)

非準拠 : 適用するパッチは存在するが、まだ適用されてない状態

以下の例だとクラスタにベースラインを追加したばっかりなので、まだどんなパッチが存在するか分からないため、パッチ状態が 不明 になっています。

パッチが存在するか確認するために、クラスタ > Update Manager (タブ) > スキャン をクリックします。

ちなみに、下のウィンドウで esx01 だけ選択してからスキャンをクリックすると残りの 3台に対してスキャンは行われません。

パッチのスキャン

スキャンの確認 ダイアログがポップアップされます。

一応、全てスキャンした方が良いので、パッチとエクステンションアップグレード 全ての項目 (にチェック) > スキャン をクリックします。

対象スキャン項目の確認

スキャンが完了するまで待ちます。

パッチスキャン完了待ち

スキャンが完了すると以下のようにパッチのスキャン結果が表示されます。

以下の結果で言うとパッチは存在するが、まだ当たってないので、全ての ESXi ホストのパッチ状態が 非準拠 になっていることが分かります。

パッチのスキャン結果確認

ステージ (パッチダウンロード、及び配布)

Step 1. ステージの実行

パッチのスキャンが終わって、適用するパッチが存在することが分かったので、今度はパッチをダウンロードし、各 ESXi に配布するために、クラスタ > Update Manager (タブ) > ステージ をクリックします。

パッチのステージ (ダウンロード)

Step 2. ベースラインの選択

ベースラインの選択 が表示されます。

パッチをダウンロードする ESXi ホスト (にチェック) > 次へ をクリックします。

ステージするベースラインの選択

もっと慎重にやりたい場合には

この例では、クラスタ内の ESXi ホスト 4台に対して一気にステージを実行しています。

もしパッチ適用対象 ESXi ホストが本番環境でもっと慎重にやりたい場合には、1台単位で実施してください。

Step 3. パッチとエクステンションの除外

パッチとエクステンションの除外 が表示されます。

ステージしたくないパッチがあれば、ここでチェックを外すことも可能です。

この例では、全てのパッチをステージするので、全ての項目 (にチェック) > 次へ をクリックします。

ステージするパッチの選択

Step 4. 設定が完了しました

設定が完了しました が表示されます。

確認して問題なければ、終了 をクリックします。

ステージ準備完了:ステージ前の設定確認、及びステージ実行

Step 5. ステージ完了待ち

ステージが開始されるので、完了するまで待ちます。

ステージ完了待ち

修正 (パッチ適用)

パッチのスキャンとステージが終わり、これで ESXi ホストにパッチを適用する準備ができました。

Step 1. 修正を実施する前に DRS の設定確認

後は、修正 をクリックし、パッチ適用を実施するだけですが、DRS 機能が使えるか使えないかによって、作業プロセスが異なります。

DRS (vSphere Distributed Resource Scheduler) とは

DRS は、クラスタを構成する ESXi ホストの CPU 使用率とメモリ使用率を監視し、リソースに偏りが発生しないように、高負荷状態の ESXi 上で動いている仮想マシンを自動的に他のホストへ vMotion (ホスト vMotion) することによってクラスタのバランスを保つ vSphere の自動リソース分散機能 (リソース平準化機能) です。

あれば非常に便利な機能ですが、この DRS 機能を使うためには、vSphere Enterprise Plus ライセンスが必要です。 (vSphere Standard 以下は使えない)

DRS が使える環境 でのパッチ適用時のタスクは以下の通りです。

  1. 修正を実行
  2. パッチ適用対象 ESXi ホスト上で動いている全ての仮想マシンが自動で他の ESXi ホストへホスト vMotion される
  3. ESXi ホストが空っぽになったら自動でメンテナンスモードに切り替わる
  4. ESXi ホストにパッチがインストールされる
  5. 再起動が必要なパッチが適用された場合には、パッチインストール後、ESXi ホストの再起動が行われる
  6. 再起動完了後、自動でメンテナンスモードが解除される

DRS が使えない環境 でのパッチ適用時のタスクは以下の通りです。

  1. パッチ適用対象 ESXi ホスト上で動いている全ての仮想マシンを他の ESXi ホストへ手動でホスト vMotion する
  2. ESXi ホストが空っぽになったら手動でメンテナンスモードに切り替える
  3. 修正を実行
  4. ESXi ホストにパッチがインストールされる
  5. 再起動が必要なパッチが適用された場合には、パッチインストール後、ESXi ホストの再起動が行われる
  6. 再起動完了後、手動でメンテナンスモードを解除する

違いとしては、DRS が使えない環境、もしくは DRS は使えるけど、DRS の自動化レベルが 「手動」 になっている環境 だと 修正 (パッチ適用) を実行する前に、パッチ適用対象となる ESXi ホストに対して、以下のタスクを手動で実施しておく必要があります。

  • パッチ適用対象 ESXi ホスト上の全仮想マシンを他の ESXi ホストへホスト vMotion し、空っぽ状態にしておく
  • メンテナンスモードへの切り替え

この例では、DRS が有効 (自動化レベル:完全自動化) になっていること前提で話を進めていきます。

Step 2. 修正の実行

クラスタ > Update Manager (タブ) > パッチ適用対象となる ESXi ホスト (を選択) > 修正 をクリックします。

この例では、1台単位でパッチ適用を実施するために、下のウィンドウで esx01 だけ選択しています。 (この後、どの ESXi ホストにパッチを適用するか選択を求められる画面が出てくるのであまり意味ないかもしれませんが、ここは気持ちの問題なのでどちらでも構いません)

修正 (パッチ適用) の実行

本番環境は 1台単位で実施

一応、全ての ESXi ホストに対して、全自動パッチ適用も可能です。

しかし、全自動でパッチを適用するためには、ちゃんとポリシーを決めて運用しない限り (全ての仮想マシンが DRS によって完璧に vMotion 出来るようにしておかないと・常に vMotion を妨げる要因を排除しておかないと)、全自動は無理です。

そして、大事な商用サービスを提供している仮想マシンが動いている本番環境にも関わらず、全自動でパッチを適用してしまうところも個人的には如何なものかと思います。

本番環境の ESXi ホストにパッチを適用する場合には、まず 1台にパッチ適用を実施し、問題なくパッチが適用されたか確認する意味合いも込めて、1台単位で実施することが望ましいのではないかと思います。

Step 3. 修正の選択

修正の選択 が表示されます。

パッチを適用するための ベースライン (にチェック) > パッチ適用対象ホスト (にチェック) > 次へ をクリックします。

パッチ適用の対象となる ESXi ホスト選択

Step 4. パッチとエクステンション

パッチとエクステンション が表示されます。

適用するパッチリストが表示されるので、全項目 (にチェック) > 次へ をクリックします。

該当 ESXi ホストに適用するパッチの選択

Step 5. スケジュール

スケジュール が表示されます。

スケジュール予約も可能 (実際に使っている方がいるのか疑問) ですが、今すぐ実施したので、ただちに > 次へ をクリックします。

パッチを適用する時刻の指定

Step 6. ホストの修正オプション

ホストの修正オプション が表示されます。

ここで表示される項目は、前回の記事で設定した内容がそのまま表示されます。 各項目の詳細、及びチェックを入れた理由と外した理由などについては、前回の記事をご確認ください。

環境に合わせて、各項目を設定し、次へ をクリックします。

パッチ適用時のメンテナンスモードオプションの選択

Step 7. クラスタ修正オプション

クラスタ修正オプション が表示されます。

ここで表示される項目も、先と同じように、前回の記事で設定した内容がそのまま表示されるので、各項目の詳細、及びチェックを入れた理由と外した理由などについては、前回の記事をご確認ください。

環境に合わせて、各項目を設定し、次へ をクリックします。

パッチ適用時のクラスタオプションの選択

Step 8. 設定が完了しました

設定が完了しました が表示されます。

確認して問題なければ、終了 をクリックします。

パッチ適用前の最終確認、及びパッチ適用実行

Step 9. 修正完了待ち

そうすると以下のように修正が実行され、関連タスクが実行されます。

先ほど言ったように、この例では DRS が有効 (自動化レベル:完全自動化) になっている前提で作業しているので、以下のタスクが全て自動で行われます。

  1. パッチ適用対象 ESXi ホスト上で動いている全ての仮想マシンが自動で他の ESXi ホストへホスト vMotion される
  2. ESXi ホストが空っぽになったら自動でメンテナンスモードに切り替わる
  3. ESXi ホストにパッチがインストールされる
  4. 再起動が必要なパッチが適用された場合には、パッチインストール後、ESXi ホストの再起動が行われる
  5. 再起動完了後、自動でメンテナンスモードが解除される
パッチ適用時のプロセス・タスク状態

スタート地点は黒い矢印です

全てのタスクが完了するまで待ちます。

パッチ適用完了待ち

Step 10. 修正完了後のパッチ状態確認

DRS 有効状態なので、パッチ適用が全て完了すると以下のように、メンテナンスモードが自動的に解除されます。

そして、パッチ適用状態が 準拠 に変わります。

パッチ適用完了後の ESXi ホストのパッチ適用状態確認

Step 11. 残りの ESXi ホスト台数分繰り返す

これで、1台の ESXi ホストのパッチ適用は完了です。

後は、修正 (パッチ適用)Step 1. ~ Step 10. を残りのホストで繰り返します。

パッチ適用時の注意点 (必読)

最後に、一つ注意点として、ESXi に最新のパッチを当てたからと言って、全てが良い訳ではありません。

ESXi ホストに適用した特定バージョンのパッチ (特定のパッチビルド) がトリガーとなって、パッチ適用後、不定期的に PSOD でハングアップする事象が起こったりもするので、本番環境に最新パッチを当てる際には、特に注意が必要です。

PSOD とは(Purple Screen of Death)

PSOD とは、パープルスクリーンで ESXi ホストがハングアップする事象のことです。

Windows で言う Blue Screen に該当します。

こういう問題をなるべく回避するためには、パッチの事前調査が必要です。

一応、日本語版のビルド情報もありますが、最新情報は常に英語版に反映されるため、こういう情報を調べるときには英語版の KB を確認することをオススメします。

すなわち、特定のビルド番号 をパッチ適用対象となる ESXi ホストに当てると何らかの原因によりトラブルが発生する可能性があるかどうかについて事前に調べる必要があります。

VMware と H/W 側 (例えば、HPE) の保守契約が生きていれば、以下を。 (それぞれノウハウを持っているので、VMware と HPE 両サポートセンターへ問い合わせしてください)

  • 該当 ESXi ホストに適用しても良い安全なパッチのビルド番号を教えてもらう
  • 該当 ESXi ホストに最新パッチを適用するとビルド番号はいくつになるのか。
  • そのビルド番号と H/W モデル (例えば、ProLiant DL360p Gen8) との相性について、PSOD が起きる可能性はあるか
  • もしくは、該当 ESXi ホストに当てては行けないビルド番号を教えてもらう

保守契約は切れているが、新しいパッチを適用したい場合には、以下のやり方が有効かなと思います。 (各ベンダさんに聞くよりリスクは高いです)

  • 本番環境と同じバージョンの ESXi ホストで構成されている検証環境を用意し、パッチ適用後、しばらく様子を見る
  • 自力で VMware の KB (ナレッジベース)、もしくは HPE の Advisory (アドバイザリーサポート情報) 等を検索して関連情報を見つける

調べた結果、世間的に実績のあるパッチ。 当てても問題なさげなパッチのビルド番号が分かったとしましょう。

ビルド番号とリリース日の紐付けは、先ほどの KB VMware ESXi/ESX のビルド番号とバージョン を調べれば分かります。

そのリリース日を参考にし、当記事 新規ベースラインの作成Step 5. 動的ベースラインの基準 のところで、リリース日に制限をかけてからスキャンを実施すれば良いです。

もしくは、既存のベースラインを編集し、リリース日に制限をかけてからスキャンを実施しても構いません。

くれぐれも安全第一で。

以上、vSphere Update Manager 6.0 ESXi ホストパッチ適用 でした。