次の方法で共有

Azure での仮想マシンのメンテナンス

  • [アーティクル]

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

Azure では、定期的にそのプラットフォームを更新して、仮想マシンのホスト インフラストラクチャの信頼性、パフォーマンス、セキュリティの向上に努めています。 これらの更新の目的は、ホスティング環境のソフトウェア コンポーネントの修正から、ネットワーク コンポーネントのアップグレード、ハードウェアの使用停止まで、広い範囲に及びます。

更新は、ホストされている VM にはほとんど影響しません。 更新が影響を及ぼす場合、Azure は影響が最小となる更新方法を選択します。

  • 更新で再起動を必要としない場合、VM は、ホストの更新中に一時停止されるか、または既に更新済みのホストにライブ移行されます。
  • メンテナンスで再起動が必要な場合は、計画メンテナンスが通知されます。 Azure により、都合の良いときに自分でメンテナンスを開始できる時間枠も与えられます。 セルフ メンテナンス期間は、そのメンテナンスが緊急でない限り、通常は 35 日間です (ホスト マシンの場合)。 Azure は、計画されたプラットフォーム メンテナンスで VM の再起動を必要とするケースの数を減らすためのテクノロジに投資しています。 計画メンテナンスを管理する方法については、Azure CLI、PowerShell、またはポータルを使用した計画済みメンテナンスの通知の処理に関する記事を参照してください。

このページでは、2 種類のメンテナンスが Azure でどのように実行されるかについて説明します。 計画外のイベント (停止) の詳細については、Windows 向けの VM の可用性の管理に関する記事または Linux 向けの該当する記事をご覧ください。

VM 内で、Linux または Windows 向けの Scheduled Events を使用して、今後のメンテナンスに関する通知を受け取ることができます。

再起動を必要としないメンテナンス

ほとんどのプラットフォーム更新は、お客様の VM に影響しません。 影響を及ぼさない更新が不可能な場合、Azure は、お客様の VM への影響が最小となる更新メカニズムを選択します。

VM に影響を与えるメンテナンスが必要な場合、ほとんどは VM を一時停止することで 10 秒未満で完了します。 まれな状況で、Azure では、VM を約 30 秒間一時停止するメカニズムが使用されます。これは、汎用 VM サイズの場合、18 か月に 1 回以下の頻度で行われます。 一時停止操作の後、VM のクロックは再開時に自動的に同期されます。

メモリ保持メンテナンスは、Azure VM の 90% 以上で機能します。 G、M、N、および H シリーズでは機能しません。 Azure では、ライブ マイグレーション テクノロジの使用を拡大すると共に、一時停止期間を短縮するためにメモリ保持メンテナンス メカニズムの改善に取り組んでいます。

再起動を必要としないメンテナンス操作は、一度に 1 つの障害ドメインに適用されます。 それらは、プラットフォーム監視ツールから警告の正常性シグナルを受信した場合、停止します。 再起動を必要としないメンテナンス操作は、ペアになっているリージョンまたは Availability Zones で同時に行われる場合があります。 特定の変更の場合、デプロイは主に Availability Zones のペア間およびリージョンのペア間でシーケンスされますが、末尾で重複が発生する場合があります。

こうした種類の更新が、一部のアプリケーションに影響を与える可能性があります。 VM を別のホストにライブ移行する場合、影響を受けやすい一部のワークロードでは、VM の一時停止に至るまでの数分間にわずかなパフォーマンスの低下が見られることがあります。 VM のメンテナンスに対する準備をして Azure のメンテナンスの影響を減らすには、そのようなアプリケーションに Linux または Windows 向けの Scheduled Events を使用してみてください。

ゼロインパクトやリブートレスの更新を含むすべてのメンテナンス アクティビティをより詳細に制御するには、メンテナンス構成機能を作成できます。 メンテナンス構成の作成では、すべてのプラットフォーム更新プログラムをスキップし、都合のよいときに更新プログラムを適用することができます。 詳しくは、「メンテナンス構成によるプラットフォームの更新の管理」をご覧ください。

ライブ マイグレーション

ライブ マイグレーションは、再起動を必要とせず、VM のメモリを保持する操作です。 これにより一時停止または凍結が発生しますが、その継続時間は通常は 5 秒未満です。 G、L、N、H シリーズを除く、サービスとしてのインフラストラクチャ (IaaS) VM はすべて、ライブ マイグレーションに対応しています。 ライブ マイグレーションは、M シリーズ SKU の大部分で利用できます。 対象となる VM は、Azure フリートにデプロイされている IaaS VM の 90% 以上に相当します。

注意

再起動を必要としないライブ マイグレーション操作については、Azure portal で通知を受信しません。 再起動を必要としないライブ マイグレーションの一覧を表示するには、スケジュール化されたイベントのクエリを実行してください。

Azure プラットフォームでは、次のシナリオでライブ マイグレーションを開始します。

  • Azure の計画メンテナンス
  • ハードウェア障害
  • 割り当ての最適化

計画メンテナンスの一部のシナリオでライブ マイグレーションが使用されており、Scheduled Events を使用して、ライブ マイグレーションの操作がいつ開始するか事前に把握できます。

Azure Machine Learning アルゴリズムでハードウェア障害の発生が予測されている場合や、お客様が VM の割り当てを最適化したい場合に、ライブ マイグレーションを使用して VM を移動することもできます。 機能低下しているハードウェアのインスタンスを検出する予測モデリングの詳細については、予測機械学習とライブ マイグレーションによる Azure VM の回復性の向上に関する記事をご覧ください。 ライブ マイグレーションの通知は、Azure portal の Monitor および Service Health のログ、およびScheduled Events に表示されます (これらのサービスを使用している場合)。

再起動を必要とするメンテナンス

計画メンテナンスで VM の再起動が必要になるまれなケースでは、事前に通知が届きます。 計画メンテナンスには、"セルフサービス フェーズ" と "予定メンテナンス フェーズ" の 2 つのフェーズがあります。

通常 4 週間続くセルフ サービス フェーズ中に、ご利用の VM でメンテナンスを開始します。 セルフ サービスの一環として、個々の VM に照会し、その状態と自分が最後に行ったメンテナンス要求の結果を確認できます。

注意

ライブ マイグレーションをサポートしていない VM シリーズの場合、メンテナンス イベント中にローカル (エフェメラル) ディスクのデータが失われる可能性があります。 ライブ マイグレーションがサポートされているかどうかについては、個々の VM シリーズを参照してください。

セルフサービス メンテナンスを開始すると、VM は、既に更新済みのノードに再デプロイされます。 VM が再デプロイされるため、一時ディスクは失われ、仮想ネットワーク インターフェイスに関連付けられた動的パブリック IP アドレスは更新されます。

セルフサービス メンテナンス中にエラーが発生した場合、その操作が停止し、VM は更新されず、セルフサービス メンテナンスを再試行するオプションが提供されます。

セルフ サービス フェーズが終了すると、予定メンテナンス フェーズが開始します。 このフェーズの間、ユーザーはメンテナンス フェーズについて照会することはできますが、自分でメンテナンスを開始することはできません。

再起動を必要とするメンテナンス管理の詳細については、Azure CLI、PowerShell、またはポータルを使用した計画メンテナンスの通知の処理に関する記事を参照してください。

予定メンテナンス中の可用性に関する考慮事項

予定メンテナンス フェーズまで待つ場合、ご利用の VM の可用性を最大限に保つために考慮すべき事柄がいくつかあります。

ペアになっているリージョン

各 Azure リージョンは、同じ地理的近傍内の別のリージョンとペアになっています。 それらは合わせて 1 つのリージョン ペアになります。 予定メンテナンス フェーズの間、Azure はリージョン ペアの一方のリージョンの VM だけを更新します。 たとえば、Azure は米国中北部の VM の更新中、同時に米国中南部の VM を更新することはありません。 ただし、北ヨーロッパなどのその他のリージョンは、米国東部と同時にメンテナンスされる可能性があります。 各リージョンに対して適切に VM を分散させるためには、リージョン ペアの動作を理解することが大切です。 詳細については、Azure リージョン ペアに関するページを参照してください。

可用性ゾーン

可用性ゾーンは、Azure リージョン内の一意の物理的な場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。 回復性を確保するため、有効になっているリージョンにはいずれも最低 3 つのゾーンが別個に存在しています。

可用性ゾーンは、障害ドメインと更新ドメインを組み合わせたものです。 Azure リージョン内の 3 つのゾーンに 3 つ以上の VM を作成する場合、VM は実際には 3 つの障害ドメインと 3 つの更新ドメインに分散されます。 Azure プラットフォームは更新ドメインへのこの分散を認識し、異なるゾーン内の VM が同時に更新されないようにします。

各インフラストラクチャの更新は、1 つのリージョン内でゾーンごとにロールアウトされます。 ただし、ゾーン 1 でデプロイを行っているときに、ゾーン 2 で別のデプロイを同時に実行できます。 デプロイはすべてシリアル化されているわけではありません。 ただし、リスクを軽減するために、再起動をが必要な 1 回のデプロイでは、一度に 1 つのゾーンのみロールアウトします。 一般に、再起動が必要な更新プログラムは可能な限り回避され、Azure によって Live Migration の使用や顧客の制御が試行されます。

仮想マシン スケール セット

フレキシブル オーケストレーション モードの仮想マシン スケール セットは、Azure コンピューティング リソースです。これにより、均一オーケストレーション モードの仮想マシン スケール セットのスケーラビリティと可用性セットのリージョンの可用性の保証を組み合わせることができます。

フレキシブルなオーケストレーションを使用すると、インスタンスを複数のゾーンに分散させるか、単一のリージョン内の障害ドメインに分散させるかを選択できます。

可用性セットと均一スケール セット

Azure VM にワークロードをデプロイするとき、可用性セット内に VM を作成して、アプリケーションの高可用性を確保することができます。 可用性セットを使用すると、再起動を必要とする停止またはメンテナンス イベントの間であっても、少なくとも 1 つの VM を確実に使用できるようになります。

可用性セット内の個々の VM は最大 20 個の更新ドメインに分散されます。 予定メンテナンス中は、どの時点においても 1 つの更新ドメインのみが更新されます。 更新ドメインは必ずしも順番に更新されるとは限りません。

均一オーケストレーション モードの仮想マシン "スケール セット" は、同一の VM のセットを単一のリソースとしてデプロイして管理するために使用できる Azure コンピューティング リソースです。 スケール セットは、可用性セット内の VM と同じように、UD をまたがって自動的にデプロイされます。 可用性セットと同様に、均一スケール セットを使用する場合、予定メンテナンス中に更新される UD は一度に 1 つだけです。

高可用性のための VM の設定の詳細については、Windows 向けの VM の可用性の管理に関する記事または Linux 向けの該当する記事をご覧ください。

次のステップ

Azure CLI、Azure PowerShell、またはポータルを使用して計画メンテナンスを管理できます。