CA Directory をセッション ストアとして設定する方法
以下の手順を完了して、CA Directory をセッション ストアとして設定できます。
casso11jp
以下の手順を完了して、CA Directory をセッション ストアとして設定できます。
2
この手順は、CA Directory がインストールされ、動作中であることを前提としています。
このトピックでは、以下の規則を使用します。
- DXHOME= C:\Program Files\CA\Directory\dxserver (Windows)
- DXHOME=/opt/CA/Directory/dxserver (UNIX)
セッション ストア スキーマ ファイルの検出
セッション ストアで、ポリシー サーバは独自の LDAP ディレクトリ オブジェクトを使用します。CA Directory は、これらの追加クラスの構造について認識しておく必要があります。セッション ストア スキーマ ファイル netegrity.dxc によって、CA Directory はこれらの追加クラスの名前および構造を知ることができます。
netegrity.dxc
ファイルは、ポリシー サーバと共にインストールされます。正しいスキーマ ファイルがあることを確認します。以下の手順に従います。
- ディレクトリsiteminder_home\eTrust に移動します。ここで、siteminder_homeはポリシー サーバのインストール パスを指定します。
- スキーマ ファイルnetegrity.dxcがあることを確認します。このファイルは、DSA セッション ストア スキーマを作成します。このスキーマにより、DSA はユーザ セッション情報を格納および取得できます。このファイルがいない場合は、Single Sign-On管理者に連絡し、リクエストしてください。
セッション ストア用の Directory System Agent (DSA)を作成します。
DSA を作成し、それをセッション ストア専用にします。専用 DSA は、セッション ストアのパフォーマンスを最大化するのに役立ちます。
以下の手順に従います。
- CA Directory ホスト システムにログインします。
- 以下のコマンドを実行して、データ DSA を作成します。dxnewdsadsa_name port prefix
- dsa_nameは、セッション ストア DSA の名前を指定します。
- portは、セッション ストアがリクエストをリスンする必要があるポートを指定します。
- prefixは、ネームスペース プレフィクスを指定します。プレフィックスを指定するために LDAP 構文を使用します。
例:dxnewdsa smsessionstore 1234 o=forwardinc,c=usForwardinc は架空の会社名です。この名前は、説明のためのみに使用され、現存する会社への言及を意図するものではありません。
DSA が作成されます。
セッション ストア スキーマの作成
DSAでは、ユーザ セッション情報を格納および取得するためにスキーマが必要です。
以下の手順に従います。
- CA Directory ホスト システムにログインします。
- 以下のコマンドを使って、DSA を停止します。dxserver stopDSA_nameDSA_nameは、DSA に割り当てる名前です。
- netegrity.dxcファイルをsiteminder_home\eTrust からコピーします。
- DXHOME\config\schema に移動し、netegrity.dxcをディレクトリに貼り付けます。
- 以下の手順でスキーマ ファイルを作成します。
- デフォルトの DSA スキーマ ファイル(default.dxg)をコピーします。default.dxg ファイルはスキーマ ディレクトリ内にあります。
- コピーから読み取り専用属性を削除します。
- コピーの名前を変更して、新しいファイルを作成します。たとえば、コピーの名前を smsession.dxg に変更します。
- 新しい スキーマ ファイルの末尾に、以下の行を追加します。#CA Schemasource "netegrity.dxc";
- ファイルを保存します。
- 新しいスキーマ ファイルに読み取り専用属性を再適用します。
DSA 上のセッション ストアの制限の設定
セッション ストア スキーマでは、セッション ストア デフォルト制限を設定します。この制限によって、アプリケーションが DSA と接続状態にある期間や検索クエリの制御方法などの DSA 操作を定義します。
以下の手順に従います。
- DXHOME\config\limits に移動します。
- 以下の手順を完了して、セッション ストア制限ファイルを作成します。
- デフォルト制限ファイル(default.dxc)をコピーします。
- 読み取り専用属性を削除します。
- smsession.dxc などのように、ファイル名を変更します。
- smsession.dxcファイルのサイズ制限セクションで、以下の例に一致するようにmax-opsを設定します。この値は、上限を表します。セッション ストアでは、検索クエリ当たり 1,000 を超えるオブジェクトを返すことが想定されていません。set max-op-size = 1000;
- multi-write queue設定を設定します。マルチライト キューの設定は、使用不能な DSA のメモリに保持されるトランザクションの最大数を指定します。指定した期間オフラインになっているサーバをサポートするには、この設定を使用します。デフォルト値は 20,000 です。処理するキューを 300,000 から 500,000 トランザクションの間に設定します。最適値は、マルチライト キューを使用せずに、ディレクトリ サーバ ホストのいずれかの通常の再起動を許可します。例: <nete:proxyrules xmlns:nete="http://www.ca.com/" debug="yes">set multi-write-queue = 300000;
- multi-write-outstanding-ops limits設定を設定します。この設定によって、DSA がそのマルチライト キューからリカバリする DNA へ一度に送信できる更新の数が決まります。デフォルトは 10 です。マルチライト キュー内の潜在的な更新の数に基づいて、デフォルトで一度に 10 個の更新を送信する DSA は、DSA の自動回復を延長します。推奨値は 1000 です。例: <nete:proxyrules xmlns:nete="http://www.ca.com/" debug="yes">set multi-write-outstanding-ops = 1000;
- ファイルを保存します。
- 読み取り専用属性を再適用します。
セッション ストア初期化ファイルの編集
初期設定ファイル (
dsa_name
.dxi) には、以下の機能を設定するための設定などがあります。- インデックスCA Directory インデックスの最適化は、CA Directory の全体的なパフォーマンスにとって重要です。インデックスを正しく設定しない場合、追加および削除操作に関して、応答時間がより遅延する可能性があります。cache-indexエントリで、インデックス付けが必要な属性を指定します。
- セッション オブジェクトのメモリへの格納
- トランザクション ログ記録デフォルトでは、各 CA Directory のデータ DSA は、トランザクション ログを使用するように設定されます。セッション ストアには、トランザクション ログは必要ありません。これは、ディレクトリのパフォーマンスに悪影響を及ぼす可能性があります。そのため、ログ記録を無効にします。
以下の手順に従います。
- DXHOME\config\servers に移動し、.DSA_namedxiという名前のセッション ストア初期設定ファイルを開きます。DSA_nameは、セッション ストア DSA の名前を指定します。
- [#schema]セクションで、スキーマの参照を default.dxg から新しいファイルに変更します。例:default.dxg を smsession.dxg に変更します。
- [#service 制限]セクションで、サービス制限への参照を default.dxc から新しいファイルに変更します。例:default.dxc を smsession.dxc に変更します。
- #grid 設定セクションで、以下のテキストと一致するように、set cache-indexエントリを編集します。set cache-index = smSessionId, smExpirationTime, smIdleExpirationTime, smSearchData, smVariableName, smFullVariableName;以下の例のように、set cache-indexエントリがset lookup-cacheエントリより上にあることを確認します。set cache-index = smSessionId, smExpirationTime, smIdleExpirationTime, smSearchData, smVariableName, smFullVariableName;set lookup-cache = true;
- (オプション)より多くのセッション オブジェクトをメモリに格納するには、以下のコマンドを使用して、smVariableValue 属性を圧縮します。set compresstype=smVariableValueここで、typeは以下の値のいずれかです。base64、hex、deflate、deflate1、deflate2。deflate タイプは最も速く、deflate1 は速度と圧縮のバランスを取り、deflate2 は最大の圧縮を試行します。指定された属性のすべての値が base64 でエンコードされている場合は、base64 のみを使用します、16 進数タイプを指定するのは、指定された属性のすべての値が 16 進数でエンコードされている場合のみです。属性値が base64 または hex 以外の任意のタイプでエンコードされている場合は、deflate タイプのいずれかを使用します。
- multi-write-disp-recovery設定がデフォルト設定の false に設定されていることを確認します。このセッション ストアには、この回復方式は不要です。以下の例では、正しいエントリが表示されています。set multi-write-disp-recovery = false;ルーティング DSA では、この設定は必要ありません。複数の DSA ピアを設定し、マルチライト レプリケーションを使用できますが、DISP 回復でこの機能を使用しないでください。レプリケーションの設定手順については、CA Directory のドキュメントを参照してください。
- (オプション)パフォーマンスを改善するためにトランザクション ロギングを無効にします。このパラメータはデフォルトで有効になっています。ログ記録を無効にするには、各初期化ファイルに以下の設定を追加します。set disable-transaction-log = true;ログ記録エントリを、エントリ セット multi-write-disp-recovery = false の下に配置します。例: <nete:proxyrules xmlns:nete="http://www.ca.com/" debug="yes">set multi-write-disp-recovery = false;set disable-transaction-log = true;トランザクション ログ記録の無効化は、ルーティング DSA では必要ありません。トランザクション ロギングを無効にした場合のデータ回復への影響を考慮してください。詳細については、CA Directory のマニュアルを参照してください。
- (オプション)セッション ストア DSA がレプリケートされる場合は、dsp-idle-time 設定を DSAナレッジファイル(DXHOME/config/knowledge/)に追加します。アイドル時間が低すぎないようにするために、アイドル時間を設定すると便利です。この設定が低すぎると、DSA がリカバリされる前に、マルチライト DSA とそのリカバリ対象ピア DSA の間のリンクがタイムアウトになる可能性があります。dsp-idle-time = 30
- 以下のコマンドを使って、DSA を再起動します。dxserver startDSA_Name
セッション ストア スキーマが設定されます。
セッション ストアのバックアップ不要
セッション ストア内のデータは常に変化するため、セッション ストアをバックアップする必要はありません。従って、リストアされたデータは古く、不正確である可能性があります。
非同期レプリケーション
同じディレクトリ情報が複数のサーバに格納されるように、DSA レプリケーションを設定できます。ディレクトリ サーバの可用性を改善するようにレプリケーションが展開されるため、アプリケーションは処理を継続できます。また DSA 間の負荷分散を有効にすることで、レプリケーションはパフォーマンスを改善できます。
CA Directory のセッション ストアは、大量の更新リクエスト(変更/追加/削除)を処理できます。ローカル ストアを含むすべての DSA セッション ストアでレプリケーション設定を最適化するには、レプリケーションを非同期に設定します。非同期に送信された更新はスレッドを開放するために、スレッドは検証を待つことなく、リクエストの処理を継続できます。そのため、レプリケーションのパフォーマンスは効率的です。
以下の手順に従います。
- DSA 上のDXHOME/config/knowledge/ に移動します。
- すべての DSA のナレッジ設定で、オプションmulti-write-asyncを dsa-flag として設定します。例: <nete:proxyrules xmlns:nete="http://www.ca.com/" debug="yes">[ dsa-flags = multi-write-async, no-service-while-recovering ]
セッション ストアを管理するポリシー サーバを有効にします。
ポリシー サーバ ストアでセッション ストアを管理するには、以下のタスクを完了します。
- セッション ストア管理ユーザを DSA に追加します。
- セッション ストア用のルート DN を確立します。
- ポリシー サーバがそのセッション ストアを参照するように指定します。
DSA に対して、セッション ストア管理ユーザおよびルート DN を追加します。
ポリシー サーバでセッション ストアを管理するには、以下の情報が必要です。
- DSA 内のユーザの完全な識別名(DN)およびパスワード。ポリシー サーバではこれらの認証情報を使用して、セッション ストアを管理します。
- セッション情報を書き込むことができるルート DN。
以下の手順に従います。
- 以下のいずれかの方法で匿名の認証を使用して、DSA にアクセスします。
- JXplorer ツールを使用します
- CA Directory コマンド ライン インターフェースを使用します。
- ポリシー ストアがセッション ストアの管理に使用できるユーザを作成します。
- 必ず、以下の OBJECT CLASS:inetOrgPersonのみを持つユーザを作成してください。
- 認証情報を書き留めます。認証情報は、ポリシー サーバがそのセッション ストア DSA を参照するように指定するために必要です。
- JXplorer から切断します。
- JXplorer を起動します。
- DSA にアクセスできることを確認するために、作成した管理ユーザの完全な DN を使用して、DSA にログインします。例:cn=admin,o=forwardinc,c=us
- セッション ストアのルート DN として機能する組織単位を手動で作成します。Example:ou=sessionstore
- JXplorer から切断します。
注:
セッション ストアへの不正なアクセスを防ぐために、匿名認証は無効にすることをお勧めします。ポリシー サーバがセッション ストアを参照するように指定
ポリシー サーバがセッション ストア DSA を参照するように指定して、ポリシー サーバでセッション ストアを管理できるようにします。
以下の手順に従います。
- ポリシー サーバ管理コンソールを開きます。casso11jp重要:Windows サーバ上で、ユーザ アカウント制御 (UAC) が有効な場合は、管理者権限でショートカットを開きます。管理者としてシステムにログインしている場合でも、管理者権限を使用します。詳細については、お使いのSingle Sign-Onコンポーネントの「リリース ノート」を参照してください。
- [データ]タブをクリックします。
- [データベース]リストからセッション ストアを選択します。
- [ストレージ]リストから CA Directory を選択します。
- [セッション ストアが有効です]オプションを選択します。
- [LDAP セッション ストア]セクションで、以下の操作を実行します。
- セッション ストア DSA の IP アドレスとポートを入力します。
- セッション ストア DSA の ルート DN を入力します。例:ou=sessionstore,o=fowardinc,c=us
- DSA 内の管理ユーザの完全な DN を入力します。例:cn=admin,o=forwardinc,c=us
- 管理ユーザのパスワードを入力します。
- [LDAP 接続のテスト]をクリックして、接続を検証します。
- [OK]をクリックします。
- ポリシー サーバを再起動します。
ポリシー サーバはセッション ストアを管理するように設定されます。
セッション ストアのパフォーマンスの最適化
ご使用の環境で高いパフォーマンスが必要な場合は、以下の推奨事項を考慮してください。
- CA Directory はネームスペースの分割をサポートしていて、これによって、複数の DSA 間で単一 OU のデータを分割できます。これは、より多くの DSA に LDAP リクエスト ロードの処理を許可することで、パフォーマンスの大きな影響を及ぼす可能性があります。データの分割によって、単一ホスト上の追加 CPU や複数のホスト上の CPU など、すべての利用可能なハードウェアを利用できます。レプリカの数が多いほど、ディレクトリへの並行書き込みが増えます。ご使用の環境で、既存のホストまたは活用されていない他のホスト上に CPU またはコアがある場合は、CA Directory ネームスペースの分割設定を検討してください。
- すべてのセッション ストア属性にインデックスを付けることはしません。セッション データに多数のインデックスを設定すると、削除のパフォーマンスが低下します。展開で使用されるセッション ストア属性のみにインデックスを付けます。展開でどのインデックスを使用するかについては、CA Directory のドキュメントを参照してください。
- パーティションを使用しますが、各パーティションは別々のホストに配置します。
- 各ホストのすべての CA Directory サーバのデータ ファイルを格納するための十分な物理メモリを許可します。ホストには、物理システムまたはゲスト インスタンスを指定できます。CA Directory サーバ インストールのデータ ディレクトリに、データ ファイルのサイズを表示できます。
- DSA の初期化ファイル(dsa_name.dxi)で、以下のエントリを確認します。このファイルは、ディレクトリDXHome/config/servers に存在します。これらのエントリがファイルにない場合は、それらを追加します。
- 以下のコマンドをサーバ ファイルに追加して、CA Directory のトランザクション ログ記録を無効にします。# disable transaction logging for performanceset disable-transaction-log = true;set disable-transaction-log-flush = true;注:サービスの中断がある場合は、レプリケーションを有効にせずにトランザクションのログ記録を無効にするには、ユーザが再度ログインする必要があります。
- dxgrid-queue コマンドを追加することにより、デフォルトの単一キューを使用します。このコマンドの設定は、デフォルトでは true です。以下に例を示します。# use single queue in front of DSA instead of# one queue per threadset dxgrid-queue = true;
接続プール
接続プールは、将来データベースへのリクエストが必要な場合に接続が再利用できるように維持されるデータベース接続ハンドルのキャッシュです。ポリシー サーバは接続プール(デフォルトでは、10 個の LDAP 接続ハンドルの)を使用して、セッション ストアのパフォーマンスを向上させます。
ただし、セッション ストア接続ハンドルが必要な平行スレッドが多すぎる場合は、接続プールの処理能力を超えて、スレッド キューが作成される場合があります。この問題を診断するため、LDAP ハンドルがロックされる前に、ポリシー サーバ プロファイラ ログで遅延があるリクエストを検索してください。このような遅延は、セッション ストア接続数を増やす必要があることを示します。
たとえば、プロファイラ ログの以下の抜粋は、ワーカ スレッド ID 3003599728 が LDAP 接続ハンドルを取得する前に 2 秒間待機することを示しています。
[13:23:38.671][26918][3003599728][Leave function CSm_Auth_Message::SetAuthContext][Sm_Auth_Message.cpp:4280][CSm_Auth_Message::SetAuthContext][13:23:40.671][26918][3003599728][Lock LDAP handle. slot=0 ld=0xb3071fe0][LdapStore.cpp:375][Lock_LdapHandle]
(この遅延は、メッセージのタイムスタンプの 2 秒の差で示されます。これは、太字で示されています)。
セッション ストア接続プールのサイズを大きくするには、MaxConnections レジストリ設定の値を変更します。このレジストリは、以下の場所にあります。
HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\LdapSessionServer=numeric_id
値:
16 進数の接続プール サイズ。例: 0xf (15)デフォルト:
0xa (10)注:
2 つのワーカ スレッドごとに少なくとも 1 つの接続ハンドルがあるように、最大ワーカ スレッド値の半分に近い値を設定します。この推奨値は、使用されるハードウェアおよびその他の環境要因に応じて異なります。パフォーマンスを最適化するために、テスト環境でこれらの設定をテストし、ご使用の環境に適合するように必要に応じて変更することをお勧めします。高ボリューム環境での期限切れになった余分なセッションの削除
CA Directory をセッション ストアとして使用するように設定されているポリシー サーバは、セッションの作成および期限切れになったセッションのクリーンアップを担当します。ポリシー サーバはユーザの認証時にセッションを作成し、次に定期的に期限切れになったセッションを検索し、それらを削除します。
高ボリューム環境では、CA Directory のセッション ストアが期限切れになった余分なセッションでいっぱいになる場合があります。この問題が発生した場合は、CA サポートで問題をオープンしてください。CA サポートによって SMDeleteSession ユーテリティが提供され、これによって期限切れになったセッションを継続的にチェックし、削除します。