記事の目次 ≫   概　要 ≫   Solarisコンテナ ≫   ワークロード・リソースの管理 ≫   パーティショニング ≫   分　離 ≫   Solarisコンテナの進化 ≫   無料のホワイトペーパー

数年来、企業は大規模な情報システムを構築して、ビジネス上の問題に対処しようとしていました。特に重視されていたのは、状況の変化に対応でき、拡張性に富み、かつ可用性の高いITインフラストラクチャを構築することでした。ビジネス・アプリケーションのために十分な可用性とパフォーマンスを提供するのが、こうした努力の中心になっていました。今日、テクノロジーへの投資を無駄せずに、同じレベルのサービスを低コストで実現するというニーズが高まる中、重点は、ITインフラストラクチャのコストを引き下げ、エンドユーザーのサービス・レベル管理を改善することへとシフトしています。企業のこの目標は、Solarisコンテナが備えている機能を活用することによって実現できるとサンは確信しています。

Solarisコンテナは、ソフトウェアによって定義された柔軟な境界に基づき、各種のソフトウェア・アプリケーションやサービスを相互に分離します。この結果、アプリケーションは他のアプリケーションから独立して管理できるようになります。こうした分離は、Solaris OSの同じインスタンスで実行されているアプリケーションについても可能です。SolarisコンテナはSolaris OSの単一インスタンスの中にアプリケーションの実行環境を創り出し、以下のことを可能にします。

• リソースの完全な封じ込めとコントロールによって、サービス・レベルをこれまで以上に予測可能なものにします。
• ソフトウェア障害の孤立化によって、障害の広がりを最小限に抑え、予想外のダウンタイムを少なくします。
• セキュリティの孤立化によって、不正アクセスや意図しない割り込みを防止します。

Solarisコンテナの主要なメリットは次のとおりです。

• 管理コストの節約：サーバのコンソリデーション（統合）およびOSインスタンス数の削減を通じて管理コストを節約します。
• リソース使用率の上昇 ：各コンテナへリソースを動的に割り当てることによってリソースの使用率を高めます。
• サービス可用性の向上 ：障害の広がりとアプリケーション間のセキュリティ侵害を最小限に抑えることによってサービスの可用性を高めます。
• 柔軟性の向上 ：コンテナをベースとするソフトウェアは動的に再構成できます。
• アカウンティングの精度と柔軟性の向上 ：システムやプロセスではなくワークロードをベースとしてアカウンティングを実施します。

Solarisコンテナ

今日の企業は、需要の急速な増加に対処できるように、システムのキャパシティに余裕をもたせてピーク時の負荷に備えています。需要が通常のレベルのときは、この余分のキャパシティは使われないままです。こうした未使用のキャパシティを他のアプリケーションが利用できるようにすれば、コスト効率のよいソリューションを実現できます。需要のレベルが高くなれば、主要なアプリケーションにリソースを再度割り当てます。このようなリソースの共有はリソースの使用率の上昇につながり、システムの必要数の減少は資産やシステムの管理コストの削減をもたらします。アプリケーションの少数システムへの統合がうまく機能するには、個々のアプリケーションを別々に管理できるようにしなければなりません。このために必要なのは、リソースの使用をコントロールすること、障害を孤立化すること、同一サーバ上で実行されているアプリケーション間のセキュリティを管理することです。つまり、サーバ内で仮想サーバー間の境界を確立することが必要になります。

このためにまず行ったことの1つは、サンの大規模なサーバ上にDynamic System Domainを導入することでした。Dynamic System Domainでは、サーバをいくつかのドメインに分割し、そのそれぞれでSolaris OSを実行します。ドメインによってアプリケーション間にハードウェアの分離が確立され、いずれかのドメインで障害が発生しても、他のドメインには伝播しないようになります。ドメインの境界はリソースに対するニーズの変化に応じて動的に設定されます。リソースはシステムを再起動しなくても別のドメインに移動します。この結果、データ・センターの柔軟性を高める一方で、ドメイン間のセキュリティと障害の孤立化を実現できます。

Solaris 2.6に導入されたSolaris Resource Manager 1.x を出発点として、サンはSolaris OSの単一インスタンス内で実行されているアプリケーションを相互に分離し、リソース使用をコントロールする機能を徐々に強めてきました。その後、こうした機能を強化し、リソース使用のよりきめ細かなコントロールに向け、Solaris OSにはいろいろなテクノロジーが組み込まれました。Solaris 9 Resource Managerやリソース・プールはこの種のテクノロジーです。これらのテクノロジーによって、Solarisコンテナを作成できるのです。コンテナとは、境界付きの1つまたは複数のリソースを備えたアプリケーションもしくはサービスを指します。こうしたリソースの境界によって、CPUやメモリの消費、ネットワークの帯域幅、あるいはプロセッサのセットまでを制限できます。これにより、Solarisコンテナはサーバの統合を推進する大きな力となります。

Solaris 10に導入されたSolaris Zoneは、Solarisコンテナをさらに一歩推し進め、サブCPUのレベルでのサーバの分割を可能にしました。Solaris Zoneは一連のソフトウェア・サービスのための完全な実行環境であり、Solarisインスタンス内の仮想Solaris環境です。Zoneはソフトウェア・サービスからプラットフォーム・リソースへの仮想マッピングを提供し、単一のSolaris OSインスタンスを共有している複数のアプリケーションを相互に分離できるようにします。 Zoneはリソース消費の境界を確立し、リソースを同一システム上の他のZoneから切り離します。境界は、Zone内で実行されているアプリケーションの処理ニーズに応じて動的に変更できます。

Solarisコンテナは以下のテクノロジーのいずれかを使って構築できます。これらのテクノロジーを組み合わせ、特定のサーバの統合に適したコンテナを構築することも可能です。

• Solaris Resource Manager： ワークロード・リソースの管理用
• リソース・プール： パーティショニング用
• Zone： 分離、セキュリティ、仮想化用

SolarisコンテナとSolaris Zoneは同じものではありません。Zoneのテクノロジーを使い、一定の特性（仮想Solaris環境による分離など）を持つコンテナを作成できます。しかし、例えばリソース・プールによって可能になる特性が必要な場合は、リソース・プールを使ってSolarisコンテナを作成します。つまり、Zoneはコンテナの一種ですが、すべてのコンテナがZoneであるわけではありません。

ワークロード・リソースの管理

複数のアプリケーションの単一サーバへの統合を妨げている要因の1つは、アプリケーションが使用するリソースに対するコントロールの欠如です。2つのデータ・センターを単一システムに統合して、管理すべきシステムの数や必要なソフトウェア・ライセンスの数を減らそうとしている会社を想定してみましょう。

データベースの1つはオンライン販売用のアプリケーションが使用し、もう1つのデータベースはマーケティング用のアプリケーションが使用しているとします。販売用のアプリケーションは会社の中核ビジネスを支えるアプリケーションですから、必要時には最低限一定の量のCPUを保証されていなければなりません。マーケティング用のアプリケーションは補助的なアプリケーションですから、CPUに対するデータベース・サーバのニーズはそれほど切迫していません。こうした2つの条件に対処するための何らかのメカニズムがなければ、2つのアプリケーションの単一システムへの統合はうまくいきません。Solarisコンテナを利用すれば、Fair Share Scheduler （図1）を使ってCPUリソースの適切な境界を確立することにより、こうしたビジネス条件に対応できます。Fair Share Scheduler はワークロードの重要性に応じてCPUリソースの配分を制御します。

図1： Solarisコンテナにより、アプリケーションを単一システムへと統合するための安全な環境を創出

パーティショニング

リソースのより厳格な分離を必要とするケースもあります。たとえば、ある種のアプリケーションは、他のワークロードがどうであっても、一定の数の専用CPUを必要とします。あるいは、サービス・レベルの合意を通じて、特定のアプリケーションが使用できるCPUの最大数を決めておいたほうがよい場合もあります。Dynamic Resource Poolsを使えば、この種のパーティショニングが可能になります。

販売用のデータベースとマーケティング用のデータベースの例では、2つのDynamic Resource Poolsを作成できます。1つは多数のCPUであり、もう1つは少数のCPUです（図2）。販売用のデータベースは多数のCPUからなるプールに割り当て、マーケティング用のデータベースは少数のCPUからなるプールに割り当てます。Solaris 10では、アプリケーションの負荷の変化に対応して、これらのリソースを動的に調整することができます。これによって、管理者が設定したシステム・パフォーマンスの目標の達成が可能になります。

図2： リソース・プールを使ってリソースを分割

分　離

アプリケーションの統合を阻害しているもう1つの要因は、アプリケーション間が論理的に分離されていないことです。これが特に重要になるのは、複数のアプリケーションが異なる業務部門に属している場合です。会社全体のサービス・プロバイダとして、2つのワークロードを単一のシステムに統合しようとしている大企業のIT部門のケースを見てみましょう。現在のところ、IT部門は2つのシステムを管理しています。各システムはそれぞれのワークロード専用となっています。というのも、各ワークロードはそれぞれの業務部門に属し、各業務部門はそれぞれにシステムを調達しているからです。システムが未使用の状態になっているときが多いため、会社としてはアプリケーションを単一のシステムに統合して、コスト効率を高めることを望んでいます。

しかし、どちらの業務部門も他の顧客とシステムを共有することに反対しています。ネームスペースが競合するおそれ、セキュリティの問題、管理の競合などが反対の理由です。これらのワークロードの単一システムへの統合は、Solarisコンテナによって可能です。これを可能にするのは、ネームスペースの分離、セキュリティ、仮想化といったSolaris Zoneの機能です。業務部門ごとにZoneを作成することにより、IT部門は単一の物理システム上に2つの異なるシステムを構築できます。各業務部門にとっては、それぞれ専用のマシンを使っているかのようにしか見えません。

図3： Zoneによって、単一の物理システム上に複数の異なるシステムを構築

Solarisコンテナの進化

Solaris 10のリリースにより、Solarisコンテナは上述の機能をすべて備えるようになりました。しかし、ここで説明した機能の多くは、Solaris OSのこれまでのリリースでも使われていました。たとえば、Solarisコンテナが備えているFair Share Schedulerの機能はSolaris 9に組み込まれていました。Solaris 9より以前には、この機能はSolaris Resource Manager 1.x の形で提供されていました。これはSolaris 2.6以降のアンバンドル・ソフトウェアです。このように、ここで説明した機能の多くは、以前のプラットフォームでも同様に利用できます。

無料のホワイトペーパー

Solarisコンテナの詳細については、ここをクリックして 、Sun BluePrintsの新しいホワイトペーパー『Solaris Containers: What They Are and How to Use Them』をダウンロードしてください。

Solarisコンテナの詳細については、 http://www.sun.com/visitors-info/benchmarks/ をご覧頂くか、Site-TKY@sun.com 宛てに電子メールを送信してください。