WebSphere Application Server V8public.dhe.ibm.com/software/dw/jp/websphere/was/was8_ws/...WebSphere...

02. システム構成

WAS V8.0 アナウンスメント・ワークショップ 1

WebSphere Application Server V8.0WebSphere Application Server V8.0

アナウンスメント・ワークショップアナウンスメント・ワークショップ

© 2011 IBM Corporation

1 WAS V8.0 アナウンスメント・ワークショップWAS V8.0 アナウンスメント・ワークショップ

0202. . システム構成システム構成

®

システム構成システム構成






Disclaimer

この資料は日本アイ・ビー・エム株式会社ならびに日本アイ・ビー・エムシステムズ・エンジニアリング株式会社の正式なレビューを受けておりません。

当資料は、資料内で説明されている製品の仕様を保証するものではありません。

資料の内容には正確を期するよう注意しておりますが、この資料の内容は2011年7月現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様が変わる可能性があるのでご注意下さい。

今後国内で提供されるリリース情報は、対応する発表レターなどでご確認ください。

IBM、IBMロゴ、ibm.com、 AIX、Rational、およびWebSphere は、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点でのIBMの商標リストについては、http://www.ibm.com/legal/copytrade.shtmlをご覧ください。

JavaおよびすべてのJava関連の商標は Oracleやその関連会社の米国およびその他の国における商標または登録商標です。

Windows は、Microsoft Corporationの米国およびその他の国における商標です。

Linuxは、Linus Torvaldsの米国およびその他の国における登録商標です。

UNIXはThe Open Groupの米国およびその他の国における登録商標です。






目次

WAS V8で提供されるコンポーネント

WASのコア・コンポーネントと基本構成

WAS NDが提供する高可用性機能

WASの管理系コンポーネントと基本構成

参考資料

まず、V8で提供されるコンポーネントの一覧を「WAS V8で提供されるコンポーネント」でご覧いただき、それぞれの詳しい説明を「 WASのコア・コンポーネントと基本構成」および「WASの管理コンポーネントと基本構成」でしていきます。また、WAS NDにおいてのみ使用できる高可用性機能について、コンポーネントの説明とは分けて「WAS NDが提供する高可用性機能」でご説明いたします。






WAS V8で提供されるコンポーネント






WAS V8で提供されるコンポーネント一覧

○○○IBM HTTP Server

○○○Web Server Plug-ins

○××Edge Components

○××WebSphere Proxy Server

○××WebSphere DMZ Secure Proxy Server

○○○Admin Agent

○××Job Manager

WAS Edition

○

Express

○

Base NDコンポーネント

○WebSphere Application Server

管理系

コア

（基盤系）

WAS V8.0が提供するコンポーネントは上記の8種類で、Webシステムを構成するアプリケーション・サーバーなどのコア・コンポーネント（6種類）、小規模から大規模までシステムの運用管理を容易にするための管理系コンポーネント（2種類）に分かれます。

これらのコンポーネントはエディションによって同梱される・されないがありますので、システム構成を考える場合にはご注意いただく必要があります。






インストール方法の変更 – IBM Installation Manager -

IBMソフトウェア共通のインストーラー– Rational Application Developerなど

– ローカル・リポジトリーに導入済みソフトウェアの情報を保持

FixPackの適用もIBM Installation Managerで実行可能– UpdateInstallerは利用せず、IBM Installation ManagerでFixPackの検索から適用まで可能

IIMによる製品インストール

IIMでのFix適用

IIM （IBM Installation Manager）の導入

WASDisc

Supplement Disc

IHS・WAS環境構築・設定

New

■V8でのインストールの流れ

WASを導入IHSを導入

先ページのWAS V8.0で提供されるコンポーネントに対し、IBM Installation Manager （以下IIM）でのインストール・Fix適用を行います。これにより、製品のインストール・Fix適用の手順は統一化され、インストール作業がよりシンプルになりました。

システムの構成において、WASの各コンポーネントが導入されるOSには必ずIIMをインストールする必要があることにご注意ください。






WASのコア・コンポーネントと基本構成

まずは、Webシステムを構成するために使用するWASのコア・コンポーネントについて、それぞれの概要と基本構成をご説明いたします。






WASシステムのコア・コンポーネント

Presentation TierBusiness Logic Tier

Web Server TierProxy TierLoad Balancer Tier

DB/MQ Server等負荷分散装置ユーザー

プロキシーWebサーバー APPサーバー

Edge Components Load Balancer

WebSphere Proxy ServerWebSphere DMZ Secure Proxy Server

Edge Components Caching Proxy

IBM HTTP Server （IHS）+ Web Server Plug-ins WebSphere Application Server

Webシステムは負荷分散層（Load Balancer Tier）、プロキシー層（Proxy Tier）、Webサーバー層（Web Server Tier）、プレゼンテーション層（Presentation Tier）、ビジネスロジック層（Business Logic Tier）の5層に分かれます。プロキシー層・Webサーバー層はシステムによっては省略される場合もありますし、前後が入れ替わる場合もあります。

上図は、WASで提供されるコア・コンポーネントの位置づけを示しています。図からもわかりますように、Webシステムの全ての層に対応するWASのコンポーネントがあり、一貫してサポートを提供できる点がWASの大きなメリットです。






WebSphere Application Server








IBM HTTP Server (IHS)+ Web Server Plug-ins WebSphere Application Server



DB/MQ Server等負荷分散装置ユーザーユーザー






Webシステムのプレゼンテーション層とビジネスロジック層を司るコンポーネントであるWebSphereApplication Serverについて概要と基本構成をご説明いたします。






WebSphere Application Server Express Base ND

WebSphere Application Server V8

セキュリティーセキュリティーHAマネージャーHAマネージャー

トランザクショントランザクション

ネーミングネーミングJMXJMX

Webサービスエンジン

Webサービスエンジン

メッセージングエンジン

メッセージングエンジン

EJBコンテナーEJBコンテナー

MDB

WebコンテナーWebコンテナー

組み込みHTTPサーバー組み込みHTTPサーバー

Servlet/JSPServlet/JSPHTMLsHTMLs JavaBeansJavaBeans

セッション

SIPコンテナー

SIPコンテナー

etc..

Java EEに準拠したエンタープライズ・アプリケーションが稼動するJavaプロセス

Javaアプリケーション実行に必要な以下のサービスを提供

– Webコンテナー

– EJBコンテナー

– SIPコンテナー

– Webサービス

– JMS （Java Messaging Service）

– JMX（Java Management Extensions）

– セキュリティー

– HAマネージャー

– トランザクション etc..

ランタイム・プロビジョニング機能により

必要なサービスのみのロードが可能

WebSphere MQ関連の機能を必要と

しない場合、無効化することが可能組み込みJMSプロバイダー

New

Java EEアプリケーションはサーブレットやJSP, EJBなどによって構成されます。WebSphereApplication ServerはこうしたJava EE準拠のアプリケーションを稼動させるためのJavaプロセスで、サーブレットやJSPのランタイム環境であるWebコンテナー、EJBランタイム環境であるEJBコンテナーなど、Java EEの仕様に合わせて複数のサービスを提供します。

数多くサービスを提供しますが、例えばEJBを使用しないアプリケーションの場合はEJBコンテナー・サービスが不要であるなど、使用するアプリケーションによって不要なサービスは少なからず存在してしまいます。こうしたことに対し、V7.0よりランタイム・プロビジョニングと呼ばれる、アプリケーション・サーバー上のアプリケーションが必要とする、小限のサービス・コンポーネントのみをロードし、

不要なサービスのロードを抑止する機能が追加されました。また、V8.0よりWebSphere MQに関連する機能（JMSプロバイダー機能）を不要な場合無効化できる機能が提供され、これまでのバージョンよりもさらに不要なサービスによるリソース消費を抑えることが可能になりました。






ノードZ

NA

AppServer

AppServer

AppServer

AppServer

…

WAS構成における基本用語

ノード– WASが管轄する論理的なマシン

• 通常は1ノード=1OS（筐体）

• 1OS内に複数のノードを配置することも可能

セル– 1つ以上のノードを論理的なグループでまとめたもの

• セル単位で各ノードを管理

• WAS Base/Expressでは通常意識しない

デプロイメント・マネージャー（DM）– セル内のすべての構成要素の集中管理を行うJava

プロセス• Webベースの管理インターフェース（管理コンソール）

などの管理機能を提供

ノード・エージェント（NA）– DMからの管理要求をアプリケーション・サーバーに

伝達するJavaプロセス

• ファイル転送サービス、DMとの構成の同期、および

パフォーマンス・モニターなどの管理機能を提供

セル

ノードA

DM

…

ノードB

NA

AppServer

AppServer

AppServer

AppServer

…

Express Base ND

DMノード：DMが属するノード

管理対象ノード：NAが属するノード

WASの基本構成をご説明します前に、WAS構成の基本用語であるセル・ノード・DM・NAについてまずご説明いたします。

セル

セルは、WAS の1つ以上のノードを論理的なグループにまとめたものです。

WAS ND構成で使用されるものであり、WAS Baseでは通常は意識しません。

ノード

ノードは、WASが管轄する論理的なマシンです。多くの場合、ネットワーク上で識別可能な IP ホスト・アドレスを持つ物理的なマシンに一致します。

NDの複数台構成では、あるノードをあるセル配下に構成することを、「統合する」といいます。各ノードで実行するアプリケーション・サーバーの管理は、DMがノード・エージェントと通信することにより行います。

デプロイメント・マネージャー（DM）

DMは、セル内のすべての構成要素の集中管理を行います。DMは、それ自体が専用のアプリケーション・サーバー上で実行されていて、Webベースの管理インターフェース（管理コンソール）などの管理機能を提供しています。

ノード・エージェント

ノード・エージェントはDMからの管理要求をアプリケーション・サーバーに伝達するJavaプロセスで、セルに統合されているすべてのノードで実行されます。また、ファイル転送サービス、構成の同期、およびパフォーマンス・モニターなどの管理機能を提供します。ノード・エージェントは単なる管理エージェントで、エンタープライズ・アプリケーションが提供する機能には関与しません。ノード・エージェントは、ノードをセルに追加すると、自動的に作成されます。逆に、セルに追加するまではノード・エージェントは作成されません。






WebSphereプロファイル

プロファイル管理ツール / manageprofilesで作成

セルプロファイル ASNADM

１ノード上のJavaプロセスの実行環境を定義するディレクトリ

– 定義されるJavaプロセスの構成ファイル・データファイル・ログ等を保持

目的に応じてプロファイルを作成

– WAS関連プロセス共通で使用するバイナリ・コードはインストール時に導入される

– 導入の負荷軽減、ディスクスペース軽減、フィックス適用負荷軽減が見込まれる

プロファイル管理ツール or manageprofilesコマンドで作成・管理

WAS製品コード

<WAS_root>/WebSphere/AppServer

Installation Managerで導入

DM プロファイル

アプリケーション・サーバープロファイル

ジョブ・マネージャープロファイル

管理エージェントプロファイル

カスタムプロファイル

セキュア・プロキシープロファイル

DM

ASNA

Job Manager

AdminAgent

NA

Secure Proxyプロファイル

Express Base ND

☆：Express / Baseで使用可能なプロファイル

☆

☆

WASのノードを実際に定義するには、構成に応じたプロファイルを作成する必要があります。

プロファイルは、1ノード上のJavaプロセスの実行環境を定義するディレクトリです。WAS関連のプロセスが共通で使用するバイナリ・コードとJavaプロセスの定義情報を分けて導入・構成することで、セルに対しノードを追加する場合など、目的に応じてプロファイルを作成するのみで済み、不要にバイナリコードを導入する必要がなくなりますので、環境作成・変更にかかる負荷の軽減やディスクスペースの削減が見込まれます。

プロファイルに関しては、プロファイル管理ツールあるいはmanageprofilesコマンドで作成・管理する必要があります。






WebSphereプロファイルの作成・管理（1/2）

プロファイル管理ツール（PMT）– GUIによるプロファイル作成が可能

– 64bit版WASに対応

プロファイル･タイプの選択画面セルプロファイル管理プロファイルアプリケーション･サーバープロファイルカスタム･プロファイルセキュア･プロキシープロファイル（構成のみ）

プロファイル･タイプの選択画面セルプロファイル管理プロファイルアプリケーション･サーバープロファイルカスタム･プロファイルセキュア･プロキシープロファイル（構成のみ）

New

※プロファイルの削除など作成以外の作業はmanageprofilesコマンドを使用する必要あり

WebSphereプロファイルを管理するため、GUIの『プロファイル管理ツール（Profile Management Tool : PMT）』およびCUIの『manageprofilesコマンド』の2種類の管理方法が提供されています。これらは使用目的に応じて使い分ける必要があります。

まず、プロファイル管理ツールはプロファイルの作成に使用できるウィザードで、『<WAS_ROOT>/bin/ProfileManagement/pmt.<実行ファイル拡張子>』コマンドで起動します。このツールでは、対話式でのプロファイルの作成・拡張と作成済みのプロファイルの確認が可能で、その他プロファイルの削除などの作業はmanageprofilesコマンドを使用する必要があります。

WAS V7までは、64bit版のWASにはプロファイル管理ツールは使用できず、manageprofilesコマンドからプロファイルを作成せざるを得ない背景がありましたが、WAS V8.0より64bit版のWASでも使用できるようになりました。






WebSphereプロファイルの作成・管理（2/2）

manageprofilesコマンド– プロファイルの作成・削除・バックアップ・リストア等を実施可能

– 使用方法：

• モードは全18種類

create プロファイルの作成

delete プロファイルの削除

listProfiles プロファイルのリスト

– 使用例：

• デプロイメント・マネージャー・プロファイルの作成

#<WAS_ROOT>/bin/manageprofiles.sh（bat） –create –profileName Dmgr01 -profilePath <WAS_ROOT>/profiles/Dmgr01–templatePath <WAS_ROOT>/templates/profileTemplates/management-serverType DEPLOYMENT_MANAGER -cellName iseCell01 –nodeName iseNode01 -hostName iseHost01

#<WAS_ROOT>/bin/manageprofiles.sh （.bat） -<mode> -<option> <parameter> ･･･

backupProfile プロファイルのバックアップ

restoreProfile プロファイルのリストア

help ヘルプ etc..

manageprofilesコマンドは『<WAS_ROOT>/bin/manageprofiles.<実行ファイル拡張子>』で呼び出すコマンドラインツールです。プロファイルの作成など選べるプロファイル操作（モード）は18種類（create, augment, delete, unaugment, unaugmentAll, deleteAll, listProfiles, listAugments, backupProfile, restoreProfile, getName, getPath, validateRegistry, validateAndUpdateRegistry, getDefaultName, setDefaultName, response, help）あります。

例えばデプロイメント・マネージャー・プロファイルを作成する場合は上記コマンドのようにコマンドを発行します。

manageprofilesコマンドの詳細に関しては、下記リンク先をご参照ください。

Information Center - 「manageprofiles コマンド」

http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/com.ibm.websphere.migration.nd.doc/info/ae/ae/rxml_manageprofiles.html






WASの基本トポロジー

アプリケーション・サーバー・ノード構成（WAS Express / Base）

ノードA

アプリケーション・サーバーアプリケーション・サーバー

アプリケーション

管理サービス/JMX 構成サービス

アプリケーション管理

管理コンソール･アプリケーション

セル構成情報

ノード構成情報

AS構成情報

管理コンソール

wsadmin

セル構成（WAS ND）

プロファイル

ノードZ






セル構成情報


AS構成情報


wsadmin

プロファイル

・・・

ノードが増加⇒管理インターフェースが増加DM管理下に置かれるノードが増加しても

管理インターフェースは1つのまま

セル

プロファイル

プロファイル

ノードB

DM管理サービス/JMX 構成サービス



セル構成情報


AS構成情報


wsadmin

ノードA

NANA


管理サービス/JMX 構成サービスノード構成情報

管理サービス/JMX


AS構成情報

WASの基本トポロジーについて、ご説明いたします。

まず、WAS Express / Baseの場合、アプリケーション・サーバー・ノード構成と呼ばれる、1ノードに1アプリケーション・サーバーが配置される構成が基本の構成になります。アプリケーション・サーバーに管理コンソールが組み込まれるため、アプリケーション・サーバーを追加するに従い、管理負荷が増大することが懸念点として挙げられます。

WAS NDの場合はセル構成と呼ばれる、DMで各ノードの構成要素を集中管理する構成が基本の構成になります。アプリケーション・サーバー・ノード構成と違い、アプリケーション・サーバーをノード内に複数たてることも可能ですし、ノードを追加する場合もDMにノードを登録しさえすれば、常に1つの管理コンソールで管理を行うことが可能です。






混合バージョン・セルの構成 NDExpress Base

WAS V8セルは、V6.x/V7.0のノードを統合管理可能

– V6.x/V7.0からの段階的な移行と、継続的なオペレーションが可能

– V5.xのノードはV7.0と違い、統合できないことに注意

セル

DM

ND V6.1 ノード

NA

App ServerV6.1

App ServerV6.1

ND V7.0 ノード

NA

App ServerV7.0

App ServerV7.0

ND V8.0 ノード

NA

App ServerV8.0

App ServerV8.0

ND V6.0 ノード（End of Service）

App ServerV6.0

App ServerV6.0

NA

DMノード

V8.0 デプロイメント・マネージャー

管理者

セル構成に関し、WAS V8.0でのセルは、前バージョンのV6.x/V7.0のノードを統合管理することが可能です。これにより、V6.x/V7.0からの段階的な移行と、継続的なオペレーションが可能です。

ただし、V7.0のセルと違い、V5.xのセルは統合できないことにご注意下さい。また、混在バージョン・セル環境下で段階的な移行を行う場合、バージョン間の差異による注意事項があります。「マイグレーション」のセッションもご参照下さい。






Node1

AppServer

クラスター

同じJava EEアプリケーションを実行するアプリケーション・サーバーのグループ

クラスターに所属するアプリケーション・サーバーをクラスター・メンバーと呼ぶ

クラスターを作成することにより、処理の負荷分散・引継ぎがサポートされる

クラスターの種類– 垂直クラスターと水平クラスターの併用も可能

NDExpress Base

拡張性

パフォーマンス

リソースの有効活用

運用管理

耐障害性筐体・OS障害

プロセス障害

△ （限界がある）

△ （必ずしも向上しない）

○ （リソースの有効活用が可能）

○ （管理対象ノードは少ない）

×

○ ○

△ （台数分のリソースが必要）

○

△ （管理対象ノードが増加）

○ （リニアに向上）

○

Node1

AppServer

AppServer

・・・

・・・

NA

IHS Plug-in

垂直クラスター構成

・・・

Node2

AppServer

IHSPlug-in

水平クラスター構成NA

NA

アプリケーションに対するパフォーマンス・可用性を向上させるため、複数のアプリケーション・サーバーに同一のアプリケーションを稼動させる場合が多いです。

アプリケーション・サーバーを単純に増やすという選択肢もありますが、WAS NDにおいてはクラスターと呼ばれる、アプリケーション・サーバーのグループを作成することが可能です。

クラスターを構成することで、クライアントからの処理の負荷を分散させるのみならず、クラスターに属するサーバー（クラスター・メンバー）間でのセッションの引継ぎやメッセージングのフェールオーバーなど様々な高可用性機能を使用することが可能になります（高可用性機能に関しては後述します）。

クラスターの基本トポロジーとして、1OS内でクラスターを組む垂直クラスター構成と複数OS（異なるOSでも可）でクラスターを組む水平クラスター構成の2種類あります。両者を合わせたクラスターも作成可能ですので、WASを動かすサーバーのスペックやOS障害時の可用性、将来的な拡張性などを考慮したうえでクラスターの組み方を検討する必要があります。






AppServer

シンプル・クラスター構成 Base

複数のExpress/Baseスタンドアロン・サーバーから構成されるクラスター

WAS NDで実現できるクラスターと違い、以下の制限があることに注意– IHSプラグインからの割り振りは25台（25 JVM）まで

• Expressは2台（2JVM）まで

– セッション管理はDB複製のみ、セッションのフェールオーバーは5台（5JVM）まで

• Expressは2台（2JVM）まで

– 構成変更・管理は各サーバー毎に実施する必要あり

– 構成ファイル（plugin-cfg.xml）をpluginCfgMerge.sh（.bat）で生成する必要あり

NDExpress

・・・

Node1

AppServer

Node25

AppServer

IHSPlug-in

シンプル・クラスター構成

Node2

5台までOK

割り振りは25台までOK

DB

pluginCfgMerge.sh（.bat） or 手動で

plugin-cfg.xmlを作成

WAS Base/Expressにおいてもシンプル・クラスターと呼ばれるクラスター構成をとることが可能です。

但し、WAS NDの持つ高可用性機能の多くが使用できず、割り振り台数にライセンス上の制限が設けられていることに注意が必要です。

WAS Baseの場合、IHS （IBM HTTP Server）プラグインからBaseサーバーへの割り振りに関し、25台（25 JVM）まで割り振り制限、セッション・フェールオーバーを行うためのDBへのパーシスタンスは5台までの制限があります（DB2のライセンスに関しては、WASのライセンスにセッション管理の用途でDB2が同梱されているため、追加のライセンスは発生しません）。

WAS Expressに関しては、2台までのプラグイン割り振りと2台までのセッション・パーシスタンスになります。

さらに、シンプル・クラスターの場合、構成変更・管理は各アプリケーション・サーバー毎に実施する必要があり、プラグインからの割り振りに対しIHS:WASを1:Nの関係に定義するために手動で構成ファイルを書き換えるか、pluginCfgMergeスクリプトを実行することで構成ファイルを生成する必要が生じることにも注意が必要です。






19

シンプル・クラスター選択指針

構成における考慮点

構成変更に関して

負荷分散に関して

高可用性に関して

変更の度に手動でプラグイン生成、マージ、伝搬の作業が発生するが対応可能か？WASノードの追加、アプリケーションの追加・更新、仮想ホスト変更、・・・

IHSのラウンドロビンでよいか？

アプリケーション・サーバーの負荷を考慮した割り振りは必要ないか？

セッション管理を使用する場合5台まででよいか？

HAマネージャーのような仕組みは必要ないか？

2フェーズ・コミットなどのトランザクション管理は必要ないか？

メッセージングの高可用性などの要件はないか？

すべてYesならシンプル・クラスターでOK19

このシンプル・クラスターの選択の指針として、以下の3つを考える必要があります。

①構成変更

前頁でご説明しましたように、各サーバー毎に作業を行わなくてはならず、台数が多くなるほど運用の負荷も増大します。後述しますWASの管理系コンポーネントで運用の負荷を軽減することは可能ですが、そうした運用負荷に対しシェルで自動化するなどの作りこみを検討する必要があります。

②処理の負荷分散

IHSで提供されるラウンドロビンのような仕組みで要件を満たすか検討する必要があります。より高度な負荷分散/流量制御の仕組みを使いたい場合には別途ロードバランサーを構築する必要があります。また、シンプル・クラスターでセッション管理を使用する場合には5台までなので、より多いサーバー台数でのセッション管理が必要である場合はシンプルクラスターを選択することは難しいです。

③高可用性

DB2へのセッション・フェールオーバー以外では、高可用性の機能は提供されません。NDのようにHAマネージャーがメンバーの稼動状況を確認する方法や、トランザクション管理、メッセージングの高可用性は実現できません。これらの仕組みを使用したい場合には、NDのクラスターが必要となります。






IBM HTTP Server （IHS） & Web Server Plug-ins

















以上がWebSphere Application Serverの基本トポロジーのご説明になります。

WASの高可用性機能に関しては、他のコア・コンポーネントの説明の後にご説明いたします。

続きまして、WASが提供するWebサーバー・コンポーネントであるIBM HTTP Server （IHS）とWeb Server Plug-insについてご説明いたします。






IBM HTTP Server– Apache HTTP Server （バージョン2.2.8）に機能を追加したWebサーバー

• WAS管理コンソール上で管理可能（Webサーバーの定義が必要）

• 証明書管理ツール（IBM Global Security Kit V8）の提供

バージョン7のコマンド体系（gsk7cmd / gsk7capicmd）を統一（gskcapicmd）

サポートする暗号群（cipher suite）にSHA-2を追加

• 【Windows系以外】 64bit - ソフトウェア・コンポーネントの提供

Web Server Plug-ins– WASとコミュニケーションを行うためのプラグイン

– WebサーバーからWASへ重み付きラウンドロビンで負荷分散を実施可能

– Webサーバー・プラグイン構成ツールによるWebサーバー構成サポート提供

• 従来通り管理コンソールやwsadminコマンドでの構成も可能

IBM HTTP Server / Web Server Plug-ins Express Base ND

New

New

IBM HTTP Serverは、2.2系のApache HTTP ServerにIBM独自のモジュール（WASの管理コンソールからの管理を可能にするモジュールやSSL関連のセキュリティー・モジュールなど）を実装したWebサーバーです。

V8.0になり、証明書管理ツールであるGSKitのバージョンアップも行われ、特に今まで2系統あったコマンド群が1つに集約され、OSに依存せず統一した手順で証明書の運用管理を行うことが可能になりました。また、サポートする暗号群もより強度なものが加わり、より安全なSSL通信をクライアントに提供することが可能になりました。さらに、V7.0まで一部OSを除いて32bit-ソフトウェア・コンポーネントの提供でしたが、V8.0よりWindowsを除き64bit-ソフトウェア・コンポーネントが提供されるようになりました。

（参考） IHS 32bit版とIHS 64bit版の注意点（WAS-08-042）

http://www-06.ibm.com/jp/domino01/mkt/cnpages1.nsf/page/default-0004B65F

Web Server Plug-insはIHS等WebサーバーとWebSphere Application Serverとの間のコミュニケーションを行うために必要なプラグインで、Webサーバー１台からWAS複数台へ重み付きのラウンドロビンでリクエストの負荷分散を行うことが可能です。

V8.0よりWeb Server Plug-insの構成定義をWebサーバー・プラグイン構成ツールによりGUIで行うことが可能になりました（従来通り管理コンソールからも構成はできます）。 Webサーバー・プラグイン構成ツールでの定義の流れに関しては、次ページの参考資料をご参照ください。






【参考】Webサーバー・プラグイン構成ツールでのＷｅｂサーバー定義の流れ

New①Webサーバー・プラグイン構成ツール（WebSphere Customization ToolBoxに同梱）の起動

②Webサーバープラグインの導入ディレクトリの登録

③Webサーバーの定義（ローカル or リモート構成かも選択）

④configure〈Webサーバー定義名〉.sh（.bat）の配布

Webサーバーの自動定義

ローカル構成の場合

リモート構成の場合

⑤Express/Baseの場合はアプリケーション・サーバー、NDの場合はDM,NAの起動

⑥configure〈Webサーバー定義名〉.sh（.bat）を実行し、管理コンソールより変更を保存（NDの場合同期処理実施）

上記はWebサーバー・プラグイン構成ツールでのWebサーバーの定義（WAS管理コンソール上でWebサーバーを管理するための設定）の流れを示したものです。実際の構成手順に関しては、参考資料P67-73をご参照ください。

なお、従来通り管理コンソール・wsadminでのWebサーバー定義も可能です。






マシンA

Webサーバー基本トポロジー

① ローカル構成

③ リモート構成（管理ノード）

– ノードエージェント経由での管理

②リモート構成（管理外ノード）

④リモート構成（IHS管理サーバー）

– IHS管理サーバー経由での管理（デフォルト:8008）

マシン

AppServer

AppServerWebServerWebServer

DM

セル

Plug-inConfig

XML filePlug-in Module

HTTP（S）

マシンB

AppServer

AppServer

DM

セルマシンA

WebServerWebServer

Plug-inConfig


HTTP（S）

プラグイン構成ファイルの手動配布が必要

マシンB

AppServer

AppServer

DM

セルマシンA

WebServerWebServer

Plug-inConfig


HTTP（S）

プラグイン構成ファイルを管理コンソールから配布

マシンB

AppServer

AppServer

DMセル

WebServerWebServer

Plug-inConfig


HTTP（S）

NA NA

NANA

NA IHSAdmin

プラグイン構成ファイルを管理コンソールから配布

WAS V8.0でのWebサーバーは、V6.xやV7.0と同様に、アプリケーション・サーバーと同一ノードでも別ノードでも配置可能です。

①ローカルWebサーバー構成

アプリケーション・サーバーと同一ノードとなりデプロイメント・マネージャーからの管理が可能で、WAS管理コンソールから、プラグイン構成の生成・伝播 / Webサーバーの開始・停止 / ログファイルの表示、構成ファイルの編集が実施可能です。

②リモートWebサーバー構成（管理外ノード）

Webサーバーとアプリケーション・サーバーは別ノードで、WASから見て管理外ノードとなります。 WAS管理コンソールから、プラグイン構成の生成が実施可能ですが、デプロイメント・マネージャーから管理できないので、デプロイメント・マネージャーのマシンでプラグイン構成ファイルを作成後、手動でWebサーバーマシンにコピーする必要があります。

③リモート構成（管理ノード）

リモートのWebサーバーマシン上にノード・エージェントを作成し、Webサーバーマシンを管理ノードとしてデプロイメント・マネージャー経由で管理することが可能です。WAS管理コンソールから、プラグイン構成の生成・伝播/ Webサーバーの開始・停止 / ログファイルの表示 / 構成ファイルの編集が実施可能です。

④リモート構成（IHS管理サーバー経由）

リモートのIHSマシン上にIHS管理サーバーを導入し、このサーバー経由でデプロイメント・マネージャーがHTTPコマンドを発行します。WAS管理コンソールから、プラグイン構成の生成・伝播 / Webサーバーの開始・停止 / ログファイルの表示 / 構成ファイルの編集が実施可能です。






Edge ComponentsPresentation Tier

Business Logic TierWeb Server TierProxy TierLoad Balancer Tier















続いて、Web基盤の中でユーザーに一番近いフロントエンド用のコンポーネントであるEdgeComponentsについてご説明いたします。






Edge Components

WAS NDに同梱されるソフトウェア提供の負荷分散装置

WASと組み合わせて、高可用性･高拡張性･パフォーマンスを向上

重要

非推奨から

安定化へ!! CBR

Load Balancer for IPv4 （LLB） Caching Proxy （CP）

・MAC転送・NAT/NAPT転送・KCBR転送

Load Balancer

Caching Proxy付きCBR

Load Balancer for IPv4 and IPv6（ULB）

Load Balancer・MAC転送

・カプセル化転送

・HA構成時のTCP/HTTPセッション引継ぎ機能の実装・TCPリセットの送信機能の実装・dscontol manager quiesceコマンドの仕様変更

New

NDExpress Base

Edge Componentsは、WAS ND に同梱されるソフトウェア提供の負荷分散装置で、主に

・カーネルスペースで動作する負荷分散装置のLoad Balancer for IPv4 （Legacy Load balancerとも呼ばれます。以下LLBと記載します）

・主にLLBのCBRコンポーネントと組み合わせて使用するプロキシー・コンポーネントのCaching Proxy（以下CPと記載します）

・V7.0から提供されたユーザースペースで動作する負荷分散装置のLoad Balancer for IPv4 and IPv6（Userspace Load balancerとも呼ばれます。以下ULBと記載します。）

の3つのコンポーネントを有します。

V8.0で重要なアップデートとして、V6.1より非推奨であったLLBとCPが安定化に移行したこと、ULBで機能拡張が行われたことが挙げられます。






Edge Components LLB / CP の機能安定化

V6.1より非推奨（廃止予定）と発表されていたLLB / CPがV8.0より安定化に変更– WAS ND V8.0以降のバージョンアップにおいてもLLB、CPが提供・サポート

考慮事項– バージョン8のLLB、CPがサポートしているOSには以下の制限がある

• LLBAIX： 6.1, 7.1 をサポートRed Hat Enterprise Linux （RHEL）： 4.0のみサポート（z/Linuxの場合は31bitのみサポート）SUSE Linux Enterprise Server （SLES）：9.0 のみサポートWindow： Windows Server 2003 のみサポートSolaris： Solaris 10 SPARC（32bit）のみサポート

• CPAIX, HPUX：32bit, 64bitOSをサポート（32bitアプリケーションとして動作）その他OS：32bit OSのみサポート

– 今後出荷される新OSに対しLLB,CPの対応予定はない

推奨されるアクション– 今後のシステムのマイグレーションに関しては、V6.1/V7.0の場合と同様、以下が推奨

• 既存システムでLLBを使用している場合は、ULBへの移行

• 既存システムでCPを使用している場合は、WebSphere Proxy Server, WebSphere DMZ Secure Proxy Serverなど別製品への移行、あるいはトポロジー変更

– システムの新規構築においてはLLB、CPを採用しない構成を検討

重要

まず、LLBとCPの安定化について、ご説明いたします。

V6.1よりLLB/CPは非推奨（廃止予定）となり、当初はV8.0をもってLLBとCPの提供は終了予定でしたが、今後製品として機能拡張は行われない代わりに、今後のバージョンアップにおいても製品が提供・サポートされ続ける予定へと変更になりました。

Information Center - 「Stabilized features」

http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rmig_stabfeat.html

ただし、V8.0でのLLB、CPがサポートしているOSには以下の制限があり、今後出荷される新OSに対しLLB,CPの対応予定はありません。今後はLLB/CPを使用せず、ULBを使用する構成をとることが推奨されます。






Load Balancer for IPv4 and IPv6（ULB）

Executor / Manager / Advisorの3つのコンポーネントで動作

転送方式はＭＡＣ転送方式とカプセル化転送方式の2種類

– ともにULBでのポート変換は行えないことに注意

2台でアクティブ-スタンバイのHA構成をとることが可能

クライアントIPによるセッション維持が可能（IPSticky）

V8での機能拡張によりLLBからの移行がより容易に

– HA構成時のTCP/IPSticky情報の引継ぎ機能の実装（repstrategyオプション）

• HAに関し、LLBと機能的に同等になった

– TCPリセットの送信機能の実装（resetオプション）

• 割り振り先サーバーの障害を検知した際に、接続中のクライアントにTCPリセットを送信可能になった

– dscontol manager quiesceコマンドの仕様変更

• 特定のクラスターに属するサーバーの割り振り制御が可能になった

Client Server

Server

Server監視

割り振り

Cluster

Manager Advisor

dsserver (java)

User Space

リクエスト Executoribmlb2 (native C)

Executorから接続数を受け取り、それらの情報を基に負荷を計算してExecutorに”重み”として伝える

Managerに接続数を伝え、“重み”を基に割り振りを行う

サーバーの監視を行いレスポンスの時間をManagerに伝える

New

以下、LLB/CPからの移行が推奨されているULBについてご説明いたします。

ULBはExecutor/Manager/Advisorの3つのコンポーネントから成るシンプルな負荷分散装置で、定期的な監視リクエストをAdvisorから送信し、その結果をManagerが判断、Managerからの割り振り指示を受けてExecutorがリクエストを転送するという一連の動作をとります。アクティブ－スタンバイのHA機能をULBで有しており、ULBの冗長化も容易に行えます。

V8.0において重要なポイントとしては、

・TCP/HTTPセッションの引継ぎの実装

・TCPリセットの送信機能の実装

・dscontrol manager quiesceコマンドの仕様変更

が挙げられ、これらの機能拡張によりLLBからULBの細かな機能差が解消され、LLBからの移行がより容易になりました。

ULBとLLBの差異につきましては、V7.0の資料になりますが、以下のリンク先資料をご参照ください。

Edge Components V7 ガイド - 「1.Overview」

http://www.ibm.com/developerworks/jp/websphere/library/was/edge7_guide/






Load Balancer for IPv4 and IPv6（ULB）の基本トポロジー【MAC転送】

MAC転送方式

処理の流れ

DMZ（非武装地帯）セキュアゾーン

AppServer

AppServer

ユーザー

Load Balancer （Active）

Load Balancer

（Standby）IHS Plug-in

IHS Plug-in

DATA・・・

・・・

TCPdst 80

IPsrc 9.188.52.100dst 10.10.10.10

MACsrc bb:bbdst cc:cc

DATA・・・

・・・

TCPsrc 80

IPsrc 10.10.10.10dst 9.188.52.100

MACsrc cc:ccdst aa:aa

IP 9.188.52.100DATA・・・

・・・

TCPdst 80

IPsrc 9.188.52.100dst 10.10.10.10

MACsrc aa:aadst bb:bb

リクエストリクエスト

レスポンスユーザー


IHS Plug-in

MAC cc:ccIP 10.10.10.3

ClusterIP 10.10.10.10（lo0）Port 80

MAC bb:bb IP 10.10.10.5

ClusterIP 10.10.10.10Port 80

クラスター・アドレスに対しループバック設定 or

iptablesの設定が必要

MAC aa:aaIP 10.10.10.1

MACヘッダーのみ変更

ULBでの転送方式であるMAC転送方式とカプセル化転送方式での基本トポロジーを以下説明します。

MAC転送方式での基本トポロジーは上記の通りです。MAC転送方式はユーザーのリクエストに対し宛先MACアドレスを変換して転送する方式ですので、同一セグメント内での割り振りに限定されます。ULBとアプリケーション・サーバーのセグメントを分けたい場合は、通常IHS+Plug-insをULBと同じセグメントに配置し、リモート構成をとる必要があります。

割り振り先サーバーからのレスポンスはLoad Balancerを経由せずにユーザーへ返る動作（DSR:Direct Server Return, 直接サーバー返答）になります。

割り振り先サーバーに対しては、ループバック・インターフェースにクラスター・アドレスをエイリアス、あるいはLinuxの場合はiptablesでクラスターアドレスに対しリダイレクトの設定を行う必要があります。

ULBの導入されているOSに割り振り先サーバー・プロセスを同居させる同居構成をとることはできないことにご注意ください。






IHS Plug-in

Load Balancer for IPv4 and IPv6（ULB）の基本トポロジー【カプセル化転送】

カプセル化転送方式

処理の流れ

DMZ（非武装地帯）セキュアゾーン

AppServer

AppServer


Load Balancer

（Standby）

ユーザーIHS Plug-in

IHS Plug-in

GRE or IPIPトンネルの設定が必要Windows OSの場合は×

DATA・・・

・・・

TCPsrc 80

IPsrc 10.10.10.10dst 9.188.52.100

MACsrc cc:ccdst aa:aa

IP 9.188.52.100

リクエストリクエスト

レスポンスユーザー


MAC bb:bb IP 10.10.10.5

ClusterIP 10.10.10.10Port 80

MAC aa:aaIP 10.10.10.1

IP 10.10.20.11

GRE orIPIPHeader

IPsrc 10.10.10.5dst 10.10.20.11

DATA・・・

・・・

TCPdst 80

IPsrc 9.188.52.100dst 10.10.10.10

MACsrc bb: bbdst cc: cc

DATA・・・

・・・

TCPdst 80

IPsrc 9.188.52.100dst 10.10.10.10

MACsrc aa:aadst bb:bb

MAC cc:ccIP 10.10.10.254

GRE or IPIPヘッダーとIPヘッダーをLBで付加

セグメントを越えた割り振りをULBで実施したい場合は、カプセル化転送方式を使用することで実現可能です。

カプセル化転送方式はRFCで定義されているIP in IPまたはGRE（Generic Routing Encapsulation ）の仕様に基づいてユーザーからの既設パケットとは別にIPヘッダーを加えて転送します。割り振り先サーバーでは、転送されたパケットを受け取り処理するために、GREあるいはIP in IPトンネルの設定を実施しておく必要があります。MAC転送方式と同じくLoad Balancerを経由せずにユーザーにレスポンスを返します。

カプセル化転送方式の考慮点として、 Windows系OSのサーバーを割り振り先に指定することができないことが挙げられます。

（参考）IP in IP Tunneling http://www.ietf.org/rfc/rfc1853.txt（参考）Generic Routing Encapsulation （GRE）http://www.ietf.org/rfc/rfc2784.txt























後に、プロキシー・コンポーネントであるWebSphere Proxy Server と WebSphere DMZ Secure Proxy Serverについてご説明いたします。






ノードZ

AppServer

AppServer

…

WebSphere Proxy Server

Javaベースのプロキシー・コンポーネント

WAS管理コンソール上で管理が可能

基本機能

–Cache機能

–SSL通信・復号機能

ルーティング

NDExpress Base

セルノードA

Proxy

…ノードB

AppServer

AppServer

AppServer

AppServer

… AppServer

AppServer

–Webサーバー・プラグインとの連携

–セッションAffinityの維持（URI / Cookie）

■ ODC（オンデマンド構成）

同一セル内のWASへ動的に割り振り

アプリ追加

動的に構成変更し自動的に割り振り

ノードZ

ＩＨＳＩＨＳ

ノードA

Proxy

…ノードB

AppServer

AppServer

AppServer

AppServer

…App

Server

AppServer

■ 汎用サーバー・クラスター

特定のWASやIHSに対し割り振り（セル跨ぎ可）

セル1

AppServer

AppServer

セル2 セル3

指定したホスト名・ポートに対し割り振り

まず、WebSphere Proxy ServerはJavaベースのプロキシー・コンポーネントで、 WASのセル内に構成し、管理コンソール上でアプリケーション・サーバーと合わせて管理することが可能です。主な基本機能として、

・Cache機能

静的コンテンツ、動的コンテンツ、SSLコンテンツのキャッシュが可能です。

・SSL通信・復号機能

SSLの復号が可能です。クライアント→Proxy間をSSL通信、Proxy Server以降は通常のHTTP通信を行うことも、クライアント→Proxy ServerをSSL通信にし、Proxy ServerでSSLを復号してURLのチェックを行った後、再び暗号化を行い、後方へSSL通信を行うことも可能です。

・Webサーバー・プラグインとの連携

Webサーバー・プラグインから要求をProxy Serverに割り振ることが可能です。

・セッションAffinityの維持

Proxy ServerにてURIやCookieによるAffinity制御が可能です。

が挙げられます。

また、ルーティング方式は以下の2種類です：

・ODC（オンデマンド構成）によるルーティング

同一セル内のサーバーに対して追加構成をすることなく、動的に構成変更し割り振ることが可能なルーティング設定です。

・汎用サーバー・クラスターによるルーティング

特定のアプリケーション・サーバーやWebサーバー（セル跨ぎも可）に対して割り振る場合に使用するルーティング設定です。






セキュアゾーンDMZ（非武装地帯）

WebSphere Proxy Serverの基本トポロジー

Javaコンポーネントのため、DMZへの配置は推奨されない– Webサーバー・プラグインとの連携が可能なので、DMZにはIHSを配置する構成を検討

Proxyクラスター構成が可能– 同じ設定のProxy Server複数台の作成・構成変更が容易

Proxy Serverの前段にEdge Components等の負荷分散装置を配置– Proxy Server自身の機能によるHigh Availability構成は不可能

複数セルのルーティングを実現可能– 汎用サーバー・クラスター構成により実現

AppServer

Proxy AppServer

Load Balancer（Active）

Load Balancer

（Standby）

Proxyクラスター

IHS Plug-in Proxy

IHS Plug-inユーザー

WebSphere Proxy Serverの基本トポロジーについて、DMZの配置は想定されていないコンポーネントのため、DMZより奥のセキュアゾーンの配置が推奨されます。

アプリケーション・サーバーと同様、セル内でクラスターを作成することができますので、容易に同じ設定のProxy Serverを複数台構成できます。

また、複数台Proxy Serverを立てる場合、Proxy Server自身はHA機能を持ちませんので、前段に負荷分散装置を配置する必要があります。

さらに、上記図には記載はありませんが、Proxy Serverからある処理はセルAのアプリケーション・サーバー、またある処理はセルBのアプリケーション・サーバーに割り振るなど、複数セルのルーティングが可能です。但し、汎用サーバー・クラスター構成での環境構築を実施する必要があります。






WebSphere DMZ Secure Proxy Server

DMZ（非武装地帯）へ配置するために、セキュリティーを強化したProxy Server– 必要最低限のポートの開放

– デジタル署名されたJAR のみをロード

– well knownポートへは非特権ユーザーとして接続

静的ルーティングと動的ルーティングの2種類選択可能

– 静的ルーティングはxmlファイルに記載されたルーティングに従い処理

– 動的ルーティングは後段のWASのアプリの構成変更にあわせ、ルーティングを変更可能

管理コンソールでの直接の構成・管理はセキュリティー上実行不可能– 構成方法は以下の2通り

• A） wsadminコマンド

• B）別ノード（Configuration-Only）で作成した構成情報をexport/import

Secure

Proxy

インターネット

企業・組織外 AppServer

Admin Agent


A） wsadminコマンドA） wsadminコマンド

NDExpress Base

B）セキュアゾーンの管理コンソールで設定したProxyの構成情報を、wsadminコマンドにてControlledゾーンのSecure Proxy Serverにimportする

B）セキュアゾーンの管理コンソールで設定したProxyの構成情報を、wsadminコマンドにてControlledゾーンのSecure Proxy Serverにimportする

SecureProxy

ルーティング情報

管理者A

管理者B

続きまして、 WebSphere DMZ Secure Proxy Server（以下Secure Proxy）ですが、こちらはDMZ（非武装地帯）へ配置するためにセキュリティーを強化したProxy Serverです。具体的には、必要低限のポートの開放、デジタル署名されたJARのみをロード、well knownポートへは非特権ユーザーとして接続する等によりセキュリティーが強化されています。

Secure ProxyはWebSphere Proxy Serverと異なり、直接管理コンソールでの管理・運用を行うことができない点が大きな特徴です。設定変更するためにはwsadminコマンド（ローカル、Flexible Management経由）もしくは、別ノードでConfuguration-Onlyプロファイルを作成し、そのノード上の管理コンソールから設定したProxyの構成情報を、wsadminコマンドにてimport/exportする必要があります。

ルーティングに関しては、xmlファイルに基づき割り振りを行う静的ルーティングと、WebSphere Proxy ServerのODC（オンデマンド構成）と同様にWASのアプリケーションの構成変更に合わせて動的にルーティングを制御する動的ルーティングが使用可能です。






WebSphere DMZ Secure Proxy Serverの基本トポロジー

DMZ（非武装地帯）へ配置

Secure Proxyの前段にEdge Components等の負荷分散装置を配置

– Secure Proxy自身の機能によるHigh Availability構成は不可能

複数セルのルーティングを実現可能

– 静的ルーティングの場合• それぞれのセルに対するルーティング情報（xmlファイル）を配置

– 動的ルーティングの場合• Secure Proxyと他のセルの間でコア・グループ・ブリッジのセットアップが必要


AppServer

AppServer

Load Balancer（Active）

Load Balancer

（Standby）

ユーザー

Secure Proxy

Secure Proxy

Secure Proxyの基本トポロジーについて、製品の位置付けよりDMZに配置します。

WebSphere Proxy Serverと同様、Secure Proxy自身はHA機能を持ちませんので、前段に負荷分散装置を配置する必要があります。

さらに、Secure Proxy Serverから、ある処理はセルAのアプリケーション・サーバー、またある処理はセルBのアプリケーション・サーバーに割り振るなど、複数セルのルーティングが可能です。






プロキシーの選択指針

○○△△非同期要求処理

○○○×複数セルのルーティング

○×○○DMZ配置

必要必要不要不要NDライセンス

×○－×Web サービスのアフィニ

ティーとフェールオーバー

○○××SIPプロキシー

××○○CGIの使用

GUIでの運用・管理は限

定的プロキシ先との関係は1:1

備考

○○×○（ラウンドロビン）ロード・バランシング

○○－○セッション・アフィニティー

IHS + Web ServerPlug-ins

IHS + mod_proxy（参考）

WebSphere Proxy Server

WebSphere DMZ Secure Proxy Server

どこに配置するか、複数セルに対しルーティングを行うか、どのようなアプリケーションを使用するか、の観点で選択

WASには複数のプロキシー製品（あるいはプロキシー機能を有する製品）がありますが、各プロキシーの選択指針について代表的な差異をまとめたものが上記表になります。このうち、IHS+mod_proxyによる構成は、開発元からのサポートが提供されない場合があるため、WASシステムでの使用はお勧めできません。参考情報として項目に載せていることにご注意ください。

Supported configurations Questions and Answers - Can I use the IBM HTTP Server proxy feature?

http://publib.boulder.ibm.com/httpserv/ihsdiag/support.html#PROXY

プロキシーの選択指針として、どこに配置するかが1つ目のポイントで、お客様要件によりDMZに配置しなければならないような場合はWebSphere Proxy Serverは選択できません。

複数のセルに対しプロキシーとしてルーティングを実現すべきかが2つ目のポイントで、お客様要件により複数のWASセルに割り振りを行う必要がある場合はIHS＋Web Server Plug-insでは対応できず、かつ負荷分散もプロキシーで実施しなければならない場合はWebSphere Proxy Server / DMZ Secure Proxyサーバーを選択することを検討する必要があります。

また、1番重要な選択ポイントとして、どのようなアプリケーションを使用し、システムを構築するのかが挙げられます。Webサービスを使用していて、Webサービスに対しアフィニティーとフェールオーバーを実施する要件がある場合にはWebSphere Proxy Server を使用する必要があります。さらにCometのポーリング処理など非同期要求処理が求められるアプリケーションを使用する場合、Apache 2.2系のWebサーバーでは1スレッド=1接続の縛りがあるため、ポーリング処理にスレッドが占有されてしまいますので、多くのクライアントが同時に使用するシステムの場合はサーバー・リソース（スレッド）消費が課題になりますが、WebSphere Proxy Server/DMZ Secure Proxy Serverの場合は非同期I/O で1スレッドで複数接続を処理できます。非同期要求処理が求められる場合はWebSphere Proxy Server/DMZ Secure Proxy Server の採用を検討するのも1つの選択肢です。

Information Center – 「Selecting a front end for your WebSphere Application Server topology」

http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/com.ibm.websphere.nd.iseries.doc/info/iseriesnd/ae/cwsv_topology.html






3636

【参考】WebSphere Virtual Enterprise （WVE）

WebSphere Application Server他社Java EEサーバー

Apache，PHP

オンデマンド・ルーター（ODR）

優先度高

優先度低

購入処理

商品閲覧

買い物中

クライアント

流量少

流量多

キュー

キュー

L3

L2

L1 1秒高

5秒

3秒

目標平均応答時間

低

高

優先度リクエスト AppEdition2

Java VMリソースの動的配置サービスポリシーによる優先制御

ヘルスポリシーによる自動回復処理

ルーティングポリシーによる条件ルーティング

AppEdition1

仮想化によるサーバー資源の

有効利用

リクエストのQueuingによる

過負荷防止

回復処理の自動化

アプリケーションエディションコントロール

設定されたサービスポリシーに従ってリクエストを優先付け

アクセス集中時にも重要な処理を確実に実行

ヘルスモニタリング機能が応答時間やCPU，メモリを監視

異常発生時に自動的に切り離し・再起動などを実行

アプリケーションの複数のバージョンをサーバー上で同時実行

テストユーザーのみを新バージョンに割振り本番環境でのテストも可能に

動的アプリケーション配置により負荷に応じてJava VM数を動的に変更

サーバーの剰余能力を適利用

自動リソース適化と業務の優先度に応じたサービスレベル管理

なお、複数アプリケーションがあり、それらの処理の優先度をつけたい等、よりインテリジェントな要件がある場合、WebSphere製品のWebSphere Virtual Enterpriseで提供されるODRと呼ばれるプロキシー・コンポーネントを使用することで、そうした要件を実現させることが可能です。

WebSphere Virtual Enterpriseに関して、詳しくは下記リンク先資料をご参照ください。

developerWorks: WebSphere Virtual Enterprise

http://www.ibm.com/developerworks/jp/websphere/category/wxd/wve.html







以上でWASが提供する、Web基盤を構成するためのコンポーネントを全てご説明いたしました。

続きまして、これらWASのコア・コンポーネントで構築するシステムに対しWAS NDで提供する高可用性機能をご説明いたします。







1）セッション・パーシスタンス– サーバー障害時に、セッション情報を保持する機能

– セッション情報のコピー先として、DBとメモリー間複製の2種類

2）ワークロード管理– 複数のサーバーで処理を分散し、障害時には他のサーバーで処理を引き継ぐ機能

•負荷分散装置 WLM•Proxy Server WLM•Webコンテナー WLM•EJBコンテナー WLM•Messaging Engine WLM

3） HAマネージャー– アプリケーションの実行に関する動的な情報を共有する機能

•障害検知

•Javaプロセス間の情報共有

•シングルトン・フェールオーバー

NDExpress Base

WAS NDが提供する高可用性の機能は大きく分けて3つ挙げられます。

これらを順番にご説明いたしますが、ワークロード管理に関しては概念の説明にとどめ、詳細は参考資料・リンクにかえさせていただきます。






セッション・パーシスタンスワークロード管理HAマネージャー


まずはセッション・パーシスタンスについてです。






セッション・パーシスタンス

セッション・パーシスタンスとは

セッション情報を異なる場所にコピーし、アプリケーション・サーバーの障害時にセッション失効を回避する機能

セッション・パーシスタンスの種類

– セッションDBによるパーシスタンスとメモリ間複製によるパーシスタンスの併用はできない

セッションオブジェクトをDBに保管他のAppServerのメモリー上にセッションオブジェクトのコピーを作成

Node2

AppServer

Node1

AppServer

DB

セッション#1

セッション#１のコピー

セッション#1 Node2

AppServer

Node1

AppServer

セッション#1

セッション#１のコピー

セッションDB メモリー間複製 NDExpress BaseNDExpress Base2台まで 5台まで無制限

Webアプリケーションでは、例えばショッピング・サイトの買い物かごなど、ユーザーの状態を保持したいという要件がある場合が多いです。しかし、HTTPはステートレスなプロトコルであるため、ユーザーの状態を保持することができません。そこで、Webアプリケーションでは、サーバー側にセッション・オブジェクトを作成しユーザーと関連付けることでユーザーの状態を保持します。このような仕組みをセッション管理と呼びます。また、セッションの維持（セッション・アフィニティー）はアプリケーション・サーバーの前段のコンポーネントで行う必要があります。

セッション・パーシスタンスとは、セッション情報（セッションオブジェクト）のコピーを異なる場所に保管することで、アプリケーション・サーバーの障害時にセッションの失効を回避する機能です。WAS NDV8.0では、セッション情報をDBへ保管するセッションDBと、他のアプリケーション・サーバーのメモリー上へセッション情報を保管するメモリー間複製の2つの方法を選択可能です。これらを併用することはできません。

※セッションDBによるセッション・パーシスタンスに関してはWAS Express /Baseでも使用は可能ですが、台数制限があることに注意が必要です。






メモリー間複製

複製ドメイン

App Server3

App Server2

App Server1

他AppServerの

セッション情報

Localのセッション情報

他AppServerのセッション情報


他AppServerの



IHS Plug-in

App Server5

App Server4

他AppServerのセッション情報

他AppServerの


App Server3

App Server2

App Server1




IHS Plug-in 複製ドメイン

peer to peer

client/server

クラスター

クラスター1クラスター2

NDExpress Base

ユーザー

ユーザー

：セッション・オブジェクト

以下の2種類の方式がある

– peer to peer– client/server

複製する単位を指定可能– 単一レプリカ（デフォルト）

– ドメイン全体

– 指定（レプリカ数を設定）

メモリー間複製では複製モードとして、peer to peer もしくは client/server を選択できます。

・peer to peerモード

リクエスト処理を行うクラスターのアプリケーション・サーバー間でセッションを保持する方法です。デフォルトでは1つのセッション・オブジェクトに関するレプリカが他サーバー上に1つ存在します。アプリケーション・サーバーに障害が発生すると、ホット・フェールオーバーと呼ばれる機能により、Webサーバー・プラグインがレプリカのあるアプリケーション・サーバーに割り振ることができます。

・client/server

リクエスト処理を行うクラスターとは別に、セッション・オブジェクトを保持するためのクラスターを構成する方法です。

なお、図中の複製ドメインとは、クラスター配下のアプリケーション・サーバー間でデータ複製を行うアプリケーション・サーバーの集合のことで、情報を共用する必要のあるすべてのアプリケーション・サーバーは、同じ複製ドメインに存在する必要があります。複製ドメイン内のアプリケーション・サーバー間でデータを複製する機能をデータ複製サービスと言い、HTTPセッションのメモリー間複製もデータ複製サービスを使用します。






■各セッション・パーシスタンスのスループット比較

メモリー間複製のパフォーマンス

■peer to peer （単一レプリカ）でのスループット

※セッション・オブジェクトの書き出しは・サーブレット・サービスの終了（End of servlet service）

・時間基準・手動更新（コーディングでの制御）

のどちらかを指定可能

CPU使用率は上がるが、サーブレット処理後に

セッション・コピーを指定してもスループットは

高い状態を維持

セッション・オブジェクトのサイズが極端に大きくならない限り、セッションDBとメモリー間複製にパフォーマンスの差はない（サイズは数KB以下が推奨）

重要

メモリー間複製とセッションDBのどちらを使用すればよいのか判断に迷うケースはよくあります。

まず、パフォーマンスに関してですが、基本的にセッション・オブジェクトのサイズが極端に大きくない限りは、両者にパフォーマンスの差異はありません。

また、セッション・オブジェクトのコピーを書き出すタイミングは、セッションDB・メモリ間複製ともに決められた時間に書き出す時間基準、サーブレット・サービスの終了後、手動更新（サーブレットのコーディングで制御）の3種類あり、中でもサーブレット・サービスの終了後の書き出しは、サーバー障害時のセッションの復旧の観点においては他の方式と比べ信頼性が高い分、トレードオフでパフォーマンスの低下が懸念される方式でしたが、V8のメモリー間複製において、CPU使用率は上がるもの、スループットはサーブレット・サービスの終了後の書き出しでも他の方式でも大きく変わらない結果が報告されています。

資料内のグラフの詳細およびセッション・パーシスタンスに関する他のパフォーマンス・レポートに関しては、下記データをご参照ください。

WASV8_SessionReplication_Performance_v1.0 （PDF）

ftp://public.dhe.ibm.com/software/webservers/appserv/was/WASV8_SessionReplication_Performance_v1.0.pdf






セッション・パーシスタンス方式の比較

○△～○○△～○◎パフォーマンス

易やや複雑-セットアップ容易性

不要要（業務DBと共用可）不要DBの使用

△（レプリカ数分増加、※1）○（パーシスタンスなしと同じ）○メモリー使用量

○

サーブレット・サービスの終了

セッションDB

△（一部ロスト）

時間基準

○

サーブレット・サービスの終了

メモリー間複製（peer to peer）

×

セッション・パーシスタンス未使用

△（一部ロスト）

障害時のセッションの復旧

時間基準

（※1） client-serverの場合、セッション保管用のサーバーの台数に応じメモリ使用量は変化

パフォーマンスのほか、選択に必要な考慮ポイントとしては、メモリー使用量やDBの使用有無、セットアップの容易性が挙げられます。

こうした考慮ポイントを押さえた上で、業務アプリケーションでDBを使用する場合など、セッションDBとして使用できるDBが用意できる環境であればセッションDBによるセッション・パーシスタンスを選択、メモリー・リソースが十分で、かつWASで簡単にセットアップを行いたい場合はメモリー間複製を利用するなどの判断をシステム要件に合わせてご選択ください。






【参考】WebSphere DataPower XC10アプライアンス

大容量240GBのキャッシング・アプライアンス製品– WebSphere eXtreme Scale V7.1 （WXS）のキャッシング機能を搭載

– WebSphere Application Serverとの連携機能

• 動的キャッシュ

• HTTPセッション

– セル跨ぎのHTTPセッション・パーシスタンスをサポート

– 異なるバージョン／エディション間で利用可能（WAS Base/Express/ND V6.1、V7.0、V8.0）

– 管理コンソールから設定・管理・運用が可能

» DBによるセッション・パーシスタンスに比べて構成・管理・運用が容易

– アプリケーションの変更は基本的に不要 XC10にＨＴＴＰセッション情報を保持して、フェイルオーバー時にサーバー間で引き継ぎ

セルA

セルB

セッション

セッション

セッション

セッション

セッション

セッション

セッションセッションセッションセッションセッション

セッション

キャッシュのモニタリング

WAS v7.0(Base/Express/ND)



XC10にＨＴＴＰセッション情報を保持して、フェイルオーバー時にサーバー間で引き継ぎ

セルA

セルB

セッション

セッション

セッション

セッション

セッション

セッション

セッションセッションセッションセッションセッション

セッション

キャッシュのモニタリング




※WAS V8に対するXC10

のサポートに関しては近々

発表予定（2011年7月時点）

なお、セッション・パーシスタンスに関して、セッションDB、メモリー間複製の他にWebSphere DataPower XC10アプライアンスを使用するという選択肢もあります。XC10の利用により、複数セル間やバージョン違いのWAS間でのセッション・パーシスタンスがサポートされ、WASの管理コンソール上で管理・運用できるため、セッションDBと比べ管理・運用を容易にすることができるというメリットがあります。

その他機能につきまして、詳しくは下記資料をご参照ください。

DataPower XC10 キャッシングアプライアンスワークショップ資料

http://www.ibm.com/developerworks/jp/websphere/library/esb/dpxc10_ws/index.html?ca=drs-

WAS V8に対するXC10のサポートに関しては近々発表される予定です（2011年7月時点）。






WASシステムの高可用性機能

セッション・パーシスタンスワークロード管理HAマネージャー

続いてワークロード管理について概要をご説明いたします。






ワークロード管理（WLM）

前段のコンポーネントで処理を分散し、障害時には他のサーバーで処理を引き継ぐ機能

– ミッションクリティカルなアプリケーションの連続した稼動を可能にする

NDExpress Base

5つのWLMポイント

負荷分散装置ユーザー

プロキシー

WebサーバーAPPサーバー

（Webコンテナー）

Load Balancer WLM

Proxy WLM

WebServerPlug-in

WebServerPlug-in

Web Container WLM

APPサーバー（EJBコンテナー）

EJB WLMPlug-in

EJB WLMPlug-in

EJB Container WLM

ME WLM

ME ME

障害検知・割り振り制御の方法は2種類

・リクエストに対するタイムアウトでの障害検知・割り振り制御

Load Balancer / Proxy / Web Container / EJB WLMで実装可能

・HAマネージャーによる障害検知・割り振り制御

Proxy / EJB / ME WLMで実装可能

Application Server（メッセージング・エンジン）

ワークロード管理（=WLM）とは、前段のコンポーネントでリクエストを割り振り、障害が発生した場合にはその障害を検知し、他の正常なサーバーに割り振る機能です。一般的なWebインフラでのWLMのポイントとして、以下があります。

・負荷分散装置 WLM

負荷分散装置からWebサーバー（Proxy Server）へのWLMです。

・Proxy WLM

Proxy ServerからWebサーバー（アプリケーション・サーバー）へのWLMです。

・Web Container WLM

WebサーバーからWebコンテナーへのWLMです。

・EJB Container WLM

Webコンテナー（EJBクライアント）からEJBコンテナーへのWLMです。

・Message Engine WLM

WebコンテナーからMessage EngineへのWLMです。

各WLMでの障害検知・割り振り制御の方法は大きく分けて2通りで、1つは実リクエストを投げてそのレスポンスにかかる時間で検知・割り振り制御する方法で、もう1つはProxy WLM / EJB WLM / ME WLMで使用できる、HAマネージャーにより障害検知・割り振りを制御する方法です。

基本的な機能に関して、V7.0とV8.0に大きな差異はありません。各層でのワークロード管理に関しては、参考資料およびV7.0のアナウンスメント・ワークショップ資料をご参照ください。

WebSphere Application Server V7 アナウンスメント・ワークショップ - 「インフラ設計」

http://www.ibm.com/developerworks/jp/websphere/library/was/was7_ws/index.html






MQリンク– MEとMQのキュー・マネージャー間を接続するネットワーク・リンク

– MQリンクによりMEに仮想キューマネージャーが定義

送信先キューマネージャーのフェールオーバーをサポート– V8より接続名の複数指定が可能

• 複数接続名リストを選択し、ホスト名（IPアドレス）とポートを指定

WMQリンクの送信チャネルにおける接続先の複数指定

WMQ QMr （アクティ

ブ）

AppServer

ME

WMQ QMr （スタンバイ）

自動的に接続先を変更

New

※ME ･･･メッセージング・エンジン

接続先のホスト名,ポートを複数指定可能

マルチインスタンス・キューマネージャー構成のＷＭＱ環境との連携が可能

※QMr ･･･キューマネージャー

なお、ワークロード管理とは話が逸れますが、WAS V8よりWebsphere MQに対し、メッセージングの送信先のキュー・マネージャーのホスト名・ポートを複数指定することで、アクティブなキュー・マネージャーがダウンした場合にスタンバイのキュー・マネージャーへ自動的に接続先を変更できるフェールオーバー機能が追加されました。

この機能拡張により、例えば WMQ v7.0.1より提供されているマルチインスタンス・キュー・マネージャー（PowerHAなどの高可用性のためのソフトウェアなしにキュー・マネージャーの可用性を高めることができる機能）を利用した高可用性構成の環境とWASの機能で連携することが可能になりました。

マルチインスタンス・キューマネージャー構成に関しては、下記リンク先をご参照ください。

MQ設計虎の巻: 第11回「高可用性設計」

http://www.ibm.com/developerworks/jp/websphere/library/wmq/toranomaki/11.html






WASシステムの高可用性機能

セッション・パーシスタンスワークロード管理

HAマネージャー

メモリ間複製によるセッション・パーシスタンスやワークロード管理を支える、重要な高可用性機能であるHAマネージャーについてご説明いたします。






HAマネージャー NDExpress Base

デプロイメント・マネージャー


アプリケーション・サーバー




コア・グループ

障害検知







シングルトンサービス（TM,ME）

の引継ぎ情報の共有

（EJB WLM情報DRS情報）

アプリケーションの実行に関する動的な情報をHAマネージャー間で共有

TM: トランザクション・マネージャー

ME: メッセージング・エンジン

HAマネージャーは、アプリケーション実行に関する動的な情報を共有するためのサービスで、セル内の全てのJavaプロセス上で稼動します。HAマネージャーの機能は大きく分けて３つです。

（1）障害検知

各Javaプロセス間で互いにハートビートを送信することで、Javaプロセス障害を検知し特定することができます。

（2）情報の共有・更新

アプリケーション稼働に必要な、EJB WLMルーティング情報、メモリ間複製の基盤であるDRS情報、 ODC（オンデマンド構成）情報等を共有し、必要な場合は即時更新されます。

（3）シングルトン・サービスのフェイルオーバー

基本的に1台のサーバー・インスタンスで実施しなければならないサービスのフェールオーバーをサポートします。具体的には、トランザクション・ログに対応するトランザクション・マネージャー・サービスのフェールオーバーによるインダウトトランザクションのピア・リカバリーと、メッセージング・エンジンのフェールオーバーがサポートされます。






HAマネージャーのコンポーネント（1/2） NDExpress Base

ノード Cノード Bノード A

セル


デプロイメント・マネージャー

プロセス


ノード・エージェントプロセス


アプリケーション・サーバープロセス


ノード・エージェントプロセス





コア・グループ

コーディネーター

HAグループ

コーディネーター・コア・グループ内全ての情報を保持・WLM情報の更新・配布・シングルトン・サービスのフェールオーバーの指示

HAグループ・ポリシーの一致するHAマネージャーのグループ

※ポリシーどのサービスをどのようにフェールオーバーするかという設定

HAマネージャー・自プロセスで使用する情報を保持・WLM情報の受け取り・シングルトン・サービスのフェールオーバーの実行

コアグループ・セル内のJVMのグループ

HA機能の設定の単位・50を越えるJVMが所属する場合

コア・グループを分ける必要あり

HAマネージャー関連のコンポーネントとしては、コーディネーターとHAマネージャーの2つがあります。また、論理的なグループとしてコア・グループとHAグループがあります。

まず、コア・グループとはセル内のJVMをグルーピングしたもので、HA機能の設定の単位となる論理グループです。デフォルトでは”DefaultCoreGroup”が使用されます。コア・グループ内でHAマネージャーとコーディネーターが稼動します。

コーディネーターはコアグループメンバーの情報（グループ名、グループメンバーやポリシーの情報）や、コアグループメンバーの状況（停止、開始、失敗）をトラッキングしています。また、サーバー障害時に適切なアプリケーション・サーバー内のHAマネージャーにフェールオーバーの指示を出します。コーディネーターの存在するJVMプロセス障害発生に備えて、全てのJVMでコーディネーターを引き継ぐ準備がされており、Single Point of Failureではありません。

HAマネージャーは、稼動している自プロセス内の情報を保持し、コーディネーターからの指示により、WLMの情報を受け取り自アプリケーション・サーバーを制御、また他サーバーのシングルトン・サービスを自アプリケーション・サーバーに引き継がせるよう動作します。

さらに、コア・グループ内のサーバー（コア・グループ・メンバー）を、さらに動的にグルーピングすることができます。これをHAグループといい、サービスをどのようにフェールオーバーするかの一致基準（ポリシー）をもとにグルーピングされます。

コア・グループについては、デフォルトで”DefaultCoreGroup”に全てのJavaプロセスがメンバーと

して登録されますが、目安として1グループ内で50プロセスを越える場合には、コア・グループを複数に分けることを検討する必要があります。






コアグループ・ブリッジ（Core Group Bridge）

– コア・グループ間の通信を可能にするサービス

– 相互に通信を行うコア・グループをアクセス・ポイント・グループに定義し、ブリッジ・インターフェースにて

接続する

• コア・グループ・アクセス・ポイント

同一セル内のコア・グループ間

• ピア・アクセス・ポイント

異なるセル内のコア・グループ間

HAマネージャーのコンポーネント（2/2）

コア・グループ1 コア・グループ2

コア・グループ4

コアグループアクセスポイント1



アクセスポイントグループ41






コア・グループ1 コア・グループ2








Meshトポロジー

– ルーティング情報等の伝達遅延が発生しにくい

Chainトポロジー

– （ほぼ無制限に）ブリッジ数を増やせる

•トンネル・ピア・アクセス・ポイント

F/Wを超えるコア・グループ間

（例：Secure Proxy Server）

コア・グループを分割しても、実際には1つのコア・グループとしてHAマネージャーの機能を使用したい場合があります。このような場合に、コアグループ・ブリッジと呼ばれる、コア・グループ間の通信を可能にするサービスが提供されています。

複数コア･グループ間の通信にはアクセス・ポイント・グループを定義し、ブリッジ・インターフェースと呼ばれる機能にてお互いを接続させる必要があります。WASV7から、アクセス・ポイントとして、F/Wを超えるコア・グループ間を接続できる“トンネル・ピア・アクセス・ポイント”が追加されました。

ブリッジ・インターフェースはコーディネーターとは異なり、明確に指定する必要があります。可用性を考慮すると各コア・グループ毎に２つのブリッジ・インターフェースを指定することが推奨されます。またコーディネーターやコアグループ・ブリッジの役割を持たせるプロセスは、可能であれば、両者の機能を持つ専用のプロセスを作成し、大ヒープサイズを1024MBに設定することが推奨されています。専用のプロセスを用意しない場合には、ノード・エージェントに役割を割り当てて下さい。

＜参考：コア・グループ・ブリッジの設定が必要なケース例＞

・バージョンの異なるシステム間でHAマネージャーの情報を共有する

・外部セルに対するJMSリクエスト

・ EJBのバックアップクラスターが外部セルに配置されている

・ WebSphere DMZ Secure Proxy Serverの動的ルーティングを使用する






シングルトン・サービスのフェールオーバー（1）

HAマネージャーにより以下の2つをフェール・オーバーサポート

– トランザクション・マネージャー・サービス

– メッセージング・エンジン

① トランザクション・マネージャー・サービスのフェールオーバー

HAマネージャーの機能により、数秒でインダウト・トランザクションを復旧

マシン A

アプリケーション・サーバー2

マシン B

クラスター


共有Disk

AS2TLog

AS1TLog

AS2TM


AS1TM

AS1TM

①アプリケーション・サーバー1がダウン②HAマネージャーがダウンを検知③コーディネーターがTMのフェールオーバーを指示

④フェールオーバーを指示されたHAマネージャーがアプリケーション・サーバー1のTMを起動⑤インダウト・トランザクションをリカバリー

WASV8.0ではHAマネージャーにより、2フェースコミットのトランザクションを使用している場合のトランザクション・マネージャー・サービスとメッセージング・エンジンの2種類のシングルトン・サービスのフェール・オーバーが可能です。

トランザクション・マネージャー・サービスのフェール・オーバーに関しては、事前に共有ディスクにトランザクションログを配置することで、障害が発生してもHAマネージャーによりトランザクション・マネージャーのフェールオーバーが自動で実行され、インダウト・トランザクションをリカバリーすることが可能になります。

HAマネージャーによるトランザクションの復旧手順は以下になります。

（1）アプリケーション・サーバー1の障害をコア・グループ内の他のサーバーのHAマネージャーが検知します。

（2）コア・グループ・コーディネーターがアプリケーション・サーバー1のトランザクション・マネージャーをアプリケーション・サーバー2に

フェールオーバーすることを決定し、アプリケーション・サーバー2のHAマネージャーにフェールオーバーを指示します。

（3）指示を受けたアプリケーション・サーバー2のHAマネージャーが通常アプリケーション・サーバー1で稼働しているトランザクション・マ

ネージャーをアプリケーション・サーバー2で起動します。

（4）アプリケーション・サーバー2で起動したアプリケーション・サーバー1のトランザクション・マネージャーがインダウト・トランザクション

のリカバリーを行います。






②メッセージング・エンジンのフェールオーバー

SIBus（サービス統合バス）

アプリケーション統合のためのメッセージ通信基盤

・ME（メッセージング・エンジン）

・SIBWS（Webサービス使用可能化）

・メディエーション

機能を有する

マシン A

マシン B

クラスター

SIBus

マシン C


JMSClient

ME1

ME1



HAマネージャーの機能で、メッセージング・エンジンのフェールオーバーが可能

シングルトン・サービスのフェールオーバー（2）



①アプリケーション・サーバー1がダウン②HAマネージャーがダウンを検知③コーディネーターがMEのフェールオーバーを指示④フェールオーバーを指示されたHAマネージャーがアプリケーション・サーバー1のMEを起動

ME（メッセージング・エンジン）

アプリケーション・サーバー上で稼動する非同期メッセージ通信基盤WMQに接続する機能（MQリンク）等を提供

また、メッセージング・エンジンのフェールオーバーに関して、WAS6.0以降では、SIBusに統合された非同期メッセージ通信基盤であるME（メッセージング・エンジン）がメッセージング・サービスを提供しますが、アプリケーション・サーバーでクラスター構成を行うことにより、HAマネージャーによるメッセージング・エンジンはクラスター間でのフェールオーバーが可能になります。

SIBusについては以下の資料をご参照ください。

WebSphere Application Server V6 SIBus入門

http://www.ibm.com/developerworks/jp/websphere/library/was/was6_sibus_intro/

WebSphere Application Server V7.0 管理ガイド

http://www.ibm.com/developerworks/jp/websphere/library/was/was7_adminguide/






WASの管理系コンポーネントと基本構成

ここまででWebの基盤を構成するためのコンポーネント、および高可用性機能についてご説明しました。

後のセクションとして、小規模環境から大規模環境まで、WAS環境の運用管理を容易にするための管理コンポーネントについて、ご説明いたします。






管理エージェント（Admin Agent）

複数WAS Base構成とExpress構成のための集中管理エージェント

– アプリケーション・サーバー・ノードを管理エージェントに登録して管理

• 各シングル・サーバー・ノードに対する構成管理/アプリケーション管理/コマンド･マネージャー/ファイル転送/管理コンソールの機能を管理エージェントが代行

– 管理のフットプリントを縮小させ起動時間を短縮させることが可能

– 1OS内の複数アプリケーション・サーバーの集中管理が可能

アプリケーション･サーバー・ノードの代理としてジョブ・マネージャーからのジョブを取得、管理ノードに対しジョブを実行させることが可能

NDExpress Base

管理エージェントとはWAS Base構成とExpress構成を管理するためにV7.0より新しく加わった管理コンポーネントで、管理エージェントにより1OS内の複数のBase構成とExpress構成を集中管理することが可能になりました。

アプリケーション・サーバー・ノードが登録されるとそのノードは管理対象ノードとして扱われます。管理エージェントの管理対象ノードになると構成管理/アプリケーション管理/コマンド･マネージャー/ファイル転送/管理コンソールの機能が管理エージェントに移行され、アプリケーション･サーバーのフットプリントを縮小させ起動時間を短縮させることができます。

また、管理エージェントは管理エージェントの管理対象ノードであるアプリケーション･サーバー･ノードの代理としてジョブ・マネージャーからのジョブを取得し、各アプリケーション･サーバー･ノードに対してジョブを実行させることが可能です。そのためには管理エージェントの管理対象ノードをジョブ・マネージャーに登録する必要があります。






管理エージェントのトポロジー


wsadmin

ノードA






セル構成情報


AS構成情報

従来の構成管理（Express/BASE）

ノードB






セル構成情報


AS構成情報

ノードA （管理対象）

ノードC

管理エージェント


wsadmin







ノードB （管理対象）



アプリケーション・サーバーセル構成情報


AS構成情報

管理エージェント登録後の構成管理

セル構成情報


AS構成情報

・管理エージェントから直接管理対象ノードの構成情報を変更可能・管理対象ノードは管理エージェントと同一OSに配置されている必要がある


wsadmin

管理エージェントの基本構成は右図の通りで、1OS内にあるノードを管理エージェントは管理することが可能です。管理エージェントに登録された段階で、登録されたアプリケーション・サーバー・ノードにある管理コンソールは使用不可能になり、管理エージェントが提供する管理コンソールからの各ノードの構成変更が可能になります。

注意点として、複数のOSを跨って管理エージェントにノードを登録できないことが挙げられます。例えば、OS区画#1 / #2にアプリケーション・サーバーが配置されていて、OS区画#1あるいは#2、もしくは異なるOS区画#3に管理エージェントを配置して2台のアプリケーション・サーバーを集中管理する、という構成をとることはできません。また、WAS NDのセル構成のように、管理エージェントに登録したノードの構成情報を同時に出力させることはできませんのでご注意ください。






ジョブ・マネージャー

運用、管理などの処理をジョブとして一箇所にキューイング複数Base/Express環境と複数ND環境に対して非同期で実行例： NDセル環境とBase環境のアプリケーション･サーバーを時間を指定して起動

ジョブの非同期実行をサポート

– 指定した時刻に実行– 特定の時間を越えたタイミングでの無効化– 特定の時間間隔での繰り返し実行– ジョブの完了通知の送信（e-mail）

以下のジョブに関して柔軟な管理機能を提供

– アプリケーション・サーバー/クラスターの始動・停止・作成・削除

– アプリケーションのインストール・アンインストール・更新・始動・停止– ファイルの配布・収集・除去– wsadminスクリプトの実行– リモート・サーバーに対し、IIM / WASインストール・Fix適用（CIM機能）

– プロファイルの作成・削除

DM経由でジョブの実行が可能

NDExpress Base

New

New

ジョブ・マネージャーとは運用、管理などの処理をジョブとして一箇所にキューイングし、複数Base/Express環境と複数NDセル環境に対して非同期で実行する仕組みを提供する管理コンポーネントです。アプリケーション･サーバーを時間を指定して起動させるなど、運用･管理の処理をスケジューリングして実行させたい場合にはジョブ・マネージャーを使用します。また、複数NDセル環境や複数Base/Express環境が混在する環境においてもジョブ・マネージャーを使用することで統一的な運用管理が可能になります。

V8.0において、ジョブ・マネージャーが実行できるジョブにリモートサーバーに対するIIMやWASのインストール・Fix適用といった集中インストール・マネージャー（CIM）機能や、プロファイルの作成・削除が追加され、よりジョブ・マネージャーが利用できるケースが増えました。さらに、V8.0ではDMからジョブ・マネージャーに対し、ジョブを登録し実行させることも可能になりました。

ジョブの管理はジョブ・マネージャー管理コンソールもしくはwsadminで可能です。wsadminでのジョブの管理については以下のInfoCenterの記載をご参照ください。

Information Center「Administrative job types」

http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/rxml_7jobtypes.html

Information Center「Administering jobs in a flexible management environment using scripting」

http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/txml_7flexiblemgmt.html






ジョブ・マネージャーの基本トポロジー

ジョブ・マネージャー登録後の構成管理

ノードA

ノードE




セル構成情報


AS構成情報

ノードD

NANA







AS構成情報


wsadmin

Job Manager管理サービス/ JMX 管理コンソール･アプリケーション

Job Manager管理

コンソール

wsadmin

Job Manager構成情報

ジョブの登録

ノードC




セル構成情報


AS構成情報

ノードB

NANA







AS構成情報


wsadmin

ジョブの実行

上図がジョブ・マネージャーにNDセル環境を登録後の構成管理です。

NDセル環境をジョブ・マネージャーに登録しても、ジョブ・マネージャーではNDセル環境の構成情報は持たず、ジョブ・マネージャー自身の構成情報しか持ちません。そのためジョブ・マネージャーでは配下の管理ノードの構成変更を行うことは出来ないため、ジョブ・マネージャーに登録しているノードの構成変更をおこなう際は、NDセル環境の場合はデプロイメント・マネージャーに、シングル・サーバー・ノードの場合は管理エージェントに対して管理コンソールもしくはwsadminコマンドで接続し、構成変更をおこないます。

NDセル環境のジョブ・マネージャーへの登録方法や登録後の動きの詳細については参考資料P.6-7をご参照ください。

またジョブ・マネージャーはデプロイメント・マネージャーやアプリケーション・サーバーと同一筐体に配置することも別筐体に配置することも可能です。ただしジョブ・マネージャーも一つのJavaプロセスですので、同一筐体に配置した場合はジョブ・マネージャーの分だけアプリケーション・サーバーで使用できるリソースは減りますのでご注意ください。






フレキシブル・マネジメント

複数のセル環境をまたがった、管理アクションの統合、一元管理が可能

複数スタンドアロン・ノード環境の統一的な運用が可能

地理的に拡散されたサーバーの管理が可能

ノード

DMAS

ノード

NA

JobManager

ノードノード

ノード

AS

Admin Agent

AS

ノード

ノード

DM

NA

AS

ノード

NA

AS

ノード

ノード

DM

NA

ノード

ノードノード

AS AS

Admin Agent

本社（東京）

支社（大阪）支社（福岡）

支社（札幌）支社（上海）

NDセルNDセル

Base/Expressサーバー

Base/Expressサーバー

NDセル

こうした管理系コンポーネントであるジョブ・マネージャーと管理エージェントを用いることで、フレキシブル・マネジメント構成をとることが可能になります。

従来、スタンドアロン環境では各サーバーを個々に管理し、またセル環境ではデプロイメント･マネージャーがノード･エージェントを通じてノード内のサーバーを管理していました。管理対象は個々のサーバーレベルのため、複数スタンドアロン環境や複数セル環境が存在する場合には、それぞれの環境を個別に管理する必要があり、大規模環境での運用性には限界がありました。

そこで登場したフレキシブル・マネジメントを使用することにより、複数セル環境が存在する場合には、複数のデプロイメント･マネージャーの一元管理や管理アクションの統合が可能になりました。複数のスタンドアロン環境が存在する場合には、統一的な運用が可能になりました。また、管理対象のノードは、地理的に拡散されていても非同期でジョブを実行するため、ネットワーク負荷を軽減することができます。






Job Manager

AppServer

AppServer

管理コンポーネントを活用したシンプルクラスター構成

管理者

NDライセンス

が必要

管理系コンポーネントを使用しない場合

IHSPlug-in

DB/MQ Server等

AppServer

AppServer

IHSPlug-in

管理系コンポーネントを使用する場合

AppServer

AppServer

IHSPlug-in

DB/MQ Server等

AppServer

AppServer

IHSPlug-in

Admin Agent

Admin Agent

・管理コンソールが複数で管理が大変アプリケーション・サーバーの台数分の管理コンソールで構成管理

・Fix適用作業が大変

各サーバーに修正モジュールを配置し、それぞれのサーバーでFix適用

：：

・管理コンソールのフットプリント縮小管理エージェントの管理コンソールから各アプリケーション・サーバーを構成管理

・Fix適用作業は1台からリモートで実施ジョブ・マネージャーでFix適用が可能

フレキシブル・マネジメント構成の応用として、先にご紹介したシンプル・クラスター構成に管理系コンポーネントを組み合わせる構成が考えられます。

ジョブ・マネージャーはWAS NDライセンスが必要になるという点は考慮点として挙げられますが、ジョブ・マネージャーのCIM機能で一括して全てのマシンにFixを適用することが可能になるなど、より運用しやすい基盤を管理系コンポーネントにより提供することが可能になります。

シンプル・クラスター構成を採用する場合に、こうした管理コンポーネントでの運用負荷の軽減することもご検討ください。






まとめ

本セッションのまとめです。






システム構成に関するまとめ

WASのコア・コンポーネントとその基本トポロジー– WebSphere Application Server

【New】MQ機能の無効化、MQリンクの送信チャネルの冗長化

– IBM HTTP Server + Web Server Plug-ins【New】Webサーバー・プラグイン構成ツールの提供

– Edge Components【New】LLB/CP機能安定化、ULBの機能拡張 / コマンドの仕様変更

– Websphere Proxy Server , WebSphere DMZ Secure Proxy Server

WAS NDの高可用性機能– セッション・パーシスタンス

• セッションDB , メモリー間複製

– リクエストの負荷分散・障害検知を行うワークロード管理

• 負荷分散装置, Proxy, Webコンテナー, EJBコンテナー, Messaging Engine WLM– WASシステムの高可用性機能を支えるHAマネージャー

• シングルトン・サービスのフェール・オーバー

WASの管理系コンポーネントとその基本トポロジー– 管理エージェント、ジョブマネージャー

– フレキシブル・マネジメント構成

本セッションにおいて、Webシステムを構成するコア・コンポーネントについてそれぞれご説明しました。システム構成でのV8.0アップデートは上記にまとめました通りになります。

また、WAS NDで提供される高可用性機能としてセッション・パーシスタンス、ワークロード管理、HAマネージャーについてご説明いたしました。

そして、運用管理を容易にするための管理系コンポーネントとそれらを使用したフレキシブル・マネジメント構成についてご説明いたしました。






参考文献

WebSphere Application Server Version 8.0 Information Centerhttp://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp

WS資料「 WebSphere Application Server V7 アナウンスメント・ワーク

ショップ」

http://www.ibm.com/developerworks/jp/websphere/library/was/was7_ws/index.html

WS資料「 WebSphere Application Server V7.0によるWebシステム基盤

設計ワークショップ」

http://www.ibm.com/developerworks/jp/websphere/library/was/was7_guide/index.html

WebSphere Application Server （WAS）虎の巻http://www.ibm.com/developerworks/jp/websphere/library/was/toranomaki/index.html






参考資料






ランタイム・プロビジョニング

アプリケーション・サーバー上のアプリケーションが必要とする、小限のコンポーネントのみをロードする機能

WAS V6.1以前：

– アプリケーション・サーバー起動時に、すべてのWAS内部コンポーネントが

ロードされる

WAS V7.0, V8.0：

– ランタイム・プロビジョニングを有効化した場合、必要なWAS内部コンポー

ネントのみがロードされる

Webコンテナー

EJBコンテナー

Web Services

SIPコンテナー

セキュリティー


その他．．．

WAS V6.1以前

全てロード

Webコンテナー

EJBコンテナー

Web Services

SIPコンテナー

セキュリティー


その他．．．

WAS V7.0,8.0

必要なものをロード

NDExpress Base

WASランタイムのパフォーマンスを向上させる機能として、V7からランタイム・プロビジョニングという機能が追加されました。V6.1まではアプリケーション・サーバーが起動する際、WebコンテナーやEJBコンテナーなど全てのWAS内部コンポーネントを起動していました。V7以降ではランタイム・プロビジョニング機能をONにすると、対象アプリケーション・サーバー上のアプリケーションや設定から必要なWAS内部コンポーネントのみを起動するようになりました。例として、アプリケーション・サーバー上にデプロイしている全てのアプリケーションがServlet、JSPのみで構成されている場合、EJBコンテナーやWeb Serviceコンポーネントなどは起動されません。これにより、平均して10%程度アプリケーション・サーバーの起動時間が短縮され、Heap使用量も減少させることができます。このランタイム・プロビジョニングはデフォルトOFFで、デプロイメント・マネージャーやノード・エージェント、AdminAgent、Job Managerといった全てのJVMで設定できます。






WebSphere MQ関連の機能無効化

WebSphere MQ関連の機能を必要としない場合、無効化することが可能– V7より提供されているランタイム・プロビジョニング機能と合わせて、不要な機能に対する消費

リソース削減が可能

– デフォルトは使用可能

– 有効範囲はセル・ノード・サーバー・

クラスターから指定

設定方法①管理コンソールの「JMSプロバイダー」>

「WebSphere MQ メッセージング・プロバイダー」

で「Disable WebSphere MQ」にチェック

②AdminTask.manageWMQ （wsadminコマンド）で

-disableWMQ をtrueに指定する

①, ②ともに構成を保管し、対象サーバーが再起動した時点で設定が反映されることに注意

[11/07/04 14:07:04:250 GMT+09:00] 00000000 JMSRegistrati I WMSG1720I: このサーバーのすべての WebSphere MQ 機能が使用不可になりました。

設定反映後のアプリケーション・サーバーのSystemOut.logの出力例

New NDExpress Base

詳細に関しては、下記リンク先をご参照ください。

Information Center - 「Disabling WebSphere MQ functionality in WebSphere Application Server」

http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tmm_wmq_disable.html






Webサーバー・プラグイン構成ツールの使い方（1/7）

①Webサーバー・プラグイン構成ツールの起動

②導入されているWebサーバープラグインのディレクトリを登録

②-2 プラグインの導入ディレクトリを指定

また、導入ディレクトリの識別名を設定

②-１ Webサーバー・ランタイム・ロケーション

の「追加」ボタンをクリック

New

Webサーバー・プラグイン構成ツールはWebサーバー・プラグインの導入されているOSに導入してください。







③Webサーバーを定義

③-１ ②で登録したプラグインを指定し、下段の

Webサーバー・プラグイン構成タブの「作成」

ボタンをクリック

③-2 使用するWebサーバーを指定し、

「次へ」ボタンをクリック







③Webサーバーの定義（続き）

③-3 Webサーバーの構成ファイルと

Listenするポートを指定し、「次へ」をクリック

③-4 必要であればIHS管理サーバーの

セットアップを実施








③-5 Windowsの場合はWindowsサービスに

IHS管理サーバーを登録するかを選択

③-6 Webサーバー定義名を指定し、

「次へ」をクリック








③-7 ローカル構成かリモート構成かを選択し、

それぞれ必要な情報を入力し、「次へ」をクリック

③-8 設定した情報を確認し、「構成」をクリック

成功の結果が表示されれば終了

ローカル構成の場合は、③でWebサーバーの定義処理が自動で行われますので、④以降の作業は不要です。







④configure〈Webサーバー定義名〉.sh（.bat）の配布

④-1 Webサーバー定義実行シェル（ configure〈Webサーバー定義名〉.sh（.bat））の生成確認

下記ディレクトリにシェルが生成されていることを確認

■APサーバーがWebサーバーと同OSの場合

〈プラグイン・ディレクトリ〉/bin

■APサーバーがWebサーバーと別OSの場合

〈プラグイン・ディレクトリ〉/bin/crossPlatformScripts/〈OSタイプ〉/

④-2 リモートのAPサーバーで作成されているAPサーバー・プロファイルあるいはDMプロファイルの

binディレクトリにシェルを配置

$ dir c:¥IBM¥WebSphere¥Plugins80¥bin¥crossPlatformScripts¥unix

：

2011/07/23 18:56 2,457 configurewebserver1.sh

$ dir c:¥IBM¥WebSphere¥Plugins80¥bin

：

2011/07/23 18:56 2,241 configurewebserver1.bat

ローカル構成の場合は、③でWebサーバーの定義処理が自動で行われますので、④以降の作業は不要です。







⑤APサーバー（Express/Base）、DM,NA（ND）の起動

⑥configure〈Webサーバー定義名〉.sh（.bat）の実行

⑥-1 ④-2で配置したシェルを実行

⑥-2 管理コンソールにWebサーバーが定義されていることを確認

$ configurewebserver1.bat：

WASX7303I: 次のオプションはスクリプト環境に渡され、argv 変数に格納される引数として使用可能になります: "[webserver1, IHS, C:¥¥IBM¥¥HTTPServer80, C:¥¥IBM¥¥HTTPServer80¥¥conf¥¥httpd.conf, 80, MAP_ALL, C:¥¥IBM¥¥WebSphere¥¥Plugins80, unmanaged,

stronger-node, stronger, windows, 8008, wasadmin, password, IBM HTTP Server V8.0]"

：

NDの場合は構成の同期を忘れずに実施してください。






【ULB】TCP/HTTPセッション引継ぎ機能（repstrategyオプション）の追加

Takeover時にTCP接続、IPSticky情報を引き継ぐか選択可能– 設定方法

– ストラテジーは以下の4種類から選択可能（デフォルト:none）none: TCP接続情報、IPSticky情報を引き継がないconnection: TCP接続情報のみ引き継ぐaffinity: IPSticky情報のみ引き継ぐ

both: TCP接続情報およびIPSticky情報を引き継ぐ

Heart Beat

primary

backup

Heart Beat

primary

backup

通常時0.5秒間隔でPrimaryからBackupへTCP接続情報あるいはIPSticky情報を同期

Primaryダウン時、同期されている情報を元に処理

を継続

ユーザー1はサーバー2へ

ユーザー1 ユーザー1

サーバー2

サーバー1

サーバー3

サーバー2

サーバー1

サーバー3

dscontrol port add 〈クラスター名〉@〈ポート〉 repstrategy 〈ストラテジー〉






【ULB】障害時のTCPリセットの送信機能追加

ヘルスチェックにより割り振り先サーバーの障害を検知した際に、接続中のクライアントにTCPリセットを送信するオプションを選択可能

–クライアントは割り振り先サーバーのダウンを即時に知ることが可能

• 特にLDAPの割り振りなどで、常に接続が張りっぱなしになるようなケース

では、有用なオプション

–設定するためには以下のコマンドを使用

RST

Client

Server

dscontrol server add （set）〈クラスター名〉@〈ポート〉@〈サーバー名〉 reset yes






負荷分散装置 WLM

負荷分散装置ユーザーユーザー

プロキシー


(Webコンテナー)

Application Server(メッセージング・エンジン)

Load Balancer WLM

Proxy WLM

WebServerPlug-in

WebServerPlug-in

Web Container WLM

APPサーバー(EJBコンテナー)

EJB WLMPlug-in

EJB WLMPlug-in

EJB Container WLM

ME WLM

ME ME

Advisorによる定期的なHTTPリクエストのレスポンスで障害検知障害検知

IPSticky （ULB,LLB）, Cookie, URI （LLBのみ）セッション維持（Affinity）

動的な重み計算による割り振り

接続数などに応じて、Sorry Serverに割り振ることも可能

割り振りポリシー

MAC転送方式（MACアドレス変換）

カプセル化転送方式（GRE/IPinIPによる）

NAT/NAPT転送方式（IPアドレス/ポート番号変換, LLBのみ）

KCBR転送方式（リクエストURLやCookieに応じた割り振り, LLBのみ）

割り振り方式

Edge Components Load balancer IPv4 （LLB） / IPv4 and IPv6（ULB）WLMを行うコンポーネント

負荷分散装置は、クライアントからのリクエストをWebサーバーに対してWLMを行うコンポーネントです。このコンポーネントは、WASV8.0 NDに含まれるEdge Componentsが該当します。

WASV8.0では、割り振り方式はMAC転送方式、セッション維持（Affinity）は接続元IPアドレスによるセッション固定方式であるIPStickyが推奨となります。また、割り振りポリシーは、Webサーバーへの接続数やレスポンスタイムを動的に計算し割り振り先を決定します。障害検知に関しては、Advisorに

よる定期的なHTTPリクエストのレスポンスを見て検知します。






Proxy Server WLM


プロキシー




Load Balancer WLM

Proxy WLM

WebServerPlug-in

WebServerPlug-in

Web Container WLM


EJB WLMPlug-in

EJB WLMPlug-in

EJB Container WLM

ME WLM

ME ME

HAマネージャーによる障害検知（オンデマンド構成）

実リクエストの接続の確立により、障害検知（汎用クラスター構成）

障害検知

SSL IDURL再書き込み

Cookie （Active / Passive）

セッション維持（Affinity）

重み付きラウンド・ロビン（デフォルト）

ランダム（WASV7から追加）


WebSphere Proxy ServerWLMを行うコンポーネント






Webコンテナー WLM


プロキシー




Load Balancer WLM

Proxy WLM

WebServerPlug-in

WebServerPlug-in

Web Container WLM


EJB WLMPlug-in

EJB WLMPlug-in

EJB Container WLM

ME WLM

ME ME

実リクエストに対する接続の確立により、障害検知障害検知

Cookie、またはURL再書き込みの中のJSESSIONIDに付加される各APサーバー毎に割り当てられたCloneID / PartitionIDでセッション維持


重み付きラウンド・ロビン（デフォルト）

ランダム


Webサーバー・プラグインWLMを行うコンポーネント

Webサーバーからアプリケーション・サーバーのWebコンテナーへのWLMは、Web サーバー・プラグインが行います。割り振りポリシーは、重み付きラウンド・ロビンとランダムが設定可能です。セッションAffinityは、CookieとURL再書き込みが設定可能です。障害検知は、実リクエストの接続の確立により行われます。






EJBコンテナー WLM


プロキシー




Load Balancer WLM

Proxy WLM

WebServerPlug-in

WebServerPlug-in

Web Container WLM


EJB WLMPlug-in

EJB WLMPlug-in

EJB Container WLM

ME WLM

ME ME

実HAマネージャーによる障害検知

実リクエストの接続の確立による障害検知

障害検知

ローカルを優先（ON/OFF設定可、デフォルトON）

プロセス Affinity （EJBクライアントとEJBコンテナが同一プロセス上で稼動する場合には、EJBの負荷分散は行われない）

トランザクション Affinity


重み付きラウンド・ロビン割り振りポリシー

EJB WLM PluginWLMを行う実体

EJBコンテナーへのWLMは、Webコンテナー上に存在するEJB WLM プラグインが実施します。割り振りポリシーは、Webコンテナーと同様に重み付きラウンド・ロビンを採用しています。

Affinityは、 “ローカルを優先”、“プロセスAffinity” 、“トランザクションAffinity” の3つがあり、“重み付けラウンド・ロビン”よりも優先されます。“ローカルを優先”を設定するとEJBクライアントと同一ノード上のEJBコンテナーへのリクエストが優先され、ネットワーク通信が行われませんので、パフォーマンスの向上が期待できます。EJBクライアントとEJBコンテナが同一プロセス上で稼動する場合は、プロセスAffinity機能により、全てのEJBクライアントのリクエストは同一プロセスのEJBコンテナーに割り振られます。トランザクションAffinityは、すべての割り振りポリシーおよびAffinityより優先され、同一のトランザクション・スコープ内のリクエストは、必ず前回と同じEJBコンテナーにリクエストが割り振られます。障害検知は、実リクエストの接続の確立、もしくはHAマネージャーにより行われます。






Messaging Engine WLM


プロキシー




Load Balancer WLM

Proxy WLM

WebServerPlug-in

WebServerPlug-in

Web Container WLM


EJB WLMPlug-in

EJB WLMPlug-in

EJB Container WLM

ME WLM

ME ME

HAマネージャーが障害を検知し、HAポリシーに従いフェールオーバーされる

HAポリシー（ポリシータイプ,優先サーバーリスト,一致基準）

障害検知

・キューポイント間でのメッセージ制御（JMSアプリケーション）

ローカル・キュー・ポイントを優先（デフォルト、優先しない設定も可）

別のキュー・ポイントに送信可能（デフォルト、同じキュー・ポイントに送信する設定も可）


・JMSクライアントからMEを検索ターゲット（検索範囲のターゲットとなるMEのグループを識別）

接続の接近性（クライアントからMEを検索する際の検索順序と範囲）

上記設定で確認されるMEが複数存在する場合には、ラウンド・ロビンで割り振られる


メッセージング・エンジン（ワークロード共用）WLMを行う実体

メッセージング・エンジンでは、SIBusメンバー内に複数のMEを起動し処理を分散させることができ、これを「ワークロード共用」と呼びます。そして、JMSクライアントから、SIBus内のアクティブなMEを検索する順番は、ターゲットおよび接続の接近性にて設定します。この設定で複数のMEが確認された場合には、ラウンド・ロビンで割り振られます。障害検知は、HAマネージャーの機能により、HAポリシーに従ってメッセージング・エンジンがフェール・オーバーされます。

Information Center – 「Workload sharing」

http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/cjt0013_.html

Information Center – 「Configuring a connection to a non-default bootstrap server」

http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tjn0033_.html

WebSphere Application Server V8public.dhe.ibm.com/software/dw/jp/websphere/was/was8_ws/...WebSphere...

Documents

Transcript of WebSphere Application Server V8public.dhe.ibm.com/software/dw/jp/websphere/was/was8_ws/...WebSphere...