※ 2018/8/28 更新 Azure ホスト側からのダンプの採取がお客様ご自身で出来るようになりました。
この場合、お客様の環境で事前に設定をしておく必要がありますので、この点についてはご注意ください。
Azure VM (Windows) で完全メモリ ダンプを採取する方法
https://blogs.technet.microsoft.com/jpaztech/2018/08/27/how_to_get_a_complete_memory_dump/
-> 近日 Linux 版も記事を公開予定です。
--------------------------------------------------
こんにちは、Azure プラットフォーム サポート部の石井です。
Azure 上で Windows の仮想マシンがフリーズした場合について、特にオンプレミスでの選択肢であったダンプを取るにあたっての手法などについてご紹介します。
- ダンプの採取にはサポート リクエストを発行してください。(※日数がかかります)
Azure では、基盤側の機能を使ってお客様の仮想マシンのダンプを採取することが可能です。当該手法によるダンプ採取にあたっての Windows OS 側の事前設定は不要です。
しかしながら、この機能は、Azure の仮想化基盤の管理者特権を使って行う必要がありますが、セキュリティ上の理由から、ユーザーには開放されていません。
Azure データセンターの管理部門に要請を行う必要がありますので、弊 Azureサポートにダンプの採取リクエストを行っていただき、1 ~ 2 営業日お待ちいただく必要があります。再稼働よりも原因追求を優先しなければならない場合にのみ有効となります。
この手法でダンプを取る場合、採取にあたってお客様の VM には影響がありません。自動で停止されることもありませんので、採取完了の連絡がサポートからありましたら、お客様ご自身の手で VMの再起動をしてください。
(※ システム全体のフリーズではなく、リモートデスクトップ接続を行って作業はできる場合には、従来の手順にて任意のタイミングでダンプが取れます。その手順は本記事の最後に記載いたします。)
ご参考: サポートにお問い合わせする方法について
http://blogs.msdn.com/b/dsazurejp/archive/2013/10/31/10462044.aspx
=> 技術サポートに対して、対象となるサブスクリプション ID と仮想マシン名を明記し、お問合せ下さい。
※Windowsのダンプの解析に必要なサポート契約について
Azure の技術サポート契約においては、原則として Azure 基盤が原因となる障害を解消するためのサポートをご提供するものとなります。Windows OS がフリーズする場合のダンプ解析については、原則としてプレミア サポート契約が必要となりますので、ご注意ください。ダンプの採取をし、ファイルをお客様にご提供するまでであれば、Standard 以上の Azure 技術サポートにて行わせていただきます。
エンタープライズ向け Premier サポート
https://www.microsoft.com/ja-jp/services/premier.aspx
- Azure での Windows Serverのフリーズ事例
ご参考までに、2016 年の過去事例にて、日本マイクロソフトのサポート部門にて、Azure の利用者からの Windows OS のダンプ解析に至った件数をカウントいたしました。フリーズした Azure 仮想マシンのダンプ採取・解析に至った案件は、日本マイクロソフトのサポート窓口を総計しても一桁しかありませんでした。
内訳としては、「サードパーティのウイルス対策製品が疑われる」、「Windows Server 2012 R2 の既知の不具合であったが、Windows Update での最新版の適用で再発が抑止できた」といったケースが筆頭となります。
その他のケースでは、「レジストリ破損、システム ファイル破損によるケースで、直近のバックアップからのリストアで復旧したもの」もありました。このようなパターンでは、Windows 標準の、便利なシステム ファイル チェッカー (sfc) で修復できるケースがありますので、ダンプを取ることが最速の解決策ではありません。
最後に、負荷によるフリーズの問題にパフォーマンス ログで調査をするなど、ダンプを解析するというアプローチを取らずに解決に迎えるケースもありました。
オンプレミスの時代から Windows OS のフリーズとは、えてしてハードウェア固有のデバイス ドライバーとの絡みで発生することが多いものです。ハードウェア固有の要因から切り離された Azure 仮想化基盤ではそういったトラブルから解放されるといっても差し支えありません。
また、オンプレミスでは、購入したハードウェアで何とかして稼働率を上げることが何よりも重要でした。
- ダンプ調査の道はハイコストです
オンプレミスで、OS のフリーズの調査にかかわったことのある方であればご存知かと存じますが、Windows OS のフリーズの調査や対処を行うことは、IT 管理者にとって極めてコストが高いといえます。
日本マイクロソフトのサポート部でも、「フリーズ＝ダンプをとって解析しなければ」というマインドにて対応を開始し、お客様に大変な苦労をしいてしまった、という苦い教訓もあります。オンプレミスではそれでも問題と向き合うことが重要なケースがありましたが、クラウドではどうなのか、改めて考えてみます。
クラウドの時代では、「物理マシンは故障する」「ソフトウェアにはバグがある」といったことを前提として、それでも稼働を続けるようなサービスを構成することを重要視しています。Azure では、これを可用性と呼んでいます。
お客様に構築いただくサービスでも、VMがフリーズしたり予期せずシャットダウンするようなケースを想定し、可能な限り他の VM でサービスを稼働続行するよう設計していただくことが大切です。うまく動作しない VM だけ、ローテーションから外して調査や復旧作業を行うといったオペレーションとなります。
Windows OS もソフトウェアである以上、バグが存在します。しかしながら、現在では顕著な不具合は数多くが対策済みとなっており、発生確率の極めて低い問題と向き合う事となります。
時には、サードパーティ製ドライバーをアンインストールしての切り分けを行う必要が生じます。そして、多くの場合、そのドライバーはシステム構築上不可欠なものですから、許容できない選択肢かもしれません。
頻度が高い問題であれば、原因追求がやりやすいという点ではよいのですが、過去 1、2 回しか発生していない、といったケースではフリーズの原因を突き止めて対処するには高コストな選択肢となると言えます。
コストについて言及すると、せっかく労力をかけたのですから、調査で分かった対策は、再利用が出来なければなりません。再発性が低い場合には、せっかく見つけたソリューションも再利用は期待できません。
IT 管理者から見ると、過去に自社環境で発生したフリーズはすべて共通する原因のように思えてしまいますが、いざ調べると、そうではないケースも多くあります。
- サービスを監視し、自動復旧させる
可用性の高いサービスを実現することで多くの問題がクリアできます。残存する数多くのソフトウェアの不具合や、多岐にわたる故障理由で発生する物理マシンのダウン、こういった理由によるサービス自体のダウンを最小化するということにコストをかけましょう、ということがクラウドに移行するにあたっての心構えの一つかと存じます。(もちろん、100%それができるわけではないですが、できる箇所から少しずつ。)
クラウドのサービス構築にあたっては、外部からの定期的な疎通確認などの手法で監視し、そのようなケースでは自動的に VM を強制再起動させるといった手法で早期に自動復旧し、サービスに戻すことが望ましい運用になります。
Azureでは、Restart-AzureRmVM や Stop-AzureRmVM といったコマンドは、5 分間、OS の正常なシャットダウンを待ちますが、それに応答しない場合には強制電源断による再起動を行ってくれる万能なコマンドです。
監視システムからフリーズを検知してから再起動が完了するまでの間は、ロードバランサーにより、ほかの仮想マシンがサービスの継続を担ってくれます。負荷は偏りますが、それも復旧に要しているわずか 5 分ほどのみとなります。
さらに、レジストリ破損など、システム自体が壊れているといったケースもあるかもしれません。VM のシステム稼働を停止せずに VM 丸ごとのバックアップが行える、Azure バックアップの機能も簡単に使えるようになっていますので「問題が起きなかった頃の構成」に VM ごと復旧するという選択肢であれば、長くとも数十分程度で行えます。
それでも、すべての IaaS 仮想マシンが、可用性を前提としたものとは限らないかと存じます。社内やエンド様への報告にあたって、調査が不可欠であるというケースもあるかと存じます。
Azure サポート部では、背景をお伺いした結果、ダンプの解析が必要不可欠だという相互認識が生まれた場合にのみ、ダンプ採取をお願いしております。
最後に、旧来の方法でもダンプが取れる方法がありますので、ご紹介をいたします。(こちらもまた頻度が激減しましたが) Windows OS におけるブルースクリーンの発生時のダンプ採取にも有効です。
- 補足: RDP 接続が行える状態でのダンプ採取について
従来の、メモリ ダンプを任意の出力にて採取するという方法も取れますが、Azure 仮想マシンではリモート デスクトップ接続での管理が前提となります。このため、RDP接続を行って作業は行えるが、特定のアプリケーションや OS の機能が完全に停滞してしまっているといった場合を想定した手順となります。
問題の分析にあたって、完全メモリ ダンプを採取されたいという場合には、オンプレミスの Windows マシンと同じく、Windows Server OS 内にてダンプの出力設定を行っていただいた上で、ダンプの採取コマンドを実行することとなります。
<完全メモリ ダンプの設定方法>
1. PageFile の大きさを 物理メモリ + 300 Mbyte の大きさに設定します。
「Windows ロゴ キー + pause」 キーを入力し [システム] ウィンドウを表示させます。
[システムの詳細設定] をクリックします。
[詳細設定] タブの [パフォーマンス] にある [設定(S)] をクリックします。
[詳細設定] タブの [仮想メモリ] の項目にある [変更(C)] ボタンをクリックします。
この画面にて、[すべてのドライブのページング ファイルのサイズを自動的に管理する(A)] オプションを外します。
システムボリューム (Azure の一時ドライブを指定します。通常は D: です。) をクリックします。
[カスタムサイズ] にチェックを付け、[初期サイズ]、[最大サイズ] の両方に物理メモリ + 300 Mbyte 以上の値を入力します。
(例えば 32 GB メモリの場合、33068 MB となります。)
その後 [設定] ボタンをクリックし設定を反映させ [OK] ボタンをクリックします。
"変更結果はコンピューターを再起動しなければ有効になりません。" というポップアップが表示されますので、[OK] ボタンをクリックします。
"パフォーマンス オプション" のウィンドウも [OK] ボタンにて閉じます。
2. 完全メモリ ダンプを設定します。
上記で表示させた [システムのプロパティ] ウィンドウにて [詳細設定] タブの [起動と回復] 枠内にある [設定(T)] ボタンをクリックします。
[デバッグ情報の書き込み] 配下のプルダウンより [完全メモリ ダンプ] を選択します。
[ダンプ ファイル] のテキスト ボックスには、"%SystemRoot%\MEMORY.DMP" というパスが記載されております。原則としてこの項目は変更せずにおいてください。
[自動的に再起動する(R)] および [既存のファイルに上書きする(O)] にチェックが付いていることを念のため確認します。(既定ではチェックがついております)
[OK] ボタンをクリックします。
その後、コンピュータを再起動させるかを問うポップアップが表示されます。差し支えなければ、再起動してください。設定のみ行っておき、後で再起動することも可能です。
なお、C: ドライブに当該のサイズの空き容量が無ければ、ダンプの保存ができません。この場合、データ量が限られてしまいますが、手順 2 で、[完全メモリ ダンプ] ではなく、[カーネル メモリ ダンプ] を設定してください。
上記設定を行った上で再起動をすると、ダンプの設定が完了します。
続いて、「RDP 操作が行える状態でのダンプ採取」には、NotMyFault というツールを利用します。
- NotMyFault の使用手順 (テスト用にブルースクリーンを発生し、メモリ ダンプの採取するためのツール)
[！！！注意！！！] 以下の手順 2 において、ブルースクリーンが発生します。強制電源断と同様、未保存のデータは消失しますのでご注意ください。
1. 下記ウェブサイトより NotMyFault ツールをダウンロードし、展開します。
NotMyfault
https://live.sysinternals.com/Files/NotMyFault.zip
2. 事象発生時、「ほかのユーザーのログオンが進まない」など、OS の部分的なフリーズと疑われる問題が発生している最中に以下を実行します。
解凍先のフォルダを開き、以下のファイルを起動します。
notmyfault64.exe
[Crash] をクリックしますと、ストップ エラー (ブルースクリーン) が発生し、メモリ ダンプ ファイルの出力が行なわれます。
RDP 接続はブルースクリーンの画面は見えず、この時点で不応答となって切断されます。しばらく (10 分ほど) 時間をおいて、再度接続してください。
再接続が行えない場合、Azure ポータルから当該の VM を再起動させてから接続します。
3. コンピューターの再起動後、DumpFolder に設定したパスにダンプ ファイルが生成されます。
次回発生時に上書きされてしまいますので、すみやかに取り出してください。