内部アーキテクチャ

内部アーキテクチャ

“お絵かき”をした構成図にパラメータを設定することで仮想データ・センターが完成することが理解できたと思います。以降では、こうした仕組みを提供する内部アーキテクチャについて簡単に紹介します。

図3は、CA AppLogicをインストールして稼働させているPCサーバーの内部を、論理的に示したものです。ハイパーバイザ（サーバー仮想化ソフト）には、オープンソースの「Xen」を利用しています。

この図の中にあるコントローラという仮想アプライアンスは、AppLogicがインストールされているグリッド全体のリソースを管理するなど、すべての意思決定を行う集中管理サーバーになります。これまで見てきた管理用のGUI画面は、すべてこのコントローラにWebブラウザでアクセスしたものです。

CA AppLogicではまた、ギガビット・イーサネットを2ポート使用します。このうち1ポートはパブリック・アクセス用で、残りの1ポートはバックボーン接続用です。2つを明確に区別して使用します。

パブリック・アクセス用は、その名の通り、パブリック・インターネットからアクセス可能なセグメントです。このセグメントには、INなどのようなファイアウォール・アプライアンスなどの仮想インタフェースがつながります。

バックボーン用は、GUIで“お絵かき”したカタログ間の接続などに利用するセグメントです。このセグメントは、パブリック・インターネットからは直接アクセスできません。このセグメントにつながる仮想インタフェースには、AppLogicのコントローラによってプライベート・アドレスが自動的に設定されます。

CA AppLogicの特徴として、ストレージのアーキテクチャも紹介します。

仮想データ・センターを構築する際、コスト的に無視できない要素に、FiberChannel（FC）のような外部ストレージがあります。通常、これらは高機能ではある一方で、コスト的なインパクトが大きなハードウエアです。

CA AppLogicは、設計思想として、外部ストレージを使うことを想定していません。コスト的に最も安価なのはローカルのHDD（DAS）だからです。

CA AppLogicでは、このローカルのHDDをうまく利用しながら、個々のPCサーバーのHDDにまたがってRAID1構成（ミラーリング）を組むことができます（図４）。グリッド全体のうち1台のグリッド・サーバーに障害が発生したとしても、残り1台のグリッド・サーバーに保存されたデータ・ボリュームは、引き続き運用が可能です。

これまで説明してきたように、CA AppLogicは、オープンソースのハイパーバイザであるXenのアーキテクチャを踏襲しつつ、GUIを用いたプロビジョニングを可能にしています。プロビジョニングでは、単に1つの仮想サーバーを起動させるだけではなく、複数の仮想サーバー間のコネクションまで考慮するように設計されています。

すぐに使える仮想アプライアンス群

冒頭で、約30個の仮想アプライアンスのひな型（カタログ）を標準添付していることを述べました。では、どのような仮想アプライアンスがあるのか気になります。図5に、数あるカタログの中から、いくつかを示しました。

これら標準添付されているカタログは、すべてLinux（CentOSなど）の上にOSS（オープンソース）のソフトウエアを搭載したものです（カタログの絵の左右にあるものは、仮想インタフェース）。OSSだけを使っているため、個別のアプライアンスを使用するにあたってライセンス費用などが発生しません。

OSSではなく有償ライセンスのOS（Windows Server 2003/2008やRed Hat Enterprise Linuxなど）をCA AppLogic上で使いたい場合にも、これら有償OSをAppLogic上で動作させる方法を提供しています。個別のカスタマイズが必要になりますが、Red Hat Enterprise Linuxのパラメータ設定をプロパティ画面で実施するといった柔軟性を提供しています。

これらのカタログが最初から提供されているので、ユーザーは、構築したいシステム環境をすぐに作れます。