Jump to content 日本-日本語

ソフトウェア  >  セキュリティ

HP IceWall SSO

HP IceWall技術レポート:パフォーマンス特集(5)

IceWall ソフトウェア

認証技術開発センター・
認証コンサルティング
サポート
導入サービス
お客様事例
技術レポート
カタログ
デモセンター
IceWallニュース
お問い合わせ
IceWall製品サイト一覧
IceWall ソフトウェア
IceWall SSO
IceWall MFA
IceWall Identity Manager
IceWall Federation
IceWall MCRP
IceWall Remote Configuration Manager
IceWall QFS
   
IceWall サイトマップ
English
IceWall SSO(English)
IceWall Federation(English)
IceWall Remote Configuration Manager(English)
日本ヒューレット・パッカード セキュリティページ
日本ヒューレット・パッカード メールニュース
サイトマップ
Webからのお問い合わせ、資料ダウンロードはこちら
※IceWall SSO は株式会社SCCとの共同開発製品です。
コンテンツに進む
HP-UX 11i v3におけるHP IceWall SSOのパフォーマンス HP-UX 11i v3におけるHP IceWall SSOのパフォーマンス
1.検証内容
2. 検証結果
3. 最後に 

技術レポート一覧へ戻る
今回の技術レポートでは、2007年4月に発表された、HP-UXの最新バージョンHP-UX 11i v3 ※1におけるHP IceWall SSOのパフォーマンスについてご紹介いたします。

今回、最新バージョンのHP-UX 11i v3 と Oracle Database 10g Release2 (以下、Oracle 10g R2) とを組み合わせた環境下で、HP IceWall SSO 8.0 R2のログインパフォーマンスの測定を行いました。測定の結果、最新のHP-UX 11iv3とHP IceWall SSOの組み合わせは、従来よりもさらに良好なパフォーマンスを提供できる事が確認されました。以降に検証の内容と結果を説明いたします。

※1 本トピックス記述時点では、HP IceWall SSO 8.0 R2 は正式に HP-UX 11i v3上での動作をサポートしておりません。 正式な対応の時期は未定ですが、できるだけ早い時期を検討しております。

1 検証内容 

1.1 検証のポイント

今回のパフォーマンス検証のポイントを説明するために、まずHP IceWall SSOシステムの構成例を以下の図に示します。

HP IceWall SSO 構成例
図 1 HP IceWall SSO 構成例


HP IceWall SSOが行う処理は、大まかにログイン(認証)とアクセス認可処理がありますが、サーバへの負荷が大きいのはログイン処理です。
上図のように、通常クライアントからのログインリクエストはIceWallサーバを経由して認証サーバへのログインリクエストになります。認証サーバは認証DBにアクセスしてユーザの情報を取得し、ログインの許可を行います。多くのクライアントが接続されたシステムにおいてログインリクエストの数が膨大になると、1台のIceWallサーバでは処理できないため、サーバを複数立ち上げて負荷を分散させることができますが、認証サーバと認証DBについては負荷分散ができないため1台で処理するしかありません。つまりHP IceWall SSOのログイン処理パフォーマンスは認証サーバと認証DBの性能が大きく影響することになります。
今回は多数のユーザからのログインリクエストを受け付けて処理する1台の認証サーバとDBサーバの性能を検証するために、HP IceWall SSOの認証サーバへの一秒当たりの認証ログイン件数を測定しています。

1.2 検証構成

今回の検証では以下の構成図のとおり、認証DB としてのOracle 10g R2 データベースサーバと認証サーバと負荷ツールを実行するクライアントを構成しました。
検証環境構成
図 2 検証環境構成


負荷の発生にはHP IceWall SSOの開発チームの内部で使用している負荷ツールを使用しています。この負荷ツールは、IceWallサーバから認証サーバへ送信されるログインリクエストをシミュレートし、連続して多数のリクエストを発生させる事ができます。

1.3 検証環境

負荷ツールクライアント、認証サーバ、DBサーバの各マシン環境は以下の表のとおりです。

  ハードウェア環境 ソフトウェア環境
負荷ツール
クライアント
HP Proliant DL360G5
CPU: Dual Core Xeon 5160 3GHz x 2
MEM: 5GB
HDD: SAS 72GB 10krpm x 2
OS: Red Hat Enterprise Linux 4 Update 2
SW: 自社製負荷ツール
認証サーバ HP Integrity rx3600
CPU: Dual Core Itanium2 1.6G/18M x 2
MEM: 4GB
HDD: SAS 72GB 10krpm x 3
OS: HP-UX 11i v3
SW: HP IceWall SSO 8.0 R2認証モジュールcertd
DBサーバ HP Integrity rx6600
CPU: Dual Core Itanium2 1.6G/24M x 4
MEM: 16GB
HDD: SAS 72GB 10k rpm x 4
OS: HP-UX 11i v3
SW: Oracle 10g R2 (10.2.0.2)


各ソフトウェアには以下の設定を行っています。
  • HP-UX 11i v3
    ・パッチ PHKL_35936 をインストールします。
    ・Hyper Threading を有効にします。 (CPUリソース最大限に生かすため)
    ・カーネルパラメータに Oracle 10g R2の推奨値を設定します。
    ・DBサーバへHP-UXをインストールする際のコマンドに-ignoreSysPrereqsオプションを指定します。
  • Oracle 10g R2 (10.2.0.2)
    ・パフォーマンス・チューニング
    後述のCOMMIT_WRITEを除き、ほとんどチューニングせず、インストール直後のデフォルト状態の
    ままです。
  • HP IceWall SSO
    ・最新バージョン 8.0 R2をインストールします。
    ・最高のパフォーマンスが得られるように、以下の認証サーバのパラメータを調整します。
    • MAXREQTHREAD
    • REQQUESIZE
    • MAXDBCONNECT
  • データベース
    ・表領域
    デフォルトのUSERS表領域を使用します。
    表領域とREDOログのファイル、および制御ファイルは、rx6600の内蔵 ハードディスク(SAS 72GB
    10k rpm)に置かれています。

1.4 検証シナリオ

検証は以下の2つのパターンで行いました。
  1. 認証DBサーバへはRead Onlyでアクセスを行い、40ユーザが同時にログインし続けるシナリオを負荷ツールが実行する。総ログイン数をログインにかかった総時間を割ることで、一秒当たりのログインの速度を割り出す。
  2. 認証DBサーバへは Read/Write でアクセスを行い、40ユーザが同時にログインし続けるシナリオを負荷ツールが実行する。OracleのパラメータCOMMIT_WRITEの値を変えて、それぞれの値について測定を行う。
※ COMMIT_WRITEパラメータについて

Oracle Database 10g R2から、COMMIT時におけるREDOログファイルへの書き込み制御するパラメータ COMMIT_WRITEがサポートされました。このパラメータがパフォーマンスに影響を及ぼすことが判明したため、このパラメータの値を変えて検証を行っています。

COMMIT_WRITEに設定できるパラメータの値は以下のとおりです。
- IMMEDIATE: コミット時にREDOログファイルへ書き込む。I/Oが発生する(デフォルト)
- BATCH: バッファリングされ、I/Oは発生しない。ログ・ライター・プロセスにより特定の時間内に
  REDOログファイルへ書き込むことができる。
- WAIT: 書き込みが完了すると制御が戻る(デフォルト)
- NOWAIT: 書き込み完了を待たずにアプリケーションへ制御が戻る

検証結果

2.1 結果 

検証結果は以下のとおりです。

シナリオ DBアクセス COMMIT_WRITE設定 ログイン処理速度
1 Read Only - 7060 ログイン/秒
2 Read/Write IMMEDIATE,WAIT 1562 ログイン/秒
IMMEDIATE,NOWAIT 3030 ログイン/秒
BATCH,NOWAIT 3030 ログイン/秒

2.2 考察

認証DBへのアクセスがReadOnlyの場合、ログイン性能は1日あたり1億人分のログイン処理を可能にするレベルの性能であり、Webシングルサインオン・ソリューションとしては業界最高水準の値です。

認証DB へのRead/Write のアクセスにおいて、COMMIT_WRITE= IMMEDIATE, WAITの場合が一番遅い結果となりました。これは、COMMIT時のREDOログファイルへの書き込みで発生したディスクI/Oがボトルネックになっているためです。COMMIT_WRITE=BATCHの場合の結果と比較すれば一目瞭然です。
このボトルネックを解消するには、
  • REDOログファイルを速いディスク装置に置くこと
  • COMMIT_WRITE=IMMEIDIATE,NOWAIT、もしくは、BATCH,NOWAITでCOMMIT書き込みするように設定すること
が考えられます。
しかし速いディスク装置は大抵非常に高価ですし、COMMIT_WRITEの値をNOWAITにすると、もしもシステムがクラッシュした時にREDOログが失われるリスクがあります。

3. 最後に

今回HP-UX 11i v3、Oracle 10g R2、HP IceWall SSO 8.0 R2を組み合わせた構成におけるパフォーマンス検証結果を行いました。実際のシステムでは様々な要因により、必ずしも同じ結果が得られるわけではありませんが、新しいHP-UX 11i v3の効果とHP IceWall SSOのパフォーマンスをどこまで引き出す事が可能かを検証する事ができました。
今回の検証結果は、本製品がシングルサインオン製品としての活用範囲を広げ、一般生活者が利用するような非常に大規模なシステムのログイン処理にも十分に耐えうること証明といえます。
2007.5.25 日本ヒューレット・パッカード コンサルティング・インテグレーション統括本部 セキュリティスペシャリスト CISSP-ISSJP 
藤波 勉
●関連技術レポート
≫ パフォーマンス特集(1) SSO製品のスケーラビリティの考え方とHP IceWall SSOのアーキテクチャ
≫ パフォーマンス特集(2) IceWall+ロードバランサが実現するパフォーマンス
≫ パフォーマンス特集(3) HP IceWall SSOのパフォーマンス調査方法
≫ パフォーマンス特集(4) 新しいパフォーマンスモニタリングツール(iwpm)のご紹介
≫ パフォーマンス特集(5) HP-UX 11i v3におけるHP IceWall SSOのパフォーマンス(本トピックス)
≫ 技術レポート一覧へ戻る
このページのトップへ
印刷用画面へ印刷用画面へ
プライバシー ご利用条件・免責事項