| title | date | tags | ||
|---|---|---|---|---|
Azure 仮想マシンにおける操作 (再起動、停止/起動、再デプロイ、再適用) について |
2021-05-24 10:30:00 -0700 |
|
こんにちは。Azure テクニカル サポート チームの洪です。
Azure 仮想マシンで予期せぬ問題が発生した際に、切り分けとして再起動や再デプロイをご案内することがありますが、その際、お客様よりそれぞれの操作の違いや目的についてご質問いただくことがあります。
そこで本稿では、 Azure 仮想マシンに対して行う操作として、「再起動」、「停止 (割り当て解除) / 起動」、 「再デプロイ」、「再適用」の違いに関して説明します。
各操作をご実施いただいた際に、「ゲスト OS の再起動」や「物理ホストの移動」が発生するか否かについて、下記の表の通りおまとめします。
| 操作 | ゲスト OS の再起動 | 物理ホストの移動 |
|---|---|---|
| 再起動 | 〇 | × |
| 停止 (割り当て解除) / 起動 | 〇 | △ ※1 |
| 再デプロイ | 〇 | 〇 |
| 再適用 | △ ※2 | × |
※1 明示的に物理ホスト サーバーの移動を行うわけではございません。可能性として、停止前と同一の物理ホスト サーバーで起動する場合もございます。 ※2 仮想マシンの再起動が必須となる操作ではありませんが、目標となるあるべき状態 (Goal State) に実体が追いつこうとした動作の結果、再起動が発生する可能性があります。
再起動は、ゲスト OS の再起動 を実施する操作です。ゲスト OS として Graceful Shutdown を実施し、その後起動します。 Graceful Shutdown とは、仮想マシンをシャットダウンする際にシステム内部で決められた手順に従い正常に仮想マシンを終了させることを意味します。 再起動による物理ホスト サーバーの移動は発生しません。 ゲスト OS 内のプロセスが正常な状態となっていない場合の切り分けとして、再起動の実行をご案内しています。
停止 (割り当て解除) は、仮想マシンが稼働する 物理ホスト サーバーから割り当てられているリソースの割り当てを解除 する操作であり、起動は 物理ホスト サーバーからリソースを割り当てる 操作です。 再デプロイと異なり、明示的に別の物理ホスト サーバーでデプロイを行うための手段ではありませんが、起動によって仮想マシンがデプロイされる物理ホスト サーバーは前回と異なる場合がほとんどになります。
停止 (割り当て解除) では、仮想マシンとしての課金はかかりません。(※ ディスクの課金はかかります。)
ご参考) 仮想マシンの課金の仕組み https://docs.microsoft.com/ja-jp/archive/blogs/dsazurejp/23
ゲスト OS 上でのみシャットダウンを実行した場合には、ポータルの画面より仮想マシンの状態が 停止済み (割り当て解除) ではなく、停止済み と表記されます。この場合はリソースがまだ割り当てられている状態との意味ですので課金が続けられます。
再デプロイとは、仮想マシンが稼働する 物理ホスト サーバーを明示的に変更 する操作です。 つまり、仮想マシンへのリソース割り当てを一度解除し、これまで稼働していた物理ホスト サーバーとは別の物理ホスト サーバーにて、仮想マシンに再度リソース割り当てを行います。 割り当ての対象となるリソースとは、vCPU コア、メモリ、NIC、一時ディスクなどの物理リソースです。
物理ホスト サーバー起因の問題が疑われている場合の切り分けとして、再デプロイの実行をご案内しています。
ご参考) ホスト サーバーの障害 https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/understand-vm-reboot#host-server-faults
なお、再デプロイに関しては、下記ブログ記事にて Azure PowerShell での操作方法などをご紹介しておりますので、ご参考としていただけますと幸いです。
ご参考) Azure 仮想マシンの再デプロイ https://jpaztech.github.io/blog/vm/vm-redeploy/
再デプロイを行う際は、下記の 2 点を注意する必要があります。
- 一時ディスクがある仮想マシン サイズをご利用の場合は、既存の一時ディスクは破棄され、新しくデプロイ先となった物理ホスト サーバーより再度割り当てられます。
- 仮想マシンに関連付けられた動的な IP アドレスは更新されます。
Azure のリソースの変更処理にあたっては、内部的に 「あるべき状態 (Goal State)」 と「実体」 という概念があります。 リソースに何かしらの変更処理が発生する際、まず Goal State が更新され、その後リソースの「実体」が更新された Goal State の状態と合致するように、変更処理が実行されます。つまり、「実体」 が「Goal State」 を追いかける動作になります。
再適用とは、同一物理ホスト サーバー内で リソースの あるべき状態 (Goal State) の情報を、リソースの実体にもう一度適用させる操作です。 何らかの理由でリソースの実体が Goal State の状態に遷移ができずエラーになってしまった変更処理に対して、もう一度同じ Goal State の情報を流し込む (適用する) ことで、前回の変更処理をやり直すことにより、仮想マシンの実体の状態と Azure 基盤側で保持している Goal Stateとの状態が不一致となっている状況の修正が試みられます。
この時、物理ホスト サーバーの移動は発生するわけではなく、また、再適用処理自体が VM の再起動を引き起こすわけではありません。しかし、その時点での仮想マシンの実体の状態と Goal State の内容の差によっては、上述の動作の結果、稀ではありますが再起動が発生する可能性があります。そのため、再適用の実行に当たっては、仮想マシンの再起動が発生しても差し支えない時間帯での実行をお勧めいたします。
仮想マシン プロビジョニング起因の問題が疑われている場合の切り分けとして、再適用の実行をご案内しています。
なお、再適用に関しては、下記公開情報に記載がございますので、併せてご確認ください。
新しい GoalState を仮想マシンにトリガーする https://docs.microsoft.com/ja-jp/azure/virtual-machines/extensions/troubleshoot#trigger-a-new-goalstate-to-the-vm
本稿が皆様のお役に立てれば幸いです。