test

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

第 6 章 Access Manager 設計の実装

ソリューションライフサイクルの実装段階では、配備のためのさまざまなソリュー ションを実装します。この章では、Sun JavaTM System Access Manager の次の実装シナリオについて説明します。

複数のホストサーバーへの Access Manager のインストール

それぞれが同じ Directory Server にアクセスする Access Manager インスタンスを複数のホストサーバーにインストールするには、次の手順に従います。

Access Manager インスタンスの配備

それぞれが同じ Directory Server にアクセスする Access Manager インスタンスを複数のホストサーバーにインストールするには、次の手順に従います。

  1. Java Enterprise System (Java ES) インストーラを実行して、Access Manager をホストサーバーにインストールします。インストーラを実行したら、「今すぐ設定」または「あとで設定」のいずれかのオプションを指定します。インストーラの実行については、『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』を参照してください。

    インストーラの実行中には、Access Manager Web コンテナとして Web Server または Application Server を インストールすることもできます。Web コンテナとして BEA WebLogic Server または IBM WebSphere Application Server を使用するには、まずそれらの製品をインストールしてから、次の手順で amconfig スクリプトを実行する必要があります。インストールの手順については、対応する BEA または IBM 製品のマニュアルを参照してください。

  2. インストール時に「あとで設定」オプションを指定した場合や、Access Manager インスタンスを (たとえば、Web コンテナとして BEA WebLogic Server または IBM WebSphere Application Server を使用するために) 再設定する必要がある場合は、amconfig スクリプトを実行する必要があります。amconfig スクリプトと amsamplesilent 設定ファイルは、AccessManager-base/bin ディレクトリに格納されています。ここで、AccessManager-base は、デフォルトのインストールディレクトリを表します。Solaris システムでは /opt/SUNWam、Linux システムでは /opt/sun/identity です。

    amconfig スクリプトを次のように実行します。

    1. amsamplesilent ファイルを書き込み可能なディレクトリに コピーし、そのディレクトリを現在のディレクトリにします。たとえば、/newinstances というディレクトリを作成します。

    2. 設定する新しいインスタンスを判別できるように amsamplesilent ファイルのコピーの名前を変更します。たとえば、Web Server 6.1 用の新しい Access Manager インスタンスを作成する場合は、ファイル名を amwebsvr6 に変更します。

    3. amwebsvr6 ファイル内の変数を設定して、新しいインスタンスを設定します。たとえば、次のように Access Manager をレルムモードで設定します。

      AM_REALM=true
DEPLOY_LEVEL=1
NEW_INSTANCE=true
WEB_CONTAINER=WS6 # Web Server is the web container
DIRECTORY_MODE=1 
...

      あとでこのインスタンスの再設定またはアンインストールが必要になった場合に備えて、新しい amwebsvr6 ファイルを保存します。

    4. 新しい amwebsvr6 ファイルをサイレント設定用入力ファイルに指定して、amconfig スクリプトを実行します。たとえば、Access Manger がデフォルトディレクトリにインストールされた Solaris システムでは、次のように入力します。


      # cd /opt/SUNWam/bin/
# ./amconfig -s ./newinstances/amwebsvr6

      amsamplesilent ファイル、またはこのファイルのコピーへのフルパスを指定して、amconfig を実行します。スクリプトは amwebsvr6 ファイル内の変数を読み取り、サイレントモード (-s オプション) で実行されて、Web コンテナ用に Access Manager を設定します。 amsamplesilent ファイルと amconfig スクリプトの実行については、『Sun Java System Access Manager 7 2005Q4 管理ガイド』を参照してください。

  3. これらの手順を、追加の Access Manager インスタンスを配備するほかのホストサー バーで繰り返します。

追加の Access Manager インスタンスを配備する場合の考慮事項には次のものがあります。

注意 – 注意 –

複数サーバーの配備では、すべての Access Manager インスタンスで、パスワー ド暗号化鍵に同じ値を使用する必要があります。

複数サーバーの配備で、Java ES インストーラを実行して Access Manager を以降の (2 番目、3 番目、それ以降の) サーバーにインストールすると、インストーラは各サーバーに対して新しいランダムなパスワード暗号化鍵を生成します。そのため、以降のサーバーでインストーラを実行する場合は、1 番目の Access Manager インスタンスの暗号化鍵値を使用してください。これは、AMConfig.properties ファイル内の am.encryption.pwd 属性からコピーできます。次のように設定します。

ただし、Access Manager インスタンスのパスワード暗号化鍵を変更する必要がある場合は、付録 B 「パスワード暗号化キーの変更」を参照してください。

プラットフォームサーバーリストおよびレルムまたは DNS エイリアスへのインスタンスの追加

異なるホストサーバーに Access Manager の複数インスタンスをインストールする場合、追加のインスタンスは、プラットフォームサーバーリスト、あるいはレルムまたは DNS のエイリアスに追加されません。次のように、追加の Access Manager インスタンスの値を明示的に追加する必要があります。

  1. 1 番目の Access Manager ホストサーバーで、amadmin として Access Manager 7 2005Q4 コンソールにログインします。

  2. Access Manager コンソールで、「設定」、「システムプロパティー」、「プラットフォーム」の順にクリックします。

  3. 追加の各 Access Manager インスタンスを、「インスタンス名」の下にあるプラットフォームサーバーリストに追加します。

    1. 「インスタンス名」のプラットフォームサーバーリストで、「新規」をクリックします。

    2. 「新規サーバーインスタンス」で、「サーバー」と「インスタンス名」を追加します。次に例を示します。

      • サーバー: http://amserver2.example.com:80

      • インスタンス名: 02

    3. 「了解」をクリックしてインスタンスを追加します。

    4. すべてのインスタンスを追加したら、「保存」をクリックします。

  4. 追加の各 Access Manager インスタンスについて、レルムまたは DNS のエイリアスを追加します。

    1. Access Manager コンソールで、「アクセス制御」をクリックし、「レルム名」の下にあるルート (最上位レベル) レルムをクリックします。

    2. 「レルム属性」で、「レルムまたは DNS のエイリアス」に Access Manager インスタンスを追加し、「追加」をクリックします。たとえば、amserver2.example.com と指定します。

    3. すべてのインスタンスを追加したら、「保存」をクリックします。

サイトとしての Access Manager 配備の設定

Access Manager 7 2005Q4 では、Access Manager 配備の集中的な設定管理を行えるようにする「サイトの概念」が導入されました。Access Manager がサイトとして設定されている場合は、クライアント要求は常にロードバランサを経由します。それにより、配備が簡略化されるとともに、クライアントとバックエンド Access Manager サーバーの間にあるファイアウォールなどの問題も解決されます。サイトには次のコンポーネントが含まれます。

次の手順は、レルムモードでの Access Manager 7 2005Q4 コンソールを示しています。

サイトの設定

Access Manager の複数サーバー配備が存在する場合は、次のどちらかの方法を使用して、配備をサイトとして設定します。

配備をサイトとして設定する場合は、Access Manager コンソールで次の機能を実行します。

また、Access Manager によって fqdnMap プロパティー (メモリー内) がロードバランサを含むように自動的に設定されるため、AMConfig.properties ファイルでこのプロパティーを明示的に設定する必要はありません。

Access Manager 配備をサイトとして設定するには、次の手順に従います。

  1. amAdmin として Access Manager にログインします。

  2. ロードバランサの URL を「サイト名」に追加します。

    1. Access Manager コンソールで、「設定」、「システムプロパティー」、「プラットフォーム」の順にクリックします。

    2. 「サイト名」の下で、「新規」をクリックし、ロードバランサに関する次の値を入力します。

      • サーバー: ロードバランサのプロトコル、ホスト名、およびポート。次に例を示します。http://lb.example.com:80

      • サイト名: 一意の 2 桁のサイト識別子 (サイト ID)。次に例を示します。10

        入力したら、「了解」をクリックします。

    3. ロードバランサを「サイト名」に追加したら、「保存」をクリックします。これにより、ロードバランサのエントリにサイト ID が追加されます。次に例を示します。http://lb.example.com:80|10

      サイト ID は、サーバー ID およびその他のサイト ID に関して一意であることが必要です。たとえば、01 をサイト ID とサーバー ID の両方に使うことはできません。

  3. 同じコンソールパネルで、ロードバランサを各 Access Manager インスタンスに マップします。

    1. 「インスタンス名」の下にある「サーバー」リストで各インスタンス名をクリックして、そのインスタンスの「サーバーインスタンスの編集」パネルを表示します。

    2. ロードバランサの「サイト名」(サイトID) を Access Manager インスタンスにマップします。たとえば、「サイト名」が 10 のロードバランサを使用した場合、1 番目のサーバーの「インスタンス名」は 01(|10) になります。

    3. 「了解」をクリックし、ほかの Access Manager インスタンスに対して上記の手順を繰り返します。

      手順を終了すると、すべての Access Manager インスタンスがロードバランサにマップされます。次に例を示します。

      http://amserver1.example.com:8080|01|10
http://amserver2.example.com:8080|02|10
http://amserver3.example.com:8080|03|10

    4. 「保存」をクリックして設定を保存します。

  4. ロードバランサのレルムまたは DNS のエイリアスを追加します。

    1. Access Manager コンソールで、「アクセス制御」をクリックし、「レルム名」の下にあるルートまたは最上位レベルのレルムをクリックします。

    2. 「レルム属性」で、ロードバランサを「レルムまたは DNS のエイリアス」に追加し、「追加」をクリックします。次に例を示します。 lb.example.com

    3. 「保存」をクリックして変更を保存します。

  5. 個々の Access Manager インスタンスとは異なり、ポリシーエージェントなどのクライアントでは、ロードバランサが唯一のエントリポイントになります。たとえば、ポリシーエージェントを使用している場合は、AMAgent.properties ファイル内の該当するエントリを、ロードバランサを指し示すように変更します。

Access Manager でのロードバランサの使用法

ロードバランサは、複数サーバー配備の環境で、クライアント要求を複数の Access Manager インスタンスに分散します。この節の情報を利用する前に、「サイトとしての Access Manager 配備の設定」の説明に従って Access Manager 配備をサイトとして設定してください。1 つのサイトには、異なるホストサーバーにインストールされた、Access Manager の複数 (2 つ以上) のインスタンスが含まれます。すべての Access Manager インスタンスが 同じ Directory Server にアクセスし、同じパスワード暗号化鍵を使用する必要があります。Access Manager のインストールについては、「複数のホストサーバーへの Access Manager のインストール」を参照してください。

この節には、ロードバランサの使用法に関する次の情報が含まれています。

ロードバランサ用の SSL ターミネーションの設定

ロードバランサを設定して SSL 要求を処理できるようにする前に、まず、Access Manger Web コンテナの SSL を設定します。手順については、『Sun Java System Access Manager 7 2005Q4 管理ガイド』の第 3 章「Access Manager を SSL モードに設定する」を参照してください。

ロードバランサと Access Manager サーバー用に SSL を設定するには、次の場合につ いて考慮してください。

SSL パススルー設定を除き、標準のサーバー証明書を使用してロードバランサの SSL ターミネーションを有効にすることができます。ただし、ロードバランサと Access Manager サーバー用に SSL パススルーを設定し、ロードバランサがクライアントから Access Manager サーバーへのすべての要求をバイパスする場合は、標準のサーバー証明書では SSL に関する次の問題が発生します。

これらの問題を解決するために、Access Manager には次のプロパティーが用意されています。

SubjectAltName 拡張機能を使用した CSR の生成

SubjectAltName 拡張機能を使用して証明書署名要求 (CSR) を生成するには、証明書データベースツール (certutil) を使用します。certutil が /usr/sfw/bin ディレクトリにない場合、まず、Solaris システムの場合は SUNWtlsu パッケージを、Linux システムの場合は sun-nss-sun-nss-devel RPM をインストールします。必要に応じて、 LD_LIBRARY_PATH 環境変数に、適切な certutil のパスを設定します。

certutil については、次のサイトを参照してください。http://www.mozilla.org/

ここでは、Web コンテナとして Web Server または Application Server を使用している場合の certutil の使用方法について説明します。Web コンテナとして BEA WebLogic Server または IBM WebSphere Application Server を使用している場合は、それぞれの BEA または IBM 製品のマニュアルを参照してください。

SubjectAltName 拡張機能を使用して CSR を生成するには、次の手順に従います。

  1. スーパーユーザー (root) としてログインするか、スーパーユーザーになります。

  2. certutil -N オプションを使用して、新しい証明書データベース (cert8.db) を作成します。必要に応じて、最初に、データベース用のディレクトリを作成します。次に例を示します。

    # mkdir certdbdir 
# cd certdbdir 
# certutil -N -d .

    certutil から入力を求められたら、鍵を暗号化するためのパスワードを入力します。

    Enter a password which will be used to encrypt your keys. 
The password should be at least 8 characters long, 
and should contain at least one non-alphabetic character.

Enter new password: your-password 
Re-enter password:  your-password

  3. SubjectAltName 拡張機能を使用して CSR を生成します。次に例を示します。

    # certutil -R -s "cn=lb.example.com,o=example.com,c=us" 
-o server.req -d . -a -8 amserv1.example.com,amserv2.example.com

    certutil から入力を求められたら、パスワード (または pin) を入力し、次にランダムシードを生成するための鍵を入力して鍵を作成します。

    Enter Password or Pin for "NSS Certificate DB": your-password

A random seed must be generated that will be used in the  
creation of your key.  One of the easiest ways to create a  
random seed is to use the timing of keystrokes on a keyboard.   

To begin, type keys on the keyboard until this progress meter  
is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!   

Continue typing until the progress meter is full:   

|************************************************************|   

Finished.  Press enter to continue:   

Generating key.  This may take a few moments...

  4. CSR (この例では server.req ファイル) を認証局 (CA) に送信します。サーバー証明書を取得し、certutil -A オプションを使用して、それを証明書データベースに追加します。

  5. 証明書データベース (cert8.db) を Web コンテナのディレクトリにコピーします。

    • Web Server。cert8.db および key3.db データベースを /opt/SUNWwbsrv/alias ディレクトリにコピーし、Web Server インスタンスの名前を使用してその名前を変更します。次に例を示します。

      https-webserver.example.com-webserver-cert8.db
https-webserver.example.com-webserver-key3.db

    • Application Server。cert8.db および key3.db データベースをインスタンスの /config ディレクトリにコピーします。次に例を示します。

      /var/opt/SUNWappserver/domains/domain1/config/cert8.db 
/var/opt/SUNWappserver/domains/domain1/config/key3.db

ロードバランサ Cookie 用の Access Manager の設定

Access Manager をロードバランサ Cookie 用に設定するには、配備内のすべての Access Manager インスタンスの設定を更新して、インスタンスがロードバランサを認識できるようにします。このシナリオでは、異なるホストサーバーに複数 (2 つ以上) の Access Manager インスタンスが配備されています。ロードバランサが、クライアント要求をさまざまな Access Manager インスタンスに経路指定します。すべての Access Manager インスタンスが、同じ Directory Server を使用します。

  1. Access Manager コンソールで、「サイトとしての Access Manager 配備の設定」の説明に従って Access Manager 配備をサイトとして設定します。配備をサイトとして設定すると、Access Manager はロードバランサを含むようにメモリー内の fqdnMap プロパティーを自動的に設定します。

  2. 各 Access Manager の AMConfig.properties ファイルに次のプロパティーを追加します。

    com.iplanet.am.lbcookie.name=amlbcookie
com.iplanet.am.lbcookie.value=amserver

    amlbcookie はロードバランサの Cookie で、amserver はそのインスタンスで使われる Access Manager ホストサーバーの名前です。

  3. 各 Web コンテナを再起動することによって、すべての Access Manager インスタンスを再起動します。

SAML を使用したロードバランサの設定

このシナリオでは、Access Manager サイトがロードバランサを使用してクライアント要求をさまざまな Access Manager インスタンスに分散しており、サイトには SAML (Security Assertions Markup Language) サービスが実装されています。要求がロードバランサ経由で Access Manager インスタンスに送信された場合、そのインスタンスが SAML 表明を取得するには、配備内のほかのどの Access Manager サーバーによって元の表明またはアーティファクトが発行されたかを認識する必要があります。

まず、配備がサイトとして設定されていることが必要です。ホストサーバーには複数の Access Manager インスタンスがインストールされており、ロードバランサがクライアント要求をさまざまなインスタンスに経路指定します。すべての Access Manager インスタンスが、同じ Directory Server にアクセスします。Access Manager セッションフェイルオーバーはオプションです。

SAML でロードバランサを使用するようにサイトを設定するには、次の手順に従います。

  1. SAML ロードバランスが機能するには、Access Manager 配備がサイトとして設定されていることが必要です。Access Manager 配備をサイトとして設定していない場合は、「サイトとしての Access Manager 配備の設定」の手順に従います。

  2. amadmin として Access Manager コンソールにログインします。

  3. Access Manager コンソールで、「連携」、次に「SAML」をクリックします。

  4. 「プロパティー」セクションの「SAML プロファイル」で、次のエントリを追加または変更します。

    • サイト ID。配備内の各 Access Manager インスタンスを追加します。すべての Access Manager インスタンスが、同じ「サイト ID とサイト発行者名」を共有する必要があります。

    • 信頼パートナー。パートナーの配備サイトの「ソース ID」(サイト ID)、「発行者名」、および「ホストリスト」を追加します。Access Manager サーバーの一意の「ソース ID」(サイト ID) と「発行者名」、およびロードバランサの URL 、IP アドレス、またはホスト名によって配備が識別され、これらの情報が設定のためにパートナーのサイトに送信されます。

      これらのフィールドの詳細については、『Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide』を参照してください。

  5. 「保存」をクリックして変更を保存します。

fqdnMap プロパティーの設定

Access Manager 配備をサイトとして設定した場合は、Access Manager によってメモリー内の fqdnMap プロパティーがロードバランサを含むように自動的に設定されるため、AMConfig.properties ファイルでこのプロパティーを設定する必要はありません。ただし、次の Access Manager 配備の場合は、このプロパティーを明示的に設定 する必要があります。

fqdnMap プロパティーを設定する必要がある場合は、配備内の各 Access Manager インスタンスの AMConfig.properties ファイルで、このプロパティーをロードバランサに設定します。必要に応じて、最初に、このプロパティーのコメント文字 (#) を削除します。 次に例を示します。

com.sun.identity.server.fqdnMap[lb.example.com]=lb.example.com

ロードバランサを経由した Access Manager インスタンスへのアクセス

ロードバランサ経由で Access Manager インスタンスにアクセスする方法は、モード (レルムまたは旧バージョン) と、アクセスするコンソールによって異なります。ロードバランサ経由で Access Manager インスタンスにアクセスするには、次の構文を使用します。 

http://loadbalancer.domain:port/amserver/console|/amconsole

旧バージョンモードでは、次の両方のコンソールにアクセスできます。

レルムモードでは、新しい Access Manager 7 2005Q4 コンソールにのみアクセスできます。次に例を示します。

http://loadbalancer.example.com:80/amserver/console

Access Manager セッションフェイルオーバーの実装

Access Manager では、Sun Java System Message Queue (Message Queue) を通信ブローカとして、また Sleepycat Software, Inc. の BerkeleyDB をセッションストアデータベースとして使用して、Web コンテナから独立したセッションフェイルオーバー実装を提供しています。Access Manager 7 2005Q4 の拡張機能には、セッションフェイルオーバー環境を設定するための amsfoconfig スクリプトと、Message Queue ブローカや Berkeley DB クライアントを起動および停止するための amsfo スクリプトが含まれています。

ここでは、次のトピックについて説明します。

Access Manager セッションフェイルオーバーシナリオ

次の図に、次のコンポーネントを含む Access Manager セッションファイルオーバーの配備シナリオを示します。

図 6–1 Access Manager セッションフェイルオーバーシナリオ

Access Manager セッションフェイルオーバー配備シナリオ

セッションフェイルオーバーコンポーネントのインストール

次の表は、Access Manager セッションフェイルオーバーに必要なコンポーネントのインストール方法を説明しています。

表 6–1 Access Manager セッションフェイルオーバーコンポーネントのインストール

コンポーネント 

インストール方法 

Access Manager 

Java ES インストーラを使用して、各ホストサーバーに Access Manager の 1 番目のインスタンスをインストールします。インストーラによって、必要なセッションフェイルオーバー Solaris パッケージまたは Linux RPM が追加されます。 

参照: 『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』

Java ES インストーラを使用して Access Manager をインストールする場合は、レルムモード (バージョン 7.x) または旧バージョンモード (バージョン 6.x) のどちらかを選択できます。Access Manager セッションフェイルオーバーは、両方のモードでサポートされています。 

Java ES インストーラを実行したあと、amconfig スクリプトを実行して次のことを行います。

  • インストール時に「あとで設定」オプションを指定した場合は、1 番目の Access Manager インスタンスを設定します。

  • インストール済みの Access Manager インスタンスを再配備または再設定します。

詳細については、「複数のホストサーバーへの Access Manager のインストール」を参照してください。

Message Queue 

Java ES インストーラを使用して、Message Queue をインストールします。 

参照: 『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』

Berkeley DB クライアント 

(Access Manager のサブコンポーネント) 

Java ES インストーラおよび amconfig スクリプトによって、Berkeley DB クライアントに必要な Access Manager パッケージまたは RPM が追加されます。ただし、Access Manager がインストールされていないサーバーに Berkeley DB クライアントをインストールする場合は、使用しているオペレーティングシステムに応じて、次のパッケージまたは RPM を手動で追加する必要があります。

Solaris OS の場合は、pkgadd コマンドを使用して、次のパッケージを追加します。 SUNWamsfodb、SUNWbdb、および SUNWbdbj。

参照: Solaris のマニュアル 

Linux OS の場合は、rpm コマンドを使用して、次の RPM を追加します。 sun-identity-sfodb、sun-berkeleydatabase-core、および sun-berkeleydatabase-java。

参照: Linux のオンラインマニュアルページ。 

注意 – 注意 –

複数サーバーの配備では、Access Manager のすべてのインスタンスが同じパスワード暗号化鍵値を使用する必要があります。1 番目の Access Manager インスタンスをインストールしたとき、AMConfig.properties ファイル内の am.encryption.pwd プロパティーからパスワード暗号化鍵値を保存します。次に、Java ES インストーラまたは amconfig スクリプトを実行してほかのホストサーバーに Access Manager インスタンスを配備するとき、パスワード暗号化鍵にこの同じ値を使用します。

セッションフェイルオーバー用の Access Manager の設定

Access Manager をセッションフェイルオーバー用に設定するには、次の手順に従います。

各手順を、以降の節で詳細に説明します。

配備でセッションフェイルオーバーが有効であるかどうかを判別するには、AMConfig.properties ファイルの com.iplanet.services.debug.level プロパティーを error から message に変更します。 次に、Solaris システムでは /var/opt/SUNWam/debug ディレクトリ、Linux システムでは /var/opt/sun/identity/debug ディレクトリにある amSession ログを確認します。

1–Cookie エンコードの無効化

Access Manager インスタンスを実行している各ホストサーバーで、Cookie エンコードを無効にします。

Access Manager クライアントは、Cookie のエンコードもデコードも実行する必要はありません。リモート SDK クライアントは、AMConfig.properties ファイルまたは Web コンテナの sun-web.xml ファイルのどちらかで、Access Manager サーバー側の設定と同期させる必要があります。

2–Web コンテナの server.xml ファイルの編集

Access Manager インスタンスを実行している各ホストサーバーで、Access Manager Web コンテナの server.xml (または同等の) 設定ファイルに、imq.jar と jms.jar がインストールされている場所を追加します。Solaris システムの場合は次のようになります。

<JAVA javahome="/usr/jdk/entsys-j2se" serverclasspath=
"/usr/share/lib/imq.jar:/usr/share/lib/jms.jar:
/opt/SUNWwbsvr/bin/https/jar/webserv-rt.jar:
${java.home}/lib/tools.jar:
/opt/SUNWwbsvr/bin/https/jar/webserv-ext.jar:
/opt/SUNWwbsvr/bin/https/jar/webserv-jstl.jar:
/usr/share/lib/ktsearch.jar"

3–Message Queue サーバーでの新規ユーザーの追加

Message Queue のユーザー名とパスワードとして guest ユーザーを使用しない場合は、Message Queue がインストールされているサーバーで、Message Queue ブローカに接続するための新しいユーザーとパスワードを追加します。たとえば、Solaris システムで、amsvrusr という新しいユーザーを追加するには、次のように指定します。

# /usr/bin/imqusermgr add -u amsvrusr -p password

次のコマンドを発行して、guest ユーザーを非アクティブにします。

# /usr/bin/imqusermgr update -u guest -a false

4–amsessiondb スクリプトの編集 (必要な場合)

amsessiondb スクリプトは、Berkeley DB クライアント (amsessiondb) の起動、データベースの作成、および特定のデータベース値の設定を行うために、amsfo スクリプトから呼び出されます。このスクリプトには、次に示すように、各種のデフォルトのパスやディレクトリを指定する変数が含まれています。

JAVA_HOME=/usr/jdk/entsys-j2se/
IMQ_JAR_PATH=/usr/share/lib
JMS_JAR_PATH=/usr/share/lib
BDB_JAR_PATH=/usr/share/db.jar
BDB_SO_PATH=/usr/lib
AM_HOME=/opt/SUNWam

これらのいずれかのコンポーネントがそれらのデフォルトのディレクトリにインストールされていない場合は、必要に応じて amsessiondb スクリプトを編集し、変数に正しい場所を設定します。

5–amsfoconfig スクリプトの実行

Access Manager 7 2005Q4 には、Access Manager 配備をセッションフェイルオーバー用に設定するための amsfoconfig スクリプトが用意されています。

amsfoconfig スクリプトを実行するための要件

amsfoconfig スクリプトを実行するには、Access Manager 配備が次の要件を満たしている必要があります。

amsfoconfig スクリプトの機能

amsfoconfig スクリプトは amsfo.conf 設定ファイルを読み取り、次の機能を実行して、Access Manager 配備をセッションフェイルオーバー用に設定します。

次の表は、Access Manager セッションフェイルオーバーのスクリプトと設定ファイルを示しています。

表 6–2 Access Manager セッションフェイルオーバーのスクリプトと設定ファイル

名前 

説明および場所 

amsofconfig

Access Manager をセッションフェイルオーバー用に設定するためのスクリプト。 

Solaris システム: AccessManager-base/SUNWam/bin

Linux システム: AccessManager-base/identity/bin

amsfo

Message Queue ブローカや amsessiondb クライアントを起動および停止するためのスクリプト。

Solaris システム: AccessManager-base/SUNWam/bin

Linux システム: AccessManager-base/identity/bin

amsfopasswd

暗号化された Message Queue ブローカユーザーのパスワードを生成するためのスクリプト。 

Solaris システム: AccessManager-base/SUNWam/bin

Linux システム: AccessManager-base/identity/bin

amsfo.conf

セッションフェイルオーバーの設定ファイル。 

Solaris システム: AccessManager-base/SUNWam/lib

Linux システム: AccessManager-base/sun/identity/lib

amProfile.conf

セッションフェイルオーバーの環境ファイル。 

Solaris システム: etc/opt/SUNWam/config

Linux システム: /etc/opt/sun/identity/config

AccessManager-base は、Access Manager のベースインストールディレクトリを表します。デフォルト値は次のとおりです。

Solaris システム: /opt

Linux システム: /opt/sun

amsfoconfig スクリプトの実行

amsfoconfig スクリプトを実行して Access Manager をセッションフェイルオーバー用に設定するには、次の手順に従います。

  1. スーパーユーザー (root) としてログインするか、スーパーユーザーになります。

  2. 表 6–3の説明に従って、amsfo.conf ファイル内の変数を設定します。

  3. スクリプトを実行します。たとえば、Access Manager がデフォルトディレクトリにインストールされた Solaris システムでは、次のように入力します。

    # cd /opt/SUNWam/bin 
# ./amsfoconfig

    スクリプトの実行時に、状態情報が表示されます。

  4. amsfoconfig スクリプトから入力を求められたら、次のパスワードを入力します。

    • Access Manager 管理者 (amAdmin) のパスワード

    • Message Queue ブローカユーザーのパスワード

  5. 結果をチェックするには、/var/tmp/amsfoconfig.log ファイルを確認します。

次の表は、amsfoconfig スクリプトで使用される amsfo.conf ファイル内の変数を示しています。amsfoconfig スクリプトを実行する前に、これらの変数を配備の必要に応じて設定します。

表 6–3 amsfoconfig スクリプトで使用される amsfo.conf ファイル内の変数

変数 

説明 

CLUSTER_LIST

クラスタに参加している Message Queue ブローカのリスト。形式は次のとおりです。 

host1:port, host2:port,host3: port

次に例を示します。 

jmq1.example.com:7777,jmq2.example.com:7777,jmq3.example.com:7777

デフォルトはありません。 

lbServerPort

ロードバランサのポート。デフォルトは 80 です。 

lbServerProtocol

ロードバランサへのアクセスに使用されるプロトコル (http または https)。デフォルトは http です。

lbServerHost

ロードバランサの名前。 

次に例を示します。lbhost.example.com

SiteID

amsfoconfig スクリプトによって作成される新規サイト(およびロードバランサ) の識別子。

SiteID は、プラットフォームサーバーリスト内にすでに存在している サーバー ID より大きい任意の値にすることができます。

デフォルトは 10 です。 

amsfoconfig スクリプトの実行例

次の例は、amsfoconfig スクリプトの実行例を示しています。

Welcome to Sun Java System Access Manager 7 2005Q4

Session Failover Configuration Setup script.
=========================================================
=========================================================
Checking if the required files are present...
=========================================================

Running with the following Settings.
-------------------------------------------------
Environment file: /etc/opt/SUNWam/config/amProfile.conf
Resource file: /opt/SUNWam/lib/amsfo.conf
         -------------------------------------------------
Using /opt/SUNWam/bin/amadmin

Validating configuration information.
Done...

Please enter the LDAP Admin password: 
(nothing will be echoed): password1
Verify: password1
Please enter the JMQ Broker User password: 
(nothing will be echoed): password2
Verify: password2

Retrieving Platform Server list...
Validating server entries.
Done...

Retrieving Site list...
Validating site entries.
Done...

Validating host: http://amhost1.example.com:7001|02
Validating host: http://amhost2.example.com:7001|01
Done...

Creating Platform Server XML File...
Platform Server XML File created successfully.

Creating Session Configuration XML File...
Session Configuration XML File created successfully.

Creating Organization Alias XML File...
Organization Alias XML File created successfully.

Loading Session Configuration schema File...
Session Configuration schema loaded successfully.

Loading Platform Server List File...
Platform Server List server entries loaded successfully.

Loading Organization Alias List File...
Organization Alias List loaded successfully.

Please refer to the log file /var/tmp/amsfoconfig.log for additional
information.
###############################################################
Session Failover Setup Script. Execution end time 10/05/05 13:34:44
###############################################################

セッションフェイルオーバーコンポーネントの起動

Access Manager 7 2005Q4 には、次の機能を実行するための amsfo スクリプトが用意されています。

Access Manager セッションフェイルオーバーコンポーネントを起動するには、次の手順に従います。

  1. 配備の必要に応じて、amsfo.conf 設定ファイル内の変数を設定します。これらの変数については、表 6–4を参照してください。

  2. amsfo スクリプトを実行して、Java Message Queue (MQ) ブローカおよび amsessiondb クライアントを起動します。詳細は、「amsfo スクリプトの実行」を参照してください。

  3. 各 Access Manager インスタンスを、それぞれの Web コンテナを起動することに より起動します。詳細は、『Sun Java System Access Manager 7 2005Q4 管理ガイド』を参照してください。

amsfo スクリプトの実行

amsfo スクリプトには、次の起動および停止オプションが含まれています。

使用法: amsfo { start | stop }

amsfo スクリプトを実行するには、次の手順に従います。

  1. スーパーユーザー (root) としてログインするか、スーパーユーザーになります。

  2. 配備の必要に応じて、amsfo.conf ファイル内の変数を設定します。これらの変数については、表 6–4を参照してください。

  3. スクリプトを実行します。たとえば、Access Manager がデフォルトディレクトリにインストールされた Solaris システムでセッションフェイルオーバーコンポーネントを起動するには、次のように入力します。

    # cd  /opt/SUNWam/bin
# ./amsfo start

  4. スクリプトの結果をチェックするには、/tmp/amsession/logs/amsessiondb.log ファイルを確認します。

次の表は、amsfo.conf 設定ファイル内の変数を示しています。amsfo スクリプトを実行する前に、これらの変数を配備の必要に応じて設定します。

表 6–4 amsfo.conf 設定ファイル

変数 

説明 

AM_HOME_DIR

Access Manager のデフォルトのインストールディレクトリ。デフォルトディレクトリは、次のようにプラットフォームによって異なります。 

Solaris システム: AccessManager-base/SUNWam/opt

Linux システム: AccessManager-base/identity/opt

AccessManager-base は、Access Manager のベースインストールディレクトリを表します。デフォルト値は、Solaris システムでは /opt、Linux システムでは /opt/sun です。

AM_SFO_RESTART

スクリプトで amsessiondb クライアントを自動的に再起動するかどうかを指定します (true または false)。

デフォルトは true (amsessiondb クライアントを再起動する) です。

CLUSTER_LIST

クラスタに参加している Message Queue ブローカのリスト。形式は次のとおりです。 

host1:port, host2:port,host3: port

次に例を示します。 

jmq1.example.com:7777,jmq2.example.com:7777,jmq3.example.com:7777

デフォルトはありません。 

DATABASE_DIR

セッションデータベースファイルを作成するディレクトリ。 

デフォルトは "/tmp/amsession/sessiondb" です。

DELETE_DATABASE

スクリプトで amsessiondb プロセスを再起動するときに、新規データベースを削除してから作成するかどうかを指定します (true または false)。

デフォルトは true です。 

LOG_DIR

ログディレクトリの場所。 

デフォルトは "/tmp/amsession/logs" です。

START_BROKER

amsessiondb プロセスとともに Message Queue ブローカを起動するかどうかを指定します (true または false)。この変数を次のように設定します。

true - Message Queue ブローカは、amsessiondb プロセスと同じマシン上で実行されます。

false - Message Queue ブローカと amsessiondb プロセスは、別のマシン上で実行されます。

デフォルトは true です。 

BROKER_INSTANCE_NAME

起動する Message Queue ブローカインスタンスの名前。 

デフォルトは aminstance です。

BROKER_PORT

ローカル Message Queue ブローカインスタンスのポート。 

デフォルトは 7777 です。 

BROKER_VM_ARGS

Java VM の引数。デフォルトは "-Xms256m -Xmx512m" です。これにより、システムリソースに基づく最大値が設定されます。

USER_NAME

Message Queue ブローカーへの接続に使用されるユーザー名。 

デフォルトは「guest」です。「3–Message Queue サーバーでの新規ユーザーの追加」 の手順で別のユーザー名を指定した場合は、USER_NAME にその名前を設定します。

PASSWORDFILE

Message Queue ブローカへの接続に使用される暗号化パスワードを含むパスワードファイルの場所。暗号化パスワードを生成するには、「amsfopasswd スクリプト」の説明に従って amsfopasswd スクリプトを使用します。

デフォルトは $AM_HOME_DIR/.password です。$AM_HOME_DIR は、Access Manager のデフォルトのインストールディレクトリを指定します。

amsfopasswd スクリプト

amsfopasswd スクリプトはテキスト形式の Message Queue ブローカパスワードを受け取り、暗号化パスワードをファイル内に格納して返します。次に、このファイルを amsfo スクリプトへの入力 (PASSWORDFILE 変数) として使用できます。

amsfopasswd スクリプトは、次のディレクトリに格納されています。

デフォルトの AccessManager-base インストールディレクトリは、Solaris システムでは /opt、Linux システムでは /opt/sun です。

次の構文を使用して amsfopasswd スクリプトを実行します。

amsfopasswd -f filename | --passwordfile filename 
            -e password | --encrypt password
amsfopasswd -h | --help

次の表は、amsfopasswd スクリプトの引数を示しています。

表 6–5 amsfopasswd スクリプトの引数

引数 

説明 

-f filename | --passwordfile filename

amsfopasswd が暗号化パスワードを保存するファイルのパス。

-e password | --encrypt password

amsfopasswd が暗号化するテキストパスワード。

-h | --help

amsfopasswd コマンドの使用例を表示して、終了します。

次の例は、amsfopasswd スクリプトを示しています。暗号化パスワードは、/opt/SUNWam/.password ファイルに格納されます。

# ./amsfopasswd -f /opt/SUNWam/.password -e mypassword

セッションフェイルオーバーの手動での設定

場合によっては、Access Manager をセッションフェイルオーバー用に手動で設定する必要があります。たとえば、amsfoconfig スクリプトの実行を計画していない場合があります。または、amsfoconfig スクリプトが設定を終了する前に次のメッセージを表示して終了する場合もあります。「サイトはすでに設定されています」または「サーバーエントリはすでにサイト設定されています」。

次の手順は、Access Manager をセッションフェイルオーバー用に手動で設定する方法について説明しています。

これらの手順は、前に説明した手順、つまり必要なコンポーネントをインストールし、amsfoconfig スクリプトを使用してセッションフェイルオーバーを設定したあと、さまざまなコンポーネントを起動する方法の手順に対応しています。

1–配備に必要なコンポーネントのインストール

配備で、Access Manager インスタンス、ロードバランサ、Message Queue、および Berkeley DB クライアントを含むすべてのコンポーネントをインストールします。詳細は、「セッションフェイルオーバーコンポーネントのインストール」を参照してください。

2–サイトとしての Access Manager 配備の設定

複数の Access Manager インスタンスとロードバランサをサイトとして設定する amsfoconfig スクリプトの実行を計画していない場合は、「サイトとしての Access Manager 配備の設定」の説明に従って配備を設定する必要があります。

3–ロードバランサ用の新規セカンダリ設定インスタンスの作成

ロードバランサ用の新規セカンダリ設定インスタンスを作成するには、次の手順に従います。

  1. amAdmin として Access Manager 7 2005Q4 コンソール にログインします。

  2. 「設定」、「グローバルプロパティー」、「セッション」、「セカンダリ設定インスタンス」の順にクリックします。

  3. 「新規」をクリックし、次の値を追加します。

    • 名前: ロードバランサの URL。次に例を示します。 http://lb.example.com:80

    • セッションストアユーザー: Message Queue サーバーへの接続に使用している名前 (「guest」以外に存在する場合)。

    • セッションストアパスワード: セッションストアユーザーのパスワード。

    • 最大待ち時間: 5000。別の値が必要な場合以外は、デフォルト値を使用してください。

    • データベース URL: Message Queue ブローカのアドレスリスト。次に例を示します。

      mqsvr1.example.com:7777,mqsvr2.example.com:7777,mqsvr3.example.com:7777

      デフォルトの Message Queue ポートは 7676 です。ただし、Application Server を Web コンテナとして使用している場合は、ポート 7676 はすでに Application Server で使用されている可能性があるため、別のポートを使うことを検討してください。有効なポート番号の範囲については、Message Queue のマニュアルを参照してください。

  4. 「追加」をクリックして変更を保存します。

4–セッションフェイルオーバーのその他の設定作業の実行

次のタスクを実行します。これらのタスクは、amsfoconfig スクリプトを実行している場合と同じです。

5–セッションフェイルオーバーコンポーネントの起動

amsfo スクリプトを実行して、Message Queue ブローカと Berkeley DB クライアント(amsessiondb) を起動します。次に、各 Access Manager インスタンスを、それぞれの Web コンテナを起動することにより起動します。「セッションフェイルオーバーコンポーネントの起動」を参照してください。

amsessiondb スクリプト

amsessiondb スクリプトは、Berkeley DB クライアント (amsessiondb) の起動、データベースの作成、および特定のデータベース値の設定を行うために、amsfo スクリプトから呼び出されます。

注 –

Access Manager セッションフェイルオーバーコンポーネントの起動と停止には、amsfo スクリプトを実行し、そのスクリプトから amsessiondb スクリプトを呼び出す方法をお勧めします。次の情報は、amsessiondb スクリプトを単独で実行する必要が生じた場合のためにのみ提供されています。

amsessiondb スクリプトを実行する前に、「4–amsessiondb スクリプトの編集 (必要な場合)」の説明に従ってパスが正しく設定されていることを確認してください。

amsessiondb スクリプトを実行する場合、Message Queue ブローカーパスワードをコマンド行にテキストで入力できます (-w または --password オプション)。ただし、ファイル内で暗号化パスワードを使用する場合(-f または --passwordfile オプション) は、最初に amsfopasswd スクリプトを実行してMessage Queue ブローカテキストパスワードをファイル内に暗号化します。次に、このファイルを -f または --passwordfile オプションに使用して、amsessiondb スクリプトを実行します。

次の構文を使用して amsessiondb スクリプトを実行します。

amsessiondb [ -u username | --username username ]
[ -w password | --password password | 
-f filename | --passwordfile filename ]
[ -c cachesize | --cachesize cachesize ]
[ -b dbdirectory | --dbdirectory dbdirectory ]
-a MQServerAddressList | --clusteraddress MQServerAddressList
[ -s numcleanexpiredsessions | --numcleansessions numcleanexpiredsessions ]
[ -v | --verbose ]
[ -i statsinterval | --statsInterval statsinterval ]
amsessiondb -h | --help
amsessiondb -n | --version

次の表は、amsessiondb スクリプトの引数を示しています。

表 6–6 amsessiondb スクリプトの引数

引数 

説明 

-u username |

--username username

Message Queue ブローカーに接続するユーザー名。「3–Message Queue サーバーでの新規ユーザーの追加」で指定したユーザーを指定します。

デフォルトは「guest」です。 

-w password | --password password

Message Queue ブローカに接続するために使用するユーザー名のテキストパスワード。「3–Message Queue サーバーでの新規ユーザーの追加」で指定したパスワードを指定します。

デフォルトは「guest」です。 

-f filename |

--passwordfile filename

Message Queue ブローカーにアクセスするための暗号化パスワードを格納するファイル。 

このオプションを指定する場合は、-w または --password オプションを指定しないでください。 

-c cachesize | --cachesize cachesize

M バイト単位でのキャッシュサイズ。デフォルトは 8M バイトです。 

-b dbdirectory |

--dbdirectory dbdirectory

Berkeley DB データベース (amsessions.db) が作成されるベースディレクトリ。

デフォルトは “sessiondb” です。amsessiondb スクリプトを実行しているディレクトリに作成されます。

注: データベースを作成するディスク領域を十分に確保するには、100,000 セッションあたり 1G バイト必要です。

-a MQServerAddressList |

--clusteraddress MQServerAddressList

次の形式の Message Queue ブローカアドレスリスト。 

host1: port[,host2: port,host 3:port,...]

次に例を示します。mqsvr1:7777,mqsvr2:7777

-s numcleanexpiredsessions | 

--numcleansessions numcleanexpiredsessions 

クリーンアップ間隔ごとに削除される期限切れのセッション数。 

デフォルトは 1000 です。 

-v | --verbose

冗長モードで実行します。結果は標準出力に送られます。 

デフォルトは、非冗長モードです。 

-i statsinterval | 

--statsInterval statsinterval 

要求、読み取り、書き込み、削除の合計の統計情報を標準出力に出力する秒単位の間隔。 

デフォルトは 60 秒です。 

-h | --help

amsessiondb コマンドの使用例を表示して、終了します。

-n | --version

現在インストールされている Access Manager のバージョンを返し、終了します。 

次の例は、amsessiondb スクリプトを示しています。

amsessiondb -u amsvrusr -f pwfile -c 128 -b sessiondb 
-a host1:7777,host2:7777

amsessiondb クライアントを使用したパフォーマンステスト

amsessiondb クライアントを使用したパフォーマンステストの条件は、次のとおりです。

次の表は、テスト結果を示しています。

表 6–7 amsessiondb クライアントを使用したパフォーマンステスト

ディスク 

備考 

標準の IDE ディスク: 1 秒間に 666 回の書き込み 

各サイトは 1 秒間に最大 300 回の認証をサポートできます。 

そのため、IDE ディスクは推奨されません。 

標準の 10K RPM SCSI ディスク (Sun Blade サーバー上): 1 秒間に 1520 回の書き込み 

各サイトは 1 秒間に最大 750 回の認証をサポートできます。 

Seagate Cheetah 15K RPM SCSI ディスク: 1 秒間に 1860 回の書き込み 

各サイトは 1 秒間に最大 900 回の認証をサポートできます。 

Sun T-300 ディスクアレイ: 1 秒間に 2700 回の書き込み 

各サイトは 1 秒間に最大 1300 回の認証をサポートできます。 

/tmp 内のスワップ領域を使用するディスク: 1 秒間に 3300 回の書き込み

各サイトは 1 秒間に最大 1600 回の認証をサポートできます。 

セッション割り当て制限の設定

Access Manager 7 2005Q4 には、設定可能な属性に基づいてAccess Manager がユーザー数を特定の数のアクティブな並行セッションに制限できるようにする、新しいセッション割り当て制限の機能が含まれています。Access Manager 管理者は、セッション割り当て制限を次のレベルで設定できます。

セッション割り当て制限のための配備シナリオ

セッション割り当て制限は、次の Access Manager 配備でサポートされています。

セッションフェイルオーバー配備では、ユーザーがログインしようとすると、セッション作成要求を受信している Access Manager サーバーは、まず、Access Manager アイデンティティーリポジトリからそのユーザーのセッション制限を取得します。次に、そのユーザーのセッション数をセッションリポジトリから直接フェッチ し (同じサイト内のすべての Access Manager サーバーからすべてのセッションを蓄積)、セッション制限がいっぱいになっているかどうかをチェックします。そのユーザーのセッション制限がいっぱいになっている場合、Access Manager サーバーは、設定されているセッション割り当て制限オプションに基づく操作を実行します。

セッションフェイルオーバー配備でセッション制限が有効になっており、セッションリポジトリが使用できない場合、ユーザー (スーパーユーザーを除く) のログインは許可されません。

セッションフェイルオーバー配備では、Access Manager インスタンスが停止していると、以前にそのインスタンスによってホストされていたすべての有効なセッションがまだ有効であると見なされ、サーバーが特定のユーザーの実際のアクティブなセッション数を判定するときにカウントされます。セッションフェイルオーバー用に設定されていない Access Manager 複数サーバー配備では、セッション割り当て制限はサポートされません。

セッション割り当て制限の設定

セッション割り当て制限を設定するには、Access Manager の最上位レベル管理者 (amAdmin など) が Access Manager コンソールでいずれかの Access Manager インスタンスに対して次の属性を設定する必要があります。これらの属性のいずれかをリセットした場合は、サーバーを再起動して新しい値を有効にする必要があります。

セッション制限の複数設定

ユーザーが、異なるレベルで複数のセッション制限を設定している場合、Access Manager は、そのユーザーの実際の割り当て制限を次の優先順位に従って判定します。

たとえば、Ken がマーケティングロールと管理ロールの両方のメンバーだとします。セッション制限は、次のように定義されています (競合の解決レベルはすべて同じ)。

Ken の割り当て制限は 3 です。

セッション割り当て制限の属性については、Access Manager コンソールのオンラインヘルプを参照してください。

セッションプロパティー変更通知の有効化

セッションプロパティー変更通知の機能を使用した場合、特定のセッションプロパティーに変更が発生すると、Access Manager は登録されているすべてのリスナーに通知を送信します。この機能は、Access Manager コンソールで「プロパティーの変更通知を有効」属性が有効(「オン」) になっている場合に有効になります。

たとえば、シングルサインオン (SSO) 環境では、複数のアプリケーションで 1 つの Access Manager セッションを共有できます。「通知プロパティー」リストで定義された特定のセッションプロパティーに変更が発生すると、Access Manager は、登録されたすべてのリスナーに通知を送信します。

SSO に参加しているクライアントアプリケーションはすべて、通知モードに設定されていれば、セッション通知を自動的に取得します。クライアントでキャッシュされたセッションは、新しいセッション状態 (任意のセッションプロパティーの変更を含む) に基づいて自動的に更新されます。セッション通知に基づいて特定のアクションを実行しようとするアプリケーションは、SSOTokenListener インタフェースの実装を記述し、次にこの実装を SSOToken.addSSOTokenListener メソッドを通して登録することができます。詳細は、『Sun Java System Access Manager 7 2005Q4 Developer’s Guide』を参照してください。

セッションプロパティー変更通知を設定するには、次の手順に従います。

  1. amadmin として Access Manager コンソールにログインします。

  2. 「設定」タブをクリックします。

  3. 「グローバルプロパティー」で「セッション」をクリックします。

  4. 「プロパティーの変更通知を有効」を「オン」に設定します。

  5. 「通知プロパティー」リストで、プロパティーが変更されたときに通知を送信する各プロパティーを追加します。

  6. リストへのプロパティーの追加が終了したら、「保存」をクリックします。

配備のチューニング

Access Manager のインストール後、amtune や関連するスクリプトを使用して配備のチューニングを行い、パフォーマンスを最適化できます。これらのスクリプトを使用すると、Access Manager、SolarisTM Operating System (OS)、Web コンテナ、および Directory Server のチューニングを行うことができます。

Java Enterprise System インストーラにより、チューニングスクリプトと関連ファイルが bin/amtune ディレクトリにインストールされます。

amtune は、対話型のスクリプトではありません。amtune を実行する前に、amtune-env 設定ファイルのパラメータを編集して、特定の環境で amtune が実行するチューニングを指定する必要があります。amtune-env 設定ファイルには、次の 2 つの主要なセクションがあります。

amtune スクリプトは次の 2 つのモードで実行できます。

amtune スクリプトが Directory Server のチューニングを自動的に行うことはありません。ほとんどの配備には、Access Manager 以外にも Directory Server にアクセスす るアプリケーションがあります。したがって、ほかのアプリケーションに与える影響 を考慮せずにチューニングによる変更を行うことは好ましくありません。

Directory Server のチューニングを行う前に、db2bak を使用して Directory Server のデータのバックアップを取ります。

amtune を実行すると、このスクリプトにより、 Directory Server チューニングスクリプト amtune-directory を含む tar ファイルが作成されます。このファイルを一時ディレクトリで解凍し、スクリプトをレビューモードで実行します。この変更が、配備で使用するすべてのアプリケーションで受け入れられるものであることを確認できたら、amtune-directory を変更モードで実行します。

チューニングスクリプトの実行、および amtune-env 設定ファイルでのチューニングパラメータの設定については、『Sun Java System Access Manager 7 2005Q4 Performance Tuning Guide』を参照してください。