IBM System p 上での Oracle Application Server 10g 性能検証

(1)

IBM System p 上での

Oracle Application Server 10g

性能検証

(2)

はじめに

多様化、高度化するアプリケーションの機能と性能を実現する一方で、それらに必要かつ十分な資源を適時に充当し、さらにシステムとしての信頼性を維持するという複合的な要件が、現在多くの IT インフラに求められています。また従来、CPU 資源の利用と言う範疇でのみ使用されていた「グリッド・コンピューティング」という概念とその手法も、この分野へパラダイムをシフトしつつあると言えます。先進的な仮想化技術を実装し、市場においても継続して評価を得ている IBM System p は高い蓋然性を持って、このグリッド・コンピューティングのための最適プラットフォームであると考えることができます。今回の検証では、特に性能と多ノード構成による拡張性(スケールアウト)を実現するために、System p とその主要な OS である IBM AIX5L の下に、 Oracle Fusion Middleware の主幹をなす、Oracle Application Server 10g と、高性能かつ高可用性を実現するデータベース、Oracle Real Application Clusters 10g を構成しました。この環境で現実に近いアプリケーション稼働させた場合の性能を様々な局面で測定し、システム全体としての拡張性を実証することを目標としました。

実際の構成としては、CPU16 個を有する IBM System p5 570 を複数の LPAR に分割した上で、Oracle Application Server 10g と Oracle Real Application Clusters 10g それぞれのノードに割り当てることによってグリッド・コンピューティング環境を構築しています。このシステム上で Oracle Application Server 10g ノードを 1 から順に増加させながら、それぞれの時点でのアプリケーションの性能を測定し、各ノード構成での測定結果を比較、グラフ化の上で拡張性に関する考察を加えました。次の段階として、Oracle Application Server 10g が提供するセッション情報のバックアップ機能であるセッション・レプリケーションを設定した上で各ノード構成での性能測定を行い、性能、スケーラビリティと信頼性の両立に関する検証を実施しています。さらに、発展段階として、IBM System p の仮想化技術の１つである Virtual Ethernet の性能測定や、Oracle Enterprise Manager 10g でグリッド・コンピューティング環境を監視した際のアプリケーションの性能への影響を検証しました。

(3)

謝辞

2006 年 11 月、日本オラクル株式会社は日本アイ・ビー・エム株式会社やグリッド戦略パートナー各社と協業体制を確立し、企業のシステム基盤の最適化を実現する次世代のビジネス・ソリューションを構築するため、先鋭の技術を集結した「Oracle GRID Center（オラクル・グリッド・センター）」( http://www.oracle.co.jp/solutions/grid_center/index.html )を開設しました。本稿は、Oracle GRID Centerの趣旨にご賛同頂いたシスコシステムズ合同会社のハードウェア・ソフトウェアのご提供および技術者によるご支援などの多大なるご協力を得て作成しております。協賛企業各社およびご協力頂いた技術者に深く感謝いたします。

(4)

2-3. システム構成... 13 3. 検証内容... 15 3-1. 検証用アプリケーション... 15 3-1-1. 使用アプリケーション ... 15 3-1-2. データベース・スキーマ ... 16 3-1-3. 処理手順 ... 17 3-2. Oracle HTTP Server ロード・バランシング・ポリシーの設定 ... 18 4. 検証結果... 19 4-1. 検証 1 基礎性能検証 ... 19 4-2. 検証 2 スケーラビリティ検証... 20 4-3. 検証 3 レプリケーション機能を使用したスケーラビリティ検証 ... 21 4-3-1. レプリケーション・プロトコルの違いによる性能への影響 ... 22 4-3-2. レプリケーション・トリガーの違いによる性能への影響 ... 24 4-3-3. レプリケーション・スコープの違いによる性能の影響 ... 26 4-3-4. 同期処理方式の違いによる性能への影響 ... 28 4-3-5. Write Quotaの違いによる性能への影響 ... 31 4-4. 検証 4 その他の検証 ... 33 4-4-1. サービスネットワークの兼用とVirtual Ethernetの活用 ... 33 4-4-2. Grid Control の管理エージェント動作時の負荷 ... 35 5. まとめ ... 36 6. 参考URL... 37

(5)

1. 実施要項

規模： 4 名

場所：日本オラクル株式会社 Oracle GRID Center

日本オラクル株式会社(データベースソフトウェアおよびミドルウェアの提供) 日本アイ・ビー・エム株式会社(ハードウェア及び OS 環境の提供)

2. 検証環境

2-1. ハードウェア

2-1-1. 使用ハードウェア 今回の検証で使用したハードウェアは以下のとおりです。データベース・サーバー IBM System p5 モデル 570 (以下 p5-570) CPU ：POWER5+ 2.2GHz 16Way

メモリー：64GB アダプター： 4 ポート 10/100/1000Base イーサーネット・アダプター × 16 枚 4 ギガビット・ファイバー・チャネル・アダプター × 3 枚高速 73.4GB ULTRA320 SCSI ディスク・ドライブ × 16 ドライブストレージ

コントローラ：IBM System Storage DS4800 (1815-82A)

拡張筐体：DS4000 EXP810 ストレージ拡張ユニット(1812-81A) 146.8GB/15K 4Gbps FC ドライブ × 4 ドライブ

SAN スイッチ

IBM TotalStorage SAN16B-2 × 2 台クライアントマシン

IBM BladeCenterH HS21 × 8 個

(6)

メモリー：4GB アダプター：デュアル・ギガビット・イーサーネットネットワークスイッチ Dell PowerConnect 5324 × 5 台 Cisco Catalyst 6504 × 1 台 Cisco Catalyst 3750 × 2 台その他機器

Hardware Management Console ：p5-570 ハードウェア管理端末(以下 HMC)

監視サーバー

CPU : Intel Pentium-D 3GHz × 1Way メモリー : 2GB 2-1-2. IBM System p のハードウェア機能 検証で使用した IBM System p のハードウェア機能[1]のうち、今回使用した機能について説明します。ロジカルパーティショニングサーバー内を複数のパーティション(区画)に論理的に分割できる機能です。サーバーのプロセッサーやメモリー、I/O などのリソースを、論理区画(LPAR)に分割し、それぞれを独立して動作させることを可能にするテクノロジーです。各 LPAR では Linux や IBM の UNIX である AIX 5L、および i5/OS などを稼働させることができ、1 台のサーバーで複数のオペレーティング環境を実現します。アドレス・マッピング・メカニズムで論理的に区画を分割する LPAR は、物理的な制約を受ける PPAR（フィジカル・パーティショニング）と異なり、プロセッサー、メモリー、アダプターなどをより柔軟に構成することができます。 LPAR には、プロセッサーの割り当て方法によって、専有プロセッサー論理区画と共有プロセッサー論理区画の 2 つのタイプがあります。専有プロセッサー論理区画は物理 CPU を 1 つの LPAR で専有して使用します。共有プロセッサー論理区画は、Micro-Partitioning 機能により、物理 CPU を複数の区画で共有して使用することができ、1 つの物理 CPU で最大 10 個の LPAR を動作させることが可能です。

(7)

Hardware Management Console(HMC) HMC は、IBM System p システムの仮想化に関する機能を制御する専用端末です。1 台の HMC で複数のサーバーを操作することが可能です。以下のような機能を提供します。 LPAR の管理パーティションの起動／停止／リセット／状態表示システムまたはパーティションのコンソールアクセスの提供 LPAR プロファイル（各 LPAR を構成するプロセッサー、メモリー、I/O

資源の割り当ての定義情報）の作成／保存予備リソースの活動化／非活動化問題判別やサービスサポートの為のツールの提供アナログ電話線を介して行う Call Home 機能やエラーログ通知機能等 Simultaneous Multi-threading(SMT) POWER5 プロセッサーより実装された機能です。SMT では、ある 1 つのスレッドが命令を実行中に、その１クロック・サイクルで使用されない演算ユニットを、独立した別のスレッドに開放して、使用することを可能にする機能です。 SMT 機能を使用すると、1 クロック・サイクル内で複数のスレッドが実行ユニットへのアクセスを共用できるため、システム・レベルでのパフォーマンス、使用率、およびスループットが向上します。SMT 機能のオン/オフは各 LPAR レベルで設定でき、Linux OS では OS 起動時のオプションで指定します。IBM System p 上にインストールされる OS は、デフォルトで SMT 機能がオンに設定されています。 Virtual Ethernet

POWER5 プロセッサーより実装された機能です。LPAR 間の TCP/IP 通信が物理イーサーネット・カードではなく、メモリーを介して行われます。Virtual Ethernet アダプターは HMC より定義され、1 つの LPAR に対して、最大 256 個定義することができます。Virtual Ethernet を使用する場合、基本的に 2 つの LPAR 間におけるメモリー転送であるため、データ転送は高速になります。ただし、転送にプロセッサーが関与するため、どちらが高速であるかは個別の状況により異なります。

(8)

2-2. ソフトウェア

今回の検証で使用したソフトウェアは以下のとおりです。アプリケーション・サーバー

AIX5L V5.3 Technical Level05 Service Pack 06 Oracle Application Server 10g Release 3 (10.1.3.1)

Oracle Enterprise Manager 10g Grid Control Management Agent(10.2.0.3) データベース・サーバー

AIX5L V5.3 Technical Level05 Service Pack 06 Oracle Database 10g Release2 (10.2.0.3) Oracle Clusterware 10g Release2(10.2.0.3)

IBM XL C/C++ Enterprise Edition V7.0 for AIX Runtime Environment Component [2]

Oracle Enterprise Manager 10g Grid Control Management Agent(10.2.0.3) クライアント

Red Hat Enterprise Linux Version4 Advanced Server Update4 Oracle Client 10g Release 2

Apache JMeter 2.2 監視サーバー

Red Hat Enterprise Linux Version4 Advanced Server Update4 Oracle Enterprise Manager 10g Grid Control (10.2.0.3) for Linux x86-64

2-2-1. Oracle Application Server 10g について

Oracle Application Server 10g は、オラクルが提供する J2EE アプリケーション・サーバー製品です。Oracle Application Server 10g は、J2EE を中心とした標準仕様に準拠しており、これによってアプリケーション開発者の確保も容易にし、将来的なシステムの拡張や改修のコスト削減を可能にします。

Oracle Application Server 10g は、Web サーバーである Oracle HTTP Server (以降、 OHS)、J2EE コンテナである Oracle Container for J2EE (以降、OC4J)、プロセス管理機能である Oracle Process Manager and Notification Service (以降、OPMN)から構成されます。OHS と OC4J はクラスタリングをサポート（Oracle Application Server Cluster と呼びます）することで冗長性を高め、スケールアウトによる拡張性を実現します。OHS から OC4J へのルーティングには全部で 8 つのロード・バランシング・ポリシーがあり、単純なラウンド・ロビン方式から、各サーバーの負荷状況からルーティング先を決定するメトリック方式等柔軟な設定が可能です。また

(9)

OPMN は、OHS と OC4J を監視し、障害発生時のプロセス自動再起動や他のクラスタノードへの自動通知機能を提供します。これによって、障害発生時にもクライアントからのリクエストは透過的にフェイルオーバーされ、アプリケーションの高い可用性が実現します。 OHS OHS 起動/停止/監視 Client HTTP(S) JDBC Database mod_plsql mod_plsql mod_php mod_php mod_oc4j mod_oc4j OC4J OC4J APPLICATION_B APPLICATION_B APPLICATION_A APPLICATION_A AJP opmn opmn

図２－１． Oracle Application Server 10g

Oracle Application Server 10g は Oracle Database 10g との高い親和性を持ちます。 Oracle GRID のインフラストラクチャは、Oracle Database のクラスタリング機能である Oracle Real Application Clusters 、 Oracle Application Server Cluster、統合されたシステムの管理・監視を実現する Oracle Enterprise Manager によって提供されます。

(10)

グリッド・コントロールグリッド・コントロールデータベース・グリッドデータベース・グリッドストレージ・グリッドストレージ・グリッドアプリケーションサーバ・アプリケーションサーバ・グリッドグリッド図２－２． Oracle GRID セッション・レプリケーションについて

セッション・レプリケーションは、Oracle Application Server 10g が提供する複数の OC4J 間でセッション情報の複製を可能にする機能です。Oracle Application Server 10g は、HttpSession オブジェクトおよび Stateful Session Bean のセッション・レプリケーションに対応します。Oracle Application Server Cluster でセッション・レプリケーションを有効することによって、クライアントからアプリケーション・サーバーへの接続だけでなく、例えば Web ショッピング・サイトにおけるショッピング・カート情報等、ユーザー固有のセッション情報の可用性を向上させることが可能です。 OHS OHS OC4J_B OC4J_B APP http://host:port/APP State State OC4J_A OC4J_A

APP StateState

mod_oc4j

(11)

図２－３．セッション・レプリケーション

Oracle Application Server 10g では、セッション・レプリケーションの動作を制御するためのパラメータ群が提供されており、アプリケーションの用件に応じた柔軟な設定が可能です。ここでは HttpSession オブジェクトのレプリケーションについて、主なパラメータを紹介します。

レプリケーション・プロトコル

セッション情報の通信方法を指定します。TCP 通信を行う Peer to Peer、UDP 通信を行う Multicast、Oracle Database にセッション情報を保持する Database があります。本検証では、Peer to Peer と Multicast の設定を使用しました。

レプリケーション・トリガー レプリケーションのタイミングを指定します。レプリケーションを属性設定時に実行する onSetAttribute、リクエスト終了時に実行する onRequestEnd、OC4J 停止時に実行する onShutdown の 3 種類があります。 レプリケーション・スコープ レプリケーション時に送信するセッション情報の範囲を指定します。変更された情報のみを送信する modifiedAttributes、全ての情報を送信する、allAttributes の 2 種類があります。 同期 / 非同期 レプリケーションの実行をアプリケーションの処理の流れに対して、同期で行うか、非同期で行うかを指定します。 Write-Quota レプリケーション時にセッション情報を送信する OC4J インスタンスの数を指定します。

2-2-2. Oracle Enterprise Manager 10g Grid Control について

Oracle Enterprise Manager 10g Grid Control（以降、Grid Control）は、オラクルのデータベース製品、ミドルウェア製品および業務アプリケーション製品を中心に、企業システム全体の運用管理、監視を一元的かつ効率よく行うためのツールです。 Grid Control を使用することによって、データベース、アプリケーション･サーバー

(12)

等、システムを構成する個々のコンポーネントを管理、監視するだけでなく、アプリケーション層からストレージ層までシステム全体を一元的に監視し、サービスレベルを管理することが可能になります。 CRM ERP Web SCM Site EMail Application Application Server Database Storage CRM ERP Web SCM Site EMail Application Application Server Database Storage

図２－４． Oracle Enterprise Manager 10g Grid Control

Grid Control は、管理、監視対象のコンポーネントに管理エージェントを配置することで、監視データの収集を行い、収集された監視データは Grid Control の管理リポジトリに格納されます。システム管理者には、Web ブラウザを使用したインターフェースが管理サービスとして提供され、監視データの参照と管理エージェントを介した対象コンポーネントの管理操作が可能です。管理コンソール AS DB Grid Control ホスト 管理エージェント管理リポジトリ _{管理エージェント} DB

・・

・

管理エージェント ターゲットホスト#1 管理サービス ターゲットホスト#2 管理情報の収集・格納管理操作の実行管理情報の参照

(13)

2-3. システム構成

今回使用したシステムの概要を図２－６に示します。アプリケーション・サーバー及びデータベース・サーバーは、p5-570 上に構成した 13 区画の LPAR に配置しています。アプリケーション・サーバーは 10 区画に配置されクラスタリングを構成しています。データベース・サーバーは 3 区画に配置され 3 ノードの Oracle Real Application Clusters を構成しています。アプリケーション・サーバーとクライアントマシン 8 台はギガビットのネットワークで構成されています。クライアントとの通信用の LAN 以外に、システム管理用のために HMC LAN が構成されています。本検証では、SMT 機能は有効にして測定を行っています。SMT が有効の場合、 OS で認識される CPU 数は割り当てられた物理 CPU 数の倍の数となりますが、以下 CPU 数という表記については、LPAR に割り当てられる物理 CPU の数という意味で記述します。アプリケーション・サーバー LPAR 構成 10 区画下記は 1 区画あたりのリソース配分です。 CPU 1 個(専有プロセッサー論理区画) SMT enabled メモリー3.5GB JVM ヒープサイズとして 2GB 割り当て 4 ポート・イーサーネット・アダプター × 1

en0 と en1 で Etherchannel Backup を en4 に構成し、クライアントとアプリケーション・サーバー間、およびアプリケーション・サーバーとデータベース・サーバー間の通信用のネットワークとして使用 en2 をセッション・レプリケーション通信の経路として使用 en3 を HMC 管理 LAN の経路として使用 73GB SCSI ディスク(OS ブート用) × 1 データベース・サーバー LPAR 構成 3 区画下記は 1 区画あたりのリソース配分です。 CPU 2 個(専有プロセッサー論理区画) SMT enabled メモリー7GB SGA には 4GB 割り当て

(14)

4 ポート・イーサーネット・アダプター × 1

en0 と en1 で Etherchannel を en4 に構成しアプリケーション・サーバーとデータベース・サーバー間の通信用のネットワークとして使用 en2 をインターコネクト用経路として使用 en3 を HMC 管理 LAN の経路として使用ファイバー・チャネル・アダプター × 1 73GB SCSI ディスク(OS ブート用) × 1 LPAR1 - 10 CPU : 1 Memory : 3.5GB 内蔵DISK :73.4GB HDD(OS) 4GbpsFibre x 1 4Port Gigabit Ether x 1 OS : AIX5L V5.3 TL05 Oracle Application Sever10g

HMC

SANスイッチ

IBM System Storage DS4800 2controller (4GB cache) DS4000 EXP810 拡張ユニット 146GB/15K x 38 PowerConnect 5324 x2台 (HMC LAN用) 監視サーバー Gigabit Ethernet Network

4Gigabit Fibre Channel

LPAR11 - 13 CPU : 2 Memory : 7GB

内蔵DISK :73.4GB HDD(OS)

4GbpsFibre x 1 4Port Gigabit Ether x 1 OS : AIX5L V5.3 TL05 Oracle Database10g IBM System p5 model 570

RAC Option IBM BladeCenterH PowerConnect 5324 x1台 (インターコネクト用) Catalyst 3750 Catalyst 3750 Catalyst 6504 図２－６．システム構成図データベース・サーバーから外部ストレージ装置(DS4800)へは、各区画からファイバーケーブル 1 本を SAN スイッチに接続しています。SAN スイッチ上では、サーバー側のポートと、ストレージの各コントローラへのパスとでそれぞれゾーニングを行っています。 EXP810 拡張ユニットに搭載されている 38 本の物理ドライブの内、4 本の物理ドライブを使用して、データファイル、制御ファイル、REDO、UNDO 用の領域とし、OS に認識された各論理ドライブを Oracle Database の自動ストレージ管理（Automatic Storage Management：ASM）のディスクグループとして設定しました。

● ● ● ● ● ● データベースサーバー区画アプリケーションサーバー区画 PowerConnect 5324 x2台 (Public用) LPAR1 - 10 CPU : 1 Memory : 3.5GB 内蔵DISK :73.4GB HDD(OS) 4GbpsFibre x 1 4Port Gigabit Ether x 1 OS : AIX5L V5.3 TL05 Oracle Application Sever10g

HMC

SANスイッチ

IBM System Storage DS4800 2controller (4GB cache) DS4000 EXP810 拡張ユニット 146GB/15K x 38 PowerConnect 5324 x2台 (HMC LAN用) 監視サーバー監視サーバー Gigabit Ethernet Network

Catalyst 6504

4Gigabit Fibre Channel

LPAR11 - 13 CPU : 2 Memory : 7GB

内蔵DISK :73.4GB HDD(OS)

4GbpsFibre x 1 4Port Gigabit Ether x 1 OS : AIX5L V5.3 TL05 Oracle Database10g IBM System p5 model 570

RAC Option Catalyst 3750 Catalyst 3750 IBM BladeCenterH PowerConnect 5324 x1台 (インターコネクト用) ● ● ● ● ● ● データベースサーバー区画アプリケーションサーバー区画 PowerConnect 5324 x2台 (Public用)

(15)

3. 検証内容

ここでは、今回行った検証内容について説明します。

3-1. 検証用アプリケーション

3-1-1. 使用アプリケーション

本検証では、検証用アプリケーションとして、JPetStore を使用しました。JPetStore は、J2EE アプリケーション・フレームワークである Spring Framework[3]のサンプルとして提供されているアプリケーションで、Web 上のペットショップを想定した設計がされています。

図３－１． JPetStore 画面イメージ

注意：画面イメージは、Spring Framework 1.2.8(http://www.springframework.org/) に付属するサンプルアプリケーションを使用しています。

ペットショップの商品情報、顧客のユーザー情報や注文情報等は、データベースに格納されているため、アプリケーション実行時にはデータベースへの参照や更新が発生します。また、商品情報、ユーザー情報、ユーザーのショッピング・

(16)

カート情報等は、アプリケーション実行時に HttpSession オブジェクトの属性として格納されるため、セッション・レプリケーションの対象となります。以上のことから、JPetStore は Oracle Application Server Cluster と Oracle Real Application Clusters から構成されるグリッド・コンピューティング技術基盤の性能や拡張性を測定するのに適したアプリケーションであるといえます。 3-1-2. データベース・スキーマ JPetStore で提供されているサンプル・スキーマ作成スクリプトを修正し、次のとおり、いくつかのテーブル・サイズを増加させています。表３－１．使用テーブルの概要（参照用）テーブル名件数サイズ概要 ACCOUNT 1,000,002 129MB アカウント表。ユーザー情報を格納。 SIGNON 1,000,002 28MB ユーザーID とパスワードを格納 PROFILE 1,000,002 37MB プロフィール表。ユーザーの設定情報を格納。 PRODUCT 160,000,016 15.3GB 商品表。商品 ID、商品名、概要等を格納。 ITEM 800,000,028 40.5GB 商品 ID に紐づいた項目で、注文で選択されるもの。アイテム ID 等を格納。 INVENTORY 800,000,028 18.1GB 在庫管理表。商品アイテム ID に紐づいて、それぞれのアイテムの在庫数を格納。それぞれのテーブルに作成された索引のサイズは以下のとおりです。表３－２．参照用テーブルの索引構成テーブル名索引名サイズ概要 ACCOUNT PK_ACCOUNT 36MB 主キー用索引 SIGNON PK_SIGNON 37MB 主キー用索引 PROFILE PK_PROFILE 38MB 主キー用索引 PK_PRODUCT 2.3GB 主キー用索引 PRODUCT_NAME 3.8GB 商品名(商品検索用) PRODUCT_DESCN 12GB 商品概要(商品検索用) PRODUCT PRODUCT_CATEGORY 2.3GB 商品カテゴリー(商品検索用) PK_ITEM 20.5GB 主キー用索引 ITEM ITEMPROD 19.3GB PRODUCTID 列 INVENTORY PK_INVENTORY 20.2GB 主キー用索引

(17)

トランザクションが発生すると、以下のテーブルに注文データが挿入されます。今回利用したアプリケーションは、トランザクションごとに、以下の表に示すテーブルにそれぞれデータを挿入します。表３－３．使用テーブルの概要（更新用）テーブル名概要 ORDERS 注文データの元表。注文 ID、注文者情報等を管理。 ORDERSTATUS 注文日時、注文状況を管理。 LINEITEM 注文数や注文単価を管理。 3-1-3. 処理手順 本検証では、負荷をかけるためのツールとして Apache JMeter（以降、JMeter）を使用しました。JMeter によって実行されるシナリオは以下のとおりです。 (1) ユーザー・サインオン任意のユーザーID をランダムに選択し、ユーザー情報を検索します。 OC4J 上では、ユーザー情報が HttpSession に保持されます。 (2) 商品検索ランダムに商品検索用のキーワードを生成し、平均で 10 件程度になるように商品を検索します。 OC4J 上では、検索結果が HttpSession に保持されます。 (3) 商品選択検索でヒットした商品の中から 1 つのアイテムを選択します。 OC4J 上では、アイテム情報が HttpSession に保持されます。 (4) ショッピング・カートに追加選択した商品を、ショッピング・カートに追加します。 OC4J 上では、商品カートが HttpSession に保持されます。上記、(2) から (4) までの操作を 1 から 5 までの数字からランダムに選択された回数だけ繰り返します。

(18)

(5) 注文ショッピング・カートに追加された商品の注文を確定します。 (6) ログアウトユーザーは、JPetStore からログアウトします。 OC4J 上では、全ての HttpSession が無効化されます。 JMeter は、HTTP リクエストごとにリクエスト完了時間と応答時間を記録します。本検証ではこれらの記録を集計し、上記 (1) から (6) まで操作をオペレーションの単位とし、スループットを計算しました。また、シナリオ実行中全ての HTTP リクエストの平均応答時間を計算し、性能の指標としています。

3-2. Oracle HTTP Server ロード・バランシン

グ・ポリシーの設定

本検証では、Oracle HTTP Server ロード・バランシング・ポリシーとして Round Robin with Local Affinity を設定しました。Round Robin with Local Affinity は OHS が実行されているホスト上の OC4J に優先してルーティングする設定です。今回の構成では、Oracle Application Server 各ノード上で OHS と OC4J の両方を起動しているため、OHS ― OC4J 間のネットワークの帯域を有効に活用できるというメリットがあります。

(19)

4. 検証結果

4-1. 検証 1 基礎性能検証

本検証では、アプリケーション・サーバー1 ノードあたりの基礎性能を測定することが目的です。アプリケーション・サーバーに対して、接続ユーザー数を増やして、その時のスループットと平均レスポンスタイムの推移を測定しました。図４－１に示すように、300 セッションを境に平均レスポンスタイムが急激に劣化していることから 300 セッションの負荷を与えた時点のアプリケーション・サーバーの性能を基礎値と定義しました。なお、図４－２に示すように、300 セッション時においてアプリケーション・サーバーの CPU 使用率は 60～70%を推移していました。 0 1 2 3 4 100 150 200 250 300 350 400 セッション数スループット比 0 1 2 3 4 5 6 7 8 9 平均レスポンスタイム比スループット比平均レスポンスタイム比図４－１．セッション数増加に伴う 1 ノードあたりの性能推移

(20)

0 20 40 60 80 100 0 120 240 360 480 600 720 時間(秒) C P U 負荷(%) 200セッション 300セッション 400セッション図４－２．1 ノードあたりの CPU 使用率

4-2. 検証 2 スケーラビリティ検証

本検証では、２－２－１節で述べたレプリケーション機能を使用しない状態で、クラスタリング構成のアプリケーション・サーバーにノードを追加したときのスケーラビリティを測定することが目的です。1 ノードあたりにかける負荷は、検証 ①で取得した基礎性能値である 300 セッションを使用しました。図４－３に示すように、アプリケーション・サーバーを 1 ノード構成から 10 ノードクラスター構成までのスループットと平均レスポンスタイムを測定しました。図中の値は 1 ノード時点のスループット値および平均レスポンスタイムを 1 とした場合の相対値です。結果として、図４－４に示すように 10 ノードクラスター時のスループット値が 9.83 倍を示し非常に高いスケーラビリティを得ることができました。平均レスポンスタイムはノードが追加されても安定的にほぼ一定の値をしましました。

(21)

0 1 2 3 4 5 6 7 8 9 10 11 1 2 4 6 8 10 ノード数スループット比 0 1 2 3 4 5 6 7 8 9 10 平均レスポンスタイム比スループット比平均レスポンスタイム比図４－３．ノード追加時のスループット比と平均レスポンスタイム比 0 2 4 6 8 10 12 0 2 4 6 8 10 12 ノード数スループット比性能スループット 1.00 1.96 3.93 5.90 7.87 9.83 図４－４．ノード追加時の性能スケーラビリティ

4-3. 検証 3 レプリケーション機能を使用し

たスケーラビリティ検証

本検証では、２－２－１節に記載したセッション・レプリケーション機能の各設定項目の組み合わせが性能にどのように影響するかを検証しました。以降の節では、レプリケーション・プロトコル／レプリケーション・トリガー／レプリケーション・スコープ／同期方式の各設定の違いに対する影響を個別に検証した結果を説明します。なお、図中に記載される各セッション・パラメータの略記を表４－１にもとづいて使用します。

(22)

表４－１．セッション・パラメータ名称と略記の対応表レプリケーション・プロトコルレプリケーション・トリガーレプリケーション・スコープ同期方式

名称(1) Multicast onRequestEnd nodifiedAttributes Async

略記(1) Mcast onReqEnd modAtt 非同期

名称(2) Peer to Peer onSetAttribute allAttributes Sync

略記(2) P2P onSetAtt allAtt 同期

名称(3) － onShutdown －－

略記(3) － onShut －－

4-3-1. レプリケーション・プロトコルの違いによる性能への影響

本検証では、レプリケーション・プロトコルとして、Peer to Peer と Multicast を使用した場合の性能への影響を検証しました。セッション数は基礎値である 300 を使用して負荷を与えました。結果としては、図４－５、図４－６に示すように、スループットおよび平均レスポンスタイムは、Mutlicast の性能が大きく劣化しました。Peer to Peer は 8 ノード以降においてレスポンスタイムが遅くなる傾向がありました。CPU 使用率は、図４－７に示すように、Mutlicast が 100%に達したため、スループットや平均レスポンスタイムの低下として表れました。なお、クラスターを構成する他のノードの CPU 使用率も同様の傾向となりました。また、図４－８に示すように、通信量も 4 倍近く多い結果となりました。この結果をうけて、レプリケーション・プロトコルは Peer to Peer が最適であると判断し、以降の検証では Peer to Peer を使用して検証を実施しました。

(23)

0.000 2.000 4.000 6.000 8.000 10.000 12.000 0 2 4 6 8 10 12 ノード数スループット比 Replicationなし Mcast/onReqEnd/modAtt/非同期 P2P/onReqEnd/modAtt/非同期図４－５．レプリケーション・プロトコルの違いによるスループットへの影響 0.000 2.000 4.000 6.000 8.000 10.000 12.000 14.000 16.000 18.000 20.000 0 2 4 6 8 10 12 ノード数平均レスポンスタイム比 Replicationなし Mcast/onReqEnd/modAtt/非同期 P2P/onReqEnd/modAtt/非同期図４－６．レプリケーション・プロトコルの違いによる平均レスポンスタイムへの影響

(24)

0 2000 4000 6000 8000 10000 12000 0 60 _{120 18}0 240 30 通信量( K B / s) 0 360 420 480 540 600 660 720 時間(秒) Mcast/onReqEnd/modAtt/非同期 P2P/onReqEnd/modAtt/非同期 0 20 40 60 80 100 0 120 240 360 480 600 720 時間(秒) CP U 使用率 (% ) Replicationなし Mcast/onReqEnd/modAtt/非同期 P2P/onReqEnd/modAtt/非同期図４－７．レプリケーション・プロトコルの違いによる CPU 使用率の違い (10 ノードクラスター構成時のあるノードの CPU 使用率) 図４－８．レプリケーション・プロトコルの違いによる通信量の違い(10 ノードクラスター構成時のあるノードの通信量) 4-3-2. レプリケーション・トリガーの違いによる性能への影響 本検証では、レプリケーション・トリガーとして、onRequestEnd / onSetAttribute / onShutdown を使用した場合の性能への影響を検証しました。結果としては、図４－９に示すように、スループットはほぼ同じ値となりました。図４－１０に示すように、平均レスポンスタイムは onShutdown、onRequestEnd、onSetAttribute の順番で速い結果となりましたが、onShutdown は JVM 正常終了時のみセッション情報が転送される方式であるため、本検証ではレプリケーション機能を使用しない場合の結果とほぼ同じになりました。CPU 使用率は onSetAttribute が最も高い結果となりました。これは、onSetAttribute が onRequestEnd に比べレプリケーションの実行回数が多いことに起因すると考えられ、通信量も onSetAttribute が onRequesEnd に比べ 500KB/s 程度多い結果となりました。onShutdown は JVM 正常終了時にレプリケーション通信を行うため、CPU 使用率への影響がないことがわかりました。なお、CPU 使用率は他のノードでも同様の傾向になりました。

(25)

0.000 2.000 4.000 6.000 8.000 10.000 12.000 0 2 4 6 8 10 12 ノード数スループット比 Replicationなし P2P/onReqEnd/modAtt/非同期 P2P/onSetAtt/modAtt/非同期 P2p/onShut/modAtt/非同期図４－９．レプリケーション・トリガーの違いによるスループットへの影響 0.000 1.000 2.000 3.000 4.000 5.000 6.000 7.000 8.000 9.000 10.000 0 2 4 6 8 10 12 ノード数平均レスポンスタイム比 Replicationなし P2P/onReqEnd/modAtt/非同期 P2P/onSetAtt/modAtt/非同期 P2p/onShut/modAtt/非同期図４－１０．レプリケーション・トリガーの違いによる平均レスポンスタイムへの影響

(26)

0 20 40 60 80 100 0 120 240 360 480 600 720 時間(秒) CP U 使用率(% ) Replicationなし P2P/onReqEnd/modAtt/非同期 P2P/onSetAtt/modAtt/非同期 P2P/onShut/modAtt/非同期 0 500 1000 1500 2000 2500 0 60 120 180 240 300360 420 480 540 600 660 720 780 840 900 時間(秒) 通信量( KB / s) P2P/onReqEnd/modAtt/非同期 P2P/onSetAtt/modAtt/非同期 P2P/onShut/modAtt/非同期図４－１１．10 ノードクラスター構成時の任意のノードの CPU 使用率図４－１２．レプリケーション・トリガーの違いによる通信量への影響 (10 ノードクラスター構成時のあるノードの通信量) 4-3-3. レプリケーション・スコープの違いによる性能の影響 本検証では、レプリケーション・スコープとして、modifiedAttributes と allAttributes を使用した場合の性能への影響を検証しました。スループットは、図４－１３に示すように、レプリケーション機能を使用しない場合と比べて、modifiedAttributes はほぼ同じ結果となりましたが、allAttributes は 10 ノード時において、10%のオーバーヘッドがありました。平均レスポンスタイムは、図４－１４に示すように、 modiffiedAttributes が allAttributes より速い結果となりました。CPU 使用率も図４－１５に示すように、modiffiedAttributes が allAttributes より 7%程度低い結果となりました。これは、modiffiedAttributes はセッション情報の更新分のみのデータ転送であるのに対して、allAttributes は OCJ4 が属性情報の全てを処理していることに起因していると考えられ、図４－１６に示すように、通信量も 5MB/s 程度多い結果となりました。なお、CPU 使用率は他のノードでも同様の傾向になりました。

(27)

0.000 2.000 4.000 6.000 8.000 10.000 12.000 0 2 4 6 8 10 12 ノード数スループット比 Replicationなし P2P/onReqEnd/modAtt/非同期 P2P/onReqEnd/allAtt/非同期図４－１３．レプリケーション・スコープの違いによるスループットへの影響 0.000 1.000 2.000 3.000 4.000 5.000 6.000 7.000 8.000 9.000 10.000 0 2 4 6 8 10 12 ノード数平均レスポンスタイム比 Replicationなし P2P/onReqEnd/modAtt/非同期 P2P/onReqEnd/allAtt/非同期図４－１４．レプリケーション・スコープの違いによる平均レスポンスタイムへの影響

(28)

0 1000 2000 3000 4000 5000 6000 7000 8000 0 ₄₅ ₉₀ 13 5 18 0 22 5 27 0 31 5 通信量( K B / s) 36 0 40 5 45 0 49 5 54 0 58 5 63 0 67 5 72 0 時間(秒) P2P/onReqEnd/modAtt/非同期 P2P/onReqEnd/allAtt/非同期 0 20 40 60 80 100 0 120 240 360 480 600 720 時間(秒) C P U 使用率( % ) Replicationなし P2P/onReqEnd/modAtt/非同期 P2P/onReqEnd/allAtt/非同期図４－１５．10 ノードクラスタ構成時における任意のノードの CPU 使用率図４－１６．レプリケーション・スコープの違いによる通信量への影響 4-3-4. 同期処理方式の違いによる性能への影響 本検証では、ノード間のレプリケーション処理を同期させるか非同期処理で行わせるかの違いが性能へどのように影響するかを検証しました。結果として、スループットは、図４－１７に示すように、同期処理した場合に低い結果となりました。特に onSetAttribute はアプリケーションのコーディング上、onRequestEnd に比べレプリケーション・トリガーが多いと考えられるため低下率が高くなっています。平均レスポンスタイムも図４－１８に示すように同様の理由で同期処理で低い結果となりました。同期処理では非同期処理に比べて応答時間が長くなる傾向を示し、測定ごとに値に波がある結果となりました。特に、レプリケーション・プロトコルとして onSetAttribute を使用し、かつ同期の場合に性能の劣化が顕著化しました。CPU 使用率は、図４－１９に示すように、onSetAttribute と onRequestEnd では、前者が上記と同じ理由により高い結果となりました。また、非同期に比べ同期が 3～5%程度高くなる傾向があり、これは同期処理では ACK のための通信などによるネットワーク通信量の増加に起因すると考えられます。

(29)

0.000 2.000 4.000 6.000 8.000 10.000 12.000 0 2 4 6 8 10 12 ノード数スループット比 Replicationなし P2P/onReqEnd/modAtt/非同期 P2P/onReqEnd/modAtt/同期 P2P/onSetAtt/modAtt/非同期 P2P/onSetAtt/modAtt/同期図４－１７．同期処理の違いによるスループットへの影響 0.000 5.000 10.000 15.000 20.000 25.000 30.000 0 2 4 6 8 10 12 ノード数平均レスポンスタイム比 Replicationなし P2P/onReqEnd/modAtt/非同期 P2P/onReqEnd/modAtt/同期 P2P/onSetAtt/modAtt/非同期 P2P/onSetAtt/modAtt/同期図４－１８．同期処理の違いによる平均レスポンスタイムへの影響

(30)

0 20 40 60 80 100 0 120 240 360 480 600 720 時間(秒) C P U 使用率( %) Replicationなし P2P/onSetAtt/modAtt/非同期 P2P/onSetAtt/modAtt/同期 0 20 40 60 80 100 0 120 240 360 480 600 720 時間(秒) C P U 使用率 (% ) Replicationなし P2P/onReqEnd/modAtt/非同期 P2P/onReqEnd/modAtt/同期図４－１９．10 ノードクラスター構成時における任意のノードの CPU 使用率 0 500 1000 1500 2000 2500 3000 0 ₄₅ ₉₀ 135 180 225 270 315 360 405 450 495 540 585 630 675 時間(秒) 通信量( KB / s) P2P/onReqEnd/modAtt/非同期 P2P/onReqEnd/modAtt/同期 P2P/onSetAtt/modAtt/非同期 P2P/onSetAtt/modAtt/同期図４－２０．同期処理の違いによる通信量への影響

(31)

4-3-5. Write Quota の違いによる性能への影響 本検証では、Write Quota を増やした場合にどのように性能に影響するかを検証しました。結果としては、スループットは、図４－２１に示すように、Quota が増えるに従い 1%程度の低い結果となりました。平均レスポンスタイムは、図４－２２に示すように、Quota が多いほど遅い結果となりました。またノード数が多いほど平均レスポンスタイムが遅くなりました。通信量は、図４－２４に示すように Write Quota を増やすとそれに比例して 2 倍、3 倍と増え、それに伴い CPU 使用率も図４－２３に示すように Quota 数が多いほど高い結果となりました。CPU 使用率は分かりやすくするため棒グラフにしています。なお、他のノードにおいても CPU 使用率は同様の傾向でした。 0.000 2.000 4.000 6.000 8.000 10.000 12.000 0 2 4 6 8 10 12 ノード数スループット比 Replicationなし P2P/onReqEnd/modAtt/非同期 P2P/onReqEnd/modAtt/非同期/Wq2 P2P/onReqEnd/modAtt/非同期/Wq3 P2P/onReqEnd/modAtt/非同期/Wq4 P2P/onReqEnd/modAtt/非同期/Wq5 図４－２１．Write Quota 数の違いによるスループットへの影響

(32)

0.000 1.000 2.000 3.000 4.000 5.000 6.000 7.000 8.000 9.000 10.000 0 2 4 6 8 10 12 ノード数平均レスポンスタイム比 Replicationなし P2P/onReqEnd/modAtt/非同期 P2P/onReqEnd/modAtt/非同期/Wq2 P2P/onReqEnd/modAtt/非同期/Wq3 P2P/onReqEnd/modAtt/非同期/Wq4 P2P/onReqEnd/modAtt/非同期/Wq5 図４－２２．Write Quota 数の違いによる平均レスポンスタイムへの影響 50 55 60 65 70 75 80 85 90 95 100 平均 CP U 使用率( % ) P2P/onReqEnd/modAtt/非同期 P2P/onReqEnd/modAtt/非同期/Wq2 P2P/onReqEnd/modAtt/非同期/Wq3 P2P/onReqEnd/modAtt/非同期/Wq4 P2P/onReqEnd/modAtt/非同期/Wq5 0 1000 2000 3000 4000 5000 6000 7000 8000 0 75 150 225 300 375 450 525 600 675 時間(秒) 通信量( K B / s) P2P/ReqEnd/modAtt/非同期 P2P/onReqEnd/modAtt/非同期/wq2 P2P/onReqEnd/modAtt/非同期/wq3 P2P/onReqEnd/modAtt/非同期/wq4 P2P/onReqEnd/modAtt/非同期/wq5 図４－２３．10 ノードクラスター構成時の任意のノードの CPU 使用率図４－２４．Write Quota の違いによる通信量への影響

(33)

4-4. 検証 4 その他の検証

4-4-1. サービスネットワークの兼用と Virtual Ethernet の活用 前節までの検証は、レプリケーション通信のために、専用の物理イーサーネット・カードを用意して実施しています。本検証では、レプリケーション通信のためのネットワークをクライアントからアプリケーション・サーバーへのアクセスおよびアプリケーション・サーバーからデータベース・サーバーへのアクセスのためのネットワーク(以降、サービスネットワーク)と兼用した場合の性能への影響と、レプリケーション通信のために Virtual Ethernet を活用した場合の影響について検証しました。レプリケーション・プロトコルやレプリケーション・トリガー、レプリケーション・スコープ、同期方式では前節までの検証結果から推奨される、 Peer to Peer、onRequestEnd、modifiedAttribute、非同期を使用しました。結果としては、スループットと平均レスポンスタイムと CPU 使用率はほぼ同じ結果となりました（図４－２５、図４－２６、図４－２７）。通信量では図４－２８に示すようにサービスネットワークを兼用した場合の通信量が、専用のインターコネクトの経路を設けた場合のインターコネクト通信量とサービスネットワークの通信量の総和に等しい結果となりました。

また、インターコネクトとして Virtual Ethernet を使用した場合も、Virtual Ethernet 通信量とサービスネットワークの通信量の総和に等しい結果となりました。結論としては、現行のネットワーク環境においてサービスネットワークをレプリケーション用の経路として兼用してもほぼ性能に差はないといえます。Virtual Ethernet の場合も 1.5MB/s 程度の通信量では同様の性能となりました。これにより、前述の環境においては、レプリケーション用の経路としてサービスネットワークを兼用しインターコネクト用のアダプターコストを削減することができますが、アプリケーション・サーバーとデータベース・サーバー間とインターコネクトを明示的に分けたい場合でも Virtual Ethernet を定義することによりアダプターのコストを削減することができます。なお、Virtual Ethernet を新たに定義することに対してシステム停止は必要ありません。

(34)

0.000 2.000 4.000 6.000 8.000 10.000 12.000 0 2 4 6 8 10 12 ノード数スループット比 Replicationなし P2P/onReqEnd/modAtt/非同期/専有 P2P/onReqEnd/modAtt/非同期/サービス兼用 P2P/onReqEnd/modAtt/非同期/Virtual

図４－２５．サービス LAN 兼用と Virtual Ethernet でのスフープットの違い

0.000 1.000 2.000 3.000 4.000 5.000 6.000 7.000 8.000 9.000 10.000 0 2 4 6 8 10 12 ノード数レスポンスタイム比 Replicationなし P2P/onReqEnd/modAtt/非同期/専有 P2P/onReqEnd/modAtt/非同期/サービス兼用 P2P/onReqEnd/modAtt/非同期/Virtual

(35)

0 1000 2000 3000 4000 5000 6000 0 ₄₅ ₉₀ 13 5 18 0 22 5 27 0 31 5 時間( 通信量( KB / s) 36 0 40 5 45 0 49 5 54 0 58 5 63 0 67 5 72 0 秒) P2P/onReqEnd/modAtt/非同期/サービス兼用 0 10 20 30 40 50 60 70 80 90 100 0 120 240 360 480 600 720 840 時間(秒) CPU 使用率 (% ) Replicationなし P2P/onReqEnd/modAtt/非同期/専用 P2P/onReqEnd/modAtt/非同期/サービス兼用 P2P/onReqEnd/modAtt/非同期/Virtual P2P/onReqEnd/modAtt/非同期/専有 P2P/onReqEnd/modAtt/非同期/サービスのみ P2P/onReqEnd/modAtt/非同期/Virtual(専有) P2P/onReqEnd/modAtt/非同期/Virtual(サービスのみ）図４－２７．サービス LAN 兼用と Virtual Ethernet でのアプリケーション・サーバー負荷の違い図４－２８．サービス LAN 兼用と Virtual Ethernet での通信量の違い 4-4-2. Grid Control の管理エージェント動作時の負荷

本検証では、Oracle Application Server 10g が稼動するノードに管理エージェントを導入し稼動させた場合に性能にどのように影響があるかを検証しました。アプリケーション・サーバー10 ノードのそれぞれのノードで管理エージェントを稼動させました。結果としては、図４－３１に示すように、管理エージェント稼動時と停止時で合計スループットの差は 0.7%でした。管理エージェントを稼動させた場合、各ノードにおいて CPU 使用率の平均が 2%程度上昇しましたが、管理エージェントを稼動させることによる影響はないと言えます。 0 0.2 0.4 0.6 0.8 1 1.2 スループット比停止時稼動時図４－３１．管理エージェント稼動/停止によるスループットへの影響

(36)

5. まとめ

Oracle Application Server 10g のレプリケーション機能における設定（レプリケーション・プロトコル、レプリケーション・トリガー、レプリケーション・スコープ、同期方式、Write Quota）の影響を検証し、適切なパラメータの組み合わせを提言しました。今回の検証ではレプリケーション設定時の CPU 使用率は 90％前後の高負荷状態となっており、この状態において平均レスポンスタイムが若干劣化するものの、10 ノードまでほぼリニアにスケールすることが確認できました。このようにレプリケーション機能を使用し可用性を維持したまま Oracle Application Server 10g が System p 上で稼動することが確認できました。また、 System p のプラットフォームで Oracle Application Server 10g を稼働させる利点をスケーラビリティや Virtual Ethernet の活用で明らかにしました。さらに、グリッド・コンピューティング環境を管理する Oracle Enterprise Manager 10g を考慮した環境においても性能の劣化なく稼働することを確認しました。

(37)

6. 参考 URL

[1] p5 テクノロジー

http://www-06.ibm.com/jp/servers/eserver/pseries/technology/

[2] IBM XL C/C++ Enterprise Edition V7.0 for AIX Runtime Environment Component http://www-1.ibm.com/support/docview.wss?uid=swg24009788

[3]Spring Framework

(38)

日本オラクル株式会社

この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。

Oracle、JD Edwards、PeopleSoft、及び Siebel は、米国オラクル・コーポレーション及びその子会社、関連会社の登録商標です。その他の名称は、各社の商標または登録商標です。

文中に参照されている各製品名及びサービス名は米国 Oracle Corporation の商標または登録商標です。その他の製品名及びサービス名はそれぞれの所有者の商標または登録商標の可能性があります。

IBM System p 上での Oracle Application Server 10g 性能検証