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

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

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

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

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

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

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

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

影響がゼロではないメンテナンスでは、ほとんどの場合、VM の一時停止は 10 秒未満です。 場合によっては、Azure はメモリ保持メンテナンスのメカニズムを使用します。 これらのメカニズムでは、最大 30 秒間 VM が一時停止され、RAM 内のメモリが保持されます。 その後、VM が再開され、クロックが自動的に同期されます。

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

再起動を必要としないメンテナンス操作は、一度に 1 つの障害ドメインに適用されます。 それらは、プラットフォーム監視ツールから警告の正常性シグナルを受信した場合、停止します。

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

ゼロインパクトやリブートレスの更新を含むすべてのメンテナンス アクティビティをより詳細に制御するには、メンテナンス管理機能を使用できます。 Azure Dedicated Host または分離された VM を使用している必要があります。 メンテナンス管理では、すべてのプラットフォーム更新をスキップし、35 日間のローリング期間内の都合のよいときに、それらの更新を適用することを選択できます。 詳細については、メンテナンス管理と Azure CLI を使用した更新の制御に関するページを参照してください。

ライブ マイグレーション

ライブ マイグレーションは、再起動を必要とせず、VM のメモリを保持する操作です。 これにより一時停止または凍結が発生しますが、その継続時間は通常は 5 秒未満です。 G、M、N、H シリーズを除く、サービスとしてのインフラストラクチャ (IaaS) VM はすべて、ライブ マイグレーションに対応しています。 対象となる 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 が再起動されるため、一時ディスクは失われ、仮想ネットワーク インターフェイスに関連付けられた動的 IP アドレスは更新されます。

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

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

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

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

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

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

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

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

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

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

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

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

可用性ゾーン

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

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

各インフラストラクチャの更新は、1 つのリージョン内でゾーンごとにロールアウトされます。 ただし、ゾーン 1 でデプロイを行っているときに、ゾーン 2 で別のデプロイを同時に実行できます。 デプロイはすべてシリアル化されているわけではありません。 ただし、リスクを軽減するために、1 つのデプロイでは一度に 1 つのゾーンのみロールアウトされます。

次のステップ

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