TSAM 拡張機能を使用して J2EE アプリケーションを管理する

3 層構成のクラウド・アプリケーションで、リソースの獲得、解放、ワークロードのバランスを取る

IBM Tivoli Service Automation Manager (TSAM) 7.2.2 では拡張機能の概念を導入し、新しい IT サービス自動化ソリューション (TSAM では、「サービス定義」と呼ばれます) を実装したり、既存のサービス定義に機能を追加したりすることができる TSAM ソフトウェア・コンポーネントのセットを用意しています。この記事では、システムのニーズに応じてロード・バランサー・ポリシーを調整する方法、ビジネス・アプリケーションのワークロードの変化に合わせてアプリケーション・サーバーを追加および除去する方法、そしてファイアウォール・ルールを変更する方法とそのような変更が必要になる理由を説明します。この記事の前編とも言える関連記事では、3 層構造の J2EE アプリケーションをセキュアな方法でクラウドにデプロイすることを目標としたシナリオを定義し、この目標を達成するために、TSAM で拡張機能をセットアップし、プロビジョニングする方法を具体的に説明しました。

Michele Crudele, Software Architect, IBM

Michele Crudele は、ローマにある IBM Software Group の Tivoli Lab に勤務するソフトウェア・アーキテクトです。20 年に及ぶ IT での経験の大半を、システム管理を目的とした製品およびソリューションを重点に費やしてきました。彼は、変更/構成管理、監視および可用性の管理、IBM オートノミック・コンピューティング技術、出版業界でのデジタル資産管理など、さまざまな分野で広範な技術的経験を積んでいます。現在はクラウド・コンピューティング・ソリューションを重点に取り組み、TSAM 拡張機能の主任アーキテクトを勤めています。



Fabio Cerri, Software Designer, IBM

Fabio Cerri は、ローマにある IBM Software Group の Tivoli Lab に勤務するソフトウェア設計者です。12 年に及ぶ IT での経験の大半を、システム管理を目的とした製品およびソリューションを重点に費やしてきました。変更/構成管理、ソフトウェア・ライセンス管理などのさまざまな分野で広範な技術的経験を積んだ彼は現在、TSAM ネットワークおよびストレージ拡張機能の主任設計者としてクラウド・コンピューティング・ソリューションに取り組んでいます。



2012年 5月 10日

Tivoli Service Automation Manager (TSAM) 7.2.2 では拡張機能の概念を導入し、TSAM プラットフォームにさらに機能を追加するための TSAM ソフトウェア・コンポーネントのセットを用意しています。拡張機能は通常、(これに限定されませんが) 以下の目的に対応します。

  • 新しい IT サービス自動化ソリューション (TSAM では、「サービス定義」と呼ばれます) の実装。例えば、大学の学生にホーム・ディレクトリーを提供するための Storage-as-a-Service ソリューションを実装するなどです。
  • 既存のサービス定義への機能の追加。例えば、サービス・ソリューションとしてそのまま使用できる TSAM を拡張し、ブート・ディスクと併せて追加のディスクを仮想マシンに接続できるようにします。

拡張機能は、TSAM の開発サイクルとは別に、IBM または顧客サービス・チームによって開発されてリリースされます。IBM が開発した拡張機能は、Integrated Service Management Library から TSAM のユーザーに無料でリリースされます。これらの拡張機能には、インストールおよび構成ガイドと、IBM 標準に従ったユーザーズ・ガイドが同梱されています。また、IBM Tivoli Service Automation Manager インフォメーション・センターから、IBM からリリースされた拡張機能のオンライン・マニュアルにアクセスすることもできます (「参考文献」を参照)。

IBM がこれまでにリリースした拡張機能のうち、TSAM で作成された仮想サーバー・プロジェクトにセキュリティー、スケーラビリティー、冗長性を追加するためにネットワーク機器の構成を管理できる拡張機能としては、次の 2 つがあります。

  • Juniper SRX ファイアウォール用 IBM Tivoli Service Automation Manager 7.2.2 拡張機能
  • F5 BIG-IP ロード・バランサー用 IBM Tivoli Service Automation Manager 7.2.2 拡張機能

Juniper SRX ファイアウォール用拡張機能は、Juniper SRX エンタープライズ・ファイアウォールによって保護される VLAN/サブネット内に (TSAM プロジェクトで) プロビジョニングされた仮想サーバーに対して、デフォルトのルール・セットを使用して自動的に制限をかける機能を提供します。クラウド管理者はプロジェクトのライフサイクルの間、ファイアウォール・ルール変更用の拡張機能が提供するサービス・オファリングを使用して、ファイアウォールのルールをさらに細かく調整することができます。デフォルトのルールは、拡張機能の初期セットアップ時に、顧客のニーズに応じてカスタマイズすることができます。

もう一方の F5 BIG-IP ロード・バランサー用拡張機能では、TSAM プロジェクトでプロビジョニングされた仮想サーバーの背後に「仮想ロード・バランサー」を配置することで、仮想サーバーにインストールされたアプリケーションのスケーラビリティーおよび冗長性を強化することができます。またロード・バランサー・ポリシーを作成することによって、TSAM プロジェクトの VLAN/サブネットのパブリック VIP (Virtual IP) アドレスでアプリケーションをアドバータイズすることができます。ロード・バランサー・ポリシーは、アプリケーションに到達するための VIP:Port と、アプリケーションを実行する (TSAM プロジェクトの) 仮想サーバー・クラスターによって識別されます。

エンタープライズ顧客は、これらのフィーチャーを利用することにより、再現可能な方法で迅速に、支社、ビジネス・パートナー、クライアントに対して階層構成のビジネス・アプリケーション (J2EE アプリケーションなど) をセキュアでスケーラブルかつ冗長性があるアプリケーションとしてプロビジョニングすることができます。

TSAM 拡張機能に関する最初の記事では、3 層構造の J2EE アプリケーションをセキュアな方法でクラウドにデプロイすることを目標としたシナリオを定義し、この目標を達成するために、TSAM で拡張機能をセットアップし、プロビジョニングする方法を具体的に説明しました。今回の記事で説明する方法を十分に理解するためには、まず、この最初の記事を読むことをお勧めします。

今回の記事では、システムのニーズに応じてロード・バランサー・ポリシーを調整する方法、ビジネス・アプリケーションのワークロードの変化に合わせてアプリケーション・サーバーを追加および除去する方法、そしてファイアウォール・ルールを変更する方法とそのような変更が必要になる理由を説明します。

シナリオの簡単な復習

顧客 ABC は、TSAM 7.2.2 と、Juniper SRX ファイアウォールおよび BIG-IP F5 ロード・バランサー対応の拡張機能をベースに、プライベート (オンプレミス) クラウド・ソリューションを運用している企業です。ABC は支社、ビジネス・パートナー、クライアントにサービスを提供するために、TSAM プラットフォームを使用しています。特に、ABC はこのプラットフォームにあらかじめ用意されている機能を大々的に利用して、クライアントが HTTP/HTTPS 標準プロトコルでアクセスできるように Web アプリケーションをプロビジョニングしています。

ABC が使用している標準的な Web アプリケーションは、HTTP サーバー、アプリケーション・サーバー、およびデータベース・サーバーからなる 3 層構成の J2EE アプリケーションです。従来のデプロイメントでは、これらのサーバーを論理的に分離するために、ルーターとファイアウォールによってサーバーに対するネットワーク接続とアクセスを制限します。データベース・サーバーがアクセスするデータは、セキュアなストレージ・ゾーンに置かれるのが通常です。

ファイアウォールとロード・バランサー用の拡張機能をダウンロードしないとしたら、ABC はサーバーをそれぞれに異なるネットワーク・セグメントで隔離するためのプロセス、そして通常はクラスターという形でデプロイされているアプリケーション・サーバーに要求を均等に配分するためのプロセスを独自にセットアップしなければなりません。けれども、ABC は BIG-IP F5 および Juniper SRX ネットワーク機器をすでに所有していることから、賢明にも、TSAM 拡張機能をセットアップして Web アプリケーションの構成を標準的なものにすることにしました。

このシナリオの詳細な内容については、TSAM 拡張機能に関する最初の記事を読んでください。

それでは早速、ロード・バランシング、そしてネットワーク・ファイアウォール・ルールを適応させる方法についての検討に入ります。


ロード・バランシングの概要

BIG-IP F5 ロード・バランサー用の TSAM 拡張機能は、ビジネス・アプリケーションのアプリケーション・サーバーの間でワークロードを均等に配分するためのサービス・オファリングを提供します。関連記事では、そのために初期デプロイメント中に必要な作業について説明していますが (「プロビジョニング」セクションのステップ 4)、ロード・バランサー・ポリシーの属性については詳しく説明されていません。

テスト・ラボでビジネス・アプリケーションをデプロイするときには、デフォルトの値が選択されたままにすることができますが、アプリケーションをクライアントにデプロイするときには、ロード・バランサー・ポリシーの属性が持つ意味を十分に理解しておくことが重要です。適切なロード・バランサー・ポリシーを選択することが、パフォーマンスおよびリソースの使用という点で違いをもたらすためです。

まずは、ロード・バランサー・ポリシーのカスタマイズ方法について説明します。


ロード・バランサー・ポリシーのカスタマイズ

初期デプロイメントの完了後は、「Modify Load Balancer Policy (ロード・バランサー・ポリシーの変更)」サービス・オファリングを使用して、随時、ロード・バランサーによるワークロードの管理方法を変更することができます。このサービス・オファリングで操作する必要があるパラメーターは、基本的に「Create Load Balancer Policy (ロード・バランサー・ポリシーの作成)」と同じです (ただし、ポリシーの name 属性と VIP:port 属性は除きます。これらの属性を変更することはできません)。

ロード・バランサー・ポリシーは、BIG-IP F5 ロード・バランサー用の TSAM 拡張機能によって定義される内部成果物であり、このポリシーは、BIG-IP 機器を最適に構成するために必要な情報で構成されます。この拡張機能の役目は、ビジネス・アプリケーションの要求側のタスクを可能な限り単純化した上で、BIG-IP 機器の複雑さを数少ない直観的なパラメーターの背後に隠し、これらのパラメーターによって拡張コードが BIG-IP の構成ステップを自動化できるようにすることです。

ロード・バランサー・ポリシーが抽象化されない場合に、ビジネス・アプリケーションの要求側が配慮しなければならなくなるような概念として、構成プロファイルを考えてください。構成プロファイルは、BIG-IP 機器内でのネットワーク・トラフィック (例えば、HTTP) の振る舞いを定義する設定が含まれる、いわゆるコンテナーです。構成プロファイルに含まれる設定のそれぞれが、特定の機能を使用可能にします。使用可能にされる機能には、例えば以下に挙げるものがあります。

  • HTTP リクエストへのヘッダーの挿入
  • HTTP サーバー・レスポンスの圧縮
  • アプリケーションの認証
  • コネクション・プーリング、その他

ロード・バランサー・ポリシーを抽象化すると、以下の内容に基づいて BIG-IP 機器を構成するために適用される構成プロファイルが、自動的に特定されます。

  • トラフィックのタイプ (図 1 の「Protocol (プロトコル)」)。選択肢には、「HTTP」、「HTTPS」、「TCP」、および「UDP」があります。
  • 仮想 IP アドレスのタイプ (図 1 の「Virtual Server Type (仮想サーバーのタイプ)」)。選択肢には、「Standard (標準)」および「Performance (パフォーマンス)」があります。「Performance (パフォーマンス)」は、HTTP またはレイヤー 4 リクエストの処理速度を増加させる VIP を指定します。
  • BIG-IP とロード・バランシング対象の仮想サーバーとの間の接続を再利用するかどうか (図 1 の「Connection Pool (コネクション・プール)」)。接続を再利用することで、接続のセットアップおよび切断が最小限になり、仮想サーバーの負荷が軽減されます (このオプションを有効にすると、F5 Networks OneConnect フィーチャーが使用可能になります。このフィーチャーは、サーバー・サイドの接続をオープン状態に維持し、接続を再利用できるようにプールすることによって、ネットワーク接続を最適に使用できるようにします)。
  • セッションの有効期間中または後続のセッション期間中に、クライアント・リクエストをプロジェクト内の同じ仮想サーバーに転送するかどうか (図 1 の「Session Persistence (セッション・パーシスタンス)」)。
図 1. ロード・バランサー・ポリシーの属性
ロード・バランサー・ポリシーの属性

この記事および関連記事で定義している、標準化されたビジネス・アプリケーションの場合、ロード・バランサー・ポリシーを以下の値で設定します。

  • Protocol (プロトコル): HTTP.
  • Virtual Server Type (仮想サーバーのタイプ): アプリケーションのテスト期間中は「Standard (標準)」を使用します。クライアントにデプロイするときには、「Performance (パフォーマンス)」を使用します。
  • Connection Pool (コネクション・プール): 「Virtual Server Type (仮想サーバーのタイプ)」として「Performance (パフォーマンス)」を選択すると、このオプションが自動的に選択され、「Standard (標準)」を選択すると、このオプションを使用するかどうかをユーザーが決定することができます。
  • Session Persistence (セッション・パーシスタンス): このパラメーターを設定するかどうかは、ビジネス・アプリケーションの特性に応じます。設定する必要がある場合、拡張コードは BIG-IP 機器に cookie パーシスタンス・プロファイルを構成することに注意してください。つまり、BIG-IP 機器は、クライアントのコンピューターに保管された HTTP cookie を使用して、クライアントに対して、前に Web サイトにアクセスしたことのあるロード・バランシング対象の仮想サーバーへの再接続を許可します。

図 1 を見るとわかるように、ロード・バランサー・ポリシーには以下の追加情報が伴います。

  • BIG-IP 機器が仮想サーバーの間でワークロードを均等に分配するために使用するルーティング・アルゴリズム (図 1 の「Algorithm (アルゴリズム)」) として、ラウンド・ロビン、最小コネクション、または予測アルゴリズムを選択することができます。すべてのクライアント・リクエストに対し、BIG-IP はアルゴリズムを実行して、リクエストをルーティングするのに適切な仮想サーバーを選択します。そのためには、ロード・バランシング対象の仮想サーバーに関する監視および可用性情報が必要です。この情報は、いわゆるモニターによって定期的に収集されます。
  • ヘルス・チェックに関するパラメーター (図 1 の「Probe Protocol (プローブ・プロトコル)」、「Check Interval (チェック間隔)」、および「Timeout (タイムアウト)」) は、拡張コードが BIG-IP モニターを構成するために使用します。チェック間隔は、BIG-IP が仮想サーバーを調べる間隔を指定します。タイムアウトは、仮想サーバーが監視リクエストを受け取ってから応答を返すまでに許容される最大の秒数を指定します。この秒数が過ぎても仮想サーバーからの応答がない場合、その仮想サーバーは停止していると見なされ、新しい接続のターゲットとして使用されなくなります。

では、この記事で定義するビジネス・アプリケーションに使用するには、どのアルゴリズムが最適でしょうか?それは、アプリケーションの特性によって決まります。

  • 最も単純なアルゴリズムは、ラウンド・ロビンです。この場合、BIG-IP は、モニターに応答している仮想サーバーの循環リストから順次仮想サーバーを選択していきます。
  • それよりも効率的なアルゴリズムは、最小コネクションです。この場合、BIG-IP はロード・バランシング対象の各仮想サーバーが処理した接続数の統計を維持し、プールのメンバーのなかで一定期間の間に最も接続数の少ないメンバーに新しい接続を渡します。
  • 使用可能なアルゴリズムのうち、最も優れているのは予測アルゴリズムです。この場合、BIG-IP は最小コネクションと同じランキング方式を使用しますが、さらに傾向を分析して、ノードのパフォーマンスが向上しているか、または劣化しているかを把握します。

アルゴリズムが優れていればいるほど、計算を行うために BIG-IP のリソースをより多く必要とします。したがって、ビジネス・アプリケーションをテストする際にはラウンド・ロビンを選択し、クライアントにアプリケーションをアドバータイズする段階になった時点で、ロード・バランサー・ポリシーを予測アルゴリズムに変更するのが良いかもしれません。

ロード・バランサー・ポリシーは 1 つの TSAM プロジェクトに属し、単一のプロジェクトから仮想サーバー全体に適用することができます。1 つのプロジェクトに複数のポリシーをデプロイすることもできますが、ポリシーごとに、外部アクセス専用の VIP:port のペアが必要になります。

次は、ワークロードの増減に応じてアプリケーション・サーバーを追加、および除去する方法を検討します。


アプリケーション・サーバーの追加と除去

ビジネス・アプリケーションへのアクセス数が増えるにつれ、クライアントは応答時間が遅くなっていると感じるはずです。この影響は、定期的に傾向分析レポートを実行して、タイミング良くアプリケーション・サーバーを追加することによって未然に防ぐことができます。

ビジネス・アプリケーションを担当する管理者は、以下のサービス・オファリングを使用してアプリケーション・サーバーを追加、除去します。

  1. TSAM の「Add Server to Project (プロジェクトへのサーバーの追加)」サービス・オファリング: このサービスを使用して、ビジネス・アプリケーション・プロジェクトの追加アプリケーション・サーバーを要求します。
  2. 「Modify Load Balancer Policy (ロード・バランサー・ポリシーの変更)」サービス・オファリング: TSAM が新規アプリケーション・サーバーをプロビジョニングした後、このサービスを使用して、そのサーバーをロード・バランサーに追加します。追加するには、「Create Load Balancer Policy (ロード・バランサー・ポリシーの作成)」ウィンドウで、新規サーバーのホスト名にチェック・マークを付けます (図 2 を参照)。
図 2. 仮想サーバーのロード・バランサー・ポリシー・プール
仮想サーバーのロード・バランサー・ポリシー・プール

逆の事態が発生した場合には (傾向分析レポートに、ビジネス・アプリケーションの使用の減少が示された場合)、リソースを解放して IT 環境内の別の用途に使用できるようにするか、あるいはデータ・センターの電力使用量を削減したいと考えるはずです。その場合、アプリケーション・サーバーの電源を切るか、またはアプリケーション・サーバーを解放し、それによってハイパーバイザーのデータ・ストアのストレージ・スペースも解放することができます。

ビジネス・アプリケーションの管理者がアプリケーション・サーバーの電源を切ることを決定した場合に必要となる作業は、TSAM の「Stop Server (サーバーの停止)」サービス・オファリングを使用することだけです。ロード・バランサーは、(モニターによって) サーバーが応答していないことを検出し、接続のルーティングを停止します。サーバーが再起動されると、それと同時にロード・バランサーが接続のルーティングを再開します。

管理者が最終的にそのアプリケーション・サーバーをビジネス・アプリケーション・プロジェクトから除去することを決定した場合には、以下のサービス・オファリングを使用します。

  1. 「Modify Load Balancer Policy (ロード・バランサー・ポリシーの変更)」サービス・オファリング: このサービスを使用して、アプリケーション・サーバーをロード・バランサーから除去します。それには、2 番目の画面に直接進んで (図 2 を参照)、サーバーのホスト名のチェック・マークを外します。
  2. TSAM の「Remove Server from Project (プロジェクトからのサーバーの除去)」サービス・オファリング: サーバーをデプロビジョニング (プロビジョニング解除) するには、このサービスを使用します。

TSAM がクラウド・コンピューティングを容易にするために提供している最も優れた機能の 1 つは、管理タスクを自動化する機能です。これには、ワークロードの変化に応じたサーバーのプロビジョニング/デプロビジョニングの自動化も含まれます。次のセクションでは、この機能について検討します。


アプリケーションのプロビジョニング/デプロビジョニングの自動化

ここからが面白い部分です。このセクションは、前のセクションと似ていますが、ここではワークロードが変わるたびに管理をする必要はありません。本番環境での Web アプリケーションに必要なコンピューティング・リソースの量は、(変更の頻度、必要なリソースの量という両方の点で) 大幅に変動する可能性があります。その量は、提供されるサービスの実際のタイプに依存します。以下に、いくつかのサンプル・シナリオを紹介します。

  1. オンライン家電販売店アプリケーションのトランザクションは、クリスマス商戦の時期に急増しますが、それ以外の時期は、トランザクションが年々増加するとしても、ワークロードは安定しています。
  2. 従業員の在席状況を追跡するエンタープライズ・アプリケーションでは、毎月第 1 営業日にリソース使用量がピークに達しますが、それ以外の日にはほぼ一定しています。
  3. オンライン・ライブラリーでは、夏の間、貸し出しが大幅に減少します。
  4. 国際的なオンライン・ニュースペーパー Web サイトでは、世界での重要な出来事の発生によってリソース使用量がピークに達します。これは、予測不可能です。

システムが即時に、しかも正確に反応して、使用可能なコンピューティング・リソースの量をアプリケーションに実際に必要なリソース量に対応させることが、顧客とのサービス・レベル・アグリーメント (SLA) を維持する上でも、リソースの使用を最適化する上でも非常に重要です。

これまでのセクションで説明したように、TSAM と BIG-IP F5 ロード・バランサー用の TSAM 拡張機能は、ワークロードの変化に対応するために必要なサービス・オファリングを提供します。けれども、これらのオファリングは、管理者の手動による介入なしにビジネス・アプリケーションを再構成可能な自動ソリューション、あるいは自己調節ソリューションにはなりません。そのようなソリューションは、顧客がそうした目的で作成する必要があります。

このセクションで目指しているのは、そのような自動化を、パブリック TPAE (Tivoli Process Automation Engine) および TSAM API、そしてその他のツールを利用して実現する方法を説明することです。TSAM ソリューションに自動調節機能を追加する手法をいくつか説明しますが、ソリューションの詳細に踏み込んで説明することはしません。代わりに、使用可能な別の技術、そしてこのタスクを達成するために使用する共通アーキテクチャーについて説明します。

最初に、このソリューションの手法とこれを実装するために必要なコンポーネントから説明します。その後、この汎用的な手法を、それぞれに異なる技術に依存する 2 つの具体的な実装に適用します。

図 3 に、ソリューションのコンポーネントを要約します。

図 3. ワークロード・バランシングの自己調節ソリューションに必要なコンポーネント
ワークロード・バランシングの自己調節ソリューションに必要なコンポーネント
  • コントローラーは、ビジネス・アプリケーションに必要な SLA を現在観測されている振る舞いと比較し、必要なアクションを決定することによって、システムの自己調節操作を制御します。コントローラーが、アプリケーション・サーバーをプロビジョニングまたはデプロビジョニングするタイミング、休止状態のアプリケーション・サーバーをオンに切り替えるタイミング、および有効に処理を行えていないアプリケーション・サーバーをオフに切り替えるタイミングを決定します。
  • リソース・モニターは、Web アプリケーションの状況と、そのベースで稼働する仮想サーバーの状況を収集するコンポーネントです。このコンポーネントによって収集された情報が、コントローラーの処理を開始するための重要な入力データとなります。コントローラーに情報を提供するパターンは、リソースの定期チェックごとに提供するようにすることも、イベントによって提供するようにすることもできます。この 2 つのどちらを選択するかは、リソース・モニターに採用された実際の技術によって変わってきます。
  • リソース・マネージャーは、アクチュエーターです。つまり、アプリケーション・サーバーのプロビジョニング/デプロビジョニング、およびロード・バランサー・ポリシーの更新を行います。このコンポーネントに該当するのは、この記事で説明するシナリオでは、BIG-IP F5 ロード・バランサー用の拡張機能を備えた TSAM です。

ここで提案する 2 つのソリューションに共通して必要なのは、TPAE をカスタマイズおよび統合するスキル (Maximo Enterprise Adapter)、そして TSAM の REST ベースの API スキルです。

  1. 最初のソリューションでは、BIG-IP 機器のモニターが収集するデータを使用して、コントローラーを実装します。このソリューションには、BIG-IP モニターのデータを取得するための開発スキルが必要になります。
  2. 2 番目のソリューションは、ITM (IBM Tivoli Monitoring) 製品をベースとした、イベント駆動型コントローラーの例です。このソリューションでは、ITM でイベントを処理するスキルも必要となります (TEC または Omnibus)。

ここからは、それぞれのソリューションについて詳しく検討します。

BIG-IP を使用する場合

図 4 に、BIG-IP を使用する場合には汎用ソリューションがどのように実装されるかを示します。

図 4. ワークロード・バランシングの自己調節ソリューション: BIG-IP モニターのデータを使用する場合
ワークロード・バランシングの自己調節ソリューション: BIG-IP モニターのデータを使用する場合

コントローラーは、スケジュールされたタスク (図中の TPAE Cron task (TPAE クーロン・タスク)) を使用して、TPAE プラットフォームに実装されます。スケジュールされたタスクは、定期的にリソースの状況をチェックし、最終的にその状況に応じた適切なアクションを実行します。リソースでのチェック情報は、BIG-IP ロード・バランサーに送信されます。コントローラーには、BIG-IP ロード・バランサーの IControl インターフェースにアクセスするためのイネーブルメント・ライブラリーが組み込まれます。

IControl インターフェースには、各種のプログラミング環境 (Java、.NET、Python、Perl など) のサポートが組み込まれているため、ソリューションを柔軟に実装することができます。Java プログラミング言語を使用する場合、イネーブルメント・ライブラリーに該当するのは JAR ファイルです。

コントローラーが、監視対象のアプリケーションの統計からアラートが必要な値を検出すると、システムの効率性および可用性を維持するためのアクションを決定します。アクションの実行により、TSAM の REST API インターフェースが呼び出され、プロビジョニング・タスクを完了するためのサービス・リクエストが送信されます。

IBM Tivoli Monitoring を使用する場合

図 5 に示すように、このソリューションは、アプリケーション・サーバーの状況を監視する ITM エージェントを使用します。

図 5. ワークロード・バランシングの自己調節ソリューション: ITM エージェントを使用する場合
ワークロード・バランシングの自己調節ソリューション: ITM エージェントを使用する場合

このソリューションでは、アプリケーション・サーバーに ITM エージェントをインストールして、適切に構成する必要があります。これは、ビジネス・アプリケーションの TSAM プロジェクトを要求するときに行うことができます。あるいはアプリケーション・サーバーをインスタンス化するために使用する仮想イメージに ITM エージェントを組み込むという方法もあります。ITM エージェントにより、統計データが ITMサーバーにアップロードされ、イベント処理のために OMNIbus に転送されます。

イベントが OMNIbus に到達した後は、カスタムの出口プロシージャーを使って TSAM REST API を呼び出すことができます。さらに、OMNIbus と Service Request Manage を統合することによって、プロビジョニング要求を送信することもできます。

次は、もう 1 つの主要なトピックについて検討します。それは、特定のエンタープライズ・アプリケーションのセキュリティー設定を変更しなければならない場合に、ファイアウォール・ルールをその変更に対応させる方法です。


ネットワーク・ファイアウォール・ルールを対応させる

Juniper SRX ファイアウォール用の TSAM 拡張機能は、ユーザーが TSAM 拡張機能の構成の一環としてネットワーク・テンプレートを作成するときに定義したデフォルト・ルールに基づき、ビジネス・アプリケーションのデプロイ時に自動的にファイアウォール・ルールを設定します。ユーザーがファイアウォール・ルールを再度処理する必要はありません。

当然、上記のシナリオはどれだけ現実的なのかという疑問が湧いてきます。特定のビジネス・アプリケーション・プロジェクトに応じてセキュリティー設定を変更しなければならないような状況は常に存在します。そのためには、現在の設定を確認することができなければなりません。

Juniper SRX ファイアウォール用 TSAM 拡張機能には、「Modify Firewall Policy (ファイアウォール・ポリシーの変更)」サービス・オファリングがあります。ファイアウォール・ポリシーは、ロード・バランサー・ポリシーと同様に、拡張機能によって定義される内部成果物です。このポリシーを構成するファイアウォール・ルールは、TSAM 仮想サーバーのプロジェクト、さらに具体的に言うとプロジェクトのサブネット/VLAN に適用されます。各プロジェクトには、それぞれに固有のファイアウォール・ポリシーがあります。このポリシーを変更するには、それを構成する個々のファイアウォール・ルールを追加、変更、または削除します (図 6 を参照)。

図 6. ビジネス・アプリケーション・プロジェクトに対して構成されたファイアウォール・ポリシー
ビジネス・アプリケーション・プロジェクトに対して構成されたファイアウォール・ポリシー

ファイアウォール・ルールは、ある送信元サブネットから別の送信先サブネットへと送信される特定のプロトコル・トラフィックを許可します。送信元と送信先 (図 6 を参照) には、一般に CIDR 表記 (サブネット・アドレス/サブネットを識別する IP アドレスのビット数) によってサブネット全体が指定されますが、特定のホストに対してトラフィックを許可したい場合には、単一の IP アドレスをファイアウォール・ルールの送信元と送信先として指定することもできます。

お気付きかもしれませんが、トラフィックを拒否するルールを指定することはできません。とは言え、この拡張機能の主な特徴のなかには以下に挙げるようなものがあります。

  • ビジネス・アプリケーションの要求側のタスクが単純化されます。
  • セキュリティー・リスクが最小限に抑えられます。

以上のことから、ファイアウォール・ポリシーには常に、変更不可能な隠しルールが含まれます。それは、すべてのトラフィックの拒否です。したがって、管理者はこのルールの例外とするトラフィックを指定することで、特定のトラフィックだけを許可することができます。これは、この機能を簡単に、そして少ないリスクで実装する方法です。

管理者の作業をさらに単純にするために、以下の 3 つのタイプのファイアウォール・ルールがあります。

  • 「From Internet (インターネットからの接続)」ルール: このルールでは、DMZ から開始された特定のプロトコル・トラフィックをプロジェクトのサブネット/VLAN に対して許可することができます。0.0.0.0/0 という表記を使って任意のアドレスを示すことができます。例えば、0.0.0.0/0 から 192.168.0.0/16 への「インターネットからの接続」ルールは、DMZ 内のすべての IP アドレスがサブネット 192.168.0.0/16 への接続を開始できることを意味します。
  • 「To Internet (インターネットへの接続)」ルール: このルールでは、プロジェクトのアプリケーション・サーバーのいずれか 1 つから DMZ に対して開始された特定のプロトコル・トラフィックを許可することができます。
  • 「From Other Project(s) (他のプロジェクトからの接続)」ルール: このルールでは、他のプロジェクト (例えば共有サービスをホストするプロジェクト) と通信できるようにプロジェクトをオープンにすることができます。「他のプロジェクトからの接続」ルールに 0.0.0.0/0 から共有サービス・プロジェクト内の 192.170.0.0/16 を設定すると、他の任意のプロジェクトが接続を開始できるようになり、それによって共有サービスの使用が可能になります。共有サービス (サブネット 192.168.0.0/0) にアクセスする必要のあるプロジェクトで、「他のプロジェクトから接続」ルールに 192.168.0.0/16 から 192.170.0.0/16 を設定すれば、構成は完了です。

まとめ

この記事では、Juniper SRX ファイアウォールおよび BIG-IP F5 ロード・バランサー用の TSAM 拡張機能を利用して、クラウドにデプロイされた J2EE ビジネス・アプリケーションのライフサイクル管理のいくつかの側面に対処する方法を説明しました。特に焦点を絞ったのは、ビジネス・アプリケーションのワークロードに対処できるように適切にロード・バランサーを調整する方法、アプリケーション・サーバーを追加および除去してビジネス・アプリケーションの使用状況の変化に対応する方法、そしてファイアウォールを効果的に使用してサーバーへのアクセスを制限する方法です。

ビジネス・アプリケーションの初期プロビジョニングについては、関連記事で説明しています。その関連記事を読めば、BIG-IP F5 ロード・バランサーの背後で Juniper SRX ファイアウォールが管理する VLAN/サブネットに仮想サーバーを配置する TSAM プロジェクトを作成する方法を学ぶことができます。

参考文献

学ぶために

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

議論するために

コメント

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, Tivoli (service management), Java technology
ArticleID=812248
ArticleTitle=TSAM 拡張機能を使用して J2EE アプリケーションを管理する
publish-date=05102012