はじめに

通常のアプリケーション・サーバー環境では、拡張性を考えて、サーバーをクラスター化するのが一般的です。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 では、WebサーバーとWebSphere Application Serverの両方がマシンAに置かれ、Database ServerはマシンBに置かれています。この構成の場合、マシンAは、アプリケーション・サーバーの複数のクローンを処理できるだけの能力を備えている必要があります。図中のHTTPプラグインは、セッションを追跡しつつ、アプリケーション・サーバーのクローンと交信したり、クローンに制御を渡すことができます。

垂直方向の規模拡張は手法として可能ではありますが、同じマシンでクローンを多数扱えるようにするには、性能の高いマシンが必要です。規模拡張を行う場合のもっと信頼性の高い堅固な解決策は、水平方向の規模拡張モデルです。

上に戻る

水平方向の規模拡張

水平方向の規模拡張モデルは、物理資源にしたがって規模拡張を柔軟に行うことが可能な、さらに都合のよい構成です。この構成にする場合、まずサーバー・グループのクローンを作成します。そして、さらにクローンを作成し、いろいろなマシンにそれらのクローンを配備することで、信頼性や規模拡張を実現することができます。垂直方向の規模拡張と比較した場合、水平方向の規模拡張では、1台のマシンの性能に制約されることはありません。(いろいろなマシンに配備されている) クローンが完全に使用し尽くされている場合、マシンを追加することで、この問題の解消を図ることができます。以下の表2は、4台のマシンにインストールされるいろいろなコンポーネントを示したものです。その構成を示したのが図2 です。

図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 です。

上に戻る

DB2WASマシンにDB2とWebSphere Application Serverをインストールする

以下のリンクには、この拡張作業の順をおっての詳細な手順が示されています。

1. IBM DB2 UDB v 7.2.1 EEをインストールする
2. IBM DB2 UDB v 7.2.1 EEを構成する
3. WebSphere Administrative Databaseをセットアップする
4. FixPak 3を、WAS 4およびDB2のパッチも含めてインストールする
5. WebSphere Application Server 4.0をインストールする

DB2WASマシンが稼働するようになったら、次にHTTPWASマシンをセットアップします。

上に戻る

HTTPWASマシンにDB2 ClientとWebSphere Application Serverをインストールする

1. DB2クライアントをインストールする
2. DB2クライアントが正しくインストールされているか確認する
3. リモートの管理データベースへのアクセスをセットアップする
4. FixPak 3を、WAS 4およびDB2のパッチも含めてインストールする
5. WebSphere Application Server 4.0をインストールする

参考文献

• DragonSlayerたちの物語の前回までの記事。
  
  
• WebSphereの拡張容易性に関するレッド・ブック WLM and Clustering Using WebSphere Application Server, Advanced Editionには、WebSphere Application Serverでアプリケーションを規模拡張するための技法が紹介されています。
  
  
• developerWorksのWebSphere (US) (日本語サイト) のHigh Volume Web Sites Zoneには、ボリュームの大きなWebサイトでe-businessソリューションを計画、設計、構築する際に参考となる文献がいろいろと紹介されています。
  
  

著者について

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テクノロジストです。

この記事を評価する

コメント

上に戻る

目次

• はじめに
• Go-ForItプロジェクト
• クラスター化の用語
• 垂直方向の規模拡張
• 水平方向の規模拡張
• 必要条件
• DB2WASマシンにDB2とWebSphere Application Serverをインストールする
• HTTPWASマシンにDB2 ClientとWebSphere Application Serverをインストールする
• 参考文献
• 著者について
• コメント