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

3 層構成のエンタープライズ・アプリケーションをセキュアな方法でクラウドにデプロイする

IBM Tivoli Service Automation Manager (TSAM) 7.2.2 では拡張機能の概念を導入し、新しい IT サービス自動化ソリューション (「サービス定義」と呼ばれます) を実装したり、既存のサービス定義に機能を追加したりすることができる 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年 2月 23日

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 プロジェクトで) プロビジョニングされた仮想サーバーに対して、デフォルトのルール・セットを使用して自動的に制限をかける機能を提供します。クラウド管理者はプロジェクトのライフサイクルの間、ファイアウォール・ルール変更用の拡張機能が提供するサービス・オファリングを使用して、ファイアウォールのルールをさらに細かく調整することができます。

デフォルトのルールは、拡張機能の初期セットアップ時に、顧客のニーズに応じてカスタマイズすることができます (図 1 を参照)。

図 1. ファイアウォールおよびロード・バランサーを対象とした拡張機能
ファイアウォールおよびロード・バランサーを対象とした拡張機能

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

ロード・バランサー・ポリシーは、アプリケーションに到達するための VIP:Port と、アプリケーションを実行する (TSAM プロジェクトの) 仮想サーバー・クラスターによって識別されます (図 1 を参照)。

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

この記事では、ファイアウォールとロード・バランサーにすぐに使用できる TSAM の拡張機能を利用して、3 層構成の J2EE アプリケーションをプロビジョニングする方法を説明します。ここで検討するのは、標準的な使用ケースです。TSAM には、顧客のニーズに応じてソリューションをカスタマイズするツールが用意されている場合もあれば、用意されていない場合もあるので、この記事では、顧客が TSAM プラットフォームを使用して簡単にプライベート・クラウド・ソリューションをセットアップできる方法を示すために、カスタマイズなしでそのまま使用できる機能に重点を置きます。

シナリオ

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

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

図 2. 標準的な J2EE アプリケーションのデプロイメント
標準的な J2EE アプリケーションのデプロイメント

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

図 3. J2EE アプリケーション・デプロイメントの標準化モデル
J2EE アプリケーション・デプロイメントの標準化モデル

標準化モデルの内容を以下に説明します。

  • すべてのサーバーは TSAM 仮想サーバー・プロジェクトの一部としてプロビジョニングされます。アプリケーション・サーバーとデータベース・サーバーは、それぞれに異なる仮想イメージをベースにプロビジョニングされます。
  • データベース・サーバーは、内部 VLAN/サブネット上に構成されます。内部 VLAN/サブネットは、ルーティング可能でファイアウォールによって保護されている、という構成ではないため、ABC ネットワーク内では特異な VLAN/サブネットです。データベース・サーバーは、データ・ディスクにアクセスできるように、ストレージ VLAN/サブネット内の vNIC とともにプロビジョニングされます。
  • アプリケーション・サーバーが構成される場所は、Web アプリケーションをホストする TSAM プロジェクトを作成すると自動的に確保される VLAN/サブネット (プロジェクト VLAN/サブネット) 上です。TSAM プロジェクトの作成時には、Web アプリケーションの VIP もプロジェクト VLAN/サブネット上で確保され、その VIP を他のネットワーク・セグメントから隔離するデフォルトのファイアウォール・ルールも設定されます。このファイアウォール・ルールで許可されるのは、DMZ からの HTTP トラフィックだけです。ファイアウォールおよびロード・バランサーの TSAM 拡張機能によって、あらゆる設定が自動的に行われます。
  • アプリケーション・サーバーは、データベース・サーバーが常駐する内部 VLAN/サブネットの vNIC とともにプロビジョニングされます。
  • ロード・バランシング・ソフトウェア・アプリケーションをデプロイする必要がないことに注目してください。その代わりとして使用される BIG-IP F5 は、TSAM プロジェクトのプロビジョニング時に自動的に構成されます。

ABC が開発や品質保証の取り組みの結果として新規アプリケーション XYZ をクライアントに配信するときには、必ず QA チームが (物理サーバーから仮想イメージを取り込むことによって) データベース・サーバーおよびアプリケーション・サーバーの仮想イメージを作成し、これらの仮想イメージを XYZ データベース・サーバー、XYZ アプリケーション・サーバーとして TSAM に登録します (このアクティビティーについては、記事の後のほうで詳しく説明します)。

: マルチテナンシー機能を利用して、同じ TSAM インスタンスで開発および QA 用の仮想環境をセットアップすることも考えられます。その場合、ABC は内部開発プロジェクトおよびテスト・プロジェクトをホストする「テナント」(TSAM の用語では「顧客」) を作成することができます。Juniper SRX ファイアウォールを対象とした TSAM 拡張機能は、ファイアウォールにセキュリティー・ゾーンを自動的に作成し、すべての開発プロジェクトを外界から、そしてインターネット対応の本番プロジェクトから遮蔽します。このようにセットアップすれば、QA チームは仮想イメージを例えば本番テナントにプロモートするだけでよくなります。プロモートした時点から、XYZ データベース・サーバーと XYZ アプリケーション・サーバーの仮想イメージをいつでも次のステップに進められます。

仮想イメージが正しくセットアップされた後は、TSAM の標準サービス・オファリングから Web アプリケーション XYZ を要求することができます。その流れは以下のとおりです。

  • XYZ アプリケーションという名前の仮想サーバー・プロジェクトを要求し、仮想イメージ (例えば、Linux Red Hat、DB2、XYZ データベース・インスタンスが事前構成されたソフトウェア・スタック) をベースとしてデータベース・サーバーを追加します。
  • 上記項目の要求が満たされたら (つまり、プロジェクト VLAN/サブネットが確保されてファイアウォール上で適切に構成され、データベース・サーバーがプロビジョニングされたら)、XYZ アプリケーション・サーバー・イメージをベースとした 1 つ以上の仮想サーバーを XML アプリケーション・プロジェクトに追加します。
  • 上記項目の要求が満たされたら (つまり、アプリケーション・サーバーがプロビジョニングされたら)、最後に、プロビジョニングされた XYZ アプリケーション・サーバーと関連付けたロード・バランサー・ポリシー (VIP:Port) を作成して、XYZ アプリケーションを Web にアドバータイズします。

記事の残りのセクションでは、上記のシナリオを詳細に説明します。まず始めに、ネットワーク、セキュリティー、およびスケーラビリティーと冗長性の設計から取り上げます。

ネットワーク設計

提案されるネットワーク設計は、多層型アプリケーションをデプロイする場合に共通して使用されているパターンです。このパターンの目的は、各層を実装するコンポーネントのそれぞれを十分に分離し、各コンポーネントを固有のネットワーク接続で構成できるようにすることです。

エンタープライズ・ネットワークは、5 つのエリアに分割します。各エリアがそれぞれに異なるサービスをホストし、異なる接続およびセキュリティー要件を実装します。ルーターおよびファイアウォールの構成により、エリア間での通信はできないようになっています。この 5 つのネットワーク・エリアが表すのは、5 つの異なるバス・サービスです。クライアントが特定のエリアからのサービスを必要とする場合には、そのエリアのバスに vNIC を構成する必要があります。

以下に、5 つのネットワーク・エリアの仕様を説明します。

  • DMZ: このネットワーク・エリアによって、インターネットを内部エンタープライズ・ネットワークから切り離します。ここにはインターネットへのルーティングが組み込まれるため、DMZ に接続可能なクライアントはすべて、インターネットにアクセスすることができます。
  • パブリック (Public) ネットワーク・エリア: このネットワーク・エリアは DMZ にルーティングされてから、インターネットにルーティングされます。DMZ との主な違いは、パブリック・ネットワーク・エリアには TSAM プロジェクトで使用される VLAN/サブネットが組み込まれ、専用のファイアウォールによって TSAM プロジェクトのインターネット・アクセスが制御されることです。この設計には、各 TSAM プロジェクトに専用 VLAN/サブネットを割り当てることが前提となります。
  • プライベート (Private) ネットワーク・エリア: このネットワーク・エリアは DMZ にルーティングされません。プライベート・ネットワーク・エリアは、慎重な扱いが求められる重要なデータにアクセスするためのエリアです。この設計の前提として、プライベート・ネットワーク・エリアにアクセスするすべてのクライアントに共通の 1 つの VLAN/サブネットを構成しなければなりません。したがって、TSAM によってプロビジョニングされ、プライベート・バスへのアクセスを必要とする仮想サーバーは、それぞれに異なるプロジェクトに属しているとしても、この共通サブネットの vNIC を持つことになります。
  • ストレージ (Storage) ネットワーク・エリア: このネットワーク・エリアも、DMZ にはルーティングされません。このエリアでは、ストレージ・サービスにアクセスすることができます。専用ストレージ・ネットワークを設けるのは共通のパターンです。その理由は、ストレージ・リソースへのアクセスおよびストレージ・リソースの使用を制御しやすくなるため、そしてストレージ・ネットワークには特有のパフォーマンス要件があるためです。この設計には、ストレージ・エリアにアクセスするすべてのデータベース・サーバーに共通の VLAN/サブネットを構成することが前提となります。
  • 管理 (Management) ネットワーク・エリア: このネットワーク・エリアは、TSAM が管理可能エンティティーにアクセスするために必要です。つまり、ハイパーバイザー、仮想サーバー、そしてファイアウォール、ロード・バランサーといった機器は、管理ネットワークに接続する必要があります。管理ネットワーク・エリアは、DMZ にはルーティングされません。設計の前提となるのは、いくつかのルーティング可能な VLAN/サブネットでネットワーク・エリアを構成することです。最初の VLAN/サブネットは、すべての静的な機器 (TSAM サーバー、ロード・バランサー、ハイパーバイザー) を構成するためだけに使用し、2 番目の VLAN/サブネットで、プロビジョニングされたすべてのサーバーをホストします。

管理要素を組み込むと、図 3 に示した標準デプロイメント・モデルの全体像が完成します。図 4 に、完成した状態のネットワーク設計を示します。

図 4. 標準化された J2EE アプリケーションをデプロイするための TSAM ソリューションの完全なネットワーク設計
標準化された J2EE アプリケーションをデプロイするための TSAM ソリューションの完全なネットワーク設計

重要な点として、既成のソリューションではネットワーク・リソース (サブネット、VLAN など) を使用して多層型アプリケーションをデプロイおよび構成しますが、これらのネットワーク・リソースのプロビジョニングまでは行いません。ソリューションに代わって、サブネットと VLAN をネットワーク・インフラストラクチャーに事前構成してから TSAM に登録する必要があります。

上記のネットワーク設計は、TSAM で実現可能な唯一のネットワーク設計というわけではありません。例えば、ネットワーク・リソースの動的な割り当ておよび登録を行うカスタム・コードを追加して拡張するという方法で TSAM を利用することもできますが、この記事ではそれについての説明はしません。

表 1 に、各種サブネットワーク間のルーティングを要約します。

表 1. 各種サブネットワーク間でのルーティングの要約
サブネットパブリックプライベート管理ストレージDMZ (インターネット)
パブリック可能不可能不可能不可能可能
プライベート不可能可能不可能不可能不可能
管理不可能不可能可能不可能不可能
ストレージ不可能不可能不可能可能不可能
DMZ (インターネット)可能不可能不可能不可能可能

表 2 に、このソリューションの各コンポーネントに必要なネットワーク・インターフェース (サブネットワークでの IP) を要約します。

表 2. 各コンポーネントに必要なネットワーク・インターフェース
アプリケーション・サーバーデータベース・サーバーTSAMファイアウォールロード・バランサー
パブリック必要不要不要必要必要
プライベート不要必要不要不要不要
管理必要必要必要必要必要
ストレージ必要必要不要不要不要

図 5 に、上記で説明したネットワーク設計を実装する物理構成を示します。

図 5. 物理ネットワーク・レイアウト
物理ネットワーク・レイアウト

セキュリティー設計

ソリューションのセキュリティー設計は主に、Web アプリケーション・サーバーをホストするサブネットを出入りするネットワーク・トラフィックの制御と管理に適用されます。

ネットワーク設計のセクションで、それぞれに異なるサービスが使用可能な「ネットワーク・ドメイン」を表す 5 つのネットワーク・エリアを明らかにしました。この設計の前提として、これらのネットワーク・エリアは互いに通信しません。クライアントがネットワーク・エリアで提供されているサービスにアクセスするには、そのエリア (表 2 に記載した、エリアを表すサブネットワークのいずれかにある IP) に vNIC を接続します。

このセキュリティー要件を満たすには、以下の 2 つの方法があります。

  • ネットワーク・インフラストラクチャーのルーターを、エリア間でのルーティングを行わないように構成します。
  • ファイアウォールを使用して、ルーティング可能なエリア間を強制的に分離します。

実際のネットワーク設計によっては、この 2 つの方法を組み合わせることが最適な選択となることもありますが、ここではファイアウォールを使用して各ネットワーク・エリアを分離することにしました。

ソリューションに定義したセキュリティー要件により、5 つのネットワーク・エリアを、図 6 に示す 5 つの異なるセキュリティー・ゾーンに当てはめることができます。この図は、セキュリティー・ゾーンとネットワーク・エリアとの対応を示すとともに、2 つのゾーン間のトラフィックを制御するためのルールがどのように定義されるのかを明らかにしています。

図 6. 5 つのセキュリティー・ゾーン
5 つのセキュリティー・ゾーン

セキュリティー・ゾーンが定義する境界では、トラフィックがネットワークの別の領域に移る際にポリシー制約が適用されます。具体的に言うと、セキュリティー・ゾーンとは、インバウンド・トラフィックとアウトバウンド・トラフィックをポリシーによって規制する必要のある 1 つ以上のネットワーク・セグメントの集合です。制御を設定する対象は、あるゾーンから別のゾーンに移動するトラフィックであるため、ゾーンは常にペアで機能します。

ソリューションを単純化するために、十分なレベルのセキュリティーを施行する上で DMZ とパブリック・ネットワーク・エリアの間の境界が極めて重要であるという前提にします。また、さまざまな Web アプリケーションの要件を満たせるように、この 2 つのゾーンの間に定義するトラフィック・ルールの構成を簡単かつ頻繁に変更できるようにすることも、ソリューションの単純化に関連してきます。

一方、他のすべてのゾーンについては、たまにしか変更することのない事前定義された一連のトラフィック・ルールを使用して、静的に構成することができると考えました。つまり、静的な手法と動的な手法をそれぞれに最適な場合に使用するということです。このようにすれば、TSAM ファイアウォール拡張機能の制御に従わせるのは、パブリック・ネットワーク・エリアと DMZ のゾーンのペアだけで済むことになります。

この単純化を行わない場合には、他のゾーンのペアも TSAM ファイアウォールの制御に従わせてください。これらのゾーンは、単純化のために特定のゾーンに限定して説明したのと同じステップに従って構成することができます。

スケーラビリティーと冗長性の設計

多層型アプリケーションの一般的な用途は、インターネット・サービスを実装することです。スケーラビリティーと冗長性は、インターネット・サービスをアドバータイズするアプリケーションにとって重要な要件となります。この 2 つを実装するには、広く支持されている何種類かの共通設計パターンがあります。

スケーラビリティーと冗長性を設計する場合、多層型ソリューションには各種のコンポーネントがあります。そのうち最も重要なのは、パーシスタンス層 (主にデータベース) とビジネス・ロジック層 (主にアプリケーション・サーバー上で実行される階層) の 2 つです。

このソリューションでは、ビジネス・ロジック層に焦点を絞ることにします。一般にこの層では、負荷が重い上にパフォーマンス要件の厳しい処理を実行します。

ここでもまた、実際のシナリオで広く使用されている共通パターンを参照します。この共通パターンでは、ロード・バランサーがフロント・エンドとしてアプリケーションからの着信要求を受け入れ、これらの要求をビジネス・ロジック層に転送します。ビジネス・ロジック層は複数のノードによって実装されます。これらのノードのそれぞれが仮想サーバーであり、同じソフトウェア・スタック (アプリケーション・サーバーと特定のアプリケーション・ソフトウェアを含む) を実行します。

インターネット・ユーザーがアクセスするアプリケーションの公開 URL は、ロード・バランサーによってアドバータイズされた 1 つのパブリック IP (VIP) を指す一方、ロード・バランサー自体は、多数の仮想サーバーに要求を分散させることができます。

ロード・バランサー用の TSAM 拡張機能は、スケーラブルで冗長性のある多層型アプリケーションの設計および実装をサポートし、アプリケーションのロード・バランサー層のデプロイメント・タスクを自動化します。このタスクを実現するのは、TSAM UI から作成されたロード・バランサー・ポリシーです。

要件に影響する重要なパラメーターには以下のものがあります。

  • ポリシーに登録するホストのリスト。これは、ロード・バランサーが要求を分散させるために使用する仮想サーバーのリストです。エントリーを追加、削除することで、アプリケーションを停止することなく、このリストを動的に変更することができます。
  • ロード・バランシングに使用するアルゴリズム。これには、ラウンドロビン、ワークロードなどがあります。
  • 確立された接続のパーシスタンス。仮想サーバーとの接続後、このチャネルで通信が継続します。
  • 障害を検出するためのコンポーネントの監視

セットアップ

早速、上記の設計ソリューションを実装するために TSAM プラットフォームとネットワーク拡張機能を構成する手順を説明します。この手順を行う必要があるのは 1 回だけです。手順の説明は、主に拡張機能の構成に重点を置いているので、基本構成についてさらに詳しい情報を得るには、インターネット上にある TSAM のドキュメントを参照してください。

ネットワーク拡張機能、または F5 ロード・バランサーおよび Juniper SRX ファイアウォールの自動化パッケージのいずれかが TSAM 7.2.2 にインストール済みであることを前提として、この構成手順に必要な作業の流れを要約します。

  1. DCM (Data Center Model) ファイルを作成して、プロビジョニングされたサーバーの接続を構成するために使用するネットワーク・リソース (サブネットワーク、VLAN) を含めるようにします。
  2. ネットワーク・リソースを TSAM にインポートします。
  3. TSAM で管理するファイアウォール、ロード・バランサーといった機器を登録するための DCM ファイルを作成します。
  4. ネットワーク機器を TSAM にインポートします。
  5. 意図するネットワークおよび関連するすべてのリソースを記述する TSAM ネットワーク・テンプレートを作成します。
  6. ネットワーク・テンプレートを TSAM にインポートします。
  7. アプリケーション・サーバー・イメージおよびデータベース・サーバー・イメージに対するネットワーク接続を構成します。

DCM (Data Center Model) は、TSAM がリソースを維持管理するためのデータ・モデルとして利用する Tivoli Provisioning Manager コンポーネントです。DCM にデータをインポートするには、リソースを記述する XML ファイルを使用します。次に、これらの DCM ファイルについて詳しく説明します。

ネットワーク・リソース用の DCM ファイル

このファイルには、前に説明した 5 つのネットワーク・エリアを構成する VLAN/サブネットのプールを格納します。ビジネス・アプリケーションをホストする新しい TSAM プロジェクトを作成すると、パブリック VLAN/サブネットのプールから、そのプロジェクトの VLAN/サブネットが確保されます。プロジェクト用の新しいアプリケーション・サーバーが要求された場合には、そのプロジェクトの VLAN の IP アドレスが確保されます。

これは、プライベート VLAN/サブネットの場合でも同じです。プロジェクト用の新しいデータベース・サーバーが要求されると、そのプライベート VLAN/サブネットの IP アドレスが確保されます。

ファイアウォールとロード・バランサー以外のネットワーク機器は、VLAN/サブネットにあらかじめ構成されている必要があります。この記事では TSAM 拡張機能について話題にしているので、これらのネットワーク機器の構成については説明しません。

DCM ネットワーク・リソース・ファイルには 5 つのエリアの定義は含まれません。このファイルは単に、5 つのエリアを構成する VLAN/サブネットのリストを作成するに過ぎません。DCM にはネットワーク設計のビルディング・ブロックを記述できますが、ネットワークの構造はネットワーク・テンプレートに記述します。

記事の「ダウンロード」セクションにある NetworkResources.zip に、ネットワーク・リソースに関する情報が記述された以下のファイルが含まれています。

  • ManagementSubnetworks.xml ファイルは、管理サブネットワークを記述します。デフォルト・ルートを使用して、基本管理ネットワークにトラフィックをルーティングできるようにしています。
  • 管理サブネットワークとは別に、プロジェクトごとに 1 つのパブリック・サブネットワークがあります。計画されたプロジェクトをプロビジョニングするために必要なこれらのリソースも、すべて DCM ファイルに組み込まれます。それを記述するのが、PublicSubnetworks.xml という名前のファイルです。
  • プライベート・サブネットワークとストレージ・サブネットワークは、BaseSubnetworks.xml ファイルの中で定義されます。

DCM ファイルにすべてのネットワーク・リソースが記述されていることを前提に、これらのネットワーク・リソースを TSAM UI から DCM にインポートするには、以下の手順に従います。

  1. 管理者として TPAE UI にログインします。
  2. Cloud Network Administration アプリケーションにアクセスします (パスは「Go To (リンク先)」 > 「Service Automation (サービス・オートメーション)」 > 「Configuration (構成)」です)。
  3. Import DCM Network Objects (DCM ネットワーク・オブジェクトのインポート)」を選択し、VLAN/サブネットワークを記述する DCM ファイルをインポートします。

ネットワーク機器用の DCM ファイル

ロード・バランサーとファイアウォールは、TSAM 拡張機能によって管理されます。その手段となるのは、システムに自動化パッケージ (F5 BIG-IP、Juniper SRX) をインポートすると実装される API です。これらの API を使用できるようにするには、ファイアウォール機器とロード・バランサー機器を DCM に定義し、特定の API のセットにリンクする必要があります。このセクションで言及するすべてのファイルも、NetworkResources.zip に含まれています。具体的には、次の 2 つのファイルです。

  • DCM_F5_BIGIP.xml ファイルには、ソリューションで使用するロード・バランサーの定義が含まれます。前にインポートされた API のセットに CLF5BIGIPLoadBalancer モデルを関連付けるために、このモデルを実装するロード・バランサー機器が宣言されます。注意する点として、このファイルにはロード・バランサー機器の 2 つの定義が含まれます。それは、F5 BIG-IP Automation パッケージに対して内部で処理されるオプションの高可用性構成が必要となるためです。
  • DCM_Juniper_SRX.xml ファイルには、ソリューションで使用するファイアウォールの定義が含まれます。前にインポートされた API のセットに CLJuniperSRXFirewall モデルを関連付けるために、このモデルを実装するファイアウォール機器が宣言されます。

これらの機器をインポートするには、ネットワーク・リソースを登録する場合と同じ手順に従って構成する必要があります。

  1. 管理者として TPAE (Tivoli Process Automation Engine) UI にログインします。
  2. Cloud Network Administration アプリケーションにアクセスします (「Go To (リンク先)」 > 「Service Automation (サービス・オートメーション)」 > 「Configuration (構成)」)。
  3. Import DCM Network Objects (DCM ネットワーク・オブジェクトのインポート)」を選択し、ネットワーク機器を記述する DCM ファイルをインポートします。

ネットワーク・テンプレート

この設計ソリューションは、エンタープライズ・ネットワークの要件に対処するためのものなので、主にサービス・プロバイダーのシナリオ (複数顧客環境) に適用されるマルチテナンシーとしての TSAM 組み込み機能については考慮に入れません。以上の前提を基に、デフォルトとして TSAM に構成されている PMRDPCUST という顧客について検討します。ネットワーク・テンプレートには、設計したエンタープライズ・ネットワークを、このデフォルト顧客に関連付けられたネットワークとして記述します。

ネットワーク・テンプレートには、設計したネットワークの構造を TSAM プラットフォームと拡張機能が使用できるような形で記述し、DCM ファイルに定義されたリソースを組み合わせて、TSAM シナリオをサポートするためのリソース間の関係と連携を明らかにします。設計したソリューションのサンプル・ネットワーク構成は、NetworkConfiguration.xml ファイルに記載されています。

図 7 に、ネットワーク・テンプレートの階層構造 (つまり、ネットワーク構成) を示します。この図に記載されているのは、ソリューションのネットワーク設計に関連する要素のみです。

図 7. ネットワーク・テンプレートの階層構造 (ネットワーク構成)
ネットワーク・テンプレートの階層構造 (ネットワーク構成)

ネットワーク構成 (NetworkConfiguration) は、ネットワーク・セグメント (NetworkSegment) のリストと、Any セクション (汎用 XML エンティティー) のリストからなります。ネットワーク・セグメント (NetworkSegment) セクションには、仮想サーバーのネットワーク・インターフェースごとのすべてのネットワーク関連の構成が含まれます。このネットワーク・セグメント (NetworkSegment) に記述されるのは、同じファイアウォール (Firewall) やロード・バランサー (LoadBalancer) によって施行されるセキュリティーやロード・バランシングなどの共通要件を持つネットワークの部分です。

この設計ソリューションのネットワーク・テンプレートには、それぞれに異なるネットワーク・エリア (管理ネットワーク、パブリック・ネットワーク、ストレージ・ネットワーク、およびプライベート・ネットワークの各エリア) を記述する 4 つのネットワーク・セグメントが組み込まれることになります。

Any セクションには、拡張機能 (上図では緑色の要素) に固有のデータが含まれます。これらのデータは、ファイアウォール (Firewall) やロード・バランサー (LoadBalancer) といった機器の一般構成に関するものです。ネットワーク構成にロード・バランサー (LoadBalancer) やファイアウォール (Firewall) といったタイプの機器を追加で定義して、複雑なネットワーク・デプロイメントを表すこともできます。さらに、各ネットワーク・セグメントを管理するために、それぞれに専用のファイアウォール (Firewall) とロード・バランサー (LoadBalancer) を 1 台ずつ用意することも可能です。その場合には、テンプレートのゲートウェイ (Gateway) 要素を使って機器を表します。

ネットワーク・セグメント (NetworkSegment) に定義されたサブネットワーク (SubNet) 要素のリストは、そのネットワーク・セグメント (NetworkSegment) が実装するネットワーク・エリアを構成するサブネットワーク (SubNet) のプールを表します (例えば、プロビジョニングされた TSAM プロジェクトに関連付けられるパブリック・サブネットワークのプール)。

ネットワーク・セグメント (NetworkSegment) に含まれるファイアウォール (Firewall) セクションが記述するのは、そのセグメントに属するサブネットワーク (SubNet) でネットワーク・トラフィックを制御するために使用する、管理対象ファイアウォールの構成です。このセクションには以下の構成要素があります。

  • インターフェース (Interface) 要素: プロビジョニングされたプロジェクトの VLAN/サブネットワークに接続するための機器のインターフェースを表します。
  • セキュリティー・ポリシー (SecurityPolicy) 要素: プロビジョニングされたプロジェクトの VLAN/サブネットワークに適用するトラフィック・ルールの構成を表します。

図 8 に示す NetworkConfiguration.xml ファイルからの抜粋は、パブリック・ゾーンと「untrusted (信頼されない)」(DMZ) ゾーンの間でのデフォルト・ファイアウォール・ルールの定義を記述している部分です (このルールは、インバウンド・トラフィックとアウトバウンド・トラフィックの両方に適用されます)。この特定の構成では、ポート 80 および 443 (HTTP、HTTPS) でのみトラフィックが許可されます。

図 8. パブリック・ゾーンと DMZ ゾーンの間でのデフォルト・ファイアウォール・ルールの定義
パブリック・ゾーンと DMZ ゾーンの間でのデフォルト・ファイアウォール・ルールの定義

ネットワーク・テンプレートをインポートする方法は以下のとおりです。

  1. 管理者として TPAE UI にログインします。
  2. Cloud Network Administration アプリケーションにアクセスします (「Go To (リンク先)」 > 「Service Automation (サービス・オートメーション)」 > 「Configuration (構成)」)。
  3. Import Network Template xml (ネットワーク・テンプレート XML のインポート」を選択し、ネットワーク・テンプレートを記述する XML ファイルをインポートします。
  4. インポートされたテンプレートを選択し、「Status of this Network Configuration (このネットワーク構成のステータス)」属性を「ACTIVE (アクティブ)」に変更します。

ネットワーク・テンプレートをインポートした後、そのテンプレートから、エンタープライズ・ネットワークを表すインスタンスを作成する必要があります。それには、以下のようにしてテンプレートをデフォルト顧客 PMRDPCUST に割り当てます。

  • TSAM の操作を開始するには、PMRDPCUST を有効にしなければなりません。その後、クラウド管理者として TSAM セルフサービス UI にログインします。
  • Create Customer (顧客の作成)」オファリングを選択して、デフォルト顧客を有効にします。
  • インポートされたネットワーク・テンプレートを、デフォルト顧客のネットワーク構成として割り当てます。
  • 要求を送信します。

プロビジョニング

このセクションでは、XYZ Web アプリケーションのプロビジョング手順を詳しく説明します。この手順は、顧客である ABC が新しい Web アプリケーションをクライアントに配信する必要があるたびに行う必要があります。

ステップ 1: ネットワークに接続するための仮想イメージを構成する

標準化された新しい Web アプリケーションを配信する際に行う最初のステップは、シナリオに関するセクションで説明したように、仮想イメージを TSAM に登録することです。登録するには、TSAM の「Register Image (イメージの登録)」サービス・オファリングを使用します。仮想イメージを登録する上で最も重要な側面は、ネットワーク・インターフェースを正しくセットアップすることです。したがって、このセクションではその具体的なプロセスに説明を絞ります。全体的なタスクについては、TSAM のドキュメントを参照してください。

仮想イメージの登録を担当するクラウド管理者が行わなければならない作業は、ネットワーク設計 (図 4) に従って、仮想イメージからプロビジョニングする仮想サーバー上で構成する vNIC の数とタイプを定義することです。この定義に従って、仮想サーバーの要求側は vNIC を構成しなければならないネットワーク・セグメントを適切に選択します。この作業は、定義されている vNIC ごとに行います。

TSAM では、クラウド管理者がネットワーク・セグメントをクラスに分類し、仮想イメージの登録時にセグメントのクラスを vNIC に関連付けることで、クラウドを要求する側のジョブを単純化できるようになっています。このような関連付けが行われていれば、クラウドを要求する側が適切なネットワーク・セグメントを選択できるため、エラーが発生しにくくなります。

TSAM が定義するネットワーク・セグメントのタイプには、管理 (Management)、ストレージ (Storage)、顧客 (Customer)、バックアップおよびリストア (Backup&Restore) の 4 つがあります。ネットワーク構成に含める各ネットワーク・セグメントは、この 4 つのいずれかのタイプに分類する必要があります。

この 4 つのタイプに加え、TSAM で「用途 (usage)」と呼ぶフィルターを使って、さらにネットワーク・セグメントを分類することができます。用途とは、通常は拡張機能が何らかの方法で管理するネットワーク・セグメントのなかから特定のネットワーク・セグメントに絞り込むために定義されているフィルターです。ネットワーク・セグメントには、1 つ以上の用途を設定することができます。ファイアウォールの拡張機能とロード・バランサーの拡張機能が定義している要素は、それぞれ firewall_extensionloadbalancer_extension です。

この記事で提案するネットワーク・テンプレートに定義されたネットワーク・セグメントには、表 3 で説明するタイプおよび用途が指定されます。

表 3. ネットワーク・セグメントに指定されたタイプおよび用途
名前タイプ用途
パブリック・ネットワーク顧客firewall_extension
loadbalancer_extension
プライベート・ネットワーク顧客
管理ネットワーク管理
ストレージ・ネットワークストレージ

拡張機能によって管理されるのは、パブリック・ネットワーク・セグメントだけであることに注目してください。パブリック・ネットワーク・セグメントでは、ファイアウォール拡張機能が DMZ に関するルールを構成し、ロード・バランサー拡張機能がこのセグメントの VIP を確保します。データベース・サーバーが常駐するプライベート・ネットワークは、拡張機能の管理対象ではありません。

クラウド管理者がこのネットワーク設計と一致する仮想イメージを構成するには、表 4 の説明に従う必要があります。

表 4. ネットワーク設計と一致する仮想イメージの構成
タイプアプリケーション・サーバー・イメージでの vNIC の構成データベース・サーバー・イメージでの vNIC の構成
顧客firewall_extension
loadbalancer_extension
顧客
管理
ストレージ

アプリケーション・サーバー・イメージを例に取ると、このような仮想サーバーを要求する側は、3 つの vNIC を構成する必要があります。つまり、「管理」タイプの 1 つの vNIC と、「顧客」タイプの 2 つの vNIC です。

TSAM は選択可能なネットワーク・セグメントとして、これらの vNIC に関連付けられたタイプと用途と一致するネットワーク・セグメントだけを提示するため、要求側は最初のネットワーク・インターフェースには管理ネットワーク・セグメントを、2 番目のネットワーク・インターフェースにはパブリック・ネットワーク・セグメントを選択するしかありません。そして、最後のネットワーク・インターフェースには、選択肢としてパブリック・ネットワーク・セグメントとプライベート・ネットワーク・セグメントが提示されます。この 2 つが提示される理由は、最後の vNIC は顧客タイプとしてタグが付けられていて、パブリック・ネットワーク・セグメントとプライベート・ネットワーク・セグメントは両方ともこのタイプに該当するためです。したがって、最後のインターフェースについては、要求側がプライベート・ネットワークを選択して、データベース・サーバーとの接続を有効にする必要があります。

ステップ 2: TSAM プロジェクトを作成して、データベース・サーバーをプロビジョニングする

このタスクでは、Web アプリケーションをホストする TSAM プロジェクトを作成して、この Web アプリケーションのネットワーク・トラフィックを管理するファイアウォールを構成し、データベース・サーバーをプロビジョニングします。このタスクを完了するには、以下の手順に従います。

  • 管理者 (クラウド管理者または顧客/テナント管理者) としてセルフサービス UI にログインします。
  • Create Project with VMware Servers (VMware サーバーでのプロジェクトの作成)」オファリング (TSAM でサポートされるすべてのタイプのサーバーを選択することができます) を選択します。
  • 「Project Details (プロジェクト詳細)」ペインで、プロジェクトの名前 (例えば、「Reimbursement expenses」)、このプロジェクトにアクセスするチーム、アプリケーションを表すこのプロジェクトの有効期限を指定します。
  • 「Requested Image (要求イメージ)」ペインで、アプリケーションのデータベース・サーバーのプロビジョニングと登録イメージに使用するリソース・グループを指定します。1 つのサーバーのみをプロビジョングするように選択します。
  • 「Server Details (サーバー詳細)」ペインで、データベースのパフォーマンス要件をサポートするサーバー・リソースを指定します。
  • データベース・イメージでミドルウェアがどのようにデプロイされ、構成されているかによっては、「Additional Software (追加ソフトウェア)」ペインに入力パラメーターを指定してから次のペインに進まなければならないこともあります。
  • 「Network Configuration (ネットワーク構成)」ペインで、データベース・サーバーに対して指定されたネットワーク接続要件を解決します。図 9 に示されているように、3 種類の vNIC が、それぞれに関連するネットワーク・セグメントを指定する適切なネットワーク・エリアにバインドされています。
    図 9. 適切なネットワーク・エリアにバインドされた vNIC
    適切なネットワーク・エリアにバインドされた vNIC
  • Network Advanced (ネットワーク拡張)」ペイン (図 10) では、プロジェクトにプロビジョニングされることが見込まれる仮想サーバーの数を指定します。この情報を使用して、「Public network (パブリック・ネットワーク)」プールからプロジェクトのために確保するサブネットのサイズが選択されます。
    図 10. プロビジョニングされることが見込まれる仮想サーバーの数
    プロビジョニングされることが見込まれる仮想サーバーの数
  • Enable Load Balancing (ロード・バランシングを有効にする)」チェック・ボックスにチェック・マークを入れてから、後でアプリケーションをアドバータイズするロード・バランサー・ポリシーを作成するために 1 つの VIP を確保するように指定します。
  • 要求を送信します。

ステップ 3: アプリケーション・サーバーをプロビジョニングする

このタスクでは、データベースと対話するビジネス・ロジック層を追加するために必要なアプリケーション・サーバーをデプロイします。アプリケーション・サーバーは、データベースをホストするプロジェクトと同じプロジェクトにデプロイされます。

このタスクを実現する方法は以下のとおりです。

  1. 管理者 (クラウド管理者または顧客/テナント管理者) としてセルフサービス UI にログインします。
  2. Add VMware servers (VMware サーバーの追加)」オファリングを選択します。
  3. 前のステップで作成したプロジェクト (「Reimbursement expenses」) を選択します。
  4. 「Requested Image (要求イメージ)」ペインで、アプリケーションで使用されるアプリケーション・サーバーのプロビジョニングと登録イメージに使用するリソース・グループを指定します。予測できるアプリケーションの要求に対応するために必要な初期サーバー数をプロビジョニングするように選択します (この例では 3 つのサーバーをプロビジョニングしました)。
  5. 「Server Details (サーバー詳細)」ペインで、アプリケーション・サーバーのパフォーマンス要件をサポートするためのサーバー・リソースを指定します。
  6. データベース・イメージでミドルウェアがどのようにデプロイされ、構成されているかによっては、「Additional Software (追加ソフトウェア)」ペインに入力パラメーターを指定してから次のペインに進まなければならないこともあります。
  7. 「Network Configuration (ネットワーク構成)」ペインで、アプリケーション・サーバーに対して指定されたネットワーク接続要件を解決します。図 11 に示されているように、4 種類の vNIC が、それぞれに関連するネットワーク・セグメントを指定する適切なネットワーク・エリアにバインドされています。
    図 11. 適切なネットワーク・エリアにバインドされた vNIC
    適切なネットワーク・エリアにバインドされた vNIC
  8. 要求を送信します。

ステップ 4: アプリケーションをアドバータイズするためのロード・バランサー・ポリシーを作成する

このタスクでは、確保された仮想 IP にロード・バランサー・ポリシーを作成して、Webアプリケーションの HTTP サーバー層とロード・バランシング層をデプロイします。このタスクを実現するには、以下の手順に従ってください。

  1. 管理者 (クラウド管理者または顧客/テナント管理者) としてセルフサービス UI にログインします。
  2. Create Load Balancer Policy (ロード・バランサー・ポリシーの作成)」オファリング (図 12) を選択します。
    図 12. ロード・バランサー・ポリシーの作成
    ロード・バランサー・ポリシーの作成
  3. 最初のペインで、前のステップで作成したプロジェクト (「Reimbursement expenses」) を選択してから、「Next (次へ)」をクリックします。
  4. 「Main Settings (主要設定)」ペインで、ポリシーの構成情報を入力します。
    1. 意味のあるポリシー名を指定します。
    2. 確保された仮想 IP のリストから、仮想 IP を選択します (この例では、1 つの IP だけが確保されています)。
    3. ポリシーのパフォーマンス・パラメーター (サーバー・タイプ、接続プール、セッション・パーシスタンスなど) のクラスを選択します。
    4. 最後に、正常性の監視パラメーターを定義します。
  5. ポリシーのロード・バランシングに含める仮想サーバーのリストを選択します。仮想サーバーごとに、Web アプリケーションをアドバータイズするポリシーで使用されるポートとは異なるポートを指定することができます。
  6. 要求を送信します。

図 13 に示すような応答が表示されます。これは、Web アプリケーションのロード・バランシングのためにポリシーに含められた仮想サーバーのリストです。

図 13. Web アプリケーションのロード・バランシングのためにポリシーに含められた仮想サーバーのリスト
Web アプリケーションのロード・バランシングのためにポリシーに含められた仮想サーバーのリスト

まとめ

Juniper SRX ファイアウォールと BIG-IP F5 ロード・バランサーの TSAM 拡張機能を使用して TSAM 7.2.2 に複雑なトポロジーをデプロイすることにより、セキュリティー、スケーラビリティー、冗長性の目標を達成することができます。ネットワーク構成を設計して、ビジネス・アプリケーションのトポロジーを標準化した後は、これらのアプリケーションをわずかなステップで迅速にクライアントにアドバータイズすることができます。

ビジネス・アプリケーションのライフサイクルを管理する方法について、以下の側面 (およびその他の側面) を詳しく説明している関連記事を調べてください。

  • ワークロードの増加に応じたサーバーの追加
  • ロード・バランサーのポリシー調整
  • ファイアウォール・ルールの変更

ダウンロード

内容ファイル名サイズ
Sample files for this articleNetworkResources.zip6KB

参考文献

学ぶために

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

議論するために

コメント

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=794213
ArticleTitle=TSAM 拡張機能を使用して J2EE アプリケーションをデプロイする
publish-date=02232012