| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
 次 |
この章では、プロキシ・インスタンスに固有のサーバー要素を構成する方法を説明します。これらの要素の多くは、プロキシ・インスタンスの設定時にロード・バランシングまたは分散トポロジを構成すると自動的に構成されることに注意してください。
この章では、次のトピックを取り扱います:
dsconfigコマンドの詳細は、第17.1項「dsconfigを使用したサーバー構成の管理」を参照してください。
ODSMの詳細は、第21章「Oracle Directory Services Managerを使用したOracle Unified Directoryへのアクセス」を参照してください。
dsconfigを使用したプロキシ構成の管理この項では、dsconfigコマンドを使用した、プロキシ構成を管理するための各プロシージャについて説明します。この項の内容は次のとおりです:
この項では、プロキシ・インスタンスと1つ以上のリモートLDAPサーバーとの通信を構成する方法を説明します。この項の内容は次のとおりです:
プロキシ・インスタンスとリモートLDAPサーバーとの通信には、次の2つの要素が関わっています:
LDAPサーバー拡張: この要素では、リモート・ピアからのレスポンスを定期的に確認し、接続プールで保持されている有効な接続を提供することによって、リモート・サーバーとの接続性が管理されます。
プロキシLDAPワークフロー要素: この要素では、LDAPサーバー拡張要素から接続が取得され、構成されているモードで定義されているとおりにユーザーから受け取った操作が実行されます。
この項では、リモートLDAPサーバーとの通信に必要なLDAPサーバー拡張を構成する方法を説明します。この項の内容は次のとおりです:
特定のプロキシ・インスタンスに構成されているLDAPサーバー拡張すべてを表示するには、次に示すように、dsconfig list-extensionsコマンドを使用します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ list-extensions
Extension : Type -----------:--------------------- gi-catalog : global-index-catalog proxy1 : ldap-server proxy2 : ldap-server
タイプがldap-serverの拡張が、LDAPサーバー拡張です。リモートLDAPサーバーごとに1つのLDAPサーバー拡張が指定されているはずです。
特定のLDAPサーバー拡張のプロパティを表示するには、次に示すように、dsconfig get-extension-propコマンドを使用します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
get-extension-prop --extension-name proxy1
Property : Value(s)
---------------------------:---------
enabled : true
remote-ldap-server-address : server1.example.com
remote-ldap-server-port : 1389
次のプロパティが表示されます:
enabledLDAPサーバー拡張が有効になっている(true)か、それとも有効になっていない(false)かを示します。
remote-ldap-server-addressおよびremote-ldap-server-portリクエストの転送先のリモートLDAPサーバーのアドレスおよびポートを示します。
monitoring-bind-dnおよびmonitoring-bind-passwordこれらのプロパティは、--advancedオプションが指定されている場合にのみ表示されます。データ・ソースの監視の実行に拡張で使用される、ユーザーの資格証明が示されます。これらのプロパティがデフォルトから変更されていない場合、これらのプロパティは表示されません。つまり監視は匿名で実行されます。これらのプロパティを構成するには、第32.5項「LDAPを使用したサーバーの監視」を参照してください。
LDAPサーバー拡張のすべてのプロパティを表示するには、dsconfig --advanced get-extension-propコマンドを使用します。例:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
--advanced get-extension-prop --extension-name proxy1
次のようなプロパティが表示されます。
Property Value(s)
----------------------------------------------------------------------
1) enabled true
2) java-class com.sun.dps.server.workflowelement
.proxyldap.LDAPServerExtension
3) monitoring-check-interval 30000
4) monitoring-connect-timeout 5000
5) monitoring-inactivity-timeout 120000
6) monitoring-ping-timeout 5000
7) pool-increment 5
8) pool-initial-size 10
9) pool-max-size 1000
10) pool-max-write 0
11) pool-release-connection-interval 300000
12) pool-use-max-write false
13) proxied-auth-use-v1 false
14) remote-ldap-server-address localhost
15) remote-ldap-server-connect-timeout 10000
16) remote-ldap-server-port 1389
17) remote-ldap-server-read-only false
18) remote-ldap-server-read-timeout 10000
19) remote-ldap-server-ssl-policy never
20) remote-ldap-server-ssl-port 636
21) saturation-precision 5
22) ssl-client-alias -
23) ssl-key-manager-provider -
24) ssl-trust-all false
25) ssl-trust-manager-provider -
|
注意: ほとんどの拡張プロパティ(SSLプロパティを除く)が、LDAPサーバー拡張の作成時にデフォルトで設定されます。 |
これらの値を変更するには、第18.1.1.2.5項「LDAPサーバー拡張のプロパティを変更するには」を参照してください。
監視プロパティの詳細は、第18.1.1.2.7項「LDAPデータ・ソースの接続監視プロパティ」を参照してください。SSL(セキュリティ)プロパティの詳細は、第24章「プロキシ/データ・ソース間のセキュリティ構成」を参照してください。
新規LDAPサーバー拡張を作成するには、次に示すように、dsconfig create-extensionコマンドを使用します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--extension-name DS-proxy5 \
--type ldap-server \
--set enabled:true \
--set remote-ldap-server-address:DS5-hostname
--set remote-ldap-server-port:1389
拡張のtypeはldap-serverである必要があります。新規拡張の名前は、extension-nameで定義します。この例では、DS-proxy5です。
作成している拡張を関連付けるリモートLDAPサーバーの名前も指定する必要があります(remote-ldap-server-address)。リモートLDAPサーバーのホスト名またはIPアドレスを指定できます。
remote-ldap-server-portを指定しないと、デフォルトのLDAPポート1389であると見なされます。
LDAPサーバー拡張のプロパティを変更するには、set-extension-propサブコマンドを使用します。このサブコマンドを使用すると、次の操作を実行できます:
LDAPサーバー拡張を有効にする(true)か、それとも有効にしない(false)かを設定できます。
リモートLDAPディレクトリ・サーバーのアドレスおよびポート(remote-ldap-server-addressおよびremote-ldap-server-port)を変更できます。
データ・ソースの監視の実行に拡張で使用される、ユーザーの資格証明を設定できます(monitoring-bind-dnおよびmonitoring-bind-password)。これを空白のままにすると、監視はデフォルトである匿名で実行されます。
たとえば、一般的な操作として、使用するリモートLDAPサーバーの変更があります。これを行うには、次に示すように、新規リモートLDAPサーバーのアドレスとポートを設定する必要があります:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-extension-prop \
--extension-name DS-proxy5 \
--set remote-ldap-server-address:DS5-hostname \
--set remote-ldap-server-port:3388
LDAPサーバー拡張の拡張プロパティを変更するには、第18.1.1.2.6項「LDAPサーバー拡張の拡張プロパティを変更するには」を参照してください。
次の拡張プロパティを構成できます:
pool-increment接続プールのサイズを大きくするまたは小さくする際の増分。remote-ldap-server-ssl-policyプロパティがuserに設定されると、2つの接続プールが作成され、各プールのサイズの増分がpool-incrementに設定されます。
デフォルト値は接続数5です。
pool-initial-size接続プールの初期サイズ。これは、プールの初期化時に作成される初期接続数です。pool-initial-sizeは、プールの最小サイズでもあることに注意してください。
デフォルト値は接続数10です。
remote-ldap-server-ssl-policyプロパティがuserに設定されると、2つの接続プールが作成され、各プールの初期サイズ、つまり最小サイズがpool-initial-sizeに設定されます。このため、最初は合計接続数が、pool-initial-sizeで示される接続数の2倍になる可能性があります。詳細は、第24.2項「セキュアな接続のモード」を参照してください。
pool-max-size接続プールの最大サイズ。これは、1つのプールに割り当てることができる最大接続数です。remote-ldap-server-ssl-policyプロパティがuserに設定されると、2つの接続プールが作成され、各プールの最大サイズがpool-max-sizeに設定されます。
デフォルト値は接続数1000です。
pool-max-write1つの接続プールに同時に割り当てることができる書込み接続の最大数。整数を指定します。このパラメータは、pool-use-max-writeパラメータがtrueに設定されている場合にのみ、考慮されます。
デフォルト値は接続数0です。
pool-release-connection-intervalプロキシに送信されているトラフィックがない場合に、プロキシで接続が未使用と見なされるまでの時間。接続数が前に増加されている接続プールの場合、そのサイズが縮小されます。未使用の接続の数がpool-incrementより大きい場合、プールのサイズはpool-incrementの分だけ縮小されます。これは、未使用の接続がクローズされ、プールから削除されることを意味します。
デフォルト値は、300000ミリ秒(30秒)です。
pool-use-max-writeこのブール値がtrueに設定されるとpool-max-writeパラメータが考慮されますが、そうでない場合は考慮されません。デフォルトで、pool-use-max-writeはfalseに設定されます。
proxied-auth-use-v1プロキシ認可制御モードを使用している場合、制御のデフォルトのバージョンはv2です。互換性の理由により前のバージョンを使用する場合は、proxied-auth-use-v1をtrueに設定します。デフォルトで、proxied-auth-use-v1はfalseに設定されます。制御の詳細は、付録B「サポートされている制御および操作」を参照してください。
remote-ldap-server-read-timeout読取りのタイムアウト。リモートLDAPサーバーがレスポンスを返す前にタイムアウトに達すると、プロキシからクライアントにエラーが返されます。デフォルトで、この値は10000ミリ秒(10秒)です。
saturation-precision飽和精度は、飽和しきい値の計算に使用されます。飽和限度はリクエストの送受信によって変化するため、飽和精度は、どれくらい飽和が変化したときに、飽和が考慮されることになるかを示します。デフォルトで、考慮に入れられるまで飽和は5%まで変化できます。
監視プロパティについては、第18.1.1.2.7項「LDAPデータ・ソースの接続監視プロパティ」で説明しています。
SSLプロパティは、セキュリティ機能です。これらのプロパティの詳細は、第24章「プロキシ/データ・ソース間のセキュリティ構成」を参照してください。
LDAPサーバー拡張の拡張プロパティを変更するには、set-extension-prop --advancedコマンドを使用します。
|
注意: これらの拡張プロパティは、デフォルトで設定されており、通常は変更されません。 |
変更する可能性がある拡張プロパティの例として、pool-max-sizeがあります。強力なリモートLDAPサーバーを使用しており、最大数のリクエストを受信するようプロキシを構成している場合は、次のようにpool-max-sizeを増加できます:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-extension-prop --advanced \
--extension-name DS-proxy5 \
--set pool-max-size:2000
LDAPサーバー拡張のdsconfig --advancedコマンドを使用すると、次の監視プロパティを表示または変更できます。明記されていないかぎり、すべてのプロパティはプロアクティブ監視に関連しています。
monitoring-check-interval監視チェックの間隔。これは、プロキシ・プロアクティブ監視でデータ・ソースのチェックが実行されるミリ秒単位の間隔です。デフォルト値は、30000ミリ秒(30秒)です。
monitoring-connect-timeoutプロアクティブ監視ファシリティがリモートLDAPサーバーへの接続の試行を停止するまでのミリ秒単位の最大時間。デフォルト値は、5000ミリ秒(5秒)です。0は無制限を意味します。
monitoring-inactivity-timeoutリモート・サーバーによる接続のクローズを回避するために定期的にアイドル接続がチェックされるまでのミリ秒単位の時間間隔。このパラメータの値は、monitoring-check-intervalより長く設定する必要があります。デフォルト値は、120000ミリ秒(120秒)です。
monitoring-ping-timeoutプロアクティブ監視でリモート・サーバーへのpingが試行されるミリ秒単位の最大時間。デフォルト値は、5000ミリ秒(5秒)です。
remote-ldap-server-read-timeout接続が失敗したと見なされるまで、LDAPサーバー拡張がリモート・サーバーからのレスポンスを待機するミリ秒単位の最大時間。0は無制限を意味します。
remote-ldap-server-connect-timeout接続が失敗したと見なされるまで、監視でリモート・サーバーへの接続が試行されるミリ秒単位の最大時間。0は無制限を意味します。デフォルトは10000ミリ秒(10秒)です。
この項では、リモートLDAPサーバーとの通信に必要なLDAPプロキシ・ワークフロー要素を構成する方法を説明します。この項の内容は次のとおりです:
特定のプロキシ・サーバー・インスタンスに構成されているワークフロー要素すべてを表示するには、次に示すように、dsconfig list-workflow-elementsコマンドを使用します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ list-workflow-elements Workflow Element : Type : enabled -----------------:--------------------:-------- adminRoot : ldif-local-backend : true load-bal-we1 : load-balancing : true proxy-we1 : proxy-ldap : true proxy-we2 : proxy-ldap : true
プロキシ・ワークフロー要素は、タイプがproxy-ldapになっているものです。
プロキシ・ワークフロー要素のプロパティを表示するには、次に示すように、dsconfig get-workflow-element-propコマンドを使用します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
get-workflow-element-prop --element-name proxy-we1
Property : Value(s) --------------------------------------:-------------------- client-cred-mode : use-client-identity enabled : true ldap-server-extension : proxy1 remote-ldap-server-bind-dn : - remote-ldap-server-bind-password : - use-proxy-auth : false
次のプロパティが表示されます:
client-cred-modeプロキシからリモートLDAPサーバーに接続する方法を示します。この例では、ステータスはuse-client-identityになっています。これは、クライアントでプロキシへの接続に使用されたものと同じ資格証明を使用してプロキシからリモートLDAPサーバーに接続されることを意味しています。これはデフォルトのモードです。
詳細は、第24章「プロキシ/データ・ソース間のセキュリティ構成」を参照してください。
enabledワークフローが有効になっている(true)か、それとも有効になっていない(false)かを示します。
ldap-server-extensionワークフロー要素が関連付けられているLDAPサーバー拡張の名前です。
client-cred-modeがuse-specific-identityまたはuse-proxy-authの場合に、リモートLDAPサーバーへの接続にプロキシで使用される、ユーザーの資格証明です。
プロキシLDAPワークフロー要素を作成するには、LDAPサーバー拡張を構成しておく必要があります。
プロキシLDAPワークフロー要素を作成するには、次に示すように、dsconfig create-workflow-elementコマンドを使用します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we5 \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:DS-proxy5
ワークフロー要素のタイプは、proxy-ldapである必要があります。新規プロキシLDAPワークフロー要素の名前は、element-nameで定義します。この例では、proxy-we5です。
クライアント資格証明モード(client-cred-mode)は、プロキシがリモートLDAPサーバーに接続する方法を示します。この例では、資格証明モードはuse-client-identityになっています。これは、クライアントでプロキシへの接続に使用されたものと同じ資格証明を使用してプロキシからリモートLDAPサーバーに接続されることを意味しています。これはデフォルトのモードです。
|
注意:
|
詳細は、第24章「プロキシ/データ・ソース間のセキュリティ構成」を参照してください。
プロキシLDAPワークフロー要素のプロパティを変更するには、set-workflow-element-propコマンドを使用します。
次のプロパティを変更できます:
プロキシLDAPワークフロー要素を有効にする(true)か、それとも有効にしない(false)かを設定できます。
使用するクライアント資格証明モードを設定できます(client-cred-mode)。
LDAPサーバー拡張を関連付けて、使用するリモートLDAPサーバーを指定できます(ldap-server-extension)。
リモートLDAPサーバーへの接続にプロキシで使用する、ユーザーの資格証明を設定できます(remote-ldap-server-bind-dnおよびremote-ldap-server-bind-password)。次の構文がサポートされています:
<password-value>
file://<password-file>
コマンド行で、クリア・テキストでパスワードを渡すことはサポートされていますが、お薦めしません。パスワード・ファイルを使用することをお薦めします。パスワード・ファイルは、コマンドが実行されたら削除できます。
たとえば、別のリモートLDAPサーバーを使用するために、ワークフロー要素で使用するLDAPサーバー拡張を変更する場合、次のように実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-workflow-element-prop --advanced \
--element-name proxy-we5 \
--set remote-ldap-server-bind-dn:uid=Specific\ User,dc=example,dc=com \
--remote-ldap-server-bind-password:file://pwd-file \
--set ldap-server-extension:DS-proxy3 \
--set client-cred-mode:use-specific-identity
エンド・ユーザーが1つの認証済操作を実行すると、プロキシLDAPワークフロー要素は、次の2つの個別操作を受け取ります:
リモート・サーバーに対してユーザーを認証するバインド操作。
実行する操作。
バインド操作が実行される際には、プロキシLDAPワークフロー要素は、LDAPサーバー拡張から接続を取得し、バインド操作を実行してから、接続を解放します。
実際の操作が着信すると、プロキシLDAPワークフロー要素は、LDAPサーバー拡張から接続を再度取得します。該当する資格証明にバインドされている接続が検出された場合、その接続が再利用されます。検出されなかった場合、新規接続を認証する必要があります。この追加認証操作をサイレント・バインドと呼びます。
サイレント・バインドの実行に使用する一連の資格証明は、バインド・モードで指定されます。これは、LDAPワークフロー要素のプロパティの1つです。これらの資格証明は、クライアント資格証明またはプロキシ資格証明です。表18-1は、Oracle Unified Directoryでサポートされているバインド・モードを示しています。
表18-1 Oracle Unified Directoryでサポートされているバインド・モード
| モード | 説明 |
|---|---|
|
|
サイレント・バインドの実行にクライアント資格証明を使用します。 |
|
|
サイレント・バインドの実行にプロキシ資格証明を使用します。 |
表18-1に示されているバインド・モードごとに、追加のパラメータを構成して、サーバーの動作を微調整することができます。これらのパラメータについては、次の各項で説明しています:
use-client-identityバインド・モードの構成バインド・モードがuse-client-identityに設定された場合、サーバーでは特定のパラメータによって阻止されないかぎり、サイレント・バインドの実行にクライアント資格証明が使用されます。サーバーでクライアント資格証明が使用されないようにするパラメータは、次のとおりです:
包含リストおよび除外リストの使用
次のリストを構成できます:
包含リスト: リモート・サーバーで処理される接尾辞をリストします。
除外リスト: リモート・サーバーで処理されない接尾辞をリストします。
クライアント・バインドDNが包含リスト上のいずれかのDNの子であるが、除外リスト上のいずれのDNの子でもない場合、プロキシ・サーバーではサイレント・バインドの実行にクライアント資格証明が使用されます。それ以外の場合、プロキシ・サーバーでは、サイレント・バインドの実行にプロキシ資格証明が使用されます。両方のリストがともに空の場合、プロキシ・サーバーでは常にクライアント資格証明が使用されます。
包含リストと除外リストは相互に排他的ではなく、同時に使用できます。ただし、1つのリストのみを定義することをお薦めします。また、両方のリストに同一の接尾辞を定義することはできません。
never-bindパラメータの使用
never-bindパラメータは、プロキシでクライアント資格証明を使用したバインドを実行する必要がある場合は常に適用できます。このフラグがtrueに設定されると、プロキシ・サーバーではリモート・データ・ソースからユーザー・エントリが読み取られ、バインドをリモート・サーバーに転送するのではなく、ユーザー・パスワード自体が検証されます。ユーザー・エントリの読取りに使用される資格証明は、プロキシLDAPワークフロー要素の次のプロパティで定義されているプロキシ資格証明であることに注意してください。remote-ldap-server-bind-dnおよびremote-ldap-server-bind-password。
受信バインド操作に重要な制御が含まれている場合、バインド操作専用の制御はnever-bind機能と互換性がないため、エラー結果が返されます。
|
注意: プロキシでユーザー・エントリの読取りに独自の資格証明が使用される場合、プロキシ認可制御を操作に追加して、リクエストの送信元のクライアントのIDを示すことができます。 |
use-specific-identityバインド・モードの構成バインド・モードがuse-specific-identityに設定されると、プロキシ・サーバーでは、すべてのサイレント・バインドの実行にプロキシ資格証明が使用されます。プロキシ資格証明は、プロキシLDAPワークフロー要素の次のプロパティで定義されます。remote-ldap-server-bind-dnおよびremote-ldap-server-bind-password。
use-specific-identityバインド・モードでは、次のパラメータを設定できます:
use-proxy-authパラメータの使用
use-proxy-authフラグがtrueに設定されると、プロキシ・サーバーでは、バインド・リクエスト以外のすべてのリクエストにプロキシ認可制御が追加されます。プロキシ認可IDの値は、クライアント・バインドDNです。
never-bindパラメータの使用
never-bindパラメータは、プロキシでクライアント資格証明を使用したバインドを実行する必要がある場合は常に適用できます。このフラグがtrueに設定されると、プロキシ・サーバーではリモート・データ・ソースからユーザー・エントリが読み取られ、バインドをリモート・サーバーに転送するのではなく、ユーザー・パスワード自体が検証されます。ユーザー・エントリの読取りに使用される資格証明は、プロキシLDAPワークフロー要素の次のプロパティで定義されているプロキシ資格証明であることに注意してください。remote-ldap-server-bind-dnおよびremote-ldap-server-bind-password。
dsconfigを使用したロード・バランシングの構成ロード・バランシングを使用してクライアント・リクエストをリモートLDAPサーバーに転送するには、次の要素が必要です:
ロード・バランシング・ワークフロー要素
ロード・バランシング・アルゴリズム
ロード・バランシング・ルート(リモートLDAPサーバーごと)
1つのロード・バランシング・ワークフロー要素で、ロード・バランシング・アルゴリズムを1つのみ使用できます。ただし、デプロイメント内のすべてのロード・バランシング・ルートで同一のロード・バランシング・アルゴリズムが使用されます。
この項では、ロード・バランシングに関連するすべての管理タスクについて説明します。インストール時のロード・バランシング・デプロイメントの設定の詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドの単純なロード・バランシングの構成に関する項を参照してください。次のトピックが含まれます:
次の各例は、dsconfigコマンドを使用して、ロード・バランシングを構成する方法を示しています。すべての例で、プロキシ・ホスト名(-h)、プロキシ管理ポート(-p)、バインドDN(-D)およびバインド・パスワード・ファイル(-j)が指定され、すべての証明書を信頼するために-Xオプションが使用されています。
ロード・バランシング・ワークフロー要素を作成します。
第18.1.3.2項「ロード・バランシング・ワークフロー要素の作成」を参照してください。
ロード・バランシング・アルゴリズムを作成します。
第18.1.3.3項「ロード・バランシング・アルゴリズムの作成」を参照してください。
ロード・バランシング・ワークフロー要素ごとに1つのロード・バランシング・ルートを作成します。
第18.1.3.4項「ロード・バランシング・ルートの作成」を参照してください。
ロード・バランシングを構成するには、dsconfig create-workflow-elementコマンドを使用して、ロード・バランシング・ワークフロー要素を作成する必要があります。例:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name load-bal-we1 \
--type load-balancing \
--set enabled:true
ロード・バランシング・ワークフロー要素を作成する場合、タイプをload-balancingにする必要があります。ワークフロー要素の名前は、element-nameで定義され、この例ではload-bal-we1です。
ロード・バランシング・デプロイメントで、リクエストが転送される方法を指定するには、ロード・バランシング・アルゴリズムを構成する必要があります。ロード・バランシング・アルゴリズム・セットによって、クライアント・リクエストが各リモートLDAPサーバーのプールにディスパッチされる方法が指定されます。使用可能なロード・バランシング・タイプは、failover、optimal、proportionalまたはsaturationです。
ロード・バランシング・アルゴリズムを作成するには、ロード・バランシング・ワークフロー要素が必要です。第18.1.3.2項「ロード・バランシング・ワークフロー要素の作成」を参照してください。
dsconfig create-load-balancing-algorithmコマンドを使用して、ロード・バランシング・アルゴリズムを作成します。例:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-load-balancing-algorithm \ --element-name load-bal-we1 \ --type failover
ロード・バランシング・アルゴリズムを作成するために、タイプをproportional、optimal、failoverまたはsaturationとして指定する必要があります。ワークフロー要素の名前は、element-nameで定義され、この例ではload-bal-we1です。
データ・ソースごとに1つのロード・バランシング・ルートが必要です。ロード・バランシング・ルートを作成する前に、ロード・バランシング・ワークフロー要素およびロード・バランシング・アルゴリズムを作成しておく必要があります。
ロード・バランシング・ルートを作成するには、dsconfig create-load-balancing-routeコマンドを使用します。例:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-load-balancing-route \ --element-name load-bal-we1 \ --route-name load-bal-route1 \ --type failover \ --set workflow-element:proxy-we1 \ --set add-priority:1 \ --set bind-priority:2 \ --set compare-priority:2 \ --set delete-priority:1 \ --set extended-priority:2 \ --set modify-priority:1 \ --set modifydn-priority:1 \ --set search-priority:2
この例では、load-bal-route1が新規ロード・バランシング・ルートの名前、load-bal-we1が既存のロード・バランシング・ワークフロー要素の名前およびproxy-we1がLDAPプロキシ・ワークフロー要素の名前です。タイプは、関連付けられているロード・バランシング・アルゴリズムで定義されているものと同じにする必要があり、ここではfailoverです。
設定するプロパティ(ここでは優先度)は、作成したロード・バランシングのタイプに関連します。アルゴリズム・タイプに関連した、ルートのプロパティの詳細は、第18.1.3.5項「ロード・バランシングのプロパティの変更」を参照してください。
ロード・バランシング・デプロイメントを設定したら、優先度、重み、飽和しきい値など特定のプロパティを変更できます。これらのプロパティのほとんどが、ロード・バランシング・ルート・レベルで変更されます。
ロード・バランシング・アルゴリズムに応じて、ロード・バランシングの次のプロパティを変更できます:
| フェイルオーバー | 最適 | 比例 | 飽和 | 検索フィルタ |
|---|---|---|---|---|
|
add-priority |
alert-threshold |
add-weight |
alert-threshold |
priority |
|
bind-priority |
saturation-precision* |
bind-weight |
priority |
allowed-attributes |
|
compare-priority |
workflow-element |
compare-weight |
threshold |
prohibited-attributes |
|
delete-priority |
delete-weight |
saturation-precision* |
workflow-element |
|
|
extended-priority |
extended-weight |
workflow-element |
||
|
modify-priority |
modify-weight |
|||
|
modifydn-priority |
modifydn-weight |
|||
|
search-priority |
search-weight |
|||
|
workflow-element |
workflow-element |
|||
|
switch-back flag |
* 飽和精度は、LDAPサーバー拡張のプロパティの1つです。
ロード・バランシング・ルートのプロパティを変更するには、dsconfig set-load-balancing-route-propコマンドを使用します。
サーバーを再起動する必要なく、実行中のアルゴリズムに新規ルートを追加したり、ルートを削除したり、ルートの優先度を変更したりできます。
|
注意: ロード・バランシング・アルゴリズムのタイプを変更することはできません。 たとえば、フェイルオーバー・ロード・バランシング・デプロイメントを比例ロード・バランシング・デプロイメントに変更するには、新規ロード・バランシング・デプロイメントを作成する必要があります。第18.1.3項「 |
次の各項では、1つのロード・バランシング・デプロイメントで使用可能な様々な設定について説明します:
フェイルオーバー・アルゴリズムを使用するロード・バランシング・デプロイメントでは、プロキシ・ワークフロー要素を変更して、使用されるルートを変更したり、指定された操作タイプのルートの優先度を変更したりできます。
フェイルオーバー・アルゴリズムでは、優先度1が最高の優先度で、特定の操作タイプに使用されるメイン・ルートであることを示します。優先度2(またはこれ以降)のルートは、プライマリ・ルートで障害が発生した場合に使用されるセカンダリ・ルートです。優先度は、操作タイプごとに設定されます。つまり、追加操作用としては優先度1のルートに、バインドおよび検索操作用として優先度2を指定できます。
たとえば、ルートload-bal-route1を最初は追加操作用の優先度1のメイン・ルートとして設定したが、このルートをバックアップ・ルートにする必要が生じた場合、次のコマンドを使用して優先度を2に設定できます。
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-load-balancing-route-prop \ --element-name load-bal-we1 \ --route-name load-bal-route1 --set add-priority: 2
|
注意: 指定された操作タイプについて、2つのルートの優先度が同じ場合、リクエストを処理するアクティブ・ルートの選択はランダムです。 |
switch-backフラグの設定ロード・バランシング・デプロイメントでのフェイルオーバーの後、バックアップ・ルートでは、障害が発生した優先サーバーが使用可能になった後でも、すべての受信リクエストの処理が続けられます。プライマリ・ルートへのスイッチバックまたはフェイルバックは、switch-backフラグがtrueに設定されていないかぎり、自動的には発生しません。デフォルトで、switch-backフラグはfalseに設定されます。
switch-backフラグは、拡張プロパティです。switch-backフラグをtrueに設定するには、次のように実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
--advanced set-load-balancing-algorithm-prop \
--element-name load-bal-we1 \
--set switch-back:true
最適アルゴリズムまたは飽和アルゴリズムを使用するロード・バランシング・デプロイメントでは、飽和精度レベルを設定できます。飽和精度は、2つの飽和レベルの差分であり、飽和レベルが最低のルートの判別に使用されます。デフォルトで、飽和精度レベルは5に設定されます。
飽和精度レベルが低すぎて、ルートが頻繁に変わりすぎると思われる場合は、次のように飽和精度レベルを変更できます:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
--advanced set-extension-prop \
--extension-name proxy1 \
--set saturation-precision:10
比例アルゴリズムを使用してロード・バランシング・デプロイメントを作成したら、プロキシ・ワークフロー要素を変更して、使用するルートおよびルートの重みを変更できます。操作タイプごとに異なる重みを指定できます。重みの値は、0以上である必要があります。0は、指定された操作には対象のルートが使用されないことを示します。
対話モードのdsconfigを使用すると、次のプロパティが変更可能なことがわかります:
>>>> Configure the properties of the Proportional Load Balancing Route
Property Value(s)
---------------------------
1) add-weight 1
2) bind-weight 1
3) compare-weight 1
4) delete-weight 1
5) extended-weight 1
6) modify-weight 1
7) modifydn-weight 1
8) search-weight 1
9) workflow-element proxy-we1
たとえば、最初にすべての操作に対してすべてのルートを重み1に設定した場合、すべてのサーバーで同等の比率で操作が処理されます。ただし、リモートLDAPサーバーを、デプロイメント内の他のユーザーより多くの検索リクエストを処理するよう設定する場合は、リモートLDAPサーバーのsearch-weightを5などのより大きな値に設定できます。これには、次のようなコマンドを使用します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-load-balancing-route-prop \ --element-name load-bal-we1 \ --route-name load-bal-route1 \ --set search-weight:5
|
注意: すべての操作について重みを変更するには、各操作の重みを個別に変更する必要があります。 |
他方のルートの2倍の操作を処理するようload-bal-route1を変更するには、すべての操作の重みを2に設定します(他方のルートの重みが1に設定されていることを前提としています)。つまり、次のようなコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-load-balancing-route-prop \ --element-name load-bal-we1 \ --route-name load-bal-route1 \ --set add-weight:2 \ --set bind-weight:2 \ --set compare-weight:2 \ --set delete-weight:2 \ --set extended-weight:2 \ --set modify-weight:2 \ --set modifydn-weight:2 \ --set search-weight:2
いずれかの操作について重みが0に設定されている場合、ルートではその指定された操作は実行されません。たとえば、add-weightを0に設定すると、load-bal-route1では、関連付けられているリモートLDAPサーバーに追加リクエストが転送されることはありません。特定の操作について、構成されているすべてのルートが重み0を示している場合、その操作はサポートされません。
飽和アルゴリズムを使用してロード・バランシング・デプロイメントを作成したら、使用されるプロキシ・ワークフロー要素、ルートの優先度、飽和しきい値および飽和しきい値アラートを変更できます。
飽和アルゴリズムでは、リクエストは次の2つの条件に基づいて分散されます。サーバーの優先度とサーバーの飽和しきい値です。飽和しきい値は、サーバーが最大化されていると見なされ、サービスの機能が低下する可能性がある限界値です。飽和アルゴリズムを使用したロード・バランシング・デプロイメントでは、リクエストは、優先度が最高(1)のサーバーに、そのサーバーに指定されている飽和しきい値に達するまで送信されます。
たとえば、load-bal-route1を最高優先度のサーバーとして指定し、しきい値を80%に指定すると、すべてのリクエストは、飽和しきい値の80%を超えるまでload-bal-route1に送信されます。80%を超えると、リクエストは、優先度リストの次のサーバーにルーティングされます。
>>>> Configure the properties of the Saturation Load Balancing Route
Property Value(s)
---------------------------
1) alert-threshold 85
2) priority 1
3) threshold 80
4) workflow-element proxy-we1
飽和しきい値を変更するには、次のコマンドを使用します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-load-balancing-route-prop \ --element-name load-bal-we1 \ --route-name load-bal-route1 \ --set threshold:90
この例では、飽和しきい値は90%に設定されています。
飽和しきい値アラートは、システム管理者にサーバーが飽和限度を超えたことを知らせる通知を送信する時点の設定に使用されます。通常、飽和しきい値アラートは、飽和が飽和しきい値を超えた後も増え続けている(これは問題を示唆している可能性がある)かどうかを示すために、飽和限度より高く設定されます。リクエストが別のルートに転送されるまでに短い遅延があって、その間に飽和の増加が続くことになる可能性があるため、アラートには受け入れ可能なバッファを設定しておく必要があります。
飽和しきい値を変更するには、次のコマンドを使用します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-load-balancing-route-prop \ --element-name load-bal-we1 \ --route-name load-bal-route1 \ --set alert-threshold:85
予防的措置を講じるために飽和しきい値アラートを飽和しきい値より低い値に設定できます(たとえば、メイン・ルートが、ロード・バランシングが設定された一連のサーバーの場合、その一連のサーバーに予防措置として1つ以上のサーバーを追加できます)。これは、飽和しきい値に達していない場合でも通知を受信することを意味しています。つまり、飽和しきい値アラートが送信されたが、飽和限度が低くなっていて、飽和しきい値には達していないということです。ただし、飽和しきい値に達したときにのみ、リクエストは優先度が次のルートに送信されます。
通知メッセージの設定の詳細は、第32.4項「アラートおよびアカウント・ステータス通知ハンドラの構成」を参照してください。
クライアント接続アフィニティを定義すると、指定されたクライアント接続からのリクエストは、設定されているロード・バランシング・アルゴリズムをバイパスして、同一サーバーにルーティングされます。クライアント接続アフィニティは、ネットワーク・グループ・レベルで設定されます。
クライアント接続アフィニティを設定するには、dsconfig create-network-group-qos-policyコマンドを使用します。詳細は、第17.1.6.3項「ネットワーク・グループのサービス品質ポリシーの作成」を参照してください。
例18-1 クライアント接続アフィニティが拒否される場合の例
クライアント接続アフィニティを設定すると、定義されている重みの制約が順守されているかぎり、ロード・バランシング・アルゴリズムはバイパスされます。
たとえば、次のルートが次の重みで設定されているとします:
LB-route1: add=10, search=0
LB-route2: add=0, search=10
LB-route1がすべての追加リクエストを受信し、LB-route2がすべての検索リクエストを受信することが明らかです。
この例でロード・バランシング・デプロイメントをクライアント接続アフィニティall-requests-after-first-write-requestで設定するとします。ロード・バランシング・デプロイメントで追加、検索、追加という一連のリクエストを受信した場合、通常、クライアント接続アフィニティでは、最初の追加リクエストと同じルート(LB-route1)に検索リクエストが送信されます。ところが、この場合、検索リクエストはLB-route1では許可されていないため、ロード・バランシング・アルゴリズムはクライアント・アフィニティによってバイパスされません。
ロード・バランシング・ワークフロー全体(ワークフロー要素、アルゴリズムおよびルート)を削除するために必要な処理は、ロード・バランシング・ワークフロー要素の削除のみです。ロード・バランシング・ワークフロー要素を削除すると、関連付けられているロード・バランシング・アルゴリズムおよびルートは通知なしに削除されます。
dsconfigを使用した分散の構成クライアント・リクエストをリモートLDAPサーバーに分散を使用して転送するには、プロキシ・サーバーに次のコンポーネントを構成する必要があります:
分散ワークフロー要素
分散アルゴリズム
1つ以上の分散パーティション(通常はリモートLDAPサーバーごとに1つ)
1つの分散ワークフロー要素には、データの分散方法が定義される分散アルゴリズムを1つのみ設定できます。1つの分散アルゴリズムで、複数のパーティションを使用できます。
次の各例は、dsconfigコマンドを使用して、分散を構成する方法を示しています。セットアップ時の分散デプロイメントの設定の詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドの単純な分散の構成に関する項を参照してください。
次の各プロシージャで使用するすべてのコマンドで、プロキシ・ホスト名(-h)、プロキシ管理ポート(-p)、バインドDN(-D)およびバインド・パスワード・ファイル(-j)が指定されます。各例では、すべての証明書を信頼するために-Xオプションが使用されます。
この項には次のトピックが含まれます:
分散ワークフロー要素を作成します。
第18.1.4.2項「分散ワークフロー要素の作成」を参照してください。
分散アルゴリズムを作成します。
第18.1.4.3項「分散アルゴリズムの作成」を参照してください。
パーティション化されたデータのチャンクごとに1つのパーティションを作成します。1つのパーティションを1つのリモートLDAPサーバーに、またはレプリケートされた複数のリモートLDAPサーバーの1つのセットに関連付ける必要があります。
容量ベースの分散の場合は、第18.1.4.4.1項「capacity分散パーティションの作成」を参照してください。
辞書編集分散または数値分散の場合は、第18.1.4.4.2項「lexicoまたはnumeric分散パーティションの作成」を参照してください。
DNパターン・アルゴリズムを使用している場合は、第18.1.4.4.3項「dnpattern分散パーティションの作成」を参照してください。
分散を構成するには、dsconfig create-workflow-elementコマンドを使用して、分散ワークフロー要素を作成する必要があります。例:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name distrib-we \
--type distribution \
--set enabled:true \
--set base-dn:ou=people,dc=example,dc=com
分散ワークフロー要素を作成するには、タイプをdistributionにする必要があります。ワークフロー要素の名前は、element-nameで定義され、この例ではdistrib-weです。
|
注意: 前述のように、 |
構成の分散要素を完成するには、分散アルゴリズムおよび適切なパーティションを作成します。
分散デプロイメントで、リクエストが転送される方法を指定するには、分散アルゴリズムを構成する必要があります。アルゴリズム・セットによって、データをパーティション化する方法およびリクエストの送信先のパーティションが指定されます。使用可能な分散タイプは、numeric、lexicoまたはdnpatternです。
分散アルゴリズムを作成するには、分散ワークフロー要素が必要です。第18.1.4.2項「分散ワークフロー要素の作成」を参照してください。
dsconfig create-distribution-algorithmコマンドを使用して、分散アルゴリズムを作成します。例:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-distribution-algorithm \
--element-name distrib-we \
--type numeric \
--set distribution-attribute:uid
ワークフロー要素の名前は、element-nameで定義され、この例ではdistrib-weです。分散アルゴリズムのタイプをcapacity、numeric、lexicoまたはdnpatternに設定する必要があります。設定するプロパティは、アルゴリズム・タイプによって異なります。この例では、アルゴリズム・タイプがnumericであるため、distribution-attributeを設定する必要があります。
次のタイプの分散パーティションを作成できます:
capacity分散パーティションの作成capacity分散パーティションを作成するには、分散ワークフロー要素および分散アルゴリズムを作成しておく必要があります。データ・セットごとに1つの分散パーティションを作成する必要があります。
分散パーティションを作成するには、dsconfig create-distribution-partitionコマンドを使用します。例:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-distribution-partition \ --element-name distrib-we \ --partition-name distrib-partition1 \ --type capacity \ --set partition-id:1 \ --set workflow-element: proxy-we1 \ --set max-entries:1000
|
注意: 容量ベースのアルゴリズムを使用する場合は、グローバル索引カタログを作成して、DNに索引を付ける必要があります。グローバル索引カタログを作成するには、第18.1.7.1.1項「グローバル索引が含まれるグローバル索引カタログを作成するには」を参照してください。 |
分散パーティションは、パーティション名(この例ではdistrib-partition1)とパーティションIDの両方で識別されます。パーティションIDは、グローバル索引カタログ参照で使用されることになるため、簡単な整数にする必要があります。タイプは、関連付けられている分散アルゴリズムで定義されているものと同じにする必要があり、ここではcapacityです。
分散パーティションを作成する場合、パーティションを管理する既存の分散ワークフロー要素の名前(element-name、ここではdistrib-we)、およびLDAPワークフロー要素などワークフロー内の次の要素の名前(workflow-element、この例ではproxy-we1)も指定する必要があります。プロキシ・ワークフロー要素によって、リモートLDAPサーバー上のデータへのアクセスに使用されるパスが指定されます。プロキシの詳細は、第18.1.1項「リモートLDAPサーバーとの通信の構成」を参照してください。
capacity分散パーティションを作成する場合、パーティションで保持可能なエントリの最大数を指定する必要があります(たとえば、1000)。
lexicoまたはnumeric分散パーティションの作成辞書編集分散と数値分散はよく似ており、辞書編集分散または数値分散の分散パーティションを作成する場合は同じプロパティを設定します。データ・セットごとに1つの分散パーティションを作成する必要があります。
lexicoまたはnumeric分散パーティションを作成するには、分散ワークフロー要素および分散アルゴリズムを作成しておく必要があります。
分散パーティションを作成するには、dsconfig create-distribution-partitionコマンドを使用します。数値分散の例として、次のようなパーティションを作成する場合があります:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-distribution-partition \ --element-name distrib-we \ --partition-name distrib-partition1 \ --type numeric \ --set partition-id:1 \ --set workflow-element: proxy-we1 \ --set lower-bound:1000 \ --set upper-bound:2000
分散パーティションは、パーティション名(この例ではdistrib-partition1)とパーティションIDの両方で識別されます。パーティションIDは、グローバル索引カタログ参照で使用されることになるため、簡単な整数にする必要があります。タイプは、関連付けられている分散アルゴリズムで定義されているものと同じにする必要があり、ここではnumericです。
分散パーティションを作成するために、既存の分散ワークフローの名前(ここではdistrib-we)、およびLDAPワークフロー要素など関連付けられているワークフロー要素の名前(この例ではproxy-we1)も指定する必要があります。プロキシ・ワークフロー要素によって、リモートLDAPサーバー上のデータへのアクセスに使用されるパスが指定されます。プロキシの詳細は、第18.1.1項「リモートLDAPサーバーとの通信の構成」を参照してください。
lexicoまたはnumeric分散パーティションを作成する場合、パーティションの下限と上限を指定する必要があります。プロキシによって、どの2つのパーティションの範囲にも、重なりがないことが確認されます。つまり、パーティション1の下限と上限を1000-3000に設定して、パーティション2の下限と上限を2000-4000に設定することはできません。
上限値自体は含まれません。つまり、前述の例では、パーティション化されるデータは1000から1999までの値のみになります。上限または下限を無制限にする場合は、キーワードunlimitedを使用します。
設定するプロパティ(この例では下限と上限)は、作成した分散のタイプに関連します。アルゴリズム・タイプに関連した、パーティションのプロパティの詳細は、第18.1.4項「dsconfigを使用した分散の構成」を参照してください。
なお、辞書編集分散アルゴリズムの場合、使用されるソート・シーケンスはASCIIです。
dnpattern分散パーティションの作成dnpattern分散パーティションを作成する前に、分散ワークフロー要素および分散アルゴリズムを作成しておく必要があります。
dnpattern分散パーティションを作成するには、dsconfig create-distribution-partitionコマンドを使用します。例:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-distribution-partition \ --element-name distrib-we \ --partition-name distrib-partition5 \ --type dnpattern \ --set partition-id:5 \ --set workflow-element: proxy-we1 \ --set dn-pattern:uid=[0-9]*[01].*
分散パーティションは、パーティション名(この例ではdistrib-partition5)とパーティションIDの両方で識別されます。パーティションIDは、グローバル索引カタログ参照に使用されるため、簡単な整数にします。分散パーティションを作成するために、既存の分散ワークフローの名前(ここではdistrib-we)、およびLDAPプロキシなど関連付けられているワークフロー要素の名前(この例ではproxy-we1)も指定する必要があります。タイプは、関連付けられている分散アルゴリズムで定義されているものと同じにする必要があり、ここではdnpatternです。
dnpatternアルゴリズムを使用する分散シナリオでは、リクエストは、分散ベースDNより下位のリクエストRDNがDN文字列パターンに一致した場合にパーティションに送信されます。たとえば、分散ベースDNがou=people,dc=example,dc=comで、リクエスト・ベースDNがuid=1,ou=people,dc=example,dc=comの場合、文字列パターンに対するチェックはRDN uid=1で実行されます。
同様に、分散ベースDNがou=people,dc=example,dc=comで、リクエスト・ベースDNがuid=1,ou=region1,ou=people,dc=example,dc=comの場合、文字列パターンに対するチェックは、RDN uid=1,ou=region1で実行されます。
DN文字列パターンは、DN構文およびJava Patternクラスのサブセットに準拠する必要があります。
| DNパターン文字列 | 説明 |
|---|---|
|
. |
任意の文字 |
|
\\ |
バックスラッシュ |
|
\t |
タブ文字 |
|
[abc] |
a、bまたはc |
|
[îabc] |
a、bまたはcを除く任意の文字 |
|
[a-zA-Z] |
aからzまたはAからZ、範囲指定に使用する文字も含む(範囲) |
|
[a-d[m-p]] |
aからd、またはmからp(和集合) |
|
[a-z&&[def]] |
d、eまたはf(積集合) |
|
[a-z&&[îbc]] |
aからzのうち、bおよびcを除く(減算) |
|
[A-Z&&[îM-P]] |
aからzのうち、mからpを除く(減算) |
次の数量詞を使用できます:
|
X? |
X、1回または0回 |
|
X* |
X、0回以上 |
|
X+ |
X、1回以上 |
|
X{n} |
X、n回 |
|
X{n,} |
X、n回以上 |
|
X{n,m} |
X、n回以上m回以下 |
negative-matchの使用negative-matchという分散プロパティを使用して、一致する必要のあるDNパターンに反するものを指定できます。つまり、無視するDNパターンを指定します。指定したDNパターンに一致しない値が分散されます。デフォルトで、negative-matchプロパティは、falseに設定されます。
次のように、negative-matchを使用して、dnpattern分散パーティションを作成します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-distribution-partition \ --element-name distrib-we \ --partition-name distrib-partition5 \ --type dnpattern \ --set partition-id:5 \ --set workflow-element: proxy-we1 \ --set dn-pattern:uid=[123]*[0-9].* \ --set negative-match:true
この例では、negative-matchがtrueに設定されているため、1、2または3で開始して、n個の文字が続くもの以外のuidについてのリクエストはすべて、対象のパーティションに転送されます。
新規エントリが元のエントリと同じパーティションに留まるようDNを変更できます。デフォルトで、プロキシでは現行パーティションの範囲外の値にDNを変更することは許可されません。
modifyDNリクエストで、エントリが配置されているパーティションの境界外の値にDNを変更できるようにするには、force-modify-dnフラグをtrueに設定します。
たとえば、uidの境界が0-999のパーティション1と、uidの境界が1000-1999のパーティション2があるとします。force-modify-dnフラグをtrueに設定して、特定のエントリのuidを1から1001に変更すると、変更は許可されますが、uidが1001のそのエントリはパーティション1に留まります。このエントリがパーティション2に移動されることはありません。
uid=1001を検索すると、サーバーは、そのようなエントリは見つからないというエラーを返します。エントリの位置を特定するには、グローバル索引カタログを使用する必要があります。これによって、変更されているエントリが常に見つかります。グローバル索引カタログを構成するには、第18.1.7項「コマンド行を使用したグローバル索引の構成」を参照してください。
DN変更操作を強制実行するには、次のように、force-modify-dnフラグをtrueに設定します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
--advanced set-workflow-element-prop --element-name distrib-we \
--set force-modify-dn:true
クリティカル度の構成によって、検索操作が失敗したときのサーバーの動作が指定されます。クリティカル度は検索リクエストにのみ適用されます。その他のリクエストはすべてサーバーによって通常どおりに処理されます。
クリティカル度は、ワークフロー・レベルでクリティカル度フラグを設定することによって構成できます。ワークフローで検索リクエストを実行するときに、下位ワークフローがある場合は、いくつかのワークフローでそのリクエストが実行されます。ワークフローのクリティカル度の設定は、次のいずれかになります:
true
これはデフォルト設定で、対象のワークフローをクリティカルであると見なすことを示します。特定のワークフローで結果を返すことに失敗した場合、その他のワークフローでの操作の実行が成功したかどうかにかかわらず、処理は停止します。
false
この設定は、対象のワークフローが非クリティカルであることを示します。クリティカル度の設定がfalseの場合、特定のワークフローでの操作実行の失敗は全体的な結果にとってクリティカルではないことがサーバーに伝えられます。非クリティカルのワークフローが結果を返すことに失敗した場合、サーバーでは単にその結果が省略され(ワークフローが何もデータを返さなかったかのように)、クライアントに成功の結果コードを返し、エラーが示されることはありません。
Partial
この設定は、対象のワークフローが部分的にクリティカルであることを示します。これは、結果の一部が取得されたことをアプリケーションからアプリケーションのユーザーに通知できることを意味します。たとえば、完全に飽和したことや無効になっていることによって、部分的にクリティカルなパーティションが結果を返すことに失敗した場合、サーバーはAdmin Limit Exceededエラーを返します。これは、実際の内容とは異なるエラーですが、この設定の目的は、クライアント・アプリケーションのロジックによって、表示されている結果が全体の一部にすぎないことが示されることです。
ワークフローのクリティカル度を設定するには、dsconfig set-workflow-propコマンドを使用します。たとえば、次のコマンドでは、workflow-1という名前のワークフローのクリティカル度がtrueに設定されます。
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-workflow-prop --workflow-name workflow-1 \ --set criticality:true
分散デプロイメントでは、クリティカル度構成によって、ホスト・エラーによって検索操作が失敗したときのサーバーの動作を指定します。クリティカル度は検索リクエストにのみ適用されます。その他のリクエストはすべてサーバーによって通常どおりに処理されます。
クリティカル度は、分散ワークフロー要素の分散パーティションごとに構成されます。分散パーティションのクリティカル度の設定は、次のいずれかになります:
true
これはデフォルト設定で、対象のパーティションをクリティカルであると見なすことを示します。たとえば、完全に飽和したことや無効になっていることによって、特定のパーティションが結果を返すことに失敗した場合、データが他のパーティションで見つかったかどうかにかかわらず、サーバーは使用不可のエラーをクライアントに返します。
false
この設定は、対象のパーティションが非クリティカルであることを示します。クリティカル度の設定がfalseの場合、特定のパーティションでの操作実行の失敗は全体的な結果にとってクリティカルではないことがサーバーに伝えられます。たとえば、完全に飽和したことや無効になっていることによって、非クリティカルのパーティションが結果を返すことに失敗した場合、サーバーでは単にその結果が省略され(パーティションが何もデータを返さなかったかのように)、クライアントに成功の結果コードを返し、エラーが示されることはありません。
Partial
この設定は、対象のパーティションが部分的にクリティカルであることを示します。これは、結果の一部が取得されたことをアプリケーションからアプリケーションのユーザーに通知できることを意味します。たとえば、完全に飽和したことや無効になっていることによって、部分的にクリティカルなパーティションが結果を返すことに失敗した場合、サーバーはAdmin Limit Exceededエラーを返します。これは、実際の内容とは異なるエラーですが、この設定の目的は、クライアント・アプリケーションのロジックによって、表示されている結果が全体の一部にすぎないことが示されることです。
分散ワークフロー要素を除くすべてのタイプのワークフロー要素について、クリティカル度は暗黙的であり、次のように処理されます:
ロード・バランシング: すべてのルートが非クリティカルと見なされます。1つのルートが機能しない場合、それがロード・バランサで選択ルートの決定に考慮されることはないためです。
LDAPプロキシ・ワークフロー要素: LDAPサーバーは常にクリティカルと見なされます。
ローカル・バックエンド・ワークフロー要素: ローカル・バックエンド・サーバーは常にクリティカルと見なされます。
分散パーティションのクリティカル度を設定するには、dsconfig set-distribution-partition-propコマンドを使用します。たとえば、次のコマンドでは、distrib-partition-1という名前のパーティションのクリティカル度がtrueに設定されます。
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-distribution-partition-prop --element-name distrib-we \ --partition-name distrib-partition-1 --set criticality:true
分散ワークフロー全体(ワークフロー要素、アルゴリズムおよびパーティション)を削除するために必要な処理は、分散ワークフロー要素の削除のみです。分散ワークフロー要素を削除すると、関連付けられている分散アルゴリズムおよびパーティションは通知なしに削除されます。
dsconfigを使用したDNリネームの構成DNリネームを構成するには、dsconfig create-workflow-elementコマンドを使用して、DNリネーム・ワークフロー要素を作成する必要があります。
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element \ --type dn-renaming \ --element-name RenameorgDN \ --set client-base-dn:ou=myorg,dc=example,dc=com \ --set next-workflow-element:load-bal-we1 \ --set source-base-dn:ou=people,dc=example,dc=com \ --set enabled:true
--set client-base-dnは、クライアント・ベースDNを示します。これは、ワークフロー・エントリ・ポイントです。
--set source-base-dnは、エントリで変換後に使用する必要のあるベースDNを示します。これは、ワークフロー終了ポイントです。
--set next-workflow-elementは、プロキシ・アーキテクチャでDNリネーム・ワークフロー要素に続くワークフロー要素を示します。これは、どのようなタイプのワークフロー要素でもかまいません。
DNリネームを構成したら、DNリネームの次のプロパティを変更できます:
クライアント・ベースDN
ソース・ベースDN
次のワークフロー要素
ブラック・リストの属性
ホワイト・リストの属性
DNリネームの現行プロパティを表示するには、dsconfig get-workflow-element-propコマンドを使用します。
DNリネームのプロパティを変更するには、dsconfig set-workflow-element-propコマンドを使用します。
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-workflow-element-prop \ --element-name RenameorgDN \ --set source-base-dn:ou=admin,dc=example,dc=com
この例では、source-base-dnのみが変更されています。元のソース・ベースDNを指定する必要はありません。新しいもののみが必要です。
リネームしてはいけないDN属性のブラック・リストを作成するには、dsconfig set-workflow-element-propコマンドを使用します。
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-workflow-element-prop --element-name RenameorgDN \ --set black-list-attributes:manager
属性にはDNタイプを指定する必要があります。
dsconfigを使用したRDN変更の構成RDNをリネームするには、dsconfig create-workflow-elementコマンドを使用して、RDN変更ワークフロー要素を作成します。
dsconfig create-workflow-element \
--set client-rdn:cn \
--set enabled:true \
--set next-workflow-element:localproxy \
--set source-rdn:uid \
--type rdn-changing \
--element-name myrdnchangingwfe \
--hostname localhost \
--port "4444" \
--trustAll \
--bindDN cn=directory\ manager \
--bindPasswordFile pwd-file \
--no-prompt
--set client-rdnは、クライアント・ベースRDNを示します。これは、ワークフロー・エントリ・ポイントです。
--set source-rdnは、エントリで変換後に使用する必要のあるベースRDNを示します。これは、ワークフロー終了ポイントです。
--set next-workflow-element:localproxyは、プロキシ・アーキテクチャでRDN変更ワークフロー要素に続くワークフロー要素を示します。これは、どのようなタイプのワークフロー要素でもかまいません。
|
注意: 次のパラメータを使用して、プロキシLDAPワークフロー要素を作成する必要があります。
RDN変更ワークフロー要素では、これらの資格証明を使用して、リモート・サーバーでの内部検索が実行されます。 |
--element-name myrdnchangingwfeは、作成しているRDN変更ワークフロー要素の名前を示します。
この構成によって、uid=user.1,ou=people,dc=example,dc=comがcn=User CN,ou=people,dc=example,dc=comに置換されます。
RDNリネームを構成したら、RDNリネームの次のプロパティを変更できます:
クライアントRDN
ソースRDN
次のワークフロー要素
オブジェクト・クラス
DN属性
置換値
RDNリネームの現行プロパティを表示するには、dsconfig get-workflow-element-propコマンドを使用します。
RDNリネームのプロパティを変更するには、dsconfig set-workflow-element-propコマンドを使用します。
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-workflow-element-prop \ --element-name myrdnchangingwfe \ --set source-rdn:uid
この例では、source-rdnのみが変更されています。元のsource-rdnを指定する必要はありません。新しいもののみが必要です。
グローバル索引では、エントリが特定の分散パーティションにマップされるため、分散トポロジでの検索操作および変更操作が速くなります。グローバル索引では、電話番号など一意の属性に基づいてエントリがマップされます。グローバル索引のリストは、グローバル索引カタログに含まれます。1つのプロキシ・インスタンスに1つ以上のグローバル索引カタログを含めることができます。
|
注意: グローバル索引およびグローバル索引カタログを構成および管理するには、リモート・サーバーで特定の制御、特にLDAP読込み前制御およびCSN制御を有効にする必要があります。詳細は、付録B「サポートされている制御および操作」を参照してください。 |
この項には次のトピックが含まれます:
gicadmを使用したグローバル索引カタログの構成グローバル索引カタログは、INSTANCE_DIR/OUD/catalogsにあるBerkeleyデータベースに格納されます。分散トポロジの高可用性を確保するために、グローバル索引カタログのレプリケーションをお薦めします。詳細は、「グローバル索引カタログのレプリケーション」を参照してください。
gicadmコマンドは、次のサーバー・インスタンス・ディレクトリにあります:
Unixの場合: INSTANCE_DIR/OUD/bin/gicadm
Windowsの場合: INSTANCE_DIR\OUD\bat\gicadm.bat
詳細は、付録A「gicadm」を参照してください。
この項で示している各プロシージャでは、分散アーキテクチャにプロキシがデプロイされており、デフォルトのプロキシ管理ポート(4444)を使用していることが前提となっています。この項には次のトピックが含まれます:
グローバル索引を作成するには、次のプロシージャで示しているとおりに、まずグローバル索引カタログを作成する必要があります。このプロシージャでは、グローバル索引カタログの作成、グローバル索引の作成と追加およびグローバル索引へのデータの追加を実行する方法を示しています。必要に応じて、データは後でグローバル索引に追加できます。
開始する前に、プロキシを分散にデプロイしておく必要があります。
gicadmコマンドを使用して、グローバル索引カタログを作成します:
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ create-catalog --catalogName sampleCatalog
カタログ名は一意である必要があります。
作成したグローバル索引カタログに、少なくとも1つのグローバル索引を作成して追加します。
次のコマンドによって、telephoneNumber属性値で構成されたグローバル索引が作成され、そのグローバル索引が、前の手順で作成したグローバル索引カタログに追加されます。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ add-index --catalogName sampleCatalog --attributeName telephoneNumber
後でadd-indexサブコマンドを使用して、追加のグローバル索引をこのグローバル索引カタログに追加できます。
グローバル索引カタログを分散に関連付けます。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ associate --catalogName sampleCatalog \ --distributionWorkflowElement myDistributionName
ワークフロー要素の詳細は、第17.1.8項「dsconfigを使用したワークフロー要素の構成」を参照してください。分散の詳細は、第18.1.4項「dsconfigを使用した分散の構成」を参照してください。
split-ldifコマンドを使用して、1つのLDIFファイルから複数のファイルを生成します。
split-ldifコマンドでは、プロキシで構成されている分散アルゴリズムに基づいて、1つのLDIFファイルのコンテンツが、複数のLDIFファイルに分割されます。このコマンドを使用して、グローバル索引にロードするデータを含めるファイルを生成することもできます。ディレクトリ・サービスを開始したときに索引付けする必要があるデータをリモートLDAPサーバーに含める場合は、グローバル索引の初期化時にsplit-ldifを使用する必要があります。ディレクトリにデータを含めない状態で開始する場合は、この手順を省略できます。
split-ldifコマンドの詳細は、このコマンドを使用してグローバル索引に1つまたは複数の索引付き属性を移入する方法の例も含めて、付録A「split-ldif」を参照してください。
gicadm importコマンドを使用して、グローバル索引にデータをインポートします。
詳細は、第18.1.7.1.8項「グローバル索引カタログにコンテンツをインポートするには」を参照してください。
グローバル索引カタログのプロパティは、グローバル索引カタログのレプリケーションに関連しています。グローバル索引カタログのプロパティのリストおよびそれらの使用についての説明は、第18.1.7.1.3項「グローバル索引カタログのプロパティの変更」を参照してください。
グローバル索引カタログのすべてのプロパティを表示するには、gicadmコマンドをget-catalog-propサブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ get-catalog-prop --catalogName sampleCatalog --property all
出力は、次のようになります。
Property : Value(s) -------------------:------------------------------- replication-server : localhost:3390, localhost:4390 server-id : 4247 window-size : 100 heartbeat-interval : 1000 group-id : 1
グローバル索引カタログの特定のプロパティの値を表示するには、そのプロパティを指定します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ get-catalog-prop --catalogName sampleCatalog --property heartbeat-interval
グローバル索引のプロパティは、グローバル索引カタログのレプリケーションに関連しています。使用可能なグローバル索引カタログのプロパティは、次のとおりです:
replication-server: host:portの形式で、レプリケーション・トポロジ内のサーバーをリストします。このプロパティは、set-catalog-propコマンドで変更してはいけませんが、enable-replicationコマンドでは変更できます。
server-id: グローバル索引カタログ・レプリケーション・ドメイン内のグローバル索引に一意の識別子を指定します。同一のグローバル索引カタログ・レプリケーション・ドメイン内の各インスタンスに、異なるサーバーIDを指定する必要があります。1つのインスタンスが複数のグローバル索引カタログ・レプリケーション・ドメインのメンバーとなっている場合は、それぞれのグローバル索引カタログ・レプリケーション・ドメイン構成で同じサーバーIDを使用できます。
構文: 1 <= INTEGER <= 65535またはテキスト。このプロパティは変更しないでください。
window-size: インスタンスがレプリケーション・サーバーとの通信で使用するウィンドウ・サイズを指定します。デフォルト値は100です。
構文: 0 <= INTEGERまたはテキスト。
heartbeat-interval: インスタンスがレプリケーション・サーバーとの通信で使用するハートビート間隔を指定します。インスタンスは、レプリケーション・サーバーからの、指定した間隔内での定期的なハートビートを予期します。ハートビートをこの間隔内に受信しなかった場合、インスタンスはその接続をクローズして、別のレプリケーション・サーバーに接続します。
構文: 100 ms <= DURATION (ms)
group-id: 特定のレプリケートされたドメインに関連付けられたID。この値は、レプリケートされたドメインのグループIDを定義します。レプリケーション・システムは、自身のものと同じグループIDのレプリケーション・サーバーに接続して更新を送信し、レプリケートしようとします。
構文: 1 <= INTEGER <= 127
|
注意: このプロパティは変更しないでください。 |
グローバル索引カタログのプロパティのリストは、第18.1.7.1.3項「グローバル索引カタログのプロパティの変更」を参照してください。
gicadmコマンドをset-catalog-propサブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
set-catalog-prop --catalogName sampleCatalog --set property:value
たとえば、変更可能なプロパティの1つとして、ハートビート間隔があります。この場合、次のように実行します:
--set heartbeat-interval:500
グローバル索引またはグローバル索引カタログの複数値プロパティの場合、--addオプションまたは--removeオプションを使用して、値を追加または削除できます。
グローバル索引カタログの場合、複数値を含めることができるのは、replication-serverプロパティのみです。グローバル索引の複数値プロパティの場合は、かわりにset-index-propサブコマンドを使用します。
値を追加するには、gicadmコマンドをset-catalog-propサブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
set-catalog-prop --catalogName sampleCatalog --add replication-server:hostname
複数値プロパティから値を削除するには、gicadmコマンドをset-catalog-propサブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
set-catalog-prop --catalogName sampleCatalog \
--remove replication-server:hostname
グローバル索引カタログのいずれかのプロパティを変更して、その後それらの値をデフォルト値にリセットする必要が生じた場合は、次のプロシージャを実行します。
gicadmコマンドをset-catalog-propサブコマンドとともに使用します。
たとえば、ハートビート間隔をリセットする場合は、次のように実行します:
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
set-catalog-prop --catalogName sampleCatalog --reset heartbeat-interval
グローバル索引のプロパティを表示するには、gicadmコマンドをget-index-propサブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ get-index-prop --catalogName sampleCatalog --attributeName telephoneNumber \ --property all
プロパティは、次のようになります:
Property Names : Property Values ---------------------------------------------:--------------------------------- global-index-deleted-entry-retention-timeout : 500 db-cleaner-min-utilization : 50 db-log-file-max : 10000000 db-checkpointer-bytes-interval : 20000000 db-checkpointer-wakeup-interval : 30 db-num-lock-tables : - db-num-cleaner-threads : - db-txn-no-sync : false db-txn-write-no-sync : true je-property : - db-directory : catalogs db-directory-permissions : 700 global-index-catalogs-shared-cache : global-index-catalogs-shared-cac global-index-attribute : telephoneNumber
|
注意: 通常、これらの値は変更できません。 |
特定のファイルのコンテンツを、グローバル索引カタログ内の1つまたは複数のグローバル索引にインポートできます。ファイルのコンテンツのインポート先のカタログの名前を指定する必要があります。オプションでattributeNameパラメータを指定することによって、ファイルのコンテンツを特定の索引に関連するデータにフィルタで抽出できます。
インポート対象のデータ・ファイルは、たとえば、split-ldifコマンドまたはgicadm exportコマンドを実行することによって作成できます。
ファイルのコンテンツをグローバル索引カタログにインポートするには、gicadmコマンドをimportサブコマンドとともに使用します。例:
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ import --file /usr/local/import-file --catalogName sampleCatalog
gicadm importタスクの実行中にプロキシ・サーバーが停止すると、グローバル索引カタログ・ワークフロー要素は無効になります。この場合、次のようにdsconfigを使用して、グローバル索引カタログ・ワークフロー要素を再度有効にします。ここで、sampleCatalogはグローバル索引カタログの名前です:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-workflow-element-prop --element-name sampleCatalog set enabled:true
グローバル索引カタログのコンテンツをディレクトリにエクスポートするには、gicadmコマンドをexportサブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
export --exportDirectory directory-path --catalogName sampleCatalog
グローバル索引カタログを分散要素に関連付けるには、gicadmコマンドをassociateサブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
associate --catalogName sampleCatalog --distributionWorkflowElement element-name
グローバル索引カタログを分散ワークフロー要素に関連付けると、グローバル索引カタログが分散のプロパティにリストされるようになります。分散に関連付けるグローバル索引カタログを確認するには、dsconfig get-workflow-element-propコマンドを使用します。ワークフロー要素の詳細は、第17.1.8項「dsconfigを使用したワークフロー要素の構成」を参照してください。
グローバル索引カタログの分散トポロジへの関連付けを解除するには、グローバル索引カタログが関連付けられている分散ワークフロー要素を確認する必要があります。対象のグローバル索引カタログを使用している分散ワークフロー要素の名前を確認するには、dsconfig --get-workflow-element-propコマンドを使用して、分散トポロジのプロパティを表示します。
グローバル索引カタログの分散ワークフロー要素への関連付けを解除するには、gicadmコマンドをdisassociateサブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
disassociate --distributionWorkflowElement element-Name
たとえば新規属性をマップするために、新規グローバル索引を既存のグローバル索引カタログに追加するには、次のプロシージャを使用します。このプロシージャによって、グローバル索引が作成され、グローバル索引カタログに追加されます。グローバル索引カタログには追加することなく、グローバル索引を作成することはできません。
開始する前に、グローバル索引カタログを構成しておく必要があります。
gicadmコマンドをadd-indexサブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ add-index --catalogName sampleCatalog --attributeName telephoneNumber
gicadmコマンドをremove-indexサブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ remove-index --catalogName sampleCatalog --attributeName telephoneNumber
高可用性を確保するために、グローバル索引カタログをレプリケートする必要があります。標準のハードウェア・ロード・バランサを使用できます。グローバル索引カタログのレプリケーションは、第3.2.7項「構成7: レプリケートされる複数のプロキシ」で示しているように、デプロイメント内で構成できます。
この項には次のトピックが含まれます:
次の手順に従って、図18-1に示しているように、3つのプロキシ・インスタンスが設定されたレプリケート・トポロジを作成し、グローバル索引カタログのレプリケーションを有効にします。
サーバー・トポロジに、少なくとも2つのプロキシ・インスタンスをインストールします。
これらのインスタンスは、冗長性のために、個別の物理マシンに配置する必要があります。
トポロジ内のプロキシのインスタンスごとに1つのグローバル索引カタログを構成して、1つ以上のグローバル索引を追加します。
gicadmコマンドを使用したグローバル索引カタログの構成の詳細は、第18.1.7.1.1項「グローバル索引が含まれるグローバル索引カタログを作成するには」を参照してください。
グローバル索引カタログのレプリケーションを有効にします。
トポロジ全体で、グローバル索引カタログがレプリケートされるプロキシ・インスタンスは、CLI構文においては、localインスタンスと見なされますが、コマンドで宣言されたその他のプロキシ・インスタンスはremoteインスタンスと見なされます。gicadm enable-replicationコマンド実行の詳細は、第18.1.7.2.2項「グローバル索引カタログのレプリケーションを有効にするには」を参照してください。
レプリケート・トポロジに含まれるプロキシごとにこの手順を繰り返します。
レプリケーションを初期化するプロキシ・インスタンスを選択します。グローバル索引カタログのコンテンツが最新となっているプロキシ・インスタンスを確認します。
あるいは、トポロジに含まれる各プロキシにLDIFファイルをインポートできます。第18.1.7.1.8項「グローバル索引カタログにコンテンツをインポートするには」を参照してください。
前の手順で選択したプロキシ・インスタンスで、gicadm initialize-replication --allコマンドを実行します。詳細は、第18.1.7.2.3項「グローバル索引カタログのレプリケーションを初期化するには」を参照してください。
|
注意: レプリケートされた複数のリモートLDAPサーバーで1つのグローバル索引カタログを使用する際に、書込み操作で同一の値を同時に変更できる上に、その値が索引付けされている場合は、1つのリモートLDAPサーバーのみでそれらの書込み操作を処理する必要があります。このためには、ロード・バランシング・ワークフロー要素の重みを、すべての書込みトラフィックが同一サーバーに送られるように設定できます。詳細は、第18.1.3.5項「ロード・バランシングのプロパティの変更」を参照してください。 |
このコマンドでは、レプリケーションが構成されますが、レプリケーションの初期化は行われません。このコマンドは、-hオプションによって宣言されたローカル・ホストで、そのローカル・ホストの管理ポートを使用して実行されます。リモート・ホストは、--remoteHostオプションによって宣言されますが、完全修飾ホスト名またはIPアドレスである必要があります。このコマンドによって、バインドIDがadminUIDであるグローバル索引カタログ・レプリケーション管理者が作成されます。
インストール時にグローバル索引カタログを作成した場合は、グローバル索引管理者はすでに作成されており、このパスワードはディレクトリ・マネージャのものと同じです。グローバル索引を使用した分散デプロイメントのインストールの詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドの単純な分散の構成に関する項を参照してください。
グローバル索引カタログのレプリケーションを有効にするには、gicadm enable-replicationコマンドを使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ enable-replication --catalogName sampleCatalog --adminUID adminUID --localReplicationPort 8989 --remoteReplicationPort 8989 \ --remoteAdminPort 4444 --remoteHost host
このコマンドによって、ローカル・ホスト上のsampleCatalogというグローバル索引カタログのコンテンツをレプリケートするようプロキシ構成が更新されます。トポロジ内のいずれかのプロキシ・インスタンスですでにグローバル索引カタログがレプリケートされている場合、このコマンドによってトポロジ内のその他すべてのプロキシ・インスタンスの構成が更新されます。このため、トポロジ内の最初の2つのプロキシ・インスタンスに対してgicadm enable-replicationを実行した後は、トポロジを拡張するために追加される新規プロキシ・インスタンスごとにこのコマンドを1回実行すれば十分です。
このコマンドを実行するプロキシ・インスタンスのレプリケーション・ポートを--localReplicationPortオプションで宣言しておく必要があります。このローカル・インスタンスのグローバル索引カタログが、後でgicadm initialize-replicationコマンドによってトポロジ全体にレプリケートされることになります。--remoteReplicationPortオプションによって、sampleCatalogというグローバル索引カタログのコンテンツが、このローカル・インスタンスからリモート・インスタンスにレプリケートされます。--remoteAdminPortは、リモート・プロキシ・インスタンスの管理ポートです。
ファイルに格納されている、ローカル・プロキシ・インスタンスのパスワードを--adminPasswordFileサブオプションを使用して宣言できます。
オプションで、--remoteBindDNサブオプションを使用してリモート・サーバーへのバインドのためのDNを、および--remoteBindPasswordFileサブオプションを使用してファイル内の、リモート・プロキシ・インスタンスのパスワードを宣言できます。これらを宣言しないと、--adminUIDによって宣言されたグローバル管理者がバインドに使用されます。
またオプションで、--localSecureReplicationサブオプションを使用してローカル・サーバーのレプリケーションポートを通した通信、および--remoteSecureReplicationサブオプションを使用してリモート・サーバーのレプリケーション・ポートを通した通信のセキュリティの確保を必須とすることもできます。
このコマンドによって、-hオプションによって宣言されたサーバー上のプロキシ・インスタンスから、トポロジに含まれるすべてのインスタンスへのsampleCatalogというグローバル索引カタログのコンテンツが初期化されます。指定するポートは管理ポートであり、レプリケーション・ポートではありません。
レプリケーション・トポロジに含まれるすべてのプロキシ・インスタンスへのグローバル索引カタログのレプリケーションを初期化するには、次のように、gicadm initialize-replication --allを使用します:
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ initialize-replication --catalogName sampleCatalog \ --adminUID adminUID --all
gicadm status-replicationコマンドを使用して、レプリケーションが完了したことを確認します。
レプリケーションが完了していない場合は、トポロジ内のすべてのプロキシ・インスタンスのステータスがrunning replicatedとなっています。
たとえばパッチを適用した後に、トポロジ内のプロキシ・インスタンスを再起動する前に、レプリケーションが完了している必要があります。
gicadm status-replicationコマンド使用の詳細は、第18.1.7.2.5項「レプリケートされたグローバル索引カタログ構成のステータスを表示するには」を参照してください。
グローバル索引カタログのレプリケーションを無効にするには、gicadm disable-replicationコマンドを使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ disable-replication --catalogName sampleCatalog --adminUID adminUID
gicadm disable-replicationコマンドは、トポロジ内の、レプリケーションを無効にするプロキシ・インスタンスごとに実行する必要があります。
レプリケートされたグローバル索引カタログの基本構成情報を表示するには、gicadm status-replicationコマンドを使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ status-replication --catalogName sampleCatalog --adminUID adminUID
カタログ名を宣言しないと、レプリケートされたすべてのグローバル索引カタログのステータス情報が表示されます。
レプリケーション・ログは、レプリケーション修復ログに格納されます。変更は変更ログに記録されます。これらのログへのアクセスの詳細は、第32.5.4項「ログへのアクセス」を参照してください。
グローバル索引カタログをレプリケートする場合は、変更ログ用のディスク領域をプロビジョニングしてください。デフォルトで、これらのログには変更が24時間格納されます。300,000回の書込み操作に、訳100MBが必要です。デフォルト値の24時間では、その期間に予期されるサービスのサイズに基づいてログを構成する必要があります。ヒントとして、24時間で1秒当たり5000回の変更につき約150GBのプロビジョニングが考えられます。ログを構成する方法の詳細は、第32.3項「ログの構成」を参照してください。
この項では、レプリケーション・トポロジでイベントが発生した場合の典型的なライフサイクルの例をいくつか示します。これらすべての例で使用している基本のレプリケーション・トポロジは、第18.1.7.2.1項「レプリケート・トポロジを作成して、グローバル索引カタログのレプリケーションを有効にするには」で作成したものです。
例18-2 レプリケート・トポロジでグローバル索引カタログを再起動するには
図18-2で示している例では、3つのプロキシ・インスタンスが、レプリケートされたグローバル索引カタログを指定して実行されています。プロキシ・インスタンス3がなんらかの理由でダウンするか停止した場合、次の手順に従って、3つのプロキシ・インスタンスがレプリケートされていることを確認します。
プロキシ・インスタンス3で、start-dsコマンドを発行します。
第18.1.7.2.5項「レプリケートされたグローバル索引カタログ構成のステータスを表示するには」に示されているように、gicadm status-replicationコマンドを実行することによって、レプリケーションが完了しているかどうかを確認できます。
例18-3 レプリケートされたグローバル索引カタログ・トポロジへのグローバル索引の追加
図18-3で示している例では、3つのプロキシ・インスタンスが、レプリケートされたグローバル索引カタログを指定して実行されています。レプリケートされたグローバル索引カタログに、追加の属性(たとえば、mail)を追加するには、次の手順に従います。
まず、3つのプロキシ・インスタンスそれぞれで、gicadm add-index mailコマンドを実行します。
分散ルートの下のディレクトリ・データをいずれかのリモートLDAPサーバーからfile1という名前のLDIFファイルに、export-ldifを使用してエクスポートします。
split-ldifを実行して、指定したディレクトリにGICコンテンツを生成します。
プロキシ・インスタンス1で、コマンドgicadm import --importDirectory directory-nameを実行します。
プロキシ・インスタンス1で、gicadm initialize-replication --allコマンドを実行します。このコマンドによって、変更が、プロキシ1からトポロジ内のその他すべてのプロキシにプッシュされ、新規グローバル索引が追加されます。
例18-4 レプリケートされたグローバル索引カタログのコンテンツの上書き
図18-4で示している例では、3つのプロキシ・インスタンスが、レプリケートされたグローバル索引カタログを指定して実行されています。プロキシ・インスタンス2および3のグローバル索引カタログのコンテンツをインスタンス1のグローバル索引カタログのコンテンツで上書きするには、次の手順に従います。
プロキシ・インスタンス1で、gicadm initialize-replication --allコマンドを実行します。これによってプロキシ・インスタンス2および3のグローバル索引カタログのコンテンツが、プロキシ・インスタンス1のグローバル索引カタログのコンテンツに置き換わります。
例18-5 レプリケート・トポロジへのプロキシの追加
図18-5で示している例では、3つのプロキシ・インスタンスが、レプリケートされたグローバル索引カタログを指定して実行されています。レプリケートされたグローバル索引カタログが指定された4つ目のプロキシ・インスタンスを追加するには、その新規プロキシ・インスタンスについて次の手順を実行します。
新規のプロキシ・インスタンス4で、gicadm create-catalogコマンドを実行します。
コマンドgicadm add-index cn、gicadm add-index snおよびgicadm add-index mailを実行します。
gicadm associateコマンドを実行します。
次のコマンドを実行します:
gicadm enable-replication --localReplicationPort replication port of instance 4 --remoteHost name or IP address of host running instance 1
このコマンドによって、インスタンス1からインスタンス4までのレプリケーションが構成されます。
initialize replication --from proxy 1コマンドを実行します。
Oracle Unified Directoryディレクトリ・サーバーをLDAPデータ・ソースとして指定してプロキシ・サーバーを使用する場合、プロキシ・サーバーとディレクトリ・サーバーとの間の接続をディレクトリ・サーバーの管理IDを使用してバインドする必要があります。そうしない場合は、グローバル索引カタログが正常に機能できるようにディレクトリ・サーバーに一定の構成が必要です。
制御のグローバルACIが変更されていない場合は、ldapmodifyコマンドを使用して、次の変更をディレクトリ・サーバーに適用します:
dn: cn=Access Control Handler,cn=config changetype: modify add: ds-cfg-global-aci ds-cfg-global-aci: (targetcontrol="2.16.840.1.113730.3.4.2 || 2.16.840.1.113730.3.4.17 | | 2.16.840.1.113730.3.4.19 || 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 | | 2.16.840.1.113730.3.4.16 || 1.3.6.1.1.13.1 || 1.3.6.1.4.1.42.2.27.9.5.9") (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";) ds-cfg-global-aci: (targetattr="createTimestamp||creatorsName||modifiersName| |modifyTimestamp||entryDN||entryUUID||subschemaSubentry||aclRights||aclRightsInfo") (version 3.0; acl "User-Visible Operational Attributes"; allow (read,search,compare) userdn="ldap:///anyone";)
Oracle Unified Directory 11g R1ディレクトリ・インスタンスからACIを削除するには、次のACIを削除する必要があります:
dn: cn=Access Control Handler,cn=config changetype: modify delete: ds-cfg-global-aci ds-cfg-global-aci: (targetcontrol="2.16.840.1.113730.3.4.2 || 2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 || 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 || 2.16.840.1.113730.3.4.16") (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";) ds-cfg-global-aci: (targetattr="createTimestamp||creatorsName||modifiersName||modifyTimestamp||entryDN||entryUUID||subschemaSubentry")(version 3.0; acl "User-Visible Operational Attributes"; allow (read,search,compare) userdn="ldap:///anyone";)
Oracle Unified Directory 11g R2ディレクトリ・インスタンスからACIを削除するには、次のACIを削除する必要があります:
dn: cn=Access Control Handler,cn=config changetype: modify delete: ds-cfg-global-aci ds-cfg-global-aci: (targetcontrol="2.16.840.1.113730.3.4.2 || 2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 || 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 || 2.16.840.1.113730.3.4.16 || 2.16.840.1.113894.1.8.31") (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";)
前述のコマンドで指定されているOIDは、Oracle Unified Directoryの未変更の構成に適しています。デフォルトのOIDが変更されている場合は、適切なOIDを含めるようコマンドを変更します。
グローバル索引カタログには次の制御が必要です:
読込み前制御、OID = 1.3.6.1.1.13.1
CSN制御、OID = 1.3.6.1.4.1.42.2.27.9.5.9
複数値属性のコンテンツの取得で、多数の値が返されることになる場合があります。Microsoft Active Directoryサーバーでは、1回の問合せで取得できる属性値の最大数が制限されます。
Microsoft Active Directoryでは、複数値属性のすべての値を取得できる範囲取得メカニズムを使用できます。このメカニズムでは、検索リクエストで、値のクライアント指定のサブセットを取得できます。複数の検索リクエストを実行し、各リクエストで個別のサブセットを取得することによって、属性の完全な値セットを取得できます。
Oracle Unified Directoryは、Microsoft Active Directoryページングのサポートを提供することによって、Active Directoryの範囲取得に対応します。Microsoft Active Directoryページングの主な目的は、返された属性のオプションの中に範囲オプションがあるかどうかを検出すること、およびMicrosoft Active Directoryサーバーから完全な範囲の属性値を取得することです。この完全な属性値セットが返されると、クライアント・アプリケーションでは範囲オプションを処理する必要がなくなります。
Microsoft Active Directoryページングは、ワークフロー要素チェーンのリーフがActive Directoryサーバーに接続されている場合にのみ関連するワークフロー要素として実装されます。Active Directoryページング・ワークフロー要素の次のプロパティを構成できます:
チェーン内の次のワークフロー要素(このワークフロー要素はリーフ・ワークフロー要素ではないため)
範囲オプションを検出するための属性のスキャン処理を軽減できるオプションの属性リスト
Microsoft Active Directoryページングのサポートを構成するには、LDAPプロキシ・ワークフロー要素を指すActive Directoryページング・ワークフロー要素を作成して有効にします。
次の例では、LDAPプロキシ・ワークフローproxy-we1を指すad-paging-we1という名前のActive Directoryページング・ワークフロー要素が作成されます。
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --element-name ad-paging-we1 --type ad-paging \ --set next-workflow-element:proxy-we1 --set enabled:true
効率性を高めるために、ワークフロー要素のhandled-attributes複数値プロパティを設定することによって特定の属性のみがスキャンされるようActive Directoryページング・ワークフロー要素を構成できます。このプロパティの値は必要な数だけ追加できます。
デフォルトで、すべての属性がスキャンされます。これは、パフォーマンスに直接影響を与える可能性があります。パフォーマンスの影響を軽減するために、handled-attributesプロパティの値としてスキャンする必要のある属性のみをリストします。
次の例では、memberOf属性のみがスキャンされるように、前の例で作成したワークフロー要素が変更されています:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-workflow-element-prop --element-name ad-paging-we1 \ --set handled-attributes:memberOf
dsconfigを使用したパススルー認証の構成パススルー認証を構成する手順は次のとおりです。
シナリオに応じて、第18.1.9.1項「パススルー認証の構成の前提条件」で説明している手順を実行します。
パススルー認証を構成します。詳細は、第18.1.9.2項「dsconfigコマンドを使用したパススルー認証の構成」を参照してください。
パススルー認証のワークフロー要素を使用して、ワークフローを作成します。
手順3で作成したワークフローを、既存の、または新しいネットワーク・グループに挿入します。
次の例では、dsconfigコマンドを使用したパススルー認証を構成する方法を説明します。パススルー認証の詳細は、第12.7項「パススルー認証の理解」を参照してください。
この項には次のトピックが含まれます:
パススルー認証を構成する際は、次の点に注意してください。
認証プロバイダのワークフロー要素を作成または識別します。
資格証明がリモートLDAPサーバーに格納されている場合、このリモート・サーバーに対するLDAPサーバー拡張およびプロキシLDAPワークフロー要素を作成し、このLDAPワークフロー要素をauth-provider-workflow-elementとして使用する必要があります。詳細は、第18.1.9.2.1項「リモートLDAPサーバーを使用したパススルー認証の構成」を参照してください。
remote-root-dnパラメータおよびremote-root-passwordパラメータを構成し、client-cred-mode=use-client-identityバインド・モードを設定する必要があることに注意してください。
LDAPサーバー拡張の作成方法の詳細は、第18.1.1.2.4項「LDAPサーバー拡張を作成するには」を参照してください。
資格証明がKerberosサーバーに格納されている場合、Kerberosワークフロー要素を作成し、このKerberosワークフロー要素を手順1のauth-provider-workflow-elementとして使用する必要があります。詳細は、第18.1.9.2.2項「Kerberosワークフロー要素を使用したパススルー認証の構成」を参照してください。
ユーザー・プロバイダのワークフロー要素を作成または識別します。
ユーザー・エントリがリモートLDAPサーバーに格納されている場合、このリモート・サーバーに対するLDAPサーバー拡張およびプロキシLDAPワークフロー要素を作成し、このLDAPワークフロー要素をuser-provider-workflow-elementとして使用する必要があります。詳細は、第18.1.9.2.1項「リモートLDAPサーバーを使用したパススルー認証の構成」を参照してください。
remote-root-dnパラメータおよびremote-root-passwordパラメータを構成する必要があることに注意してください。
LDAPサーバー拡張の作成方法の詳細は、第18.1.1.2.4項「LDAPサーバー拡張を作成するには」を参照してください。
ユーザー・エントリがローカルに格納されている場合、ローカル・バックエンド・ワークフロー要素を作成し、このローカル・バックエンド・ワークフロー要素をuser-provider-workflow-elementとして使用する必要があります。詳細は、第18.1.9.2.1項「リモートLDAPサーバーを使用したパススルー認証の構成」を参照してください。
dsconfigコマンドを使用したパススルー認証の構成次の例では、資格証明とベースDN dc=auth,dc=comを格納したリモートLDAPサーバーを使用して、パススルー認証を構成します。Oracle Unified Directoryインスタンスはdc=user,dc=com接尾辞の下にユーザー・エントリをローカルに格納します。
ここでは、リモートLDAPサーバーは認証サーバーとして動作し、Oracle Unified Directoryはユーザー・サーバーとして動作します。
次の各プロシージャで使用するすべてのコマンドで、プロキシ・ホスト名(-h)、プロキシ管理ポート(-p)、バインドDN(-D)およびバインド・パスワード・ファイル(-j)が指定されます。各例では、すべての証明書を信頼するために-Xオプションが使用されます。
この項には次のトピックが含まれます:
リモートLDAPサーバーを使用してパススルー認証を構成する手順は、次のとおりです。
資格証明を格納しているLDAPサーバーのLDAPサーバー拡張を作成します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" \ -j pwd-file -X -n create-extension --extension-name authServer \ --type ldap-server --set enabled:true \ --set remote-ldap-server-address:authHostname \ --set remote-ldap-server-port:1389 \
LDAPサーバー拡張の作成方法の詳細は、第18.1.1.2.4項「LDAPサーバー拡張を作成するには」を参照してください。
手順1で作成したLDAPサーバー拡張を使用して、プロキシLDAPワークフロー要素を作成します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --element-name authProxy --type proxy-ldap \ --set enabled:true --set client-cred-mode:use-client-identity \ --set ldap-server-extension:authServer \ --set remote-root-dn:cn=administrator,cn=users,dc=auth,dc=com \ --set remote-root-password:********
プロキシLDAPワークフロー要素の作成方法の詳細は、第18.1.1.3.3項「プロキシLDAPワークフロー要素を作成するには」を参照してください。
ローカル・バックエンド・ワークフロー要素を作成して、dc=user,dc=com接尾辞の下にユーザー・エントリをローカルに格納します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --element-name userWfe --type db-local-backend \ --set enabled:true --set base-dn:"dc=user,dc=com"
パススルー認証のワークフロー要素を作成します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --element-name ptaWfe \ --type pass-through-authentication --set enabled:true \ --set auth-provider-workflow-element:authProxy \ --set user-provider-workflow-element:userWfe \ --set pta-auth-suffix:dc=auth,dc=com --set pta-suffix:dc=user,dc=com \ --set pta-user-suffix:dc=user,dc=com
Kerberosワークフロー要素を使用してパススルー認証を構成する手順は、次のとおりです。
Kerberos認証プロバイダのワークフロー要素を作成します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --type kerberos-auth-provider \ --element-name kerberosWfe --set enabled:true
ローカル・バックエンド・ワークフロー要素を作成して、dc=user,dc=com接尾辞の下にユーザー・エントリをローカルに格納します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --element-name userWfe --type db-local-backend \ --set enabled:true --set base-dn:dc=user,dc=com
パススルー認証のワークフロー要素を作成します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --element-name ptaWfe \ --set auth-provider-workflow-element:kerberosWfe --set enabled:true \ --set user-provider-workflow-element:userWfe --type pass-through-authentication
dsconfigを使用した仮想ACIの構成各ワークフローは、このワークフローで処理される操作に適用されるACIのリストを定義しているアクセス制御グループに関連付けられます。
デフォルトでは、ローカル・バックエンドと呼ばれるアクセス制御グループが作成されます。このアクセス制御グループには、ユーザー・データから取得されたすべてのACIが含まれています。「名前」属性は削除できません。ワークフローの仮想ACIが無効化されている場合、そのワークフローのアクセス制御グループとしてローカル・バックエンドを指定する必要があります。仮想ACIが無効になるワークフローの場合、任意のアクセス制御グループを使用できます。
この項では、ワークフローの仮想ACIの構成方法について説明します。この項の内容は次のとおりです。
特定のワークフローの仮想ACIを有効にするには、次のコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-workflow-prop --workflow-name workflow1 --set virtual-aci-mode:true \ --set access-control-group:group1
この例では、group1はアクセス制御グループを参照します。このアクセス制御グループは、デフォルトで作成されたローカル・バックエンドまはたそれ以外の作成済のアクセス制御グループのいずれかにすることができます。アクセス制御グループの作成の詳細は、第17.1.11項「dsconfigによるアクセス制御グループの構成」を参照してください。
特定のワークフローの仮想ACIを無効にするには、次のコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-workflow-prop --workflow-name workflow1 --set virtual-aci-mode:false \ --set access-control-group:"Local Backends"
|
注意: ワークフローの仮想ACIを無効にする際は、次の点に注意してください。
|
dsreplicationコマンドの--advancedモードによって、仮想ACIのレプリケーションを構成できます。
仮想ACIのレプリケーションを構成する手順は、次のとおりです。
仮想ACIのレプリケーションを有効化します。
$ dsreplication enable \ --host1 host1 --port1 4444 --bindDN1 "cn=Directory Manager" \ --bindPasswordFile1 pwd-file1 --replicationPort1 8989 \ --host2 host2 --port2 4444 --bindDN2 "cn=Directory Manager" \ --bindPasswordFile2 pwd-file2--replicationPort2 8989 \ --adminUID admin --adminPasswordFile admin-pwd-file \ --advanced --baseDN virtual-acis -X -n
レプリケーションを初期化します。
$ dsreplication initialize --advanced --baseDN virtual-acis \ --adminUID admin --adminPasswordFile admin-pwd-file \ --hostSource host1 --portSource 4444 \ --hostDestination host2 --portDestination 4444 -X -n
この項では、Oracle Directory Services Managerを使用して管理できるプロキシ・サーバー構成の要素について説明します。この項の内容は次のとおりです:
ロード・バランシングまたは分散を構成せずにプロキシ・サーバー・インスタンスを設定した場合は、ODSMを使用してロード・バランシングを構成できます。開始する前に、ロード・バランシング・デプロイメントを構成しているコンポーネントについて理解しておくと便利です。詳細は、第3.2.1項「構成1: 単純なロード・バランシング」を参照してください。
ODSMを使用してロード・バランシングを構成するには、次の手順を実行します:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」で示しているように、ODSMからプロキシ・サーバーに接続します。
「ホーム」タブを選択します。
「構成」項目の「ロード・バランサの設定」を選択します。
「ロード・バランシング: バックエンド・サーバー」画面で、次の情報を入力します:
「ロード・バランシング名」フィールドに、このロード・バランシング・ワークフロー要素の名前を入力します。
「追加」をクリックして、クライアント・リクエストのロード・バランシング対象とする少なくとも2つのレプリケート済バックエンドLDAPサーバーの接続詳細を入力します。
ODSMでは、アクセス可能かどうかを確認するために、これらのバックエンドLDAPサーバーへの接続が試行されます。接続試行が失敗した場合、それでもそのサーバー詳細を使用するか、それとも接続詳細を確認するかを尋ねるプロンプトが表示されます。
すべてのバックエンドLDAPサーバーを追加したら、「次へ」をクリックして続行します。
「ロード・バランシング: オプション」画面で、次の情報を入力します:
「ロード・バランシング・アルゴリズム」を選択します。
選択したロード・バランシング・アルゴリズムに応じて、各バックエンドLDAPサーバーの関連する重みまたは優先度を指定します。
ロード・バランシング・アルゴリズムの詳細は、第12.1項「プロキシを使用したロード・バランシング」を参照してください。
ロード・バランシングのオプションを指定したら、「次」をクリックして続行します。
「ロード・バランシング: ネーミング・コンテキスト」画面で、「追加」をクリックして、対象のプロキシ・インスタンスで対応する少なくとも1つのネーミング・コンテキスト、つまり接尾辞を指定します。
必要なネーミング・コンテキストをすべて追加したら、「次」をクリックして続行します。
「ロード・バランシング設定: サマリー」画面で、ロード・バランシング構成を確認し、「終了」をクリックして構成を完了します。
ロード・バランシングを構成した後は、ODSMの「構成」タブで構成の任意の側面を変更できます。
ロード・バランシングまたは分散を構成せずにプロキシ・サーバー・インスタンスを設定した場合は、ODSMを使用して分散を構成できます。開始する前に、分散デプロイメントを構成しているコンポーネントについて理解しておくと便利です。詳細は、第3.2.2項「構成2: 単純な分散」を参照してください。
ODSMを使用して分散を構成するには、次の手順を実行します:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」で示しているように、ODSMからプロキシ・サーバーに接続します。
「ホーム」タブを選択します。
「構成」項目の「ディストリビュータの設定」を選択します。
「分散: データのパーティション化」画面で、次の情報を入力します:
「パーティション数」を選択します。
「分散アルゴリズム」を選択します。使用可能な分散アルゴリズムの詳細は、第12.2項「プロキシを使用したデータ分散」を参照してください。
この分散デプロイメントで対応する「ネーミング・コンテキスト」、つまり接尾辞を入力します。
分散を構成する「ネットワーク・グループ」を選択します。
選択した分散アルゴリズムに応じて、各パーティションの容量、DNパターンまたは境界を入力します。
すべてのパーティション詳細を入力したら、「次」をクリックして続行します。
「分散: サーバー・パーティション」で、パーティションごとに「追加」をクリックして、パーティション化されたデータを保持する各バックエンドLDAPサーバーの接続詳細を入力します。
ODSMでは、アクセス可能かどうかを確認するために、これらのバックエンドLDAPサーバーへの接続が試行されます。接続試行が失敗した場合、それでもそのサーバー詳細を使用するか、それとも接続詳細を確認するかを尋ねるプロンプトが表示されます。
必要なサーバーについてすべて追加したら、「次」をクリックして続行します。
「分散: グローバル索引」画面で、グローバル索引の詳細を指定します。グローバル索引の詳細は、第12.3項「グローバル索引カタログ」を参照してください。
グローバル索引を構成したら、「次」をクリックして続行します。
「分散: サマリー」画面で、分散構成を確認し、「終了」をクリックして構成を完了します。
分散を構成した後は、ODSMの「構成」タブで構成の任意の側面を変更できます。
クリティカル度フラグという新規のパラメータを追加して、ワークフローを構成します。デフォルトで、クリティカル度フラグはTrueに設定されます。
次の項では、ODSMを使用してワークフローのクリティカル度を構成する方法を説明します。dsconfigを使用したクリティカル度の構成の詳細は、第18.1.4.6項「ワークフローのクリティカル度の構成」を参照してください。
ODSMを使用してワークフローのクリティカル度を構成するには、次の手順を実行します:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」で示しているように、ODSMからプロキシ・サーバーに接続します。
「構成」タブを選択します。
「コア構成」ビューを選択します。
「ワークフロー」要素で、クリティカル度フラグを設定する、目的のワークフローを選択します。
ワークフローに設定するクリティカル度の値(True、FalseまたはPartial)を選択します。たとえば、選択したワークフロー要素にクリティカル度を設定するには、「True」をクリックします。
ODSMを使用して、Oracle Unified Directoryプロキシ・サーバーのアクセス制御要素を作成できます。このようにするには、次の手順を実行します。
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「コア構成」要素を選択します。
プロパティが右側のペインに表示されます。
「アクセス制御グループ」を開きます。
「追加」をクリックして、プロキシ・インスタンスによって処理されるローカル・バックエンドを1つ以上指定します。
いずれのワークフローにも関連付けられていないこれらのアクセス制御グループを削除する場合は、「削除」をクリックします。アクセス制御グループを削除すると、そのアクセス制御グループに含まれるすべてのACIが削除されます。
ODSMを使用して、Oracle Unified Directoryプロキシ・サーバーの変換ワークフロー要素の作成、変更および削除を実行できます。変換ワークフロー要素の詳細は、第17.2.4項「ODSMを使用したワークフロー要素の構成」を参照してください。
次の各項で、ODSMを使用して変換を構成する方法を説明します。dsconfigを使用した変換の構成の詳細は、第12.6.3.2項「CLIを使用した変換の構成例」を参照してください。
この項には次のトピックが含まれます:
Oracle Unified Directoryプロキシ・サーバーに接続している場合、ODSMを使用して5つの異なるタイプの変換を作成できます。サポートされている変換タイプの詳細は、第12.6.2.1項「変換のタイプ」を参照してください。
|
注意: Oracle Unified Directoryサーバー・インスタンスに接続している場合、変換機能はプロキシ・サーバーでしかサポートされていないため、新規変換を作成するオプションは用意されません。 |
ODSMを使用して変換を作成するには、次の手順に従います:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「コア構成」ビューを選択します。
「作成」メニューから、「変換」を選択します。
「変換」サブメニューから、必要な変換タイプを選択します。
この例では、「アウトバウンド属性追加」変換タイプの次のプロパティを取り上げます。
「名前」フィールドに、変換の名前を入力します。
「条件」リージョンで、次の情報を入力します:
|
注意: 条件はオプションです。ただし、ここで変換レベルで指定するランタイム条件は、変換が使用される変換ワークフロー要素に変換ワークフロー要素レベルで指定される条件と組み合せて使用されます。変換ワークフロー要素の詳細は、第17.2.4項「ODSMを使用したワークフロー要素の構成」を参照してください。 |
「フィルタに一致するエントリ」フィールドに、有効なLDAPフィルタを入力します。
「エントリ親接尾辞」ボックスで、「追加」をクリックして、祖先にする必要のあるDNを指定します。
エントリを選択するには、「選択」をクリックします。
「エントリ・ピッカー」ウィンドウで、「ツリー・ビュー」を選択してディレクトリ・ツリーに移動し、対象のエントリを見つけるか、「検索ビュー」を選択して対象のエントリを検索します。
「除外された操作」リストから、除外する操作を選択します。
「変換定義」リージョンで、次の情報を入力します:
「クライアント属性」フィールドに、クライアント仮想属性の名前を入力します。
クライアント属性エントリを選択するには、「選択」をクリックします。
「属性ピッカー」ウィンドウで、目的のエントリを見つけて選択するか、または「検索」をクリックして目的のエントリを検索します。
「値定義」ボックスで、「追加」をクリックして、クライアント仮想属性の値定義を指定します。
「定義」をクリックして、適切な値定義を入力します。値定義の指定の詳細は、第18.2.5.4項「値定義画面からの値の選択」を参照してください。
「競合動作」リストから、必要な競合動作ポリシーを選択します。
「ソース内の仮想」をクリックして、「はい」に設定します。
「作成」をクリックします。
この項では、変換のプロパティを変更する方法を説明します。この例では、第18.2.5.1項「変換の作成」で作成した「アウトバウンド属性追加」変換タイプのプロパティを変更します。
変換を変更するには、次の手順を実行します:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「コア構成」ビューを選択します。
「変換」要素を開きます。
目的の変換をクリックします。
変更処理を実行できるように、右側のペインに変換構成の詳細が表示されます。
必要な情報を変更します。
「適用」をクリックします。
変換を削除するには、次の手順を実行します:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「コア構成」ビューを選択します。
「変換」要素を開きます。
削除する変換を選択します。
削除する前に確認を求める「構成の削除」ウィンドウが表示されます。
「OK」をクリックします。
値定義ビルダー・サブ画面を使用すると、変換によって追加、マップまたは削除される属性の値を定義できます。
次の値を指定できます:
定数値: 定数値の入力に使用します。
別の属性の値: 処理対象のエントリの既存の属性から新規属性を作成する場合、または別の属性から値をフィルタ処理して取得する場合に使用します。
式の値: 1つ以上の既存の属性の特定の値を操作ることによって、属性値を作成するまたは属性値をフィルタ処理する場合に使用します。
図18-8は、「値定義」画面を示しています。
