| Oracle® Fusion Middleware Oracle Entitlements Server管理者ガイド 11gリリース2 (11.1.2.2) B71695-05 |
|
 前 |
 次 |
モニタリングおよびパフォーマンスのチューニングは、アプリケーションで使用されるOracle Entitlements Serverコンポーネントの管理には必要不可欠なものです。コンポーネントを監視して、それらが問題なく動作していることを確認し、Oracle Entitlements Serverコンポーネントのパフォーマンスをチューニングすると、現在のシステム・リソースおよびトラフィック・ロードに基づいた、最適なパフォーマンスおよびスループットが得られます。
この章では、パフォーマンスおよびスループットを最大限にするためのOracle Entitlements Serverの構成およびデプロイ方法について説明します。また、アプリケーションで使用されるコンポーネントのモニタリング、分析およびチューニングについても取り上げます。この章には、次のセクションがあります。
この章では、Oracle Entitlements Serverデプロイメントにおける重要な概念およびコンポーネントを理解していることを想定しています。次の項では、この章のパフォーマンス関連のトピックの基本的な事項について説明します。
通常、パフォーマンス・チューニングには一連のトレードオフが伴います。ボトルネックが発生して原因を判定する場合、期待した結果を得るために、ある分野のパフォーマンスを変更しなければならないことがあります。パフォーマンス目標の達成に向けての明確な計画があれば、最も重要な分野がはっきりするため、パフォーマンス向上のために何を犠牲にするかを判断しやすくなります。
アプリケーションのパフォーマンス機能を最大限に高めるには、パフォーマンスおよびスケーラビリティを設計に組み込む必要があります。パフォーマンス計画は、現在のパフォーマンス要件を満たし、既知の問題(ボトルネックやハードウェア・リソースの不足など)を解決し、負荷、ユーザーまたはプロセスの予期される変化に対応します。また、パフォーマンスに影響を与えることなく、ピーク時にコンポーネントを拡張する方法も示します。
この後の項では、アプリケーション環境をチューニングしてパフォーマンスを最適化するための計画を作成する手順について説明します。
ステップ1: パフォーマンス目標および要件の定義
ステップ2: アプリケーションの認可の設計
アプリケーションのパフォーマンス・チューニングを始める前に、まず達成しようとするパフォーマンス目標を明確化する必要があります。
パフォーマンス目標が何であるかを理解するために、次のステップを実行してください。
パフォーマンス制約とそれぞれの影響を理解することで、レスポンス時間、スループット、特定のハードウェアにかかる負荷など、アプリケーション環境にとって現実的なパフォーマンス目標を確実に設定できます。パフォーマンス目標は、次のような制約によって制限されます。
ハードウェアおよびソフトウェアの構成(CPUタイプ、ディスク・サイズ、ディスクの処理速度、十分なメモリーなど)。
アプリケーションのニーズを十分に満たすために必要なハードウェアおよびソフトウェアの構成。ニーズを決定するプロセスは、キャパシティ・プランニングと呼ばれ、ハードウェア要件を決定する式は、1つではありません。
システムのパフォーマンス目標。キャパシティ・プランニングの際には、システムのパフォーマンス目標を評価し、アプリケーションを理解することが求められます。サーバー・ハードウェアのキャパシティ・プランニングでは、最大のパフォーマンス要件に焦点を当てます。
キャパシティ・プランニングの詳細は、Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイドの「キャパシティ・プランニングおよびクラスタと高可用性機能の使用」の章項を参照してください。
ピーク使用量やレスポンス時間に対応した高可用性アーキテクチャの構成。
Oracle Entitlements Serverの高可用性機能の実装の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Management高可用性ガイド』の「Oracle Entitlements Serverの高可用性の構成」の章を参照してください。
ドメイン間での相互運用、レガシー・システムの使用、およびレガシー・データのサポートが可能かどうか
開発、実装およびメンテナンスのコスト。
高可用性(HA)および障害時リカバリのためにアプリケーションをデプロイしてチューニングする作業を始める前に、運用環境を明確に定義しておくことが重要です。運用環境は、次のような大まかな制約および要件によって決まります。
デプロイメント・アーキテクチャ
エンドツーエンドのデプロイメントおよび運用セキュリティ要件
ハードウェア・リソース
高可用性(HA)および障害時リカバリ(DR)要件
新しいシステムを設計するのか、既存のシステムをメンテナンスするのかにかかわらず、具体的なパフォーマンス目標を設定して、最適化の方法と対象を知っておいてください。パフォーマンス目標を決定するには、デプロイするアプリケーションおよびシステムの環境面での制約を理解する必要があります。
アプリケーションの条件にかなう認可アクティビティのレベルに関する情報を収集してください。これには次のものが含まれます。
ビジネス・アプリケーションごとの予想されるユーザー数(合計および同時ユーザー数)
アプリケーションごとの同時ユーザー認可リクエスト数
合計管理対象アプリケーション数
認可データのサイズ(アプリケーションごとに編成)
認可システムのパフォーマンスに対する高可用性と障害時リカバリの選択肢および想定される影響
ターゲットCPUの使用率に基づくキャパシティ・プランニング
この項には次のトピックが含まれます:
Oracle Entitlements Serverでは、一般的なビジネス、アプリケーションおよびサービス・フローを明確に表現するポリシー・モデルを提供しようとしています。
個々のビジネス・ロールおよび権限の1対1の単純なマッピングを行うと、ポリシーが増大し、根底にあるプロセスと目的の関係を把握できなくなります。Oracle Entitlements Serverでは、ポリシーのモデリングのベースとして階層を使用しています。これにより、関係に基づいた目標のグループ化が容易になります。さらに、属性および権限を継承することもできます。Oracle Entitlements Serverの階層型リソース、ロール、ポリシーおよびポリシー・ドメインの階層構造により、ポリシーのサイズの削減およびポリシーの複雑性の低減が可能になります。Oracle Entitlements Serverでは、属性ベースのアクセス制御(ABAC)、ロールベースのアクセス制御(NIST RBAC)、ERBAC (Enterprise RBAC)およびJava Authentication and Authorization Service (JAAS)ポリシー・モデルをサポートしています。ビジネス・ニーズに基づいて、ポリシー・モデルのいずれかを使用したり、これらを組み合せて使用することもできます。
ビジネス・プロセスと目的は階層型である傾向があります。たとえば、貸付承認プロセスは複数のサブプロセスから構成され、これらのサブプロセスの一部はさらにきめ細やかなプロセスを構成することがあります。同様に、Webアプリケーションは複数のWebページから構成され、各ページには様々なセクションがあり、各セクションには様々な情報が含まれています。
ロールベースのアクセス制御(RBAC)モデルでは、ロールを使用してエンタープライズ・セキュリティをモデル化します。RBACの場合、権限はロールを拡張したものです。ロールは、次の3つのカテゴリに分けることができます。
企業全体の静的ロール: ユーザーは目的に関係なく、これらのロールを付与されます。たとえば、Employeeロールは、企業全体で共通であるため、静的な割当てにすることが可能です。このようなロールの多くは、LDAPまたは他の企業全体のアイデンティティ・ストアに格納されます。このようなロールは通常、認証時に割り当てられ、ほとんどの場合、セッションの有効期限まで有効です。
アプリケーション固有の静的ロール: これらは、エンタープライズ・アプリケーション・サブセットに固有の、静的ロールの割当てです。ユーザーまたはエンタープライズ・ロールは、アクセスしようとしているアプリケーションに基づいた様々なロールを付与されます。通常は、ベスト・プラクティスとして、アプリケーション・ロールをエンタープライズ・ロールに付与することをお薦めします。ユーザー数は、通常、企業においては非常に大きな数になります。管理するのは難しく、パフォーマンスに影響を及ぼす可能性があります。
アプリケーション固有の動的ロール: これらは動的または条件付きでアプリケーション・ロールに割り当てられます。これらは、ユーザーが開始したアクションによって必要に応じて割り当てられます。たとえば、ファンド・マネージャ・ロールは特定のファンド担当者にのみ付与される必要があります。これらは、認可リクエストが実行されたときに成立し、決定が算出されると破棄されます。前述のとおり、Oracle Entitlements Serverでは、状況に基づいて、正確なロールの割当ての制御を容易に行うことができます。
前述のとおり、企業全体のロールは算出が容易ですが、柔軟性に欠けています。動的ロールはすべての認可リクエストに対して算出する必要がありますが、非常に柔軟性に富んでいます。ただし、ローカルの参照のために、これらのロールはキャッシュからフェッチでき、完全な算出が必要ではありません。ロールの静的または動的な特徴および範囲により、正しいロール・タイプの選択の際の係数が決定されます。要件の変更によっては、企業全体のロールをアプリケーション固有の動的ロールに変換できます。また、その逆も可能です。
Oracle Entitlements ServerがNIST RBACおよびABAC標準に基づいているため、このタイプの相互運用性が可能になります。
属性がABAC (属性ベースのアクセス制御)モデルのベースとなります。Oracle Entitlements Serverでは様々な属性をサポートしています(たとえば、ユーザー、エンタープライズ・ロール属性はPIPを介してOESでサポートされ、リソース属性は直接OESでサポートされています。アプリケーション・ロール属性はサポートされていません)。さらに、カスタム属性を特定のニーズのために定義できます。ABACは非常に状況への依存度が高く、基本的に、これらの属性に基づいた式を評価することにより、すべての認可決定が行われます。認可モデルとして、ABACは動的な計算への依存度が高いため、RBACよりも柔軟性があります。ただし、これを採用すると、静的ポリシー・データに基づいた監査を行うことができなくなります。また、複雑になるということは、ABACモデルはRBACモデルよりも多くの計算を使用するということでもあります。
Oracle Entitlements Serverでは、ポリシー構造を備え、これにより、ビジネス・セキュリティ要件を未処理のABACモデルにマップできます。サブジェクト(ユーザーおよびエンタープライズ・ロール)、リソースおよび属性は、ABACポリシーで最も共通に使用される要素です。Oracle Entitlements Server UIは、これらのオブジェクトについて容易に使用できるように抽象化されていて、ポリシーを簡単に構築できます。Oracle Entitlements Serverでは、リソース、属性およびポリシーの継承もサポートしています。これにより、多数のユーザーおよびリソースを制御できるように、ポリシーを戦略的に配置できます。
様々なOracle Entitlements Serverコンポーネントの推奨される設計技術の詳細は、『Oracle Fusion Middleware Oracle Entitlements Server開発者ガイド』を参照してください。
前述の項では、RBAC、Java2 ABACなどの様々な標準の認可モデルを提示しました。これらは、アプリケーション認可の設計用にOracle Entitlements Serverによってサポートされています。次に、拡張性の高い認可サブシステムを設計するための、重要な検討事項を示します。
1つ目は、基本的にアプリケーションの使用パターンに合った適切な認可モデルを選択することです。たとえば、アプリケーションの使用パターンが看護師や医師などのフ機能エンティティで十分に定義されている病院情報アプリケーションを構築する場合、認可設計パターンに基づいたRBACを採用すると、通常、このアプリケーションは恩恵を受けます。
2つ目は、認可サブシステムの様々な要素の増大する要因を判定することが設計の側面であるということです。通常、認可システムは、3つの側面を持つ領域として考えることができます。3つの側面とは、アプリケーション・ユーザー(エンド・ユーザー、グループまたはアプリケーション・ロールとして認識)、保護されるアプリケーション・リソースおよび操作、アプリケーション・ユーザーと(許可されたリソースおよび操作)と追加のルールをバインドする認可ポリシーがあります。拡張性やパフォーマンスの高い認可システムでは、認可スペースが増大する効果を認可サブシステム上でできるだけ一定に保つことが非常に重要です。たとえば、次のように入力します。
アプリケーションで、保護されるリソースの合計数が、経費報告データベースの合計レコード数の増加と同様に、データ・セキュリティの合計ユーザー数とともに継続的に増加している場合
機能セキュリティのために処理する必要のある新しい種類のエンド・ユーザーのグループ化があるため、アプリケーション・ロールの合計数が増加している場合
これらのシナリオでは、認可サブシステムの設計は、インテリジェントな認可パターン(階層型リソースの継承可能なポリシー、ポリシーに基づいた属性、およびユーザー移入のタイプに対応する条件に基づいた属性を持つアプリケーション・ロール・ポリシーなど)を介して増加に対応できることが非常に重要です。重要なポイントは、認可サブシステムの増大が、認可の範囲の拡大に対応するためではなく、新しい種類の認可要件に対応するためのアプリケーションのビジネス要件に基づいているということです。
3つ目は、最新のクラウド・ベースのアプリケーションという新しい課題に取り組むことです。アプリケーション・ユーザーに関する従来の静的な情報について認可決定を行う必要があるだけでなく、ユーザーの動的な状況に関する情報を使用する必要もあります。これには、アプリケーションの認可モデルの適用、および複数の認可標準を組み合せてRBACやABACなどを一緒に使用する新しい要件に対応する設計が必要になります。
4つ目は、クラウド上にデプロイされ、様々なユーザーにサービスを提供する必要のある、SAASアプリケーションを設計することです。これには、ビジネス・データだけでなくセキュリティ・データにおいても、マルチテナントやデータの分離をサポートするアプリケーションの設計が必要になります。これを行うと、より厳しい要件や制約が認可サブシステムにもたらされます。これにより、認可システムがコンパクトで効果的になり、テナント数の増大に対して柔軟性に富んだものになります。
Oracle Entitlement Serverのインストールの構成後、最適なパフォーマンスが必要になります。この項では、Oracle Entitlement Serverのパフォーマンスの最適化について、Oracle Entitlement Serveの管理者のためのガイドラインについて説明します。このセクションでは、次のトピックについて説明します。
これらのOracle Entitlements Serverコンポーネントのチューニングの最適化は、次の項で説明します。
パフォーマンス・チューニング全体の中で最初にチューニングする必要があるコンポーネントは、OESポリシー・ストアです。ポリシー・ストアのチューニングには、基礎となるデータベースおよびTopLink Java永続性API(JPA)プロバイダのチューニングが含まれています。Java Persistence APIは、Java EEアプリケーションおよびJava SEアプリケーションの永続性に関する仕様です。次の各項では、ポリシー・ストアのチューニングの一環として、チューニングの個々の側面について説明します。
表15-1では、最適な値でチューニングする必要のある、様々なOracle Databaseのシステム・パラメータについて説明し、サンプルの値を示しています。アプリケーションのニーズに基づいて、値を調整できます。
表15-1 Oracle Databaseのシステム・パラメータのチューニング
|
パラメータ名 |
説明 |
デフォルト値 |
推奨値 |
|
processes |
PROCESSESには、Oracleに同時に接続できるオペレーティング・システムのユーザー・プロセスの最大数を指定します。 |
40 |
1500 |
|
sga_target |
SGA_TARGETには、すべてのSGAコンポーネントの合計サイズを指定します。 |
0 (SGA自動チューニングは、DEFERREDモードの自動チューニング・リクエストでは使用禁止、IMMEDIATEモードの自動チューニング・リクエストでは使用可能である。) |
3221225472 (3GB) |
|
audit_trail |
AUDIT_TRAILは、データベース監査を有効または無効にします。 |
なし |
なし |
|
open_cursors |
OPEN_CURSORSには、1つのセッションで同時にオープンできるカーソル(プライベートSQL領域へのハンドル)の最大数を指定します。 |
50 |
500 |
|
pga_aggregate_target |
PGA_AGGREGATE_TARGETには、インスタンスに接続されたすべてのサーバー・プロセスが使用できるターゲット集計PGAメモリーを指定します。 |
10MB、またはSGAサイズの20%のいずれか大きい方 |
1610612736 (1.5 GB) |
|
nls_sort |
NLS_SORTには、ORDER BY問合せの照合順序を指定します。 この値がBINARYの場合、ORDER BYの問合せの照合順番は、文字に対応する数値に基づきます(システム・オーバーヘッドが比較的少なくて済むバイナリ・ソート)。 この値が名前付き言語ソートの場合、ソートは、定義された言語ソートの順序に基づいて行われます。NLS_LANGUAGEパラメータがサポートするほとんど(すべてではない)の言語は、同じ名前の言語ソートもサポートしています。 |
BINARY |
|
|
filesystemio_options |
FILESYSTEMIO_OPTIONSには、ファイル・システム・ファイルに対する特定のI/O操作を指定します。 |
SETALL |
|
|
fast_start_mttr_target |
FAST_START_MTTR_TARGETには、データベースがシングル・インスタンスのクラッシュ・リカバリを実行するまでにかかる秒数を指定します。 |
0 |
3600 |
|
db_securefile |
DB_SECUREFILEには、セキュア・ファイルとしてLOBファイルを処理するかどうかを指定します。 |
PERMITTED |
ALWAYS |
|
session_cached_cursors |
SESSION_CACHED_CURSORSを使用すると、キャッシュするセッション・カーソル数を指定できます。 |
0 |
500 |
|
plsql_code_type |
PLSQL_CODE_TYPEには、PL/SQLライブラリ単位のコンパイル・モードを指定します。 |
INTERPRETED |
NATIVE |
|
"_b_tree_bitmap_plans" |
False |
||
|
Memory_target |
MEMORY_TARGETはデータベース初期化パラメータ(iOracle 11gで導入)です。これは、自動PGAおよびSGAメモリー・サイズ設定のために使用できます。 |
0 |
0 |
Oracle DatabaseのREDOログの詳細は、『Oracle Databaseリファレンス』を参照してください。
次のSQLスクリプトをシステム・パラメータの設定に使用できます。SQLスクリプトは、SYSDBAロールを持つDBユーザーとして実行する必要があります。
ALTER SYSTEM SET processes = 1500 SCOPE = spfile; ALTER SYSTEM SET sga_target = 3221225472 SCOPE = spfile; ALTER SYSTEM SET audit_trail = NONE SCOPE = spfile; ALTER SYSTEM SET open_cursors = 500 SCOPE = spfile; ALTER SYSTEM SET pga_aggregate_target = 1610612736 SCOPE = spfile; ALTER SYSTEM SET nls_sort = BINARY SCOPE = spfile; ALTER SYSTEM SET filesystemio_options = SETALL SCOPE = spfile; ALTER SYSTEM SET fast_start_mttr_target = 3600 SCOPE = spfile; ALTER SYSTEM SET db_securefile = ALWAYS SCOPE = spfile; ALTER SYSTEM SET session_cached_cursors = 500 SCOPE = spfile; ALTER SYSTEM SET plsql_code_type = NATIVE SCOPE = spfile; ALTER SYSTEM SET "_b_tree_bitmap_plans" = FALSE scope=spfile ALTER SYSTEM SET memory_target=0 SCOPE = SPFILE;
また、kernel.shmall、kernel.shmmax、kernel.semおよびfs.file-maxが最適な値に設定されていることを確認します(すべてのカーネル・レベル・パラメータはチューニング可能で、/etc/sysctl.confから取得できます)。
次のREDOログおよびUNDO変更ログのすべての管理操作は、SYSDBAロールを持つDBユーザーとして実行する必要があります。
REDOログ・ファイル用の割当てディスク領域の増加
3つのREDOログ・ファイル(各ファイルのサイズは4GB以上)を使用することをお薦めします。新しいREDOログ・ファイルの作成後、既存または古いREDOログ・ファイル(グループ)は、削除する必要があります。
次のSQLコマンドを実行して、新しいREDOログ・グループを追加します。環境に従って適切なファイル・パスが設定されていることを確認します。
alter database add logfile ('<oradata directory>/orcl/redo04.log') SIZE 4G;
alter database add logfile ('<oradata directory>/orcl/redo05.log') SIZE 4G;
alter database add logfile ('<oradata directory>/orcl/redo06.log') SIZE 4G;
次のSQLコマンドを実行して、古いREDOログ・ファイル(グループ)を削除します。次の手順を実行します。
Exec SQL: SELECT group#, member FROM V$LOGFILE;
追加したメンバー以外のgroup#に対しては、次を実行すると、これらを削除できます。
ALTER DATABASE DROP LOGFILE GROUP <group#>;
アクティブなログ・グループを削除する場合、次のように、ログ・スイッチを変更する必要があります。
ALTER SYSTEM SWITCH LOGFILE;
Oracle DatabaseのREDOログの詳細は、『Oracle Database管理者ガイド』の「REDOログの管理」の章を参照してください。
UNDO表領域用の割当てディスク領域の増加
UNDO表領域のサイズは、20GBにすることをお薦めします。
次のSQLコマンドを実行して、UNDO表領域のサイズを変更します。環境に従って適切なファイル・パスが設定されていることを確認します。
ALTER DATABASE DATAFILE '<oradata directory>/orcl/undotbs01.dbf' RESIZE 20G;
Oracle DatabaseのUNDOログの詳細は、『Oracle Database管理者ガイド』の「UNDOログの管理」の章を参照してください。
リポジトリ作成時の表領域のチューニング
OES DBスキーマは、RCU (リポジトリ作成ユーティリティ)を介して作成されます。RCUによるデータベース・スキーマの作成時に、次の作業を実行します。
最適なパフォーマンスのために、十分に大きいサイズの初期ディスク領域をOES表領域に割り当てます。IAS_OPSSおよびIAS_TEMP表領域に6GBのファイルを割り当てます。
ポリシー・ストアで多くの大規模なアプリケーションを管理する場合は、大量の表領域を割り当てます。IAS_OPSS表領域には40GBを、IAS_TEMP表領域には15GBを割り当てることができます。
ポリシー・ストアに多くの大規模なアプリケーションを追加する場合は、表領域がフルになったときに引き続き拡張しないように、表領域の増分を100MBではなく1GBとしてマークすることをお薦めします。
RCUを使用して、スキーマ作成時に表領域をチューニングする手順を次に示します。
RCUの「表領域のマップ」画面で、「表領域の管理」ボタンをクリックして、既存の表領域を変更します。
画面の左側の部分で IAS_OPSSまたはIAS_TEMP表領域を選択し、表15-2に示したフィールドを編集します。
データファイルを変更または編集するには、編集するデータファイルの隣にあるアイコンを選択して、鉛筆の付いたアイコンをクリックします。
「データファイルの編集」画面が表示されます。
次の表の説明に従って情報を指定します。
表15-3 データファイルのサイズの指定
| フィールド | 説明 |
|---|---|
|
サイズ |
最適なパフォーマンスのために、十分に大きいサイズの初期ディスク領域をOES表領域に割り当てます。 |
|
フル時に自動的にデータ・ファイルを拡張(AUTOEXTEND) |
データファイルがフルになったときに、データファイルのサイズが自動的に拡張されるようにするには、「フルになった場合に自動的にデータファイルを拡張(AUTOEXTEND)」を選択します。「増分」フィールドで、データファイルがフルになるたびに増分する1GBを指定します。このドロップダウン・リストを使用して、ギガバイト(GB)で指定します。ポリシー・ストアに多くの大規模なアプリケーションを追加する場合は、表領域がフルになったときに引き続き拡張しないように、表領域の増分を100MBではなく1GBとしてマークすることをお薦めします。 |
|
最大サイズ |
無制限 |
DBインスタンスがすでに存在する場合の表領域のチューニング
DBインスタンスがすでに存在する場合、SYSDBAロールを持つDBユーザーとしてALTER TABLESPACEコマンドを実行し、ディスク領域を追加します。たとえば、次のように入力します。
alter tablespace R2_IAS_OPSS ADD DATAFILE '<oradata directory>/orcl/R2_ias_opss2.dbf' SIZE 20 G AUTOEXTEND ON; alter tablespace R2_IAS_TEMP ADD TEMPFILE ''<oradata directory>/orcl/R2_iastemp2.dbf' SIZE 10 G AUTOEXTEND ON;
前述の手順は、すべての必要なOES DBスキーマのチューニングに対応しています。時々実行する必要のあるチューニングは、データベースに保存されたポリシー・データから、OES DBスキーマ・ユーザーとしてデータベース統計を収集することのみです。
JPS_DN.PARENTDN列については、スキーマ統計を収集しないでください。この列のヒストグラムを収集すると、問合せのパフォーマンスに影響があります。ヒストグラムを無効にするには、次のSQLスクリプトを実行します。
EXECUTE dbms_stats.delete_column_stats(ownname=>'<SCHEMA_NAME>', tabname=>'JPS_DN', colname=>'PARENTDN', col_stat_type=>'HISTOGRAM');
EXECUTE dbms_stats.set_table_prefs('<SCHEMA_NAME>', 'JPS_DN','METHOD_OPT', 'FOR ALL COLUMNS SIZE AUTO, FOR COLUMNS SIZE 1 PARENTDN');
スキーマ名を使用し、DBMS_STATSプロシージャを実行して、次のように最新の統計を収集します。
Execute DBMS_STATS.gather_schema_stats('<SCHEMA_NAME>',DBMS_STATS.AUTO_SAMPLE_SIZE,no_invalidate=>FALSE)
必要な頻度でプロシージャ実行するようにデータベース・ジョブ定義することにより、これを自動化できます。この収集操作は、ストアに大量のポリシー・データを移行した後に実行する必要があります。
次のSQL例では、OPSS_AUTO_STATISTICSと呼ばれるデータベース・ジョブを作成します。これは、日曜日の午前0時に実行されます。このデータベース・ジョブは、SYSDBA権限を持つユーザーが追加する必要があります。
BEGIN
SYS.DBMS_SCHEDULER.CREATE_JOB (
job_name => '"SYS"."OPSS_AUTO_STATISTICS"',
job_type => 'PLSQL_BLOCK',
job_action => 'Execute
DBMS_STATS.gather_schema_stats(''<SCHEMA>'',DBMS_STATS.AUTO_SAMPLE_SIZE,no_invalidate=>FALSE);',
number_of_arguments => 0,
start_date => NULL,
repeat_interval => 'FREQ=WEEKLY;BYDAY=SUN;BYHOUR=0;BYMINUTE=0;BYSECOND=0',
end_date => NULL,
job_class => '"SYS"."DEFAULT_JOB_CLASS"',
enabled => FALSE,
auto_drop => FALSE,
comments => '',
credential_name => NULL,
destination_name => NULL);
SYS.DBMS_SCHEDULER.SET_ATTRIBUTE(
name => '"SYS"."OPSS_AUTO_STATISTICS"',
attribute => 'logging_level', value => DBMS_SCHEDULER.LOGGING_OFF);
SYS.DBMS_SCHEDULER.enable(
name => '"SYS"."OPSS_AUTO_STATISTICS"');
END;
/
『Oracle Databaseパフォーマンス・チューニング・ガイド』の統計を収集するタイミングに関する項を参照してください。
Oracle Entitlements Serverでは、データベース操作のJPA (Java Persistence API)実装として、EclipseLinkを使用しています。一部のEclipseLinkチューニング・パラメータ(表15-4)はjps-config.xmlファイルに設定できます。
表15-4 EclipseLinkのチューニング
| プロパティ | 説明 | デフォルト値 |
|---|---|---|
|
eclipselink.jdbc.connection_pool.default.max |
内部接続プール内の最大読取り接続数 |
32 |
|
eclipselink.jdbc.connection_pool.default.min |
内部接続プール内の最小読取り接続数 |
32 |
プロパティは、Oracle Entitlements Server管理用にDBポリシー・ストアのサービス・インスタンスを設定するか、制御プル・モードでPDPサービスを設定することにより上書きできます。次に例を示します。
<propertySet name="props.db.1">
<property name="jdbc.url"
value="jdbc:oracle:thin:@<HOST>:<PORT>/<SID>"/>
<property name="oracle.security.jps.farm.name" value="cn=my_domain"/>
<property name="server.type" value="DB_ORACLE"/>
… …
<property name=" eclipselink.jdbc.connection_pool.default.min" value="16"/>
<property name=" eclipselink.jdbc.connection_pool.default.min" value="64"/>
</propertySet>
… …
<serviceInstance name="policystore.db" provider="policystore.provider">
<property name="policystore.type" value="DB_ORACLE"/>
<propertySetRef ref="props.db.1"/>
</serviceInstance>
EclipseLinkプロパティの詳細は、EclipseLink APIリファレンスのPersistenceUnitPropertiesクラスに関する項を参照してください。
移行や配布のような大量のデータ操作のパフォーマンスを最適化するには、この項で説明するように、JVMパラメータをチューニングします。
WLST (WebLogic Scripting Tool)は、Oracle Middlewareのコマンド行スクリプト・インタフェースです。Oracle Entitlements Serverでは、セキュリティ・ストアの移行を含む一部の管理作業で使用されます。大規模なアプリケーションの移行では、次のようにWLSTツール用のJVMパラメータをチューニングして、Javaメモリー・サイズを設定する必要があります。
ファイルMIDDLEWARE_HOME/wlserver_10.3/common/bin/wlst.shを編集します。
JAVA_HOMEをバージョンが1.6.0_31以降のJDKに指定し、次のように、MEM_ARGSを追加します。
MEM_ARGS="-Xms6144m -Xmx6144m -Xmn1900m -XX:+UseParallelGC -XX:PermSize=128m -XX:MaxPermSize=1024m"
必要なヒープ・サイズ・パラメータ(ms、mx、mn)は、移行するアプリケーションのサイズに基づいて設定できることに注意してください。
OES管理サーバーは、ポリシー配布時のアプリケーションのスナップショット生成およびすべてのOES管理UI CRUD操作のために、最適化したパフォーマンスでチューニングする必要があります。
1. JDKバージョン1.6.0_31以上を使用します。
2. JDKメモリー・サイズをチューニングします。特に、大きなアプリケーション・ポリシーの場合、アプリケーション・ポリシーのスナップショットを生成するには、管理サーバーに大量のメモリーが必要になります。OES管理用のWebLogicドメインを構成時に、JDKを選択できます。「サーバーの起動モードおよびDKの構成」画面で、バージョンが1.6.0_31以降の場合、使用可能なJDKから選択し、それ以外の場合は「その他のJDK」をクリックして、1つ選択します。
手動でファイルを編集する必要がある場合、JAVA_HOMEプロパティを設定する、DOMAIN_HOME/bin/startWeblogic.shスクリプトを編集します。次に示すように、DOMAIN_HOME/bin/startWeblogic.shスクリプトを編集します。
JAVA_HOME="/home/user/jdk1.6.0_31"
MEM_ARGS="-Xms6144m -Xmx6144m -Xmn1900m -XX:PermSize=128m -XX:MaxPermSize=1024m"
before the line "${JAVA_HOME}/bin/java ${JAVA_VM} -version"
OESセキュリティ・モジュールが制御プル・モードで構成されている場合、これには次の2つの主要な機能があります。
PDPまたはPEP(あるいはその両方)として動作します。つまり、認可リクエストを受け取った後で決定を下し、その決定を実行します。
これはポリシー配布コンポーネントを定期的にコールして、構成されたポリシーとポリシー・データを評価のために使用可能にします。
したがって、OESセキュリティ・モジュールをチューニングする際には、2つの点に注意します。1つは、高スループットの認可リクエスト処理が行われている点と、もう1つは効率的にポリシーが配布されている点です。
ポリシー・データは、セキュリティ・モジュールのパフォーマンスに影響します。関数、属性、ロール、リソースおよびポリシーの数は、認可のスループット、配布時間およびセキュリティ・モジュールに必要なメモリー・サイズに大きく影響します。
この項では、次のポリシー・データ・サンプルを例として使用します。ご使用のアプリケーションは、サイズおよびモデリングにおいて異なっていることがあります。
Application Name: myapp oracle.security.jps.ldap.root.name: cn=jpsroot oracle.security.jps.farm.name: cn=base_domain
次に示すポリシー・データは、1つの例です。ポリシー・アーティファクトの数値は、ご使用のポリシー・モデリングの数値にする必要があります。
次に示した情報は、SM側でチューニングできません。データは、SMで必要なメモリーを見積もるために使用できます。
表15-5 セキュリティ・モジュールのチューニング属性
| 項目 | 数値 | コメント | 問合せSQL |
|---|---|---|---|
|
リソース・タイプ |
1 |
||
|
属性定義 |
17 |
||
|
関数定義 |
269 |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,%cn=functions,'; |
|
|
アプリケーション・ロール |
0 |
アプリケーション・ロールは作成されません。Weblogic Serverのロールとプリンシパルが使用されます。 |
|
|
権限受領者 |
5351 |
ポリシーのプリンシパルは権限受領者として格納されます。2つのアプリケーションの1つのプリンシパルに対して1つのポリシーです。 |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,cn=jaas policy,cn=grantees,'; |
|
権限 |
1772 |
ポリシーで使用されるリソース・アクションのペア。 |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,cn=jaas policy,cn=permissions,'; |
|
リソース |
3173 |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,%cn=resources,'; |
|
|
資格 |
1806 |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,%cn=permission sets,'; |
|
|
ポリシー |
5351 |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,%cn=policies,'; |
|
|
ルール |
5351 |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,%cn=rules,'; |
|
|
属性 |
1,484,356 |
前述のエントリの属性 |
select count(*) from jps_attrs where jps_dn_entryid in (select entryid from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,%'); |
|
割当て先の属性 |
1,220,877 |
ポリシー割当ての属性 |
select count(*) from ct_9_1 where jps_dn_entryid in (select entryid from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,cn=jaas policy,cn=permissions,'); |
前述のポリシー・データ・サンプルの場合、次に示すように、サンプル・ランタイム・キャッシュのメモリー・サイズを計算できます。
表15-6 ポリシー・データのサンプル・ランタイム・キャッシュのメモリー・サイズ
| キャッシュ・タイプ | 合計ヒープ・サイズ | 計算式 |
|---|---|---|
|
リソース・ポリシー・キャッシュ |
476.91M |
0.4K * 割当て先数 |
|
権限キャッシュ |
143.78M |
0.12K * 割当て先数 + 0.41K * 権限数 |
|
リソース・キャッシュ |
0.13M |
44 * リソース数 |
|
ポリシー・キャッシュ |
1.46MB |
286 * ポリシー数 |
|
リソース・タイプ・キャッシュ |
小さいキャッシュのため、無視されます。 |
|
|
関数キャッシュ |
小さいキャッシュのため、無視されます。 |
|
|
属性キャッシュ |
小さいキャッシュのため、無視されます。 |
|
|
AppRoleキャッシュ |
使用不可 |
|
|
ロール・ポリシー・キャッシュ |
使用不可 |
ポリシー配布は、データベースのポリシー・ストアからポリシー・データを取得し、ポリシー・データをローカルの暗号化済XMLポリシー・ファイルに書き込み、ランタイム・ポリシー・キャッシュの2つのコピーの間で切り替えるプロセスです。
OESセキュリティ・モジュールモジュールは、次のような状況でメモリーを使用します。
メモリー内のポリシー・データをキャッシュとして保持する場合。ランタイム・ポリシー・キャッシュのメモリーのサイズ設定の式に関する項を参照してください。セキュリティ・モジュールの起動後、ポリシー・キャッシュ・データは常にメモリー内にあります。サイズはポリシー・データに基づき、静的に予測可能です。単一のセキュリティ・モジュールにバインドされたアプリケーション・ポリシーが複数存在する可能性があります。したがって、メモリー・サイズはバインドされたアプリケーションの数をかけて計算する必要があります。
認可プロセスのメモリーを使用する場合。ここでは、動的でリクエストの頻度に影響されます。認可プロセスの終了後、メモリーはGCできます。この部分では分析はありません。想定されるバッファ = 1.5 * ランタイム・キャッシュ
ポリシーを配布する場合。ポリシー配布は、データベースのポリシー・ストアからポリシー・データを取得し、ポリシー・データをローカルの暗号化済XMLポリシー・ファイルに書き込み、ランタイム・ポリシー・キャッシュの2つのコピーの間で切り替えるプロセスです。
フラッシュの配布が初めて発生するか、セキュリティ・モジュールに選択されない多数の変更があります。
PDPにポリシーがすでに配布されていて、小さなサイズ変更がポリシー・ストアで発生している場合、増分配布が発生します。
通常の認可メモリー要件は、(1) + (2) = 2.5* ランタイム・キャッシュとして計算されます。
フラッシュ・ポリシー配布を取得するための初期化時間は、[[ランタイム・キャッシュ] * ( 2 + 3.67 * アプリケーション数) * 1.2 * 1.33] + 256 MBとして計算されます。
フラッシュ配布にはより多くのメモリーが必要なので、[[ランタイム・キャッシュ] * ( 2 + 3.67 * アプリケーション数) * 1.2 * 1.33] + 256 MB式を使用して、PDP用の推奨メモリー・サイズを計算します。
アプリケーション数は、セキュリティ・モジュール・インスタンスにバインドされたアプリケーション数です。
ポリシー・アーティファクトに基づいたランタイム・ポリシー・キャッシュのメモリー・サイズ設定
OES認可ポリシー・アーティファクトがビジネス・セキュリティ要件に基づいてユーザーによって作成されます。ポリシー・アーティファクトは、データベース・セキュリティ・ストアに保存され(1)、様々なタイプのセキュリティ・ストア間で移行され(XMLファイルベースまたはRDBMSベース)(2)、管理サーバーを介して顧客によって管理および配布され(3)、OESセキュリティ・モジュールによって使用されたポリシー・キャッシュとしてメモリーにロードされます(4)。
ポリシー・アーティファクトを次にリストします。
表15-7 ポリシー・アーティファクト
| ポリシー・アーティファクト | 説明 |
|---|---|
|
リソース・タイプ |
リソース・タイプは、保護されたオブジェクトのタイプを表します。小さいサイズのメタデータ。 |
|
リソース |
リソースは保護されたコンポーネントまたはオブジェクトであり、これに対してアクセス権が付与または拒否されます。 数値は大きくなる可能性があります。 |
|
リソース属性 |
リソースに割り当てられた属性値。 |
|
関数定義 |
組込み関数のメタデータおよびカスタム・プラグイン関数。 小さいサイズのデータ。 |
|
属性定義 |
属性宣言のメタデータ。小さいサイズのデータ。 |
|
アプリケーション・ロール |
|
|
アプリケーション・ロール・メンバー |
|
|
ロール・マッピング・ポリシー |
アプリケーション・ロールを特定のリソースおよび特定の条件でユーザー、グループに割り当てるポリシー。 |
|
資格 |
タスクの実行に必要な小さいリソース・セットおよび関連アクション。 |
|
プリンシパル |
ポリシーで使用されるユーザー、グループまたはアプリケーション・ロール。数値は大きくなりますが、様々なカスタマ・アプリケーションと異なることがあります。 これはIDストアでの合計ユーザー/グループのサブセットです。 |
|
権限 |
ポリシーで使用されるリソースおよび関連アクション。数値は大きくなりますが、様々なカスタマ・アプリケーションと異なることがあります。 |
|
割当て |
合計リソース数 * すべてのポリシーのプリンシパル。 |
|
認可ポリシー |
認可ポリシー 数値は大きくなります。 各ポリシーのサイズは、複雑な条件および複数の責任が含まれていることがあるため、異なる可能性があります。 複雑なポリシーの場合、サイズ設定に係数が必要です。 |
ランタイム・ポリシー・キャッシュは、OES認可ポリシーのメモリー表現です。サイズはポリシー・アーティファクト数に基づいて設定されます。
計算式の詳細:
(0.42K * 割当て先数) + (0.12K * 割当て先数 + 0.41K * 権限数)+( 286 * ポリシー数)+( 44 * リソース数) + (0.26 * 権限受領者数) + (0.69K * 権限受領者数) + (0.85k * ポリシー数)
最終的な計算式:
= 0.54K * 割当て数 +
0.41K * 権限数 +
0.72K * 権限受領者数 +
0.044K * リソース数 * リソース属性係数 +
0.85K * ポリシー数 * ポリシー係数
0.122K * 合計アプリケーション・ロール・メンバーシップ数
リソース属性がない場合、リソース属性係数は1にデフォルト設定されています。
条件および責任がないポリシーの場合、ポリシー係数は1にデフォルト設定されています。
次に示すように、DOMAIN_HOME/bin/startWeblogic.shスクリプトとすべてのJVMパラメータを編集します。これらの行が"${JAVA_HOME}/bin/java ${JAVA_VM} -version"の行の前にあることに注意してください。:
JAVA_HOME="/scratch/example_user/tools/jdk1.6.0_31" /home/user/jdk1.6.0_31 MEM_ARGS="-Xms6144m -Xmx6144m -Xmn1900m -XX:PermSize=128m -XX:MaxPermSize=1024m -XX:+UseParallelGC "
説明:
-Xms6144m -Xmx6144m: JVMに使用できる初期メモリー・サイズおよび最大メモリー・サイズがそれぞれ選択されます。これらの値はJVMヒープ用に使用されます。これは、配布時にランタイム・キャッシュおよび一時的なポリシー・データ用のメモリーを予約します。
このパラメータを適切にチューニングすると、ガベージ・コレクションのオーバーヘッドが削減され、応答時間およびスループットが改善されます。この値が低すぎると、OutOfMemoryエラーまたはマイナー/完全ガベージ・コレクションが発生します。
-XX:PermSize: 永続的な生成データに使用可能な初期メモリー・サイズが選択されます。128MBを指定すると、ほとんどのシナリオについて、この部分のヒープを増加させるオーバーヘッドがなくなります。
-XX:MaxPermSize: 永続的な生成の最大サイズが選択されます。1024MBを指定すると、大きなカスタム権限がある場合に、OutOfMemoryErrorが発生しなくなります。
-XX :+UseParallelGC: スカベンジにパラレル・ガベージ・コレクションが使用されます。このコレクション・アルゴリズムは、スループットを最大化するように設計されています。同時に、休止を最小限に抑えるため、セキュリティ・モジュールに適したGCアルゴリズムです。
次に示す、すべてのJVMパラメータを最後の行に追加して、OES_CLIENT_HOME/oes_sm_instances/SM_NAME/run-j2se.shスクリプトを編集します。
${JAVA_HOME}/bin/java -Xms6144m -Xmx6144m -Xmn1900m -XX:PermSize=128m -XX:MaxPermSize=1024m -XX:+UseParallelGC -Doracle.security.jps.config=./config/jps-config.xml
-classpath ./: ./sm-config-tool.jar oracle.security.oes.tools.OESJ2SESampleApp PD
次に示すように、すべてのJVMパラメータを追加して、OES_CLIENT_HOME/oes_sm_instances/SM_NAME/startWSServer.shスクリプトを編集します。最後のJAVA_OPT行の後にプロパティを追加することに注意してください。
JAVA_OPT="$JAVA_OPT -Xms6144m -Xmx6144m -Xmn1900m -XX:PermSize=128m -XX:MaxPermSize=1024m -XX:+UseParallelGC"
PDPサービス構成の場合、表15-8を参照してください。この表に、Webサービス・セキュリティ・モジュールのパラメータがリストされています。
表15-8 Webサービス・セキュリティ・モジュール・パラメータ
| Webサービス・セキュリティ・モジュール・パラメータ | 説明 |
|---|---|
|
oracle.security.jps.pdp.sm.IdentityCacheEnabled |
アイデンティティ・キャッシュを使用している場合に設定されるフラグ。設定されない場合、デフォルトでアイデンティティ・キャッシュは有効にされます。 |
|
oracle.security.jps.pdp.sm.IdentityMaxCacheSize |
最大キャッシュ・サイズを指定します。 デフォルト値は20000です。 すべてのサブジェクトの数に応じて、このパラメータをチューニングします。 |
|
oracle.security.jps.pdp.sm.IdentityCacheEvictionPercentage |
キャッシュが最大サイズに達したときに削除する必要があるアイデンティティの比率を指定します。 デフォルト値は20%です。 |
|
oracle.security.jps.pdp.sm.IdentityCachedEntryTTL |
キャッシュ内のアイデンティティ・レコードの存続時間を秒数で指定します。 デフォルト値は3600秒です。 |
|
oracle.security.jps.pdp.wssm.WSLoggingSoapHandlerEnabled |
Webサービス・セキュリティ・モジュールのEnvelopLoggingSOAPHandlerを有効にしている場合に設定するフラグです。 デフォルト値はfalseです。 |
PDPサービス構成の場合、次のプロパティを追加します。
oracle.security.jps.pd.client.PollingTimerInterval:
このプロパティは、PDの定期的な確認の間隔を指定します。デフォルト値は600秒です。ポリシー・データの変更頻度に合せて、設定値を増減できます。
デフォルトの属性リトリーバをキャッシング用にチューニングできます。
詳細は、B.3項「事前定義済属性リトリーバの手動構成」を参照してください。B.3.2項「個々の属性値の構成」の手順は、プロパティ"ttl" (cachedが有効化されている場合、cached属性値の存続時間"ttl"(秒))および"cached" (属性値のキャッシングを有効化)を使用しています。
認可決定キャッシングによって、Oracle Entitlements Serverは、同一コールが行われると、認可コールの結果をキャッシュし、その決定を今後使用できます。
セキュリティ・モジュールの決定キャッシュに対して、PDPのjps-config.xmlファイルで、次のプロパティを設定します。
<property name="oracle.security.jps.pdp.AuthorizationDecisionCacheEnabled" value="true"/> <property name="oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionCapacity" value="1500"/> <property name="oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionPercentage" value="10"/> <property name="oracle.security.jps.pdp.AuthorizationPerUserDecisionCacheSize" value="1500"/> <property name="oracle.security.jps.pdp.AuthorizationDecisionCacheTTL" value="300"/>
表15-9に、前述の構成の詳細を示します。
表15-9 OESキャッシュのチューニング時の構成例
| プロパティ | 説明 | デフォルト値 | 推奨 |
|---|---|---|---|
|
oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionCapacity |
これは、決定キャッシュ・サイズがこのサイズに達した場合に決定キャッシュを削除するのに使用する数です。 |
500 |
認可リクエストを行っている同時ユーザーの数に応じて、このパラメータをチューニングします。 |
|
oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionPercentage |
決定キャッシュが最大容量に達した場合に削除する認可決定の比率。 |
10 |
|
|
oracle.security.jps.pdp.AuthorizationPerUserDecisionCacheSize |
これは、第2レベルの決定キャッシュ・サイズがこのサイズに達した場合に各ユーザー(サブジェクト)の決定キャッシュを削除するのに使用する数です。 すべてのサブジェクトの数に応じて、このパラメータをチューニングします。 |
1000 |
1人のユーザーに対してキャッシュされる認可結果の数 |
|
oracle.security.jps.pdp.AuthorizationDecisionCacheTTL |
これは決定キャッシュのTTL (秒)です。 |
60秒 |
PepRequestFactory.newQueryPepRequest().decide()を使用して、制御された配布モードでセキュリティ・モジュール・インスタンスの多数の子リソース(100より多い場合など)についてアクセスを問い合せます。
この機能はデフォルトでは無効化されていますが、制御された配布モードにあるセキュリティ・モジュール・インスタンスに対して有効にできます。
これを有効にするには、セキュリティ・モジュールのjps-config.xmlファイルを更新し、PDPサービス・インスタンスに対して次のプロパティを追加します。
<serviceInstance name="pdp.service" provider="pdp.service.provider">
…. ….
<property name="oracle.security.jps.runtime.enableResourcePermissionCache" value="true"/>
この項には次のトピックが含まれます:
移行、スナップショット生成および配布を含む一部の主要な操作では、パフォーマンス測定用にログが必要になります。
WLSTを介した移行では、INFOレベルのログがあります。タイムスタンプ付きのログをWLSTコンソールに直接出力できます。次の例を参照してください。
Apr 19, 2013 3:07:00 AM oracle.security.jps.internal.tools.utility.JpsUtilMigrationPolicyImpl migrateAppPolicyData INFO: Migration of Application Policies in progress..... … … Apr 19, 2013 3:07:39 AM oracle.security.jps.internal.tools.utility.util.JpsMigrateUtil cloneResourceType INFO: Migration of Resources started Apr 19, 2013 3:08:12 AM oracle.security.jps.internal.tools.utility.util.JpsMigrateUtil cloneResourceType INFO: Migration of Resources completed in 00:00:33 … … Apr 19, 2013 3:08:44 AM oracle.security.jps.internal.tools.utility.util.JpsMigrateUtil clonePermissionSet INFO: Migration of Permission Sets completed in 00:00:31 … … Apr 19, 2013 3:11:35 AM oracle.security.jps.internal.tools.utility.destination.apibased.JpsDstPolicy clone INFO: Completed Migrating 5,351 policies in [170,914] ms. … … Apr 19, 2013 3:20:57 AM oracle.security.jps.internal.tools.utility.destination.apibased.JpsDstPolicy clone INFO: Migration of Grants completed in 00:09:22 … … Apr 19, 2013 3:20:57 AM oracle.security.jps.internal.tools.utility.JpsUtilMigrationPolicyImpl migrateAppPolicyData INFO: Migration of Application Policies completed, Time taken for migration is 00:13:57
次に示すログ・レベル設定で、Javaのlogging.propertiesファイルを作成します。
handlers= java.util.logging.FileHandler .level= INFO ############################################################ # Handler specific properties. # Describes specific configuration info for Handlers. ############################################################# default file output is in user's home directory. java.util.logging.FileHandler.pattern =<Log_home>/performance.log java.util.logging.FileHandler.limit = 10000000 java.util.logging.FileHandler.count = 200 java.util.logging.FileHandler.formatter =java.util.logging.SimpleFormatter java.util.logging.FileHandler.level = FINE java.util.logging.ConsoleHandler.level = INFO java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter ############################################################ # Facility specific properties. ############################################################ # Provides extra control for each logger. ############################################################ # For example, set the com.xyz.foo logger to only log SEVERE # messages: oracle.security.jps.internal.policystore.SnapshotWorker.level=FINEST
ログを有効にするには、次のように、DOMAIN_HOME/bin/startWeblogic.shスクリプトを編集します。
${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} -Djava.util.logging.config.file=./logging.properties
-Dweblogic.Name=${SERVER_NAME}
-Djava.security.policy=${WL_HOME}/server/lib/weblogic.policy ${JAVA_OPTIONS} ${PROXY_SETTINGS} ${SERVER_CLASS}
スナップショットがアプリケーション・ポリシーに対して生成されると、ログ・ファイルから次のログ・メッセージが示されます。
Jan 31, 2013 1:07:49 AM oracle.security.jps.internal.policystore.SnapshotWorker run FINE: SnapshotWorker begin. ............... Jan 31, 2013 1:12:43 AM oracle.security.jps.internal.policystore.SnapshotWorker run FINE: SnapshotWorker end.
前述の項のように、logging.propertiesファイルを作成し、次の行を追加します。
oracle.security.jps.az.internal.runtime.pd.receiver.UpdatePolicySet.level=FINEST
各セキュリティ・モジュール・タイプに応じて異なるスクリプトを更新する必要があります。
Javaセキュリティ・モジュール
Javaセキュリティ・モジュールの起動スクリプトを編集し、ログ・プロパティを追加します。例として、OES_CLIENT_HOME/oes_sm_instances/SM_NAME/run-j2se.shを参照します。
${JAVA_HOME}/bin/java -Doracle.security.jps.config=${OES_INSTANCE_HOME}/config/jps-config.xml
${MEM_ARGS} -Djava.util.logging.config.file=./config/logging.properties oracle.security.oes.tools.OESJ2SESampleApp PD
ログ・プロパティ・ファイルで次を有効にします。
oracle.security.jps.az.internal.runtime.pd.receiver.UpdatePolicySet.level=FINEST
Webサービス・セキュリティ・モジュール
OESCLIENT/oes_sm_instances/wssm/startWSServer.shスクリプトで、次の行を追加します。
JAVA_OPT="$JAVA_OPT -Djava.util.logging.config.file=./config/logging.properties".
WebLogicセキュリティ・モジュール
最後に次の内容で、DOMAIN_HOME/bin/startWeblogic.shスクリプトを編集します。
${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} -Djava.util.logging.config.file=./config/logging.properties
Tomcatセキュリティ・モジュール
最後のJAVA_OPTS行に次の行を追加して、TOMCAT_HOME/ bin/catalina.shスクリプトを編集します。
JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.config.file=./config/logging.properties".
ログ・メッセージ
タイムスタンプ付きのログ・メッセージを使用して、ポリシー配布に費やした時間("starting"から"afterCommit finished"まで)を取得できます。次にメッセージ例を示します。
Jan 31, 2013 10:11:19 PM oracle.security.jps.az.internal.runtime.pd.receiver.UpdatePolicySet commit FINE: Starting ... .......... Jan 31, 2013 10:20:06 PM oracle.security.jps.az.internal.runtime.pd.receiver.UpdatePolicySet commit FINE: completed. Active Apps: [[]], Bounded Apps [[FinanceApp]] Jan 31, 2013 10:20:07 PM oracle.security.jps.az.internal.runtime.pd.receiver.UpdatePolicySet commit FINE: afterCommit is finished Jan 31, 2013 10:20:07 PM oracle.security.jps.az.internal.runtime.pd.receiver.UpdatePolicySet finishFirstDist
