.NET開発者中心 厳選ブログ記事 Windows Azureの新IaaS機能「Virtual Machines」活用TIPS（後編） ―― 「SE の雑記」より ―― 小澤 真之 2012/07/05
Page1 Page2

■AzureのVirtual Machinesのディスクの基本構成と容量について

　昨日、twitterで、下記の質問がありました。

「Azureがデフォルトで提供しているVMsのイメージは、デフォルトで全体の容量が30Gbytes、空き容量は20Gbytes程度になっています。この環境でセキュリティ・パッチ適用をしながら運用すると、どれくらいの期間、容量オーバーにならずに使い続けられると思いますか？」

　これについて自分なりの考えを、以下にまとめてみたいと思います。ただしこれは、あくまで個人的な考えに過ぎず、以下のような結果になることは保証しませんし、いかなる責任も負いませんのでご了承くださいませ。

●VMインスタンスの基本的なディスク構成

　VMsにおける各VMインスタンスの基本的なディスク構成については、「蒼の王座： Windows Azure Virtual Machinesの概要」がとても参考になりますので、以下の説明と併せてご参照ください。

　OS選択用のギャラリから作成したVMインスタンスのディスクは、以下のような構成になっています（※この例では、「Windows Server 2008 R2 SP1」のイメージを使用しています）。

OS選択用のギャラリから作成したVMインスタンスの基本的なディスク構成

　そして、本稿の手順により自分でアップロードしたVHDでVMインスタンスを作成した際のディスク構成は、以下のようになります。

自分でアップロードしたVHDで作成したVMインスタンスの基本的なディスク構成

　「ディスク0（＝Disk 0）としてOSのブート・ディスク、ディスク1（＝Disk 1）としてテンポラリ（＝一時的）・ストレージが接続されている」という構成は変わりません。自分でアップロードしたVHDを使用した場合、ディスク・サイズが柔軟に設定できますので、Cドライブのサイズはギャラリのものより増やせます。

　ディスク0は自分のサブスクリプションのBlobストレージ上に保存されていますので、永続化領域として使用できます。実際のファイルは、Azure Storage ExplorerなどでBlobストレージに接続することで確認できます（次の画面はその例）（※前述の［FROM GALLERY］ではなく［QUICK CREATE］で作成した場合は、使用するストレージ・アカウントの選択ができませんので、任意の場所に保存できないので注意が必要です）。

Blobストレージとして保存されたディスク0（Azure Storage Explorer）

　VMsでは、サイズを見ると分かるのですが、オンプレミスで可変長のディスクとしてVHDを作成したとしても、Blobストレージでは固定長でサイズが取られるようです。従って、Cドライブを大きく作成してしまうと、ストレージの消費量が大きくなるので注意が必要です。

　次の画面のように（VMインスタンスのWindows OSの）デバイス・マネージャ上はどちらもVHDに接続していると認識されますが、Blobストレージ上に保存されているVHDはディスク0のものだけですので、ディスク1に関してはテンポラリ用の非永続領域として扱う必要があります。

VMインスタンスのWindows OS上のデバイス・マネージャにおける各ディスクの表示例

　なお、追加の永続化領域が必要になった場合は、新しい永続化ディスクを追加するということができますので、別ディスクとして容量を増やすことは可能です。

●ページ・ファイルはディスク1に保存される

　Cドライブの容量を消費する原因として、ページ・ファイルの存在があります。OSインストール直後のデフォルトの設定では、Cドライブに物理メモリと同サイズのページング・ファイルが作成されていると思います。AzureのVMsでは、ページング・ファイルはDドライブに作成されるようになっています。これは一般化したVHDを独自にアップロードした場合でも同様の設定になります。次の画面は、その両者のページ・ファイルの場所を示すダイアログの例です。

ページング・ファイルはDドライブに作成されるようになっている（左：ギャラリから選択した場合、右：独自のVHDの場合）

　ページ・ファイルの設定は、VMsを展開する際に使用される応答ファイル内の「RunSynchronousCommand」のところで「C:\Windows\OEM\Unattend.wsf」を実行することにより行われます（※この挙動は「C:\Windows\Panhter\Unattend.xml」から確認できます。このように「AzureのVMsでは、独自の応答ファイルが使用されている」という点は意識をしておく必要があります）。

　いずれにしてもVMsでは、ページ・ファイルは永続化されたシステム領域（＝ディスク0）ではなく、非永続化のテンポラリ領域に作成されるように設定されますので、システム・ドライブの使用量を抑えるようになっているといえます。

　Windowsマシンを運用されている方は、「この状態でもクラッシュ・ダンプを取得できるのか？」ということが気になるかと思います。この辺りは富士通が公開している「Windows Server 2008/Windows Server 2008 R2大容量メモリダンプファイル設計ガイド」がとても参考になります。

　Windows Server 2008 R2では、システム領域を使用せずにデータ領域のpagefile.sysを使用して、完全メモリ・ダンプを生成することが可能になっています。AzureのVMsは、このための設定となっているようですので、完全メモリ・ダンプを出力する必要になった場合にも、Cドライブにpagefile.sysを作成せずに運用ができると思います。

　カーネル・メモリ・ダンプの出力先に関しては、「%SYSTEMROOT%\MEMORY.dmp」になっていますが、既存のファイルがあった場合は上書きされ、恐らく数Gbytesの範囲に収まると思いますので、デフォルトの20Gbytes程度の領域が空いている状態であれば問題はないでしょう。

●で、Cドライブの容量は足りているのか

　繰り返しになりますが、ギャラリから作成した直後の状態で20Gbytes程度、Cドライブの空きがあります。個人的な意見としては、これだけの空き領域があれば十分に運用できると思います。

　先ほど示した富士通による資料に、Windows OSの推奨サイズの参考情報が記載されています。そこで示されているサイズは、修正プログラムを適用しながらの運用も考慮されています。それに従えば、全体の容量が30Gbytes、空き容量は20GbytesというVMsの環境でも、パッチを適用しながら運用できると考えられます。なお、この試算は数回のSP（サービス・パック）適用も考慮されたサイズになっているようです（※素のOSの状態での考えですので、ほかのミドルウェアが入っている場合は、そのフットプリント＋パッチ分の容量を差し引いて考慮する必要があります）。

　Windows Server 2008 R2 SP1を適用する際には、最低でも9〜10Gbytes程度の空き領域が必要です。これは現状の空き領域である20Gbytesで余裕がありますので、新しいSPが適用された際にも十分に適用が可能な空き領域のサイズとなっていると思います。また、SP1の際にはSP1のアンインストール用のファイルを消すことで、適用後にディスクの使用量を軽減するということができました。次のSPも同じ仕様になっていれば、適用後の使用中の容量の削減も可能かと思います。

　インストールする必要があるミドルウェアがあり、それがシステム・ドライブの領域を大量に消費するという場合には、ギャラリにデフォルトで用意されているイメージを使用するのではなく、（ミドルウェアの増分を加味した）適切なサイズでCドライブを作成したVHDをアップロードすることで、柔軟に対応できると思いますので、30Gbytesというサイズは実のところ、あまり気にしないでもよいのかな〜と思ったりもしています（といっても、大きなサイズでVHD作ってしまうと、ストレージの消費量が多くなるので、課金に気を付ける必要が出てきますが）。

【筆者プロフィール】 小澤 真之 　ブログでSQL Serverを中心にマイクロソフト製品の情報を発信しています。 SE の雑記

INDEX
	.NET開発者中心 厳選ブログ記事
	Windows Azureの新IaaS機能「Virtual Machines」活用TIPS（後編）
	1．AzureのVirtual Machinesにオンプレミスのイメージをアップロード
	2．AzureのVirtual Machinesのディスクの基本構成と容量について

「.NET開発者中心 厳選ブログ記事」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）