Microsoft Azure Virtual Machines のベスト プラクティス: 単一の VM、一時ストレージ、アップロード済みディスク


このポストは、5 月 8 日に投稿された Virtual Machines Best Practices: Single VMs, Temporary Storage and Uploaded Disks (著者: Drew McDaniel) の翻訳です。

皆様、こんにちは。

Microsoft Azure Virtual Machines の機能開発チームに所属する Drew McDaniel と申します。私はチームが結成されてから現在まで、仮想マシン (VM) の機能開発に携わってきました。

このブログ記事では、Azure Virtual Machines の機能を最大限に活用するうえで役立つガイドラインとして、ベスト プラクティスをいくつか紹介したいと思います。これらのガイドラインは、お客様のフィードバックをそのまま採用しており、お客様に頻繁に発生するいくつかの問題を対象としています。

可用性セットに単一の VM を構成しないようにする

VM が Azure にデプロイされる際に、VM を可用性セット (英語) の一部として、または可用性セットが [None] に構成されるように構成できます。おそらく、すべてのユーザーが高可用性の VM を希望していらっしゃると思いますので、選択肢として [None] を挙げたことは少々誤解を招く説明かもしれません。同じ機能を提供する複数の VM がデプロイされる場合に推奨されるのは、可用性セットを選択することのみです。デプロイしている VM が同じ機能を提供する VM のセットの一部ではない場合に (つまり、1 つの共通のロード バランサーが管理する複数の Web サーバーや、データを複製している 2 つの SQL Server など、複数の VM の一部ではない場合に)、[None] を選択する必要があります。

「可用性セットに単一の VM をデプロイすることがなぜいけないのか」と思う方もいらっしゃるでしょう。簡単に言うと、可用性セット内に単一の VM インスタンスをデプロイすると、プラットフォームのメンテナンスに関する詳細な警告や通知が表示されなくなるからです。この構成では、単一の VM インスタンスのリブートが可能であり、プラットフォームのメンテナンスの実行時に、詳細な警告が表示されずにリブートが実行されます。

単一の VM インスタンスをデプロイして、可用性セットのオプションを [None] に設定すると、プラットフォームのメンテナンス処理で VM がリブートされる前に通知が表示されます。この構成を使用することで、リブートのタイミングと理由を把握していない状態で単一の VM インスタンスがリブートされるのを防ぐことができます。

複数の VM が可用性セットにデプロイされているときは、可用性セット内の VM に、プラットフォームのメンテナンスに対応しないわずかなサブセットが常に存在するように、バックグラウンドで Azure プラットフォームが管理します。そのため、可用性セットに複数の VM がデプロイされている場合は、少なくともそれらの VM の一部は常に稼働状態となります。単一の VM インスタンスが可用性セットの一部ではない場合は、この VM が高可用性セットの一部ではないことを Azure プラットフォームに指定します。このためマイクロソフトは、この設定に従って、プラットフォームのメンテナンス処理で VM がリブートされる前に電子メールでユーザーに通知されるようにする、特殊なプロセスを用意しています。

可用性セット内に存在する VM が 1 つだけである場合は、ベスト プラクティスの構成ではないことを示す警告が常に VM のダッシュボードに表示されます。この構成は、既存のサービス レベル アグリーメント (SLA) の保証の対象外です。

メモ: VM を可用性セット内、または可用性セット外に移動する場合は、移動時にその VM がリブートされます。

VM のサービス レベル アグリーメント (SLA) の保証の詳細については、こちらをご覧ください。

一時ストレージ

お客様が Microsoft Azure Virtual Machines を使用する主な理由の 1 つに、Microsoft Azure Virtual Machines が永続ディスクをサポートしている点が挙げられます。つまり、この永続性によりこれらの永続ディスクに書き込まれたデータは、リブート、起動と停止、またはその他のライフサイクル イベントを通じて利用可能になります。ただし、Microsoft Azure Virtual Machines には、VM ごとに 1 つの一時ディスクも含まれています。これらの一時ディスクのデータは、標準の VM ライフサイクル イベントを通じて保持されない可能性があります。これは、永続ディスクのデータが Microsoft Azure Storage に保存されるのに対して、一時ディスクのデータはハイパーバイザー ソフトウェアを実行するホストのオペレーティング システムに保存されるためです。

皆さんご想像のとおり、一時ディスクは、実際に一時的に使用するデータに対して非常に有用です。Windows のこの種類のデータの良い例として、ページ ファイルが挙げられます。実際に Azure のイメージから新しい Windows VM がプロビジョニングされる際は、ページ ファイルがこの一時ディスクに配置されるように構成されています。永続的に使用する必要があるデータに、一時ディスクを使用しないでください。よくある誤った構成として、お客様が一時ドライブに SQL データベース ファイルを配置する場合や、このドライブに Windows Active Directory ドメイン コントローラーのデータベース ファイルを配置する場合があります。

多くの Windows VM では、一時ディスクのボリュームには D:\ のドライブ文字が付けられます。"Temporary Storage" のドライブ ラベルも付けられます。これは、以下の Azure VM のスクリーンショットでご確認いただけます。

一時ディスクを誤って使用しないようにするために、一時ディスクがテスト手順の一部としてリセットされる操作を実行することをお勧めします。一時ディスクがリセットされる最も簡単な方法は、VM のサイズを変更することです。最初に必要に応じて VM を構成し、VM のサイズを変更して、その後すべてが予定どおりに機能するように VM を元に戻す必要があります。

OS ディスクのアップロード

Microsoft Azure の優れた利点の 1 つとして、Azure Virtual Machines で使用される VHD フォーマット ファイルを容易にアップロードできる点が挙げられます。アップロードされた VHD ファイルが Windows オペレーティングシステムを含むときには、VHD は以下の 2 つのカテゴリのいずれかになります。(1) OS を generalize する目的で、アップロードする前にゲスト オペレーティング システムで sysprep が実行されたもの、または、(2) ゲスト オペレーティング システムで sysprep が実行されていないもの。(2) の場合、ゲスト オペレーティング システムはオペレーティング システムを含むディスクとして登録されます。このディスクが VM の作成に使用される場合、デプロイ時に、Microsoft Azure での使用向けに最適化されるというプロビジョニング エージェントのメリットが得られません。そのため、Azure の VM を起動した後で、次のベスト プラクティスを実践する必要があります。

1. ページファイルを一時ディスクに移動する – 前述のとおり、通常、一時ディスクはドライブ D:\ です。ページ ファイルを一時ディスクに移動することをお勧めします。この操作により、ページ ファイルに関連する保存されたストレージのトランザクションが除去され、永続ファイルに保存する必要があるデータ用に、Microsoft Azure Storage への帯域幅が解放されます。

2. アクティベーションサーバーを構成する – この手順は、製品版の Windows またはボリューム ライセンス版の Windows であるアップロード済みディスクに有効です。この手順は、評価版の Windows の有効化には使用できません。Microsoft Azure から提供されたアクティベーション サーバーを使用して VM が有効化されるように構成するため、管理コマンド プロンプトで次の手順を実行します。

a. VM で製品版の Windows を実行している場合は、次の手順を使用して VM がボリューム ライセンス版の Windows になるように構成します。

i. 「KMS クライアント セットアップ キー」のページからご使用の Windows エディションの該当する KMS クライアント セットアップ キー (汎用ボリューム ライセンス キー) を探します。

ii. slmgr /ipk <セットアップ キー> <ENTER> と入力して、クライアント セットアップ キーをインストールします。

b. slmgr /skms kms.core.windows.net <ENTER> と入力して、KMS サーバーの DNS アドレスを設定します。

i. 21ViaNet が運用する Microsoft Azure の場合は、kms.core.windows.net を kms.core.chinacloudapi.cn に置き換えてください。

c. slmgr /ato <ENTER> と入力して、有効化を開始します。

3. SAN のポリシーを構成する – 新しいボリュームが自動的にオンライン状態になるように SAN のポリシーを構成するために、管理コマンド プロンプトで次のコマンドを実行してください。

1.Diskpart

2.SAN POLICY=OnlineAll

3.Exit

4. キープアライブを構成する – RDP セッションのタイムアウトを回避するために、管理コマンド プロンプトで次のコマンドを実行する必要があります。

a. reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /t REG_DWORD /vKeepAliveEnable /d

b. reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /t REG_DWORD /vKeepAliveInterval /d

これらのベスト プラクティスが役に立つと感じた方は、ぜひコメント欄にご意見、ご感想をお寄せください。その他の頻繁に発生する問題に直面している場合も、コメント欄にご記入いただければ幸いです。今後の記事で他のベスト プラクティスを公開できるよう取り組んでまいります。

--Drew McDaniel

Comments (0)

Skip to main content