次の方法で共有


事前イベントと事後イベントについて

適用対象: ✔️ Windows VMs ✔️ Linux VM ✔️ オンプレミス環境 ✔️ Azure Arc 対応サーバー。

Azure Update Manager の事前イベントと事後イベントを使用すると、スケジュールされたメインテナント構成の前後に特定のタスクを自動的に実行できます。 スケジュール メンテナンス構成の作成方法について詳しくは、「Azure portal と Azure Policy を使用してマシンの定期的な更新をスケジュールする」を参照してください。 たとえば、事前および事後イベントを使用して、スケジュールの一部であるマシンで次のタスクを実行できます。 次の一覧は完全なものではなく、必要に応じて事前および事後イベントを作成できます。

サンプル タスク

事前イベントと事後イベントを定義できるシナリオを次に示します。

シナリオ 説明
マシンの電源を入れる マシンの電源を入れて更新プログラムを適用します。
スナップショットの作成 データの回復に使用されるディスク スナップ。
通知メール パッチをトリガーする前に通知アラートを送信します。
サービスの停止 ゲートウェイ サービス、NPExServices、SQL サービスなどのサービスを停止します。

事前および事後イベントを含むスケジュールの実行順序

特定のスケジュールに対して、事前イベント、事後イベント、またはその両方を含めることができます。 さらに、複数の事前または事後イベント、あるいはその両方を含めることができます。 事前および事後イベントを含むスケジュールの実行シーケンスは次のとおりです。

  1. 事前イベント - スケジュール メンテナンス期間が開始する前に実行されるタスク。 たとえば、パッチを適用する前にマシンの電源をオンにします。

  2. キャンセル - このステップでは、スケジュール実行のキャンセルを開始できます。 スケジュール実行のキャンセルを選択する可能性があるシナリオには、事前イベント エラーや事前イベントの実行が完了しなかった場合などがあります。

    Note

    事前イベントの一部としてキャンセルを開始する必要があります。スケジュールは Azure Update Manager またはメンテナンス構成によって自動的にキャンセルされません。 キャンセルに失敗した場合、スケジュール実行は、ユーザー定義のメンテナンス期間中に更新プログラムのインストールを進めます。

  3. 更新プログラムのインストール - 更新プログラムは、ユーザー定義のスケジュール メンテナンス期間の一部としてインストールされます。

  4. 事後イベント - 事後イベントは、更新プログラムのインストール直後に実行されます。 更新プログラムのインストールが完了し、期間が残っている場合はメンテナンス期間内に、メンテナンス期間が終了した場合は期間外に発生します。 例: パッチ適用の完了後に VM をオフにします。

    Note

    Azure Update Manager では、事前イベントはメンテナンス期間外に実行され、事後イベントはメンテナンス期間外に実行される可能性があります。 マシンでスケジュール実行を完了するために必要なこの追加の時間を計画する必要があります。

  5. スケジュールの状態 - スケジュール実行の成功または失敗の状態は、スケジュールの一部であるマシンでの更新プログラムのインストールのみを指します。 スケジュール実行の状態には、事前および事後イベントの状態は含まれません。 事前イベントが失敗し、キャンセル API を呼び出した場合、スケジュール実行の状態はキャンセル済みとして表示されます。

    Azure Update Manager では、Event Grid を使用して、予定メンテナンス構成の事前および事後イベントを作成および管理します。 Event Grid では、Azure Webhook、Azure Functions などのイベント ハンドラーから選択して、事前および事後アクティビティをトリガーできます。

    事前および事後を含むスケジュールの実行シーケンスを示すスクリーンショット。

    Note

    Azure Automation Update 管理の事前および事後イベント内で Runbooks を使用していて、Azure Update Manager でそれらの再利用を計画している場合は、Automation Runbook にリンクされた Azure Webhook を使用することをおすすめします。 詳細情報。

事前イベントと事後イベントのスケジュールのタイムライン

事前および事後を含むスケジュールのタイムラインを示すスクリーンショット。

事前および事後イベントのスケジュールのタイムラインを理解するには、次の表を参照することをお勧めします。

たとえば、メンテナンス スケジュールが午後 3 時 00 分に開始するように設定され、ゲスト メンテナンス スコープのメンテナンス期間が 3 時間 55 分の場合があります。 スケジュールには 1 つの事前イベントと 1 つの事後イベントがあり、詳細は次のとおりです。

時刻 詳細
2:19 PM スケジュール実行は午後 3 時に開始されるため、開始時刻の 40 分前 (つまり午後 2 時 19 分) にマシンまたはスコープを変更できます。
これは、新しいスケジュールを作成する場合や、事前イベントを含む既存のスケジュールを編集する場合に適用されます。
午後 2 時 20 分 - 午後 2 時 30 分 事前イベントは少なくとも 30 分前にトリガーされるため、午後 2 時 20 分から午後 2 時 30 分の間はいつでもトリガーされる可能性があります。
午後 2 時 30 分 - 午後 2 時 50 分 事前イベントは午後 2 時 30 分から午後 2 時 50 分に実行されます。 事前イベントは午後 2 時 50 分までにタスクを完了する必要があります。
複数の事前イベントが構成されている場合は、すべてのイベントを 20 分以内に実行する必要があります。 複数の事前イベントがある場合、それらのすべてが互いに独立して実行されます。 事前イベントでロジックを定義することで、ニーズに応じてカスタマイズできます。 たとえば、2 つの事前イベントを順番に実行する場合は、2 番目の事前イベントのロジックに遅延開始時刻を含めることができます。
事前イベントが 20 分を超えて実行され続けるか失敗した場合は、スケジュール実行のキャンセルを選択でき、そうしない場合は事前イベントの実行状態に関係なくパッチのインストールが進められます。
午後 2:50 キャンセル API を呼び出すことができる最も遅い時刻は午後 2 時 50 分です。
キャンセル API が呼び出せない場合、または設定されていない場合は、パッチのインストールが続行されます。
3:00 PM スケジュール実行は午後 3 時 00 分にトリガーされます。
6:55 PM 午後 6 時 55 分に、スケジュールは 3 時間 55 分のメンテナンス期間中に更新プログラムのインストールを完了します。
更新プログラムがインストールされると、事後イベントは午後 6 時 55 分にトリガーされます。
より短い 2 時間のメンテナンス期間を定義した場合、メンテナンス後のイベントは 2 時間後にトリガーされ、規定された 2 時間より前に (つまり 1 時間 50 分で) 更新プログラムのインストールが完了すると、事後イベントが即時に開始されます。

次の点に注意することをおすすめします。

  • 事前イベントを含む新しいスケジュールを作成するか既存のスケジュールを編集する場合、事前イベントを実行するには、メンテナンス期間の開始 (上記の例では午後 3 時) 前に少なくとも 40 分が必要です。そうでないと、現在のスケジュールされた実行が自動的に取り消されます。
  • スクリプトまたはコードからキャンセル API を呼び出すと、スケジュール全体ではなくスケジュール実行がキャンセルされます。
  • 事前および事後イベントの実行の状態は、選択したイベント ハンドラーで確認できます。

次のステップ

  • 事前および事後イベントを作成する方法については、メンテナンス前と後の構成イベントに関する記事を参照してください。
  • 事前および事後イベントを構成する方法、またはスケジュール実行をキャンセルする方法については、メンテナンス前と後の構成イベントに関する記事を参照してください。
  • Webhooks を使用して VM をオンまたはオフするために事前または事後イベントを使用する方法については、こちらを参照してください。
  • Azure Functions を使用して VM をオンまたはオフするために事前または事後イベントを使用する方法については、こちらを参照してください。