Udostępnij za pośrednictwem

仮想マシン作成時に指定する二つの「名前」

  • Artykuł

なぜ二つ？

Windows Azure 仮想マシン (以下: 「仮想マシン」) で仮想マシンを作成する時、名前を指定する場所が2か所ありますよね。

まずここ、

image

図 1: 仮想マシン名

次にこっち。

 

image

図 2: DNS名

ちょっとしたテストのために一台作りたいだけなのに、何で名前を二つ考えなきゃいけないの？と思われるかもしれません。特に、「クラウド サービス」（一般名詞としてのクラウドサービスではなく、Windows Azureの機能の一つである「クラウド サービス」。Web ロール等があるやつ） にはあまり興味が湧かず、 「仮想マシン」が初 Azure である、という方はそう感じられるのではないでしょうか。

Windows Azure の仕組み

これは、Windows Azure の「クラウド サービス」の構造を考えるとすっきりします。そこで、 Windows Azure の登場人物 (構成要素) とその階層関係を改めて整理してみましょう。図3 に大雑把な構造を示し、以降、この図ベースで説明します。   

 

image

図 3: Windows Azure の基本的な構造

ホステッド サービス

まず、大きなくくりとして「ホステッドサービス」があります (図 3 の ①) 。PaaS の「クラウドサービス」にせよ、 IaaS の「仮想マシン」にせよ、この「ホステッドサービス」の中に配置されるという基本構造は共通です。

そして、ホステッドサービスの中は「プロダクション」と「ステージング」という二つの環境に分かれています。図 3 でいうと ①-A と ①-B です。役割の意図としては読んで字のごとく「本番環境」とその手前の「ステージング環境」です。

DNS 名

ここで「名前」が一つ登場します。ホステッドサービスのプロダクション環境には、「ksasakivm.cloudapp.net」のような DNS 名が「必ず」付きます。これは、ホステッドサービスの作成時に指定するもので、サービスをインターネットに公開した際にクライアントがアクセスしてくる FQDN そのものです。ホステッドサービス内には、複数のインスタンス(後述)が配置可能ですが、これらに対する負荷分散ホスト名になります。図 2 の「DNS 名」とはこれなのです。

デプロイメント

次に、プロダクションなりステージングなりの環境（入れ物）に対して、Web ロールや Worker ロールや Persistent VM ロール（これが「仮想マシン」）が配置されるわけですが、どんな種類のマシンが何台入っているか、というのをまとめた単位が「デプロイメント」です。Visual Studio から Windows Azure のプロジェクトを「発行」すればそれが 1 デプロイメント。HPC クラスタマネージャから Azure 計算ノードを 100 ノード追加しても 1 デプロイメント、スタンドアロンの「仮想マシン」を 1 台作るのも 1 デプロイメントです。

ロール

配置された「デプロイメント」の中身をのぞいてみると、いくつかの「ロール」が含まれています。「ロール」そのものは Windows Server や Linux を動かすマシンではなく、その定義情報です。Web サーバーを定義したロール、HPC の計算ノードを定義したロールなど様々なロールがあります。オブジェクト指向でいうところの「クラス」みたいなものです。

インスタンス （とその名前）

ロールの実体がインスタンスです。これは、 Windows Server (や Linux) が実行されている VM （仮想マシン）です。用語が紛らわしくて大変申し訳ないのですが、ここで言う VM とは、 Windows Azure の IaaS 機能であるところの「仮想マシン」だけを指すものではなく、「Azure のハイパーバイザー上で動いている仮想計算機」という広い意味での仮想マシンです。クラウドサービスの Web ロールや Worker ロール、VM ロール、IaaS の「仮想マシン」である Persistent VM ロール、それらのインスタンスはすべて仮想マシンです。 （ああ、一般名詞とかぶる固有名詞を編み出さないでほしいんだよな、説明が難しくなるから）

さて、ようやくインスタンスにまでたどり着きました。ここではゲスト OS が動いているわけなので、当然それに対してコンピューター名を付ける必要がありますが、これが先ほどの図 1 で指定する「仮想マシン名」です。

というわけで、大規模な公開サービスをホストすることを意識した Windows Azure では、一台一台のコンピュータにつける名前のほかに、それらに対する負荷分散用の DNS 名を付けるようになっており、この基本設計が、新しい IaaS 機能である「仮想マシン」にも受け継がれているというわけです。

旧ポータルで見てみる

この辺の構造は、実は旧ポータルで自分の「仮想マシン」を見てみるとわかりやすいのです。

私は今こういう 3 台の「仮想マシン」を持っているのですが、これを旧ポータルで見てみましょう。

image

 

こんな感じ。

image

 

"kshpcv4a" というホステッドサービス内の、プロダクション（運用）環境に "kshpcv4a" という名前のデプロイメントがあり、その中には 3 つのロールと、それぞれのロールに一つずつのインスタンスが存在します。

 

まとめると

  • 「クラウドサービス (PaaS)」も「仮想マシン (IaaS)」も、配置の基本的構造は同じ。
  • そのため、「仮想マシン」を一台だけ作る場合も、ホステッドサービスが必要。
    • ってことは、それ用の DNS 名を決める必要がある。
  • そして、個々のインスタンスにつくコンピュータ名は、当然 DNS 名とはまた別に必要。

ということです。

 

※ おまけ: クラウドサービスと仮想マシンの違い

旧ポータルで見るとわかるように、「仮想マシン」は「クラウドサービス」と違い、ロールとインスタンスが常に 1:1 です（少なくとも今のところは）。こういう構造になっているということがわかると、なぜ「仮想マシン」は「クラウドサービス」のように柔軟に台数を増減できないのか、といったあたりが見えてきますよね。

「クラウドサービス」の台数増減は、ロールのインスタンス数を変更する操作です。インスタンス数はサービス構成ファイル (.cscfg) で定義されており、ということは稼働中に更新できます。これに対し、「仮想マシン」の台数を変えようとすると、ロールのインスタンス数ではなく、ロールそのものの種類を増やさねばなりません。サービス構成 (.cscfg) ではなく、より根本的なサービス定義 (.csdef) を変更する必要があるということです。

では、なぜ仮想マシンは「1 ロール 1 インスタンス」なんでしょう。これは、仮想マシンのサイズはロール定義 (.csdef のほう) で決まっちゃうので、別ロールに分けておかないと複数の仮想マシンが全部同じサイズになっちゃう、とかそういう事情があるのかもしれません。

 

というわけで、本当は HPC 2012 のヘッドノードを作る話を書きたかったのですがそれはまた次回。

__END__