目次 1. はじめに 検証概要 システム構成 ハードウェア ソフトウェア 検証項目 検証方法 検証実施詳細 サーバ負荷分散検証

23 

Loading....

Loading....

Loading....

Loading....

Loading....

全文

(1)

Copyright ©2006 BEA Systems Japan,Ltd. Fujitsu Ltd. All Rights Reserved.

日本 BEA システムズ‒ 富士通

アプリケーションサーバフロント統合

アライアンステクニカルホワイトペーパー

【Windows プラットフォーム編】

ネットワークサーバ アイピーコム

IPCOM

(2)

Technical White Paper

目次

1.はじめに...1

2.検証概要...2

2. 1 システム構成...2

2. 2 ハードウェア...2

2. 3 ソフトウェア...2

2. 4 検証項目...5

2. 5 検証方法...5

2. 6 検証実施詳細...5

3.検証結果と考察...6

3. 1 サーバ負荷分散検証...6

3. 2 SSL アクセラレーター性能検証...9

3. 3 保守性検証...12

3.3.1 サーバの追加...12

3.3.2 サーバ保守...15

3.3.3 セッションオーバー発生時の sorry メッセージ表示...18

4.まとめ...20

(3)

Technical White Paper

はじめに



1.はじめに

WEB コンピューティングの普及により、拡張性を見込んだ柔軟なシステムの構 築が望まれ、システムへのハイパフォーマンス、ハイアベイラビリティの要求 が増加しています。また、プラットフォームのオープン化に伴いシステムが複 雑化したことにより、ソフトウェアやハードウェアの製品個々の単独ではなく、 ソリューションシステムとしてシステムトータルで検証することが求められて います。 この要求に対し、アプリケーションとビジネスの統合といったニーズに対応す るアプリケーション・プラットフォームである BEA WebLogic Server 9.x とサー バシステムとネットワークの接点となるシステムフロントに必要な機能を統合 したネットワークサーバ IPCOM との組み合わせにより、信頼性の高い、WEB システムを構築することが可能です。

日本 BEA システムズ株式会社 (http://www.beasys.co.jp/) と富士通株式会社 (http://jp.fujitsu.com/) は、BEA WebLogic Server と IPCOM での「アプリケー ションサーバフロント統合アライアンス」を実施します。

今回、本アライアンスのひとつとして、Windows システム上での WEB システ ムフロントに着目した両製品によるシステム検証を行いましたので、ご報告い たします。

本検証では、BEA WebLogic Server と IPCOM を使った WEB システムを構築す る場合に必要なシステム構成及び各種設定を、実運用に近い構成で検証し、明 確にします。 本文書の著作権は、日本 BEA システムズ株式会社および富士通株式会社に帰属します。 日本 BEA システムズ株式会社および富士通株式会社の文書による許諾なしに、本文書の 全部および一部を複製、販売、転用等することは禁じられています。本文書は、情報提供 のみを目的としており、特定の製品の仕様を定義したり、特定の運用方法を推奨したりす るものではなく、本文書および本文書に含まれる情報に基づく決定について、日本 BEA システムズ株式会社および富士通株式会社は、いかなる責も負わないものとします。日本 BEA システムズ株式会社および富士通株式会社は、本文書に関し、その内容の正確性、妥 当性を含め、いかなる保証も明示たると黙示たるとを問わず、一切いたしません。日本 BEA システムズ株式会社および富士通株式会社は、本文書に記載された製品の仕様なら びに動作を、お客様への予告なく変更する場合があります。Windows は、米国 Microsoft Corporation の米国およびその他の国における登録商標です。BEA WebLogic Server、 WebLogic は、BEA systems Inc. の登録商標もしくは商標です。本文書に記載されている 会社名、製品名、名称等は、すべて各社の商標または登録商標です。本資料に記載されて いるシステム名、製品名等には、必ずしも商標表示 ((R)、(TM)) を付記していません。

(4)

Technical White Paper

検証概要



2.検証概要

2. 1 システム構成

以下に検証を行ったシステム構成を示します。検証システムには、イントラネッ トに接続した WEB システム構成モデルとし、利用率が高い Windows 版の BEA WebLogic Server を採用し、アプケーションサーバのスケラビリティを考慮し、 サーバのスケールアウトが容易なブレードサーバを使用します。また、アプリ ケーションサーバの負荷分散、SSL アクセラレーターおよびファイアーウォール としてネットワークサーバ IPCOM の最新機種である IPCOM S400 を使用しま す。以下にシステム構成図を示します。 図 2-1. 検証システム構成

2. 2 ハードウェア

【ネットワーク】 ◆サーバ負荷分散(SLB)・ファイアーウォール・SSL アクセラレーター装置 FUJITSU IPCOM S400 ×  台 ( 二重化構成 ) ◆セキュアスイッチ FUJITSU SR-S36C ×  台 【サーバ】 ◆ WEB サーバ/アプリケーションサーバ FUJITSU PRIMERGY BX600(サーバブレード × 4 ) CPU:Intel Xeon CPU 3.06 GHz MEM:.0GB

オペレーティングシステム: Windows Server 003 Standard Edition SP 【クライアント】

◆ PC

FUJITSU ESPRIMO K50 ×  台

CPU:Intel Celeron CPU.66GHz MEM:.0GB

オペレーティングシステム: Windows XP Professional SP  FUJITSU ESPRIMO K500 ×  台

CPU:Intel Celeron M processor .40GHz MEM:.0GB オペレーティングシステム: Windows XP Professional SP

【WEB サーバおよびアプリケーションサーバ】 BEA WebLogic Server 9.

【検証用アプリケーション】

Avitek Medical Records(WebLogic サンプルアプリケーション) PC 4 台 PC サーバ  PRIMERGY BX600 ( サーバブレード ×4) セキュアスイッチ  SR-S316C2 セキュアスイッチ  SR-S316C2 FW/SLB IPCOM S2400

2. 3 ソフトウェア

(5)

Technical White Paper

検証概要

3

検証用アプリケーションの構成は以下のとおりです。 アプリケーションの一連の動作は以下のとおりです。 (1)PC の WEB ブラウザから WEB サーバをアクセスします。 http://{ ホスト名 }:700/index_ja.jsp 以下の初期画面が表示されたら、サンプルアプリケーション(Avitek Medical Records)をアクセスします([MedRec の開始]をクリックします)。

(2)WEB ブラウザに Avitek Medical Records のメニュー画面(下左図)が表示 れます。医師を選択し、ログインをクリックします。

図 2-2. アプリケーション構成

サーバブレード (PC サーバ )

Windows Server 2003 Standard Edition

MedrecEAR

PhysianEAR

StartBrowserEAR

InitEAR

BEA WebLogic Server

DB

(PointBase)

JMS

(6)

Technical White Paper

検証概要

4

(3)WEB ブラウザに認証画面(上右図)が表示されます。ユーザ名とパスワー ドを入力し、[ログイン]をクリックします。 (4)患者の検索画面(下左図)が表示されます。姓(例えば、A)を入力し、[検 索]をクリックします。 (5)検索結果画面(上右図)が表示されます。 (6)検索した患者の姓をクリックし、患者情報(下左図)を表示します。 (7)患者情報の表示画面で[プロファイル]をクリックし、プロファイル情報(上 右図)を表示します。 (8)プロファイル表示画面で[ログアウト]をクリックします。 検証で利用する(2)~(7)の各画面のデータサイズは以下のとおりです。 画面名 画面サイズ(バイト) (2)メニュー画面 26115 (3)認証画面 26031 (4)検索画面 7679 (5)検索結果画面 4513 (6)患者情報画面 3518 (7)プロファイル画面 2996 合計 70852

(7)

Technical White Paper

検証概要

5

◆サーバ負荷分散検証

IPCOM S400 のサーバ負荷分散機能を使い、BEA WebLogic Server システム の負荷分散を検証します。 ◆ SSL アクセラレーター性能検証 IPCOM S400 の SSL アクセラレーターの性能を検証します。 ◆保守性検証 IPCOM S400 の機能を利用したサーバシステムの保守性とサービス性を検証 します。 【負荷ツール】

Microsoft Web Application Stress Tool(以降 WAS) 【検証手順】 多数の仮想端末からサーバへのアクセスを発生させる検証では、WAS の Script 機能を使用し、あらかじめサンプルアプリケーションの一連の動作処理 を登録しておき、その Script を自動実行させます。 自動実行では、ウォーミングアップを 30 秒、測定時間を数分間として連続的 に実行させます。 測定回数は複数回数とします。 登録する一連の動作処理は、以下のとおりです。 ① メニュー画面を表示します。 ② 医師でログインします。 ③ 患者の検索を実施します。 ④ 検索結果の1名を選択し、表示します。 ⑤ 選択した患者のプロファイルを表示します。 ⑥ ログアウトします。 ※ 上記の処理については、前述の「2.3 ソフトウェア」を参照してくだ さい。 【検証期間】 006 年 7 月 3 日から 006 年 7 月 0 日 【検証場所】 富士通株式会社 社内

2. 4 検証項目

2. 5 検証方法

2. 6 検証実施詳細

(8)

Technical White Paper

検証結果と考察

6

3.検証結果と考察

3. 1 サーバ負荷分散検証

アプリケーションとビジネスの統合といったニーズに対応するアプリケーショ ン・プラットフォームを利用したシステムが普及しており、IPCOM との整合 性の確認が求められています。

そこで、IPCOM S400 を使用して、BEA WebLogic Server の WEB アプリケー ションシステムに対するサーバ負荷分散の検証を行い、その結果を報告します。 以下にサーバ負荷分散のシステム構成を示します。 1)検証条件 ・サーバ負荷分散(SLB)方式 以下の2通りの方式を評価します。 -ラウンドロビン方式 -最小コネクション数 ・セッション維持(一意性保証) 負荷分散の単位は、コネクション単位で評価します。 セッションの維持は、cookie オプションを利用する以下の2通りの方式 を評価します。 -クライアント ID 挿入方式

IPCOM 自身が cookie キー(FJNADDSPID=)にクライアント ID を 挿入する。

-セッション ID 参照方式

BEA WebLogic Server にて Java Servlet が Set-cookie で設定したキー (JSESSIONID=)のセッション ID を IPCOM が参照する。 ・ファイアーウォール アプリケーションサーバへ必要なアクセス(ARP、http、https)のみ許 可し、それ以外は遮断します。 ・SSL アクセラレーター 本検証では SSL 通信は使用しません。

※ IPCOM の WEB アプリケーションの負荷分散機能では、WEB アクセラ レーター機能を使用しない場合、TCP コネクション単位で振り分けを行 図 3-1. サーバ負荷分散システム PC 4 台 PC サーバ  PRIMERGY BX600 ( サーバブレード ×4) セキュアスイッチ  SR-S316C2 セキュアスイッチ  SR-S316C2 FW/SLB IPCOM S2400 負荷分散

(9)

Technical White Paper

検証結果と考察

7

うので、サーバの設定で KeepAlive 機能をオフにする必要があります。

本 評 価 で は、WEB ア ク セ ラ レ ー タ ー 機 能 を 使 用 し な い た め、BEA WebLogic Server の KeepAlive 設定をオフにします。

2)検証方法

WEB サーバ/アプリケーションサーバとして BEA WebLogic Server 9. を 4 台のサーバブレードにインストールし、サンプルアプリケーション (Avitek Medical Records) を検証用アプリケーションとして稼動させて利 用します。 クライアント ID 挿入方式によるセッション維持でのサーバ負荷分散の 検証は、クライアント PC を 4 台同時に動作させ、 台の PC で 40 仮想 端末の WAS を起動することで合計 60 の仮想端末を使用し、WAS の script 機能による自動実行を行いました。測定時間は 3 分間で連続走行を 実行し、測定を 5 回繰り返します。 セッション ID 参照方式によるセッション維持の検証は、4 台のクライア ント PC のブラウザからサンプルアプリケーションをアクセスして実施し ます。 3)検証結果 ラウンドロビンおよびと最小コネクション数の2つの負荷分散方式によ るサーバ負荷分散機能で、クライアントからのアクセスがほぼ均等に割 り振られ、各サーバの負荷がほぼ均一でした。これは、IPCOM の負荷分 散モニタ画面で目視し、確認しました。以下に、二通りの負荷分散方式 による IPCOM のコネクション数の負荷分散モニタ画面表示例を示しま す。     図 3-2-1. ラウンドロビン方式 図 3-2-1. 最小コネクション方式 セッション維持方式 負荷分散方式 クライアント ID 挿入 セッション ID 参照 ラウンドロビン 問題なし 問題なし 最小コネクション数 問題なし 問題なし

(10)

Technical White Paper

検証結果と考察



4)考察

IPCOM S400 のサーバ負荷分散機能を使用し、BEA WebLogic Server で 稼動するサンプルアプリケーションへのクライアントからのアクセスが 分散されることを検証しています。 セッション維持では、クライアント ID 挿入方式およびセッション ID 参 照方式の両方でセッションが維持された状態で、サーバ負荷分散が行わ れることを検証しています。 サーバ負荷分散では、負荷分散方式による性能差はないと考えられます。 なお、今回の検証結果では、BEA WebLogic Server は、サーバの CPU 負 荷率がほぼ 00%で動作しているため、負荷計測エージェントを使用した CPU 負荷率でのサーバ負荷分散方式は、利用しても効果が少ないと考え られます。

5)参考

サーバ負荷分散方式による性能差の検証は、BEA WebLogic Server の自 動チューニング機能により、測定を繰り返すごとに単位時間当たりの処 理件数が増加するため、性能値の確定ができませんでした。

以下に例として、負荷分散をラウンドロビン方式でセッション維持をク ライアント ID 挿入方式で行う条件にて測定した単位時間当たりのリクエ スト数の推移を示します。

※ BEA WebLogic Server の自動チューニング機能とは、アクセス数に したがってスレッドを増減させる機能のことです。

なお、今回の検証結果では、BEA WebLogic Server は、サーバ CPU 負荷 率(タスクマネージャで目視計測)がほぼ 00%で動作しています。しか しながら、クライアント PC の CPU 負荷率(タスクマネージャで目視計 測)は、4 ~ 50%のばらつきはありますが、平均で 0%前後であるため、 また、ネットワークのトラッフィク(IPCOM の QoS モニタでの目視計測) も約 Mbps であるため、クライアント PC の処理性能やネットワーク トラフィックによる阻害はないと考えられます。 計測回数 ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ リクエスト数 /単位時間 377.1 428.7 463.4 508.1 530.6 557.3 583.7 606.4 図 3-3. 単位時間当たりのリクエスト数の推移

(11)

Technical White Paper

検証結果と考察

9

3. 2 SSL アクセラレーター性能検証

データの盗聴や改ざん、成りすましを防止するため、SSL による暗号化通信の 利用が増加しており、イントラネット内のシステムにおいても高度のセキュリ ティが求められています。しかし、SSL による暗号化通信を利用する場合、暗 号化/復号化の処理を行う必要があり、この処理を WEB サーバで行うとサー バのパフォーマンスが低下します。 そこで、IPCOM の SSL アクセラレーター機能を利用することにより、暗号化 /復号化処理を WEB サーバから IPCOM へオフロードすることにより、WEB サーバのパフォーマンスを向上させることができます。

SSL 通信を行うにあたり、IPCOM S400 の SSL アクセラレーター機能を利用 する場合と、BEA WebLogic Server の SSL 機能(サーバで実行)を利用する場 合との性能を検証し、その結果を報告します。

なお、IPCOM S400 の SSL アクセラレーター機能と BEA WebLogic Server で の SSL 機能の条件を一致させるため、アプリケーションサーバは  台で検証を 行います。

以下に IPCOM の SSL アクセラレーター機能を使用した通信と BEA WebLogic Server の SSL 機能を使用した通信の例を示します。

図 3-4-2. BEA WebLogic Server の SSL 機能使用例 図 3-4-1. IPCOM S2400 の SSL アクセラレーター機能使用例 PC 4 台 PC サーバ  PRIMERGY BX600 ( サーバブレード ×4) セキュアスイッチ  SR-S316C2 セキュアスイッチ  SR-S316C2 FW/SLB IPCOM S2400 https 通信 SSLアクセラレーター PC 4 台 PC サーバ  PRIMERGY BX600 ( サーバブレード ×4) セキュアスイッチ  SR-S316C2 セキュアスイッチ  SR-S316C2 FW/SLB IPCOM S2400 https 通信 SSL 機能

(12)

Technical White Paper

検証結果と考察

0

1)検証条件 ・サーバ負荷分散(SLB)方式 ラウンドロビン方式 ・セッション維持(一意性保証) 分散の単位は、ノード単位で評価します。 ・ファイアーウォール アプリケーションサーバへ必要なアクセス(ARP、http、https)のみ許 可し、それ以外は遮断します。 ・SSL アクセラレーター 以下の  通りの方式を評価します。 - IPCOM の SSL アクセラレーター機能使用時。 - BEA WebLogic Server の SSL 機能使用時。 2)検証方法

WEB サーバ/アプリケーションサーバとして BEA WebLogic Server 9. を  台のサーバブレードにインストールし、サンプルアプリケーション (Avitek Medical Records) を検証用アプリケーションとして稼動させて利 用します。このとき、他の 3 台のサーバブレードは IPCOM のシャットダ ウン制御機能を利用して停止状態にします。

クライアント PC を 4 台同時に動作させ、 台の PC で 0 仮想端末の WAS を起動することで合計 40 の仮想端末を使用し、WAS の script 機能 による自動実行を行います。測定時間は 3 分間で連続走行を実行し、測 定を 5 回繰り返します。

3)検証結果

IPCOM の SSL ア ク セ レ ー タ 機 能 を 使 用 す る 場 合 は、BEA WebLogic Server の SSL 機能を使用する場合に比べ、約 .7 倍高速でした。

以下に、SSL 機能処理装置ごとの単位時間当たりのリクエスト数(測定 4 回の平均値)を示します。

SSL 機能処理装置 IPCOM WebLogic Server 性能比率

リクエスト数/単位時間 122.0 73.3 1.7

(13)

Technical White Paper

検証結果と考察



4)考察

IPCOM の SSL アクセラレーター機能を使用する場合、BEA WebLogic Server の SSL 機能を使用するよりも、専用ハードウェアであるため処理 が高速であることは当然です。しかし、今回の検証結果では、利用した サンプルアプリケーションの一連の処理で使用するコンテンツのサイズ が合計で約 70 キロバイトしかなく、暗号化/複合化処理以外の DB 処理 などのアプリケーションの動作処理に時間が多くとられ、暗号化/復号 化処理にはあまり時間が取られていないと考えられます。このため、両 者の性能差が小さかったと推測します。 大容量のコンテンツが多い WEB サイトでは、暗号化/複合化処理に多く の時間がとられるために、IPCOM の SSL アクセラレーター機能による暗 号化/複合化処理のオフロードの効果は大きいと考えられます。

(14)

Technical White Paper

検証結果と考察



3. 3 保守性検証

システムの初期投資を最小限におさえ、ビジネスの拡大にあわせシステムを増 強することが望まれていますが、システムの増強にはサービス停止が必要です。 しかし、IPCOM を導入することで、サービス無停止でシステムの増強が可能 です。 システムの利用者増加などにより、システムの負荷が増加しサーバのスケール アウトが必要になった時の手順とサービス性に関して検証を行い、結果を報告 します。 以下にサーバ追加の概念図を示します。 1)検証条件 ・サーバ負荷分散(SLB)方式 ラウンドロビン方式 ・セッション維持(一意性保証) コネクション単位の分散によるクライアント ID 挿入方式

3.3.1 サーバの追加

IPCOM が提供する以下の機能についてサーバシステムの保守性とサービス性 の検証を行い、結果を報告します。 ・サーバの追加 ・サーバ保守 ・セッションオーバー発生時の Sorry メッセージ表示 図 3-6. サーバのスケールアウト PC 4 台 PC サーバ  PRIMERGY BX600 ( サーバブレード ×4) セキュアスイッチ  SR-S316C2 セキュアスイッチ  SR-S316C2 FW/SLB IPCOM S2400 PC 8台 PC サーバ  PRIMERGY BX600 ( サーバブレード ×4) セキュアスイッチ  SR-S316C2 セキュアスイッチ  SR-S316C2 FW/SLB IPCOM S2400 クライアントの増加に伴い、サーバブレードを 1 台追加 サーバブレード (up/active) サーバブレード(down/-)

(15)

Technical White Paper

検証結果と考察

3

・ファイアーウォール アプリケーションサーバへ必要なアクセス(ARP、http、https)のみ許 可し、それ以外は遮断します。 ・SSL アクセラレーター 本検証では SSL 通信は使用しません。 2)検証方法

WEB サーバ/アプリケーションサーバとして BEA WebLogic Server 9. をサーバブレードにインストールし、サンプルアプリケーション (Avitek Medical Records) を検証用アプリケーションとして稼動させて利用しま す。 最初は  台のサーバブレードを稼動し、その後、1台のサーバブレード のスケールアウトを実施し、稼動させます。 スケールアウト前は、クライアント PC を  台同時に動作させ、 台の PC で 0 仮想端末の WAS を起動することで合計 40 の仮想端末を使用し、 WAS の Script 機能による自動実行で連続走行を行います。 さらに、スケールアウト後 PC を  台追加し、4 台のクライアント PC を 同時に動作させ、合計 0 の仮想端末を使用し、WAS の Script 機能によ る自動実行で連続走行を行います。 IPCOM の操作は、あらかじめ追加するサーバを定義しておき、以下のモ ニタ画面の操作により、 台のサーバのスケールアウトを実施します。 3)検証結果 前もって、IPCOM でスケールアウト時に追加するサーバを保守状態にし ておき、途中でスケールアウトを実行してもクライアントのセッション が切断されることなく、追加したサーバにもアクセスが分散されること を IPCOM の負荷分散モニタ画面で目視し、確認しました。 以下に、サーバを  台スケールアウトした場合のサーバ負荷分散状態を IPCOM のコネクション数の負荷分散モニタ画面表示例で示します。 図 3-7.IPCOM の負荷分散ルール画面と保守状態の解除操作画面

(16)

Technical White Paper

検証結果と考察

4

4)考察 将来、WEB サーバのスケールアウトを意識したシステム構築を行い、あ らかじめ IPCOM のポリシーに WEB サーバを設定しておくことで、無停 止のスケールアウトが実現可能となります。 負荷が継続的に増加するシステムを構築する場合は、IPCOM を導入し、 構築時からスケールアウトを考慮したシステムの構築を行うことで、運 用中のサービスを無停止にすることが可能となります。 本検証のように、ブレードサーバ PRIMERGY BX600 を使用していると、 スケールアウトによるサーバ増設などが容易に行えます。 図 3-8. スケールアウト実施時の負荷分散状況

(17)

Technical White Paper

検証結果と考察

5

3.3.2 サーバ保守

サーバを運用していく上で、定期的にセキュリティパッチを適用していくのは 運用上、必須になっていますが、セキュリティパッチ適用時にはサーバの再起 動などサービス停止を伴うケースが多いです。

しかし、複数台設置した BEA WebLogic Server の前段に IPCOM を設置し、サー バ負荷分散を行うことにより、保守時には IPCOM のシャットダウン制御機能 を利用して、サーバの保守を順次実行していくことで、サービスを停止させず にサーバ保守を行うことが可能となり、サービス性がアップします。 サーバ保守を実施するには、一部のサーバを保守状態にする必要があるため、 サーバを保守状態にする手順とサービス性に関しての検証を行い、結果を報告 します。 以下にサーバ保守の概念図を示します。 1)検証条件 ・サーバ負荷分散(SLB)方式 ラウンドロビン方式 ・一意性保証(セッション維持) コネクション単位の分散によるクライアント ID 挿入方式 ・ファイアーウォール アプリケーションサーバへ必要なアクセス(ARP、http、https)のみ許 可し、それ以外は遮断します。 ・SSL アクセラレーター 本検証では SSL 通信は使用しません。 図 3-9. サーバの保守 PC 4 台 PC サーバ  PRIMERGY BX600 ( サーバブレード ×4) セキュアスイッチ  SR-S316C2 セキュアスイッチ  SR-S316C2 FW/SLB IPCOM S2400 PC サーバ  PRIMERGY BX600 ( サーバブレード ×4) セキュアスイッチ  SR-S316C2 FW/SLB IPCOM S2400 サーバ保守のため、サーバブレードを 2 台を保守状態に移行 サーバブレード (up/active) サーバブレード(down/-) PC 4 台 セキュアスイッチ  SR-S316C2

(18)

Technical White Paper

検証結果と考察

6

2)検証方法

WEB サーバ/アプリケーションサーバとして BEA WebLogic Server 9. をサーバブレードにインストールし、サンプルアプリケーション (Avitek Medical Records) を検証用アプリケーションとして、稼動させて利用し ます。 最初は 4 台のサーバブレードを稼動させ、その後、サーバ保守の実施に あたり  台のサーバブレードを保守状態にしてシステムから分離させま す。 クライアント PC は、4 台を同時に動作させ、 台の PC で 0 仮想端末の WAS を起動することで合計 0 の仮想端末を使用し、WAS の Script 機能 による自動実行で連続走行を行います。 IPCOM の操作は、以下のモニタ画面の操作により稼動中の 4 台のサーバ から  台を順次保守状態にします。 3)検証結果 IPCOM のサーバ負荷分散モニタの画面操作により、 台のサーバを保守 状態にすると、クライアント PC からの新規アクセスが保守状態にした サーバには振り分けられないことを IPCOM の負荷分散モニタ画面で目視 し、確認しました。以下に、サーバの保守を実施した場合(4 台 ⇒  台) のサーバ負荷分散の状態を IPCOM のコネクョン数の負荷分散モニタ画面 表示例で示します。          図 3-10. IPCOM の負荷分散ルール画面と保守状態の設定操作画面

(19)

Technical White Paper

検証結果と考察

7

4)考察

BEA WebLogic Server が稼動しているサーバシステムのサーバ保守を実 行する場合でも、IPCOM のシャットダウン機能を利用し、サーバを切り 離して保守を実施することで、サービスを停止させることなくサーバの 保守が実現可能になります。 また、保守が完了したサーバをシステムに復旧させる場合も、IPCOM の 操作によりサービスを停止させることなく、サーバをシステムに組み込 むことが可能です。組み込まれたサーバには、IPCOM のスロースタート 制御機能により、クライアント PC の新規アクセスから徐々に振り分けら れ安定した負荷分散が行われます。 なお、サーバ保守中の場合は、保守をしていないサーバのコネクション 数が増加するため、あらかじめシステム設計時に保守時の最大コネクショ ン数を考慮する必要があります。 本検証のように、ブレードサーバ PRIMERGY BX600 を使用していると、 サーバの保守が容易に行えます。 図 3-11. サーバ保守実施時(2 台 ⇒ 4 台)の負荷分散状況

(20)

Technical White Paper

検証結果と考察



3.3.3 セッションオーバー発生時の sorry メッセージ表示

システムの能力以上の要求をクライントから受けると現在のほとんどの IT システムはスローダウンまたはシステム停止になってしまいます。しかし、 IPCOM を導入することで、クライントの要求を制限し、制限したクライント にはメッセージを出すことができます。 セッションオーバーが発生した場合の動作とサービス性を検証し、結果を報告 します。 1)検証条件 ・サーバ負荷分散(SLB)方式 ラウンドロビン方式 ・一意性保証(セッション維持) コネクション単位の分散によるクライアント ID 挿入方式 ・ファイアーウォール アプリケーションサーバへ必要なアクセス(ARP、http、https)のみ許 可し、それ以外は遮断します。 ・SSL アクセラレーター 本検証では SSL 通信は使用しません。 2)検証方法

WEB サーバ/アプリケーションサーバとして BEA WebLogic Server 9. をサーバブレード 4 台にインストールし、サンプルアプリケーション (Avitek Medical Records) を検証用アプリケーションとして稼動させて利 用します。

クライアント PC は、 台を同時に動作させ、 台の PC で 40 仮想端末の WAS を起動することで合計 0 の仮想端末を使用し、WAS の Script 機能 による自動実行で連続走行を行います。 IPCOM の操作は、クライアントからのアクセス数を制限するアクセス制 限機能でコネクション数を 00 と設定し、コネクション数がオーバー した場合は sorry メッセージを表示するように設定します。 3)検証結果 クライアントからの連続的なアクセスによりアクセス制限数を超え、セッ 図 3-12. セッションオーバーの発生 PC サーバ  PRIMERGY BX600 ( サーバブレード ×4) セキュアスイッチ  SR-S316C2 セキュアスイッチ  SR-S316C2 FW/SLB IPCOM S2400

(21)

Technical White Paper

検証結果と考察

9

ションオーバーの状態が発生した場合に、新規アクセスを行ったクライ アントに以下の sorry メッセージ画面が表示され、アクセスが受けつけら れないことを IPCOM の負荷分散モニタ画面で目視し、確認しました。 4)考察 IPCOM のアクセス制限機能とセッションオーバーエラー発生時に sorry メッセージを表示する設定を行うことにより、sorry サーバを別途設置し なくても、クライアントに対し、システムの接続制限を通知することが 可能となります。 これにより、システムダウンなどの発生を未然に防ぐことが可能となり ます。 図 3-13. IPCOM からの sorry メッセージ表示画面

(22)

Technical White Paper

まとめ

0

4.まとめ

今回の検証では、BEA WebLogic Server と IPCOM を使った WEB アプリケーショ ンシステムにおける、「サーバ負荷分散」、「SSL アクセラレーター性能」、「保守性」 の 3 つの観点から特性と運用上の注意点などの検証を行いました。

サーバ負荷分散では、BEA WebLogic Server のサンプルアプリケーションのサー バ負荷分散が IPCOM で可能であり、セッション維持も問題なく行えました。 サーバ負荷分散の方式では、ラウンドロビン方式でも最小コネクション数でも性 能的には差はないと考えられます。

また、BEA WebLogic Server はサーバのサンプルアプリケーションを稼動した場 合に、今回の検証結果ではサーバの CPU 負荷率は 00%となるため、負荷計測エー ジェントを使用する負荷分散方式では効果が現れないと考えられます。

SSL アクセラレーター性能では、IPCOM の SSL アクセラレーター機能を利用す る方が BEA WebLogic Server の SSL 機能を利用するより、約 .7 倍の性能が良い という検証結果から、IPCOM の SSL アクセラレーター機能を利用することにより、 WEB サーバ/アプリケーションサーバのパフォーマンスを向上させることがで きます。 今回の検証結果では、検証で使用したサンプルアプリケーションの一連の処理で 使用するコンテンツのデータ量が少ない(コンテンツの合計で約 70 Kbyte)ため、 暗号化/複合化処理以外の DB 処理などのアプリケーションの動作処理の方に時 間が多くとられ、暗号化/復号化処理にはあまり時間が取られていないと考えら れます。 このため、大容量のコンテンツが多い WEB サイトなどでは、IPCOM の SSL アク セラレーター機能による暗号化/複合化処理のオフロードの効果はさらに大きく なると考えられます。 保守性では、サーバの追加やサーバの保守において IPCOM の保守機能を利用す ることで、サービス性が向上することがわかりました。 モニタの画面操作により、サーバを保守状態へ移行し、作業完了後保守状態を解 除することで、アプリケーションシステムのサービスを停止させないようにする ことができます。 また、ブレードサーバ PRIMERGY BX600 を使用してシステムを構築することに より、IPCOM の機能を利用したサーバ保守やサーバのスケールアウトが容易に 行えます。

(23)

Technical White Paper

日本 BEA システムズ-富士通 アプリケーションサーバフロント統合アライアンス テクニカルホワイトペーパー 【Windows プラットフォーム編】 006 年 9 月 初版

Updating...

参照

Updating...

関連した話題 :