Workload Deployer を使用した仮想アプリケーションの容易な自動化

パターン手法によるクラウド・アプリケーションの構築

仮想アプリケーションとは、エンタープライズ・ミドルウェア・コンポーネントにデプロイ可能な業界標準の成果物と、デプロイメント後のアプリケーションのランタイム動作を制御する一連のポリシーからなる、お客様向けに設計されたエンティティーです。この記事では、パターンを使用した作成プロセスの自動化を含め、仮想アプリケーション構築の背後にある概念を明らかにし、IBM Workload Deployer バージョン 3.0 を使用する実例を紹介します。

Brian Stelzer, Staff Software Engineer, IBM

Author photoBrian Stelzer は、IBM Workload Deployer チームのソフトウェア・エンジニア兼チーム・リーダーです。現在は、IBM Workload Deployer、WebSphere Application Server、および VMware ベースの技術を重点としたクラウド環境のトレーニングおよびアーキテクチャー・ソリューションを提供する役割を果たしています。以前は、WebSphere Application Server および WebSphere Application Server Community Edition を対象としたマイグレーション・ソリューションを設計していました。



Davanum Srinivas, Senior Software Engineer, IBM

Davanum SrinivasDavanum Srinivas は、IBM Workload Deployer チームのソフトウェア・エンジニアです。現在は、IBM Workload Deployer のストレージの側面に取り組むチームを率いています。以前は IBM Workload Deployer チームのリリース・アーキテクトの役割を担当し、WebSphere Web Services 開発に携わっていました。



Amit Acharya, Advisory Software Engineer, IBM

Amit AcharyaAmit Acharya は、IBM Cloud Initiatives Development 組織に在籍する顧問ソフトウェア・エンジニアです。現在、プライベート・クラウド空間の製品の戦略的品質計画および実行を主導している彼は、これまで Platform as a Service ベータ・プログラムの実行に尽力してきました。彼は、顧客を中心としたエンタープライズ・アプリケーション開発およびミドルウェア・ソリューションで豊富な経験を積んでいます。サービス指向アーキテクチャー分野の IBM Redbooks の著者でもあり、IBM Patent Portfolio に積極的に貢献してきました。また、Purdue University で電気工学およびコンピューター・エンジニアリングの修士号を取得しました。



2011年 9月 02日

仮想アプリケーションとは、(エンタープライズ・ミドルウェア・コンポーネントにデプロイ可能な) 業界標準の成果物と、デプロイメント後のアプリケーションのランタイム動作を制御する一連のポリシーからなる、お客様向けに設計されたエンティティーです。

IBM Workload Deployer 3.0 (従来の WebSphere CloudBurst) の主な特長は、お客様がエンタープライズ・アプリケーションの論理ビューに専念できるように、このアプライアンスが、デプロイする必要のあるミドルウェア・コンポーネントとその構成方法を自動的に判断することです。

この記事では、仮想アプリケーション・パターンを構築する方法を具体的に説明します。つまり、Workload Deployer の Virtual Application Builder 機能を使用できるように、エンタープライズ・アプリケーションの要件を判断し、これらの要件を定義する方法を説明します。

タスクのシナリオ: 仮想アプリケーション・パターンの構築

例えば、組織に稼働中のアプリケーションが多数あり、その数はさらに増える予定だとします。IT 部門の通常のプロセスでは、アプリケーションごとにハードウェア要件とソフトウェア要件を判断し、これらの要件に関する申請書を提出します。その後は、ハードウェアとソフトウェアのセットアップ、インストール、構成という時間のかかる面倒なプロセスが待っています。このプロセスが終わると、次は、モニターおよびフェイルオーバーのセットアップをし、ログの収集およびモニター方法の設定に移ります。そして最後に、次回の作業が楽になるようにアプリケーションごとにカスタム・スクリプトを作成したとすると、最終的にはハードウェア、ソフトウェア、アプリケーション、スクリプトなどが、かなりの数に膨れ上がってしまうことでしょう。

アプリケーションの要求を標準化して、稼働中のアプリケーションの数だけでなく、開発中、テスト中のアプリケーションの急増にも十分対応できるだけの余裕を持てるとしたら、皆さんはその話に乗りますか?そこで登場するのが、Workload Deployer です。例えば、標準的なアプリケーションで、一部のコードが J2EE アプリケーション・サーバーにデプロイされていて、一部のデータがリレーショナル・データベースに保管されているとします。このアプリケーションのロギング、モニター、フェイルオーバーなどを素早く簡単にセットアップできる方法があるとしたら実に重宝するはずですが、それがまさに、Workload Deployer が WebApp パターンで提示している方法なのです。Workload Deployer をデータ・センターにデプロイすれば、アプリケーションのデプロイメント、モニターのセットアップ、スケーリング、そしてロギングを標準化された方法で素早く行えるようになります。

WebApp パターンに基づく仮想アプリケーションには、一般に以下の成果物があります。

  • アプリケーション・サーバーにデプロイする J2EE EAR (Enterprise Archive) または J2EE WAR (Web Application Archive)
  • データベースを初期化するためのデータベース・スキーマ/テーブル/行の作成スクリプト
  • LDIF (LDAP Data Interchange Format) ファイルの形をとったユーザーおよびグループのリスト

Workload Deployer を使用することで、仮想アプリケーションの設計、成果物のアップロード、そしてロギング、モニター、スケーリングなどに関するポリシーの指定といった作業を素早く行って、仮想アプリケーションをプライベート・クラウドにデプロイすることができます。


仮想アプリケーションを素早く作成する方法

あるいは、IBM Workload Deployer 3.0 に組み込まれた Virtual Application Builder を使って、仮想アプリケーションを作成することができます。

例えば、新しい仮想アプリケーションを作成し、「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントと「Database (データベース)」コンポーネントをドラッグ・アンド・ドロップして、この 2 つのコンポーネントを関連付けます。そして、コード成果物と、そのコードが要求するテーブルを記述するデータベース・スキーマとが含まれる JEE ベースの EAR (Enterprise Archive) または WAR (Web Archive) をアップロードすれば、IBM Workload Deployer はこのアプリケーションを、WebApp パターンを使って最適化した形で (したがって、「仮想アプリケーション」という用語が使われています) デプロイできるものとして認識します。

以前の WebSphere Cloudburst による仮想システムの概念との主な違いは、実行中のシステムを構成するためにハイパーバイザー上で最終的に起動することになる仮想マシンの数を、ユーザーが決定する必要も、知る必要もないという点です。この役目を Workload Deployer に任せれば、Workload Deployer がコンポーネントや、コンポーネント間のリンク、そして関連するポリシーを調べ、仮想マシンの数、そして何をどの仮想マシンで実行するかに関して最適な判断を下します。

仮想システムでは、必要なミドルウェア・コンポーネントとその数を決めなければなりません。その心配は、仮想アプリケーションでは不要です。アプリケーションを設計するときに、例えばそのアプリケーションのスケーラビリティーの側面を制御するポリシーを指定するだけでよいのです。


IWD での仮想アプリケーション・パターンの構築

「仮想アプリケーション・パターンの構築」とは何を意味するのかと言うと、それは単純に、エンタープライズ・アプリケーションの要件を評価し、評価した要件を IBM Workload Deployer に定義するというだけです。このプロセスで難しい部分はエンタープライズ・アプリケーションの要件を理解することですが、いったん理解してしまえば、Virtual Application Builder ツールで数回のドラッグ・アンド・ドロップ操作を行うだけで、Workload Deployer に要件を定義することができます。

このセクションでは Virtual Application Builder ツールについて詳しく探り、以下のタスクを実行する方法を説明します。

  • 仮想アプリケーション・パターンの構築
  • コンポーネントの構成
  • コンポーネント間のリンクの構成

Virtual Application Builder ツールの基礎知識

Virtual Application Builder ツールとは、仮想アプリケーションを画面上でグラフィックを利用して構築できるように統合されているグラフィカル・ツールです。このツールは以下の 3 つの主要なセクションで構成されており、この 3 つのセクションが一体となって機能し、グラフィックを利用して仮想アプリケーションを作り上げます。

  • アセット (パレット): 仮想アプリケーションを構築するために使用できるすべてのコンポーネントが含まれています。これらのコンポーネントは論理的なグループに分類されています (例えば、「Database (データベース)」コンポーネント・グループには、すべてのデータベース・コンポーネントが含まれます)。
  • キャンバス: ここで、グラフィックを利用して仮想アプリケーションを構築していきます。
  • プロパティー・シート: コンポーネントごとにプロパティー・シートがあります。プロパティー・シートには、特定のコンポーネント、リンク、またはポリシーに対してユーザーが構成できるプロパティーが含まれています。

図 1 に、Virtual Application Builder ツールのユーザー・インターフェースを示します。

図 1. Virtual Application Builder ツールのインターフェース
Virtual Application Builder ツールのインターフェース

ここからは、仮想アプリケーション・パターンを構築する方法を説明します。

仮想アプリケーション・パターンを構築する

Virtual Application Builder ツールの基礎知識を学んだところで、今度は仮想アプリケーション・パターンの構築に取り掛かります。けれどもその前に、仮想アプリケーションとは、さまざまなタイプのワークロード・パターンを構築するために使用する汎用フレームワークであることを理解してください。この記事で使用するサンプル仮想アプリケーション・パターンには、以下の要件があります。

  • エンタープライズ・アプリケーションをホストするアプリケーション・サーバーへの依存関係は 1 つであること
  • データを永続化するデータベースへの依存関係は 1 つであること
  • 認証用のユーザー・レジストリーへの依存関係は 1 つであること

仮想アプリケーション・パターンを構築するプロセスで最初のステップとなるのは、「Pattern (パターン)」 > 「Virtual Applications (仮想アプリケーション)」の順に選択して、「Virtual Application Pattern (仮想アプリケーション・パターン)」パネルにナビゲートすることです。このビューには、ユーザーに表示が許可されている仮想アプリケーション・パターンがすべてリストアップされます。緑色のプラス・アイコンをクリックすると、仮想アプリケーションの作成パネルが表示されます。このパネルで、仮想アプリケーションを一から作成することも、既存のテンプレートを基に作成することもできます。「Blank application (ブランク・アプリケーション)」を選択して、「Start Building (構築の開始)」をクリックすると、Virtual Application Builder ツールが表示されます (図 2 を参照)。

図 2. 仮想アプリケーションの作成パネル
仮想アプリケーションの作成パネル

サンプル・エンタープライズ・アプリケーションにはミドルウェア要件として、アプリケーション・サーバー、データベース、ユーザー・レジストリーの 3 つが必要です。この 3 つの要件を満たすには、それぞれのコンポーネントをパレットからキャンバスにドラッグ・アンド・ドロップします (図 3 を参照)。

図 3. ドラッグ・アンド・ドロップ操作による構築
ドラッグ・アンド・ドロップ操作による構築
  • アプリケーション・サーバー要件を満たすために使用するのは、「Application Components (アプリケーション・コンポーネント)」サブセクションに見つかる「Enterprise Application (エンタープライズ・アプリケーション)」(WebSphere Application Server) コンポーネントです。
  • データベース要件を満たすために使用するのは、「Database Components (データベース・コンポーネント)」サブセクションに見つかる「Database (データベーベース)」(DB2) コンポーネントです。
  • ユーザー・レジストリー要件を満たすために使用するのは、「User Registry Components (ユーザー・レジストリー・コンポーネント)」サブセクションに見つかる「User Registry (ユーザー・レジストリー)」(Tivoli Directory Server) コンポーネントです。

3 つすべての従属コンポーネントをキャンバスに配置したら、次のステップに進んで、コンポーネント間のリンクを設定します。リンクには多数の役割がありますが、そのうち最も重要なのは以下の役割です。

  • 仮想マシンのポートを開いて、VM との間のトラフィックを許可します。すべてのポートは、リンクを使って具体的にオープンしない限り、ロックされています。
  • 追加プロパティーを定義します。

このサンプル・アプリケーションの場合、データベースおよびユーザー・レジストリーと通信することが要件となっていますが、ユーザー・レジストリーとデータベースとの間の通信は要件とはなっていません。リンクを設定するには、ソース・コンポーネントのエッジにある青色のボールをマウスでクリックした状態のまま、ターゲット・コンポーネントまでリンクをドラッグします。図 4 に、このシナリオ用に定義した 2 つのリンクを示します。

図 4. コンポーネント間のリンクの設定
コンポーネント間のリンクの設定

この時点で、仮想アプリケーションの構造が確立されたことになります。次のステップでは、デプロイメントの前に、それぞれのコンポーネントとリンクのプロパティーを構成します。コンポーネントおよびリンクごとに、ユーザーが構成できる固有のプロパティー (オプションおよび必須プロパティーの両方) のセットがあります。

何を最初に構成して、何を最後に構成するかに関して厳格に決められたルールはありませんが、「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントを最初に構成することを強くお勧めします。その理由は、リンクのプロパティーを構成するときに明らかになります。

コンポーネントを構成する

  1. エンタープライズ・アプリケーションをアップロードして、「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントを構成します (図 5 を参照)。
    図 5. 「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントのプロパティーの構成
    「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントのプロパティーの構成
  2. データベースの名前とサイズを指定して、「Database (データベース)」コンポーネントを構成します。アプリケーションでデータベースに事前にデータが取り込まれている必要がある場合には、スキーマ・ファイルもアップロードしてください。指摘しておく価値のある重要な情報として、このデータベースのライフサイクルは、このデータベースが属している仮想アプリケーションのライフサイクルと同じです。仮想アプリケーションが終了すると、データベース (およびそのすべての状態情報) も終了します。
  3. 「User Registry (ユーザー・レジストリー)」コンポーネントを構成するには、LDIF ファイルをアップロードして、ユーザーおよびグループ・フィルターを指定します。

リンクを構成する

各リンクが表すのは、通信パス、つまりコンポーネント間の関連付けです。コンポーネントの場合と同じく、リンクにもそれぞれに固有のプロパティーがあります。

  1. 「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントと「Database (データベース)」コンポーネントとの間を結ぶデータベース・リンクを構成します。リンクをクリックすると、リンクのプロパティーが表示されます。このリンクは、通信チャネルを開くだけでなく、エンタープライズ・アプリケーションのデータソース JNDI 名をマッピングする手段にもなります。図 6 に、その一例を示します。
    図 6. 「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントと「Database (データベース)」コンポーネントとの間のリンクの構成
    「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントと「Database (データベース)」コンポーネントとの間のリンクの構成

    デプロイメント時には、ここで指定した JNDI 名が WebSphere Application Server によって作成される JNDI 名にリンクされて「Database (データベース)」コンポーネントがサポートされます。

  2. 「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントと「User Registry (ユーザー・レジストリー)」コンポーネントとの間のリンクを構成します。このリンクを使用して、エンタープライズ・アプリケーションに定義されているロールを、「User Registry (ユーザー・レジストリー)」コンポーネントに定義されている具体的なユーザーおよびグループにマッピングすることができます。図 7 に、このマッピングを示します。
    図 7. 「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントと「User Registry (ユーザー・レジストリー)」コンポーネントとの間のリンクの構成
    「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントと「User Registry (ユーザー・レジストリー)」コンポーネントとの間のリンクの構成

    お気付きでない場合に備えて言っておきますが、「Database (データベース)」コンポーネントの Resource reference of Data Source (データソースのリソース参照) プロパティーと、「User Registry (ユーザー・レジストリー)」コンポーネントの Role Name (ロール名) プロパティーには、エンタープライズ・アプリケーションから得られたオプションがすでに設定されています。ユーザーがリンクを仮想アプリケーションに追加すると、Workload Deployer は該当する情報についてエンタープライズ・アプリケーションのデプロイメント記述子を調べます。つまり、JNDI 参照の場合には web.xml を調べ、セキュリティー・ロールについては application.xml を調べます。図 8 に一例を示します。

    図 8. application.xml および web.xml の確認箇所
    application.xml および web.xml の確認箇所
  3. 仮想アプリケーションを保存します (図 9 を参照)。
    図 9. 仮想アプリケーションの保存
    仮想アプリケーションの保存

これで、このセクションの手順は完了です。この後は、仮想アプリケーションをデプロイする方法、そしてモニターする方法について説明します。


アプリケーションのデプロイメント

ここからが、面白いところです。アプリケーションを Virtual Application Builder でモデル化できると、このサンプル・アプリケーション vAppArticle をデプロイすることができますが、その作業は極めて簡単です!以下の手順に従って、仮想アプリケーションをデプロイしてください。

  1. 「Patterns (パターン)」 > 「Virtual Applications (仮想アプリケーション)」の順にクリックし、「vAppArticle」をクリックします。図 10 に例を示します。
    図 10. 仮想アプリケーションを見つける
    仮想アプリケーションを見つける
  2. デプロイメントを開始するには、パネルの右側にある「Deploy the virtual application into the cloud (仮想アプリケーションをクラウドにデプロイします)」をクリックします (図 11 を参照)。
    図 11. 仮想アプリケーションのデプロイメント
    仮想アプリケーションのデプロイメント図を拡大するにはここをクリックしてください。
  3. Deploy the virtual application into the cloud (仮想アプリケーションをクラウドにデプロイします)」をクリックすると、クラウド・グループの選択肢が表示されます (図 12 を参照)。
    図 12. 仮想アプリケーションのデプロイメント・ターゲット
    仮想アプリケーションのデプロイメント・ターゲット

    Workload Deployer で仮想アプリケーションがデプロイメント・ターゲットとしてサポートするのはクラウド・グループだけです。環境プロファイルはデプロイメント・ターゲットとしてサポートされません。

    図 12 に示すダイアログ・ボックスには、デプロイされている VM に対するセキュア SSH アクセスを構成するための「Advanced (拡張)」オプションもあります。セキュア SSH アクセスを構成するには、独自の公開鍵をアップロードすることも、Workload Deployer に公開鍵と秘密鍵のペアを生成させることもできます。デプロイされている VM は、ユーザー名とパスワードによるアクセスを許可しません。アクセスするには、ユーザー名と秘密鍵が必要です。したがって、セキュア SSH アクセスを構成しなければ、VM に直接アクセスすることができなくなります。SSH 鍵は、アプリケーションをデプロイした後に、仮想アプリケーション・コンソールから追加または変更することができます。「OK」をクリックして、デプロイメントを開始してください。

  4. Workload Deployer が仮想アプリケーションのデプロイメントを開始すると、短時間のうちに (その時間はネットワーク構成に依存します)、仮想アプリケーションがデプロイされて使用できる状態になります。

    Workload Deployer はアプリケーションのデプロイメントをインフラストラクチャー固有のアクションに変換し、必要な VM のデプロイメントを開始して、ミドルウェアおよびアプリケーションを構成します。

  5. デプロイメント・ステータスを確認するには、「Instances (インスタンス)」 > 「Virtual Applications (仮想アプリケーション)」の順にクリックし、「vAppArticle」アプリケーションをクリックします (図 13 を参照)。
    図 13. 仮想アプリケーション・インスタンス
    仮想アプリケーション・インスタンス

    仮想アプリケーションのデプロイメントは、インフラストラクチャー固有の詳細も、ミドルウェア固有の詳細も隠します。例えば、ユーザーが VM の数を指定したり、WebSphere Application Server のバージョンを指定したりする必要はありません。したがって、アプリケーション開発者はインフラストラクチャーおよびミドルウェアの詳細を IBM Workload Deployer に任せて、アプリケーションの開発に専念できるというわけです。

    図 14 に、仮想アプリケーションのデプロイメント・ステータスを示します。

    図 14. 仮想アプリケーションのデプロイメント・ステータス
    仮想アプリケーションのデプロイメント・ステータス図を拡大するにはここをクリックしてください。

    仮想アプリケーションがデプロイされると、「VM Status (VM ステータス)」が「Launching (起動中)」から「Running (実行中)」に変わります。VM が完全にインスタンス化された時点で、VM 内部に常駐する Workload Deployer 固有のエージェントが、VM をこのアプリケーション・デプロイメントで担うロールに応じて構成するためのアクションを開始します。

    VM のロールは、その特定の VM が持つことになるミドルウェアの特性を示します。VM のロールとしては、例えば WebSphere Application Server、DB2、または TDS が考えられます。IBM Workload Deployer エージェントが特定のロールに応じて VM を構成すると、その VM の「Role Status (ロール・ステータス)」が変わり、ロールが完全に構成された時点でその「Role Status (ロール・ステータス)」の色が緑色になります。すべてのロールが正常に構成されて緑色のステータスに変わった時点で、仮想アプリケーションにアクセス可能になります。

  6. デプロイメントが完了した仮想アプリケーションには、WAS VM の ENDPOINT ハイパーリンクをクリックすることによって直接アクセスすることができます。
    図 15. エンタープライズ・アプリケーションへのアクセス
    エンタープライズ・アプリケーションへのアクセス図を拡大するにはここをクリックしてください。

    データベース VM およびユーザー・レジストリー VM のエンドポイント URL は、そのミドルウェアにアクセスするための特定の情報を示します。例えば、データベースのエンドポイント URL には、DB2 クライアントを使用してデータベースにアクセスする際の接続情報が示されます。


アプリケーションのモニター

IBM Workload Deployer では、デプロイされた後の仮想アプリケーションを、仮想アプリケーション・コンソールからモニターおよび管理できるようになっています。さらに、この一元化されたダッシュボードからは、デプロイされた仮想アプリケーションで特定の操作を行ったり、OS 専用のログ、ミドルウェア専用のログ、そして Workload Deployer エージェント専用のログを表示したりすることもできます。

仮想アプリケーション・コンソールにアクセスするには、「Instances (インスタンス)」 > 「Virtual Applications (仮想アプリケーション)」の順にクリックしてから、「vAppArticle」をクリックします。右側のパネルで、「More details and advanced options (詳細と拡張情報)」アイコンをクリックすると (図 16 を参照)、仮想アプリケーション・コンソールが新しいブラウザー・ウィンドウに開きます。

図 16. 仮想アプリケーション・コンソールへのアクセス
仮想アプリケーション・コンソールへのアクセス

図を拡大するにはここをクリックしてください。

仮想アプリケーション・コンソールには、以下の 4 つのタブがあります。

  • Virtual Machine Monitoring (仮想マシン・モニター): このビューには、リアルタイムの仮想マシン統計情報がグラフ形式で表示されます。例えば、デプロイされているアプリケーションが大量の CPU サイクルを使用している場合、このビューから、その特定の VM の CPU 使用量が高いことが見て取れます。
  • Middleware Monitoring (ミドルウェア・モニター): このビューには、リアルタイムのミドルウェア固有のモニター統計情報がグラフ形式で表示されます。例えば、アプリケーション使用のピーク時に、アプリケーションに対するリクエスト数を追跡することができます。
  • Operation (操作): このビューでは、ターゲットとする VM で、ミドルウェア固有の操作を実行することができます。例えば、インストール済みアプリケーションを新しいバージョンで更新するのに、デプロイメント全体を終了することは避けたいとします。その場合、「Operation (操作)」タブで、アプリケーションを更新したり、その他の必要な操作を実行したりすることができます。
  • Logging (ロギング): このビューは、VM ごとの OS 専用のログ、ミドルウェア専用のログ、Workload Deployer エージェント専用のログを集めた、一元化されたユーザー・インターフェースです。あらゆるログを簡単に表示できるため、さまざまな VM のさまざまなサブシステムでの障害を一度にデバッグするのに役立ちます。

図 17 と図 18 に例として、「Operation (操作)」タブと「Logging (ロギング)」タブのスクリーン・キャプチャーを示します。

図 17. 仮想アプリケーション・ダッシュボードの「Operation (操作)」タブ
仮想アプリケーション・ダッシュボードの「Operation (操作)」タブ
図 18. 仮想アプリケーション・ダッシュボードの「Logging (ロギング)」タブ
仮想アプリケーション・ダッシュボードの「Logging (ロギング)」タブ

図を拡大するにはここをクリックしてください。


おまけ: 独自のデータベース・パターンの構成

すべての構成に当てはまるわけではありませんが、データベースがアプリケーションから完全に独立していて、固有のライフサイクルに従い、独特のスキルを持つまったく別のチームによって管理される場合もよくあります。Workload Deployer ではこの要件を認識し、データベースを別個のエンティティーとして作成、管理できるようになっています。したがって、仮想アプリケーションでは、独自のデータベースを作成する代わりに、この既存のデータベースに接続することができます。

このセクションでは、Workload Deployer のデータベース・パターン (vAppDB と名付けます) を構成します。また、「Existing Database (既存データベース)」コンポーネントを使用するように仮想アプリケーションを拡張することで、この独自のデータベースを利用できるようにします。この記事の焦点は、データベース・パターンを調べることではなく Web アプリケーション・パターンを詳しく調べることですが、これは、Workload Deployer の重要なサポート機能なので、この記事では基本的に、「サービスとしてのデータベース」モデルを可能にする方法を具体例を用いて説明します。

vAppDB データベース・パターンを構成してデプロイする

  1. 「Patterns (パターン)」 > 「Database Patterns (データベース・パターン)」の順にナビゲートして、緑色のプラス・アイコンをクリックします。この操作によって表示される「Database Pattern (データベース・パターン)」パネルで、データベースの名前とサイズを指定して、サポート・スキーマ・ファイルをアップロードすることができます (図 19 を参照)。
    図 19. データベース・パターンの作成パネル
    Database Pattern creation panel
  2. データベース・プロパティーの定義がすべて完了したら、「Save (保存)」をクリックします。その後、このデータベースを選択して「Deploy (デプロイ)」アイコンをクリックすることで、指定したデータベースがデプロイされます。ネットワークによっては、このプロセスに時間がかかる場合があります。データベースのデプロイメント・ステータスをモニターするには、「Instances (インスタンス)」 > 「Databases (データベース)」の順にナビゲートし、データベースを強調表示して、データベースの情報を表示します。デプロイメントが完了したら、ホスト、ポート、ユーザー、およびパスワード情報をメモに書き留めてください (図 20 を査証)。
    図 20. データベース・インスタンス情報 (ホストおよびポート)
    データベース・インスタンス情報 (ホストおよびポート)

    この情報は、「Existing Database (既存データベース)」コンポーネントを使って仮想アプリケーションを拡張するときに使用します。

「Existing Database (既存データベース)」コンポーネントを使用して拡張する

既存のミドルウェアや、組織内外のレガシー・エンタープライズ・システムに接続しなければならないことはよくあります。Workload Deployer には、このような場合に対する答えも用意されています。Workload Deployer はプライベート・クラウド外部のシステムにも柔軟にアクセスして引き続き利用できるように、既存のデータベース、ユーザー・レジストリー、CICS、IMS などへのアクセスを可能にするコンポーネントを用意しています。

このシナリオでは、仮想アプリケーションを「Existing Database (既存データベース)」コンポーネントで拡張することによって、この柔軟性を明らかにします。(例えば「Existing User Registry (既存ユーザー・レジストリー)」コンポーネントを選ばずに)「Existing Database (既存データベース)」コンポーネントを選んだのは、このコンポーネントがデータベース・パターンの機能を示しているというだけの理由です。また、何度も繰り返しておく価値があることとして、データベース・パターンの機能にはここで取り上げる以上のものがあります。これで少なくとも、そういう存在は知ってもらえたので、この特定の機能に興味を持った読者の方はさらに詳しく調べてください。

  1. Virtual Application Builder ツールで仮想アプリケーションを開きます。「Database (データベース)」コンポーネントを削除してから (このアクションは、コンポーネントに関連付けられたリンクも削除します)、「Existing Database (既存データベース)」(DB2) コンポーネントを追加し、リンクを再設定します (図 21 を参照)。
    図 21.「Database (データベース)」コンポーネントの削除とリストア
    「Database (データベース)」コンポーネントの削除とリストア
  2. 「Existing Database (既存データベース)」コンポーネントを構成します。vAppDB を作成してデプロイするステップで書き留めたホスト、ポート、ユーザー名、およびパスワード情報を使用して、このコンポーネントを構成します。
  3. 新しく作成したリンクにはプロパティーが構成されていないため、このリンクのプロパティー・シートを再構成します。図 22 に、その一例を示します。
    図 22. 「Existing Database (既存データベース)」のプロパティー・シート
    「Existing Database (既存データベース)」のプロパティー・シート

更新内容を保存すると、それだけではなく、別個のエンティティーとして管理されるデータベースのセットアップも完了したことになります。これで、仮想アプリケーションは「Database (データベース)」コンポーネントではなく、「Existing Database (既存データベース)」コンポーネントを使用するように拡張されました。


共有サービス (キャッシュおよびプロキシー)

共有サービスとは、1 つ以上の仮想アプリケーション・インスタンスによって共有されるサービスです。現在、共有サービスには以下の 2 つがあります。

  • サービスとしてのキャッシング
  • サービスとしてのプロキシー

共有サービスを構成して開始するのは、管理レベルのアクティビティーです。このアクティビティーを一度完了すれば、後はすべての仮想アプリケーション・インスタンスで使用することができます。ユーザーが特定のデプロイメントのキャッシング・サービスやプロキシー・サービスを開始し、管理することを心配する必要はありません。

キャッシング・サービスやプロキシー・サービスを共有することには、以下の 2 つの重要なメリットがあります。

  • リソースの効率的な使用。仮想アプリケーションのデプロイメントごとのプロキシーおよびキャッシングを使用する必要がなくなります。
  • フェイルオーバー・サポート。共有サービスは複数の VM を使ってデプロイされるため、1 つの VM が機能停止しても、その VM が再作成されるか再起動されるまで、他の VM がワークロードを引き継ぎます。

共有サービスを有効にする (管理者)

  1. 共有サービスを開始するには、管理レベルのユーザーとしてログインします。ログインしたら、「Cloud (クラウド)」 > 「Shared Services (共有サービス)」の順にクリックします。
    図 23. 共有サービスを有効にする
    共有サービスを有効にする図を拡大するにはここをクリックしてください。
  2. 「CachingService」と「PROXY」という2 つの共有サービスが表示されます。これらのサービスは事前に構成済みです。サービスごとのデプロイメント・アイコンをクリックしてください。
  3. 各サービスをデプロイするために必要な情報は、VM の数、そしてターゲット・クラウド・グループの 2 つだけです。「Deploy (デプロイ)」をクリックすると、その後すぐに、共有サービスが使用できる状態になります。例として、図 24 に実行中のキャッシング・サービスを示します。
    図 24. 共有キャッシング・サービスのデプロイメント
    共有キャッシング・サービスのデプロイメント図を拡大するにはここをクリックしてください。

Web アプリケーション・パターン共有サービスを有効にする (ユーザー)

キャッシングおよびプロキシーの共有サービスは、仮想アプリケーション全般で使用されるように設計されています。ここで具体的に取り上げるのは、Web Application パターンによって共有サービスを使用する方法の一例です。

Web Application パターンでは、キャッシング・サービスを使用して HTTP セッション情報を保管します。このパターンで使用するのはメモリー内パーシスタンスであるため、データベースには永続化されませんが、フェイルオーバー・サポートがキャッシング・サービスによって提供されていれば、この点が問題になることはありません。Web Application パターンがキャッシング・サービスを使用できるようにするには、まず「Scaling Policy (スケーリング・ポリシー)」を追加し、その上で「Enable session caching (セッション・キャッシュを使用可能に設定)」チェック・ボックスにチェック・マークを付けます。

Web Application パターンは、仮想アプリケーションにリクエストをルーティングするためにプロキシー・サービスを使用します。「Scaling Policy (スケーリング・ポリシー)」と「Routing Policy (ルーティング・ポリシー)」を 「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントに追加すれば、Web Application パターンがプロキシー・サービスを使用できるようになります。

基本的な機能のために行う作業は、これだけです。図 25 に、使用可能な状態にされた 2 つのサービスを示します。

図 25. Web Application パターンで使用可能にされた共有サービス
Web Application パターンで使用可能にされた共有サービス

次の (そして最後の) ステップは、これらの新しい設定で仮想アプリケーションをデプロイすることです。ここで唯一の違いとして気付くのは、アプリケーションに仮想ホスト名を使用してアクセスしていることですが、裏では、実はかなりのことが行われています。仮想ホスト名によるアプリケーションへのアクセスは、最初にプロキシー・サービスによってルーティングされます。さらに、HTTP セッション情報はVM にローカルに永続化されるのではなく、キャッシング・サービスに永続化されます。

記事の範囲ではありませんが、このシナリオの締めくくりとして指摘しておくべき点として、IP ロード・バランサーは、仮想ホストへの着信リクエストをプロキシー・サービス VM IP アドレスにルーティングするように構成する必要があります。


まとめ

仮想アプリケーションおよびデータベースを作成、デプロイ、管理するタスクは、クラウド・コンピューティングには欠かすことができません。Workload Deployer は、これらのタスクを極めて簡単にするターンキー・ソリューションとなります。

参考文献

学ぶために

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

議論するために

コメント

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, Information Management
ArticleID=754239
ArticleTitle=Workload Deployer を使用した仮想アプリケーションの容易な自動化
publish-date=09022011