Azure VM 一時ディスクの変更 と 注意点
はじめに
Azure VM の一時ディスクは、OS ディスクとは別に用意されているディスクです。
この一時ディスクは、既定では Windows VM では "D:" であり、Linux VM では "/dev/sdb1" として提供されます。
しかしながら、利用したいと考えているアプリケーションの制限として、D: にインストールすることが必須であったりするなどの制限がある場合には、一時ディスクのドライブレターを変更する必要がある場合があります。
難しい手順ではありませんが、一時ディスクを別ドライブに変更する手順を確認してみます。
一時ディスクとは
通常、Azure VM が利用しているマネージドディスク(例えば C: )は、実態としてはネットワーク経由で提供されています。
一方、一時ディスクは、Azure VM をホストしている物理ホストのローカルディスクを利用して提供されています。
したがって、ネットワーク経由で提供されている他のディスクに比べ、非常に高速なディスクとして利用ができるものになっています。
高速というメリットに対し、デメリットもあります。
一時ディスクは、永続性がない領域ですので、失われて困るデータを置くことはできません。
Azure VM は様々な要因(例えば、ハードウェアの障害や、VMを停止して再起動させた際)により、別の物理ホスト上に移動される可能性があります。
その際、ネットワーク経由で提供されているディスクについては維持されますが、一時ディスクについてはデータが引き継がれず、新規に割り当てられます。(以前の一時ディスクは削除され、復旧できません。)
これらの特徴から、一時ディスクは、キャッシュやスワップ領域などに利用されることが多く、既定では、ページ ファイル(仮想メモリのスワップ領域)として利用されています。
なお、一時ディスクが提供されているのは、Azure VM の一部のシリーズのみで、全てではありません。
例えば、Dシリーズ(汎用) で新しいDv5の系列を見てみると
Dv5 および Dsv5 シリーズ … 提供されていない
Ddv5 および Ddsv5 シリーズ… 提供されている
という違いがあることがわかります。( "d" の有無である程度わかりますね)
Ddv5 および Ddsv5 シリーズ は 一時ディスクが提供されている
他、この辺も参考になるかと思います。
一時ディスクのドライブレター変更をしたVMでの注意点
一時ディスクの設定については、VM がデプロイされる際に、Azure によって自動的に構成がなされています。
プロビジョニングエージェントによって D ドライブが作成され、ページファイルが設定なされることで構成されることにより、新規 VM の作成時に、設定した覚えのない一時ディスクの設定がなされているというわけですね。
一時ディスクの設定を変更しても、再デプロイをしない限りは、特段利用には問題はありません。
しかし、VM を再デプロイするという場合には、再び実行される Azure 側の処理を考慮する必要が生じます。
例えば、
- Azure VM Backup で 新規VM としてリストア (既存を置換するリストアは大丈夫)
- Azure Ssite Recovery で フェールオーバー する
- Azure VM の複製のマスターとして利用する
といった場合です。
こういった場合、そもそも一時ディスクを利用しないサイズで構成したり、または都度、再デプロイ後にドライブ変更手順を実施したりする等、ケアを検討する必要があるでしょう。
このあたりは、おまけ、の箇所で確認してみます。
他、この辺も参考になるかと思います。
一時ディスクを変更してみる
では、一時ディスクの変更を試してみます。
なお手順は、以下公開ドキュメントにて案内されており、こちらに従っていきます。
Step.0 VM の作成
まずは確認するための VM を作成してあげます。
VMのサイズは、一時ディスクが提供されているものを選択します。
今回は Standard_D2ads_v5 を選択しました。75 GB の一時ディスクが提供されることがわかります。
追加のデータディスクとして 1 TB ディスクを作成します。
デプロイされた VM に接続し、ディスクの構成を確認してみます。
確かに D: ドライブとして 75 GB の一時ディスクが提供されています。
追加した 1 TB の データディスク は F: ドライブになっていますが、こちらを D: へ変更してアプリケーションのインストール用に利用をしたい、というのが今回のシナリオです。
Step.1 一時的に pagefile.sys を C ドライブに移動する
[スタート] メニューを右クリックし、 [システム] を選択します。
[Advanced system settings(システムの詳細設定の表示)] から、システムプロパティを開き、[Advanced] タブ の [パフォーマンス] セクションで [設定] を選択してパフォーマンスオプションを開きます。
[Advanced] タブ の [仮想メモリ] セクションで [変更] を選択します。
C ドライブを [System managed (システム管理サイズ)] 、D ドライブを [None (ページング ファイルなし)] に変更します。
設定したいドライブをクリックして、中ほどの [System managed size] / [No paging file] どちらかをチェックして [Set] をクリックすれば変更できます。
[OK] を押して進むと、変更を有効化するには再起動が必要な旨の警告と共に、再起動するかどうかの確認がきます。再起動します。
Step.2 ドライブ文字の変更
再起動後、[スタート] メニューを右クリックし、今度は「diskmgmt.msc」と入力して、ディスク管理ツールを起動します。
D: ドライブを右クリックして、[ドライブ文字とパスの変更] を行います。
[ドライブ文字] を変更する画面で、[D:] を選択して、[変更] をクリックします。プルダウンで変更したいドライブ文字を選択して、[OK] をクリックします。今回は T: にしました。
警告が表示されますが、[はい] をクリックします。
D: ドライブを T: ドライブに変更することができました。
同様の手順で、アプリケーションをインストールしたい追加ディスク(今回は F:ドライブ) を D: ドライブに変更してあげます。
Step.3 pagefile.sys を一時ストレージ ドライブに戻す
Step.1 と同様の手順で、C: ドライブを [None (ページング ファイルなし)] 、T: ドライブを [System managed (システム管理サイズ)] に変更します。
確認
VM を再起動し、確認してみましょう!
D: ドライブには、アプリケーションをインストールしたい追加ディスク 1 TB の領域が割り当てられています。
T: ドライブには、一時ディスク 75 GB の領域が割り当てられています。
無事に変更することができました!
おまけ1 - 一時ディスクの変更は、Azure VM Backup から 新規VM として Restore しても維持されるか?
一時ディスクの変更は、Azure VM Backup から 新規VM として Restore しても、維持されるでしょうか?
試してみた結果、追加ディスクを D: ドライブに割り当てた状態は維持されていましたが、ページファイルの構成エラーが出ている状況になっていました。
そのため、リストア後、ページファイルの設定を変更(Step.3を実施)する必要がありました。
なお、既存VM を上書きする形でのリストアであれば、問題はありません。
試してみた結果は、以下に畳んで、載せておきます。
一時ディスクの変更は、新規VM として Restore しても維持されるか? - ページファイルの構成エラーが出る - 検証結果
Azure VM Backup を有効化して、バックアップを取得しました。
バックアップ取得が完了したら、早速、VM の復元 を試してみます。
復元は、新規VMとして復元します。
復元の構成 [新規作成] とし、復元の種類として [新しい仮想マシンの作成] を選びます。
さて、起動したVMにログインしてみます。
おおっと、エラーが出ていますね…
エラーメッセージは、以下の通りです。
Windows created a temporary paging file on your computer because of a problem that occurred with your paging file configuration when you started your computer. The total paging file size for all disk drives may be somewhat larger than the size you specified.
コンピューターの起動時にページング ファイルの構成に問題が発生したため、Windows によってコンピューターに一時ページング ファイルが作成されました。 すべてのディスク ドライブのページング ファイルの合計サイズは、指定したサイズより多少大きい場合があります。
確かに、ページファイルの設定を確認すると、割り当てられている一時ディスクを利用できていない状況(全て None)になっています。
ディスク管理ツールで確認すると、 D: ドライブには、1 TB の追加ディスクが割り当てられた状態となっています。
一時ディスクの設定を変更して再起動すると、正常に起動することができました。
既存VM を上書きする形での Restore であれば、問題はない - 検証結果
[既存を置換] を選択してリストアする。
リストア後、変更した D: ドライブは維持されており、一時ディスクも U: ドライブのまま、ページファイルの設定も正常でした。
おまけ2 - Azure Site Recovery で異なるリージョンに復元する場合は、一時ディスクの設定は維持されるか?
こちらも試してみた結果、追加ディスクを D: ドライブに割り当てた状態は維持されていましたが、ページファイルの構成エラーが出ている状況になっていました。
そのため、Azure VM Backup の新規VMリストアをした場合と同様、フェイルオーバー後に、ページファイルの設定を変更(Step.3を実施)する必要がありました。
こちらも、試してみた結果は、以下に畳んで載せておきます。
ASRフェイルオーバした場合、維持されるか? - ページファイルの構成エラーが出る - 検証結果
保護したVMを、東日本から西日本へ、フェイルオーバしてみます。
フェイルオーバした VM にログインしてみます。
Azure VM Backup で 新規VM としてリストアした場合と同じエラーです。
やはり、ドライブレターの割り当ては維持されていますが、ページファイルの設定が上手くいっていないようです。
おまけ3 - 一時ディスクの変更は、 sysprep して複製できるか?
このVMを sysprep して、イメージ化し、複製することはできるでしょうか?
試してみたところ、一時ディスクが D: ドライブとなり、追加ディスクが E: 以降のドライブとなる(D: ドライブに割り当てた状態が変更されている)状態となりました。
この場合はもう一度、複製展開後の VM で 一時ディスクの設定を変更(Step1 - 3を実施)する必要があります。
こちらも、試してみた結果は、以下に畳んで載せておきます。
一時ディスクの変更は、sysprep 後も維持されるか? - 維持されない - 検証結果
sysprep してイメージ化し、複製する流れについては、以前以下に纏めました。
同様に試してみましょう。
まずは VM 内で コマンドプロンプトを管理者権限で開き、 sysprep を実行します。
rmdir /s /q C:\Windows\Panther
cd %windir%\system32\sysprep
sysprep.exe /oobe /generalize /mode:vm /shutdown
sysprep により VM が停止したら、VM を停止させたまま、CloudShell から 仮想マシンのステータスを [一般化] に設定します。
Set-AzVm -ResourceGroupName $rgName -Name $vmName -Generalized
ここまでで一般化が完了しましたので、Azure Portal から VM をイメージ化します。
さて、イメージ化が完了したので、複製して VM を作成してみましょう。
Sysprep により管理者アカウントなどは失われいるので、再設定する必要があります。
VM のサイズは、一般化前と同様の Standard_D2ads_v5 を選択します。
ディスク欄を確認すると、一般化前と同様の構成で、追加ディスクが自動指定されています。
VM を作成し、接続して確認してみます!
D: ドライブは、75 GB、 追加したアプリケーションをインストールするためのディスクは E: ドライブになっています。
見事に一時ディスクを移動させる設定が失われていますね。
まとめ
一時ディスクのドライブレターを変更することができます。
しかしながら、一時ディスクのドライブレターを変更した VM を長期運用しようとすると、バックアップやディザスタリカバリーの観点で面倒が生じそうですね。
D:ドライブを永続させる必要がある場合は、一時ディスクのないサイズにて VM に追加ディスクを構成して実現することを検討しましょう。
参考URL
Discussion