次の方法で共有


メンテナンス構成による VM の更新の管理

適用対象: ✔️ Linux VM ✔️ Windows VM ✔️ フレキシブル スケール セット ✔️ 均一スケール セット

Azure は、信頼性、パフォーマンス、セキュリティを改善し、新機能を導入する目的で、インフラストラクチャを頻繁に更新しています。 ほとんどの更新は、ユーザーに対して透過的に行われますが、一部のセンシティブなワークロードでは、数秒間であっても、メンテナンスのために仮想マシン (VM) がフリーズしたり切断したりすることが許されません。 センシティブなワークロードには、ゲーム、メディア ストリーミング、金融取引などがあります。

メンテナンス構成機能を使用すれば、多くの Azure VM リソースに対する更新を制御および管理することができます。 メンテナンス構成は Azure Resource Graph と統合され、低遅延と高スケールのカスタマー エクスペリエンスが実現されています。

重要

メンテナンス構成を使用するには、少なくとも共同作成者のロールを持ち、サブスクリプションがメンテナンス リソース プロバイダーに登録されるようにする必要があります。

スコープ

現在、メンテナンス構成では、ホスト、OS イメージ、ゲストの 3 つのスコープがサポートされています。 更新プログラムのスケジュール設定と管理はどのスコープでも可能ですが、主な違いは、スコープがサポートするリソースにあります。

範囲 サポートされているリソース
Host 分離された VM、分離された仮想マシン スケール セット、専用ホスト
OS イメージ 仮想マシン スケール セット
ゲスト VM、Azure Arc 対応サーバー

Host

このホスト スコープでは、分離された VM、分離された仮想マシン スケール セット、専用ホストで、再起動を必要としないプラットフォームの更新プログラムを管理できます。

このスコープに固有の機能と制限は次のとおりです。

  • スケジュールは、35 日以内であればいつでも設定できます。 35 日後は、更新プログラムが自動的に適用されます。
  • 少なくとも 2 時間のメンテナンス期間が必要です。
  • 現在、ラックレベルのメンテナンスはサポートされていません。

Azure 専用ホストに関する詳細情報

OS イメージ

メンテナンス構成で OS イメージ スコープを使用すると、より簡単で予測可能なエクスペリエンスを通して、仮想マシン スケール セット内の OS ディスクにアップグレードを適用するタイミングを決定できます。 アップグレードは、VM の OS ディスクを、最新のイメージ バージョンから作成された新しいディスクに置き換えることによって実行されます。 すべての構成済み拡張機能とカスタム データ スクリプトは OS ディスク上で実行されますが、データ ディスクは保持されます。

このスコープに固有の機能と制限は次のとおりです。

  • スケール セットでメンテナンス構成を使用するには、OS の自動アップグレードを有効にする必要があります。
  • 繰り返しは 1 週間 (7 日) までスケジュールできます。
  • メンテナンス期間には最低 5 時間が必要です。

ゲスト

ゲスト スコープは、Azure Update Manager と統合されています。 これを使用して、Azure、オンプレミス環境、Azure Arc 対応サーバーを介して接続されている他のクラウド環境に、Windows Server および Linux マシン用の更新プログラムをインストールする定期的なデプロイ スケジュールを保存できます。

このスコープに固有の機能と制限は次のとおりです。

  • 仮想マシンのパッチ オーケストレーションAutomaticByPlatform に設定する必要があります。
  • メンテナンス期間の上限は 3 時間 55 分です。
  • メンテナンス期間は、最低 1 時間 30 分必要となります。
  • [繰り返し] の値は、6 時間以上である必要があります。
  • スケジュールの開始時刻は、スケジュールの作成時刻から少なくとも 15 分後にする必要があります。

スケジュールの追加/変更オプションのスクリーンショット。

Note

  • リソース グループ名とメンテナンス構成名の文字数は、128 文字未満にする必要があります。

  • 新しく作成されたスケジュールの場合、トリガー時間の評価には 15 分の遅延がありますが、既存のスケジュールの場合は 3 分の遅延があります。 そのため、既存のスケジュールの場合は 23:57 から 00:00、新しいスケジュールの場合は 23:45 から 00:00 の間のスケジュールを作成しないことをお勧めします。 これは、トリガー時刻の評価ステージ後、ジョブを実行する前に開始日時がシステムによって再確認されるためです。 これらの制限時間内に構成すると、評価と実行の時間が異なるため、スケジュールがトリガーされない可能性や、VM が応答しなくなったりシャットダウンされたりする可能性があります。

メンテナンス構成では、ゲスト スコープの VM に対して、2 つのスケジュールされたパッチ適用モード (静的モードと動的スコープ モード) が提供されます。 既定では、動的スコープ モードが構成されていない場合、システムは静的モードで動作します。

どちらのモードでも、メンテナンス構成をスケジュールまたは変更するには、スケジュールされたパッチ時刻の前に推奨されるバッファーとして 15 分が必要です。 たとえば、午後 3 時にパッチ適応ジョブをスケジュールする場合、すべての変更 (VM の追加、VM の削除、動的スコープの変更など) は午後 2 時 45 分までに完了する必要があります。

本トピックについて詳しくは、「Azure portal と Azure Policy を使用してマシンの定期的な更新をスケジュールする」を参照してください。

重要

リソースを別のリソース グループまたはサブスクリプションに移動すると、システムは現在このシナリオをサポートしていないため、そのリソースに対するスケジュールされたパッチの適用は機能しなくなります。 回避策として、トラブルシューティングに関する記事の手順に従ってください。

シャットダウンされたマシン

シャットダウンされたマシンにメンテナンス更新プログラムを適用することはできません。 スケジュールされた更新の少なくとも 15 分前までにマシンの電源を入れてください。そうしないと、更新プログラムが適用されない場合があります。

スケジュールされた更新時にマシンがシャットダウン状態にある場合、Azure portal でメンテナンス構成の関連付けが解除されているように見えることがあります。 これは表示上の問題です。 メンテナンス構成の関連付けは解除されておらず、Azure CLI からその旨を確認できます。

管理オプション

次のいずれかのオプションを使用して、メンテナンス構成を作成および管理できます。

重要

API には、プレ/ポスト tasks プロパティが表示されますが、現時点ではこのプロパティはサポートされていません。

Azure Functions のサンプルについては、メンテナンス構成と Azure Functions を使用したメンテナンス更新のスケジュールに関するページを参照してください。

サービスの制限

指標として、次の制限をお勧めします。

インジケーター パブリック クラウドの制限 Mooncake/Fairfax の制限
リージョンあたり、サブスクリプションあたりのスケジュールの数 250 250
スケジュールへのリソースの関連付けの合計数 3,000 3,000
動的スコープごとのリソースの関連付け 1.000 1.000
リージョンあたり、リソース グループまたはサブスクリプションあたりの動的スコープの数 250 250
スケジュールごとの動的スコープの数 200 100
スケジュールごとにすべての動的スコープにアタッチされているサブスクリプションの合計数 200 100

ゲスト スコープの動的スコープに対してのみ次の制限をお勧めします。

リソース 制限
リソースの関連付け 1,000
タグ フィルターの数 50
リソース グループ フィルターの数 50

次のステップ