| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11gリリース1（11.1.1） B61378-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11gリリース1（11.1.1） B61378-01 |
|
戻る |
次へ |
この章では、セットアップしたIdentity Managementエンタープライズ・デプロイメントの管理について説明します。
この章の内容は次のとおりです。
この項では、Oracle Identity Managementエンタープライズ・デプロイメントの各種コンポーネントを起動、停止および再起動する方法を説明します。
この項の内容は次のとおりです。
起動
次のコマンドを入力して、Oracle Virtual Directoryなどのシステム・コンポーネントを起動します。
ORACLE_INSTANCE/bin/opmnctl startall
次を実行することでシステム・コンポーネントが起動されていることを確認できます。
ORACLE_INSTANCE/bin/opmnctl status -l
停止
次のコマンドを実行して、Oracle Virtual Directoryなどのシステム・コンポーネントを停止します。
ORACLE_INSTANCE/bin/opmnctl stopall
起動
次のコマンドを入力して、Oracle Internet Directoryなどのシステム・コンポーネントを起動します。
ORACLE_INSTANCE/bin/opmnctl startall
次を実行することでシステム・コンポーネントが起動されていることを確認できます。
ORACLE_INSTANCE/bin/opmnctl status -l
停止
次のコマンドを実行して、Oracle Internet Directoryなどのシステム・コンポーネントを停止します。
ORACLE_INSTANCE/bin/opmnctl stopall
Oracle HTTP Serverを起動または停止する前に、ORACLE_HOMEとORACLE_INSTANCEという環境変数が定義されていること、およびPATHにORACLE_HOME/opmn/binが指定されていることを確認します。次に例を示します。
export ORACLE_HOME=/u01/app/oracle/product/fmw/web export ORACLE_INSTANCE=/u01/app/oracle/admin/web[1-2] export PATH=$ORACLE_HOME/opmn/bin:$PATH
起動
次のコマンドを発行して、Oracle Web層を起動します。
opmnctl startall
停止
次のコマンドを実行して、Web層を停止します。
opmnctl stopall
前述を実行すると、Web層全体が停止します。
opmnctl stoproc process-type=OHS
前述を実行すると、Oracle HTTP Serverのみが停止します。
再起動
Web層を再起動するには、前述の各項における記載のとおりstopコマンドを実行してからstartコマンドを実行します。
Oracle HTTP Serverのみを再起動するには、次のコマンドを使用します。
opmnctl restartproc process-type=OHS
ノード・マネージャを起動および停止するには、次のようにします。
起動
ノード・マネージャを起動するには、次のコマンドを実行します。
IDMHOST> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
IDMHOST> ./startNodeManager.sh
停止
ノード・マネージャを停止するには、前の項で起動したプロセスを強制終了します。
WebLogic管理サーバーを起動および停止するには、次のようにします。
起動
管理サーバーを起動するために推奨される方法は、WLSTを使用してノード・マネージャに接続することです。
IDMHOST1> cd ORACLE_BASE/product/fmw/oracle_common/common/bin
IDMHOST1> ./wlst.sh
wlstシェルで一度、次を実行します。
wls:/offline>nmConnect(Admin_User,'Admin_Password,ADMINHOST1,'5556',
'IDMDomain','/u01/app/oracle/admin/domain_name/aserver/IDMDomain'
wls:/nm/domain_name> nmStart('AdminServer')
または、次のコマンドを使用して管理サーバーを起動することもできます。
DOMAIN_HOME/bin/startWeblogic.sh
停止
管理サーバーを停止するには、http://admin.mycompany.com/consoleというURLを使用してWebLogicコンソールにログインします。
次のように実行します。
「ドメイン構造」メニューで「環境」 →「サーバー」をクリックします。
「制御」タブをクリックします。
「AdminServer(管理サーバー)」を選択します。
「停止」をクリックし、「ただちに強制停止」を選択します。
管理サーバーを停止することを確認するよう求められたら、「はい」をクリックします。
再起動
前の各項で、停止と起動の手順を実行してサーバーを再起動します。
Oracle Identity ManagerサーバーとOracle SOA Suiteサーバーを起動および停止するには、次のようにします。
起動
OIM管理対象サーバーを起動するには、http://admin.mycompany.com/consoleというURLを使用してWebLogicコンソールにログインします。
次のように実行します。
「ドメイン構造」メニューで「環境」 →「サーバー」をクリックします。
「制御」タブをクリックします。
SOAサーバー（WLS_SOA1またはWLS_SOA2（あるいはその両方））を選択します。
|
注意: Oracle Identity ManagerサーバーとOracle SOA Suiteサーバーは相互に独立して起動できます。これらの起動順序には依存関係はありません。ただし、OIMのすべての機能を使用できるためには、SOAサーバーが稼働している必要があります。 |
「起動」ボタンをクリックします。
サーバーを起動することを確認するよう求められたら、「はい」をクリックします。
WLS_SOA1またはWLS_SOA2（あるいはその両方）が起動されたら、WLS_OIM1またはWLS_OIM2（あるいはその両方）を選択します。
「起動」をクリックします。
サーバーを起動することを確認するよう求められたら、「はい」をクリックします。
停止
OIM管理対象サーバーを停止するには、http://admin.mycompany.com/consoleというURLを使用してWebLogicコンソールにログインします。次のように実行します。
「ドメイン構造」メニューで「環境」 →「サーバー」をクリックします。
「制御」タブをクリックします。
OIMサーバー（WLS_OIM1またはWLS_OIM2（あるいはその両方））および（WLS_SOA1またはWLS_SOA2（あるいはその両方））を選択します。
「停止」ボタンをクリックし、「ただちに強制停止」を選択します。
サーバーを停止することを確認するよう求められたら、「はい」をクリックします。
再起動
前の各項で、停止と起動の手順を実行してサーバーを再起動します。
Oracle Access Managerの管理対象サーバーを起動および停止するには、次のようにします。
起動
OAM管理対象サーバーを起動するには、http://admin.mycompany.com/consoleというURLを使用してWebLogicコンソールにログインします。
次のように実行します。
「ドメイン構造」メニューで「環境」 →「サーバー」をクリックします。
「制御」タブをクリックします。
OAMサーバー（WLS_OAM1またはWLS_OAM2（あるいはその両方））を選択します。
「起動」ボタンをクリックします。
サーバーを起動することを確認するよう求められたら、「はい」をクリックします。
停止
OAM管理対象サーバーを停止するには、http://admin.mycompany.com/consoleのURLを使用してWebLogicコンソールにログインします。次のように実行します。
「ドメイン構造」メニューで「環境」 →「サーバー」をクリックします。
「制御」タブをクリックします。
OAMサーバー（WLS_OAM1またはWLS_OAM2（あるいはその両方））を選択します。
「停止」ボタンをクリックし、「ただちに強制停止」を選択します。
サーバーを停止することを確認するよう求められたら、「はい」をクリックします。
再起動
前の各項で、停止と起動の手順を実行してサーバーを再起動します。
Oracle Adaptive Access Managerを起動および停止するには、次のようにします。
起動
OAAM管理対象サーバーを起動するには、http://admin.mycompany.com/consoleというURLを使用してWebLogicコンソールにログインします。次のように実行します。
「ドメイン構造」メニューで「環境」 →「サーバー」をクリックします。
「制御」タブをクリックします。
OAAMサーバー（WLS_OAAM1またはWLS_OAAM2（あるいはその両方））を選択します。
「起動」ボタンをクリックします。
サーバーを起動することを確認するよう求められたら、「はい」をクリックします。
停止
OAM管理対象サーバーを停止するには、http://admin.mycompany.com/consoleのURLを使用してWebLogicコンソールにログインします。次のように実行します。
「ドメイン構造」メニューで「環境」 →「サーバー」をクリックします。
「制御」タブをクリックします。
OAAMサーバー（WLS_OAAM1またはWLS_OAAM2（あるいはその両方））を選択します。
「停止」をクリックし、「ただちに強制停止」を選択します。
サーバーを停止することを確認するよう求められたら、「はい」をクリックします。
再起動
前述の停止と起動の手順を実行してサーバーを再起動します。
Oracle Identity Federationの管理対象サーバーを起動および停止するには、次のようにします。
起動
OIF管理対象サーバーを起動するには、http://admin.mycompany.com/consoleにアクセスしてWebLogicコンソールにログインします。次のように実行します。
「ドメイン構造」メニューで「環境」 →「サーバー」をクリックします。
「制御」タブをクリックします。
OIFサーバー（WLS_OIF1またはWLS_OIF2（あるいはその両方））を選択します。
「起動」をクリックします。
サーバーを起動することを確認するよう求められたら、「はい」をクリックします。
停止
OIF管理対象サーバーを停止するには、http://admin.mycompany.com/consoleにアクセスしてWebLogicコンソールにログインします。次のように実行します。
「ドメイン構造」メニューで「環境」 →「サーバー」をクリックします。
「制御」タブをクリックします。
OIFサーバー（WLS_OIF1またはWLS_OIF2（あるいはその両方））を選択します。
「停止」をクリックし、「ただちに強制停止」を選択します。
サーバーを停止することを確認するよう求められたら、「はい」をクリックします。
再起動
前述の停止と起動の手順を実行してサーバーを再起動します。
OIFインスタンスとEMAgentの起動
次のコマンドを実行して、OIFインスタンスとEMAgentを起動します。
ORACLE_INSTANCE/bin/opmnctl startall
次のコマンドを実行して、インスタンスが正常に起動されたことを確認できます。
ORACLE_INSTANCE/bin/opmnctl status -l
OIFインスタンスとEMAgentの停止
次のコマンドを実行して、OIFインスタンスとEMAgentを停止します。
ORACLE_INSTANCE/bin/opmnctl stopall
起動
Oracle Access Manager 10gのアイデンティティ・サーバーを起動するには、次のスクリプトを使用します。
ORACLE_HOME/identity/oblix/apps/common/bin/start_ois_server
環境でNPTLスレッド・モデルを使用する必要がある場合、かわりに次のスクリプトを使用します。
ORACLE_HOME/identity/oblix/apps/common/bin/start_ois_server_nptl
スクリプトが実行されたシェルで、サーバーが正常に起動したことが示されます。
停止
Oracle Access Manager 10gのアイデンティティ・サーバーを停止するには、次のスクリプトを使用します。
ORACLE_HOME/identity/oblix/apps/common/bin/stop_ois_server
スクリプトが実行されたシェルで、サーバーが正常に停止したことが示されます。
再起動
Oracle Access Manager 10gのアイデンティティ・サーバーを再起動するには、次のスクリプトを使用します。
ORACLE_HOME/identity/oblix/apps/common/bin/restart_ois_server_nptl
スクリプトが実行されたシェルで、サーバーが正常に再起動したことが示されます。
起動
Oracle Access Manager 10gのアクセス・サーバーを起動するには、次のスクリプトを使用します。
ORACLE_HOME/access/oblix/apps/common/bin/start_access_server
環境でNPTLスレッド・モデルを使用する必要がある場合、かわりに次のスクリプトを使用します。
ORACLE_HOME/access/oblix/apps/common/bin/start_access_server_nptl
スクリプトが実行されたシェルで、サーバーが正常に起動したことが示されます。
停止
Oracle Access Manager 10gのアクセス・サーバーを停止するには、次のスクリプトを使用します。
ORACLE_HOME/access/oblix/apps/common/bin/stop_access_server
スクリプトが実行されたシェルで、サーバーが正常に停止したことが示されます。
再起動
Oracle Access Manager 10gのアクセス・サーバーを再起動するには、次のスクリプトを使用します。
ORACLE_HOME/access/oblix/apps/common/bin/restart_access_server
環境でNPTLスレッド・モデルを使用する必要がある場合、かわりに次のスクリプトを使用します。
ORACLE_HOME/access/oblix/apps/common/bin/restart_access_server_nptl
スクリプトが実行されたシェルで、サーバーが正常に再起動したことが示されます。
この項では、このマニュアルで説明しているIdentity Managementエンタープライズ・デプロイメントの監視について説明します。
この項の内容は次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、次のようにOracle Internet Directoryを監視できます。
アイデンティティ管理ドメインのFarmホーム・ページで、Fusion Middlewareの円グラフを表示します。このグラフによりOracle Fusion Middlewareコンポーネントのステータスが表示されます。グラフで緑色の部分によりコンポーネントが正常に起動して稼働していることが示されます。赤色の部分によりコンポーネントが停止していることが示されます。
グラフの下の「Identity and Access」セクションには、個別のOracle Internet Directoryインスタンスの名前（例: oid1、oid2）、そのステータス、ホスト名およびCPU使用率が表示されます。「ステータス」列の緑の矢印は、そのインスタンスが正常に稼働していることを示し、赤い矢印はそのインスタンスが停止していることを示します。個別のOracle Internet Directoryインスタンスの名前をクリックすると、そのインスタンスのホーム・ページが表示されます。
インスタンスのホーム・ページには、そのインスタンスのメトリックが表示されます。たとえば、パフォーマンス、負荷、セキュリティ、レスポンス、CPU使用率、メモリー使用率などです。
Oracle Identity Management 11gインストーラを使用してOracle Internet Directoryのインストールを実行した場合、インストーラによってそのOracle Internet Directoryインスタンスに割り当てられるデフォルトのコンポーネント名は「oid1」です。このコンポーネント名は変更できません。
このOracle Internet Directoryインスタンスのインスタンス固有構成エントリは、「cn=oid1, cn=osdldapd, cn=subconfigsubentry」です。
別のコンピュータ上で2回目のOracle Internet Directoryインストールを実行した場合に、そのOracle Internet Directoryインスタンスが1つ目のインスタンスと同じデータベースを使用する場合、インストーラは、同じOracleデータベースを使用する他方のコンピュータ上のインストール済Oracle Internet Directoryインスタンスを検知するため、2つ目のOracle Internet Directoryインスタンスには「oid2」というコンポーネント名を割り当てます。
2つ目のOracle Internet Directoryインスタンスのインスタンス固有構成エントリは、「cn=oid2, cn=osdldapd, cn=subconfigsubentry」です。「cn=oid2, cn=osdldapd, cn=subconfigsubentry」というエントリ内のプロパティに変更を加えても、1つ目のインスタンス（oid1）は影響を受けません。
別のコンピュータ上で3回目のOracle Internet Directoryインストールを実行した場合に、そのインスタンスが1つ目と2つ目のインスタンスと同じデータベースを使用する場合、インストーラは、3つ目のOracle Internet Directoryインスタンスに「oid3」というコンポーネント名を割り当てます。同様に、同じデータベースを使用する別のホスト上の追加のインスタンスにも、この規則に従って順番にコンポーネント名が割り当てられます。
すべてのOracle Internet Directoryインスタンスの共有構成は、「cn=dsaconfig, cn=configsets,cn=oracle internet directory」です。このエントリに変更を加えると、すべてのOracle Internet Directoryインスタンスが影響を受けます。
この命名規則では、Oracle Internet Directoryインスタンスごとに異なるコンポーネント名が割り当てられるため、Oracle Enterprise Managerを使用してドメインを表示する際に混乱が避けられます。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、次のようにOracle Virtual Directoryを監視できます。
アイデンティティ管理ドメインのFarmホーム・ページで、Fusion Middlewareの円グラフを表示します。このグラフによりOracle Fusion Middlewareコンポーネントのステータスが表示されます。グラフで緑色の部分によりコンポーネントが正常に起動して稼働していることが示されます。赤色の部分によりコンポーネントが停止していることが示されます。
グラフの下の「Identity and Access」セクションには、Oracle Virtual Directoryアプリケーションの各インスタンスの名前（例: ovd1、ovd2）、そのステータスおよびホスト名が表示されます。「ステータス」列の緑の矢印は、そのOracle Virtual Directoryインスタンスが正常に稼働していることを示し、赤い矢印はそのインスタンスが停止していることを示します。個別のOracle Virtual Directoryインスタンスの名前をクリックすると、そのインスタンスのホーム・ページが表示されます。
インスタンスのホーム・ページには、そのインスタンスの次のようなメトリックや構成が表示されます。
Oracle Virtual Directoryのステータス: ページ上部のOracle Virtual Directoryインスタンス名の横に表示される緑の矢印は、そのインスタンスが正常に稼働していることを示し、赤い矢印はそのインスタンスが停止していることを示します。
現行ロード: ここには、そのOracle Virtual Directoryインスタンスの現在のワークロードが示されます。これには、「オープン接続」、「個別に接続しているユーザー」および「個別に接続されたIPアドレス」という3つのメトリックが含まれます。
平均レスポンス時間メトリック: ここには、LDAP検索リクエストを完了するのにかかる平均時間（ミリ秒単位）が表示されます。
操作メトリック: ここには、終了したLDAP検索リクエストにおけるミリ秒当たりの平均数が表示されます。
リスナー: この表には、クライアントにサービスを提供するためにそのOracle Virtual Directoryインスタンス用に構成されたリスナーが一覧表示されます。
アダプタ: この表には、そのOracle Virtual Directoryインスタンスとともに構成された既存のアダプタが一覧表示されます。Oracle Virtual Directoryは、アダプタを使用して各種の基盤データ・リポジトリに接続します。
リソース使用率: ページの右側にCPUとメモリーの使用率メトリックが表示され、そのOracle Virtual Directoryインスタンスによって使用されているシステム・リソースが示されます。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、次のようにOracle Directory Integration Platformを監視できます。
アイデンティティ管理ドメインのFarmホーム・ページで、Fusion Middlewareの円グラフを表示します。このグラフによりOracle Fusion Middlewareコンポーネントのステータスが表示されます。グラフで緑色の部分によりコンポーネントが正常に起動して稼働していることが示されます。赤色の部分によりコンポーネントが停止していることが示されます。
グラフの下の「Identity and Access」セクションには、Oracle Directory Integration Platformアプリケーションの各インスタンスの名前（すべて「DIP (11.1.1.1.0)」という名前）、そのステータスおよびホスト名が表示されます。それぞれのOracle Directory Integration Platformインスタンスは、異なる管理対象サーバーにデプロイされています。「ステータス」列の緑の矢印は、そのOracle Directory Integration Platformインスタンスが正常に稼働していることを示し、赤い矢印はそのインスタンスが停止していることを示します。個別のOracle Directory Integration Platformインスタンスの名前をクリックすると、そのインスタンスのホーム・ページが表示されます。
インスタンスのホーム・ページには、そのインスタンスの次のようなメトリックが表示されます。
Oracle Directory Integration Platformのステータス: ページ上部のOracle Directory Integration Platformインスタンス名の横に表示される緑の矢印は、そのインスタンスが正常に稼働していることを示し、赤い矢印はそのインスタンスが停止していることを示します。
DIPコンポーネント・ステータス: この表には次のメトリックが含まれています。
クォーツ・スケジューラ: ここには、タスクを同期向けにスケジュール設定できるかどうかが示されます。緑の矢印は、そのスケジューラが稼働していることを示し、赤い矢印はそのスケジューラが停止していることを示します。
MBean: ここには、ユーザーがプロファイル管理を実行できるかどうかが示されます。緑の矢印は、プロファイル管理を実行できることを示し、赤い矢印はプロファイル管理を実行できないことを示します。
同期プロファイル: ここには、登録済プロファイルとそれらの実行ステータスが表示されます。高可用性デプロイメントでは、すべてのインスタンスでプロファイルの同じリストが表示されます。
プロビジョニング・プロファイル: ここには、登録済プロビジョニング・プロファイルとそれらの実行ステータスが表示されます。高可用性デプロイメントでは、すべてのインスタンスでプロファイルの同じリストが表示されます。
リソース使用率: ページの右側にはCPUとメモリーの使用率メトリックが表示され、そのOracle Directory Integration Platformインスタンスによるリソース使用率が示されます。
Oracle Enterprise Manager Grid Controlを使用して、Oracle Access Managerを監視できます。詳細は、Oracle Enterprise Managerの概要の「アイデンティティ管理」を参照してください。
このマニュアルで説明している参照用エンタープライズ・トポロジは高いスケーラビリティを備えています。このトポロジは、スケール・アップすることもスケール・アウトすることもできます。トポロジをスケール・アップする際は、すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいサーバー・インスタンスを追加します。トポロジをスケール・アウトする際は、新しいサーバーを新しいノードに追加します。
この項の内容は次のとおりです。
このガイドで説明しているOracle Identity Managementトポロジには、ディレクトリ層、アプリケーション層およびWeb層という3つの層があります。すでに1つ以上のサーバー・インスタンスが実行されているノードに新しいサーバー・インスタンスを追加することで、3つすべての層内のコンポーネントをスケール・アップできます。
ディレクトリ層には、Oracle Internet Directoryノードが2個（OIDHOST1とOIDHOST2）とOracle Virtual Directoryノードが2個（OVDHOST1とOVDHOST2）あります。各Oracle Internet Directoryノードは、Oracle Internet Directoryインスタンスを実行しています。各Oracle Virtual Directoryノードは、Oracle Virtual Directoryインスタンスを実行しています。Oracle Internet DirectoryインスタンスまたはOracle Virtual Directoryインスタンスは、一方または両方のノード上でスケール・アップできます。
ディレクトリ層にはOracle Internet Directoryノードが2個（OIDHOST1とOIDHOST2）あります。それぞれOracle Internet Directoryインスタンスを実行しています。どちらのノード上の既存Oracle Identity Managementバイナリも、新しいOracle Internet Directoryインスタンスを作成するために使用できます。
新しいOracle Internet DirectoryインスタンスをどちらかのOracle Internet Directoryノードに追加するには、第7.2.2項「追加のOracle Internet Directoryインスタンスの構成」の手順に加えて、次の指示に従ってください。
手順2と手順4では、389と636以外のポートを選択します。これらのポートは、ノード上の既存のOracle Internet Directoryインスタンスによって使用されているからです。
第7.3.1項「WebLogicサーバー・ドメインへのOracle Internet Directoryの登録」の手順に従って、新しいOracle Internet DirectoryインスタンスをWebLogicドメインに登録します。新しいOracle Internet Directoryインスタンスの場所をORACLE_INSTANCEの値として使用します。
新しいOracle Internet Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。
ディレクトリ層にはノードが2個（OVDHOST1とOVDHOST2）あります。それぞれOracle Virtual Directoryインスタンスを実行しています。どちらのノード上の既存Oracle Identity Managementバイナリも、新しいOracle Virtual Directoryインスタンスを作成するために使用できます。
新しいOracle Virtual DirectoryインスタンスをどちらかのOracle Virtual Directoryノードに追加するには、第7.3.1項「WebLogicサーバー・ドメインへのOracle Internet Directoryの登録」の手順に加えて、次の指示に従ってください。
手順2と手順4では、6501と7501以外のポートを選択します。これらのポートは、ノード上の既存のOracle Virtual Directoryインスタンスによって使用されているからです。
第7.3.1項「WebLogicサーバー・ドメインへのOracle Internet Directoryの登録」の手順に従って、新しいOracle Virtual DirectoryインスタンスをWebLogicドメインに登録します。新しいOracle Virtual Directoryインスタンスの場所をORACLE_INSTANCEの値として使用します。
新しいOracle Virtual Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。
アプリケーション層にはノードが5個あります。2個のノード（IDMHOST1とIDMHOST2）では、Oracle Directory Integration PlatformとOracle Directory Services Managerの管理対象サーバーを実行しています。2個のノード（OAMHOST1とOAMHOST2）では、Oracle Access Managerアイデンティティ・サーバーとアクセス・サーバーを実行しています。残りのノードは管理ノード（OAMADMINHOST）で、Oracle Access Manager Webパス、ポリシー・マネージャ、WebゲートおよびOracle HTTP Serverのインスタンスを実行しています。
アプリケーション層には、Oracle Directory Integration PlatformおよびOracle Directory Services Managerのコンポーネントとともに構成された管理対象サーバーが実行されているノード（IDMHOST2）がすでに存在します。このノードには、ローカル・ディスク上のOracle Fusion Middleware Identity ManagementホームとWebLogic Serverホームが含まれています。
既存のインストール内容（WebLogic Serverホーム、Oracle Fusion Middlewareホームおよびドメイン・ディレクトリ）を使用して、Oracle Directory Integration PlatformとOracle Directory Services Managerのコンポーネント用の新しい管理対象サーバーを作成できます。
第9.2項「Oracle Directory Integration PlatformとODSMクラスタの拡張」の手順に加えて、次の指示に従って、Oracle Directory Integration PlatformとOracle Directory Services Manager用のトポロジをスケール・アップしてください。
Oracle Identity Managementのコンフィギュレーション・アシスタントを使用して、トポロジをスケール・アップします。ORACLE_HOME/binディレクトリにあるconfig.shスクリプトを実行して、コンフィギュレーション・アシスタントを起動します。
新しい管理対象サーバーとともにOracle HTTP Serverモジュールを再構成します。第5章「Web層の構成」の手順に従ってこのタスクを完了します。
Oracle Access Managerでは、新しいサーバー・インスタンスをインストールする場合、 別個のORACLE_HOMEの場所を指定する必要があります。複数のOracle Access ManagerコンポーネントのインスタンスにおいてORACLE_HOMEを共有することはサポートされていません。
アイデンティティ・サーバーをスケール・アップするには、第10.3.1.2項「OAMHOST2における2番目のアイデンティティ・サーバーのインストール」の手順を実行します。
アクセス・サーバーをスケール・アップするには、第10.4.2.2項「アクセス・サーバーのインストールの起動」の手順を実行します。
Webパスをスケール・アップするには、第10.3.3項「OAMADMINHOSTにおけるWebパスのインストール」の手順を実行します。
Webゲートをスケール・アップするには、第10.4.3項「OAMADMINHOST、WEBHOST1およびWEBHOST2におけるWebゲートのインストール」の手順を実行します。
OAMをスケール・アップするには、次のようにします。
http://admin.mycompany.com/consoleでOracle WebLogic Server管理コンソールにログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「ロックして編集」を「チェンジ・センター」メニューでクリックします。
拡張するホスト上の既存サーバーを選択します（例: WLS_OAM1）。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。
サーバー・リスニング・アドレス: 管理対象サーバーが実行するホストの名前です。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポートです。このポートはホスト内で一意である必要があります。
「OK」をクリックします。
新規作成したサーバーWLS_OAM3をクリックします。
SSLリスニング・ポートを設定します。管理対象サーバーが実行するホストで一意にする必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。OAMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローニング元となるソース・サーバーでホスト名検証が無効にされている場合、これらの手順は不要です。クローニングされたサーバーにホスト名検証の設定が伝播されているからです。ホスト名検証を無効にする手順は次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
新しい管理対象サーバーをOAMで登録します。この時点で、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。Oracle OAMコンソールでこれを行います。次のように実行します。
http://admin.mycompany.com/oamconsoleでOAMコンソールにoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「作成」を「アクション」メニューで選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーの実行場所となるホストです。
ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポートです。
OAMプロキシ・ポート: OAMプロキシを実行するポートです。これは当該ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: オープン
「コヒーレンス」タブをクリックします。
ホストで一意な値に「ローカル・ポート」を設定します。
「適用」をクリックします。
「適用」をクリックします。
これで、新しい管理対象サーバーを起動できます。
OAAMをスケール・アップするには、OAAMサーバーとOAAM管理サーバーの両方について同じ手順を実行します。
http://admin.mycompany.com/consoleでOracle WebLogic Serverコンソールにログインします。次のように実行します。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「ロックして編集」を「チェンジ・センター」メニューでクリックします。
拡張するホスト上の既存サーバーを選択します（例: WLS_OAAM1やWLS_OAAM_ADMIN1）。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です（例: WLS_OAAM3）。
サーバー・リスニング・アドレス: 管理対象サーバーが実行するホストの名前です。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポートです。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新規作成サーバーの「WLS_OAAM3」をクリックします。
SSLリスニング・ポートを設定します。管理対象サーバーが実行するホストで一意にする必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。OAAMHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。
新しいサーバーのクローニング元となるソース・サーバーでホスト名検証が無効にされている場合、これらの手順は不要です。クローニングされたサーバーにホスト名検証の設定が伝播されているからです。ホスト名検証を無効にする手順は次のとおりです。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「環境」ノードを「ドメイン構造」ペインで開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
この時点で、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。Oracle OAMコンソールでこれを行います。次のように実行します。
http://admin.mycompany.com/oamconsoleでOAMコンソールにoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「作成」を「アクション」メニューで選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーの実行場所となるホストです。
ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポートです。
OAMプロキシ・ポート: OAMプロキシを実行するポートです。これは各ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: オープン
「適用」をクリックします。
「コヒーレンス」タブをクリックします。
ホストで一意な値に「ローカル・ポート」を設定します。
「適用」をクリックします。
これで、アクセス・サーバーを起動できます。ただし、サーバーを使用するには、それが存在していることをWebゲートに通知する必要があります。この操作は次のように実行します。
http://admin.mycompany.com/oamconsoleでOAMコンソールにoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「エージェント」→「OAMエージェント」→「10gエージェント」を開きます。
変更するWebゲートをダブルクリックします。
「追加」の「+」記号をクリックして、新しいサーバーを「プライマリ・サーバー」リストまたは「セカンダリ・サーバー」リストに追加します。
サーバー名をリストから選択します。
「適用」をクリックします。
このケースでは、SOAコンポーネントとともに構成された管理対象サーバーが実行されているノードがすでに存在しています。このノードには、既存の管理対象サーバー用のミドルウェア・ホーム、Oracleホーム（SOA）およびドメイン・ディレクトリが含まれています。
既存のインストール内容（ミドルウェア・ホームおよびドメイン・ディレクトリ）を使用して、新しいWLS_OIMサーバーとWLS_SOAサーバーを作成できます。Oracle Identity ManagerとOracle SOA Suiteのバイナリを新しい場所にインストールしたり、パックと解凍を実行したりする必要はありません。
次の手順に従って、トポロジをスケール・アップします。
管理コンソールを使用して、WLS_OIM1またはWLS_SOA1をクローニングして新しい管理対象サーバーを作成します。クローニング元となるソース管理対象サーバーは、新しい管理対象サーバーを実行するノード上にすでに存在している必要があります。
管理対象サーバーをクローニングする手順は次のとおりです。
管理コンソールで「環境」→「サーバー」を選択します。
クローニングする管理対象サーバーを選択します（例: WLS_OIM1やWLS_SOA1）。
「クローンの作成」を選択します。
新しい管理対象サーバーに、「WLS_OIMn」または「WLS_SOAn」という名前を付けます。nには、新しい管理対象サーバーを識別するための番号を指定します。
残りの手順では、WLS_SOA1とWLS_OIM1がすでに実行されているOIMHOST1に新しいサーバーを追加することを前提にしています。
リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPアドレスを割り当てます。このサーバーでお薦めしているサーバー移行を実行する予定の場合は、別のノードへの移動を可能にするために、このアドレスはVIP（別称: 浮動IP）である必要があります。このVIPは、すでに実行されている管理対象サーバーで使用されているものとは異なっている必要があります。
新しい管理対象サーバー上で、SOA、OIMおよびUMS用のJMSサーバーを作成します。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成して名前を付けます（例: SOAJMSFileStore_N）。ストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。
|
注意: このディレクトリは、管理対象サーバーを起動する前に、存在する必要があります。存在しないと、起動操作は失敗します。 |
ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/SOAJMSFileStore_N
SOA用の新しいJMSサーバーを作成します（例: SOAJMSServer_N）。このJMSServerではSOAJMSFileStore_Nを使用します。SOAJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー（WLS_SOAn）を指定します。
新しいUMSJMSServer用の新しい永続ストアを作成します（例: UMSJMSFileStore_N）。このストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_N.
|
注意: このディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。新しいUMS用JMSサーバー用のストアとしてSOAJMSFileStore_Nを割り当てることもできます。明確に区別するために、個々の永続ストアを次の手順で使用します。 |
UMS用の新しいJMSサーバーを作成します（例: UMSJMSServer_N）。このJMSServer用に、UMSJMSFileStore_Nを使用します。UMSJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー（WLS_SOAn）を指定します。
新しいOIMJMSServer用の新しい永続ストアを作成します（例: OIMJMSFileStore_N）。このストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_N
|
注意: このディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。新しいOIM用JMSサーバー用のストアとしてSOAJMSFileStore_Nを割り当てることもできます。明確に区別するために、個々の永続ストアを次の手順で使用します。 |
OIM用の新しいJMSサーバーを作成します（例: OIMJMSServer_N）。このJMSServer用に、OIMJMSFileStore_Nを使用します。OIMJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー（WLS_OIMn）を指定します。
SOA JMSモジュールのSubDeploymentターゲットを更新して、先ほど作成したSOA JMSサーバーを含めます。このためには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」（表の「名前」列でハイパーリンクとして表示されている）をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、SOAJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー（WLS_SOA1とWLS_SOA2）の構成ウィザードJMS構成から生成されます。 |
「SOAJMSServerXXXXXX」サブデプロイメントをクリックします。SOAJMSServer_Nと呼ばれる新しいSOA用JMSサーバーをこのサブデプロイメントに追加します。「保存」をクリックします。
UMSJMSSystemResourceのSubDeploymentターゲットを更新して、先ほど作成したUMS用JMSサーバーを含めます。このためには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」（表の「名前」列でハイパーリンクとして表示されている）をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、UCMJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー（WLS_SOA1とWLS_SOA2）の構成ウィザードJMS構成から生成されます。 |
「UMSJMSServerXXXXXX」サブデプロイメントをクリックします。UMSJMSServer_Nと呼ばれる新しいUMS用JMSサーバーをこのサブデプロイメントに追加します。「保存」をクリックします。
OIMJMSModuleのSubDeploymentターゲットを更新して、先ほど作成したOIM用JMSサーバーを含めます。このためには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」（表の「名前」列でハイパーリンクとして表示されている）をクリックします。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、OIMJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー（WLS_OIM1とWLS_OIM2）の構成ウィザードJMS構成から生成されます。 |
「OIMJMSServerXXXXXX」サブデプロイメントをクリックします。OIMJMSServer_Nと呼ばれる新しいOIM用JMSサーバーをこのサブデプロイメントに追加します。「保存」をクリックします。
第13.5.1項「SOA管理対象サーバーのコヒーレンス構成の更新」の説明に従って、Oracle Coherenceを構成します。
新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。
管理コンソールで、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の下の「ディレクトリ」に、デフォルト永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOAn管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。SOAHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。新しいサーバーのクローニング元となったソース・サーバーでホスト名検証がすでに無効化されている場合、これらの手順は不要です（ホスト名検証の設定はクローニングされたサーバーに伝播されているため）。
ホスト名検証を無効にする手順は次のとおりです。
Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAのホストとポートを更新します。次の手順を実行します。
ブラウザを開いて、http://admin.mycompany.com/emのOracle Enterprise Manager Fusion Middleware Controlに移動します。
管理ユーザー資格証明を使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。
|
注意: 前述の手順を実行する際に、1つ以上のOracle Identity Manager管理対象サーバーが実行している必要があります。 |
「Identity and Access」→「oim」に移動します。
「oim」を右クリックして「システムMBeanブラウザ」に移動します。
「アプリケーション定義のMBean」で、「oracle.iam」→「アプリケーション: oim」→「XMLConfig」→「構成」→「XMLConfig.SOAConfig」→「SOAConfig」に移動します。
新しいSOAサーバーのホストとポートでRmiurl属性の値を更新します。「適用」をクリックして、変更を保存します。
Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBにアクセスするために使用されます。これがアプリケーション・サーバーのURLです。Oracle Identity Managerのクラスタ化デプロイメントでは、すべてのSOA管理対象サーバー用URLがあるカンマ区切りリストになります。次はこの属性の値の例です。
t3://oimhost1.mycompany.com:8001,oimhost2.mycompany.com:8001,oimhost3.mycompany.com:8001
管理コンソールから、新しい管理対象サーバーを起動してテストします。
クラスタ内の既存の管理対象サーバーを停止します。
新規作成した管理対象サーバーであるWLS_SOAnが稼働していることを確認します。
新規に作成した管理対象サーバー（http://vip:port/soa-infra）上のアプリケーションにアクセスします。アプリケーションは機能している必要があります。
この新規サーバーのサーバー移行をテストします。新規サーバーの追加先となったノードで、次の手順を実行します。
WLS_SOAnという管理対象サーバーを停止します。
このためには、次のコマンドを実行します。
kill -9 pid
このコマンドでは、その管理対象サーバーのプロセスID（PID）を指定します。ノードのPIDを確認するには、次のコマンドを使用します。
ps -ef | grep WLS_SOAn
ノード・マネージャ・コンソールを参照します。WLS_SOA1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待ちます。これを再起動する前に、分離するまでノード・マネージャで30秒待ちます。
ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。
Web層には、Oracle HTTP Serverのインスタンスが実行されている1つのノードがすでにあります。既存のOracle HTTP Serverバイナリを使用して、新しいOracle HTTP Serverインスタンスを作成できます。Oracle HTTP Serverをスケール・アップするには、第5章「Web層の構成」の手順を実行します。
この手順に加えて、既存のWeb層構成のORACLE_INSTANCE/config/OHS/component/moduleconf内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。
Oracle Fusion Middleware 11g Web層ユーティリティの構成ウィザードを使用して、トポロジをスケール・アップします。ORACLE_HOME/binディレクトリにあるconfig.shスクリプトを実行して、構成ウィザードを起動して、残りの手順に従って新しいOracle HTTP Serverインスタンスを作成します。
新しいOracle HTTP Serverインスタンスのホスト情報とポート情報に基づいてロード・バランサを再構成します。
トポロジをスケール・アウトする際は、新しいサーバーを新しいノードに追加します。このマニュアルで説明しているOracle Identity Managementトポロジの3つすべての層内のコンポーネントは、新しいノードに新しいサーバー・インスタンスを追加することでスケール・アウトできます。
ディレクトリ層には、Oracle Internet Directoryノードが2個（OIDHOST1とOIDHOST2）とOracle Virtual Directoryノードが2個（OVDHOST1とOVDHOST2）あります。各Oracle Internet Directoryノードは、Oracle Internet Directoryインスタンスを実行しています。各Oracle Virtual Directoryノードは、Oracle Virtual Directoryインスタンスを実行しています。Oracle Internet DirectoryインスタンスまたはOracle Virtual Directoryインスタンスは、新しいノードをディレクトリ層に追加することでスケール・アウトできます。
ディレクトリ層にはOracle Internet Directoryノードが2個（OIDHOST1とOIDHOST2）あります。それぞれOracle Internet Directoryインスタンスを実行しています。OIDインスタンスは、新しいノードを既存のOracle Internet Directoryクラスタに追加することでスケール・アウトできます。Oracle Internet Directoryインスタンスをスケール・アウトするには、次の手順を実行します。
第7.2.2項「追加のOracle Internet Directoryインスタンスの構成」の手順に従って、Oracle Internet Directoryを実行する新しいノードを追加します。
第7.3.1項「WebLogicサーバー・ドメインへのOracle Internet Directoryの登録」の手順に従って、新しいOracle Internet DirectoryインスタンスをWebLogicドメインに登録します。
新しいOracle Internet Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。
ディレクトリ層にはノードが2個（OVDHOST1とOVDHOST2）あります。それぞれOracle Virtual Directoryインスタンスを実行しています。Oracle Virtual Directoryを実行するように構成された新しいノードをディレクトリ層に追加することで、Oracle Virtual Directoryをスケール・アウトできます。Oracle Virtual Directoryインスタンスをスケール・アウトするには、次の手順を実行します。
第8.2.2項「追加のOracle Virtual Directoryインスタンスの構成」の手順に従って、Oracle Virtual Directoryを実行する新しいノードを追加します。
第8.3.1項「Oracle WebLogicサーバー・ドメインへのOracle Virtual Directoryの登録」の手順に従って、新しいOracle Virtual DirectoryインスタンスをWebLogicドメインに登録します。
新しいOracle Virtual Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。
アプリケーション層にはノードが5個あります。2個のノード（IDMHOST1とIDMHOST2）では、Oracle Directory Integration PlatformとOracle Directory Services Managerの管理対象サーバーを実行しています。2個のノード（OAMHOST1とOAMHOST2）では、Oracle Access Managerアイデンティティ・サーバーとアクセス・サーバーを実行しています。残りのノードは管理ノード（OAMADMINHOST）で、Oracle Access Manager Webパス、ポリシー・マネージャ、WebゲートおよびOracle HTTP Serverのインスタンスを実行しています。
アプリケーション層には、Oracle Directory Integration PlatformとOracle Directory Services Managerとともに構成された管理対象サーバーが実行されている2つのノード（IDMHOST1とIDMHOST2）がすでに存在します。Oracle Directory Integration PlatformとOracle Directory Services Managerのインスタンスは、管理対象サーバーが配置された新しいノードを既存のクラスタに追加することでスケール・アウトできます。DIPとODSMのインスタンスをスケール・アウトするには、次の手順を実行します。
第9.2項「Oracle Directory Integration PlatformとODSMクラスタの拡張」の手順に従って、トポロジ内のOracle Directory Integration PlatformインスタンスとOracle Directory Services Managerインスタンスをスケール・アウトします。
新しい管理対象サーバーを使用してOracle HTTP Serverモジュールを再構成します。
第9.4項「Oracle Web層と連携するためのODSMの構成」の手順に従って、このタスクを完了します。
新たに追加した管理対象サーバーのホスト名とポートをWebLogicClusterパラメータリストに追加します。
Oracle Access Managerでは、新しいサーバー・インスタンスをインストールする場合、 別個のORACLE_HOMEの場所を指定する必要があります。複数のOracle Access ManagerコンポーネントのインスタンスにおいてORACLE_HOMEを共有することはサポートされていません。
アクセス・サーバーをスケール・アウトするには、第10.4.2.2項「アクセス・サーバーのインストールの起動」の手順を実行します。
Webパスをスケール・アウトするには、第10.3.3項「OAMADMINHOSTにおけるWebパスのインストール」の手順を実行します。
Webゲートをスケール・アウトするには、第10.4.3項「OAMADMINHOST、WEBHOST1およびWEBHOST2におけるWebゲートのインストール」の手順を実行します。
スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。
第4.5.3項「Oracle WebLogic Serverのインストール」の説明に従って、Oracle WebLogic Serverを新しいホストにインストールします。
第4.5.4項「OIM Platform and Directory Services Suiteのインストール」の説明に従って、Oracle Fusion Middlewareのアイデンティティ管理コンポーネントを新しいホストにインストールします。
http://admin.mycompany.com/consoleでOracle WebLogic Server管理コンソールにログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「ロックして編集」を「チェンジ・センター」メニューでクリックします。
拡張するホスト上の既存サーバーを選択します（例: WLS_OAM1）。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。
サーバー・リスニング・アドレス: 管理対象サーバーが実行するホストの名前です。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポートです。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新規作成したサーバーである「WLS_OAM3」をクリックします。
SSLリスニング・ポートを設定します。このポートは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。IDMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローニング元となったソース・サーバーでホスト名検証がすでに無効にされている場合は、これらの手順は不要です。ホスト名検証の設定は、クローニングされたサーバーに伝播されているからです。ホスト名検証を無効にするには、次の手順を実行します。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「環境」ノードを「ドメイン構造」ペインで開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
次のコマンドを使用してIDMHOST1上のドメインをパックします。
pack.sh -domain=ORACLE_BASE/admin/IDMDomain/aserver/IDMDomain -template =/tmp/IDMDomain.jar -template_name="OAM Domain" -managed=true
pack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
次のコマンドを使用して新しいホスト上でドメインを解凍します。
unpack.sh -domain=ORACLE_BASE/admin/IDMDomain/mserver/IDMDomain -template=/tmp/IDMDomain.jar -template_name="OAM Domain" -app_dir=ORACLE_BASE/admin/IDMDomain/mserver/applications
unpack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
コンソールから管理対象サーバーを起動するには、その前にIDMHOST3上でノード・マネージャのプロパティ・ファイルを作成する必要があります。このためには、MW_HOME/oracle_common/common/binにあるsetNMProps.shスクリプトを実行します。次を入力します。
cd MW_HOME/oracle_common/common/bin
./setNMProps.sh
新しい管理対象サーバーをOAMで登録します。この時点で、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。このためには、Oracle OAMコンソールで次の手順を実行します。
http://admin.mycompany.com/oamconsoleで、OAMコンソールにoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「作成」を「アクション」メニューで選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーの実行場所となるホストです（IDMHOST3）。
ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポートです。
OAMプロキシ・ポート: OAMプロキシを実行するポートです。これは当該ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: オープン
「適用」をクリックします。
これで、アクセス・サーバーを起動できます。ただし、サーバーを使用するには、それが存在していることをWebゲートに通知する必要があります。この操作は次のように実行します。
http://admin.mycompany.com/oamconsoleでOAMコンソールにoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「エージェント」→「OAMエージェント」→「10gエージェント」を開きます。
変更するWebゲートをダブルクリックします。
「追加」の「+」アイコンをクリックして、新しいサーバーを「プライマリ・サーバー」リストまたは「セカンダリ・サーバー」リストに追加します。
サーバー名をリストから選択します。
「適用」をクリックします。
Web層を更新します。新しい管理対象サーバーの作成と起動が行われたので、Web層でリクエストの転送が開始します。ただし、新しい管理対象サーバーが作成されたことをWebサーバーに通知することをお薦めします。
このためには、各Web層のOAM.confファイルを更新します。このファイルは、ORACLE_INSTANCE/config/OHS/component name/moduleconfディレクトリにあります。
新しいサーバーをこのファイル内のWebLogicClusterディレクティブに追加します。次に変更前の例を示します。
<Location /OAM_admin>
SetHandler weblogic-handler
WebLogicCluster
OAMhost1.mycompany.com:14200,OAMhost2.mycompany.com:14200
</Location>
変更後は次のようになります。
<Location /OAM_admin>
SetHandler weblogic-handler
WebLogicCluster
OAMhost1.mycompany.com:14200,OAMhost2.mycompany.com:14200,OAMhsot3.mycompany.com:14300
</Location>
スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。次のように実行します。
第4.5.3項「Oracle WebLogic Serverのインストール」の説明に従って、Oracle WebLogic Serverを新しいホストにインストールします。
第4.5.4項「OIM Platform and Directory Services Suiteのインストール」の説明に従って、Oracle Fusion Middlewareのアイデンティティ管理コンポーネントを新しいホストにインストールします。
http://admin.mycompany.com/consoleでWebLogicコンソールにログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「ロックして編集」を「チェンジ・センター」メニューでクリックします。
拡張するホスト上の既存サーバーを選択します（例: WLS_OAAM1やWLS_OAAM_ADMIN1）。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です（例: WLS_OAAM3）。
サーバー・リスニング・アドレス: 管理対象サーバーが実行するホストの名前です。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポートです。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新規作成サーバーの「WLS_OAAM3」をクリックします。
SSLリスニング・ポートを設定します。管理対象サーバーが実行するホストで一意にする必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。OAAMHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。
新しいサーバーのクローニング元となるソース・サーバーでホスト名検証が無効にされている場合、これらの手順は不要です。クローニングされたサーバーにホスト名検証の設定が伝播されているからです。ホスト名検証を無効にする手順は次のとおりです。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「環境」ノードを「ドメイン構造」ペインで開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
次のコマンドを使用してIDMHOST1上のドメインをパックします。
pack.sh -domain=ORACLE_BASE/admin/IDMDomain/aserver/IDMDomain -template =/tmp/IDMDomain.jar -template_name="OAAM Domain" -managed=true
pack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
次のコマンドを使用して新しいホスト上でドメインを解凍します。
unpack.sh -domain=ORACLE_BASE/admin/IDMDomain/mserver/IDMDomain -template=/tmp/IDMDomain.jar -template_name="OAAM Domain" -app_dir=ORACLE_BASE/admin/IDMDomain/mserver/applications
unpack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
コンソールから管理対象サーバーを起動するには、その前にsetNMProps.shスクリプトを実行して、OAAMHOST2上でノード・マネージャのプロパティ・ファイルを作成する必要があります。setNMProps.shスクリプトは、MW_HOME/oracle_common/common/binにあります。次を入力します。
cd MW_HOME/oracle_common/common/bin
./setNMProps.sh
新しいホスト上のノード・マネージャと新しい管理対象サーバーを起動します。
新しい管理対象サーバーの作成と起動が行われたので、Web層でリクエストの転送が開始します。ただし、新しい管理対象サーバーが作成されたことをWebサーバーに通知することをお薦めします。
このためには、各Web層のoaam.confファイルを更新します。このファイルは、ORACLE_INSTANCE/config/OHS/component_name/moduleconfディレクトリにあります。
新しいサーバーをこのファイル内のWebLogicClusterディレクティブに追加します。次に変更前の例を示します。
<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200
</Location>
変更後は次のようになります。
<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster
oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200,oaamhsot3.mycompany.com:14300
</Location>
トポロジをスケール・アウトする際は、SOAとともに構成された新しい管理対象サーバーを新しいノードに追加します。
この項の手順を実行する前に、次の要件を満たしていることを確認してください。
SOAとともに構成された管理対象サーバーが実行されている既存のノードがトポロジ内に存在していること。
新しいノードがWebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること。
共有記憶域内の既存のインストール内容を使用して、新しいWLS_SOA管理対象サーバーまたはWLS_WSM管理対象サーバーを作成してください。新しい場所にWebLogic ServerやSOAのバイナリをインストールする必要はありませんが、新しいノードでドメイン構成をブートストラップするためにパックと解凍を実行する必要があります。
|
注意:
|
次の手順に従って、トポロジをスケール・アウトします。
新しいノードで、SOAのインストール内容とドメイン・ディレクトリが含まれている既存のミドルウェア・ホームをマウントして、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOMEをローカルOracleインベントリにアタッチするには、次のコマンドを実行します。
SOAHOSTn> cd ORACLE_BASE/product/fmw/soa/ SOAHOSTn> ./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_17_R28.0.0-655
ミドルウェア・ホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成して（別のWebLogicがそのノードにインストールされている場合は編集します）、ORACLE_BASE/product/fmwをこのファイルに追加します。
Oracle WebLogic管理コンソールにログインします。
使用される新しいノード用の新しいマシンを作成して、このマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。
Oracle WebLogic Server管理コンソールを使用して、WLS_SOA1をクローニングして新しい管理対象サーバーを作成します。このサーバーに「WLS_SOAn」という名前を付けます（nには番号を指定します）。
|
注意: これらの手順では、それまで管理対象サーバーが実行されていなかったノード「n」に新しいサーバーを追加することを前提にしています。 |
新しい管理対象サーバー用に使用するホスト名またはIPアドレスを、この管理対象サーバーのリスニング・アドレスとして割り当てます。
このサーバーに対してサーバー移行を実行する予定の場合は（これをお薦めします）、これはサーバーのVIPアドレス（別称: 浮動IPアドレス）である必要があります。このVIPアドレスは、既存の管理対象サーバーで使用されているものとは異なっている必要があります。
新しい管理対象サーバー上で、SOA、OIM（該当する場合）およびUMS用のJMSサーバーを作成します。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成して名前を付けます（例: SOAJMSFileStore_N）。ストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。次に例を示します。
ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_N
|
注意: このディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。 |
SOA用の新しいJMSサーバーを作成します（例: SOAJMSServer_N）。このJMSServerではSOAJMSFileStore_Nを使用します。SOAJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー（WLS_SOAn）を指定します。
新しいUMSJMSServer用の新しい永続ストアを作成して、名前を付けます（例: UMSJMSFileStore_N）。ストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore _N
|
注意:
|
UMS用の新しいJMSサーバーを作成します（例: UMSJMSServer_N）。このJMSサーバー用に、UMSJMSFileStore_Nを使用します。UMSJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー（WLS_SOAn）を指定します。
新しいOIMJMSServer用の新しい永続ストアを作成して、名前を付けます（例: OIMJMSFileStore_N）。ストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_N
|
注意:
|
OIM用の新しいJMSサーバーを作成します（例: OIMJMSServer_N）。このJMSサーバー用に、OIMJMSFileStore_Nを使用します。OIMJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー（WLS_SOAn）を指定します。
SOA JMSモジュールのSubDeploymentターゲットを更新して、先ほど作成したSOA JMSサーバーを含めます。このためには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」（表の「名前」列でハイパーリンクとして表示されている）をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。SOAJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名はSOAJMSServer形式のランダムな名前で、最初の2つのサーバー（WLS_SOA1とWLS_SOA2）の構成ウィザードJMS構成から生成されます。 |
「SOAJMSServerXXXXXX」サブデプロイメントをクリックします。SOAJMSServer_Nと呼ばれる新しいSOA用JMSサーバーをこのサブデプロイメントに追加します。「保存」をクリックします。
UMSJMSSystemResourceのSubDeploymentターゲットを更新して、先ほど作成したUMS用JMSサーバーを含めます。このためには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」（表の「名前」列でハイパーリンクとして表示されている）をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。UMSJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュールはUMSJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー（WLS_SOA1とWLS_SOA2）の構成ウィザードJMS構成から生成されます。 |
「UMSJMSServerXXXXXX」サブデプロイメントをクリックします。UMSJMSServer_Nと呼ばれる新しいUMS用JMSサーバーをこのサブデプロイメントに追加します。「保存」をクリックします。
OIMJMSModuleのSubDeploymentターゲットを更新して、先ほど作成したOIM用JMSサーバーを含めます。このためには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」（表の「名前」列でハイパーリンクとして表示されている）をクリックします。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュールはOIMJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー（WLS_SOA1とWLS_SOA2）の構成ウィザードJMS構成から生成されます。 |
「OIMJMSXXXXXX」サブデプロイメントをクリックします。OIMJMSServer_Nと呼ばれる新しいOIM用JMSサーバーをこのサブデプロイメントに追加します。「保存」をクリックします。
次のようにpackコマンドをSOAHOST1上で実行して、テンプレート・パックを作成します。
Prompt> cd ORACLE_COMMON_HOME/common/bin
Prompt> ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
次のコマンドをSOAHOST1上で実行して、作成されたテンプレート・ファイルをSOAHOSTNにコピーします。
Prompt> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_BASE/product/fmw/soa/common/bin
次のようにunpackコマンドをSOAHOSTN上で実行して、管理対象サーバーのドメイン・ディレクトリ内にテンプレートを解凍します。
SOAHOSTN> cd ORACLE_BASE/product/fmw/soa/common/bin SOAHOSTN> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar
第13.5.1項「SOA管理対象サーバーのコヒーレンス構成の更新」の説明に従って、Oracle Coherenceを構成します。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAのホストとポートを更新します。次の手順を実行します。
ブラウザを開いて、http://admin.mycompany.com/emのOracle Enterprise Manager Fusion Middleware Controlに移動します。
管理ユーザー資格証明を使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。
|
注意: 前述の手順を実行する際に、1つ以上のOracle Identity Manager管理対象サーバーが実行している必要があります。 |
「Identity and Access」→「oim」に移動します。
「oim」を右クリックして「システムMBeanブラウザ」に移動します。
「アプリケーション定義のMBean」で、「oracle.iam」→「アプリケーション: oim」→「XMLConfig」→「構成」→「XMLConfig.SOAConfig」→「SOAConfig」に移動します。
新しいSOAサーバーのホストとポートでRmiurl属性の値を更新します。「適用」をクリックして、変更を保存します。
Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBにアクセスするために使用されます。これがアプリケーション・サーバーのURLです。Oracle Identity Managerのクラスタ化デプロイメントでは、すべてのSOA管理対象サーバー用URLがあるカンマ区切りリストになります。次はこの属性の値の例です。
t3://oimhost1.mycompany.com:8001
oimhost2.mycompany.com:8001
oimhost3.mycompany.com:8001
新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。
管理コンソールで、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の下の「ディレクトリ」に、デフォルト永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOAn管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。SOAHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。新しいサーバーのクローニング元となったソース・サーバーでホスト名検証がすでに無効化されている場合、これらの手順は不要です（ホスト名検証の設定はクローニングされたサーバーに伝播されているため）。
ホスト名検証を無効にする手順は次のとおりです。
「環境」ノードを「ドメイン構造」ウィンドウで開きます。
Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
新しいノード上でノード・マネージャを起動します。ノード・マネージャを起動するには、既存ノードの共有記憶域内のインストール内容を使用して、次のように新しいノードのホスト名をパラメータとして渡してノード・マネージャを起動します。
SOAHOSTN> WL_HOME/server/bin/startNodeManager new_node_ip
Oracle WebLogic Server管理コンソールから、新しい管理対象サーバーを起動してテストします。
クラスタ内の既存の管理対象サーバーをすべて停止します。
新規作成した管理対象サーバーであるWLS_SOAnが稼働していることを確認します。
新規に作成した管理対象サーバー（http://vip:port/soa-infra）上のアプリケーションにアクセスします。アプリケーションは機能している必要があります。
新しい管理対象サーバーのサーバー移行を構成します。
|
注意: この新しいノードでは既存の共有記憶域のインストール内容が使用されているため、このノードではすでにノード・マネージャが使用されているとともに、ネットマスク、インタフェースおよびwlsifconfigスクリプトのスーパーユーザー権限が含まれたサーバー移行向けに構成された環境が使用されています。新しいSOA管理対象サーバーの浮動IPアドレスはすでに新しいノードに存在しています。 |
次の手順に従ってサーバー移行を構成します。
管理コンソールにログインします。
左側のペインで「環境」を開き、「サーバー」を選択します。
移行を構成する対象となるサーバー（ハイパーリンクとして表示）を表の「名前」列から選択します。そのサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。
|
注意: 新しいサーバーの移行ターゲットとして、最も負荷が小さいマシンを指定してください。このノードで追加の管理対象サーバーを維持するために十分な使用可能リソースを確保するために、必須容量計画を完了しておく必要があります。 |
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
この新規サーバーのサーバー移行をテストします。新規サーバーの追加先となったノードで、次の手順を実行します。
1. WLS_SOAn管理対象サーバーを強制的に停止します。
2. このためには、次のコマンドを実行します。
kill -9 pid
このコマンドでは、当該管理対象サーバーのプロセスID（PID）を指定します。ノードのPIDを確認するには、次のコマンドを使用します。
ps -ef | grep WLS_SOAn
3. ノード・マネージャ・コンソールを参照します。WLS_SOA1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。
4. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待ちます。これを再起動する前に、分離するまでノード・マネージャで30秒待ちます。
5. ノード・マネージャによって再起動されたサーバーを再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。
Web層には2つのノードがあり、それぞれOracle HTTP Serverインスタンスが実行されています。Oracle HTTP Serverを実行するように構成された新しいノードをWeb層に追加することで、Oracle HTTP Serverのコンポーネントをスケール・アウトできます。Oracle HTTP Serverをスケール・アウトするには、次の項の手順を実行します。
既存のWeb層構成のORACLE_INSTANCE/config/OHS/component/moduleconf内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。
表19-1には、11g Oracle Identity Managementエンタープライズ・デプロイメントでバックアップする静的アーティファクトを示しています。
表19-1 Identity Managementエンタープライズ・デプロイメントでバックアップする静的アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
Oracleホーム（データベース） |
Oracle RACデータベースのホスト: INFRADBHOST1 INFRADBHOST2 |
ユーザー定義 |
ディレクトリ層 |
|
MW_HOME（OID） |
OIDHOST1 OIDHOST2 |
MWホーム:
ORACLEホーム: OIDHOST1とOIDHOST2の両方における |
ディレクトリ層 |
|
MW_HOME（OVD） |
OVDHOST1 OVDHOST2 |
MWホーム:
ORACLEホーム: OVDHOST1とOVDHOST2の両方における |
ディレクトリ層 |
|
MW_HOME（DIP、ODSM、OIM、OAAM、OAM11g、OIFおよび管理サーバー） |
IDMHOST1 IDMHOST2 |
FMWホーム:
DIP/ODSM ORACLEホーム: IDMHOST1とIDMHOST2の両方における 管理サーバーのORACLEホーム: IDMHOST1とIDMHOST2の両方における |
アプリケーション層 |
|
MW_HOME（OHS） |
WEBHOST1 WEBHOST2 |
MWホーム:
ORACLEホーム: WEBHOST1における ORACLEホーム: WEBHOST2における |
Web層 |
|
OAMADMINHOST（OAMの管理用に使用） |
OAMADMINHOST |
MWホーム:
OHSのORACLEホーム:
WEBパス・ホーム:
ポリシー・マネージャ・ホーム:
WEBゲート・ホーム:
|
アプリケーション層 |
|
OAM |
OAMHOST1 OAMHOST2 |
ORACLE ACCESS MANAGERホーム:
アイデンティティ・サーバー・ホーム:
アクセス・サーバー・ホーム:
|
アプリケーション層 |
|
関連ファイルのインストール |
各ホスト |
OraInventory:
Windowsレジストリ: （HKEY_LOCAL/MACHINE/Oracle） |
対象外 |
表19-2には、11g Oracle Identity Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクトを示しています。
表19-2 Identity Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
ドメイン・ホーム |
|
|
アプリケーション層 |
|
アプリケーション・アーティファクト（earファイルとwarファイル） |
|
WebLogic Server管理コンソールからすべてのデプロイメント（Oracle Directory Integration PlatformとOracle Directory Services Managerを含む）を参照して、すべてのアプリケーション・アーティファクトを特定してください。 |
アプリケーション層 |
|
インスタンス・ホーム（OHS） |
|
|
Web層 |
|
インスタンス・ホーム（OHS） |
OAMADMINHOST |
/u01/app/oracle/admin/ohs_inst/oamAdmin_ohs |
アプリケーション層 |
|
OIDインスタンス・ホーム |
OIDHOST1OIDHOST2 |
/u01/app/oracle/admin/oid_inst1
/u01/app/oracle/admin/oid_inst2 |
ディレクトリ層 |
|
OVDインスタンス・ホーム |
|
|
ディレクトリ層 |
|
Oracle RACデータベース |
|
ユーザー定義 |
ディレクトリ層 |
|
OAM |
|
すべての構成は、この表で示しているそれぞれのホーム・ディレクトリ内にあります。インスタンス・ホームはありません。 |
アプリケーション層 |
Oracle Fusion Middlewareコンポーネントのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
この項では、Oracle Fusion Middlewareのパッチ・ファイルを適用する方法、および最小限の停止時間でOracle Identity Managementコンポーネントにパッチを適用する方法を説明します。
この項の内容は次のとおりです。
Oracle Fusion Middlewareソース・ファイルへのパッチ適用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
最小限の停止時間でOracle Identity Managementコンポーネントにパッチを適用するには、次の指示に従うことをお薦めします。
OIDHOST1とOVDHOST1のLDAPトラフィックをOIDHOST2とOVDHOST2にルーティングします。
パッチを適用する場所となるホスト（OIDHOST1またはOVDHOST1）上のOracle Internet DirectoryサーバーまたはOracle Virtual Directoryサーバーを停止します。
Oracle Internet DirectoryパッチまたはOracle Virtual Directoryパッチをホストで適用します。
Oracle Internet DirectoryまたはOracle Virtual Directoryのサーバーをホストで起動します。
パッチをテストします。
トラフィックを再びOIDHOST1またはOVDHOST1にルーティングします。
アプリケーションが正常に動作していることを確認します。
OIDHOST2とOVDHOST2のLDAPトラフィックをOIDHOST1とOVDHOST1にルーティングします。
パッチを適用する場所となるホスト（OIDHOST2またはOVDHOST2）上のOracle Internet DirectoryサーバーまたはOracle Virtual Directoryサーバーを停止します。
Oracle Internet DirectoryパッチまたはOracle Virtual Directoryパッチをホストで適用します。
Oracle Internet DirectoryまたはOracle Virtual Directoryのサーバーをホストで起動します。
パッチをテストします。
パッチを適用した両方のホスト（OIDHOST1とOIDHOST2、またはOVDHOST1とOVDHOST2）にトラフィックをルーティングします。
この項では、このマニュアルで説明しているIdentity Managementエンタープライズ・デプロイメントで発生する可能性のある一般的な問題のトラブルシューティング方法を説明します。
この項の内容は次のとおりです。
この項では、Oracle Internet Directoryで発生する可能性のある一般的な問題とその解決策を紹介します。
問題
Oracle Internet Directoryサーバーが応答しません。ロード・バランシング・ルーターがICMPメッセージを監視目的でLDAP SSLポートに送信するように構成されている場合は、Oracle Internet DirectoryサーバーはSSLネゴシエーションを開始する際にハングすることがあります。したがって、ロード・バランシング・ルーターがLDAP SSLポートの監視のためにICMPメッセージを使用することは避ける必要があります。
ソリューション
TCPやLDAPのプロトコル自体など、別のものを使用してください。
また、LDAPの非SSLポートを監視することも、LDAP可用性を検出するのに十分です。
問題
Oracle Internet DirectoryサーバーへのSSO/LDAPアプリケーション接続が切断されています。
ソリューション
ロード・バランシング・ルーターのタイムアウトとSSO/Applicationタイムアウト構成パラメータを確認してください。SSO/LDAPアプリケーションのタイムアウト値は、LBR IDLEタイムアウト値未満にする必要があります。
問題
LDAPアプリケーションがLDAPエラー53（DSAが動作しようとしない）を受信しています。LDAPトランザクションの途中でいずれかのデータベース・ノードが停止すると、Oracle Internet Directoryサーバーはエラー53をLDAPクライアントに送信します。
ソリューション
Oracle Internet Directoryデータベース・ノードが停止した理由を確認するには、次の場所にあるOracle Internet Directoryのログを参照してください。
ORACLE_INSTANCE/diagnostics/logs/OID/oidldapd01s*.log
問題
TNSNAMES.ORAやTAFの構成に関連した問題があります。
ソリューション
Oracle Databaseの高可用性の概要に関するマニュアルを参照してください。
この項では、Oracle Virtual Directoryで発生する可能性のある一般的な問題とその解決策を紹介します。
問題
Oracle Virtual Directoryサーバーが応答しません。ロード・バランシング・ルーターがICMPメッセージを監視目的でLDAP SSLポートに送信するように構成されている場合は、Oracle Virtual DirectoryサーバーはSSLネゴシエーションを開始する際にハングすることがあります。したがって、ロード・バランシング・ルーターがLDAP SSLポートの監視のためにICMPメッセージを使用することは避ける必要があります。
ソリューション
TCPやLDAPのプロトコル自体など、別のものを使用してください。
また、LDAPの非SSLポートを監視することも、LDAP可用性を検出するのに十分です。
問題
Oracle Virtual DirectoryサーバーへのSSO/LDAPアプリケーション接続が切断されています。
ソリューション
ロード・バランシング・ルーターのタイムアウトとSSO/Applicationタイムアウト構成パラメータを確認してください。SSO/LDAPアプリケーションのタイムアウト値は、LBR IDLEタイムアウト値未満にする必要があります。
問題
TNSNAMES.ORAやTAFの構成に関連した問題があります。
ソリューション
Oracle Databaseの高可用性の概要に関するマニュアルを参照してください。
この項では、Oracle Directory Integration Platformで発生する可能性のある一般的な問題とその解決策を紹介します。
問題
インスタンスが正常に動作していません。
ソリューション
インスタンスの個別ログをチェックします。たとえば、WLS_ODS1にデプロイされているインスタンスが動作していない場合は、WLS_ODS1-diagnostic.logファイルをチェックします。
問題
Oracle RACフェイルオーバー時に、Oracle Directory Integration Platformアプリケーションが実行されている管理対象サーバーのログ・ファイルに次のような例外が記録されます。
RuntimeException:
[2008-11-21T00:11:10.915-08:00] [WLS_ODS] [ERROR] []
[org.quartz.impl.jdbcjobstore.JobStoreTX] [tid: 25] [userId: <anonymous>]
[ecid: 0000Hqy69UiFW7V6u3FCEH199aj0000009,0] [APP: DIP] ClusterManager: Error
managing cluster: Failed to obtain DB connection from data source
'schedulerDS': java.sql.SQLException: Could not retrieve datasource via JNDI
url 'jdbc/schedulerDS' java.sql.SQLException: Cannot obtain connection:
driverURL = jdbc:weblogic:pool:schedulerDS, props =
{EmulateTwoPhaseCommit=false, connectionPoolID=schedulerDS,
jdbcTxDataSource=true, LoggingLastResource=false,
dataSourceName=schedulerDS}.[[
Nested Exception: java.lang.RuntimeException: Failed to setAutoCommit to true
for pool connection
AuthenticationException while connecting to OID:
[2008-11-21T00:12:08.812-08:00] [WLS_ODS] [ERROR] [DIP-10581] [oracle.dip]
[tid: 11] [userId: <anonymous>] [ecid: 0000Hqy6m54FW7V6u3FCEH199apO000000,0]
[APP: DIP] DIP was not able to get the context with the given details {0}[[
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
Credentials]
ほとんどの例外は、次の例のようにスケジューラまたはLDAPに関連するものです。
1. 'jdbc/schedulerDS' java.sql.SQLExceptionというJNDI urlを通じてデータソースを取得できませんでした。
2. javax.naming.AuthenticationException: [LDAPエラー・コード49 - 無効な資格証明]
ソリューション
Oracle RACフェイルオーバー時に、Oracle Directory Integration Platformアプリケーションが実行されている管理対象サーバーのログ・ファイルに例外が記録されます。これらのエラーが発生するのは、WebLogic Serverプラットフォーム上で構成されたマルチ・データソースが、フェイルオーバー時にOracle RACデータベース・インスタンスの状態を確認しようとしたときです。これらは無害なエラーであるため、無視してかまいません。Oracle Directory Integration Platformアプリケーションは、1〜2分後に回復して正常に動作し始めます。Oracle RACフェイルオーバーの場合、1つのインスタンスが常時実行されていると、Oracle Directory Integration Platformの停止時間はありません。
この項では、Oracle Directory Services Managerで発生する可能性のある一般的な問題とその解決策を紹介します。
Oracle Directory Services Managerにログインしたら、同じブラウザ・ウィンドウから複数のディレクトリ・インスタンスに接続できます。
同じブラウザ・プログラムの複数のウィンドウを使用して、それぞれ異なるディレクトリに同時に接続することは避けてください。このようにすると、ターゲット到達不能エラーが発生します。
Internet ExplorerやFirefoxなどの異なるブラウザ・プログラムから同じOracle Directory Services Managerインスタンスにログインして、それぞれ異なるディレクトリ・インスタンスに接続できます。
ブラウザの言語設定を変更した場合は、新しい設定を使用するためにそのセッションを更新する必要があります。セッションを更新するには、現在のサーバー接続を切断するか、ブラウザ・ページをリフレッシュして（[F5]を押すか、Oracle Directory Services ManagerのURLをURLフィールドに再入力して[Enter]を押します）同じサーバーに再接続するか、またはブラウザを終了してから再起動します。
問題
Oracle Enterprise Manager Fusion Middleware ControlからOracle Directory Services Managerを起動するために、「Oracle Internet Directory」ターゲット内の「Oracle Internet Directory」メニューで「Directory Services Manager」を選択してから、「データ・ブラウザ」、「スキーマ」、「セキュリティ」または「拡張」を選択しました。
しかし、Oracle Directory Services Managerが開きません。場合によっては、エラー・メッセージが表示されます。
ソリューション
これはインストールに問題がある可能性があります。『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
問題
Oracle HTTP Serverを使用してOracle Directory Services Managerフェイルオーバーを実行すると、フェイルオーバーが透過的になりません。次の手順を実行すると、この現象が発生します。
Oracle HTTP Serverを使用して、高可用性アクティブ/アクティブ構成でOracle Directory Services Managerはデプロイされています。
Oracle HTTP Serverの名前とポート番号を使用して、Oracle Directory Services Managerのページを表示します。
Oracle Internet Directoryサーバーに接続します。
Oracle Directory Services Manager Oracle HTTP Serverの現在のホストとポートを使用して、Oracle Internet Directoryサーバーを操作します。
WebLogic Server管理コンソールを使用した際、管理対象サーバーを1つずつ停止します。
Oracle Directory Services Managerのページとポート、およびOracle Internet Directoryに対して以前に確立された接続に戻ります。
これを実行すると、Oracle Directory Services Managerのページと新しい接続を再確立するように求めるメッセージが表示されます。
ソリューション
この問題が発生した場合、次の手順を実行します。
Webブラウザで、現在のOracle Directory Services Managerページを終了します。
新しいWebブラウザ・ページを起動し、Oracle Directory Services Manager Oracle HTTP Serverの同じ名前とポートを指定します。
以前に操作していたOracle Internet Directoryサーバーへの新しい接続を再確立します。
問題
Oracle Directory Services Managerでは、Oracle Internet Directoryとの接続が一時的に切断されて、LDAPサーバーが停止しているというメッセージが表示されます。
ソリューション
Oracle Directory Services Managerがロード・バランサを介してOracle Internet Directoryに接続されている高可用性構成では、Oracle Directory Services Managerは、Oracle Internet Directoryのいずれかのインスタンスから別のインスタンスへのフェイルオーバー時に、サーバーが停止していることを報告します。他の構成では、このメッセージでは、Oracle Internet Directoryが停止されてから再起動されたことが示される場合があります。どちらの場合でも、接続が1分以内に再確立されて、再ログインせずに続行できるようになります。
問題
Oracle Directory Services Managerでは、Oracle RACデータベースを使用しているOracle Internet Directoryインスタンスとの接続が一時的に切断されます。Oracle Directory Services Managerでは、次のメッセージが表示されることがあります。
LDAPエラー・コード53 - この機能は組み込まれていません
ソリューション
このエラーは、Oracle Internet Directoryインスタンスが使用しているOracle Databaseのフェイルオーバー時に発生する可能性があります。接続が1分以内に再確立し、再ログインせずに続行できます。
問題
次の手順を実行して、Oracle HTTP ServerがOracle Directory Services Managerのリクエストを、クラスタ化されたOracle WebLogic Server環境内の複数のOracle WebLogic Serverにルーティングするように構成する必要があります。
ソリューション
次の手順を実行します。
Oracle HTTP Serverのhttpd.confファイルのバックアップ・コピーを作成します。この手順の実行後に問題が発生した場合は、このバックアップ・コピーを使用してファイルを復元します。
次のテキストをOracle HTTP Serverのhttpd.confファイルの末尾に追加して、変数プレースホルダ値を、各自の環境に固有のホスト名と管理対象サーバー・ポート番号に置換します。先頭行として必ず「<Location /odsm/ >」を入力してください。「<Location /odsm/faces >」や「<Location /odsm/faces/odsm.jspx >」を入力すると、Oracle Directory Services Managerのインタフェースが正しく表示されないことがあります。
<Location /odsm/ >
SetHandler weblogic-handler
WebLogicCluster host-name-1:managed-server-port,host-name_2:managed_server_port
</Location>
第19.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを停止してから起動して、構成の変更内容をアクティブ化します。
|
注意: Oracle Directory Services Managerの接続先であるクラスタ内のOracle WebLogic Serverで障害が発生すると、Oracle Directory Services Managerの接続が切断されて、セッション・タイムアウトのメッセージが表示されます。Oracle Directory Services Managerに再びログインした後は、Oracle Directory Services Managerのリクエストは、httpd.confファイルで指定されたクラスタ内のセカンダリOracle WebLogic Serverにルーティングされます。 |
問題
Webブラウザを使用してOracle Directory Services Managerにアクセスできません。
ソリューション
Oracle Virtual Directoryサーバーが稼働していることを確認します。Oracle Directory Services ManagerからOracle Virtual Directoryサーバーに接続するには、このサーバーが稼働している必要があります。
「サーバー」、「ポート」、「ユーザー名」および「パスワード」の各フィールドに正しい資格証明を入力したことを確認します。ldapbindコマンドをターゲットのOracle Virtual Directoryサーバーに対して実行することで、サーバー、ユーザー名およびパスワードの資格証明を確認できます。
サポートされているブラウザを使用していることを確認します。Oracle Directory Services Managerは、次のブラウザをサポートしています。
Internet Explorer 7
Firefox 2.0.0.2および3.0
Safari 3.1.2（デスクトップ）
Google Chrome 0.2.149.30
|
注意: Oracle Directory Services Managerはこれらのブラウザをすべてサポートしていますが、認定されているのはInternet Explorer 7とFirefox 2.0.0.2のみです。 |
問題
Oracle Enterprise Manager Fusion Middleware ControlからOracle Directory Services Managerを起動するために、「Oracle Virtual Directory」ターゲットで「Oracle Virtual Directory」メニューの「Directory Services Manager」エントリからいずれかのオプションを選択しても、Oracle Directory Services Managerが開きません。
ソリューション
これはインストールに問題がある可能性があります。『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
問題
Oracle HTTP Serverを使用してOracle Directory Services Managerフェイルオーバーを実行すると、フェイルオーバーが透過的になりません。次の手順を実行すると、この現象が発生します。
Oracle HTTP Serverを使用して、高可用性アクティブ/アクティブ構成でOracle Directory Services Managerはデプロイされています。
Oracle HTTP Serverの名前とポート番号を使用して、Oracle Directory Services Managerのページを表示します。
Oracle Virtual Directoryサーバーに接続します。
Oracle Directory Services Manager Oracle HTTP Serverの現在のホストとポートを使用して、Oracle Virtual Directoryサーバーを操作します。
WebLogic Server管理コンソールを使用した際、管理対象サーバーを1つずつ停止します。
Oracle Directory Services Managerのページとポート、およびOracle Virtual Directoryに対して以前に確立された接続に戻ります。これを実行すると、Oracle Directory Services Managerのページと新しい接続を再確立するように求めるメッセージが表示されます。
ソリューション
この問題が発生した場合、次の手順を実行します。
Webブラウザで、現在のOracle Directory Services Managerページを終了します。
新しいWebブラウザ・ページを起動し、Oracle Directory Services Manager Oracle HTTP Serverの同じ名前とポートを指定します。
以前に操作していたOracle Virtual Directoryサーバーへの新しい接続を再確立します。
問題
Oracle Directory Services Managerでは、Oracle RACデータベースを使用しているOracle Virtual Directoryインスタンスとの接続が一時的に切断されます。Oracle Directory Services Managerでは、「LDAPエラー・コード53 - この機能は組み込まれていません」というメッセージが表示されることがあります。
ソリューション
このエラーは、Oracle Virtual Directoryインスタンスが使用しているOracle Databaseのフェイルオーバー時に発生する可能性があります。接続が1分以内に再確立し、再ログインせずに続行できます。
Oracle Access Manager 10.1.4.3ドキュメント・セット内のマニュアルのほとんどには、トラブルシューティングの付録セクションが含まれています。
Oracle Access Managerの特定のコンポーネントや機能に関するトラブルシューティング情報については、Oracle Access Manager 10.1.4.3ドキュメント・セット内の適切なマニュアルを参照してください。Oracle Access Managerドキュメント・セット内の各マニュアルの説明については、Oracle Access Managerの概要に関するマニュアルで、マニュアルの手引きに関する項を参照してください。
問題
Oracle WebLogic管理コンソールにアクセスするためにOracle HTTP Serverとロード・バランシング・ルーターを構成した後に、特定の変更をアクティブ化すると、WebLogic Server管理コンソールのログイン画面にリダイレクトされます。
ソリューション
この現象は、管理コンソールを使用してポート、チャンネルおよびセキュリティの設定に加えられた変更が、管理コンソールによって追跡される結果として発生します。特定の変更については、コンソールによってユーザーのブラウザが管理サーバーのリスニング・アドレスにリダイレクトされることがあります。リダイレクションに関係なく、アクティブ化が完了します。再びログインする必要はありません。ユーザーは単にURLを次の値に変更して、管理コンソールのホーム・ページに直接アクセスできます。
admin.mycompany.com/console/console.portal
問題
Oracle Access Managerを構成した後に、特定の変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされます（アクティブ化が実行された場所のコンテキスト・メニューにリダイレクトされるかわりに）。
ソリューション
この現象は、Oracle Access Managerのシングル・サインオンが構成されている場合は想定されるものであり、管理サーバーによって実行されるリダイレクションの結果として生じます。リダイレクションに関係なく、アクティブ化が完了します。必要に応じて、ユーザーは適切なコンテキスト・メニューに手動で再びアクセスしてください。
問題
ポリシー・ドメインに無効なURLや正しくないURLが含まれている場合に、正しいURLを使用してOAM構成ツールを実行しても、ポリシー・マネージャが更新されません（このツールが正常に完了した場合でも同様です）。
ソリューション
OAM構成ツールは、既存のapp_domain名を使用して実行されると、新しいURLを既存のポリシー・ドメインに追加します。このツールは、いずれの既存URLも削除しません。したがって、ポリシー・マネージャ・コンソールを使用して無効なURLを削除する必要があります。次の手順に従って、既存のポリシー・ドメイン内のURLを更新します。
次のURLを使用してポリシー・マネージャ・コンソールにアクセスします。
http://hostname:port/access/oblix
たとえば、次のURLをWebブラウザで入力します。
http://oamadminhost.mycompany.com:7777/access/oblix
プロンプトが表示されたら、administratorユーザーの資格証明を使用してログインします。
初期ページで、「ポリシー・マネージャ」リンクをクリックします。
ポリシー・マネージャ・コンソールで、「ポリシー・ドメイン」リンクをクリックします。
「ポリシー・ドメイン」ページで、適切なポリシー・ドメインのリンクをクリックします。
「ポリシー・ドメイン」ページで、「リソース」タブを選択します。
「リソース」ページで、有効なURLまたは正しくないURLを選択して削除します。
この項では、Oracle Identity Managementエンタープライズ・デプロイメントに関する他の推奨事項を紹介します。
ほとんどの本番デプロイメント環境ではファイアウォールが使用されます。データベース接続は複数のファイアウォールにまたがって確立されるため、データベース接続がタイムアウトにならないようにファイアウォールを構成することをお薦めします。Oracle Real Application Cluster（Oracle RAC）については、データベース接続はOracle RAC VIPとデータベース・リスナー・ポートを使用して確立されます。ファイアウォールがこれらの接続をタイムアウトさせないように構成する必要があります。そのような構成が不可能な場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルで、SQLNET.EXPIRE_TIME=nというパラメータを設定します（nは分単位の時間）。この値を、ネットワーク・デバイス（ファイアウォール）の既知のタイムアウト値より小さい値に設定します。Oracle RACについては、このパラメータをすべてのOracleホーム・ディレクトリで設定します。
