仮想システム・パターンを設計する

仮想システム・パターンを計画、設計する際の重要な検討事項

IBM PureApplication System の仮想システム・パターンは、仮想マシンからアプリケーションに至るまでのシステムのデプロイメントを迅速に行えるようにするとともに、再現可能にします。仮想システム・パターンを使えば、トポロジー全体を完成させるために必要な手作業によるタスクを完全に自動化できるため、従来はアプリケーションをデプロイするのに数時間、あるいは数日かかっていたところを、ものの数分でデプロイできるようになります。このようにパターン指向でミドルウェアのデプロイメントを行うことで、エラーの原因になりやすい手作業による構成プロセスによってもたらされるバグが排除されるだけでなく、パターンにはベスト・プラクティスが組み込まれているため、ソリューションのデプロイメントが加速化および最適化されるというわけです。この記事では、仮想システム・パターンを設計して開発する際の重要な検討事項を明らかにします。

Nauman Fakhar, Senior Solutions Architect, IBM

Nauman Fakhar は、シリコンバレーにある IBM Cloud ラボ・チームのシニア・ソリューション・アーキテクトです。現在の職務では、IBM のお客様およびビジネス・パートナーのクラウド・ストラテジーとソリューションを支援しています。クラウド・ラボ・チームに加わる前は、新興企業や IBM の世界各地の WebSphere 販売相談チームに在籍していました。



Giuseppe Accardo, Senior Technology Consultant, IBM

Giuseppe Accardo は、フォスター・シティーの Silicon Valley IBM Innovation Center でシニア・テクノロジー・コンサルタントを務めています。彼の主な役割は、クラウド・コンピューティング技術を広め、IBM ビジネス・パートナーとそのクライアントが、それぞれのソリューションに IBM ソフトウェアおよびハードウェア・ポートフォリオを統合できるように支援することです。スマート・データ・センター・マネジメントで Tivoli ブランドに取り組んできた彼は、国際 IBM PureApplication System チームのメンバーとなっています。



2012年 5月 24日

仮想システム・パターンは、ベスト・プラクティスを利用して複雑なアプリケーションおよびプラットフォームの開発を完全に自動化することから、仮想システム・パターンの開発で最も重要な技術的役割を担うのは、アプリケーションのデプロイ担当者です。

アプリケーションのデプロイ担当者は、以下のタスクにおけるサブジェクト・マター・エキスパートです。

  • アプリケーションの前提条件 (ハードウェアとソフトウェアの両方) を特定する
  • 高可用性、スケーラビリティー、フェイルオーバー、およびフォルト・トレランスの観点からソリューション・アーキテクチャーを理解する
  • アプリケーションのデプロイメントにベスト・プラクティスを適用し、インストールおよび構成のボトルネックを理解する
  • アプリケーションを構成するすべてのコンポーネントをインストールする
  • アプリケーションをインストールするスクリプトを (シェル、Jython、DDL スクリプトを使用して) 記述する
  • 前提条件となるミドルウェアおよびソフトウェア製品を管理する
  • アプリケーションで基本的な機能テストを実行する

アプリケーションのデプロイ担当者は、手作業による重要なタスクの自動化タッチポイントを識別し、業界のベスト・プラクティスをパターンに組み込めるだけのインストール、デプロイメント、そして構成の経験を事前に積んでいることが理想です。例えば、お客様やユーザーのほとんどが WebSphere で Java 仮想マシン (JVM) をある特定のヒープ・サイズに設定して実行しているとしたら、この設定がパターンに組み込まれることになります。

そこで、この記事では仮想システム・パターンの計画および設計のプロセスに関するいくつかの案を検討し、要所要所で参考になる解説を提供したいと思います。記事で取り上げるトピックは以下のとおりです。

  • 仮想システム・パターン設計における重要な概念 (弾力性、トポロジー、オーケストレーション、セキュリティーなど)
  • 仮想システム・パターンをデプロイする際の重要な技術的側面
    • ランタイムを識別し、パターンのコンポーネントにマッピングする方法
    • パターンにネイティブ・コンポーネントを組み込む方法
    • 既存のアセット (スクリプトやツールなど) を再利用する方法
    • 仮想ディスクのサイジング
  • スクリプト・パッケージ、組み込み拡張・取り込みツール、および ICON (Image Construction and Composition Tool) のそれぞれを使用して、IBM PureApplication System に用意されている基本イメージ・カタログの機能を拡張する 3 つの方法
  • 反復型パターン開発およびテスト手法におけるベスト・プラクティス

重要なパターン設計概念

仮想システム・パターンを設計、開発する際には、以下の概念について検討する必要があります。

  • 弾力性
  • トポロジー
  • オーケストレーション
  • セキュリティー

以下で、それぞれの概念について詳しく説明します。

弾力性

クラウド環境に弾力性をもたらすには、リソースを動的に割り当てるという手段で、アプリケーションの自動水平スケーリングおよび自動垂直スケーリングを行う必要があります。仮想システム・パターンでは、IBM PureApplication System の IMP (Intelligent Management Pack) 機能を使用することで、WebSphere Application Server 環境に弾力性を持たせることができます。

IMP 機能は、ポリシーによって記述されたサービス・レベル・アグリーメント (SLA) やパフォーマンス・メトリックに応じて、仮想システム・パターン内の WebSphere Application Server セルをオンデマンドで拡大または縮小することができます。IMP が水平スケーリングを行う一例は、現行の CPU 容量不足などにより、WebSphere Application Server セルのワークロードが急増したことを検出した場合です。この場合、IMP はワークロードの需要を満たすために自動的に新しい WebSphere Application Server ノードをプロビジョニングします。さらに、IMP には構成時に垂直スケーリングを実装できるだけの柔軟性があります。応答時間に関する SLA に従ってパフォーマンスの劣化を防ぐために、IMP は WebSphere クラスター内で新しい JVM の起動をトリガーすることができます。

弾力性がアプリケーションの要件である場合、IBM PureApplication System で IMP 対応の WebSphere Application Server 環境を使用することを検討してください。

図 1. 仮想システム・パターンで IMP 対応の WebSphere イメージを選択する
仮想システム・パターンで IMP 対応の WebSphere イメージを選択する

トポロジー

現在お使いの環境に、トポロジーに関する既存のベスト・プラクティスが適用されている場合、それらのベスト・プラクティスは仮想システム・パターンにも関係してきます。

例えば、使用している本番環境のベスト・プラクティスとして、8 つの JVM とメモリー内のセッション・レプリケーションを使用してクラスター化した WebSphere Application Server をセットアップしている場合、本番フレーバーの仮想システム・パターンにも同じ設定を適用します。

開発およびテスト・フレーバーの仮想システム・パターンの場合には、単一サーバーの構成を選択し、JVM のヒープ・サイズを小さく設定することもできます。

仮想システム・パターンの設計の一環として、各製品 (そして製品ごとの VM の数) をリストにして、VM 間の関係を反映させたトポロジー図を作成しておくと役に立ちます。例えば、WebSphere Application Server が MQ サーバーに接続する必要がある場合には、この通信をトポロジー図に反映します。

図 2. 仮想システム・パターンのトポロジーを図に記述する
仮想システム・パターンのトポロジーを図に記述する

オーケストレーション

仮想システム・パターンのトポロジーを特定したら、当然次に行うべきステップは、各 VM で必要なアクションをリストアップして、システムの立ち上げをオーケストレーションすることです。さらに、それぞれのアクションを実行する順序も決定する必要があります。

図 3. トポロジーをオーケストレーションする順序を決定する
トポロジーをオーケストレーションする順序を決定する

例えば、アプリケーションのインストール・プロセスを行う場合に、データベースが所定のスキーマで稼働中でなければならないとしたら、アプリケーションのインストール・プロセスを開始する前に、データベースのセットアップをオーケストレーションしなければならないことは言うまでもありません。

このようなオーケストレーションを可能にするために、仮想システム・パターンでは、仮想マシンを起動する順序、そして仮想マシン全体で自動化スクリプトを実行する順序を設計者が指定できるようになっています。

図 4. 仮想システム・パターンのデプロイメント・ツールでオーケストレーションの順序を指定する
仮想システム・パターンのデプロイメント・ツールでオーケストレーションの順序を指定する

トポロジー図は仮想システム・パターン開発者の青写真となるため、トポロジー図の拡張版に、オーケストレーション・タスクをその順序と併せて記載しておくと役立つ可能性があります。

セキュリティー: ディレクトリー・サーバー

LDAP サポートは、仮想システム・パターンを設計する際に検討しなければならないセキュリティー関連のトピックの 1 つです。一般に、アプリケーション専用の LDAP サーバーは必須ではありません。ほとんどのアプリケーションは、保護対象のリソースへのアクセス権を許可するために、既存の LDAP サーバー (企業の LDAP ディレクトリーなど) に接続することになります。その場合には、LDAP サーバー・コンポーネントは仮想システム・パターンに組み込まれません。

WebSphere Application Server の観点からは、仮想システム・パターン内での既存の LDAP サーバーへの接続は、LDAP サーバー情報 (ホスト名、ユーザー ID とパスワード、等々) を入力パラメーターとして取るスクリプト・パッケージから取り込むことができます。スクリプト・パッケージは、Jython スクリプトによって WebSphere Application Server 内の LDAP 接続を自動的に構成することにより、仮想システム・パターンのユーザーが手作業で接続を構成する負担を軽減します。

図 5. スクリプト・パッケージを使用して WebSphere Application Server 内の LDAP 接続を構成する
スクリプト・パッケージを使用して WebSphere Application Server 内の LDAP 接続を構成する

アプリケーションに専用の LDAP サーバーが必要な場合には、IBM PureApplication System に用意されている Web アプリケーション用仮想アプリケーション・パターンを使用して、まず、新しい Tivoli Directory Server インスタンスを立ち上げます。すると、仮想システム・パターン内の WebSphere インスタンスが、新しく立ち上げられた Tivoli Directory Server LDAP サーバーに接続できるという仕組みです。WebSphere Application Server を新規 Tivoli Directory Server で構成するには、仮想システム・パターンに含まれるスクリプト・パッケージを使用することができます。

図 6. 仮想システム・パターン内の WebSphere Application Server インスタンスを、仮想アプリケーション・パターンで立ち上げた Tivoli Directory Server サーバーに接続する
仮想システム・パターン内の WebSphere Application Server インスタンスを、仮想アプリケーション・パターンで立ち上げた Tivoli Directory Server サーバーに接続する

組織内の他の重要な役割の人からの情報収集

組織によっては、サブジェクト・マターの知識がさまざまな役割の人に分散しているため、以下に挙げるような、さまざまな領域の技術専門家の参加が必要になる場合もあります。

  • アプリケーション・アーキテクト: 仮想システム・パターンを作成する一環として、製品版のマイグレーションが行われる場合には、アプリケーション・アーキテクトの参加が必要です。例えば、仮想システム・パターンにマイグレーションすることで、アプリケーション・サーバーのバージョンをあるレベルから別のレベルにアップグレードするとしたら、アプリケーション・アーキテクトはマイグレーションする可能性のあるコードについての情報を提供する必要も出てきます。
  • アプリケーション・テスター: アプリケーションに、アプリケーションのデプロイ担当者にはわからないような複雑な機能テストやパフォーマンス・テストが必要な場合、そのアプリケーションが仮想システム・パターン内にデプロイされた後に、テスターが参加して、アプリケーションが適切に機能することを検証する必要があります。
  • セールス・エンジニアおよび製品マネージャー: アプリケーションのインストール、構成、ライフサイクル管理、およびスケーリングに関してお客様が苦労する点をよく理解している従業員は、仮想システム・パターンを設計する上で有益な情報を提供することができます。例えば、10 日間かかっていたインストール/構成サイクルを、仮想システム・パターンによって 20 分に短縮できる場合、それによって市場投入までの時間、あるいは価値を生み出すまでの時間を短縮できるということを製品マネージャーが指摘することもできます。また、仮想システム・パターンによってお客様の POC 環境を (何時間/何日間ではなく) 数分で立ち上げられる場合、販売サイクルの平均時間を短縮できるとともに、製品の使いやすさをお客様に実証できるということをセールス・エンジニアが指摘することも考えられます。

推奨されるベスト・プラクティスは、設計に関する情報を収集する目的、そして考えられる問題を事前に発見する目的で、初期の打ち合わせに上記のさまざまな役割の人を関与させることです。そしてプロジェクトが進行するのに伴い、支援が必要になった場合に備え、中心となるアプリケーションのデプロイ担当者をさまざまな役割が含まれるチームと関連させます。

どのプロジェクトでも、仮想システム・パターンの開発には技術分野以外の役割の人 (例えば、プロジェクトの後援者やプロジェクト・マネージャーなど) が関係します。ただし、これらの役割について、この記事では説明しません。


ランタイムの識別およびマッピング

ランタイムを仮想システム・パターンのコンポーネントに効果的にマッピングするためには、当然、さまざまなランタイムを識別しなければなりません。そのプロセスについて検討します。

ランタイムを識別する

仮想システム・パターンを設計する際の最初のステップは、ターゲット・アプリケーションをホストするために必要なすべてのランタイム・コンポーネントを識別することです (これには、正確なバージョン番号を識別することも含まれます)。一般に、以下のランタイム・コンポーネントが必要になります。

  • 拡張機能 (例えば Linux 上の特定の RPM) が組み込まれたオペレーティング・システム
  • Web サーバー
  • アプリケーション・サーバー
  • データベース
  • ビジネス・プロセス・サーバー
  • メッセージング・コンポーネントおよび接続コンポーネント (MQ など)
  • カスタム・ミドルウェア・コンポーネント (例えば、カスタム C++ アプリケーション・サーバーなど)

はじめに確認しなければならないランタイムは、オペレーティング・システムです。そのオペレーティング・システムが IBM PureApplication System でサポートされていることを確認してください。

ミドルウェア・ランタイムをパターンのコンポーネントにマッピングする

必要なオペレーティング・システムがサポートされていることを確認した後、マッピング作業を開始します。

  • IBM ミドルウェア・コンポーネントは、IBM PureApplication System に付属のミドルウェア製品の Hypervisor Edition にマッピングする必要があります。例えば、ランタイム・コンポーネントの 1 つが Red Hat Linux 上の WebSphere Application Server V7 だとしたら、このコンポーネントのマッピング先は、IBM PureApplication System に付属の Red Hat Linux 用 WebSphere Application Server V7.x Hypervisor Edition イメージです。
  • IBM PureApplication System イメージ・カタログに、完全にバージョン番号が一致する IBM 製品がない場合には、アプリケーションを新しいバージョンの製品で実行できるかどうかを評価する必要があります。例えば、アプリケーションが WebSphere Application Server V7.0.0.17 で実行されている場合、IBM PureApplication System の WebSphere Application Server イメージのバージョンが V7.0.0.19 であるとしたら、アプリケーションをこの新しいバージョンの WebSphere Application Server で実行して評価する必要があります。
  • IBM PureApplication System に用意されている IBM 製品のバージョンではアプリケーションを実行できない場合、あるいは IBM 製品の Hypervisor Edition イメージが IBM PureApplication System イメージ・カタログに含まれていない場合でも、IBM PureApplication System が提供する柔軟性により、完全にカスタマイズした仮想イメージを作成することができます。
    図 7. カタログ内のベース・イメージを拡張して取り込む
    カタログ内のベース・イメージを拡張して取り込む
    • カスタム・イメージ: IBM PureApplication System での拡張・取り込み機能、または ICON ツールを使用することで、製品のカスタム・イメージを作成することができます。この方法では、オペレーティング・システムのハイパーバイザーのコア・イメージがベースとして取得されてから、そのオペレーティング・システムのコア・イメージに製品がインストールされます。このカスタマイズされたイメージが再び IBM PureApplication System に取り込まれて、繰り返しデプロイできるようになります。
    • カスタム・イメージのサポートに関する検討事項: IBM ミドルウェア製品のカスタム・イメージを作成する前に、カスタマイズ後の製品の構成がサポートされるかどうかを IBM サポートに確認してください。
  • 仮想システム・パターンのコンポーネントを IBM 以外の製品にマッピングする場合でも、上記で説明したカスタム・イメージの手法を使って、IBM 以外の製品を仮想システム・パターンに組み込むことができます。
    図 8. トポロジーを構成する製品を仮想システム・パターンのコンポーネントにマッピングする
    トポロジーを構成する製品を仮想システム・パターンのコンポーネントにマッピングする

パターンへのネイティブ・コンポーネントの組み込み

ネイティブ・コンポーネントとは、オペレーティング・システムに依存する製品またはランタイムのことです。例えば、C++ で作成されたカスタム・サーバーは、おそらく特定のオペレーティング・システムやアーキテクチャーで実行されるようにコンパイルされているはずなので、ネイティブ・コンポーネントであると見なせます。

ネイティブ・コンポーネントをパターンに組み込む場合、最も重要な点はそのコンポーネントが対応しているオペレーティング・システムと IBM PureApplication System 上のターゲットとなる Hypervisor Edition のオペレーティング・システムとを確実に対応させることです。

ネイティブ・コンポーネントを仮想システム・パターンに組み込む手段としては、スクリプト・パッケージ拡張・取り込み機能、または ICON ツールを使用することができます。


既存のスクリプトおよびツールの再利用

仮想システム・パターンは、お客様のインフラストラクチャーやプラットフォームに対する既存の投資を最大限に活用することを目的に設計されています。したがって、アプリケーションのインストールおよび構成を自動化するスクリプトは、仮想システム・パターンの開発で再利用する主要なアセットです。

図 9. スクリプトの再利用について説明する図
スクリプトの再利用について説明する図

例えば、WebSphere Application Server クラスターを作成し、データ・ソース/キュー定義を構成して、EAR ファイルをインストールする Jython スクリプトがあるとします。アプリケーションの立ち上げをオーケストレーションするために、このようなスクリプトを仮想システム・パターン環境で再利用するのは至って簡単です。同じことは、スキーマを作成してテーブルに初期データを取り込む DB2 DDL ファイルや SQL ファイルについても言えます。これらのスクリプトも、仮想システム・パターンに含まれる DB2 コンポーネントに簡単に適用することができます。

さらに、対応する IBM PureApplication System のハイパーバイザー・イメージが存在しない製品が仮想システム・パターンに含まれる場合には、その製品の既存の自動化ツールが仮想システム・パターンで極めて役立ちます。例えば、(GUI 駆動型のインストール・シールドとは対照的に) サード・パーティー製品のサイレント・インストール・ツールを仮想システム・パターンで再利用することで、IBM 以外の製品を自動的に立ち上げることができます。


ディスクのサイズに関する検討事項

Hypervisor Edition イメージのデフォルト構成には、特定のディスク・サイズが設定されています。例えば、WebSphere Application Server プロファイルは 2GB の仮想ディスクに配置され、DB2 データの仮想ディスクのサイズはデフォルトで 10GB に設定されます。

アプリケーションにデフォルトとは異なるディスク・サイズが必要な場合には、サイズを大きくした仮想ディスクで IBM PureApplication System カタログの対応する製品イメージの拡張・取り込みを行う必要があります。

それと同時に、仮想ディスクをいっぱいにする原因となるログ・ファイルと一時ファイルをクリーンアップまたはローリングするための戦略を準備する必要もあります。


パターンのコンポーネントの拡張および取り込み

IBM PureApplication System に、仮想システム・パターンの設計に含まれる製品に対応するハイパーバイザー・イメージがない場合 (これに該当する製品には、IBM 以外のサード・パーティー製品や、対応する Hypervisor Edition イメージが存在しない IBM 製品が考えられます)、その製品/コンポーネントを仮想システム・パターンに取り込むには、以下の 3 つの方法があります。

  • スクリプト・パッケージを使用する
  • 拡張・取り込みの手法を使用する
  • ICON (Image Construction and Composition Tool) を使用する

スクリプト・パッケージを使用する

スクリプト・パッケージを使用する場合、仮想システム・パターンによってプロビジョニングされる VM 上で、既存のスクリプトまたは新しいスクリプトを実行することができます。「パッケージ」と呼ばれる理由は、ユーザーがアプライアンスにアップロードする ZIP ファイルまたは TAR ファイルには、複数のスクリプトおよび関連するバイナリー・ファイル、そしてスクリプトの実行対象となるファイルを含めることができるためです。例えば、カスタムの Java プログラムを実行するスクリプト・パッケージの場合、ユーザーは JAR ファイルと併せて、その JAR ファイル内で Java コードを呼び出すシェル・スクリプトがまとめて含まれる ZIP ファイルをアップロードすることができます。

しかも、スクリプト・パッケージは組み込み環境変数にアクセスできるため、その実行環境となるクラウドに関して、よりインテリジェントに対応することができます。例えば、WebSphere Application Server VM に含まれるスクリプト・パッケージは、デプロイ時にクラウド内の (同じ仮想システム・パターンに含まれる) DB2 VM のホスト名を参照することができます。

したがって、IBM PureApplication System のハイパーバイザー・イメージにサード・パーティーのコンポーネントを自動的にインストールして構成するためにも、スクリプト・パッケージを使用することができます。

サード・パーティー製品をインストールする場合、どのハイパーバイザー・イメージを選択するべきかという問題に関しては、選択肢としてコア OS イメージ、またはパターンにすでに含まれている他のいずれかのハイパーバイザー・イメージがあります。この問題に適切に対応するには、いくつか検討しなければならないことがあります。

インストールしようとしているサード・パーティー製品を、仮想システム・パターンの一部となっているイメージ上に一緒に配置できるとしたら、その製品を該当する既存のイメージに比較的簡単にインストールすることができます。例えば、仮想システム・パターンに WebSphere Application Server イメージが含まれていて、サード・パーティー製品を WebSphere Application Server と同じ場所に配置できる場合には、スクリプト・パッケージを WebSphere Application Server VM に追加するだけで、そのサード・パーティー製品を簡単にインストールすることができます。

一方、その製品に固有の専用 VM が必要な場合には、仮想システム・パターン内でコア OS イメージを使用して、そのコア OS イメージにスクリプト・パッケージを追加します。コア OS イメージは、オペレーティング・システムだけがインストールされている空のハイパーバイザー・イメージです。コア OS イメージの VM は、他の通常の IBM 製品の VM と同じように、パターンの一部として立ち上げられるので、この VM に追加されたスクリプト・パッケージが実行されて、サード・パーティー製品のインストール、構成、起動が行われます。

したがって、この手法が適切なのは、サード・パーティー製品のバイナリーがそれほど大きいサイズではなく (この記事を執筆している時点では、IBM PureApplication System GUI からアップロードするスクリプト・パッケージのサイズは、2GB に制限されています)、サード・パーティー製品のインストールや構成がそれほど複雑ではなく、シェル・スクリプトで自動化できる場合です。

スクリプト・パッケージのサイズが 2GB を超える場合には、デプロイメント・ツールのコマンド・ライン・インターフェースからパッケージをアップロードできることを覚えておいてください。大容量のファイルや製品バイナリーをスクリプト・パッケージに含める場合は、大容量のファイルをネットワーク・ファイルシステムや中央リポジトリーに保管し、スクリプトがその場所にアクセスすることでファイルを取得する、というのがベスト・プラクティスです。

拡張・取り込み

スクリプト・パッケージを使用する場合には、仮想システム・パターンのデプロイメント時にハイパーバイザー・イメージを (スクリプトによって) カスタマイズすることができますが、一方、拡張・取り込みの手法では仮想システム・パターンをデプロイする前に VM をカスタマイズして、そのカスタマイズ済み VM を IBM PureApplication System カタログの一部にします。

すべてのパターンで VM の標準ベースラインを設定する場合には、拡張・取り込みの手法が役立つはずです。例えば、IBM PureApplication System 内の WebSphere Application Server ハイパーバイザー・イメージ・プロファイル・ディレクトリーに設定されているデフォルトのディスク・サイズでは要件を満たせないことから、WebSphere Application Server プロファイルのディスク・サイズを大きくしたいとします。その場合、カタログ内の WebSphere Application Server イメージを拡張して、WebSphere Application Server プロファイル・ディレクトリーのディスク・スペースを増やすことができます。この原則は、すべてのパターンで特定の Linux RPM を特定の VM に配置するなど、VM 上で行う必要があるあらゆる標準化に当てはまります。

さらに、この拡張・取り込みの手法は、サード・パーティー製品をコア OS イメージや既存の IBM 製品のハイパーバイザー・イメージにインストールするためにも使用することができます。拡張・取り込みの手法を使用した場合の手順は、まず拡張するイメージをクラウドにデプロイし、そのイメージ用にプロビジョニングされた VM 上で手作業によるカスタマイズ (サード・パーティー製品のインストールなど) を行います。カスタマイズが完了したら、デプロイされた状態の VM を新しい論理名でカタログに取り込みます。これで、このカスタマイズされたイメージを任意の仮想システム・パターンで使用できるようになります。

拡張・取り込みの手法がスクリプト・パッケージよりも (サード・パーティー製品に) 優先されるのは、スクリプトで製品のインストールや構成を行うことができない場合です。例えば、製品を GUI でしかインストールできないとすると、人間が介入しなければなりません。このような場合には、拡張・取り込みの手法が有効な選択肢となります。さらに、仮想システム・パターンに製品を短時間でオンボードしなければならない一方、現時点では自動インストール用のスクリプトを作成するためのリソースがないという場合にも、拡張・取り込みの手法が望ましい選択肢となるはずです。

また、サード・パーティー製品のバイナリーがかなり大きい (例えば 2GB を超える) 場合も、スクリプト・パッケージよりも拡張・取り込みの手法が望ましい手段となります。

知っておくべき点として、スクリプト・パッケージはベース・イメージにさまざまな「フレーバー」を追加することができるため、「イメージのスプロール」として知られる問題を防ぎます。スクリプト・パッケージを使用しなければ、ベース・イメージの構成がほんのわずかに異なるだけだとしても、拡張・取り込みのプロセスを踏まなければならないため、結果的にカタログ内のイメージの数が大量に増えていくことになります。

拡張・取り込みの手法には、以下の問題があります。

第 1 に、取り込んだ VM でユーザーが行うカスタマイズは手作業によるものであるため、そのカスタマイズ作業を完全にドキュメントにしておかない限り、それを再現するのは困難です。例えば、Red Hat と SuSE Linux の両方をサポートするとしたら、それぞれの Linux フレーバーに対してカスタマイズを 2 回繰り返さなければなりません。同様に、ある時点でハイパーバイザー・イメージを新しいバージョンにアップグレードする場合にも、この手作業によるカスタマイズを繰り返す必要があります。

第 2 に、カスタマイズしたイメージの特定のプロパティーは動的であることを忘れないでください。これらのプロパティーは、デプロイメントごとに異なります。例えば、クラウド内のイメージのインスタンスには、それぞれ動的にホスト名または IP アドレスが割り当てられます。イメージに構成されたサード・パーティー製品にこのような動的な情報が必要な場合には、イメージに関連付けられた (イメージのアクティベーション時に実行される) スクリプト・パッケージを使用して、イメージ内の情報を更新する必要があります。

これらの問題の一部は、ICON ツールを使用することによって解決されます。

ICON (Image Construction and Composition Tool) を使用する

IBM PureApplication System に付属の ICON (Image Construction and Composition Tool) は、ベースとなる仮想イメージの再現可能なカスタマイズを可能にするツールです。上記で説明した拡張・取り込みの原則は、ICON にも当てはまりますが、そこには 1 つの大きな違いがあります。それは、ICON では、「バンドル」として知られる概念によってイメージをモジュール式でカスタマイズできることです。これは、イメージのカスタマイズが本質的に ICON で文書化されて再現可能になることを意味します。

ICON でのバンドルは、ソフトウェアとそのソフトウェアのインストールや構成に必要な構成スクリプトを表し、ベースとなるハイパーバイザー・イメージ上で実行されます。構成スクリプトは、イメージ・アクティベーションの一環として実行されるため、その動作環境となっているクラウドのコンテキストを理解することができます (例えば、VM のホスト名を動的に選択できるなど)。ICON では、1 つのイメージに複数のバンドルを追加できるだけでなく、さまざまなイメージでバンドルを再利用することができます。したがって、例えば「製品 X」のバンドルを使用して、Red Hat または SuSE イメージをカスタマイズすることも可能です。

同様に、新しく登場したベース・イメージのバージョンをカスタマイズしなければならない場合には、新しいベース・イメージ上で、既存のバンドルを自動的かつ再現可能な方法で再度実行することができるため、仮想イメージのカスタマイズを保守する負担が軽減されます。

事前の作業が大幅に増えるとは言え、複数のオペレーティング・システムをサポートしなければならない場合や、イメージのカスタマイズの再現が懸念事項である場合、さらにはイメージが頻繁にアップグレードされる場合には、ICON のほうが IBM PureApplication System の基本的な拡張・取り込みの手法よりも推奨されます。

表 1. 各タスクに最適な手段
ツール最適な手段
スクリプト・パッケージフットプリントが小さい製品のインストール
人間の介入を必要としないサイレント・インストールが可能な製品
インストール後のカスタマイズ・ステップ
順序付けられたトポロジーのオーケストレーション
拡張・取り込みサイレント・インストールが不可能な、GUI によるインストール・プロセス
フットプリントが大きい製品のインストール
大規模なトポロジーの迅速なデプロイメント
ICONカスタマイズして IBM PureApplication System にインポートできる仮想イメージの効率的な作成
IBM 製ではない複雑な製品のインストール

反復型開発およびテスト

最後に、仮想システム・パターンの開発およびテストに関する全般的な指針について検討します。この指針は、ほとんどの IT 開発作業で功を奏します。

仮想システム・パターンの開発には、一度に仮想システム・パターンに含まれるあらゆるコンポーネントの起動および構成を自動化しようとする「大胆な選択」による手法で臨みがちですが、この手法にはリスクが伴います。新しい環境でアプリケーションを起動する際の予期せぬ問題を発見するのが遅れる可能性があるためです。

これは特に、仮想システム・パターンの手法を用いて製品を新しいバージョンや別のバージョンにアップグレードする場合に当てはまります。例えば、製品の異なるバージョンでアプリケーションを機能させるにはアプリケーションに何らかの調整が必要であることが判明したり、サード・パーティーのコンポーネントがハイパーバイザー・イメージに含まれる特定のバージョンのオペレーティング・システムでは正常に機能しないことが判明したりする可能性があります。

このような問題が後から判明することがないようにする最善の方法は、仮想システム・パターンの開発に、反復型の手法を採用することです。それには、以下のように、スクリプト・パッケージで自動化しようとしているすべてのタスクを事前に手作業で実行してみてください。

  • スクリプト・パッケージを使わずに、トポロジー内のすべての VM をクラウドにデプロイします。
  • すでにスクリプトを使って VM での構成タスクを行っている場合は、これらのスクリプトを手作業で実行します。それには、スクリプトを直接 VM にアップロードして、そのスクリプトを呼び出すという作業を自らの手で行います。スクリプトがまだない場合は、(GUI またはコマンド・ラインを使用して) すべてのタスクを手作業で行い、元の仮想システム・パターンのオーケストレーション・ステップでの作業と異なる部分をドキュメントに残します。
  • すべての VM を構成してから、自らの手でアプリケーションを起動し、その環境で基本的なテストを実行することでアプリケーションを検証します。
  • その環境でアプリケーションが機能することを検証した後、手作業で行ったすべてのステップを自動化するスクリプトの作成に取り掛かることができます。
  • 既存のスクリプトがある場合は、それらのスクリプトをスクリプト・パッケージに追加するだけで、作業は完了です。一方、既存のスクリプトがない場合には、まず、手作業で構成を行った VM 上でスクリプトの反復型開発を行います。
    • これに加え、スクリプト・パッケージの反復型テスト手法もあります。スクリプト・パッケージは、(VM の起動時またはシャットダウン時に) 自動的に実行されるように指定することも、ワークロード・デプロイメント GUI から手作業で実行することもできます。
    • スクリプト・パッケージを GUI から手作業で実行する利点は、毎回起動するごとに、スクリプト・パッケージに更新を取り込めることです。つまり、スクリプトを変更するたびに仮想システム・パターン全体を再デプロイすることなく、スクリプト・パッケージの反復型テストを行うことができます。

まとめ

この記事が、developerWorks および IBM PureApplication System インフォメーション・センターで提供されている情報と併せて、皆さんが独自の仮想システム・パターンの開発を順調にスタートさせる手助けとなることを願っています。

謝辞

支援および指導してくださった、Kai Young 氏、Catherine C. Diep 氏、Shaun Murakami 氏、Jason Anderson 氏、および Animesh Singh 氏に感謝の意を表します。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, WebSphere, Tivoli (service management)
ArticleID=816675
ArticleTitle=仮想システム・パターンを設計する
publish-date=05242012