仮想マシンの管理機能だけがVirtual Machine Manager(SC2012VMM)の価値ではない。仮想化システムを支えるホスト(物理マシン)も効率よく管理するSC2012VMMの新機能と、近くリリース予定のSC2012 Service Pack 1の新機能について解説する。
前回の記事では、System Center 2012 Virtual Machine Manager(SC2012VMM)を使って仮想マシンのテンプレート化を進めることが、仮想マシンを作る際の繰り返し作業を大幅に減らすこと、さらには運用の標準化にもつながっていくことを解説した。最終回となる今回は、SC2012VMMの新機能によって、導入した仮想化をさらに便利に使うコツと、SC2012のこれからのロードマップについて解説しよう。
ここ数年、仮想化導入はサーバ統合のために進んできたといっても過言ではないだろう。今でも、残っている物理サーバを減らすべく、統合が進んでいることも事実だ。だからこそ、仮想マシンをいかに迅速かつ手間をかけずに作るかという一点だけでも記事になる。しかし、昨今の運用管理製品の進化は、仮想化基盤そのものの自動管理へと広がりを見せている。そのためにSC2012VMMでは以下のような機能も提供している。
読者の皆さんはリソース・プールという言葉を聞いたことがあるだろうか。コンピュータが持っているプロセッサやメモリ、ストレージなどのリソースを1つに束ねて(プール化して)おき、必要なときに必要な分だけ、そこからリソースを割り当てることで、リソースを無駄なく最大限活用できるようにしようという考え方である。
このリソース・プールという言葉は仮想化とともに使われることが多いのだが、言葉の持つイメージと実際の動作にはギャップがある。それは、サーバ仮想化技術の上で仮想マシンを作るという流れでは、仮想マシンを配置する物理マシン(ホスト)が持つリソースに仮想マシンが依存してしまうからだ(複数サーバ間で共有可能なストレージだけに注目すれば別の意見もあるだろうが、仮想化全体としてはまだまだ難しい)。そのため、物理マシンに関係なくリソース・プールから自由にリソースを選んで仮想マシンに割り当てるのは、そう簡単ではない。
そのギャップを埋めるべくSC2012VMMが仮想化管理製品として提供しているのが、動的最適化の機能である。これは、複数の仮想マシンが稼働する物理マシンの負荷状況をリアルタイムにチェックし、負荷の高い物理マシンから負荷の低い物理マシンへ自動的に仮想マシンを移動させることで、物理マシンの負荷の均一化を図る機能である。これにより、IT管理者の手を介すことなく購入したハードウェアをバランスよく利用することが可能となり、負荷の高い物理マシン上の仮想マシンだけが遅くなるといったリスクへの対応も自動化できる。
仮想マシン上ではアプリケーションが動作しており、アプリケーションの負荷は常に変動しているため、1つの物理マシン上で稼働する仮想マシンの数だけでは負荷状況は計れない。それならば、仮想マシンを止めずに物理マシン間を移動できるライブマイグレーションの機能を有効に活用して、特定の物理マシンの負荷が高くなってしまうような状況を自動的に回避しようというわけだ。
電源の最適化機能は、物理マシンの負荷が均一になるように調整する最適化の延長で実現される。この機能を利用すると、夜中もしくは週末といったシステム全体の負荷が減ることが分かっている時間帯に、稼働する物理マシンの数そのものを減らすことができる。仮想マシンの数は変わらなくても、個々の仮想マシンの負荷が減れば、当然集約率も上げられるため、少数の物理マシンに仮想マシンを集約させ、利用していない物理マシンの電源をオフにすることで、電気代を節約できる。もちろん、物理マシンの電源オンや仮想マシンの再配置も自動で行われる。
新しくHyper-Vホスト(物理マシン)を追加しようとすると、OSをインストールし、ドライバを入れ、Hyper-Vを有効にし、クラスタ環境に追加した上で、SC2012VMMに登録し、仮想マシンを配置できる状態にする必要がある。ベアメタル展開とは、これらの一連の作業を自動化するSC2012VMMの機能である。管理者はあらかじめ組み込むデバイス・ドライバなどの登録をしておくことで、物理マシン追加時の手間を一気に省くことができる。
パッチ管理の自動化機能もある。仮想マシンに対するパッチ適用は、動作するアプリケーションに影響を及ぼすため、仮想マシンごとに慎重に考える必要がある。しかし、仮想化基盤たるHyper-Vや管理用のOS、SC2012VMMなどは、設置場所によっては常に最新で、セキュアな状態にすることが望ましい場合もある。そこで、SC2012VMMでは、仮想化基盤へのパッチ管理を自動化する仕組みを用意している。基盤の管理を自動化することで、管理者にはその上で動くアプリケーションの管理に専念してもらおうというわけだ。
仮想マシンをなぜ作るのか? という問いは愚問だ。当然、その上で何かを動かしたいからに決まっている。では、例えば3階層システムを仮想マシンで構築する際、仮想マシンが3つできればそれで迅速に環境が作れたといえるだろうか。答えはNoだ。
なぜなら、3階層システムの場合、複数のWebサーバがロード・バランサによって負荷分散されながら、その後のアプリケーション・サーバを呼び出し、その後に控えるデータベース・サーバでデータの処理を行う必要がある。そのため、仮想マシンを3つ作る手間以上の作業が残っていることも多い。
SC2012VMMでは、このような複数階層を持つシステム環境を迅速に構築できる仕組みとして、サービス・テンプレートという機能を提供している。前回記した仮想マシンのテンプレートを高機能化させたものだと考えていただきたい。
サービス・テンプレートには、Webサーバ/アプリケーション・サーバ/データベース・サーバなどの階層管理と、それぞれの階層における仮想マシンのプロセッサ数やメモリ容量、OSの種類、展開時の標準台数と最大最小台数(階層ごと)、さらにはロード・バランサを含むネットワーク設定の情報までも組み込める。
あとは、このサービス・テンプレートを利用してサービスを作成するわけだ。誰が作っても、中程度のプロセッサとメモリに加えて最低限のストレージ容量しか持たないWebサーバ3台とアプリケーション・サーバ2台、十分なメモリとストレージが割り当てられたデータベース・サーバ2台の計7台の仮想マシンが自動作成される、といった具合だ。Webサーバの負荷が高くなったときの処理も、仮想マシンを1つ追加してからいちいち手動でWebサーバに仕上げるのではなく、Webサーバをスケールアウトするという処理を行うことで、Webサーバ用として事前に定義された仮想マシンが増えることになる。
極論をいえば、開発したアプリケーションと用意したデータベース定義を、できあがった仮想マシンに展開するだけでいきなりシステムそのものが動き出すということである。これはパブリックなクラウドでいうところのPaaS(Platform as a Service)に近いもので、この仕組みを社内で提供できるようになれば、社内のアプリケーション・アーキテクチャもサービス・テンプレートとして指定したものに集約(標準化)され、運用管理者を悩ませるアプリケーションの運用と管理もかなりシンプルなものになる。
もちろん、アプリケーション開発者からの反発を買わないように、サービス・テンプレートの定義は開発チームも交えて検討し、それらが迅速に提供できることのメリットを開発者に納得してもらう必要がある。ハードルが高いと感じる方もいるだろうが、従来からのサーバ集約が落ち着きを見せ始め、次の一手を模索する企業の中には、社内PaaSの実現に向けて動き始めたところもある。企業が抱える運用の課題を解決する手段の1つとして、検討してみる価値はあるだろう。
なお、本記事では詳細について触れなかったが、SC2012VMMでは、サーバ・アプリケーションの仮想化という新しい仕組みも提供しており、これからますます重要度が増すであろう「アプリケーションを意識した仮想化への取り組み」の支援も始めている。詳細は次のTechNetのページが参考になるだろう。
Copyright© Digital Advantage Corp. All Rights Reserved.