Azure 上の Windows OS が起動しない場合の情報まとめ (2018 年 8 月 27 日版)
こんにちは、Azure サポート チームの石井です。
今回は Windows OS が上がらない場合の情報や心構えをまとめてお伝えします。
まずは、最新情報です。
Windows サポート チームより、8/23 に有用な Blog ポストが投稿されたので、こちらからもポインターを作成しておきます。
Windows OS としての、OS 起動の問題についての考え方と発生パターン・復旧パターンがまとまっています。(残念ながら、「壊れた原因は分からない」が通説です。OS があがらないのはファイルが壊れるからですが、「誰が何をどう書き換えたのか」 全てをログを記録していたら、きっとそれだけでまともに動作できないほど重たくなってしまうでしょう。)
OS が起動しなくなる問題 (NoBoot) 発生時の対処方法について – 概要
https://blogs.technet.microsoft.com/askcorejp/2018/08/24/noboot-troubleshoot-1/
OS が起動しなくなる問題 (NoBoot) 発生時の対処方法について – 対処方法
https://blogs.technet.microsoft.com/askcorejp/2018/08/24/noboot-troubleshoot-2/
続いて、Azure 特有の Tips をまとめました。
TIPS #1 ブート診断による画面確認
Windows VM ではブート診断を有効化していただくことで、Azure ポータル上から OS の画面ショットを見ることができます。RDP 接続が出来ない場合には、ブート診断を使ってどのような画面になっているか確認をしましょう。
ブート診断を使用して、Azure の Windows 仮想マシンをトラブルシューティングする方法
/ja-jp/azure/virtual-machines/windows/boot-diagnostics
TIPS #2 Azure における復旧方法
OS 起動不可能なケースに陥った場合、Blog ポスト "OS が起動しなくなる問題 (NoBoot) 発生時の対処方法について – 対処方法" にて記載されているような対策を Azure 上で行うにはどのようにすればよいでしょうか。
まず、起動ができない VM の OS ディスクを、他の正常な仮想マシンにデータ ディスクとして接続して対応するというケースです。
順序が前後しますが、"[3] SFC (System File Checker), [4] regback を用いたレジストリ復旧, [5] 更新プログラムのアンインストール" はこれで行えます。
参考: 以前、以下でも書いている部分がありますので、重複除去のため今回はポインターのみとしておきます。Regback ファイルの置き換えや、システム ファイル チェッカー (SFC) コマンドでなんとか正常に復旧できたという事例はありますので、試す価値アリです。
仮想マシンがつながらない場合のトラブルシュート (Windows)
https://blogs.technet.microsoft.com/jpaztech/2016/04/14/vm-windows-disconnection-troubleshoot/
続いて、"[1] スタートアップ修復" や "[2] Boot 構成情報の修正" の場合、これは Windows の回復コンソールの立ち上げが必要となります。回復コンソールは、Azure 上からは直接操作ができませんので、Nested Hyper-V を使っていただくか、VHD ファイルをオンプレミスにダウンロードし、オンプレミスの Hyper-V 上で行うことになります。
オンプレミスに Hyper-V サーバーが無い場合、Azure での Nested Hyper-V 用 VM を一時的に作成するということが便利です。オンプレミスでやる場合も、オンプレミス側の Hyper-V 構築 ～ VHD のダウンロード ～ VM の起動まで、手順はほとんど同じなので参考として下さい。
Nested Hyper-V を使った VM の復旧
https://blogs.technet.microsoft.com/jpaztech/2017/10/13/recover_vm_using_nested_hyperv/
Nested Hyper-V 環境内の VM から、インターネットに接続する必要がある場合には以下を参照してください。
Nested Hyper-V の VM からの外部への通信について
https://blogs.technet.microsoft.com/jpaztech/2018/04/16/connectivity_from_nested_vm/
TIPS #3 バックアップからの復旧
Windows OS としての復旧コマンドで 100％ 復旧するという保証はありませんので、万一のため、バックアップからの復旧を視野にいれておきます。特に、復旧までの時間がある程度予測できるのはこちらになります。
Azure Backup にて、VM のバックアップを取得しておけば、何かあった場合に前回正常であった、最新の状態からの復元が行える可能性が高いです。
ただし、復旧をより確実なものとするには、以下のような点も心がけてください
バックアップの基本: Azure Backup で複数世代のバックアップを保持する
起動できない、というエラーに陥った場合、何らかの形で Windows OS のデータが破損してしまっている状態と想定されます。
このようなケースで事例上少なくないのは、「バックアップを取ったその時点で、すでに何らかのデータが壊れてしまっていた」という状況です。Azure Backup は、VM を止めずにバックアップを取る事ができます。ただし、稼働中の OS は、起動時に必要なファイルの一部が破損しても、次の再起動までは走り続けることが出来るという場合があります。
つまり、その VM を再起動していたら、遅かれ早かれ OS は上がってこなかった・・・という事ですね。
※ 「Windows イメージに何らかの支障が発生した状態で稼働が続いているとどのようになるか」 くどいようですが補足します。
Windows VM を再起動したら、VM があがってこなかった。OS の問題が起きているようなので、バックアップから何世代か前のものを、複数試してみたが、どれをリストアしても同じ状態になってしまった。といったシナリオになります。
これは原因はひとつで、もともと Windows イメージが壊れており、そのまま稼働していたからです。Azure Backup は 1 日ごとに 7 世代、といったポリシー設定に基づいて世代管理しますので、その枠内で無事復旧できるイメージがあればいいですが、そうではない場合、Azure Backup でも復旧できないシナリオもある、ということです。サポートでも月に １ 回あるか無いか、という稀で不運な事例ではありますが、リスクとして想定したほうがよいかもしれません。
それでは、Azure Backup は何世代取ればよいのか？ ということになります。
再起動して無事あがってくることが保証できるタイミングまでを含めてもらうことが一番安全ですが、再起動なんて月に 1 度か、それ以下しかしない、ということも勿論あります。
その場合には
万一の際の備え: 正常な状態の VM を停止し、OS ディスクのスナップショットを作成しておく
ということが最も低コストでしょう。
また、Azure Backup などから復元した OS ディスクは、ディスクの交換を使って、現存する VM に直接差し替えが出来ます。(少し前まで、これが出来ず、VM を再作成が必須でした。復旧の迅速化のため、こちらの手順も検証しておくことをおすすめします。)
(PowerShell編)Azure仮想マシン(管理ディスク)の交換を活用して元のネットワークにリストアする
https://blogs.technet.microsoft.com/jpaztech/2018/06/04/ps-restore-vm-by-swap-manageddisk/
Unmanaged Disks (非管理ディスク)、Managed Disk (管理ディスク) 環境を問わず、VHD ファイルのスナップショットを取っておくことが可能です。
(※) スナップショットは必ず、VM を停止した状態で取得します。Azure Backup と違って、ディスクのスナップショットは VM の稼働状態で取るとデータが不整合になるためです。
スナップショットを取るため、VM を停止、開始させるので、OS が上がることも確かめることができます。
タイミングとしては、Windows OS にアプリケーションを追加したり、Windows Update を適用する、といったシステム変更に際してスナップショットを作成しておくと安心です。
追加コストの話
スナップショットの課金形態や考え方は、Unmanaged Disks (非管理ディスク)、Managed Disk (管理ディスク) で若干異なります。Azure Backup からさらに追加でコストが発生する部分ですので、適切に理解をするため、ご紹介します。
・Unmanaged Disks (非管理ディスク) のスナップショット
Unmanaged Disks (非管理ディスク) のスナップショットはもとのディスク (VHD ファイル) のコピーではなく、あくまでその時点の差分である。VHD ファイルを誤って削除してしまうと、スナップショットも削除されてしまう。
ただし課金の面では有利であり、あくまで差分の容量分のみが課金される。
例:
1. 元々の使用量が 30 GB のVHDでスナップショットを作成する。この時点ではスナップショットぶんの課金ゼロであり、30 GB の VHD の容量分のみの課金となる。
2. VHD ファイル上に 1 GB の変更が加わる。この時点で以前のスナップショットとの差分で生じた 1 GB が加算された、31 GB ぶんの課金が発生する。
上記のようなことが、公式ドキュメント Understanding How Snapshots Accrue Charges に書かれています。
・Managed Disk (管理ディスク) のスナップショット
Managed Disks のスナップショットは、元データの完全なコピーである。このため、スナップショットを作成した元のディスクを削除してしまっても、スナップショットは残る。
課金の面では、スナップショット元のデータのコピーのため、実使用量分のデータがまるまる課金対象になる。
※ ただし、Managed Disks はもともと、P10 (Premium, 128GiB) や S10 (Standard, 128GiB) といった VHD のサイズごとに課金枠が決まっているが、スナップショットはその中の実容量をベースに課金される。つまり、128 GiB の VHD 中、10 GiB しか使われていなかったら、10 GiB 分のみがスナップショットの課金額となる。
Premium ストレージのスナップショットを Standard ディスクに取る、ということも可能。つまり、P10 の Managed Disks をスナップショットを入れてコスト計算すると、P10 のもとのディスクの料金と、Standard スナップショットの容量別課金 * 使用している実容量GB の課金となる。
Managed Disks の価格
https://azure.microsoft.com/ja-jp/pricing/details/managed-disks/
<抜粋 (2018/8/27) > Premium SSD Managed Disks のマネージド ディスク スナップショットおよびイメージを、Standard ストレージに保存できます。オプションはローカル冗長ストレージ (LRS) とゾーン冗長ストレージ (ZRS) のいずれかをお選びいただけます。Standard LRS と Standard ZRS どちらのオプションでも、これらのスナップショットとイメージはディスクの使用量に応じて月々 \5.60/GB で課金されます。たとえば、プロビジョニングされた容量が 64 GB のマネージド ディスクのスナップショットを作成し、実際に使用したデータ サイズが 10 GB だった場合、スナップショットは、使用したデータ サイズである 10 GB に対してのみ課金されます。Premium SSD マネージド ディスク ストレージに保存することを選択した場合、1 か月あたり \17.03/GB で課金されます。
Unmanaged も Managed も、OS 起動が確約されるのであれば、前のバージョンのスナップショットは削除しても OK なので、1 世代分のスナップショットを保持すればよいということになります。
- 参考資料
バックアップと高可用性、DR との違い、といった点も理解しておくことが重要です。高可用性環境なら、VM 1 台の OS が起動しなかった場合にも復旧のための時間的猶予が生まれます。
以下ポストでも紹介していますので、ご参考下さい。
Azure エンジニアが解説する落ちないサービス入門
https://blogs.technet.microsoft.com/jpaztech/2018/05/29/aiming_no_downtime/