目次


クラウド環境における仮想イメージの増殖を防ぐには?

Comments

身近なところにイメージ・スプロールの怪物が存在していませんか?

2011年の 5月に、私は IBM® 内で WebSphere® の部門から Tivoli® の部門へと異動になりました。異動した最初の週、私はイメージ・スプロールの怪物に出くわしました。たった 2 件の顧客で 11,000 もの仮想イメージがあったのです。そのときから、私はこの 12月 (2011年) が来るのを実に心待ちにしていました。それは、この 12月に IBM から 2 つの新技術、IBM Image Construction and Composition ToolIBM Virtual Image Library がリリースされる予定であることを知っていたからです。この記事では、この 2 つの新技術を紹介し、イメージ・スプロールという恐ろしい怪物をコントロールし、スプロールを解消するために、これらの技術がいかに役立つかを説明します。

なぜイメージ・スプロールが発生するのか?

仮想イメージのスプロールは、仮想イメージが「ブラック・ボックス」であるという単純な事実から発生する、クラウド・コンピューティング業界の比較的新しい現象です。仮想化とクラウド・コンピューティングによって新しい仮想イメージを非常に容易に作成することができますが、イメージの中に何が含まれているかを把握することや、イメージを管理することは、非常に困難になっています。残念なことに、イメージ・カタログが増えるにつれ、適切なイメージを探し出すことが次第に困難になってきます。新しいイメージが作成されるのは、既存のイメージのどれが再利用可能なのかを判断するよりも新しいイメージを作成した方が容易だからです。

私が見るところ、ほとんどの顧客は以下の 2 つのカテゴリーのいずれかに分類されます。

  • 標準的なオペレーティング・システムのイメージのみを持ち、スクリプトと手作業によるインストールによってインスタンスごとにソフトウェア・コンテンツを追加している。
  • より多くのコンテンツをイメージに追加し、イメージ・スプロールの問題を抱えている。

効果的な形でバランスがとれている顧客は極めて稀です。その結果、仮想イメージ技術のメリットがフルに活かされていません。

イメージ・カタログを適切なサイズにする

私はパフォーマンスに関する業務経験が長かったせいかもしれませんが、私の固い信念として、どのようなパスのパフォーマンスを改善する場合であっても、完全に排除できる部分を最初に見つけ、その後で、残っているパスをもっと単純で高速に実行されるようにする方法を検討する必要があると思っています。また、バランスのとれたイメージ・カタログを作成するためには以下のような考え方も適用する必要があります。

  • する必要がないことであれば、それをしてはなりません。
  • 一度だけする必要があるものであれば、それを毎回してはなりません。
  • 自動化できることであれば、それを自動化する必要があります。

仮想イメージを作成することによるメリットは非常に大きく、一度イメージのインストールと構成を行えば、後はそのイメージを共有することができます。このためインストールと構成のスキルを持つ人員は、組織の中に最小限いればよくなります。インストールと構成のプロセスは一度だけ実行されて、テストが行われます。そしてそのイメージは必要に応じて単純にコピーされます。コピーのステップは繰り返し可能であり、またコピーを利用することによって (多くの場合に手作業で行われ、間違いを起こしやすい) ステップをなくすことができるため、品質を改善することができます。パフォーマンスの面でも大きなメリットがあります。インストール・プログラム単体を再度実行するよりも、イメージをコピーしてインスタンス化する方が短時間で処理が行われ、またイメージ・キャッシング技術と組み合わせると、実行時間を大幅に短くすることができます。

こうしたメリットから、私は単なる OS 以上のものを含む仮想イメージ・テンプレートに意味があると考えています。つまり私はコンテンツが含まれるイメージ・カタログを期待しています。しかし何千ものイメージから成るイメージ・カタログでは、今私が述べたメリットは失われています。そうしたカタログでは、1 つ 1 つのイメージがインストールと構成を必要としており、キャッシングのメリットはなく、保守は悪夢のような作業となり、イメージが共有されることはめったにありません。その一方ですべてのバリエーションに対して新しいイメージを作成するわけにはいきません。イメージの再利用と共有を促すようにバランスをとる必要があります。

このバランスをとるための答えは 1 つではありません。1 つのイメージに多くの内容を追加すればするほど、保守しなければならないイメージは増えることになります。一方でイメージに追加する内容が少なければ、スクリプトや手作業のステップが増え、間違いを起こす可能性のある要素が多くなります。イメージ・テンプレートに一度だけ「焼き付ける」ものと、インスタンス化する際に追加するものとのバランスをとるための大まかな目安として以下の 3 つを挙げることができます。

  • すべてのインスタンスに必要なものは、イメージに焼き付けます。これに該当するものとしては、オペレーティング・システムや皆さんの組織の標準 (監視エージェント、必要なセキュリティー、監査ソフトウェアなど) があります。これらはすべて、イメージに直接焼き付ける有力な候補です。
  • 大規模なものや作業に時間がかかるものは、イメージに焼き付けます。これに該当するものとしては、大規模なバイナリーや作成に時間がかかる構成ファイルなどがあります。例えばアプリケーション・サーバーやデータベース・サーバーなどのミドルウェア製品は、バイナリーや何らかのレベルの構成をイメージに直接焼き付ける有力な候補です。
  • 頻繁に変更されるものは、インスタンス化の際にスクリプトを作成します。これに該当するものとしては、短時間で設定できる構成や構成オプション (ポート番号やパスワードなど) があります。また、OS の緊急フィックスや開発中のアプリケーションなど、頻繁に変更されるソフトウェアも該当します。

Image Construction and Composition Tool を使用してバランスをとる

IBM は、IBM Hypervisor Edition のイメージや IBM Workload Deployer (旧 WebSphere CloudBurst™ Appliance) の仮想システム・パターンを作成する際、上記の目安に従っています。仮想イメージには、バイナリーが複数の構成と共にプリインストールされています。また各イメージに含まれる共通の構成パラメーターは公開されています。そのため、1 つの仮想イメージを多くの異なる環境やアプリケーションに使用することができます。イメージは単純にコピー (キャッシュ) され、目的に合わせて異なるパラメーター・セットを使用してインスタンス化されます。この異なる構成でインスタンス化された各イメージの間では、パターン・スクリプトが使用されます。パターン・スクリプトによる方法は高速であり、また特定のパターンの構成が数多くあるからです。またユーザーは、頻繁に変更されるコンテンツ (ユーザーのアプリケーションなど) に対する IBM Workload Deployer スクリプト・パッケージを追加することもできます。

IBM Image Construction and Composition Tool を使用すると、これらと同じ手法を適用して独自のイメージを作成することができます。このイメージ作成ツールは以下のような作業を支援するように設計されています。

  • イメージ作成時のコンテンツのインストールを自動化する。
  • インスタンス化する際の構成オプションを作成し、必要なイメージの数を減らす。
  • 1 つのボタンに触れるだけでイメージを再作成する。
  • 異なるクラウド (プライベートとパブリック)、または異なる OS やバージョンに対してイメージを再作成する。
  • イメージ内の特定のソフトウェア・バージョンと依存関係を識別する。

図 1 に示すように、IBM Image Construction and Composition Tool 環境を構築すると、IBM Workload Deployer、IBM SmartCloud Provisioning、IBM SmartCloud Enterprise、または VMware ESX のイメージを作成することができます。バンドルとイメージ定義は、さまざまなクラウド環境で再利用することができます。このツールは IBM Workload Deployer 3.1に含まれており、また SmartCloud Provisioning 1.2 オープン・ベータ・プログラムの一部として利用することができます。

図 1. IBM Image Construction and Composition Tool の概要
IBM Image Construction and Composition Tool の概要
IBM Image Construction and Composition Tool の概要

IBM Virtual Image Library を使用してイメージ・スプロールという怪物を理解し、コントロールする

既に皆さんの環境にイメージ・スプロールという怪物がいる場合、Virtual Image Library の機能を利用すると、手早く容易にスプロールを解消することができます。まず、Virtual Image Library を既存の VMware 環境に接続します。イメージの移動やコピーは必要ありません。これにより、特定のソフトウェアを含むイメージの検索を即座に開始することができ、また類似性や相違点のレポートも作成することができます。例えば最初のステップは、さまざまな組織が作成した、さまざまな Windows® イメージや Linux® イメージの数を削減することかもしれません。

まず、すべてを標準化するためのベースとなる、オペレーティング・システムのマスター・イメージの 1 つを選択します。「類似性検索」を実行し、似ているすべてのイメージを特定します。マスター・イメージと似ている (または同一の) イメージは、削除の有力な候補となります。例えば図 2 は類似性レポートの一例を示しており、2 つのイメージ (w2k3-db2client-9.1.4-eap と jeff-w2k3-db2client-9.1.4) は、実際には選択されたイメージと同一です。また、類似性の高いイメージも表示されています。似ているイメージに対し、ソフトウェア・レベルとファイル・レベルの両方でマスターに対する相違点の比較を実行し、何が違うのかを正確に突き止めることができます。おそらく、バリエーションの多くが不要なこと、そしてイメージの削除を開始できることがわかるはずです。

図 2. IBM Virtual Image Library の類似性レポートの例
IBM Virtual Image Library の類似性レポートの例
IBM Virtual Image Library の類似性レポートの例

ゴールデン・テンプレート・イメージを特定すると、IBM Virtual Image Library のリファレンス・リポジトリーとバージョン管理機能を使用して、それらのイメージを管理することができます。まず、それらのイメージを Version 1 として Virtual Image Library にチェックインします。次に、Virtual Image Library がゴールデン・テンプレートとそれらの場所を追跡できるように、それらのイメージを各運用リポジトリーにチェックアウトします。ゴールデン・テンプレートに変更が必要になった場合には、そのテンプレート・イメージをチェックアウトして変更を適用し、新しいバージョンとしてチェックインします。図 3 は、ある 1 つのイメージのバージョン・ツリーと、そのバージョンの明確な系統を示す系統図の例を示しています。

図 3. IBM Virtual Image Library の「Version Chain (バージョン・チェーン)」と「Family Tree (系統図)」の例
IBM Virtual Image Library の「Version Chain (バージョン・チェーン)」と「Family Tree (系統図)」の例
IBM Virtual Image Library の「Version Chain (バージョン・チェーン)」と「Family Tree (系統図)」の例

そして、この新しいバージョンを各ロケーションにチェックアウトします。可能な場合には、この時点で、この前のバージョンを運用リポジトリーから削除します。そうすることで、常に最新バージョンが使われるようになります。また簡単にバージョン間の比較を行って変更点を知ることができ、必要な場合にはいつでもリポジトリー内にある古いバージョンに戻すことができます。

すべてを統合する

IBM Virtual Image Library を使用してイメージ・スプロールという怪物をコントロールするのみならず、IBM Image Construction and Composition Tool を使用してイメージ・テンプレートの作成を始める必要があります。複数のマスター・イメージにわたって使用するコンテンツのソフトウェア・バンドルを作成すると、マスター・イメージの作成を容易に自動化することができます。また、インスタンス化を行う際のパラメーター化機能を使用すると、再利用しやすいイメージを作成することができ、さらにマスター・テンプレートを集約することができます。

頻繁に変更されるコンテンツのためにゴールデン・テンプレートを変更しなくても済むように、そうした頻繁に変更されるコンテンツをインスタンス化する際に取得する動的コンポーネントとして各イメージ・テンプレートに含めることを推奨します。そのための手法は数多くあります。IBM には IBM Tivoli End Point Manager (従来の BigFix®) という素晴らしいソリューションがあり、このソリューションではオペレーティング・システムのパッチのためのビルド済みコンテンツまで提供します。IBM Workload Deployer のユーザーは多くの場合、頻繁に変更されるコンテンツ (開発中のアプリケーションなど) を、仮想システムのパターン・スクリプトを使用して取得し、そのコンテンツをインスタンス化する際にインストールします。

まとめ

仮想化とクラウド・コンピューティングによって、イメージ・スプロールの問題が生じています。仮想イメージをより効果的な方法で作成、管理する方法を検討しない限り、クラウドのメリットをフルに活用することはできません。そのために IBM では、新しく Virtual Image Library と Image Construction and Composition Tool を提供しています。Virtual Image Library を使用すると、イメージに含まれるコンテンツを簡単に把握することができ、イメージの検索や、相違点と類似点の比較レポートの作成も簡単に行うことができます。Image Construction and Composition Tool を使用すると、再利用可能でパラメーター化されたイメージを作成することができます。

IBM SmartCloud Provisioning、IBM SmartCloud Enterprise、IBM Workload Deployer 3.1 で、これらの機能について調べてみてください。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=822899
ArticleTitle=クラウド環境における仮想イメージの増殖を防ぐには?
publish-date=07022012