スーパー・クラスターで解決する: 第 2 回 WebSphere DMZ Secure Proxy Server、ODR、および WebSphere eXtreme Scale による最高のスケーラビリティー

ほとんどのエンタープライズ・ソフトウェア・トポロジーにおいて、アプリケーションのスケーラビリティーは重要なサービス品質なので、エンタープライズ品質の Java™ EE アプリケーションは、通常は IBM® WebSphere® Application Server Network Deployment クラスターにデプロイされて実行されます。しかし、実用的なクラスターのサイズには限界があります。この限界は、非常に高いアプリケーション・スケーラビリティーを実現するための有用なテクニックである、「スーパー・クラスター」を使用して乗り越えることができます。この 2 部構成の記事の第 1 回では、スーパー・クラスターを定義し、HTTP プラグインと IBM WebSphere Proxy Server で使用する方法を調べました。この記事 (第 2 回) では、第 1 回での議論を発展させて、IBM WebSphere DMZ Secure Proxy Server V7、IBM WebSphere Virtual Enterprise のオンデマンド・ルーター、および IBM WebSphere eXtreme Scale も含めて議論します。この記事の内容は IBM WebSphere 開発者向け技術ジャーナルから引用したものです。

Kevin Kepros, Advisory Software Engineer, IBM

Kevin Kepros は、ミネソタ州ロチェスターにある IBM Software Development Lab の advisory software engineer です。彼は WebSphere High Availability Manager コンポーネントの開発リーダーであり、WebSphere Clustering 開発チームのメンバーです。



Dr. Debasish Banerjee, WebSphere Consultant, IBM

Dr. Debasish Banerjee は、現在 IBM Software Services の WebSphere コンサルタントです。彼は WebSphere internationalization architect として自身の WebSphere キャリアを開始しました。高速トランザクション処理、分散キャッシュ、エラスティック・コンピューティング、およびクラウド・コンピューティングが現在の関心領域です。Debasish は、コンビネータベースの関数型プログラミング言語の分野で博士号を取得しました。



2009年 7月 22日

はじめに

第 1 回の議論では、ほとんどのアプリケーションのスケーラビリティーの問題は、IBM WebSphere Application Server クラスターを使用することで対応できるという結論になりました。アプリケーションのスケーラビリティー要件が、1 つの WebSphere Application Server クラスターで処理できる能力を上回ることはほとんどありません。しかし、そういう事も起こりえます。このようなシナリオにおいて、暗黙的なクラスターのサイズの制限を超えるために使用できるテクニックの 1 つが、図 1 に示す階層型クラスター、つまり「スーパー・クラスター」を定義することです。

図 1. 階層型のスーパー・クラスター
階層型のスーパー・クラスター

スーパー・クラスタリングの本質は以下のとおりです。

  • アプリケーションを複数のクラスター (クラスターのクラスター) にデプロイします。
  • 適切なルーターを使用してクライアント要求を配信します。これにより、クライアントから見ると、2 階層の階層型クラスターが従来どおりの 1 階層のフラットな WebSphere Application Server クラスターのように見えます。

クライアント要求の配信に使用するルーターの種類は、スーパー・クラスターの使用と、それに関連する制限に直接影響します。第 1 回では、スーパー・クラスター・トポロジーにおいて HTTP プラグインまたは WebSphere Proxy Server、あるいは両方を組み合わせて使用する方法について説明しました。第 2 回では、第 1 回での議論を継続、発展させて IBM WebSphere DMZ Secure Proxy Server V7、IBM WebSphere Virtual Enterprise のオンデマンド・ルーター (ODR)、および IBM WebSphere eXtreme Scale を含めて説明します。


WebSphere DMZ Secure Proxy Server を使用する

セキュリティー上の理由から、DMZ (非武装地帯) の中にプロキシー・サーバーを配置したくない場合があります。第 1 回では、この問題に対処する 1 つの方法として、図 2 に示すように HTTP プラグイン (DMZ 内) と WebSphere Proxy Server (プロトコル・ファイアウォールの内側) の両方を使用したルーティングの実施を説明しました。

図 2. プロキシー・サーバーにルーティングする DMZ 内の Web サーバー
プロキシー・サーバーにルーティングする DMZ 内の Web サーバー

もう 1 つのオプションは、図 3 に示すように WebSphere DMZ Secure Proxy Server V7 を使用することです。

図 3. WebSphere DMZ Secure Proxy Server
WebSphere DMZ Secure Proxy Server

WebSphere DMZ Secure Proxy Server V7 は、WebSphere Application Server Network Deployment の一部として組み込まれています。WebSphere DMZ Secure Proxy Server は別個にインストールされ、DMZ 内にプロキシー・サーバーをインストールして実行する手段を提供します。

DMZ 内に配置されたマシンに WebSphere DMZ Secure Proxy Server をインストールした後、セキュア・プロキシー・プロファイルを作成します。結果的にできあがるトポロジーは、アプリケーション・サーバー・クラスターが含まれるバックエンド・セルとは異なる新しいセルになります。セキュア・プロキシー・サーバーは Web コンテナーを持たないので、管理コンソールをホストできません。したがって、WebSphere DMZ Secure Proxy Server で管理タスクを構成または実行する必要がある場合は、以下のいずれかのオプションを使用して行います。

  • スクリプト (GUI なし): コマンドラインからスクリプトによってサーバーを管理します。
  • 管理エージェント: DMZ で実行する管理エージェント・プロファイルを作成し、セキュア・プロキシーを管理エージェントに登録します。
  • 構成専用のセキュア・プロキシー・サーバー・プロファイル: 構成専用のセキュア・プロキシー・サーバー・プロファイルをバックエンドの WebSphere Application Server Network Deployment セルで作成して、構成をカスタマイズします。

最後の方法では、構成専用バージョンのセキュア・プロキシー・プロファイルから構成をエクスポートし、DMZ 内のセキュア・プロキシー・プロファイルにそれをインポートします。

セキュア・プロキシー・サーバーの管理の詳細についてはこの記事の範囲外です。詳細については、WebSphere Application Server のインフォメーション・センターを参照してください。

ルーティング

セキュア・プロキシー・サーバーは、静的または動的な情報に基づいて要求をルーティングできます。ルーティング情報の取得に使用するメカニズムは、セキュア・プロキシー・サーバーで使用するように構成されているセキュリティー・モードによって異なります。

  • 低セキュリティー・モード

    この種類のプロキシー構成については第 1 回で説明しました。このモードでは、別個のインストールや別個のセルなどは必要ありません。その代わりに、標準のプロキシー・サーバー (アプリケーション・サーバーと同じセルに定義されます) を単純に使用し、動的情報に基づいてルーティングします。しかしこのモードでは、プロキシー・サーバーとアプリケーション・サーバーとの間の完全な通信が必要とされるので、一般に DMZ 内での使用には適していません。

  • 中セキュリティー・モード

    中セキュリティー・モードで構成すると、セキュア・プロキシー・サーバーは動的ルーティング情報を取得して使用します。しかし、セキュア・プロキシー・サーバーとバックエンドのアプリケーション・サーバーは実際には別のセルにあるので、動的ルーティング情報は特別なコア・グループ・ブリッジ HTTP トンネル接続経由でセキュア・プロキシー・サーバーに伝えられます。基本的には、HTTP ポートを使用してセル間コア・グループ・ブリッジを作成します。したがって、ルーティング情報 (アプリケーション・トラフィックを伴います) はバックエンドのアプリケーション・サーバーのセルとセキュア・プロキシー・サーバーのセルの間で交換されます。

    低セキュリティー・モードと中セキュリティー・モードの両方において、ルーティング情報はプロキシー・サーバーによって動的に取得されるので、スーパー・クラスターを使用するために必要なステップは、基本的に第 1 回で説明した WebSphere Application Server 用のステップと同じです。

  • 高セキュリティー・モード

    高セキュリティー・モードで構成すると、セキュア・プロキシー・サーバーは静的ルーティング情報に基づいてアプリケーション要求をルーティングします。このモードは WebSphere DMZ Secure Proxy Server のデフォルトのモードであり、この記事の残りの部分で詳しく調べます。概念的には、これは HTTP プラグインがルーティングを実行する方法と同じです。ルーティング情報が含まれるフラット・ファイルを生成し、スーパー・クラスターを作成するようにファイルを編集して、DMZ 内に配置されたセキュア・プロキシー・サーバーにそれをコピーする必要があります。デフォルトでは、生成するルーティング・ファイルは targetTree.xml という名前になります。

WebSphere DMZ Secure Proxy Server とスーパー・クラスター

セキュア・プロキシーを使用してスーパー・クラスター全体に要求をルーティングする方法を理解するには、単純な例を調べるのが一番の方法です。図 4 に示す単純な 2 つのクラスターによるトポロジー全体にルーティングするように、セキュア・プロキシー・サーバーを構成するために必要なステップを調べてみましょう。

図 4. DMZ Secure Proxy Server を使用したスーパー・クラスター
DMZ Secure Proxy Server を使用したスーパー・クラスター

ここで説明するサンプル・トポロジーは意図的に制限されています。ただし、ここで説明するテクニックは、はるかに大規模なトポロジーにも容易に拡張して適用することができます。

WebSphere DMZ Secure Proxy Server でスーパー・クラスター・トポロジーを構成するには、以下の基本ステップを実行します。

  1. WebSphere Application Server クラスターを作成します。
  2. アプリケーションをクラスターにインストールします。
  3. アプリケーションをテストして検証します。
  4. 追加の WebSphere Application Server クラスターを作成します。
  5. アプリケーション・モジュールを各 WebSphere Application Server クラスターにマップします。
  6. セキュア・プロキシーの静的ルーティング・ファイル (targetTree.xml) を生成します。
  7. 複数のクラスターにわたって要求をルーティングするように targetTree.xml ファイルを編集します。
  8. 変更した targetTree.xml ファイルをセキュア・プロキシー・サーバーの staticRoutes ディレクトリーにコピーします。

これらのステップの多くについては、第 1 回で詳しく説明したのでここでは繰り返しませんが、ステップ 6 と 7 は DMZ セキュア・プロキシー・サーバー、およびそのスーパー・クラスター全体へのルーティング機能に特有のものです。この 2 つのタスクをよく調べてみましょう。

targetTree.xml ファイルを生成する

高セキュリティー・モード (デフォルト) の DMZ セキュア・プロキシー・サーバーでは、静的ルーティング情報が含まれるファイルをセキュア・プロキシー・サーバーに供給する必要があります。このファイルは、アプリケーションをホストしているバックエンド・セルから生成する必要があります。これを実行するには、Dmgr プロセスで実行中の TargetTreeMbean で exportTargetTree コマンドを使用します。例えば、リスト 1 に示す Jython コマンドを使用すると、スクリプトによって静的ルーティング・ファイルを生成できます。

リスト 1. targetTree.xml ファイルを生成するためのスクリプト・コマンド
// Query for the TargetTreeMbean MBean
mbean=AdminControl.queryNames('*:*,type=TargetTreeMbean,process=dmgr')

// Invoke exportTargetTree method on the TargetTree MBean
AdminControl.invoke(mbean, 'exportTargetTree',
C:/WebSphere/AppServer/targetTree.xml')

スーパー・クラスター以外のトポロジーでは、生成される XML ファイルをデプロイメント・マネージャーからセキュア・プロキシー・サーバーの <profile root>/staticRoutes ディレクトリーに単純に転送できます。するとセキュア・プロキシー・サーバーはこの静的ルーティング情報を使用して、アプリケーション要求をターゲットに送るようになります。スーパー・クラスター・トポロジーでは、この静的ルーティング情報を編集して、スーパー・クラスターのメンバーがすべて含まれる 1 つのフラットなクラスターを作成する必要があります。

targetTree.xml ファイルを編集する

スーパー・クラスターを作成するために targetTree.xml ルーティング・ファイルと plugin-cfg.xml ルーティング・ファイルを編集する際の原理は同じです。2 階層の階層型クラスターのフラットなビューをルーターに示す必要があります。

複数のクラスターにマップされるアプリケーション・モジュールがあり、静的ルーティング・ファイルが生成されたら、次のステップはファイルの編集です。図 5 に、この単純な例のトポロジーから生成された targetTree.xml の関連するコード・セクションを示します。それぞれに 2 つのメンバーが定義された 2 つのクラスター (Cluster1 と Cluster2) が構成されています。

図 5. targetTree.xml -- クラスター定義
targetTree.xml -- クラスター定義

targetTree.xml ファイルの各サーバー (クラスター化されていないアプリケーション・サーバーも含みます) は、cluster 要素内で定義されます。各 cluster 要素には、そのクラスターの各メンバーを定義する link 要素を 1 つ以上持つサーバー・セクション (<!-- server section -->) が 1 つあります。

起動時に、セキュア・プロキシー内部のオンデマンド構成コードは、静的ルーティング・ファイルを読み取り、インメモリー・ルーティング・データを構築します。アプリケーション要求を受け取ると、セキュア・プロキシーはこのインメモリー・ルーティング情報を使用して、要求をターゲットに送ります。ルーターは、ターゲット・サーバーが本当に構成済み WebSphere クラスターの一部かどうかを確認しません。要求のルーティング時に、WebSphere DMZ Secure Proxy Server は適切なセッション・アフィニティーを維持します。

targetTree.xml ファイルを編集する主な目的は、階層型 (スーパー) クラスターのすべてのメンバーが、従来の (フラットな) クラスターに属しているように、セキュア・プロキシー・サーバーに見せることです。したがって、このファイルの編集では以下のことが必要になります。

  1. アプリケーション要求に対してデフォルトで使用されるクラスターを決定します。
  2. 他のクラスターのメンバー (サーバー・セクションの link 要素) を、デフォルトでクライアント要求を処理した、targetTree.xml ファイル内のクラスターに移動します。

デフォルトのターゲットがどのクラスターかを確認する最も簡単な方法は、変更前の targetTree.xml ファイルを使用して単純にアプリケーションをテストすることです。アプリケーション・モジュールが複数のクラスターにマップされるとしても、実際にはただ 1 つのクラスターが、デフォルトでアプリケーション要求のサービスに使用されます。通常、これは targetTree.xml 内に定義されたクラスターのうち、要求を処理できる最初のクラスターになります。デフォルトのターゲットになるクラスターがわかったら、他のクラスターのサーバー・セクションからメンバーをデフォルトのクラスターに移動します。すべての他の cluster 要素のサーバー・セクションから、デフォルトのターゲット・クラスターの cluster 要素内の対応するサーバー・セクションに、link 要素をカット・アンド・ペーストします。

図 6 に、変更された targetTree.xml ファイルの一部を示します。これは、スーパー・クラスターを作成するために Cluster1 と Cluster2 のメンバーがマージされたことを示しています。

図 6. targetTree.xml スーパー・クラスター: Cluster1
targetTree.xml スーパー・クラスター: Cluster1

上の例では、デフォルトのターゲット・クラスターは Cluster1 でした。このため、サーバー・セクションの link 要素は Cluster2 から Cluster1 に移動されました。変更済みの targetTree.xml ファイルがセキュア・プロキシーの <profile home>/staticRoutes ディレクトリーに配置されたことにより、WebSphere DMZ Secure Proxy Server はスーパー・クラスターの 4 つのメンバーすべてに要求を配信するようになります。

link 要素を移動する必要があることに注意してください。移動ではなくコピーを行い、link 要素が 2 か所に存在してしまうと、期待どおりにルーティングが機能しません。HTTP プラグイン・ルーティング・ファイルの編集の場合は、使用しないクラスター定義をそのまま残しても構いませんが、セキュア・プロキシーでは、静的ルーティング・ファイルの形式と内容についての制約が厳しくなっています。targetTree.xml ファイルのサーバーが不適切に移動されると、ルーターがターゲット・クラスターの該当するメンバーを見つけることができなくなり、クライアント (ブラウザー) 要求は 503 (サービス使用不可) エラーで失敗する可能性があります。

その他の考慮事項

セキュア・プロキシーを使用してスーパー・クラスター全体にルーティングする場合は、さらにいくつかの考慮事項がありますので以下に示します。

  • 静的ルーティング XML ファイルは、例えば、targetTree.xml や <any name>.xml など、どのような名前でも構いません。
  • 静的ルーティング XML ファイルは、セキュア・プロキシー・サーバーの <profile home>/staticRoutes ディレクトリーに配置します。
  • 複数の静的ルーティング・ファイル (例えば、xxx.xml) を、セキュア・プロキシー・サーバーの <profile home>/staticRoutes ディレクトリーに置くことができます。これらのファイルは自動的にマージされて、1 つのインメモリー・ルーティング・テーブルが作成されます。この自動マージを避けるには、古いバージョンの静的ルーティング・ファイルを保存するためのサブディレクトリー (例えば、<profile home>/staticRoutes/saved) を作成します。
  • 静的ルーティング・ファイル (例えば、xxx.xml) に対して行われた変更は、自動的に再ロードされることはありません。これらの変更を反映させるには、セキュア・プロキシー・サーバーを停止して起動する必要があります。
  • 静的ルーティングは、使用可能な場合、常に動的ルーティングより優先されます。セキュア・プロキシー構成は、proxy-settings.xml ファイル内のサーバー・スコープに保持されます。この構成ファイルには、静的ルーティングを強制する enableStaticRouting="true" 属性が含まれます。

制限

第 1 回で説明したように、どのスーパー・クラスター・トポロジーにも制約や制限があります。WebSphere DMZ Secure Proxy Server をルーターとして使用する場合は、以下の制限を認識してください。

  • スーパー・クラスターに対し、セキュア・プロキシーは HTTP プロトコルのルーティングのみをサポートできます。
  • このスキームは、セッション・フェイルオーバーもセッション・レプリケーションもサポートしません。セッション・フェイルオーバーには、WebSphere eXtreme Scale またはセッション・パーシスタンスを使用できます。
  • このテクニックでは、静的ルーティング・ファイルは手動で管理する必要があります。したがって、手動で以下の操作を行う必要があります。
    • 静的ルーティング・ファイルの生成
    • 静的ルーティング・ファイルの編集
    • 静的ルーティング・ファイルのプロパゲーション
    • トポロジー変更に伴う静的ルーティング・ファイルの同期化
  • このテクニックでは、コア・グループ・ブリッジ・サービス (CGBS) 構成が必要になる場合があります。
    • クラスター (アプリケーションのデプロイメント・ターゲット) が異なるコア・グループに配置されている場合は、バックエンド・セルに CGBS が必要になります。
    • ルーティング情報を動的に取得するため、中セキュリティー・モードでセキュア・プロキシー・サーバーを実行する場合は、CGBS が必要になります。

次のセクションでも同じサンプル・シナリオを見ていきますが、今度は WebSphere DMZ Secure Proxy Server でなく、WebSphere Virtual Enterprise オンデマンド・ルーター (プロキシー・サーバー) を使用してスーパー・クラスター全体に要求を配信します。


WebSphere Virtual Enterprise を使用する

WebSphere Application Server Network Deployment のアドオンとして、IBM WebSphere Virtual Enterprise を使用して、基盤となっている WebSphere Application Server インフラストラクチャを仮想化できます。ユーザー指定のサービス・レベル・アグリーメント (SLA)、ヘルス管理、運用監視、およびアプリケーション・エディションに基づく動的な運用は、WebSphere Virtual Enterprise (以前の WebSphere Extended Deployment Operations Optimization) の重要で有用な機能の 1 つです。

オンデマンド・ルーター

WebSphere Virtual Enterprise にはオンデマンド・ルーター (ODR) コンポーネントが含まれ、アプリケーション要求トラフィックの調整、割り込みのないアプリケーション・ロールアウト、およびその他の重要な機能において中心的な役割を果たします。したがって、WebSphere Virtual Enterprise トポロジーにおいて、HTTP トラフィックは ODR によってルーティングされます。

構成とトポロジーの観点から見ると、ODR は典型的な WebSphere Application Server Network Deployment プロキシー・サーバーのように見えます。スケーラビリティーと高可用性のためには、ODR をクラスター化する必要があります。通常の ODR クラスターには少なくとも 2 つのメンバーが含まれ、それぞれ別個のマシンに存在します。現在の WebSphere Virtual Enterprise の実装では、ODR クラスターは単に ODR の集まりに過ぎません。したがって、ODR クラスターは、管理コンソールやスクリプトによって明示的に作成、管理されることはありません。ユーザーが ODR を個別に作成し、管理します。

ODR とスーパー・クラスター

従来のプロキシー・サーバーと同様に、ODR もトラフィックをスーパー・クラスターにルーティングするために使用することができます。これを実行するためのステップを以下に示します。基本的には第 1 回でプロキシー・サーバーについて説明したステップと同じです。

  1. WebSphere Application Server クラスターを作成します。
  2. アプリケーションをクラスターにインストールします。
  3. アプリケーションをテストして検証します。
  4. 追加の WebSphere Application Server クラスターを作成します。
  5. アプリケーション・モジュールを各 WebSphere Application Server クラスターにマップします。
  6. クラスターを含むすべてのコア・グループと、ODR を含むコア・グループをブリッジします。

従来のプロキシー・サーバーと同様に、静的ルーティング・ファイルを手動で編集する必要はありません。ODR はルーティング情報を動的に取得します。この動的ルーティングを適切に機能させるためには、ODR を含むコア・グループと、ターゲット・クラスター・メンバーを含むコア・グループを、CGBS を使用してブリッジする必要があります。


ODR スーパー・クラスタリング・トポロジー

セキュリティー上の理由から、ODR は通常 DMZ には配置されません。その代わりに、図 7 に示すように、DMZ に存在する Web サーバー (とプラグイン) が、ファイアウォールの内側に配置された ODR クラスターのメンバーに、HTTP 要求をルーティングします。このトポロジーと、パート 1 で説明した HTTP プラグインとプロキシー・サーバーの両方をスーパー・クラスターで使用するトポロジーが似ていることに注意してください。

図 7. ODR プロキシー
ODR プロキシー

ODR のルーティング機能は、従来のプロキシー・サーバーの機能と似ています。ODR は着信 HTTP 要求を、その要求に対応できる任意のターゲット・サーバーに「アプリケーション・スコープ」方式でルーティングします。WebSphere Application Server セルでは、ODR は、関連アプリケーションがデプロイされている WebSphere クラスター・メンバーおよびクラスター化されていない WebSphere Application Server インスタンスに、セッション・アフィニティーを維持しながら HTTP 要求を配信します。内部的には、マルチクラスター・ルーティング・コンポーネントは、クラスター化されていないアプリケーション・サーバーを、アプリケーション・サーバーを唯一のメンバーとして持つシングルトン WebSphere Application Server クラスターとして扱います。

図 7 に示したように、Web サーバーとプラグイン・ルーターの組み合わせでは、HTTP 要求を厳密なラウンドロビン方式ですべての ODR クラスター・メンバーに転送します。セッション・アフィニティーはアプリケーション・サーバーへの要求の転送時に ODR によって処理されるので、プラグイン・ルーター・レベルではセッション・アフィニティーを維持する必要はありません。

第 1 回で説明した HTTP プラグインとプロキシー・サーバーのトポロジーと全く同じように、HTTP プラグイン・コンポーネントを使用可能にして要求を ODR クラスターに転送するには、特別な静的ルーティング・ファイルが必要です。ODR には、必要な plugin-cfg.xml ファイルを自動生成するメカニズムが用意されています。このファイルは ODR の <profile home>/etc ディレクトリーに置かれます。また、生成されるプラグイン・データのスコープを指定するためのオプションがあります。WebSphere Virtual Enterprise では、このスコープ設定によって、プラグイン・ルーターはどの ODR が ODR クラスターに属していると見なすかが決まります。また、スクリプトを構成して、ODR が生成したプラグイン・ファイルを Web サーバー・マシンの適切な位置に自動的にコピーすることができます。関連する構成変更 (アプリケーションの追加、削除、変更、ODR の数の変更、およびプラグイン生成スコープの変更など) が行われた場合は、新しいプラグイン・ファイルが自動生成されます。ODR からのプラグイン・ルーティング・ファイル生成の詳細については、この記事の第 1 回の図 18 と 19、および IBM Redbooks 「Optimizing Operations with WebSphere Extended Deployment V6.1」を参照してください。

その他の考慮事項

WebSphere Virtual Enterprise ODR を使用して、スーパー・クラスター全体にルーティングする場合は、以下の事項を考慮してください。

  • WebSphere Application Server Network Deployment と比較すると、WebSphere Virtual Enterprise は高可用性マネージャーの Bulletin Board Service を多用します。このため、WebSphere Virtual Enterprise を使用する場合は、コア・グループ・サイズを 50 個 (控えめなサイズ) に制限します。
  • 従来のプロキシー・サーバーでは、クラスター・レベルでプラグイン・ルーティング・ファイルの生成と配信の設定を構成できます。ODR の場合、これらの設定は個々の ODR レベルでのみ指定できます。
  • Web サーバーが ODR クラスター・メンバー全体に要求を配信する方法を調整するには、デフォルトのラウンドロビン負荷分散アルゴリズムで使用される LoadBalanceWeight 属性値を変更します。この値は、ODR が生成した plugin-cfg.xml ファイルにあります。例えば、ODR クラスター・メンバーがホストされるマシンの性能が異なる場合は変更する必要があります。
  • この時点で、生成されたプラグイン・ルーティング・ファイルには、生成時に起動されていて、実行中であった ODR のみが含まれます。
  • WebSphere Virtual Enterprise には、動的クラスターを作成するオプションが用意されています。ODR のマルチクラスター・ルーティング機能では、従来の WebSphere Application Server 静的クラスターと WebSphere Virtual Enterprise 特有の動的クラスターは区別されません。したがって、図 7 の一部またはすべてのクラスターは、さまざまな動的特性を持つ可能性があります。

制限

WebSphere Virtual Enterprise ODR をルーターとして使用する場合、以下の制限があります。

  • スーパー・クラスターに対し、ODR は HTTP プロトコルのルーティングのみをサポートできます。
  • このスキームは、セッション・フェイルオーバーもセッション・レプリケーションもサポートしません。セッション・フェイルオーバーには、WebSphere eXtreme Scale またはセッション・パーシスタンスを使用できます。
  • このテクニックでは、ODR とクラスター (アプリケーションのデプロイメント・ターゲット) が異なるコア・グループに配置される場合は CGBS 構成が必要になります。

次のセクションでは、スーパー・クラスターの概念が IBM WebSphere eXtreme Scale とどのように関連するかについて調べます。


WebSphere eXtreme Scale を使用する

WebSphere eXtreme Scale には、非常に強力なメモリー一貫性を持つ分散キャッシュが用意されています。WebSphere eXtreme Scale は、ホストしている JVM (Java Virtual Machine) のヒープ領域から形成された仮想領域でデータをキャッシュします。WebSphere eXtreme Scale は、スループットの予測が可能な直線的なスケーラビリティーを備えています。WebSphere eXtreme Scale を使用することで、大量の区分データを潜在的に格納可能なエラスティック・グリッドを作成できます。WebSphere eXtreme Scale はレプリカを使用して、本質的な高可用性をサポートします。また、グリッドの動作を変更するためにユーザーが構成できるプラグインをいくつか提供します。

デプロイメント環境

WebSphere eXtreme Scale では、その操作のために WebSphere Application Server 製品を使用する必要は一切ありません。また、Java EE JVM も不要です。WebSphere eXtreme Scale は WebSphere 以外の Java Standard Edition (Java SE) JVM にもデプロイできます。32 ビット (より一般的な環境) または 64 ビットのどちらの JVM にも対応しています。

WebSphere eXtreme Scale と WebSphere Application Server

WebSphere eXtreme Scale は標準 Java SE 環境で使用できますが、WebSphere eXtreme Scale を WebSphere Application Server と共に使用すると、テスト、デバッグ、および問題判別などが改善され、管理機能が向上します。

WebSphere Application Server Network Deployment に精通していて、すでに実行しているのであれば、この環境に WebSphere eXtreme Scale をデプロイすることが、いくつかの理由で魅力的であることがわかるでしょう。WebSphere Application Server Network Deployment では、WebSphere eXtreme Scale グリッドおよび関連アプリケーションの管理、デプロイメント、および構成を一元的に行うことができます。PMI (Performance Monitoring Infrastructure) サービスを使用すると、さまざまな WebSphere eXtreme Scale 関連の統計情報を中央から視覚化して監視できます。

WebSphere eXtreme Scale は 1 つの JVM にデプロイできますが、このようなデプロイ方法では高可用性は実現されません。また、大量のデータをキャッシュするには 1 つの JVM では不十分です (例えば、32 ビット JVM では、最大 2 GB の使用可能ヒープ領域しか保証できません)。したがって、大量の高可用性の区分データをキャッシュするには、WebSphere eXtreme Scale を複数の JVM にデプロイする必要があります。単純な Java SE 環境では、WebSphere eXtreme Scale のデプロイメントは、製品に付属しているスクリプトを使用して実行します。同じスクリプトを使用して、クラスター化されていない WebSphere Application Server インスタンスに WebSphere eXtreme Scale をデプロイすることもできますが、WebSphere Application Server Network Deployment クラスターを使用すると、管理機能が向上し、WebSphere eXtreme Scale のデプロイメントが容易になります。

WebSphere Application Server Network Deployment ランタイムは、実行用にヒープ領域をいくらか消費することに注意してください。したがって、WebSphere eXtreme Scale を Network Deployment 環境にデプロイすると、グリッド内の実際のオブジェクトをキャッシュするために使用できるヒープ領域が減ります。これは向上した管理機能とのトレードオフです。

カタログ・サービス

WebSphere eXtreme Scale の設計上、グリッドの起動前に、カタログ・サービスが存在する必要があります。WebSphere eXtreme Scale のカタログ・サーバーは、配置や管理のサービスを提供するために使用されます。WebSphere Application Server 以外の環境では、特別な JVM をカタログ・サーバーとして指定し、グリッドの起動前にその JVM を起動します。

WebSphere Application Server Network Deployment 環境では、カタログ・サービスはデフォルトでは、デプロイメント・マネージャー・プロセス上で開始されます。ただし、セル・スコープのカスタム・プロパティーを使用して 1 つ以上のアプリケーション・サーバーがカタログ・サービスをホストするように指定することで、このデフォルトの動作を変更することができます。

WebSphere Application Server クラスターでのデプロイメント

WebSphere eXtreme Scale グリッドは、WebSphere eXtreme Scale コンテナーによってホストされます。WebSphere Application Server 環境では、デプロイされたアプリケーションの META-INF ディレクトリーにある objectGrid.xml と objectGridDeployment.xml という 2 つの構成ファイル (キャッシュへのアクセスに使用するプログラミング・モデルによっては、entity.xml も META-INF ディレクトリーに存在します) の存在がトリガーとなり、WebSphere eXtreme Scale がコンテナー・サービス、つまりグリッドを開始します。

ローカル・グリッドまたはリモート・グリッド

WebSphere eXtreme Scale グリッド、およびそのグリッドを使用するアプリケーションは、同じ JVM 内に配置できます。または、アプリケーションを一方の JVM で実行し、別の JVM で実行中のグリッド・コンテナーにアクセスすることもできます (クライアント・サーバーのリモート・モード)。お察しのとおり、各トポロジーに関連してさまざまなトレードオフがあります。

図 8 に、WebSphere eXtreme Scale グリッド、およびそのグリッドを使用するアプリケーションが同じ JVM に配置されたトポロジーの例を示します。この例では、グリッドにアクセスするときに、パフォーマンス上の利点があります。つまり、キャッシュされたデータにアクセスするためにアプリケーションからのネットワーク・ホップは必要ありません。

図 8. ローカル WebSphere eXtreme Scale グリッド
ローカル WebSphere eXtreme Scale グリッド

このローカル・グリッド構成では、前述の WebSphere eXtreme Scale の XML グリッド構成ファイルを、使用しているアプリケーションの META-INF ディレクトリーにパッケージできます。すると、アプリケーションを管理コンソールから (または wsadmin スクリプトで) デプロイして起動できます。WebSphere eXtreme Scale コンテナー (したがって、グリッド) はアプリケーションと共に自動的に起動されます (ここでは、WebSphere eXtreme Scale カタログ・サーバーがすでに起動されて実行中であると仮定します)。

クライアント・サーバーのリモート・モードでは、WebSphere eXtreme Scale グリッドは、図 9 に示すようにアプリケーションをホストしているクラスターとは別の WebSphere クラスターにホストされます。

図 9. リモート WebSphere eXtreme Scale グリッド
リモート WebSphere eXtreme Scale グリッド

このリモート・グリッド構成では、グリッド・データにアクセスするためにネットワーク・ホップが必要です。しかし、このトポロジーには分離性という利点があり、アプリケーションのスケーラビリティーに関係なくグリッドをスケール・アップまたはスケール・ダウンできます (例えば、WebSphere eXtreme Scale グリッド・クラスター内の JVM の数が、アプリケーション・クラスター内の JVM の数と異なっていても構いません)。その上、このトポロジーを使用すると、複数の異なるアプリケーション (それぞれ独自のクラスター内にあります) が 1 つのデータ・グリッドを共有することもできます。もう 1 つの潜在的な利点は、このトポロジーを使用すると、アプリケーション・クラスターと WebSphere eXtreme Scale グリッド・クラスターを異なるバージョンの WebSphere Application Server にホストできることです。

Java のプリミティブ型で記述できるデータをキャッシュするためだけにグリッドが使用されると、1 つの単純なアプリケーションによって WebSphere eXtreme Scale コンテナーを管理できます。この単純なアプリケーションは、グリッド・クラスターにデプロイされ、META-INF ディレクトリーに 2 つの構成ファイルを持つことができます。こうすると、この単純なアプリケーションの起動によって、グリッド・コンテナーが自動的に起動されます。

プリミティブ型以外のデータ・オブジェクトがグリッドでキャッシュされる場合、この単純なアプリケーションは、META-INF ディレクトリーの構成ファイルと共に、グリッドに格納されるオブジェクトのクラス定義も含む必要があります。

グリッド・クラスターにデプロイされるこの単純なアプリケーションの目的は、計算処理の実行ではなく、WebSphere eXtreme Scale ランタイムに以下のものを提供することです。

  • グリッド構成パラメーター
  • グリッドに格納されるオブジェクトのシリアライズおよびデシリアライズに必要なクラス定義

スーパー・クラスター内の WebSphere eXtreme Scale グリッド

第 1 回で説明したように、WebSphere Application Server クラスターの最大サイズに直接影響を及ぼす、コア・グループと関連したスケーラビリティーの制約があります。WebSphere Application Server V6.1 以降では、一般にコア・グループ (したがって、クラスター・サイズ) のメンバー数を最大 100 個程度に制限することを推奨しました (実際の制限は、使用可能なリソース、アプリケーションの数、およびネットワーク帯域幅などに左右されます)。

WebSphere eXtreme Scale グリッドの最大サイズは、グリッド・クラスターのすべてのメンバーで使用可能な空きヒープ領域の合計になることを思い出してください。したがって、必要なグリッド・サイズまたはキャッシュ・サイズが、最大推奨サイズを超える WebSphere Application Server クラスターを必要とする場合、どのような WebSphere eXtreme Scale デプロイメント戦略に従えばよいでしょうか。繰り返しますが、その答えは WebSphere Application Server クラスターでグリッドをホストすることです。これにより、スーパー・クラスター内のすべての JVM のヒープ領域を使用して、非常に大規模なグリッド領域を形成できます。

わかりやすくするため、WebSphere eXtreme Scale はコア・グループまたはクラスターに依存しないものとします。クラスター・サイズに関する考慮事項は、WebSphere eXtreme Scale が WebSphere Application Server Network Deployment にデプロイされることと関係があります。

図 10 に、クライアント・サーバー型の WebSphere eXtreme Scale グリッド環境を示します。ここでは、アプリケーションは従来の WebSphere クラスターにデプロイされ、スーパー・クラスター内にデプロイされている WebSphere eXtreme Scale にアクセスします。

図 10. スーパー・クラスターにデプロイされた WebSphere eXtreme Scale
スーパー・クラスターにデプロイされた WebSphere eXtreme Scale

WebSphere eXtreme Scale スーパー・クラスター・トポロジーを作成する手順を以下に示します。

  1. 予想される WebSphere eXtreme Scale グリッドのサイズから、スーパー・クラスターを構成する WebSphere Application Server クラスターの数 n (n は 1 以上) を決定します。
  2. n 個のコア・グループを作成します。
  3. これで、DefaultCoregroup コア・グループを含む n 個のコア・グループを用意できたので、すべてのコア・グループに対し、以下のようにします。
    • 標準コア・グループ形成ルールに従います。
    • ベスト・プラクティスによって推奨されるのは、各コア・グループを 2 つの優先コーディネーター・サーバーによって構成することであり、理想的にはクラスター化されていないサーバー上、および異なる物理マシン上に配置することです。
    • それぞれ最新バージョンのコア・グループ・プロトコルを実行するように構成します。
  4. DefaultCoregroup の 3 つのメンバーから構成される、WebSphere eXtreme Scale カタログ・サービス用の、水平 WebSphere Application Server クラスター (例えば、CatalogCluster) を作成します。
    • CatalogCluster を使用して、確実にすべてのカタログ・サーバーが同じコア・グループに属するようにします。これは、WebSphere eXtreme Scale デプロイメントの要件です。
    • 各カタログ・サーバーを別の物理マシンに配置すると、カタログ・サービスの高可用性が実現されます。
    • 妥当な数のカタログ・サーバー (この例では 3 つ) は、カタログ・サービスの高可用性に役立ちます。
    • CatalogCluster WebSphere Application Server クラスターは、WebSphere eXtreme Scale グリッドをホストしている WebSphere Application Server スーパー・クラスターの一部ではありません。
  5. CatalogCluster のメンバーを WebSphere eXtreme Scale カタログ・サーバーとして指定するため、セル・スコープの catalog.services.cluster カスタム・プロパティーを適切に定義します。ここには、CatalogCluster の各メンバーのホストおよびポートが記載されます。
  6. 必要な WebSphere Application Server クラスターを、n 個のコア・グループすべてに作成します。各クラスターは、適切な数のクラスター・メンバーを持ちます。

WebSphere Application Server スーパー・クラスター・トポロジーを構成すると、グリッド・コンテナーを構成し起動する単純なアプリケーションを作成する必要があります。この単純な WebSphere eXtreme Scale 管理アプリケーションを構成するには、以下のようにします。

  1. 必要なクラス定義および必要な WebSphere eXtreme Scale 構成ファイルを META-INF ディレクトリーに持つダミー・アプリケーション (例えば、GridApp) を作成します。
  2. GridApp を、スーパー・クラスターに含める予定の WebSphere Application Server クラスターのいずれかにデプロイします。
  3. GridApp モジュールを、スーパー・クラスターを構成するすべての WebSphere Application Server クラスターにマップします。第 1 回で説明した、モジュールを複数のクラスターにマップするテクニックを使用してください (アプリケーションを CatalogCluster にはマップしないでください。CatalogCluster クラスターのメンバーは、WebSphere eXtreme Scale コンテナーをホストしても、キャッシュ領域を提供しないからです)。
  4. CatalogCluster クラスターが実行中であることを確認します。
  5. 関連グリッド・コンテナーを自動的に起動するダミー・アプリケーションを各クラスターで起動します。

WebSphere Application Server クラスターとこの類の単純なアプリケーションを使用すると、WebSphere eXtreme Scale の管理が容易になります。すべての関連クラスターのダミー・アプリケーションを起動したり停止したりすることにより、グリッド・コンテナーを容易に起動したり停止したりできます。グリッド構成ファイルを変更するとグリッドの再起動が必要になるので、ここで説明したテクニックは、数百もの JVM を含む大規模なグリッドを管理する単純でわかりやすい方法になります。このように、WebSphere eXtreme Scale によるスーパー・クラスタリング・テクニックを使用すると、グリッド管理および監視を中央 (例えば、WebSphere Application Server デプロイメント・マネージャー) から容易に行うことができます。

その他の考慮事項

スーパー・クラスター・トポロジーで WebSphere eXtreme Scale を使用する際に考慮する必要のある、その他の事項を以下に挙げます。

  • エンタープライズ品質のリモート WebSphere eXtreme Scale グリッドは、他のユーザー・アプリケーションと共に配置しないでください。
  • スーパー・クラスターで実行される WebSphere eXtreme Scale グリッドの場合、カタログ・サーバー・クラスターまたはクラスターをホストしているグリッドを含む、どのコア・グループともブリッジする必要はありません。
  • Network Deployment 環境でクラスター化されていない WebSphere Application Server インスタンスを使用して WebSphere eXtreme Scale コンテナーをホストする場合は、コア・グループのサイズ制約はなくなりません。すべてのプロセスは (クラスター化されている、いないに関係なく) コア・グループのメンバーなので、クラスター化されていないサーバーで構成されるコア・グループが大きくなりすぎると、問題が生じることがあります。

スーパー・クラスター内のアプリケーションと WebSphere eXtreme Scale

図 11 に示すように、アプリケーションと WebSphere eXtreme Scale グリッドの両方をスーパー・クラスターにデプロイすることが可能です (この例では、クライアント・サーバー構成)。このシナリオでは、アプリケーションのスケーラビリティーのために使用されるスーパー・クラスターと、グリッドのスケーラビリティーのために使用されるスーパー・クラスターを組み合わせています。それぞれのスーパー・クラスターは独立して拡張できます。

図 11. スーパー・クラスター内のアプリケーションと WebSphere eXtreme Scale グリッド
スーパー・クラスター内のアプリケーションと WebSphere eXtreme Scale グリッド

HTTP セッション・フェイルオーバー

アプリケーションのスケーラビリティーや、ルーターと関連したスーパー・クラスタリング・テクニックの説明時に触れたように、HTTP セッション・レプリケーションがサポートされないという制限があります。これは、WebSphere Application Server のレプリケーション・サービスが、現在はシングル・コア・グループに制限されているからです。しかし、前述のように、WebSphere eXtreme Scale グリッドを使用して、スーパー・クラスター全体に HTTP セッション・レプリケーションを提供できるので、HTTP セッション・フェイルオーバーが使用可能となります。

WebSphere eXtreme Scale には、HTTP セッション管理を提供するための HTTP サーブレット・フィルターが組み込まれています。WebSphere eXtreme Scale にはフィルターをアプリケーションに適切に導入するためのユーティリティーが用意されており、HTTP セッション・データを保存して、スーパー・クラスター全体にレプリケートできます。HTTP セッション・データに WebSphere eXtreme Scale グリッドを使用すると、コア・グループ、スーパー・クラスター、さらに WebSphere Application Server セル全体の HTTP セッションの保存とレプリケーションが可能になります。

HTTP セッション管理の場合、通常はグリッド・コンテナーをアプリケーションと同じ JVM に配置します。図 12 に、このトポロジーの例を示します。

図 12. WebSphere eXtreme Scale を使用したスーパー・クラスターに対する HTTP セッション管理
WebSphere eXtreme Scale を使用したスーパー・クラスターに対する HTTP セッション管理

当然ながら、リモート WebSphere eXtreme Scale グリッドも必要に応じて HTTP セッション管理のために使用できます。したがって、標準クラスター内にアプリケーションとグリッド (図 8)、スーパー・クラスター内にアプリケーションと WebSphere eXtreme Scale グリッド (図 12) を持つことができます。または、アプリケーション・ホスティング・クラスターと WebSphere eXtreme Scale グリッド・ホスティング・クラスターのどちらかまたは両方がスーパー・クラスターとして構成される、リモート・グリッド・トポロジーを持つことができます。HTTP セッション管理用のリモート・グリッドの使用は、複数のアプリケーションが同じ WebSphere eXtreme Scale グリッドを使用してセッション・データを保存しようとしているか、または HTTP セッション状態が異なるアプリケーション間で共有されるシナリオにおいて必要とされます。


まとめ

この 2 部構成の記事の第 2 回では、スーパー・クラスターの議論を進め、IBM WebSphere DMZ Secure Proxy Server V7、IBM WebSphere Virtual Enterprise オンデマンド・ルーター、および IBM WebSphere eXtreme Scale を含めて議論を展開しました。この記事では、2 階層の階層型クラスターが DMZ Secure Proxy Server から従来のフラットなクラスターのように見えるように、静的ルーティング・ファイルを手動で編集するためのテクニックの背後にある戦略を解説し、オンデマンド・ルーターでスーパー・クラスタリング・テクニックを使用する方法について説明しました。

スーパー・クラスタリング・テクニックには、WebSphere eXtreme Scale を WebSphere Application Server Network Deployment クラスターと共に使用する興味深いアプリケーションもあります。この状況で、予想される WebSphere eXtreme Scale グリッドのサイズが、1 つの WebSphere Application Server クラスターが提供するヒープ領域の合計を超える場合は、スーパー・クラスタリング・テクニックを使用して非常に大規模なグリッドを形成できます。実際、クラスター (それぞれが妥当な数のメンバーを持ちます) の数を増やすことで、膨大な量のデータを保存する WebSphere eXtreme Scale グリッドを形成できます。この記事では、このようなグリッドのデプロイメント・トポロジー、構成、および管理について説明しました。また、WebSphere eXtreme Scale グリッドを使用して、スーパー・クラスターに Java EE アプリケーションがデプロイされるトポロジーに対して、HTTP セッション・フェイルオーバーをサポートする方法についても説明しました。

スーパー・クラスターは日々の業務で必要になるものではありませんが、HTTP クライアントまたは大規模な WebSphere eXtreme Scale グリッドのために必要になった場合、それに対処できる方法がいくつかあります。すべてのスーパー・クラスター・オプションには制限がいくつかありますが、シナリオによっては、それらの制約は問題にならないでしょう。

100 個 (WebSphere Virtual Enterprise の場合は 50 個) を超えるメンバーを持つクラスターがすぐに必要な場合や、クラスター内に今後 100 台 (WebSphere Virtual Enterprise の場合は 50 台) を越えるアプリケーション・サーバーを配置できるくらい柔軟なデプロイメント・アーキテクチャーが必要な場合は、スーパー・クラスターを検討してもよいでしょう。

スーパー・クラスターに含めることができる WebSphere Application Server インスタンスの数には理論的な制限はありませんが、スーパー・クラスタリング・テクニックをスケーラビリティーの万能薬とは考えないでください。特定の Java EE アプリケーションが使用するリソースによって、これらのアプリケーションのスケーラビリティーに制約が課されることがあります。例えば、データベース関連アプリケーションでは、基盤となるデータベース・サーバーで対応できる最大データベース接続数が、アプリケーションを同時にデプロイできる WebSphere Application Server インスタンス数を制限することがあります。つまり、アプリケーションのスケーラビリティーが制限されることになります。

一般に、ハイパー・スケーラビリティーは、取り組みがいのあるトピックですが、場合によっては、従来のデータ・モデリングやプログラミング規律にパラダイム転換を要求するかもしれません。このようなトピックはこの 2 つの記事の範囲を超えますが、もし関心があれば、参考文献を参照して、eXtreme Transaction Processing (XTP) のすばらしい概要や、その他の参考文献を入手してください。


謝辞

この記事の技術的な内容と正確性について、準備やレビューをしていただいた次の方々に感謝します。Bob Westland (WebSphere Application Server Network Deployment workload manager architect)、Benjamin Parees (WebSphere Virtual Enterprise development)、Keith Smith (on demand router architect)、Chris Johnson (eXtreme Scale architect and co-lead)、Doug Berg (eXtreme Scale architect and co-lead)、Robert Wisniewski (eXtreme Scale evangelist)、Hao Wang (eXtreme Scale development)、Peter Van Sickel (IBM Software Services for WebSphere consultant)。

参考文献

学ぶために

議論するために

コメント

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=WebSphere
ArticleID=618418
ArticleTitle=スーパー・クラスターで解決する: 第 2 回 WebSphere DMZ Secure Proxy Server、ODR、および WebSphere eXtreme Scale による最高のスケーラビリティー
publish-date=07222009