Sun Java System Access Manager 7 2005Q4 配備計画ガイド

第 5 章 Access Manager での配備設計

ソリューションライフサイクルの配備設計段階では、ハイレベルの配備アーキテクチャーとローレベルの実装仕様を設計し、ソリューションを実装するために必要な一連の計画および仕様を準備します。この配備設計段階でプロジェクトの承認が行われます。この章は、Sun Java^TM System Access Manager での配備設計に関する次の節で構成されています。

ロードバランサの使用法

ほとんどの配備では、ユーザー要求を 2 つ以上の Access Manager インスタンスに分散するために、Access Manager はロードバランサを使用して設定されます。ロードバランサは、ハードウェア、ソフトウェア、またはその両方の組み合わせを使用して実装できます。次の図は、ロードバランサを使用した Access Manager 配備を示しています。

図 5–1 ロードバランサを使用した Access Manager の設定

スティッキーセッション用のロードバランサの設定

Access Manager とともに配備するロードバランサは、スティッキーセッションをサポートしている必要があります。スティッキーセッションでは、セッションが特定の Access Manager インスタンスによって作成されると、セッション情報を保持するために、ユーザーからのそれ以降の要求は引き続きその同じインスタンスに配信されます。Access Manager は Cookie を使用してセッション情報を中継するため、ロードバランサは、そのセッションを作成した Access Manager インスタンスに要求をリダイレクトする必要があります。スティッキーセッションが存在しない場合は、すべての Access Manager インスタンスを信頼する必要があるため、パフォーマンスが低下します。スティッキーセッションは、setcookie 関数またはロードバランサ Cookie のどちらかを使用して実装できます。

詳細は、「Access Manager でのロードバランサの使用法」を参照してください。

複数の JVM 環境

Access Manager サービスは、複数の Java 仮想マシン (JVM) 環境でサポートされています。これは、Sun Java System Application Server のインスタンスは複数の JVM を保持するように設定でき、そのすべてで Access Manager サービスが稼働可能であることを意味します。Access Manager のアーキテクチャーでは、マシン内の Sun Java System Application Server インスタンスの数、複数マシンをまたがる Access Manager サービスの数、単一の Application Server が保持できる JVM の数などに関する配備に制限を課しません。

複数の JVM 環境については、次の Sun Java System Application Server のマニュアルを参照してください。http://docs.sun.com/coll/1310.1

Directory Server レプリケーションに関する考慮事項

Access Manager のパフォーマンスと応答時間を改善するには、レプリケートされた Directory Server 間でロードバランスを使用する方法と、レプリケートされたサーバーをユーザーの近くに配置する方法の2 つの方法があります。Directory Server は、シングルサプライヤ構成またはマルチサプライヤ構成でセットアップできます。Sun Java System Directory Proxy Server などのロードバランスアプリケーションも使用できます。Directory Proxy Server は、設定された Directory Server セット間の LDAP 操作のプロポーショナルなロードバランスを動的に実行します。1 つ以上の Directory Server インスタンスが利用できない場合、負荷は残りのサーバー間でバランス良く再配分されます。サーバーが復帰すると、負荷がバランス良くかつ動的に再配分されます。

Access Manager をインストールする前に、Directory Server レプリケーションを設定する必要があります。この設定によって、サプライヤとコンシューマのデータベースが正しく同期されるため、参照や更新が適切に同期されていることを確認する時間が取れるようになります。

Access Manager をレプリケーション目的でインストールした場合、Directory Server の各インスタンスおよび Access Manager の各インスタンスは、以下に対して同じ値を使用して設定する必要があります。

ディレクトリマネージャー
ディレクトリマネージャーのパスワード
Directory Server の管理者 ID
サーバー管理者のパスワード
ベースサフィックス
デフォルトの組織

レプリケーション用の設定

Access Manager は、シングルサプライヤまたはマルチサプライヤのレプリケーションで動作するように設定できます。次の図は、コンシューマが読み取り専用のデータベースであるシングルサプライヤ構成を示しています。書き込み操作要求の参照は、サプライヤデータベースに対して行われます。この設定により、負荷が複数のディレクトリに分散させられるため、サーバーのパフォーマンスを向上させる手段として利用できます。

図 5–2 シングルサプライヤの Directory Server レプリケーション

次の図は、Access Manager の複数インスタンスを使用したマルチサプライヤ構成、またはマルチマスターレプリケーション (MMR) を示しています。この設定によりフェイルオーバー保護および高可用性が実現されるため、サーバーのパフォーマンスはさらに向上します。

図 5–3 マルチサプライヤの Directory Server 構成

以下の手順を使用すると、Access Manager がまだインストールされていない場合に、Access Manager ディレクトリツリーのルートまたは最上位レベルでレプリケーションを設定したり、デフォルトの組織レベルでレプリケーションを設定したりすることができます。

サプライヤおよびコンシューマ Directory Server インスタンスをインストールします。

手順については、『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』を参照してください。
サプライヤおよびコンシューマ間のレプリケーションアグリーメントを設定し、ディレクトリ参照および更新が正しく機能することを確認します。

このバージョンの Access Manager で機能するように、既存の Directory Server データの移行が必要になる場合があります。詳細は、『Sun Java System Access Manager 6 2005Q1 Migration Guide』を参照してください。
Access Manager および Directory Server を初めて配備する場合や、既存のユーザーデータを使用する予定がない場合は、Java ES インストールプログラムを実行して Access Manager をインストールしてください。

インストール時に、既存の Directory Server が存在するかどうか尋ねられたら「はい」を選択し、「レプリケーション用の設定」でインストールしたサプライヤ Directory Server のホスト名とポート番号を指定します。
Access Manager がインストールされているホストサーバーで、使用しているプラットフォームに応じて、次のディレクトリの AMConfig.properties ファイルを修正します。
- Solaris システム: /etc/opt/SUNWam/config
- Linux システム: /etc/opt/sun/identity/config
次のプロパティーを修正して、「レプリケーション用の設定」でインストールしたコンシューマ Directory Server のホストおよびポート番号を反映します。
- com.iplanet.am.directory.host
- com.iplanet.am.directory.port
次のプロパティーを修正して、要求されたエントリが見つからない場合に Access Manager が同じ要求を繰り返す回数を指定します。

com.iplanet.am.replica.retries
次のプロパティーを修正して、Access Manager が再試行を行うまでの時間をミリ秒単位で指定します。

com.iplanet.am.replica.delay.between.retries
有効になっている Access Manager 認証モジュールごとに、Access Manager コンソールを使用して、「レプリケーション用の設定」でインストールしたコンシューマディレクトリを指定します。
- 最初の LDAP サーバーとポートには、プライマリ (コンシューマ) Directory Server のホスト名とポート番号を指定します。たとえば、consumer1.example.com:389 と指定します。
- 2 番目の LDAP サーバーとポートには、セカンダリ (サプライヤ) Directory Server のホスト名とポート番号を指定します。たとえば、supplier1.example.com:389 と指定します。
serverconfig.xml ファイルで、「レプリケーション用の設定」でインストールしたコンシューマディレクトリのホスト名とポート番号を指定します。serverconfig.xml ファイルの例を次に示します。
Web コンテナを再起動して Access Manager を再起動します。

`serverconfig.xml` ファイルの例

次の例は、serverconfig.xml のレプリケーションの変更を示しています。

<iPlanetDataAccessLayer>
<ServerGroup name="default" minConnPool="1"
maxConnPool="10">
<Server name="Server1"
host="consumer1.example.com" port="389"
type="SIMPLE" />

ロードバランサを使用する場合の設定

次の図は、Directory Proxy Server またはハードウェアロードバランサを含むマルチサプライヤ構成を示しています。この設定により、Access Manager によりサポートされているフェイルオーバー、高可用性、および管理されたロードバランスをうまく活用することができます。

図 5–4 ロードバランサを使用したマルチサプライヤ構成

LDAP ロードバランサを使用することにより、Access Manager で提供されるレベルを上回る高可用性とディレクトリフェイルオーバー保護の機能が追加されます。たとえば、Directory Proxy Server は、各サーバーに再配分される負荷の割合を指定できます。また、すべてのバックエンド LDAP サーバーが使用不可になった場合は、Directory Proxy Server が引き続き要求を管理し、クライアントのクエリーを拒否します。ロードバランサをインストールする場合は、このアプリケーションを認識するように Access Manager を設定する必要があります。

Access Manager を設定する前に、Directory Server をレプリケーション用にセットアップします。ディレクトリレプリケーションおよびセットアップ手順については、Sun Java System Directory Server のマニュアルを参照してください。http://docs.sun.com/coll/1316.1
LDAP ロードバランサをインストールおよび設定します。使用しているロードバランサに同梱されているマニュアルの指示に従ってください。
AMConfig.properties ファイルで、 com.iplanet.am.directory.host および com.iplanet.am.directory.port プロパティーを、コンシューマ Directory Server のロードバランサのホストおよびポート番号を指すように修正します。
有効になっている Access Manager 認証モジュールごとに、Access Manager コンソールを使用して、コンシューマ Directory Server を指定します。次の手順では、例としてLDAP 認証モジュールを使用します。
- 最初の LDAP サーバーとポートには、プライマリ(コンシューマ) Directory Server のホスト名とポート番号を、proxyhostname:port の形式で入力します。
- 2 番目の LDAP サーバーとポートには何も入力しないでください。
serverconfig.xml ファイルで、コンシューマ Directory Server のホスト名とポート番号を指定します。serverconfig.xml ファイルの例を次に示します。
Web コンテナを再起動して Access Manager を再起動します。

`serverconfig.xml` ファイルに対するロードバランサの変更

次の例は、serverconfig.xml ファイルに対するロードバランサの変更を示しています。

<iPlanetDataAccessLayer>
<ServerGroup name="default" minConnPool="1"
maxConnPool="10">
<Server name="Server1"
host="idar.example.com" port="389"
type="SIMPLE"

ファイアウォールを使用した Directory Server

Access Manager とDirectory Server の間にファイアウォールが設定されている場合、ファイアウォールのアイドル接続タイムアウト値が、Directory Server のアイドル接続タイムアウト値 (nsslapd-idletimeout 属性) を下回ると、Access Manager 接続がタイムアウトすることがあります。この問題は通常、Access Manager の負荷が低く、使用率がピークに達していないときに発生します。

Directory Server 接続がファイアウォールによって切断されると、Access Manager は、この接続が切断されていることを認識せず、LDAP 接続プールで使用可能なすべての接続を使い果たします。LDAP 接続プールを新規に作成するには、Access Manager を再起動する必要があります。この問題を回避するには、次の解決策を検討してください。

グローバルタイムアウト属性の設定

Directory Server の nsslapd-idletimeout グローバル属性を、ファイアウォールのアイドル接続タイムアウト値より小さい値に設定できます。ただし、nsslapd-idletimeout は Access Manager 以外のアプリケーションにも影響するグローバル設定属性であるため、この解決策を採用できない場合もあります。

個々のクライアント接続のタイムアウトの設定

Directory Server では、個々のクライアント接続に対して個別の属性を設定できます。nsIdleTimeout 属性では、個々のクライアントのアイドル接続タイムアウト値を指定します。この値は、Directory Server のグローバル設定で指定した nsslapd-idletimeout 値よりも優先されます。

LDAP ディレクトリにバインドした Access Manager ユーザーについて、nsIdleTimeout 属性を設定します。このユーザーは、デフォルトでは amldapuser になっています。この属性は、dsameuser および puser ユーザーにも適用されます。

amldapuser に nsIdleTimeout 属性を追加するには、Directory Server コンソールまたは ldapmodify ツールのどちらかを使用します。次に例を示します。

ldapmodify -h host-name -p port 
-D "cn=Directory Manager" -w password 
dn: cn=amldapuser,ou=DSAME Users, dc=example,dc=com 
changetype: modify
add: nsIdleTimeout
nsIdleTimeout: timeout-value

timeout-value には、ファイアウォールについて設定したアイドル接続タイムアウト値よりも低い値を指定します。このように設定すると、amldapuser ユーザーの Access Manager 接続は、ファイアウォールによって切断される前に、Directory Server によって切断されます。

dsameuser または puser にタイムアウトを追加する場合にも、上の構文を使用しますが、dn オプションを dsameuser または puser ユーザーに設定します。

AMConfig.properties ファイルの com.sun.am.event.connection.idle.timeout プロパティーでは、持続検索が再起動するまでのタイムアウト値 (分) を指定します。このプロパティーを指定しておけば、接続が切断されたときに持続検索が確実に再起動します。この値は、ロードバランサまたはファイアウォール TCP のタイムアウト値よりも低い値にしておくことが理想的です。そうすれば、接続が切断する前に持続検索が再起動するようになるからです。デフォルト値はゼロ (0) で、持続検索は再起動されません。

Directory Server 属性と ldapmodify ツールについては、次の Sun Java System Directory Server のマニュアルを参照してください。http://docs.sun.com/coll/1316.1