この章では、プロキシ・サーバー・インスタンス固有の機能について説明します。内容は次のとおりです:
プロキシを使用して、複数のデータ・ソースまたはレプリケートされたLDAPサーバー間でリクエストをロード・バランシングすることができます。
ロード・バランシング・デプロイメントでは、リクエストは、設定されているロード・バランシング・アルゴリズムに基づいて、データ・ソースの1つにルーティングされます。
次のいずれかのロード・バランシング・アルゴリズムを選択できます:
フェイルオーバー。複数のリモートLDAPサーバーが、特定の操作タイプに対して、サーバー上で構成されている優先度に基づいてリクエストを処理します。エラーが発生すると、その操作タイプに対して次に優先度が高いサーバーに、リクエストが送信されます。
詳細は、第11.1.1項「フェイルオーバー・ロード・バランシング」を参照してください。
最適。複数のリモートLDAPサーバー間に優先度が設けられません。飽和レベルが最も低いLDAPサーバーが、リクエストを処理するサーバーになります。最適なルートが選択されるように、リモートLDAPサーバーの飽和レベルは定期的に再評価されます。
詳細は、第11.1.2項「最適ロード・バランシング」を参照してください。
比例。すべてのリモートLDAPサーバーが、設定された比率(重み)に基づいてリクエストを処理します。
詳細は、第11.1.3項「比例ロード・バランシング」を参照してください。
飽和。飽和制限に達するまで、1つのメインLDAPサーバーがすべてのリクエストを処理します。
詳細は、第11.1.4項「飽和ロード・バランシング」を参照してください。
検索フィルタ。複数のLDAPサーバーがデプロイされ、リクエスト検索フィルタの特定の属性に基づいてリクエストを処理します。詳細は、第11.1.5項「検索フィルタ・ロード・バランシング」を参照してください。
フェイルオーバー・アルゴリズムを使用したロード・バランシングでは、プロキシが、特定の操作タイプ(追加操作など)に対して優先度が一番高いリモートLDAPサーバーまたはデータ・センターにリクエストをルーティングします。リモートLDAPサーバーが停止するまで、プロキシは優先度ルートにリクエストを送信し続けます。これは、ネットワークの切断、ハードウェアの障害、ソフトウェアの障害などの問題が原因になります。フェイルオーバーにより、プロキシは、特定の操作タイプに対する2番目の優先度のサーバーに着信リクエストをルーティングします。
図11-1は、フェイルオーバー・ロード・バランシングの構成を示しています。この例では、3つのルートがあり、それぞれ、操作タイプごとに一意の優先度が設定されています。追加操作はすべて、最高優先度(priority=1
)が設定されているサーバー1によって処理され、バインド操作はサーバー2によって処理されます。サーバー1が停止すると、追加リクエストは、2番目の優先度が設定されているサーバー2に送信されます。
デフォルトでは、停止したサーバーが再度実行しても、プロキシはそのサーバーへのリクエストの再ルーティングをすぐには行いません。たとえば、サーバー1が停止すると、追加リクエストはサーバー2に送信されます。サーバー1が再起動しても、着信した追加リクエストは、サーバー2が処理し続けます。ただし、サーバー2が停止して、サーバー1が再起動している場合、サーバー1が着信リクエストを再び受信するようになります。このデフォルト動作は、switch-back
フラグで変更できます。switch-back
フラグの構成については、第15.1.3.5.2項「switch-back
フラグの設定」を参照してください。
フェイルオーバーを効果的に実行するには、ビジネス・ニーズに合った間隔内でフェイルオーバーが発生するように監視チェック間隔を低く設定する必要があります。監視チェック間隔の詳細は、第29章「Oracle Unified Directoryの監視」を参照してください。
最適ロード・バランシング・アルゴリズムでは、プロキシは、最低飽和レベルのルートにリクエストを送信します。ルート上のリモートLDAPサーバーの飽和レベルが、そのデプロイメントでの他のリモートLDAPサーバーの飽和レベルを超えるまで、プロキシはリクエストをこのルートに送信し続けます。飽和レベルは割合で表されます。
ルートの飽和レベルが変わると、ロード・バランシング・アルゴリズムが最適なルートを再評価し、必要に応じて別のルートを選択します。最低飽和レベルのルートが、常に最適ルートとして選択されます。図11-5の構成では、最低飽和レベルのサーバーはサーバー1であり、この飽和レベルが他のサーバーの飽和レベルを超えるまで、サーバー1がすべてのリクエストを処理します。サーバーの1つが停止すると、その飽和レベルは100%になります。
飽和精度を構成して、ルートが最低飽和レベルのサーバーに切り替わる前の2つのサーバー間の飽和レベルの差を設定できます。デフォルトでは、飽和精度は5に設定されています。ただし、アルゴリズムがサーバー間で頻繁に切り替わっている場合は、飽和精度を10に設定できます。飽和精度はLDAPサーバーの拡張で設定します。詳細は、第15.1.3.5.3項「最適アルゴリズムまたは飽和アルゴリズムでの飽和精度の設定」を参照してください。
飽和レベルは、接続プール内の使用中の接続数と、その構成済の最大サイズとの割合を示します。接続プールの最大サイズは、LDAPサーバー拡張オブジェクトの拡張パラメータの1つです。
使用中の接続数が、最大プール・サイズの2で割った数より小さい場合、飽和は0
になります。これは、プールが飽和していないことを意味します。
接続の半分以上が使用中である場合、次のように飽和レベルが計算されます:
100 * (1 - 使用可能な接続数/(最大プール・サイズ/2))
この計算により、すべての接続が使用中であるとき、飽和レベルが100
になります。
比例ロード・バランシング・アルゴリズムでは、プロキシは、複数のルート間において、設定されている比率に基づいて、リモートLDAPサーバーまたはデータ・ソースにリクエストを転送します。ルートによって処理されるリクエストの比率は、構成内の各ルートに対して設定した重みによって識別されます。重みは整数値で表されます。
ロード・バランシングを構成する際に、各LDAPサーバーが処理するリクエスト比率を示す必要があります。図11-3の例では、2:1という重みが設定されているため、サーバー1は、サーバー2の2倍の数の接続を処理します。サーバー2とサーバー3は、同じリクエスト量を処理します(1:1)。
図11-4に示されているように、クライアント操作の各タイプに対して重みを構成できます。たとえば、サーバー1で全バインド操作を処理するように設定できます。そのためには、バインドの重みをサーバー1は1
(以上)に設定し、サーバー2とサーバー3は0
に設定します。
図11-4の例では、サーバー1は、サーバー2とサーバー3の3倍の追加リクエストを処理します。ただし、サーバー1が処理する検索リクエストは、サーバー2とサーバー3が処理する半分になります。サーバー2とサーバー3は、追加リクエストと検索リクエストについて同じ量を処理しますが、バインド・リクエストは処理しません。
図11-4のように、バインド、追加および検索以外の操作の重みを変更しなければ、サーバーは他のすべての操作(削除など)については、同じロードを共有します。
比例ロード・バランシングにおけるルートの重みの構成の詳細は、第15.1.3.5項「ロード・バランシングのプロパティの変更」を参照してください。
飽和ロード・バランシング・アルゴリズムでは、プロキシは、選択された優先度のルートにリクエストを送信します。そのルートのリモートLDAPサーバーが、設定されている飽和しきい値を超えるまで、プロキシは、その優先度のルートにリクエストを送信し続けます。飽和しきい値は割合で表されます。
たとえば、1つのリモートLDAPサーバーですべての着信リクエストを管理する必要がある場合、このサーバーに優先度1を設定します。飽和索引が70%に達するとリクエストの処理を停止するように同じリモートLDAPサーバーを設定するには、図11-5のように、飽和しきい値を70%に設定します。このようにすると、サーバーは飽和レベルが70%に達するまで、全着信リクエストを処理します。そして、プロキシは、次に優先度の高いサーバー2に、リモートLDAPサーバーへの新しいリクエストをすべて送信します。サーバー2は、サーバー2の飽和しきい値に達するまで、またはサーバー1の飽和レベルが再び低くなるまで、リクエストを処理し続けます。
つまり、サーバー1の飽和レベルが70%に達すると、プロキシはサーバー2にリクエストを送信し始めます。サーバー1が70%のままで、サーバー2が60%に達すると、プロキシは、新しいリクエストをサーバー3に送信します。
ただし、サーバー2がリクエストを処理しているときに、サーバー1の飽和レベルが55%まで落ちると、サーバー2が飽和しきい値に達していない場合でも、プロキシはサーバー1に新しい全リクエストを送信し始めます。
すべてのルートが飽和しきい値に達する場合、プロキシは、飽和レベルが最低のルートを選択します。
サーバーが飽和レベルに達したときに警告を発するように、飽和しきい値アラートを設定することができます。たとえば、飽和しきい値アラートを60%に設定した場合、サーバーがこの値に達すると通知が届き、サーバーのパフォーマンスが低下しすぎないうちに対応策をとることができます。
飽和レベルの決定方法の詳細は、第11.1.2.1項「飽和レベルの決定」を参照してください。
検索フィルタ・ロード・バランシング・アルゴリズムでは、プロキシは、リクエスト検索フィルタで定義されている特定属性に基づいてLDAPサーバーに検索リクエストをルーティングします。
トポロジは、プロキシ経由でアクセス可能な複数のLDAPサーバーで構成されます。すべてのLDAPサーバーには似たデータが含まれますが、各サーバーが、より高いパフォーマンスを提供するように検索フィルタで定義された属性に基づいて最適化されます。各ルートを、許可属性リストと禁止属性リストで構成できます。リクエストの検索フィルタに少なくとも1つの許可属性が含まれ、禁止属性が含まれていない場合に、検索リクエストはルートと一致します。
図11-6は、検索フィルタ・ロード・バランシング・アルゴリズムを示しています。この例では、3つのLDAPサーバーがあり、3つの個別ルートが設定されています。LDAPサーバー1は索引としてuid
属性を持ち、LDAPサーバー2は索引としてcn
属性を持ち、3つ目のLDAPサーバーはパススルー・ルートです。
プロキシが、検索フィルタにuid
属性を含む検索リクエストを受信すると、検索リクエストは、より高いパフォーマンスのためLDAPサーバー1にルーティングされます。同様に、検索フィルタにcn
属性が含まれている場合、検索リクエストはLDAPサーバー2にルーティングされます。他のすべての検索リクエストは、パススルーLDAPサーバー3にルーティングされます。
追加、削除、変更などのその他すべてのリクエストは、優先度ベースでLDAPサーバーにルーティングできます。各検索フィルタ・ルートに優先度が設定されます。この優先度によってルートの評価順序が決まります。検索フィルタに一致し、優先度が一番高いルート・フィルタが、リクエスト処理用に選択されます。すべての検索フィルタ・ルートの優先度が同じ場合、どのルートでもリクエストを処理できます。
Oracle Unified Directoryの分散機能は、水平スケーラビリティなど、全エントリを単一のデータ・ソースまたはLDAPサーバーに格納できない大規模デプロイメントに対応できる機能です。また、分散を使用して、1秒当たりの更新回数を調整することができます。
分散デプロイメントでは、まずデータを小さなチャンクに分割する必要があります。データを分割するには、split-ldif
コマンドを使用します。このようなデータ・チャンクをパーティションと呼びます。通常、各パーティションは別々のサーバー上に格納されます。
データの分割は、次の分散アルゴリズムのいずれかに基づきます:
数値。エントリを、命名属性(たとえばuid)の数値に基づいて、パーティションに分割し、分散します。詳細は、第11.2.1項「数値分散」を参照してください。
辞書編集。エントリを、命名属性(たとえばcn)のアルファベット値に基づいて、パーティションに分割し、分散します。詳細は、第11.2.2項「辞書編集分散」を参照してください。
容量。エントリは、各パーティションの容量に基づいてパーティションに追加されます。このアルゴリズムは、追加リクエストにのみ使用されます。他のすべてのリクエストは、グローバル索引カタログまたはブロードキャストによって分散されます。詳細は、第11.2.3項「容量分散」を参照してください。
DNパターン。エントリを、エントリDNのパターン(値)に基づいて、パーティションに分割し、分散します。詳細は、第11.2.4項「DNパターン分散」を参照してください。
選択するデータ分散タイプは、ディレクトリ・サービス内のデータの編成方法によります。数値分散と辞書編集分散は、特別な分散形式を持ちます。DNパターンは、既存のデータ分散モデルと一致させるのに使用できます。
クライアント・リクエスト(追加以外)が、分散パーティションの1つとリンクできない場合、グローバル索引カタログが構成されていないかぎり、プロキシは、着信リクエストをすべてのパーティションにブロードキャストします。
ただし、リクエストが分散範囲外であることが明確な場合は、このリクエストは、エントリが存在しないことを示すエラーとともに返されます。たとえば、分散パーティションにuidが1-100 (partition1
)と100-200 (partition2
)が含まれている状態で、ベースDNがuid=222,ou=people,dc=example,dc=com
の検索を実行すると、プロキシは、このエントリが存在しないことを示します。
さらに、数値アルゴリズムと辞書編集アルゴリズムの場合、分散ベースDNの直下の最初のRDNが、リクエストの処理用に使用されます。たとえば、次の検索はエラーを返します。uidが分散ベースDN (たとえばou=people,dc=example,dc=com
)の直下の最初のRDNでないためです。
$ ldapsearch -b "uid=1010,o=admin,ou=people,dc=example,dc=com" "objectclass=*"
パーティション数は慎重に決めてください。デプロイメント内のパーティション数を定義する際、後でデータを分割し、新しいパーティションに再分散する場合、ダウンタイムが必要になることを念頭に置いておく必要があります。ただし、初期パーティション外のエントリを持つデータで、新しいパーティションを追加することはできます。
たとえば、初期パーティションが、uidが1-100のデータ(partition1
)と100-200のデータ(partition2
)で構成されている場合に、後で、200-300のuidを含むpartition3
を追加することはできます。ただし、partition1
とpartition2
を分割して、たとえばpartition1
に1-150のuidを含め、partition2
に150-300のuidを含めることは簡単ではありません。パーティションの分割は、新しい分散デプロイメントを再構成するのと実質同じです。
数値アルゴリズムを使用する分散では、プロキシは、リクエスト内の分散ベースDNの直下の最初のRDNの数値に基づいて、リクエストをパーティションの1つに転送します。数値アルゴリズムの分散を設定する場合、選択した属性の数値に基づいてデータベース上のデータをパーティションに分割します。このとき、選択する属性が数値文字列を表すものである必要があります。プロキシは、同じ数値アルゴリズムを使用して、適切なパーティションにすべてのクライアント・リクエストを転送します。
たとえば、図11-7に示されているように、エントリのuidに基づいて、2つのパーティションにデータを分割できます。
この例では、uidが1111
のエントリの検索はパーティション1に送信され、uidが2345
のエントリの検索はパーティション2に送信されます。定義されているパーティション範囲外のuidのエントリに対するリクエストについては、そのエントリが存在していないことが示されます。
注意: 分散アルゴリズムの上限は含まれません。つまり、この例においては、uidが |
例11-1 数値分散アルゴリズムを使用した検索例
次の検索は成功します:
$ ldapsearch -b "uid=1010,ou=people,cn=example,cn=com" "cn=Ben"
ただし、次の検索では、エントリが存在しないことが示されます(結果コード32
):
$ ldapsearch -b "uid=1010,o=admin,ou=people,cn=example,cn=com" "objectclass=*" $ ldapsearch -b "uid=99,ou=people,cn=example,cn=com" "objectclass=*"
プロキシが、上記定義されている分散アルゴリズムでエントリの所属するパーティションを判断できないため、次の検索はブロードキャストされます:
$ ldapsearch -b "ou=people,cn=example,cn=com" "uid=*"
辞書編集アルゴリズムを使用する分散では、プロキシは、リクエスト内の分散ベースDN直下の最初のRDNのアルファベット値に基づいて、リクエストをパーティションの1つに転送します。辞書編集アルゴリズムの分散を設定する場合、選択した属性のアルファベット値に基づいてデータベース上のデータをパーティションに分割します。プロキシは、同じアルゴリズムを使用して、適切なパーティションにすべてのクライアント・リクエストを転送します。
たとえば、図11-8に示されているように、エントリのcnに基づいて、2つのパーティションにデータを分割できます。
この例では、cnがBen
など、B
で始まるエントリに対するリクエストはパーティション1に送信され、cnがM-Y
のエントリに対するリクエストはパーティション2に送信されます。
注意: 分散アルゴリズムの上限は含まれません。つまり、この例において、cn= |
例11-2 辞書編集分散アルゴリズムを使用した検索例
次の検索は成功します:
$ ldapsearch -b "cn=Ben,ou=people,cn=example,cn=com" "objectclass=*"
次の検索も、cn=Ben
が最初のRDNになるので、成功します。
$ ldapsearch -b "uid=1010,cn=Ben,ou=people,cn=example,cn=com" "objectclass=*"
ただし、次の検索では、エントリが存在しないことが示されます(結果コード32
):
$ ldapsearch -b "cn=Ben,o=admin,ou=people,cn=example,cn=com" "objectclass=*" $ ldapsearch -b "cn=Zach,ou=people,cn=example,cn=com" "objectclass=*"
次の検索は、所属するパーティションを判断できないので、ブロードキャストされます:
$ ldapsearch -b "ou=people,cn=example,cn=com" "cn=*"
容量ベースの分散では、プロキシは、各パーティションの容量に基づいて追加リクエストを送信します。これは、パーティションに含めることができるエントリの最大数により判断されます。他のすべてのリクエストは、グローバル索引カタログまたはブロードキャストによって分散されます。
データは完全無作為にパーティションに分散されるため、特定のデータ・エントリが所属するパーティションを識別する最も簡単な方法はグローバル索引を使用する方法です。容量分散を使用する場合は、グローバル索引は必須です。グローバル索引がセットアップされていない場合、追加以外のすべてのリクエストはブロードキャストされます。グローバル索引の詳細は、第11.3項「グローバル索引カタログ」および第15.1.7項「コマンドラインを使用したグローバル索引の構成」を参照してください。
図11-9の例では、パーティション1は、パーティション2の2倍の容量があるので、パーティション1は、パーティション2より2倍の追加リクエストを受信します。この場合、両方のパーティションが同時に一杯になります。すべてのパーティションが一杯になったら、各サイクルで各パーティションに1つのリクエストが送信されます。
DNパターン・アルゴリズムを使用する分散では、プロキシは、リクエスト・ベースDNと文字列パターンとの照合に基づいて、リクエストをパーティションの1つに転送します。照合は、リクエスト・ベースDNの相対部分、つまり、分散ベースDN以下の部分についてのみ行われます。たとえば、図11-10に示されているように、エントリのuid内のDNパターンに基づいて、2つのパーティションにデータを分割できます。
DNパターンを使用する分散は、数値アルゴリズムまたは辞書編集アルゴリズムを使用する分散より面倒です。できるかぎり、別の分散アルゴリズムを使用するようにしてください。
この例では、0、1、2、3または4で終わるuidのすべてのデータ・エントリがパーティション1に送信されます。5、6、7、8または9で終わるuidのデータ・エントリはパーティション2に送信されます。
この分散は、数値を使用していますが、数値分散とはまったく異なります。数値分散では、データは数値の範囲に基づいて分割されますが、DNパターン分散は、データ文字列のパターンに基づきます。
DNパターン・アルゴリズムを使用する分散は、通常、分散パーティションが分散ベースDNに正確に対応していない場合に使用します。たとえば、データが図11-11で示されているように分散されている場合、パーティション1とパーティション2のデータは、ベースDN ou=people,ou=region1
とou=people,ou=region2
の両方に該当します。データを簡単に分散するには、DNパターンを使用する以外方法がありません。
例11-3 地域別分割DNパターン・アルゴリズムの例
情報のデプロイメントが2つの地域で行われている場合、データの分散にはDNパターン分散を使用するのが簡単です。たとえば、従業員番号が4桁コードで、最初の桁が地域を示している場合、次のようになります:
地域1 | 地域2 |
---|---|
1000 |
2000 |
1001 |
2001 |
1002 |
2002 |
1003 |
2003 |
1004 |
2004 |
1005 |
2005 |
1006 |
2006 |
1007 |
2007 |
1008 |
2008 |
1009 |
2009 |
1010 |
2010 |
... |
... |
データのロードを分散するのに各地域内のエントリを2つのサーバーに分割します。このとき、サーバー1には、0、1、2、3および4で終わるすべてのエントリが含まれ、サーバー2には、5、6、7、8および9で終わるすべてのエントリが含まれます(図11-10参照)。
したがって、DNパターン1222
の検索はパーティション1に送信され、2222
も同様です。
分散デプロイメントでグローバル索引カタログを使用できます。容量ベース分散を構成する場合、DNを索引とするグローバル索引カタログをセットアップする必要があります。グローバル索引カタログは、エントリと、そのデータを格納する分散パーティションとをマップします。プロキシはクライアントからリクエストを受信すると、分散が、グローバル索引カタログで属性エントリを検索して、クライアント・リクエストを正しいパーティションに転送します。これにより、ブロードキャストの手間を省くことができます。さらに、DN変更リクエストが行われる場合、グローバル索引カタログにより、そのエントリが確実に存在することを確認することができます。
グローバル索引カタログは、従業員番号や電話番号など、特定の属性に基づいてエントリをマップします。索引とする属性値は、全エントリにおいて一意である必要があります。たとえば、一意でない国などに基づいて、グローバル索引を使用してエントリをマップすることはできません。
値が一意でない属性を索引とした場合、プロキシが、リクエストされるすべてのエントリを返せないことがあります。たとえば、必ずしも一意とはかぎらないmail
属性を索引にしたとします。そして、次の2つのエントリを連続で追加します:
uid=user.1
およびmail=joe.smith@example.com
の属性を持つエントリ1はパーティション1に送信されます。
uid=user.2
およびmail=joe.smith@example.com
の属性を持つエントリ2はパーティション2に送信されます。
この状況では、グローバル索引mail
は、2つ目のエントリへの参照のみを保持します。この場合、フィルタ(mail=joe.smith@example.com)
の検索を実行すると、2つ目のエントリuid=user.2
のみが返されることになります。
グローバル索引カタログには、複数のグローバル索引を含めることができます。各グローバル索引でそれぞれ異なる属性のマッピングを行います。たとえば、電話番号をベースにしたエントリのマッピングを行うグローバル索引と、従業員番号をベースにしたエントリのマッピングを行うグローバル索引を含むGI-catalog
というグローバル索引カタログをセットアップできます。この場合、電話番号または従業員番号のいずれかを使用して、正しいパーティションにクライアント・リクエストを転送できます。
グローバル索引カタログとグローバル索引は、gicadm
コマンドを使用して作成および構成されます。詳細は、第15.1.7項「コマンドラインを使用したグローバル索引の構成」および付録A「gicadm」を参照してください。
グローバル索引には、LDIFファイルからデータを移入できます。1つのLDIFファイルのデータは、split-ldif
コマンドを使用してパーティションに分割できます。詳細は、付録A「split-ldif」を参照してください。
シングル・ポイント障害を回避するために、グローバル索引カタログはレプリケートする必要があります。グローバル索引カタログのレプリケートについては、第15.1.7.2項「グローバル索引カタログのレプリケーション」を参照してください。
例11-4 電話番号のグローバル索引カタログの使用
グローバル索引の作成に使用できる一意の属性の一般的な例は、電話番号です。この属性値は一意になるので、その電話番号を持っている人物(従業員など)は1人のみです。
次の例では、データベース内のエントリは電話番号に基づいて分割されています。グローバル索引には、次の情報が含まれています:
値 | パーティションID |
---|---|
4011233 |
1 |
4011234 |
1 |
7054477 |
2 |
グローバル索引には、従業員名、場所または電話番号に関連付けることのできるその他の属性値は格納されません。属性の索引とパーティションとのマッピングのみが行われます。索引値(ここでは電話番号)に関連付けられているデータは、リモートLDAPサーバー上に置かれています。
1人の従業員が複数の電話番号を持っている場合、複数値エントリとしての扱いになります。この場合、グローバル索引が電話番号に基づいて作成される際、たとえばBen Brownという1人の従業員を検出するグローバル索引エントリが2つできるということになります。
前述の例では、従業員Ben Brownには、4011233
と7054477
の両方の電話番号が割り当てられています。この場合、Ben Brownの1つの電話番号を検索すれば、Ben Brownに2つの電話番号が割り当てられていることとは関係なく、正しいパーティションと、その電話番号に関連付けられている、Ben Brownという名前を含むすべての情報が返されます。
ディレクトリの各エントリは、DNおよび属性と属性値のセットにより識別されます。クライアント側で定義されたDNおよび属性は、サーバー側で定義されたDNおよび属性にマップされない場合があります。たとえば、サンプルAという組織ではdc=parentcompany
, dc=com
というエントリを使用しているとします。ここに、サンプルBという別の組織が加わりました。このサンプルBは、dc=newcompany
, dc=com
というエントリを使用しています。つまり、既存のクライアント・アプリケーションを正しく動かすには、dc=newcompany
, dc=com
をdc=parentcompany
, dc=com
にリネームする必要があります。
DNリネーム・ワークフロー要素を定義して、DNをサーバー側と一致する値にリネームできます。クライアントがリクエストを行うと、DNと属性の名前がサーバー側と一致するように変更されます。結果がクライアントに返されるときには、DNと属性はクライアント側と一致するよう元に戻されます。
Oracle Unified Directoryでは、ディレクトリ情報ツリー(DIT)のコンテンツを、異なるベースDNの別のDITに変換できるDNリネーム・ワークフロー要素が用意されています。ある操作(追加、バインド、削除、変更など)がDNリネーム・ワークフロー要素を通ることにより、DNリネーム構成に従ってパラメータが変換され、仮想エントリから実際のエントリへの変換が行われます。
図11-12は、プロキシを使用したDNリネームの動作を示しています。
クライアントはou=myorg
, dc=server
, dc=com
エントリを待機します。しかし、LDAPサーバー上のエントリはou=people
, dc=server
, dc=com
です。プロキシは、DNリネーム・ワークフロー要素を使用してしてDNのリネームを行います。
この例では、実際のエントリou=people
, dc=server
, dc=com
を、クライアントからはou=myorg
, dc=server
, dc=com
エントリに見えるようにします。
DNリネーム変換は、次のオブジェクトに対して適用可能です:
エントリのDN。たとえば、LDAPサーバー上の実際のエントリであるdn:uid=user
, ou=people
, dc=server
, dc=com
が、クライアントの仮想エントリdn:uid=user
, ou=myorg
, dc=server
, dc=com
に変換されます。
DNを含むエントリの属性。たとえば、オブジェクトクラスinetorgpersonmanager
のエントリのmanager属性のサーバー側の値がmanager:uid=mgr
, ou=people
, dc=server
, dc=com
である場合に、クライアント側の値であるmanager:uid=mgr
, ou=myorg
, dc=server
, dc=com
に変換します。
注意: 変換は、エントリのすべてのユーザー属性に適用できます。このとき、該当する属性リストを定義したり、該当しない属性リストを定義することもできます。 |
Oracle Unified Directoryでは、RDNChanging構成を使用して、ソース・ディレクトリからOracle Unified Directoryに対して、RDN値をリネームまたは置換することが可能です。
図11-13は、プロキシを使用したDNリネームの動作を示しています。
注意: 相対識別名(RDN)は、エントリDNの左端の要素です。たとえば、 |
RDNChanging構成には、次のパラメータがあります:
RDNの名前変更を実行するオブジェクト・クラスのタイプを指定します。デフォルト設定はperson
です。
TrueまたはFalse: クライアント・ビュー内の元のRDN値(source-rdn
パラメータで指定)を新しいRDN値(client-rdn
パラメータで指定)に置き換えるかどうかを指定します。デフォルトの設定はtrue
です。
注意: この値がtrueに設定されており、エントリの新しいRDN属性に複数の値がある場合、Oracle Unified DirectoryではRDNの最初の値が使用されます。 |
Oracle Unified Directoryで置換または変更される、ソース・ディレクトリの元のRDN属性名を指定します。
Oracle Unified Directoryで使用される新しいRDN属性名を指定し、source-rdn構成パラメータで指定されている属性名と置き換えます。
RDNの名前変更を実行するDNを持つ属性のリスト。属性のデフォルト・リストはmember
、manager
およびowner
です。
Oracle Unified Directoryは、ワークフロー要素の定義を介したデータ変換をサポートしています。ワークフロー要素のインスタンスを作成することにより、物理データを異なる方法で表示できます。この章では、Oracle Unified Directoryで変換がどのように発生するのかについて説明します。この章の内容は次のとおりです:
LDAPクライアント・アプリケーションのデータ構造が、LDAPリポジトリのデータ構造と異なる場合があります。スキーマが異なる場合もあれば(エントリ内の属性タイプが異なる)、値が異なる場合もあります(属性名は同じでも値のセマンティクスが異なる)。これが、変換が必要な対象となります。
1つの変換は、特定の方向における特定のアクションを実行します。必要な変換を指定し、既存のワークフロー要素に対する変換を定義します。
この項には次のトピックが含まれます:
変換の方向は、変換がリクエスト中に適用されるのか、応答中に適用されるのか、または両方に適用されるのかを示し、これにより変換モデルが決まります。
変換は次のタイプに分類できます:
読取り変換(アウトバウンド変換): 詳細は、第11.6.1.1.1項「読取り変換」を参照してください。
書込み変換(インバウンド変換): 詳細は、第11.6.1.1.2項「書込み変換」を参照してください。
マッピング変換(双方向変換): 詳細は、第11.6.1.1.3項「マッピング変換」を参照してください。
読取り変換は、一般的に使用される変換です。読取り変換は、リクエストへの応答中にのみ発生します。リクエスト中には変換は行われず、物理データの変更はありません。
図11-14は、読取り変換の概念を示しています。
組織に、personエントリを表示するレガシー・アプリケーションがあるとします。このアプリケーションは、email
属性を含まないエントリをサポートしません。物理データ・ソースはアップグレードされており、email
属性はpersonエントリから削除されています。
そこで、検索応答中にemail
属性を追加するという変換が必要になります。この変換は、データ・ソースから読み取られるエントリを変更し、email
属性を追加します。このとき、この属性値はfirstname.surname@mycompany.com
になります。元に戻す変換は必要ないので、物理データは変更されません。
書込み変換は、応答中ではなく、リクエスト中に適用される変換です。書込み変換は、バックエンドに格納する前に、クライアントによって提供されたデータを変更します。
図11-15は、書込み変換の概念を示しています。
組織に、personエントリをデータ・ソースに追加するレガシー・アプリケーションがあるとします。このアプリケーションは、email
属性なしでエントリを追加します。物理データ・ソースはアップグレードされており、email
属性はpersonエントリの必須属性となっています。そこで、追加リクエスト中にemail
属性を追加するという変換が必要になります。この変換は、データベースに書き込むエントリを変更します。逆の変換は必要ありません。
マッピング変換は、一般的に使用される変換です。これは、まず変換がリクエスト中に適用され、逆の変換が応答中に適用されるという双方向の変換です。このような変換は、物理データ・ビュー内の属性またはエントリが、仮想データ・ビュー内の属性またはエントリにマップされるため、マッピング変換と呼ばれます。マッピング変換では、既存値を、DNコンポーネント、属性タイプまたは値、またはオブジェクト・クラスに割り当てる前に、処理することができます。
図11-16は、マッピング変換の概念を示しています。
組織に、surname
およびfirstname
の属性を持つエントリが格納される物理データ・ソースがあるとします。この組織には、firstname surname
という形式のcn
(共通名)属性を持つエントリを要求するクライアント・アプリケーションがあります。
このクライアント・アプリケーションは、cn=Joe Smith
という形式のエントリの検索リクエストを送信します。変換は、このリクエスト中に名(firstname)と姓(surname)を抽出し、このリクエストをsurname=Smith, firstname=Joe
という形式に変換するように定義されています。対応するエントリは、データ・ソース内にあります。このエントリをクライアント・アプリケーションに戻す前に、逆の変換が実行されます。クライアント・アプリケーションは、認識できるcn=Joe Smith
というエントリを受信します。
このリクエストは、surname=Smith, firstname=Joe
という形式に変換されます。
Oracle Unified Directoryは、プロキシ・サーバーでの変換をサポートするLDAPサーバーです。
変換を実装するには、次のことが必要です:
変換タイプのワークフロー要素のインスタンスを作成します。
目的のワークフロー要素リストに変換ワークフロー要素を挿入します。
Oracle Unified Directoryのアーキテクチャの詳細は、第4.2項「Oracle Unified Directoryのアーキテクチャ」を参照してください。
変換ワークフロー要素インスタンスは、特定の変換アクションが定義されているデータ・ビューのことです。
この項では、変換のワークフロー要素を構成するためのコンポーネントについて説明します。次のトピックが含まれます:
変換タイプのワークフロー要素は、次の変換セットで構成できます:
注意: 説明:
|
この項には次のトピックが含まれます:
addOutboundAttribute
変換タイプこの変換は、検索操作中、リクエスト内の属性リストが未定義(つまり、すべて該当)な場合、またはその属性が含まれている場合に、クライアントに返されるエントリに、仮想属性または値を追加します。
エントリに仮想属性がすでに含まれているかどうか判断できない場合、conflict-behaviorパラメータが、次のポリシーのどれを適用するかを決定します:
仮想値を追加しない
仮想値を追加して、既存値とマージする
既存値を仮想値に置き換える
仮想属性をソース・リポジトリで検索できる場合(ソース・リポジトリ内のエントリの一部に仮想属性が含まれており、この属性について検索が最適化されている)、およびフラグvirtual-in-source
が設定されている場合、変換プロセスは、SEARCH REQUEST
フィルタで仮想属性をソース・リポジトリに転送します。通常、仮想属性はソース・リポジトリに転送されません。このパラメータがFALSE
に設定されている場合、検索リクエストは一般用に最適化されているということです。つまり、仮想属性はソース・リポジトリには存在していないことを意味します。
注意: 追加リクエストまたは変更リクエストに仮想属性を含めることが必要とされる場合は、ソース・スキーマ・チェックが適用されます。したがって、仮想属性を受け入れるようにソースのスキーマを構成することをお薦めします。それ以外の場合は、スキーマ・チェックを無効にしてください。 |
表11-1は、addOutboundAttribute
変換タイプのパラメータを説明しています。
表11-1 addOutboundAttribute変換タイプのパラメータ
パラメータ | dsconfig CLI | 複数(M)/単一(S)値 | オプション(O)/必須(M) | 値 |
---|---|---|---|---|
クライアント仮想属性の名前とクライアント仮想属性の値定義 |
|
S |
M |
文字列 詳細は、第11.6.2.3項「変換のための属性値の定義」を参照してください。 たとえば、 |
競合動作ポリシー |
|
S |
O [デフォルト= |
|
ソース内の仮想ポリシー |
|
S |
O [デフォルト = |
|
エントリが一致する必要があるフィルタベースの条件 |
|
S |
O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用] |
LDAPフィルタ |
祖先である必要があるDNベースの条件 |
|
M |
O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用] |
DN |
処理する操作から操作を除外する条件 |
|
M |
O [デフォルト = すべてのLDAP操作に適用] |
列挙(ADD、MODIFY...) |
filterOutboundAttribute
変換タイプこの変換では、ソースから受信したエントリをクライアントに送信する前に、ここから属性または値を削除します。
表11-2は、filterOutboundAttribute
変換タイプのパラメータを説明しています。
表11-2 filterOutboundAttribute変換タイプのパラメータ
パラメータ | dsconfig CLI | 複数(M)/単一(S)値 | オプション(O)/必須(M) | 値 |
---|---|---|---|---|
ソース仮想属性の名前とクライアント仮想属性の値定義 |
|
S |
M |
文字列 詳細は、第11.6.2.3項「変換のための属性値の定義」を参照してください。 たとえば、 |
エントリが一致する必要があるフィルタベースの条件 |
|
S |
O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用] |
LDAPフィルタ |
祖先である必要があるDNベースの条件 |
|
M |
O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用] |
DN |
処理する操作から操作を除外する条件 |
|
M |
O [デフォルト = すべてのLDAP操作に適用] |
列挙(ADD、MODIFY...) |
addInboundAttribute
変換タイプこの変換は、追加操作の実行中、データをソースに転送する前に、クライアントから受信したエントリに仮想属性または値を追加します。
エントリに仮想属性がすでに含まれているかどうか判断できない場合、conflict-behaviorパラメータが、次のポリシーのどれを適用するかを決定します:
仮想値を追加しない
仮想値を追加して、既存値とマージする
既存値を仮想値に置き換える
表11-3は、addInboundAttribute
変換タイプのパラメータを説明しています。
表11-3 addInboundAttribute変換タイプのパラメータ
パラメータ | dsconfig CLI | 複数(M)/単一(S)値 | オプション(O)/必須(M) | 値 |
---|---|---|---|---|
ソース仮想属性の名前とソース仮想属性の値定義 |
|
S |
M |
文字列 詳細は、第11.6.2.3項「変換のための属性値の定義」を参照してください。 たとえば、 |
競合動作ポリシー |
|
S |
O [デフォルト= |
|
エントリが一致する必要があるフィルタベースの条件 |
|
S |
O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用] |
LDAPフィルタ |
祖先である必要があるDNベースの条件 |
|
M |
O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用] |
DN |
処理する操作から操作を除外する条件 |
|
M |
O [デフォルト = すべてのLDAP操作に適用] |
列挙(ADD、MODIFY) |
filterInboundAttribute
変換タイプこの変換では、追加(および変更)時に、クライアントから受信したエントリ(および変更)をソースに送信する前に、ここから属性または値を削除します。
表11-4は、filterInboundAttribute
変換タイプのパラメータを説明しています。
表11-4 filterInboundAttribute変換タイプのパラメータ
パラメータ | dsconfig CLI | 複数(M)/単一(S)値 | オプション(O)/必須(M) | 値 |
---|---|---|---|---|
クライアント仮想属性の名前とクライアント仮想属性の値定義 |
|
S |
M |
文字列 詳細は、第11.6.2.3項「変換のための属性値の定義」を参照してください。 たとえば、 同様に、 |
エントリが一致する必要があるフィルタベースの条件 |
|
S |
O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用] |
LDAPフィルタ |
祖先である必要があるDNベースの条件 |
|
M |
O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用] |
DN |
処理する操作から操作を除外する条件 |
|
M |
O [デフォルト = すべてのLDAP操作に適用] |
列挙(ADD、MODIFY...) |
mapAttribute
変換タイプこの変換では、両方向において、クライアント属性を1つのソース属性にリネームしたり、値の変換を行うことができます。
表11-5は、mapAttribute
変換タイプのパラメータを説明しています。
表11-5 mapAttribute変換タイプのパラメータ
パラメータ | dsconfig CLI | 複数(M)/単一(S)値 | オプション(O)/必須(M) | 値 |
---|---|---|---|---|
クライアント属性の名前とクライアント仮想属性からソース仮想属性へのマッピングの値定義 |
|
S |
M |
文字列 詳細は、第11.6.2.3項「変換のための属性値の定義」を参照してください。 たとえば、 |
ソース内の仮想ポリシー |
|
S |
O [デフォルト = |
|
競合動作ポリシー |
|
S |
O [デフォルト= |
|
エントリが一致する必要があるフィルタベースの条件 |
|
S |
O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用] |
LDAPフィルタ |
祖先である必要があるDNベースの条件 |
|
M |
O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用] |
DN |
処理する操作から操作を除外する条件 |
|
M |
O [デフォルト = すべてのLDAP操作に適用] |
列挙(ADD、MODIFY...) |
条件付きで変換ワークフロー要素を構成できます。条件は、transformations-workflow-element
または個々のtransformation
に対して設定できるプロパティ(属性)です。変換は、LDAPリクエストがすべての条件およびワークフロー要素レベルで設定されているすべての条件を満たしている場合のみ、実行されます。
変換の実装には、次の条件を使用できます:
変換を実施するかどうかを決定するルールに対して条件を構成できます。
transformations-workflow-elementに対して条件を設定できます。この場合、そのworkflow-elementに設定されているすべての変換に対して条件が照合され、各変換が実際に処理される前に評価されます。
個々の各変換に対しても条件を設定でき、この変換の実際の処理前に評価されます。
条件は、広い意味で次のカテゴリに分類されます:
この条件は、指定されている1つの親接頭辞の下にある名前のエントリをターゲットとするLDAP操作のみに適用される変換に対して使用されます。
このタイプの条件が構成されていない場合、処理されるすべてのエントリに対して変換が適用されます。
この条件は、指定フィルタと一致するエントリに対するLDAP操作にのみ適用される変換に対して使用されます。
このタイプの条件が構成されていない場合、処理されるすべてのエントリに対して変換が適用されます。
この条件は、複数値属性のリストを指定し、各属性が、変換によって影響を受けてはならないLDAP操作を示します。各LDAPプロトコル・メッセージに対する変換(ある場合)のアクションを無効にできます。
このタイプの条件が構成されていない場合、このタイプの変換が通常影響するすべてのLDAP操作に対して変換が実行されます。
属性値により、変換中における仮想属性の値を定義できます。この値は、デフォルト値のままにすることもできますし、他の属性値から値を作成するルールにすることもできます。
addInboundAttribute、addOutboundAttribute
およびmapAttribute
では、追加する仮想属性の値を構成する必要があります。filterInboundAttribute
およびfilterOutboundAttribute
では、フィルタリングする値を構成することもできます。
属性は、次から値を導出できます:
静的なデフォルト値の属性を生成したり、属性の静的な値でフィルタリングする場合に使用します。
たとえば、プロパティsource-attribute:mycompany=Acme
は、デフォルトの会社名を指定する際に使用します。
dsconfig --create-transformation \ --type add-inbound-attribute \ --set source-attribute:mycompany=Acme \ --transformation-name virtDeptName \
%inputAttrName%
構文を使用して、処理対象のエントリ内の既存の属性から新しい属性を作成したり、別の属性から取得する値をフィルタリングできます。
たとえば、プロパティsource-attribute:displayName=%cn%
は、cn
属性の値から新しい属性値を取得する必要があることを示します。
dsconfig --create-transformation \ --type add-inbound-attribute \ --set source-attribute:displayName=%cn% \ --transformation-name virtDeptName \
注意: 同じ |
{expression}
構文を使用して、既存の属性値を操作することにより、属性値を作成したり、属性値をフィルタリングできます。
たとえば、プロパティclient-attribute:mail={%cn%.%sn%@mycompany.com}
は、既存の属性の値を組み合せて属性を導出するための正規表現です。
dsconfig create-transformation \ --type add-outbound-attribute \ --set client-attribute:mail={%cn%.%sn%@mycompany.com} \ --transformation-name virtDeptName \
virtAttrName=%refAttrName%(virtValue1,refValue1)(virtValue2,refValue2)
構文を使用して、別の属性の値のマッピングとして仮想値を定義します。
virtAttrName
パラメータに対して、変換が、refAttrName
から抽出された値を追加またはフィルタリングします。refAttrName
がrefValue1
と一致すれば、変換は、virtValue1
に対する追加またはフィルタリングを行います。指定する値内の文字(、)、,
および\
は\
文字でエスケープ処理する必要があります。
たとえば、複数の部署を持つ組織があり、取得される部署IDにより、部署名が、Department:1–Marketing、2–Sales、3–Financeなどのように返されます。ただし、deptId
が1
の場合、deptName
に対して返される値はMarketing
です。deptId
が2
の場合は、deptName
値はSales
です。同様に、deptId
が3
の場合は、deptName
に対して返される値はFinance
です。
dsconfig --create-transformation \ --type add-outbound-attribute \ --set client-attribute:deptName=%deptId%(Marketing,1)(Sales,2)(Finance,3) \ --transformation-name virtDeptName
virtAttrName=virtAttrValue1=virtAttrValue2=
構文を使用して、複数値仮想属性を指定します。
dsconfig --create-transformation \ --type add-outbound-attribute \ --set client-attribute:countriesResp=France=Germany=Italy \ --transformation-name virtCountriesRep
この項では、変換ワークフロー要素の構成方法について説明します。この項の内容は次のとおりです:
transformations-workflow-element
およびtransformation
は、変換構成の中心的なエントリです。
変換ワークフロー要素は、変換への参照リストを含むコンテナです。1つの変換は複数のtransformation-workflow-element
によって再利用できます。条件は、transformations-workflow-element
またはtransformation
のいずれかに対して設定できるプロパティ(属性)です。
表11-6では、transformations-workflow-element
に対して構成できるパラメータについて説明します。
表11-6 transformations-workflow-elementの構成パラメータ
パラメータ | dsconfig CLI | 複数(M)/単一(S)値 | オプション(O)/必須(M) | 値 |
---|---|---|---|---|
変換タイプのリスト 詳細は、第11.6.2.1項「変換のタイプ」を参照してください。 |
変換オブジェクト(関連付け) |
M |
M |
変換の参照 |
エントリが一致する必要があるフィルタベースの条件 詳細は、第11.6.2.2.2項「エントリ一致フィルタ」を参照してください。 |
|
S |
O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用] |
LDAPフィルタ |
祖先である必要があるDNベースの条件 詳細は、第11.6.2.2.1項「親接頭辞」を参照してください。 |
|
M |
O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用] |
DN |
処理する操作から操作を除外する条件 詳細は、第11.6.2.2.3項「除外LDAP操作」を参照してください。 |
|
M |
O [デフォルト = すべてのLDAP操作に適用] |
列挙(ADD、MODIFY...) |
変換の実行順序は構成できません。たとえば、変換Aと変換Bを使用するtransformation-workflow-element
を使用するとします。このとき、エントリに対して変換Aを先に実行してから変換Bを実行するように指定することはできません。Bの後にAである可能性もあります。
変換の実行順序を定義する必要がある場合、たとえば、変換Aを変換Bの前に実行する必要がある場合は、変換Aを使用するtransformation-workflow-element
を最初に作成することをお薦めします。次に、変換Bを使用する別のtransformation-workflow-element
を作成します。そして、2つ目のtransformation-workflow-element
を最初のtransformation-workflow-element
の後に配置します。
図11-17は、高レベルな構成モデルを示しています。
この項の例は、CLIで変換を作成し、変換ワークフロー要素を作成し、変換を追加し、条件を関連付ける方法について説明します。
次の手順で変換を構成します:
まず、filter-outbound-attribute
タイプの変換を作成します。
$ dsconfig --create-transformation -X -n -Q -p -D cn="directory manager" -j pwd-file \ --set source-attribute:description \ --type filter-outbound-attribute\ --transformation-name fodescription
add-outbound-attribute
タイプの別の変換を作成します。
$ dsconfig --create-transformation -X -n -Q -p -D cn="directory manager" -j pwd-file \ --set client-attribute:legacyemail=%cn%.%sn%@mycompany.com \ --type add-outbound-attribute \ --transformation-name legacyemail
最初の変換でtransformations-workflow-element
を作成し、これを処理フローに追加します。
$ dsconfig --create-workflow-element -X -n -Q -p -D cn="directory manager" -j pwd-file \ --set transformation:legacyemail \ --set set next-workflow-element:pxywfe \ --type transformations \ --element-name trsfwfe
$ dsconfig --set-workflow-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \ --workflow-name pxywf \ --set workflow-element:trsfwfe
2つ目の変換をワークフロー要素に追加します。
$ dsconfig --set-workflow-element-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \ --element-name trsfwfe \ --add transformation:fodescription
cn=users
の下の変換のみ実行するという変換条件を定義します。
$ dsconfig --set-workflow-element-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \ --element-name trsfwfe \ --set entry-parent-suffix:cn=users,dc=oracle
パリにいるユーザーにのみ変換を適用するように設定します。
$ dsconfig --set-workflow-element-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \ --element-name trsfwfe \ --set entry-match-filter:l=Paris
新しいマッピング変換を作成し、これをワークフロー要素に追加します。
$ dsconfig --create-transformation -X -n -Q -p -D cn="directory manager" -j pwd-file \ --set client-attribute:faxnum=%facsimileTelephoneNumber% \ --type map-attribute \ --transformation-name mapfax
$ dsconfig --set-workflow-element-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \ --element-name trsfwfe \ --add transformation:mapfax
この変換が人物に対してのみ適用されるように設定します。
$ dsconfig --set-transformation-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \ --transformation-name mapfax \ --set entry-match-filter:\(objectclass=person\)