レベル: 中級 Rohit Sahasrabudhe, e-business Architect, IBM, Software Group
Balu Ramachandran, e-business Architect, IBM, Software Group
2002年 5月 28日 このDragonSlayテクニカル・コンサルティンング・チームについての連載第18回目では、Rohit SahasrabudheとBalu Ramachandranが、クラスター環境にGo-ForItを配備する方法を解説します。GoForItプロジェクトは、すでに、ある程度の期間稼働してきていますが、実動段階になると、クラスター化することが重要な意味をもつようになります。本稿では、クラスター化によって何が違ってくるのか、およびクラスター化をうまく利用する方法について紹介します。Go-ForItにクラスター化機能を追加することで、このプロジェクトは大規模化しやすくなり、カスタマーの使用可能度も高まります。また、本稿では、数々の細かな手順を紹介するとともに、アプリケーションをバンドルし、WebSphere Application Server 4.0を使ってクラスター化された環境にそのアプリケーションを配備する方法を説明します。
はじめに
通常のアプリケーション・サーバー環境では、拡張性を考えて、サーバーをクラスター化するのが一般的です。WebSphere Application Server V4.0でクラスター化を実現するのは、非常に簡単です。クラスター化を行うと、Webアプリケーションを実行するために必要なすべてのデータが中央に保存されるようになります。この中央部分がクラスター内のすべての関係者からアクセスできるようになった時点で、われわれは、クラスター化の目標を達成できたことになります。クラスター化には、主に2つの方法があります。垂直方向の規模拡張 と水平方向の規模拡張です。今回の記事では、規模拡張の選択肢を紹介し、それがWebSphere Application Serverとどのように関係してくるのかを検討します。
Go-ForItプロジェクト
Go-ForIt.com プロジェクトは、論理的な3層のアーキテクチャーとして構築されるe-businessアプリケーションです。このアプリケーションは、Enterprise JavaBeans (EJB) コンポーネント、JavaBeans、サーブレットなどからなっています。われわれは、Webサーバー (IBM HTTP Server)、WebSphere Application Server、およびDB2 UDBからなる1個のノード上にGo-ForItを配備することから始めました。カスタマーからの要求が増えるとともに、アプリケーションの信頼性を維持するために、われわれは、水平方向の規模拡張によって、クラスター化を実現しました。
アプリケーションのさまざまなコンポーネントは、1個のアプリケーション・サーバー・プロセスに配備されました。われわれは、1個のサーバー・グループを作成し、このサーバー・グループから5個のクローンを作成しました。そして、各ノードに2個のクローンをインストールしました。クラスターに関係したすべてのノードが、1個のWebSphereドメイン・クラスターに属します。複数のマシンにクローンを配備することで、信頼性が実現されました。クローンを作成しつつ、カスタマーによって設定されるセッションを処理する必要があることから、直ちに、そのような状況でセッションの持続性はどのように処理すればよいのかという疑問が生じてきます。WebSphere Application Serverのセッション・マネージャー機能を利用すれば、すべてのセッションが1個のデータベースに保存されるように指定することができます。このようにしておけば、あるクローンがサービスを停止したとしても、カスタマーの要求に対してサービスを提供できる別のクローンが、共通のデータベース・リポジトリーにアクセスすることで、カスタマーによって設定されていたセッションを続行できることになります。
クラスター化の用語
-
HTTPサーバーとプラグイン
- WebSphere Application Serverは、HTTPサーバーすなわちWebサーバーと連携して、Webアプリケーションからの、サーブレットなどの動的なコンテンツに対する要求を処理します。(本稿では、HTTPサーバーとWebサーバーの2つの用語をまったく同じ意味で使用します。) HTTPサーバーとアプリケーション・サーバーは、HTTPサーバー用のWebSphere HTTPプラグインを使用して交信を行います。HTTPプラグインは、可読性の高いXML構成ファイルを使って、要求をWebサーバーで処理するのか、アプリケーション・サーバーで処理するのかを判断します。HTTPプラグインは、アプリケーション・サーバーとの交信に、標準のHTTPプロトコルを使用します。必要なら、安全なHTTPSを使用するように設定することもできます。このHTTPプラグインは、IBM HTTP Server、Apache、Microsoft IIS、Netscape iPlanetなど、一般的なWebサーバーで利用できます。
-
サーバー・グループ
- サーバー・グループとは、アプリケーション・サーバーおよびそのコンテンツとほぼ同じ内容のコピーを作成するときに使用されるテンプレートのことです。アプリケーション・サーバーを表す論理的な概念です。
-
クローン
- クローン作成 (cloning) とは、既存の完全に構成されたサーバーを基にサーバー・グループを作成する処理のことです。そのようなコピーのことをクローンと呼びます。クローンは、その作成の元となったサーバー・グループと、すべての点で同じものです。サーバー・グループと異なり、サーバー・グループを元に作成されたクローンは、具体的な物理的なノード上で実行される具体的なアプリケーション・サーバー・プロセスを表します。
垂直方向の規模拡張
一番単純な構成としては、同じマシンにアプリケーション・サーバーの多数のクローンを設け、同時にそのマシンでHTTPサーバー・プロセスを実行することが考えられます。その場合、通常、まずアプリケーション・サーバー・プロセスを基にサーバー・グループを定義します。次に、そのサーバー・グループのクローンを1個作成し、アプリケーション・サーバーとWebサーバーのインストールされているその同じマシンに、そのクローンを配備します。ユーザーからの要求が増えたときは、クローンを追加、配備することで対処できます。これらのクローンは、すべて同じサーバーに配備されます。どれだけのクローンを追加できるかは、その1台のマシンの性能に依ります。ある一定のクローン数でCPUを占有し尽くしてしまう場合、クローンを追加しても垂直方向の規模拡張では問題を解消できなくなります。以下の表1は、2台のマシンにインストールされるいろいろなコンポーネントを示したものです。その構成を示したのが図1 です。
表1. 垂直方向の規模拡張のコンポーネント
|
マシンA
|
マシンB
| | HTTPサーバー | DB2 Server 7.2 | | WebSphere HTTPプラグイン | | | WebSphere Application Server | | | DB2クライアント | |
図1. クローンによる垂直方向の規模拡張
図1 では、WebサーバーとWebSphere Application Serverの両方がマシンAに置かれ、Database ServerはマシンBに置かれています。この構成の場合、マシンAは、アプリケーション・サーバーの複数のクローンを処理できるだけの能力を備えている必要があります。図中のHTTPプラグインは、セッションを追跡しつつ、アプリケーション・サーバーのクローンと交信したり、クローンに制御を渡すことができます。
垂直方向の規模拡張は手法として可能ではありますが、同じマシンでクローンを多数扱えるようにするには、性能の高いマシンが必要です。規模拡張を行う場合のもっと信頼性の高い堅固な解決策は、水平方向の規模拡張モデルです。
水平方向の規模拡張
水平方向の規模拡張モデルは、物理資源にしたがって規模拡張を柔軟に行うことが可能な、さらに都合のよい構成です。この構成にする場合、まずサーバー・グループのクローンを作成します。そして、さらにクローンを作成し、いろいろなマシンにそれらのクローンを配備することで、信頼性や規模拡張を実現することができます。垂直方向の規模拡張と比較した場合、水平方向の規模拡張では、1台のマシンの性能に制約されることはありません。(いろいろなマシンに配備されている) クローンが完全に使用し尽くされている場合、マシンを追加することで、この問題の解消を図ることができます。以下の表2は、4台のマシンにインストールされるいろいろなコンポーネントを示したものです。その構成を示したのが図2 です。
表2. 水平方向の規模拡張のコンポーネント
|
マシンA
|
マシンB
|
マシンC
|
マシンD
| | WebSphere HTTPプラグイン | WebSphere HTTPプラグイン | WebSphere HTTPプラグイン | | | HTTPサーバー | HTTPサーバー | HTTPサーバー | DB2 7.2 | | WebSphere Application Server 4.0 | WebSphere Application Server 4.0 | | | DB2クライアント | DB2クライアント | |
図2. 1台のマシンに複数のアプリケーション・サーバーを配備しての水平方向の規模拡張
図2 の構成の場合、マシンAでは、HTTP Serverおよびアプリケーション・サーバーとの交信に必要なプラグインが実行されます。マシンBとマシンCは同じ構成で、いずれも、複数のアプリケーション・サーバーを、それぞれのクローンで実行します。さらに、DB2 Clientを介して、マシンD上のDatabase Serverとも交信を行うことができます。
本稿では、図2 の水平方向の規模拡張モデルに話を絞ることにします。この図では4台のマシンが使用されることになっていますが、以下の例では、説明の都合上、2台のマシンを使用することを考えます。実動環境では、4台のマシンを使用するモデルを検討したほうがよいでしょう。以下、本稿では、このマシン2台のモデルで各マシンにコンポーネントをインストールし、構成するときの、順を追っての詳細な手順説明へのリンクを掲げることにします。
必要条件
インストール作業を開始するには、まず、以下のようなハードウェアおよびソフトウェアの要求仕様を備えた2台のマシンを用意する必要があります。
- Pentium III、800 MHz
- 10 GBのハード・ディスク
- 512 MB RAM
- Windows 2000、Service Pack 2を含む
われわれの場合、ネットワークの問題が起こらないようにするために、プライベートなネットワーク・アドレスを使用して単純なネットワークを構成しました。そのようなIPアドレスによる単純な構成を示したのが、以下の図3 です。
図3. 2台のマシンによる水平方向の規模拡張
DB2WASマシンにDB2とWebSphere Application Serverをインストールする
以下のリンクには、この拡張作業の順をおっての詳細な手順が示されています。
-
IBM DB2 UDB v 7.2.1 EEをインストールする
-
IBM DB2 UDB v 7.2.1 EEを構成する
-
WebSphere Administrative Databaseをセットアップする
-
FixPak 3を、WAS 4およびDB2のパッチも含めてインストールする
-
WebSphere Application Server 4.0をインストールする
DB2WASマシンが稼働するようになったら、次にHTTPWASマシンをセットアップします。
HTTPWASマシンにDB2 ClientとWebSphere Application Serverをインストールする
-
DB2クライアントをインストールする
-
DB2クライアントが正しくインストールされているか確認する
-
リモートの管理データベースへのアクセスをセットアップする
-
FixPak 3を、WAS 4およびDB2のパッチも含めてインストールする
-
WebSphere Application Server 4.0をインストールする
参考文献
著者について  | | | Rohit Sahasrabudheは、米国テキサス州オースチンにあるIBM Developer Relations Technical Consulting勤務のe-businessアーキテクトです。Rohitは、IBM認定のe-businessソリューション・デザイナー、ソリューション・テクノロジスト、およびRed Hat認定エンジニアです。Louisville大学で、数学およびコンピューター・サイエンス専攻の工学のBS (理学士号) を取得しています。2000年にIBMに入社するまでに、ドイツでのものも含めて3回の協力スタッフの経験があります。ソフトウェア・エンジニアとしてIBMに入社し、Lotus Domino Solutions部門に勤務しています。氏は、つねに自身のWebSphere技能の向上に努め、技術相談や講習会の講師として世界中を旅したいと考えています。 |
| 
| | Baluは、米国テキサス州オースチンにあるIBM Developer Relations Technical Consulting勤務のe-businessアーキテクトで、独立系ソフトウェア・ベンダー (ISV) 向けに教育、補助、相談を行っています。氏は、認定Javaプログラマー、認定WebSphereスペシャリスト、認定e-businessテクノロジストです。 |
記事の評価
| 
