目次


IBM Pattern Development Kit を使用して仮想アプリケーション・パターンを作成する

第 2 回 コンポーネント・リンク、スケーリング・ポリシー、およびインテント・ポリシーを作成する

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: IBM Pattern Development Kit を使用して仮想アプリケーション・パターンを作成する

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:IBM Pattern Development Kit を使用して仮想アプリケーション・パターンを作成する

このシリーズの続きに乞うご期待。

はじめに

第 1 回では、互いに接続されていない HTTPD コンポーネントと Tomcat コンポーネントを作成しました。けれども、さまざまなワークロードとインテントに動的に適応することができるクラスターを構築するには、HTTPD サーバーと Tomcat サーバーが連動しなければなりません。それを可能にするのが、仮想アプリケーション・パターンに組み込まれたリンクとポリシーです。

リンクは、コンポーネント間の接続を確立します。例えば、HTTPD コンポーネントと Tomcat コンポーネントの相互依存関係は、リンクによって提供されます。ポリシーは、仮想アプリケーション内のアプリケーション成果物のサービス品質レベルを表します。ポリシーは、アプリケーション・レベルでグローバルに適用することも、個々のコンポーネントに対してのみ適用することもできます。この記事では、HTTPD と Tomcat のリンク、スケーリング・ポリシー、インテント・ポリシーを 3 つの個別のプラグイン・プロジェクトに分けます。ポリシーをそれぞれに独立させると、他のコンポーネントをサポートするためにポリシーを拡張するのが柔軟かつ容易に行えるようになります。

HTTPD と Tomcat のリンク

このセクションでは、Tomcat コンポーネントから HTTPD コンポーネントへのリンクを作成する方法を説明します。このリンクにより、HTTPD コンポーネントが Tomcat コンポーネントに依存する形になります。

HTTPD と Tomcat のリンクの設計

HTTPD と Tomcat の間のリンクでは、Tomcat がワーカーとして HTTPD に登録されます。図 1 に、このトポロジーを示します。このトポロジーでは、Tomcat がアプリケーション・サーバーとなり、Tomcat にとって HTTPD は HTTP プロキシー兼ロード・バランサーとなります。HTTPD はユーザーから受信したリクエストを Tomcat に転送し、Tomcat から受信したレスポンスをユーザーに返します。

Tomcat サーバーを HTTPD サーバーに登録するには、インストールの完了後、Tomcat が HTTPD にパラメーターをエクスポートする必要があります。仮想アプリケーション・パターンでは、ロールの依存関係 (つまり、リンク) によってロール間でデータを送信し、特定のパラメーターに対するウォッチドッグ・スクリプトを作成することができます。Tomcat および HTTPD コンポーネントの場合、HTTPD のロールを Tomcat のロールに依存させる必要があります。こうすることで、Tomcat でのエクスポートされるパラメーターやステータスの変更が、Tomcat に依存する HTTPD のロールに渡されることになります。

図 1. リンクのターゲット・アーキテクチャー
リンクのターゲット・アーキテクチャー
リンクのターゲット・アーキテクチャー

リンク・プラグイン・プロジェクトの作成

以下の手順に従って、リンク・プラグイン・プロジェクトを作成します。

  1. Plug-in Development Kit を使用して、連載第 1 回で使用したワークスペースを開きます。
  2. plugin.com.ibm.samples.httpdtomcat」という名前の IBM Workload Plug-in プロジェクトを作成します。1 次パターン・タイプとして「patterntype.samples.apache version 1.0 (patterntype.samples.apache バージョン1.0)」を選択します。
  3. plugin フォルダー内にある config.json を開きます。
    1. 「Overview (概要)」タブの「Package (パッケージ)」セクションで、ロールの名前を「HTTPDTOMCAT」から「HTTPD_INSTALL」(plugin.com.ibm.samples.httpd プラグインで定義されているロール名と同じ名前) に変更し、このロールのスクリプト・ファイルをすべて削除します。
    2. HTTPD_INSTALL フォルダー内に、TOMCAT_INSTALL という名前 (plugin.com.ibm.samples.tomcat プラグインで定義されているロール名と同じ名前) のフォルダーを作成します。続いて、この TOMCAT_INSTALL フォルダー内に、changed.py という名前のスクリプト・ファイルを作成します。図 2 で、HTTPD_INSTALL にはロール・タグ (R) が付けられていて、TOMCAT_INSTALL には依存関係タグ (D) が付けられていることに注目してください。これは、HTTPD_INSTALL ロールが TOMCAT_INSTALL ロールからデータを受け取って、changed.py スクリプトを実行することを意味します。
      図 2. リンク・プラグイン・パッケージと、プロジェクト・エクスプローラーに表示されたリンク・プラグイン・パッケージの構造
      リンク・プラグイン・パッケージと、プロジェクト・エクスプローラーに表示されたリンク・プラグイン・パッケージの構造
      リンク・プラグイン・パッケージと、プロジェクト・エクスプローラーに表示されたリンク・プラグイン・パッケージの構造
    3. config.json」タブに切り替えて、パッケージの名前を HTTPDTOMCAT から HTTPD_TOMCAT に変更します。このパッケージが、コンポーネント・トランスフォーマーで使用されます。
    4. 「Application Model (アプリケーション・モデル)」タブに切り替えます。「link_httpd_tomcat」という ID を持つ新規リンクを追加し (図 3 を参照)、「Source (ソース)」ではプラグイン・コンポーネント名「samplesTomcat」を選択し、「Target (ターゲット)」ではプラグイン・コンポーネント名「samplesHttpd」を選択します。
      図 3. リンク・メタデータの詳細
      リンク・メタデータの詳細
      リンク・メタデータの詳細
  4. 「metadata.json」タブに切り替えて、すべての属性の sampleValue に値を追加します。これらのサンプル値は、PureApplication System の仮想アプリケーション・ビルダーにデフォルト値として表示されます。
  5. 国際化に対応させるために、messages.json 内にストリングを作成して、patterntype.json を更新します。詳細については、連載第 1 回を参照してください。
    リスト 1. リンクの messages.json
    {
    	LINK_TOMCAT_HTTPD_LABEL:Link for httpd and tomcat,
    	LINK_TOMCAT_HTTPD_DESC:Link for httpd and tomcat,
    	LINK_TOMCAT_IP_LABEL:Tomcat IP  variable name,
    	LINK_TOMCAT_IP_DESC:Tomcat IP  variable name,	
    	LINK_TOMCAT_PORT_LABEL:Tomcat Port  variable name,
    	LINK_TOMCAT_PORT_DESC:Tomcat Port  variable name,
    }
  6. 図 4 に示す OSGI サービス・コンポーネントを作成するために、メニューを「File (ファイル)」 > 「New (新規)」 > 「Other… (その他…)」 > 「IBM Workload Plug-in Development」 > 「OSGI Service Component (OSGI サービス・コンポーネント)」の順に選択します。コンポーネント名として「link_httpd_tomcat」と入力します。「Service type (サービス・タイプ)」では、「Topology Provider (java based) (トポロジー・プロバイダー (Java ベース)」を選択します。「Implementation class (実装クラス)」には、「com.ibm.samples.transform.httpdtomcat.HttpdTomcatTransformer」と入力します。
    図 4. OSGI コンポーネントのリンク
    OSGI コンポーネントのリンク
    OSGI コンポーネントのリンク

リンク・プラグインの実装

HttpdTomcatTransformer を実装する

HttpdTomcatTransformercom.ibm.maestro.model.transform.TopologyProvider クラスを継承して、次の 2 つのメソッドをオーバーライドします。

  • transformComponent: このメソッドは、アプリケーション・モデルのコンポーネントをトポロジー文書のオブジェクトに変換します。このメソッドが呼び出されるのは、コンポーネントが初期化されるときです。
  • transformLink: このメソッドは、ソース・コンポーネントとターゲット・コンポーネントに関連付けられたトポロジー文書の内容を更新することによって、アプリケーション・モデルのリンクを変換します。コンポーネントが変換されてから、リンクが変換されます。

このリンク・プラグイン・プロジェクトでは、metadata.json に定義されるリンクは 1 つだけなので、transformLink メソッドが有効になります。このメソッドに含まれる要素は以下のとおりです

  • sourceFragment は、トポロジー文書の中でソース・コンポーネントと関連付けられた部分です。
  • targetFragment は、トポロジー文書のターゲット・コンポーネントと関連付けられた部分です。
  • applicationUrl は、(PureApplication System Storehouse 内の) アプリケーション成果物のルート URL です。
  • applicationLink は、アプリケーション・モデルに含まれるリンク・オブジェクトです。

このメソッドを実装するには、以下の手順に従います。

  1. sourceFragment (HTTPD ロール・フラグメント) と targetFragment (Tomcat ロール・フラグメント) を参照できるようにプリント・アウトしておきます。
  2. HTTPD_TOMCAT パッケージを Httpd vm-template に追加します。
  3. JSON の VM テンプレート部分に含まれる TOMCAT_INSTALL 定義に HTTPD_INSTALL 依存関係を追加します。こうすることにより、Python スクリプト HTTPD_INSTALL/TOMCAT_INSTALL/changed.py が TOMCAT_INSTALL ロールから変更 (追加、削除、更新) を受信できるようになります。
  4. HTTPD_INSTALL にパラメーターを追加します。これらのパラメーターは、後で Python スクリプトで使用するためのものです。

changed.py を実装する

HTTPD_INSTALL/TOMCAT_INSTALL/changed.py スクリプトは、HTTPD コンポーネントの HTTPD_INSTALL ロールで実行されます。HTTPD_INSTALL ロールで start.py が実行された後は、TOMCAT_INSTALL ロールで変更が発生するたびに、changed.py スクリプトが実行されます。changed.py を実行するための前提条件には、以下の 2 つがあります。

  1. 現在のロールで start.py の実行が完了していること。
  2. 従属ロールからデータまたはステータスの変更が送信されること。

もう 1 つ注意する点として、changed.py は、1 回のデプロイメント・プロセスで何度も実行される場合があります (図 5 を参照)。

図 5. スクリプト実行フローの例
スクリプト実行フローの例
スクリプト実行フローの例

すべてのライフサイクル・スクリプトで maestro パラメーター (リスト 2 を参照) を出力しておくと、スクリプトをデバッグするのに役立つことがあります。インスタンスがデプロイされるときに、PureApplication System は、各ライフサイクル・スクリプトの maestro パラメーターの値をログに記録します。ライフサイクル・スクリプトによって、使用されるパラメーターが異なることに注意してください。

リスト 2. changed.py の内部パラメーター
logger.debug('maestro.node:'+str(maestro.node))
logger.debug('maestro.role:'+str(maestro.role))
logger.debug('maestro.parms:'+str(maestro.parms))
logger.debug('maestro.xparms:'+str(maestro.xparms))
logger.debug('maestro.operation:'+str(maestro.operation))
logger.debug('maestro.updated:'+str(maestro.updated))
logger.debug('maestro.added:'+str(maestro.added))
logger.debug('maestro.removed:'+str(maestro.removed))
logger.debug('maestro.depends:'+str(maestro.deps))

changed.py スクリプトは何度も呼び出される可能性があるため、呼び出される都度、従属ロール・インスタンスの変更のタイプ (追加、削除、更新) に応じて適切なアクションを取らなければなりません。呼び出しプロセスには、特殊なものが 1 つあります。それは、再起動操作です (図 6)。

図 6. 再起動操作のスクリプト実行フロー
再起動操作のスクリプト実行フロー
再起動操作のスクリプト実行フロー

それぞれの呼び出しを区別するために、changed.py には、現在の仮想マシンの中で従属ロールからエクスポートされたデータをチェックするスクリプトを組み込む必要があります。ロール・インスタンスに変更があった場合、例えば、表 1 では以下のようになります。

  • ロール・インスタンスが新たに追加された場合、maestro.added には、そのロールのフルネームが追加されます。
  • 追加されたロール・インスタンスに依存関係がある場合、maestro.deps には、その従属ロールからエクスポートされたパラメーターの記載が、そのロールのフルネームの下にあります。
  • ロール・インスタンスが新たに削除された場合、maestro.removed には、そのロールのフルネームが記載されます。
  • 削除されたロール・インスタンスに依存関係がある場合、maestro.deps には、その削除されたロール・インスタンスに関連する記載はありません。
  • ロール・インスタンスが新たに更新された場合、maestro.updated には、そのロールのフルネームが追加されます。また、更新されたロール・インスタンスに依存関係がある場合、maestro.deps には、その従属ロールからエクスポートされたパラメーターの記載があります。
表 1. ロール・インスタンスの変更に関連する情報
maestro.added
(フルネーム)
maestro.removed
(フルネーム)
maestro.updated
(フルネーム)
maestro.added
(エクスポートされたパラメーター)
新たに追加されたロール・インスタンス有り有り
新たに削除されたロール・インスタンス有り
新たに更新されたロール・インスタンス有り有り

一般に、従属ロール・インスタンスが変更されるたびに、changed.py が一回実行されます。ときには、同じロールを持つ異なる複数のインスタンスで同じ変更が同時に行われることがありますが、その場合には、これらのインスタンス名がまとめられて、changed.py が一回だけ呼び出されます。このことから、maestro.addedmaestro.removed、および maestro.updated には、複数のインスタンス名が記載されることがあります (リスト 3 およびリスト 4 を参照)。

リスト 3. maestro.added の内容
[u'Tomcat_Server-tomcat.11372783844723.TOMCAT_INSTALL',
u'Tomcat_Server-tomcat.21372783844724.TOMCAT_INSTALL']
リスト 4. maestro.deps の内容
{u'Tomcat_Server-tomcat.11372783844723.TOMCAT_INSTALL':
	{u'TOMCAT_READY':
		{u'TOMCAT_HOME': u'/opt/apache/tomcat7',
		 u'TOMCAT_PORT': u'8080',
		 u'TOMCAT_IP': u'172.20.107.11',
		 u'COMPONENT_NAME': u'TomcatServer'}},
 u'Tomcat_Server-tomcat.21372783844724.TOMCAT_INSTALL':
	{u'TOMCAT_READY':
		{u'TOMCAT_HOME': u'/opt/apache/tomcat7',
		 u'TOMCAT_PORT': u'8080',
		 u'TOMCAT_IP': u'172.20.107.4',
		 u'COMPONENT_NAME': u'TomcatServer'}}}

例えば、changed.py スクリプトでは以下のチェックが行われます。

  • インストール完了フラグがセットされている場合、それは再起動操作を意味するため、何も実行する必要はありません。
  • インストール完了フラグがセットされていない場合は、変更されたノード名がロール依存関係情報 (maestro.deps) に含まれているかどうかをチェックします。変更されたノード名が含まれている場合、これが追加操作であるかどうか (ch_infomaestro.updatedmaestro.added のどちらから取得されているか) をチェックします。追加操作である場合は、これが構成ファイルへ変更を加えるための初めての書き込みであれば (FLAG_FILE が存在しない場合) write_conf および export_flag 関数を呼び出し、そうでなければ chang_conf 関数を呼び出すことで、構成ファイルに新しい行を追加します。
  • 変更されたノード名がロール依存関係情報 (maestro.deps) に含まれていない場合、これが削除操作であるかどうか (ch_infomaestro.removed から取得されているか) をチェックします。削除操作である場合は、chang_conf 関数を呼び出して、構成ファイルから行を削除します。構成ファイルに対して操作を実行するたびに、HTTPD を再起動する (restart_httpd を呼び出す) 必要があることに注意してください。

リスト 5 に、HTTPD サーバーの httpd.config ファイルに追加しなければならない内容を記載します。この内容を追加することにより、Tomcat サーバー (この例では、IP アドレスは 192.168.0.4、ポートは 8080) を HTTPD サーバーに登録できるようになります。

リスト 5. httpd.conf ファイルの構成内容
ProxyPass /images !
ProxyPass /css !
ProxyPass /js !
ProxyPass / balancer://cluster/
<Proxy balancer://cluster/>
BalancerMember http://192.168.0.4:8080/ loadfactor=1
</Proxy>

Tomcat サーバーを HTTPD サーバーに登録するための完全なスクリプトは、この記事に付属のソース・プロジェクトに含まれています。この changed.py スクリプトは、スケーリング・ポリシーと使用インテント・ポリシーに必要な TOMCAT_INSTALL の追加と削除をサポートしています。

Tomcat へのスケーリング・ポリシーの追加

このセクションでは、Tomcat コンポーネントのスケーリング・ポリシーの作成方法を説明します。Tomcat は、あらゆるユーザー・リクエストでメインの処理コンポーネントとなるため、Tomcat 用にスケーリング・ポリシーを作成しますが、HTTPD 用にはスケーリング・ポリシーは作成しません。

スケーリング・ポリシーの設計

スケーリング・ポリシーでは、CPU 使用率に応じて自動的に Tomcat 仮想マシンを作成または破棄することができます。図 7 に示すように、スケーリング・ポリシーによって Tomcat を HTTPD に対して追加することができます。HTTPD のバランシング機能は、複数の Tomcat サーバーで利用することができます。

図 7. スケーリングのターゲット・アーキテクチャー
スケーリングのターゲット・アーキテクチャー
スケーリングのターゲット・アーキテクチャー

スケーリングのターゲット・アーキテクチャーでは、1 つの HTTPD が複数の Tomcat サーバーに接続してロード・バランシングを行います。この場合、Tomcat サーバーの数が n であれば、Tomcat サーバーごとのワークロードは約 1/n となります。このようなタイプのスケーリングは、水平スケーリングとも呼ばれます。この他、スケーリングのタイプには、ワークロードに合わせて CPU の数とメモリーを調整する垂直スケーリングと呼ばれるものもあります。垂直スケーリングについての詳細は、「プラグインのモニター・サービス」を参照してください。

スケーリング・ポリシー・プラグインを作成する

  1. plugin.com.ibm.samples.scaling プロジェクトを作成し、1 次パターン・タイプとして「patterntype.samples.apache」を指定します。
  2. このスケーリング・ポリシーにロールは必要ないので、plugin フォルダーの下に置かれている config.json を開き、「Overview (概要)」タブの「Package (パッケージ)」セクションから「SCALING」ロールを削除します。
  3. 「Application Model (アプリケーション・モデル)」タブに切り替えます。「policy_tomcat_scaling」という ID を持つ新規ポリシー・タイプ・メタデータを追加します。「Applicable to (適用対象)」リストに、プラグイン・コンポーネント名として「samplesTomcat」を追加します (図 8 を参照)。
    図 8. スケーリング・ポリシー・メタデータの詳細
    スケーリング・ポリシー・メタデータの詳細
    スケーリング・ポリシー・メタデータの詳細
  4. ポリシーに 3 つの必須属性を追加します。CPU.Used.Basic.Primitive 属性は、スケールアウト (最大値) からスケールイン (最小値) までの CPU 範囲を定義します。CPU 使用率がこの属性で定義した範囲を超えると、スケールインまたはスケールアウトが行われます。triggerTime1 属性は、スケールアウトまたはスケールインのトリガー時間 (秒単位) です。scaleInstanceRange1 属性は、スケールアウト (最大値) からスケールイン (最小値) までの仮想マシン・インスタンス数の範囲を定義します。
  5. 仮想アプリケーションの起動時には、最小数のアプリケーション・インスタンスが作成されます。以降は、仮想アプリケーションが定期的にモニターされて、すべてのアプリケーション・インスタンスの CPU 使用率がサンプリングされ、平均値が算出されます。各モニター時点で、モニターが開始されてから (経過した全時間にわたって) モニターされたすべての値をもとに計算した平均値が、指定した範囲を超えていた場合には、インスタンス数が許容範囲内であるという前提の下で、スケーリング・アクションがトリガーされます (図 9 を参照)。
    図 9. スケーリング・ポリシーの属性
    スケーリング・ポリシーの属性
    スケーリング・ポリシーの属性
  6. 「metadata.json」タブに切り替えて、グループ部分を追加すると、このグループ部分の内容 (リスト 6 を参照) が、PureApplication System の仮想アプリケーション・ビルダーにドロップダウン・メニューとして表示されます。「transformAs: linked」プロパティーを追加して、スケーリング・ポリシーが独立したポリシー・コンポーネントとして機能するようにしてから、すべての属性にサンプル値を追加します。
    リスト 6. metadata.json 内のスケーリング・ポリシーの属性
    groups: [
             {
                category: scaling policy type,
                id: Basic,
                label: CPU base scaling policy,
                defaultValue: true,
                attributes: [
                   CPU.Used.Basic.Primitive,
                   triggerTime1,
                   scaleInstanceRange1
                ],
                description: CPU base scaling policy type
             }
          ],
  7. messages.json を更新して国際化に対応させます (リスト 7 を参照)。
    リスト 7. スケーリング・ポリシーの messages.json
    {
    	POLICY_SCALING_TOMCAT_LABEL:Scaling Policy for Tomcat,
    	POLICY_SCALING_TOMCAT_DESC:Scaling Policy for Tomcat,
    	POLICY_SCALING_CPU_USED_LABEL:CPU used,
    	POLICY_SCALING_CPU_USED_DESC:CPU used percentage range,
    	POLICY_SCALING_TRIGGER_TIME_LABEL:Trigger time,
    	POLICY_SCALING_TRIGGER_TIME_DESC:Trigger time for scaling,
    	POLICY_SCALING_INSTANCE_RANGE_LABEL:Scale instance range,
    	POLICY_SCALING_INSTANCE_RANGE_DESC:Scale instance range,
    }
  8. 「policy_tomcat_scaling」という名前の OSGI サービス・コンポーネントを作成します。このコンポーネントの名前は、スケーリング・ポリシー・メタデータ ID と同じでなければなりません。「Service type (サービス・タイプ)」には、「Topology Provider (java based) (トポロジー・プロバイダー (Java ベース))」を選択します。「Implementation class (実装クラス)」には、「com.ibm.samples.transform.scaling.ScalingTransformer」と入力します (図 10 を参照)。
    図 10. OSGI コンポーネントのスケーリング・ポリシー
    OSGI コンポーネントのスケーリング・ポリシー
    OSGI コンポーネントのスケーリング・ポリシー

スケーリング・ポリシー・プラグインの実装

スケーリング・ポリシーには、ロールもスクリプトも含まれません。ScalingTransformer は com.ibm.maestro.model.transform.TopologyProvider 抽象クラスを実装し、transformComponent メソッドと transformLink メソッドの 2 つをオーバーライドします。

ポリシー・プラグインでは、transformComponent および transformLink メソッドが両方とも呼び出されます。transformComponent メソッドでは、メタデータの属性のフォーマットがスケーリングの属性のフォーマットに変換されます。メタデータの属性のフォーマットは、metadata.json で定義されます。スケーリングの属性のフォーマットは、リスト 8 に記載されているとおりです。

リスト 8. トポロジー文書内のスケーリングの属性のフォーマット
scaling:{
     triggerEvents:[{
         metric:CPU.Used,
         scaleOutThreshold:{value:40,type:CONSTANT,relation:>=},
         conjection:OR,
         scaleInThreshold:{electMetricTimeliness:historical,
         value:20,
         type:CONSTANT,
         relation:<=}],
    min:2,
    max:9,
    triggerTime:300,
    role:TOMCAT_INSTALL
}

リスト 8 のように設定することで、TOMCAT_INSTALL ロールで自動スケーリングを実行できるようになります。triggerEvents および triggerTime などの属性がスケーリングの構成部分に含まれている場合、これらの属性によってクラスターの自動スケーリング機能が有効化されます。また、上記に示されているように、インスタンスの最小数を定義する min 属性と、最大数を定義する max 属性もあります。

スケーリングの属性部分は、ターゲット・ロールが含まれる vm-template に追加する必要があります。これにより、vm-template 内の対応するロールで自動スケーリング機能が有効になります。

transformLink メソッドでは、トポロジー文書内の TOMCAT_INSTALL ロールが含まれる vm-template に、スケーリングの属性部分を追加します。

  • sourceFragment は、トポロジー文書内の該当するコンポーネントです。
  • targetFragment は、transformComponent によって生成されるスケーリング・ポリシー・トポロジー文書です。

スケーリングの属性をトポロジー文書内の該当するコンポーネントに追加するときには、スケーリングの属性に最大値と最小値が定義済みであることが重要です。ただし、これらの値は競合する可能性があるため、競合する値を修正するための correctScaleInstanceRange 関数が存在します。

リンク・プラグインに含まれる changed.py スクリプトは、複数の VM インスタンスを使用してスケーリングをサポートするように設計されていることに注意してください。

パターンへの使用インテント・ポリシーの追加

HTTPD サーバーと Tomcat サーバーの初期インスタンス数は、使用インテント・ポリシーによって制御することができます。このポリシーは、単独で使用することも、スケーリング・ポリシーと連動させることもできます。

インテント・ポリシーの設計

インテント・ポリシーでは、サーバー配備時に仮想マシンの数を変更することができます。このポリシーには、「テスト・インテント」と「本番インテント」の 2 種類があります。図 11 に、1 つの HTTPD サーバーと 2 つの Tomcat サーバーが配備された「テスト」トポロジーを示します。

図 11. テスト・インテントのトポロジー
テスト・インテントのトポロジー
テスト・インテントのトポロジー

このターゲット・アーキテクチャーでは、1 つの HTTPD サーバーが 2 つの Tomcat サーバーに接続します。それぞれの Tomcat サーバーに、50% のワークロードが配分されます。

図 12 に、「本番」トポロジーを示します。本番用配備は、2 つの HTTPD サーバーと 4 つの Tomcat サーバーからなる環境を提供します。

図 12. 本番インテントのトポロジー
本番インテントのトポロジー
本番インテントのトポロジー

このターゲット・アーキテクチャーでは、2 つの HTTPD サーバーが 4 つの Tomcat サーバーに接続します。この場合、通常は 2 つのTomcat サーバーが高可用性 (HA) サーバーとして使用されます。2 つの HTTPD サーバーのうち、一方の HTTPD サーバーがもう一方の HTTPD サーバーのバックアップとなります。それぞれの Tomcat サーバーには、25% のワークロードが配分されます。

スケーリング・ポリシーと併せてテスト・インテント・ポリシーを使用する場合、それはスケーリング・ポリシーのみを使用するのと同じことです。本番インテント・ポリシーとスケーリング・ポリシーを組み合わせると、図 13 に示す複雑なシステムになります。

図 13. 本番インテント・ポリシーとスケーリング・ポリシーを組み合わせたトポロジー
本番インテント・ポリシーとスケーリング・ポリシーを組み合わせたトポロジー
本番インテント・ポリシーとスケーリング・ポリシーを組み合わせたトポロジー

このターゲット・アーキテクチャーでは、2 つの HTTPD サーバーが多数の Tomcat サーバーに接続します。n 個の Tomcat サーバーがある場合には、それぞれの Tomcat サーバーには、1/n のワークロードが配分されます。

使用インテント・ポリシー・プラグイン・プロジェクトを作成する

  1. plugin.com.ibm.samples.scaling プロジェクトを作成して、1 次パターン・タイプとして「patterntype.samples.apache」を指定します。
  2. plugin フォルダー内にある config.json を開きます。このインテント・ポリシーには、ロールは必要ないので、「Overview (概要)」タブの「Package (パッケージ)」セクションから「INTENT」ロールを削除します。
  3. 「Application Model (アプリケーション・モデル)」タブに切り替えます。「policy_httpd_tomcat_intent」という ID を持つ新規ポリシー・タイプ・メタデータを追加します。「Applicable to (適用対象)」のリストには、「samplesHttpd」「samplesTomcat」を追加します (図 14 を参照)。
    図 14. インテント・ポリシー・メタデータの詳細
    インテント・ポリシー・メタデータの詳細
    インテント・ポリシー・メタデータの詳細
  4. 図 15 に示す 4 つの属性を追加します。httpdNumber1tomcatNumber1 は、テスト・インテント・ポリシー用の属性であり、httpdNumber2tomcatNumber2 は本番インテント・ポリシー用の属性です。
    図 15. インテント・ポリシーの属性
    インテント・ポリシーの属性
    インテント・ポリシーの属性
  5. 「metadata.json」タブに切り替えて、仮想アプリケーション・ビルダーのドロップダウン・メニューにするグループ部分を追加します。「transformAs: linked」プロパティーを追加して、インテント・ポリシーが独立したポリシー・コンポーネントとして機能するようにします。また、すべての属性にサンプル値を追加します。
  6. messages.json を更新して国際化に対応させます (リスト 9 を参照)。
    リスト 9. インテント・ポリシーの messages.json
    {
    	POLICY_SCALING_TOMCAT_LABEL:Scaling Policy for Tomcat,
    	POLICY_SCALING_TOMCAT_DESC:Scaling Policy for Tomcat,
    	POLICY_SCALING_CPU_USED_LABEL:CPU used,
    	POLICY_SCALING_CPU_USED_DESC:CPU used percentage range,
    	POLICY_SCALING_TRIGGER_TIME_LABEL:Trigger time,
    	POLICY_SCALING_TRIGGER_TIME_DESC:Trigger time for scaling,
    	POLICY_SCALING_INSTANCE_RANGE_LABEL:Scale instance range,
    	POLICY_SCALING_INSTANCE_RANGE_DESC:Scale instance range,
    }
  7. policy_httpd_tomcat_intent という名前の OSGI サービス・コンポーネントを作成します。「Service type (サービス・タイプ)」には、「Topology Provider (java based) (トポロジー・プロバイダー (Java ベース)」を選択します。「Implementation class (実装クラス)」には、「com.ibm.samples.transform.intent.IntentTransformer」と入力します (図 16 を参照)。
    図 16. インテント・ポリシー OSGI コンポーネント
    インテント・ポリシー OSGI コンポーネント
    インテント・ポリシー OSGI コンポーネント

インテント・ポリシー・プラグインの実装

インテント・ポリシーの IntentTransformer クラスは、スケーリング・ポリシーの ScalingTransformer と同様のクラスです。インテント・プロジェクトでは、transformComponent および transformLink メソッドが両方とも呼び出されます。transformComponent メソッドでは、メタデータの属性のフォーマットがインテントの属性のフォーマットに変換されます。インテントの属性は、スケーリングの属性のサブセットであり、両方のフォーマットは同じです (リスト 10 を参照)。scaling 属性には、role 属性の他には max 属性と min 属性があるのみです。max 属性は、初期値を制御するためだけに使われることから、この属性には min 属性と同じ値が設定されていることに注意してください。

リスト 10. トポロジー文書内のインテントの属性のフォーマット
scaling:{
   min:2,
   max:2,
   role:TOMCAT_INSTALL
}

transformLink メソッドでは、スケーリング・ポリシーが最初に実行される可能性があることから、scaling 属性が既に存在している可能性を認識して、スケーリングの属性部分を vm-template に追加します。さらに、min と max の値を修正する機能もあります。この機能では、トポロジー文書の max プロパティーの最大値とスケーリング・ポリシーを使用して、スケーリング・ポリシーの max プロパティーの値を設定し、トポロジー文書の min プロパティーの最小値とスケーリング・ポリシーを使用して、スケーリング・ポリシーの min プロパティーの値を設定します。トポロジー文書の scaling プロパティーは、スケーリング・ポリシーによって置き換えられます。

まとめ

この第 2 回の記事では、リンク、スケーリング・ポリシー、使用インテント・ポリシーを組み込んだ仮想アプリケーション・パターンを開発する方法を説明しました。この仮想アプリケーション・パターンを使用することで、ワークロード・パフォーマンスおよびターゲットとする使用シナリオに応じたトポロジーのスケーリングが可能になります。

第 3 回では、共有サービスを作成することにより、複数の Tomcat サーバー・インスタンスで共有されるシングルトン memcached サーバー・プールを提供します。

ダウンロード・ファイル

この記事に付属の samples.apache のサンプル・コードを参照してください。このパッケージをダウンロードし、メニューから「File (ファイル)」 > 「Import… (インポート…)」 > 「IBM Workload Plug-in Development」 > 「IBM Workload Pattern type Package (IBM Workload パターン・タイプ・パッケージ)」を順に選択して、プロジェクトをインポートすることができます。


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


関連トピック


コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=962898
ArticleTitle=IBM Pattern Development Kit を使用して仮想アプリケーション・パターンを作成する: 第 2 回 コンポーネント・リンク、スケーリング・ポリシー、およびインテント・ポリシーを作成する
publish-date=02202014