Technical White Paper Copyright ©2006 BEA Systems Japan,Ltd. Fujitsu Ltd. All Rights Reserved. 日本 BEA システムズ‒ 富士通 アプリケーションサーバフロント統合 アライアンステクニカルホワイトペーパー 【Windows プラットフォーム編】 ネットワークサーバ アイピーコム IPCOM

Technical White Paper 日本BEAシステムズ‒ 富士通 ......WebLogicは、BEA systems Inc. の登録商標もしくは商標です。本文書に記載されている 会社名、製品名、名称等は、すべて各社の商標または登録商標です。本資料に記載されて

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Technical White Paper

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

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

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

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

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

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

IPCOM

Technical White Paper

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

IPCOM

目次1.はじめに...............................................................................................................................................12.検証概要...............................................................................................................................................22. 1 システム構成.............................................................................................................................22. 2 ハードウェア.............................................................................................................................22. 3 ソフトウェア.............................................................................................................................22. 4 検証項目......................................................................................................................................52. 5 検証方法......................................................................................................................................52. 6 検証実施詳細.............................................................................................................................53.検証結果と考察.................................................................................................................................63. 1 サーバ負荷分散検証................................................................................................................63. 2 SSL アクセラレーター性能検証..........................................................................................93. 3 保守性検証..................................................................................................................................123.3.1 サーバの追加.......................................................................................................................123.3.2 サーバ保守...........................................................................................................................153.3.3 セッションオーバー発生時の sorry メッセージ表示..........................................184.まとめ...................................................................................................................................................20

Technical White Paper

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

IPCOMはじめに

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)) を付記していません。

Technical White Paper

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

IPCOM検証概要

2.検証概要

2. 1 システム構成

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

図 2-1. 検証システム構成

2. 2 ハードウェア

【ネットワーク】◆サーバ負荷分散(SLB)・ファイアーウォール・SSL アクセラレーター装置

FUJITSU IPCOM S�400 × � 台 ( 二重化構成 )◆セキュアスイッチ

FUJITSU SR-S3�6C� × � 台【サーバ】

◆ WEB サーバ/アプリケーションサーバFUJITSU PRIMERGY BX600(サーバブレード × 4 )

CPU:Intel Xeon CPU 3.06 GHz MEM:�.0GBオペレーティングシステム: Windows Server �003 Standard Edition SP�

【クライアント】◆ PC

FUJITSU ESPRIMO K5��0 × � 台CPU:Intel Celeron CPU�.66GHz MEM:�.0GBオペレーティングシステム: Windows XP Professional SP�

 FUJITSU ESPRIMO K5�00 × � 台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 ソフトウェア

Technical White Paper

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

IPCOM検証概要

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

MedrecEARPhysianEAR

StartBrowserEARInitEAR

BEA WebLogic Server DB(PointBase)

JMS( ファイル )

Technical White Paper

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

IPCOM検証概要

4

(3)WEB ブラウザに認証画面(上右図)が表示されます。ユーザ名とパスワードを入力し、[ログイン]をクリックします。

(4)患者の検索画面(下左図)が表示されます。姓(例えば、A)を入力し、[検索]をクリックします。

(5)検索結果画面(上右図)が表示されます。

(6)検索した患者の姓をクリックし、患者情報(下左図)を表示します。

(7)患者情報の表示画面で[プロファイル]をクリックし、プロファイル情報(上右図)を表示します。

(8)プロファイル表示画面で[ログアウト]をクリックします。

検証で利用する(2)~(7)の各画面のデータサイズは以下のとおりです。

画面名 画面サイズ(バイト)

(2)メニュー画面 26115

(3)認証画面 26031

(4)検索画面 7679

(5)検索結果画面 4513

(6)患者情報画面 3518

(7)プロファイル画面 2996

合計 70852

Technical White Paper

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

IPCOM検証概要

5

◆サーバ負荷分散検証IPCOM S�400 のサーバ負荷分散機能を使い、BEA WebLogic Server システムの負荷分散を検証します。

◆ SSL アクセラレーター性能検証IPCOM S�400 の SSL アクセラレーターの性能を検証します。

◆保守性検証IPCOM S�400 の機能を利用したサーバシステムの保守性とサービス性を検証します。

【負荷ツール】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 検証実施詳細

Technical White Paper

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

IPCOM検証結果と考察

6

3.検証結果と考察3. 1 サーバ負荷分散検証

アプリケーションとビジネスの統合といったニーズに対応するアプリケーショ

ン・プラットフォームを利用したシステムが普及しており、IPCOM との整合

性の確認が求められています。

そこで、IPCOM S�400 を使用して、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

負荷分散

Technical White Paper

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

IPCOM検証結果と考察

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参照

ラウンドロビン 問題なし 問題なし

最小コネクション数 問題なし 問題なし

Technical White Paper

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

IPCOM検証結果と考察

4)考察

IPCOM S�400 のサーバ負荷分散機能を使用し、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. 単位時間当たりのリクエスト数の推移

Technical White Paper

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

IPCOM検証結果と考察

9

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

データの盗聴や改ざん、成りすましを防止するため、SSL による暗号化通信の

利用が増加しており、イントラネット内のシステムにおいても高度のセキュリ

ティが求められています。しかし、SSL による暗号化通信を利用する場合、暗

号化/復号化の処理を行う必要があり、この処理を WEB サーバで行うとサー

バのパフォーマンスが低下します。

そこで、IPCOM の SSL アクセラレーター機能を利用することにより、暗号化

/復号化処理を WEB サーバから IPCOM へオフロードすることにより、WEB

サーバのパフォーマンスを向上させることができます。

SSL 通信を行うにあたり、IPCOM S�400 の SSL アクセラレーター機能を利用

する場合と、BEA WebLogic Server の SSL 機能(サーバで実行)を利用する場

合との性能を検証し、その結果を報告します。

なお、IPCOM S�400 の 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 機能

Technical White Paper

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

IPCOM検証結果と考察

�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

図 3-5. SSL 機能の性能

Technical White Paper

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

IPCOM検証結果と考察

��

4)考察

IPCOM の SSL アクセラレーター機能を使用する場合、BEA WebLogic

Server の SSL 機能を使用するよりも、専用ハードウェアであるため処理

が高速であることは当然です。しかし、今回の検証結果では、利用した

サンプルアプリケーションの一連の処理で使用するコンテンツのサイズ

が合計で約 70 キロバイトしかなく、暗号化/複合化処理以外の DB 処理

などのアプリケーションの動作処理に時間が多くとられ、暗号化/復号

化処理にはあまり時間が取られていないと考えられます。このため、両

者の性能差が小さかったと推測します。

大容量のコンテンツが多い WEB サイトでは、暗号化/複合化処理に多く

の時間がとられるために、IPCOM の SSL アクセラレーター機能による暗

号化/複合化処理のオフロードの効果は大きいと考えられます。

Technical White Paper

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

IPCOM検証結果と考察

��

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/-)

Technical White Paper

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

IPCOM検証結果と考察

�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 の負荷分散ルール画面と保守状態の解除操作画面

Technical White Paper

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

IPCOM検証結果と考察

�4

4)考察

将来、WEB サーバのスケールアウトを意識したシステム構築を行い、あ

らかじめ IPCOM のポリシーに WEB サーバを設定しておくことで、無停

止のスケールアウトが実現可能となります。

負荷が継続的に増加するシステムを構築する場合は、IPCOM を導入し、

構築時からスケールアウトを考慮したシステムの構築を行うことで、運

用中のサービスを無停止にすることが可能となります。

本検証のように、ブレードサーバ PRIMERGY BX600 を使用していると、

スケールアウトによるサーバ増設などが容易に行えます。

図 3-8. スケールアウト実施時の負荷分散状況

Technical White Paper

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

IPCOM検証結果と考察

�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-S316C2FW/SLB

IPCOM S2400

サーバ保守のため、サーバブレードを 2台を保守状態に移行

サーバブレード(up/active)

サーバブレード(down/-)

PC 4 台

セキュアスイッチ SR-S316C2

Technical White Paper

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

IPCOM検証結果と考察

�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 の負荷分散ルール画面と保守状態の設定操作画面

Technical White Paper

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

IPCOM検証結果と考察

�7

4)考察

BEA WebLogic Server が稼動しているサーバシステムのサーバ保守を実

行する場合でも、IPCOM のシャットダウン機能を利用し、サーバを切り

離して保守を実施することで、サービスを停止させることなくサーバの

保守が実現可能になります。

また、保守が完了したサーバをシステムに復旧させる場合も、IPCOM の

操作によりサービスを停止させることなく、サーバをシステムに組み込

むことが可能です。組み込まれたサーバには、IPCOM のスロースタート

制御機能により、クライアント PC の新規アクセスから徐々に振り分けら

れ安定した負荷分散が行われます。

なお、サーバ保守中の場合は、保守をしていないサーバのコネクション

数が増加するため、あらかじめシステム設計時に保守時の最大コネクショ

ン数を考慮する必要があります。

本検証のように、ブレードサーバ PRIMERGY BX600 を使用していると、

サーバの保守が容易に行えます。

図 3-11. サーバ保守実施時(2 台 ⇒ 4 台)の負荷分散状況

Technical White Paper

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

IPCOM検証結果と考察

��

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

Technical White Paper

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

IPCOM検証結果と考察

�9

ションオーバーの状態が発生した場合に、新規アクセスを行ったクライ

アントに以下の sorry メッセージ画面が表示され、アクセスが受けつけら

れないことを IPCOM の負荷分散モニタ画面で目視し、確認しました。

4)考察

IPCOM のアクセス制限機能とセッションオーバーエラー発生時に sorry

メッセージを表示する設定を行うことにより、sorry サーバを別途設置し

なくても、クライアントに対し、システムの接続制限を通知することが

可能となります。

これにより、システムダウンなどの発生を未然に防ぐことが可能となり

ます。

図 3-13. IPCOM からの sorry メッセージ表示画面

Technical White Paper

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

IPCOMまとめ

�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 の機能を利用したサーバ保守やサーバのスケールアウトが容易に行えます。

Technical White Paper

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

IPCOM

日本 BEA システムズ-富士通アプリケーションサーバフロント統合アライアンステクニカルホワイトペーパー

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

�006 年 9 月 初版Copyright © �006 BEA Systems Japan, Ltd. Fujitsu Ltd. All Rights Reserved.