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

Transcription

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

2 はじめに 多様化 高度化するアプリケーションの機能と性能を実現する一方で それらに必要かつ十分な資源を適時に充当し さらにシステムとしての信頼性を維持するという複合的な要件が 現在多くの IT インフラに求められています また従来 CPU 資源の利用と言う範疇でのみ使用されていた グリッド コンピューティング という概念とその手法も この分野へパラダイムをシフトしつつあると言えます 先進的な仮想化技術を実装し 市場においても継続して評価を得ている IBM System p は高い蓋然性を持って このグリッド コンピューティングのための最適プラットフォームであると考えることができます 今回の検証では 特に性能と多ノード構成による拡張性 ( スケールアウト ) を実現するために System p とその主要な OS である IBM AIX5L の下に Oracle Fusion Middleware の主幹をなす Oracle Application Server 1g と 高性能かつ高可用性を実現するデータベース Oracle Real Application Clusters 1g を構成しました この環境で現実に近いアプリケーション稼働させた場合の性能を様々な局面で測定し システム全体としての拡張性を実証することを目標としました 実際の構成としては CPU16 個を有する IBM System p5 57 を複数の LPAR に分割した上で Oracle Application Server 1g と Oracle Real Application Clusters 1g それぞれのノードに割り当てることによってグリッド コンピューティング環境を構築しています このシステム上で Oracle Application Server 1g ノードを 1 から順に増加させながら それぞれの時点でのアプリケーションの性能を測定し 各ノード構成での測定結果を比較 グラフ化の上で拡張性に関する考察を加えました 次の段階として Oracle Application Server 1g が提供するセッション情報のバックアップ機能であるセッション レプリケーションを設定した上で各ノード構成での性能測定を行い 性能 スケーラビリティと信頼性の両立に関する検証を実施しています さらに 発展段階として IBM System p の仮想化技術の1つである Virtual Ethernet の性能測定や Oracle Enterprise Manager 1g でグリッド コンピューティング環境を監視した際のアプリケーションの性能への影響を検証しました 2

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

4 目次はじめに...2 謝辞...3 目次 実施要項 検証環境 ハードウェア 使用ハードウェア IBM System pのハードウェア機能 ソフトウェア Oracle Application Server 1g について Oracle Enterprise Manager 1g Grid Controlについて システム構成 検証内容 検証用アプリケーション 使用アプリケーション データベース スキーマ 処理手順 Oracle HTTP Server ロード バランシング ポリシーの設定 検証結果 検証 1 基礎性能検証 検証 2 スケーラビリティ検証 検証 3 レプリケーション機能を使用したスケーラビリティ検証 レプリケーション プロトコルの違いによる性能への影響 レプリケーション トリガーの違いによる性能への影響 レプリケーション スコープの違いによる性能の影響 同期処理方式の違いによる性能への影響 Write Quotaの違いによる性能への影響 検証 4 その他の検証 サービスネットワークの兼用とVirtual Ethernetの活用 Grid Control の管理エージェント動作時の負荷 まとめ 参考 URL

5 1. 実施要項 規模 : 4 名 場所 : 日本オラクル株式会社 Oracle GRID Center 日本オラクル株式会社 ( データベースソフトウェアおよびミドルウェアの提供 ) 日本アイ ビー エム株式会社 ( ハードウェア及び OS 環境の提供 ) 2. 検証環境 2-1. ハードウェア 使用ハードウェア 今回の検証で使用したハードウェアは以下のとおりです データベース サーバー IBM System p5 モデル 57 ( 以下 p5-57) CPU :POWER5+ 2.2GHz 16Way メモリー :64GB アダプター : 4 ポート 1/1/1Base イーサーネット アダプター 16 枚 4 ギガビット ファイバー チャネル アダプター 3 枚 高速 73.4GB ULTRA32 SCSI ディスク ドライブ 16 ドライブ ストレージ コントローラ :IBM System Storage DS48 ( A) 拡張筐体 :DS4 EXP81 ストレージ拡張ユニット ( A) 146.8GB/15K 4Gbps FC ドライブ 4ドライブ SAN スイッチ IBM TotalStorage SAN16B-2 2 台 クライアントマシン IBM BladeCenterH HS21 8 個 CPU :Intel Xeon dualcore 3GHz 5

6 メモリー :4GB アダプター : デュアル ギガビット イーサーネット ネットワークスイッチ Dell PowerConnect 台 Cisco Catalyst 台 Cisco Catalyst 台 その他機器 Hardware Management Console :p5-57 ハードウェア管理端末 ( 以下 HMC) 監視サーバー CPU : Intel Pentium-D 3GHz 1Way メモリー : 2GB 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 で最大 1 個の LPAR を動作させることが可能です 6

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 つのスレッドが命令を実行中に その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 間におけるメモリー転送であるため データ転送は高速になります ただし 転送にプロセッサーが関与するため どちらが高速であるかは個別の状況により異なります 7

8 2-2. ソフトウェア今回の検証で使用したソフトウェアは以下のとおりです アプリケーション サーバー AIX5L V5.3 Technical Level5 Service Pack 6 Oracle Application Server 1g Release 3 ( ) Oracle Enterprise Manager 1g Grid Control Management Agent(1.2..3) データベース サーバー AIX5L V5.3 Technical Level5 Service Pack 6 Oracle Database 1g Release2 (1.2..3) Oracle Clusterware 1g Release2(1.2..3) IBM XL C/C++ Enterprise Edition V7. for AIX Runtime Environment Component [2] Oracle Enterprise Manager 1g Grid Control Management Agent(1.2..3) クライアント Red Hat Enterprise Linux Version4 Advanced Server Update4 Oracle Client 1g Release 2 Apache JMeter 2.2 監視サーバー Red Hat Enterprise Linux Version4 Advanced Server Update4 Oracle Enterprise Manager 1g Grid Control (1.2..3) for Linux x Oracle Application Server 1g について Oracle Application Server 1g は オラクルが提供する J2EE アプリケーション サーバー製品です Oracle Application Server 1g は J2EE を中心とした標準仕様に準拠しており これによってアプリケーション開発者の確保も容易にし 将来的なシステムの拡張や改修のコスト削減を可能にします Oracle Application Server 1g は 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 つのロード バランシング ポリシーがあり 単純なラウンド ロビン方式から 各サーバーの負荷状況からルーティング先を決定するメトリック方式等柔軟な設定が可能です また 8

9 OPMN は OHS と OC4J を監視し 障害発生時のプロセス自動再起動や他のクラスタノードへの自動通知機能を提供します これによって 障害発生時にもクライアントからのリクエストは透過的にフェイルオーバーされ アプリケーションの高い可用性が実現します OHS OC4J Client HTTP(S) mod_oc4j mod_php mod_plsql AJP APPLICATION_A APPLICATION_B JDBC Database opmn 起動 / 停止 / 監視 図 2-1. Oracle Application Server 1g Oracle Application Server 1g は Oracle Database 1g との高い親和性を持ちます Oracle GRID のインフラストラクチャは Oracle Database のクラスタリング機能である Oracle Real Application Clusters Oracle Application Server Cluster 統合されたシステムの管理 監視を実現する Oracle Enterprise Manager によって提供されます 9

10 グリッド コントロール アプリケーションサーバ グリッド データベース グリッド 図 2-2. Oracle GRID ストレージ グリッド セッション レプリケーションについてセッション レプリケーションは Oracle Application Server 1g が提供する複数の OC4J 間でセッション情報の複製を可能にする機能です Oracle Application Server 1g は HttpSession オブジェクトおよび Stateful Session Bean のセッション レプリケーションに対応します Oracle Application Server Cluster でセッション レプリケーションを有効することによって クライアントからアプリケーション サーバーへの接続だけでなく 例えば Web ショッピング サイトにおけるショッピング カート情報等 ユーザー固有のセッション情報の可用性を向上させることが可能です OHS OC4J_A mod_oc4j APP State OC4J_B APP State 1

11 図 2-3. セッション レプリケーション Oracle Application Server 1g では セッション レプリケーションの動作を制御するためのパラメータ群が提供されており アプリケーションの用件に応じた柔軟な設定が可能です ここでは 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 インスタンスの数を指定します Oracle Enterprise Manager 1g Grid Control について Oracle Enterprise Manager 1g Grid Control( 以降 Grid Control) は オラクルのデータベース製品 ミドルウェア製品および業務アプリケーション製品を中心に 企業システム全体の運用管理 監視を一元的かつ効率よく行うためのツールです Grid Control を使用することによって データベース アプリケーション サーバー 11

12 等 システムを構成する個々のコンポーネントを管理 監視するだけでなく アプリケーション層からストレージ層までシステム全体を一元的に監視し サービスレベルを管理することが可能になります CRM ERP Web SCM Site Application Application Server Database 図 2-4. Oracle Enterprise Manager 1g Grid Control Storage Grid Control は 管理 監視対象のコンポーネントに管理エージェントを配置することで 監視データの収集を行い 収集された監視データは Grid Control の管理リポジトリに格納されます システム管理者には Web ブラウザを使用したインターフェースが管理サービスとして提供され 監視データの参照と管理エージェントを介した対象コンポーネントの管理操作が可能です Grid Control ホスト 管理サービス ターゲットホスト #1 管理エージェント AS 管理情報の収集 格納 管理操作の実行 管理リポジトリ 管理エージェント DB 管理情報の参照 管理コンソール ターゲットホスト #2 DB 管理エージェント 図 2-5. Oracle Enterprise Manager Grid Control による管理 12

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

14 4 ポート イーサーネット アダプター 1 en と en1 で Etherchannel を en4 に構成しアプリケーション サーバーとデータベース サーバー間の通信用のネットワークとして使用 en2 をインターコネクト用経路として使用 en3 を HMC 管理 LAN の経路として使用 ファイバー チャネル アダプター 1 73GB SCSI ディスク (OS ブート用 ) 1 Gigabit Ethernet Network Catalyst 654 監視サーバー IBM System p5 model 57 Catalyst 375 Catalyst 375 アプリケーションサーバー区画 LPAR1-1 CPU : 1 Memory : 3.5GB 内蔵 DISK :73.4GB HDD(OS) 4GbpsFibre x 1 4Port Gigabit Ether x 1 OS : AIX5L V5.3 TL5 Oracle Application Sever1g PowerConnect 5324 x2 台 (Public 用 ) PowerConnect 5324 x2 台 (HMC LAN 用 ) PowerConnect 5324 x1 台 ( インターコネクト用 ) HMC IBM BladeCenterH データベースサーバー区画 LPAR11-13 CPU : 2 Memory : 7GB 内蔵 DISK :73.4GB HDD(OS) 4GbpsFibre x 1 4Port Gigabit Ether x 1 OS : AIX5L V5.3 TL5 Oracle Database1g RAC Option 4Gigabit Fibre Channel SAN スイッチ IBM System Storage DS48 2controller (4GB cache) DS4 EXP81 拡張ユニット 146GB/15K x 38 図 2-6. システム構成図 データベース サーバーから外部ストレージ装置 (DS48) へは 各区画からファイバーケーブル 1 本を SAN スイッチに接続しています SAN スイッチ上では サーバー側のポートと ストレージの各コントローラへのパスとでそれぞれゾーニングを行っています EXP81 拡張ユニットに搭載されている 38 本の物理ドライブの内 4 本の物理ドライブを使用して データファイル 制御ファイル REDO UNDO 用の領域とし OS に認識された各論理ドライブを Oracle Database の自動ストレージ管理 (Automatic Storage Management:ASM) のディスクグループとして設定しました 14

15 3. 検証内容 ここでは 今回行った検証内容について説明します 3-1. 検証用アプリケーション 使用アプリケーション本検証では 検証用アプリケーションとして JPetStore を使用しました JPetStore は J2EE アプリケーション フレームワークである Spring Framework[3] のサンプルとして提供されているアプリケーションで Web 上のペットショップを想定した設計がされています 図 3-1. JPetStore 画面イメージ 注意 : 画面イメージは Spring Framework 1.2.8( に付属するサンプルアプリケーションを使用しています ペットショップの商品情報 顧客のユーザー情報や注文情報等は データベー スに格納されているため アプリケーション実行時にはデータベースへの参照や更新が発生します また 商品情報 ユーザー情報 ユーザーのショッピング 15

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

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

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 間のネットワークの帯域を有効に活用できるというメリットがあります 18

19 4. 検証結果 4-1. 検証 1 基礎性能検証本検証では アプリケーション サーバー 1 ノードあたりの基礎性能を測定することが目的です アプリケーション サーバーに対して 接続ユーザー数を増やして その時のスループットと平均レスポンスタイムの推移を測定しました 図 4-1に示すように 3 セッションを境に平均レスポンスタイムが急激に劣化していることから 3 セッションの負荷を与えた時点のアプリケーション サーバーの性能を基礎値と定義しました なお 図 4-2に示すように 3 セッション時においてアプリケーション サーバーの CPU 使用率は 6~7% を推移していました スループット比 スループット比 平均レスポンスタイム比 セッション数 平均レスポンスタイム比 図 4-1. セッション数増加に伴う 1 ノードあたりの性能推移 19

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

21 スループット比 スループット比平均レスポンスタイム比 ノード数 平均レスポンスタイム比 図 4-3. ノード追加時のスループット比と平均レスポンスタイム比 12 1 性能スループット スループット比 ノード数 図 4-4. ノード追加時の性能スケーラビリティ 4-3. 検証 3 レプリケーション機能を使用したスケーラビリティ検証本検証では 節に記載したセッション レプリケーション機能の各設定項目の組み合わせが性能にどのように影響するかを検証しました 以降の節では レプリケーション プロトコル / レプリケーション トリガー / レプリケーション スコープ / 同期方式の各設定の違いに対する影響を個別に検証した結果を説明します なお 図中に記載される各セッション パラメータの略記を表 4-1にもとづいて使用します 21

22 表 4-1. セッション パラメータ名称と略記の対応表 レプリケーション プロトコル レプリケーション トリガー レプリケーション スコープ 同期方式 名称 (1) Multicast onrequestend nodifiedattributes Async 略記 (1) Mcast onreqend modatt 非同期 名称 (2) Peer to Peer onsetattribute allattributes Sync 略記 (2) P2P onsetatt allatt 同期 名称 (3) - onshutdown - - 略記 (3) - onshut レプリケーション プロトコルの違いによる性能への影響本検証では レプリケーション プロトコルとして Peer to Peer と Multicast を使用した場合の性能への影響を検証しました セッション数は基礎値である 3 を使用して負荷を与えました 結果としては 図 4-5 図 4-6に示すように スループットおよび平均レスポンスタイムは Mutlicast の性能が大きく劣化しました Peer to Peer は 8 ノード以降においてレスポンスタイムが遅くなる傾向がありました CPU 使用率は 図 4-7に示すように Mutlicast が 1% に達したため スループットや平均レスポンスタイムの低下として表れました なお クラスターを構成する他のノードの CPU 使用率も同様の傾向となりました また 図 4-8に示すように 通信量も 4 倍近く多い結果となりました この結果をうけて レプリケーション プロトコルは Peer to Peer が最適であると判断し 以降の検証では Peer to Peer を使用して検証を実施しました 22

23 12. Replication なし Mcast/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/modAtt/ 非同期 スループット比 ノード数 図 4-5. レプリケーション プロトコルの違いによるスループットへの影響 Replication なし Mcast/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/modAtt/ 非同期 平均レスポンスタイム比 ノード数 図 4-6. レプリケーション プロトコルの違いによる平均レスポンスタイムへの影響 23

24 CPU 使用率 (%) Replicationなし Mcast/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/modAtt/ 非同期 時間 ( 秒 ) 通信量 (KB/s) Mcast/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/modAtt/ 非同期 3642 時間 ( 秒 ) 図 4-7. レプリケーション プロトコ ルの違いによる CPU 使用率の違い (1 ノ ードクラスター構成時のあるノードの CPU 図 4-8. レプリケーション プロトコルの違いによる通信量の違い (1 ノードクラスター構成時のあるノードの通信量 ) 使用率 ) レプリケーション トリガーの違いによる性能への影響本検証では レプリケーション トリガーとして onrequestend / onsetattribute / onshutdown を使用した場合の性能への影響を検証しました 結果としては 図 4-9に示すように スループットはほぼ同じ値となりました 図 4-1に示すように 平均レスポンスタイムは onshutdown onrequestend onsetattribute の順番で速い結果となりましたが onshutdown は JVM 正常終了時のみセッション情報が転送される方式であるため 本検証ではレプリケーション機能を使用しない場合の結果とほぼ同じになりました CPU 使用率は onsetattribute が最も高い結果となりました これは onsetattribute が onrequestend に比べレプリケーションの実行回数が多いことに起因すると考えられ 通信量も onsetattribute が onrequesend に比べ 5KB/s 程度多い結果となりました onshutdown は JVM 正常終了時にレプリケーション通信を行うため CPU 使用率への影響がないことがわかりました なお CPU 使用率は他のノードでも同様の傾向になりました 24

25 12. Replication なし P2P/onReqEnd/modAtt/ 非同期 P2P/onSetAtt/modAtt/ 非同期 P2p/onShut/modAtt/ 非同期 スループット比 ノード数 図 4-9. レプリケーション トリガーの違いによるスループットへの影響 平均レスポンスタイム比 Replication なし P2P/onReqEnd/modAtt/ 非同期 P2P/onSetAtt/modAtt/ 非同期 P2p/onShut/modAtt/ 非同期 ノード数 図 4-1. レプリケーション トリガーの違いによる平均レスポンスタイムへの影響 25

26 CPU 使用率 (%) Replication なし P2P/onReqEnd/modAtt/ 非同期 P2P/onSetAtt/modAtt/ 非同期 P2P/onShut/modAtt/ 非同期 時間 ( 秒 ) 図 ノードクラスター構成時 の任意のノードの CPU 使用率 通信量 (KB/s) P2P/onReqEnd/modAtt/ 非同期 P2P/onSetAtt/modAtt/ 非同期 P2P/onShut/modAtt/ 非同期 時間 ( 秒 ) 図 レプリケーション トリガーの違いによる通信量への影響 (1 ノードクラスター構成時のあるノードの通信量 ) レプリケーション スコープの違いによる性能の影響本検証では レプリケーション スコープとして modifiedattributesと allattributes を使用した場合の性能への影響を検証しました スループットは 図 4-13に示すように レプリケーション機能を使用しない場合と比べて modifiedattributes はほぼ同じ結果となりましたが allattributes は 1 ノード時において 1% のオーバーヘッドがありました 平均レスポンスタイムは 図 4-14に示すように modiffiedattributes が allattributes より速い結果となりました CPU 使用率も図 4-15に示すように modiffiedattributes が allattributes より 7% 程度低い結果となりました これは modiffiedattributes はセッション情報の更新分のみのデータ転送であるのに対して allattributes は OCJ4 が属性情報の全てを処理していることに起因していると考えられ 図 4-16に示すように 通信量も 5MB/s 程度多い結果となりました なお CPU 使用率は他のノードでも同様の傾向になりました 26

27 Replication なし P2P/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/allAtt/ 非同期 8. スループット比 ノード数 図 レプリケーション スコープの違いによるスループットへの影響 Replication なし P2P/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/allAtt/ 非同期 平均レスポンスタイム比 ノード数 図 レプリケーション スコープの違いによる平均レスポンスタイムへの影響 27

28 CPU 使用率 (%) Replication なし P2P/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/allAtt/ 非同期 時間 ( 秒 ) 通信量 (KB/s) 時間 ( 秒 ) P2P/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/allAtt/ 非同期 図 ノードクラスタ構成時に おける任意のノードの CPU 使用率 図 レプリケーション スコー プの違いによる通信量への影響 同期処理方式の違いによる性能への影響本検証では ノード間のレプリケーション処理を同期させるか非同期処理で行わせるかの違いが性能へどのように影響するかを検証しました 結果として スループットは 図 4-17に示すように 同期処理した場合に低い結果となりました 特に onsetattribute はアプリケーションのコーディング上 onrequestend に比べレプリケーション トリガーが多いと考えられるため低下率が高くなっています 平均レスポンスタイムも図 4-18に示すように同様の理由で同期処理で低い結果となりました 同期処理では非同期処理に比べて応答時間が長くなる傾向を示し 測定ごとに値に波がある結果となりました 特に レプリケーション プロトコルとして onsetattribute を使用し かつ同期の場合に性能の劣化が顕著化しました CPU 使用率は 図 4-19に示すように onsetattribute と onrequestend では 前者が上記と同じ理由により高い結果となりました また 非同期に比べ同期が 3~5% 程度高くなる傾向があり これは同期処理では ACK のための通信などによるネットワーク通信量の増加に起因すると考えられます 28

29 Replication なし P2P/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/modAtt/ 同期 P2P/onSetAtt/modAtt/ 非同期 P2P/onSetAtt/modAtt/ 同期 8. スループット比 ノード数 図 同期処理の違いによるスループットへの影響 Replication なし P2P/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/modAtt/ 同期 P2P/onSetAtt/modAtt/ 非同期 P2P/onSetAtt/modAtt/ 同期 平均レスポンスタイム比 ノード数 図 同期処理の違いによる平均レスポンスタイムへの影響 29

30 CPU 使用率 (%) Replicationなし P2P/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/modAtt/ 同期 時間 ( 秒 ) CPU 使用率 (%) Replication なし P2P/onSetAtt/modAtt/ 非同期 P2P/onSetAtt/modAtt/ 同期 時間 ( 秒 ) 図 ノードクラスター構成時における任意のノードの CPU 使用率 3 25 通信量 (KB/s) P2P/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/modAtt/ 同期 P2P/onSetAtt/modAtt/ 非同期 P2P/onSetAtt/modAtt/ 同期 時間 ( 秒 ) 675 図 4-2. 同期処理の違いによる通信量への影響 3

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

32 平均レスポンスタイム比 Replication なし P2P/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/modAtt/ 非同期 /Wq2 P2P/onReqEnd/modAtt/ 非同期 /Wq3 P2P/onReqEnd/modAtt/ 非同期 /Wq4 P2P/onReqEnd/modAtt/ 非同期 /Wq ノード数 図 4-22.Write Quota 数の違いによる平均レスポンスタイムへの影響 平均 CPU 使用率 (%) P2P/onReqEnd/modAtt/ 非同期 P2P/onReqEnd/modAtt/ 非同期 /Wq2 P2P/onReqEnd/modAtt/ 非同期 /Wq3 P2P/onReqEnd/modAtt/ 非同期 /Wq4 P2P/onReqEnd/modAtt/ 非同期 /Wq5 通信量 (KB/s) P2P/ReqEnd/modAtt/ 非同期 P2P/onReqEnd/modAtt/ 非同期 /wq2 P2P/onReqEnd/modAtt/ 非同期 /wq3 P2P/onReqEnd/modAtt/ 非同期 /wq4 P2P/onReqEnd/modAtt/ 非同期 /wq 時間 ( 秒 ) 図 ノードクラスター構成時 の任意のノードの CPU 使用率 図 4-24.Write Quota の違いによる通 信量への影響 32

33 4-4. 検証 4 その他の検証 サービスネットワークの兼用と Virtual Ethernet の活用前節までの検証は レプリケーション通信のために 専用の物理イーサーネット カードを用意して実施しています 本検証では レプリケーション通信のためのネットワークをクライアントからアプリケーション サーバーへのアクセスおよびアプリケーション サーバーからデータベース サーバーへのアクセスのためのネットワーク ( 以降 サービスネットワーク ) と兼用した場合の性能への影響と レプリケーション通信のために Virtual Ethernet を活用した場合の影響について検証しました レプリケーション プロトコルやレプリケーション トリガー レプリケーション スコープ 同期方式では前節までの検証結果から推奨される Peer to Peer onrequestend modifiedattribute 非同期を使用しました 結果としては スループットと平均レスポンスタイムと CPU 使用率はほぼ同じ結果となりました ( 図 4-25 図 4-26 図 4-27) 通信量では図 4-2 8に示すようにサービスネットワークを兼用した場合の通信量が 専用のインターコネクトの経路を設けた場合のインターコネクト通信量とサービスネットワークの通信量の総和に等しい結果となりました また インターコネクトとして Virtual Ethernet を使用した場合も Virtual Ethernet 通信量とサービスネットワークの通信量の総和に等しい結果となりました 結論としては 現行のネットワーク環境においてサービスネットワークをレプリケーション用の経路として兼用してもほぼ性能に差はないといえます Virtual Ethernet の場合も 1.5MB/s 程度の通信量では同様の性能となりました これにより 前述の環境においては レプリケーション用の経路としてサービスネットワークを兼用しインターコネクト用のアダプターコストを削減することができますが アプリケーション サーバーとデータベース サーバー間とインターコネクトを明示的に分けたい場合でも Virtual Ethernet を定義することによりアダプターのコストを削減することができます なお Virtual Ethernet を新たに定義することに対してシステム停止は必要ありません 33

34 12. Replication なし P2P/onReqEnd/modAtt/ 非同期 / 専有 P2P/onReqEnd/modAtt/ 非同期 / サービス兼用 P2P/onReqEnd/modAtt/ 非同期 /Virtual スループット比 ノード数 図 サービス LAN 兼用と Virtual Ethernet でのスフープットの違い レスポンスタイム比 Replicationなし P2P/onReqEnd/modAtt/ 非同期 / 専有 P2P/onReqEnd/modAtt/ 非同期 / サービス兼用 P2P/onReqEnd/modAtt/ 非同期 /Virtual ノード数 図 サービス LAN 兼用と Virtual Ethernet での平均レスポンスタイムの違い 34

35 CPU 使用率 (%) Replication なし P2P/onReqEnd/modAtt/ 非同期 / 専用 P2P/onReqEnd/modAtt/ 非同期 / サービス兼用 P2P/onReqEnd/modAtt/ 非同期 /Virtual 時間 ( 秒 ) 通信量 (KB/s) P2P/onReqEnd/modAtt/ 非同期 / サービス兼用 P2P/onReqEnd/modAtt/ 非同期 / 専有 P2P/onReqEnd/modAtt/ 非同期 / サービスのみ P2P/onReqEnd/modAtt/ 非同期 /Virtual( 専有 ) P2P/onReqEnd/modAtt/ 非同期 /Virtual( サービスのみ ) 時間 ( 秒 ) 図 サービス LAN 兼用と Virtual Ethernet でのアプリケーション サーバー 図 サービス LAN 兼用と Virtual Ethernet での通信量の違い 負荷の違い Grid Control の管理エージェント動作時の負荷本検証では Oracle Application Server 1g が稼動するノードに管理エージェントを導入し稼動させた場合に性能にどのように影響があるかを検証しました アプリケーション サーバー 1 ノードのそれぞれのノードで管理エージェントを稼動させました 結果としては 図 4-31に示すように 管理エージェント稼動時と停止時で合計スループットの差は.7% でした 管理エージェントを稼動させた場合 各ノードにおいて CPU 使用率の平均が 2% 程度上昇しましたが 管理エージェントを稼動させることによる影響はないと言えます 1.2 停止時稼動時 1.8 スループット比 図 管理エージェント稼動 / 停止によるスループットへの影響 35

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

37 6. 参考 URL [1] p5 テクノロジー [2] IBM XL C/C++ Enterprise Edition V7. for AIX Runtime Environment Component [3]Spring Framework 37

38 日本オラクル株式会社 Copyright 28 Oracle Corporation Japan. All Rights Reserved. 無断転載を禁ず この文書はあくまでも参考資料であり 掲載されている情報は予告なしに変更されるこ とがあります 日本オラクル社は本書の内容に関していかなる保証もいたしません また 本書の内容に関連したいかなる損害についても責任を負いかねます Oracle JD Edwards PeopleSoft 及び Siebel は 米国オラクル コーポレーション及びその子会社 関連会社の登録商標です その他の名称は 各社の商標または登録商標です 文中に参照されている各製品名及びサービス名は米国 Oracle Corporation の商標または登録商標です その他の製品名及びサービス名はそれぞれの所有者の商標または登録商標の可能性があります 38