| Oracle® Exalogic Elastic Cloud Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド リリースEL X2-2、X3-2、X4-2およびX5-2 E51446-03 |
|
 前 |
 次 |
| Oracle® Exalogic Elastic Cloud Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド リリースEL X2-2、X3-2、X4-2およびX5-2 E51446-03 |
|
前 |
次 |
この章では、アイデンティティ管理トポロジをセットアップした後に実行できるいくつかの操作について説明します。これらの操作には、モニタリング、スケーリング、トポロジのバックアップ、トラブルシューティングなどがあります。
この章には次のトピックが含まれます:
この項では、アイデンティティ管理のためのOracleエンタープライズ・デプロイメントの各種コンポーネントを起動、停止および再起動する方法について説明します。
この項の内容は次のとおりです。
インフラストラクチャ全体を起動するときは、次の順序でコンポーネントを起動します(トポロジ内にないものは無視してください)。
データベース
データベース・リスナー
Oracle Unified Directory
ノード・マネージャ
Oracle Access Managerサーバー
WebLogic管理サーバー
Oracle Traffic Director
SOAサーバー
Oracle Identity Managerサーバー
Oracle Unified Directoryを起動および停止する手順は、次のとおりです。
Oracle Unified Directoryを起動するには、次のコマンドを発行します。
OUD_ORACLE_INSTANCE/OUD/bin/start-ds
Oracle Access Manager管理対象サーバーを起動および停止する手順は、次のとおりです。
通常、Access Manager管理対象サーバーは、WebLogicコンソールを使用して起動します。しかし、管理コンソールのシングル・サインオンを有効にした後で、コンソールにアクセスするには、1つ以上のAccess Managerサーバーが実行されている必要があります。Access Managerサーバーが実行されていない場合は、WLSTを使用して起動できます。
LinuxまたはUNIXでWLSTを起動するには、次のように入力します。
cd ORACLE_COMMON_HOME/common/bin ./wlst.sh
WLSTシェルで、次のコマンドを実行します。
nmConnect('Admin_User','Admin_Password', 'OAMHOST','Port', 'domain_name','MSERVER_HOME')
nmStart('OAMServer')
Portは、第A.3項のNMGR_PORTです。domain_nameは、ドメインの名前です。Admin_UserおよびAdmin_Passwordは、第9.5.4項「ノード・マネージャ資格証明の更新」の手順2で入力した、ノード・マネージャのユーザー名およびパスワードです。次に例を示します。
nmConnect('weblogic','password', 'IDMHOST1','5556', 'IDMDomain','MSERVER_HOME')
nmStart('WLS_OAM1')
別のサーバーがすでに実行されている場合、Oracle Access Manager管理対象サーバーを起動するには、第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、WebLogicコンソールにログインします。
続けて、次の手順を実行します。
「ドメイン構造」メニューで、「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
OAMサーバー(WLS_OAM1またはWLS_OAM2、あるいはその両方)を選択します。
「起動」ボタンをクリックします。
サーバーを起動するかどうか確認を求められたら、「はい」をクリックします。
Oracle Access Manager管理対象サーバーを停止するには、第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、WebLogicコンソールにログインします。続けて、次の手順を実行します。
「ドメイン構造」メニューで、「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
OAMサーバー(WLS_OAM1またはWLS_OAM2、あるいはその両方)を選択します。
「停止」ボタンをクリックし、「ただちに強制停止」を選択します。
サーバーを停止するかどうか確認を求められたら、「はい」をクリックします。
次の各項の説明に従って、WebLogic管理サーバーを起動および停止します。
|
注意:
|
管理サーバーを起動するには、WLSTを使用してノード・マネージャに接続することをお薦めします。
cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
WLSTシェルで、次を実行します。
nmConnect('Admin_User','Admin_Password','ADMINVHN','5556', 'IDMDomain','ASERVER_HOME')
nmStart('AdminServer')
かわりに、次のコマンドを使用して管理サーバーを起動することもできます。
ASERVER_HOME/bin/startWebLogic.sh
管理サーバーを停止するには、第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、WebLogicコンソールにログインします。
続けて、次の手順を実行します。
「ドメイン構造」メニューで、「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
「AdminServer(admin)」を選択します。
「停止」をクリックし、「ただちに強制停止」を選択します。
管理サーバーを停止するかどうか確認を求められたら、「はい」をクリックします。
ノード・マネージャを起動および停止する手順は、次のとおりです。
起動されるノード・マネージャが管理サーバー(IDMHOST1またはIDMHOST2)を制御する場合は、ノード・マネージャを起動する前に、次のコマンドを発行します。
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
ノード・マネージャの共有記憶域を使用している場合は、第13.3.5項「共通または共有記憶域の使用」の説明に従って、JAVA_OPTIONSを設定します。
ノード・マネージャを起動するには、次のコマンドを発行します。
cd /u02/private/oracle/config/nodemanager ./startNodeManager.sh
Oracle Traffic Directorインスタンスを起動および停止するには、第7.6項「Oracle Traffic Directorインスタンスの起動」を参照してください。
Oracle Identity ManagerおよびOracle SOA Suiteサーバーを起動および停止する手順は、次のとおりです。
Oracle Identity Manager管理対象サーバーを起動するには、第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、WebLogicコンソールにログインします。
続けて、次の手順を実行します。
「ドメイン構造」メニューで、「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
SOAサーバー(WLS_SOA1またはWLS_SOA2、あるいはその両方)を選択します。
|
注意: Oracle Identity ManagerサーバーとOracle SOA Suiteサーバーは、互いに関係なく起動できます。その起動順序に依存関係はありません。ただし、Oracle Identity Managerの機能をすべて使用できるためには、SOAサーバーが起動され、実行されている必要があります。 |
「起動」ボタンをクリックします。
サーバーを起動するかどうか確認を求められたら、「はい」をクリックします。
WLS_SOA1またはWLS_SOA2、あるいはその両方が起動された後、WLS_OIM1またはWLS_OIM2、あるいはその両方を選択します。
「起動」をクリックします。
サーバーを起動するかどうか確認を求められたら、「はい」をクリックします。
Oracle Identity Manager管理対象サーバーを停止するには、第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、WebLogicコンソールにログインします。続けて、次の手順を実行します。
「ドメイン構造」メニューで、「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
OIMサーバー(WLS_OIM1またはWLS_OIM2、あるいはその両方)および(WLS_SOA1またはWLS_SOA2、あるいはその両方)を選択します。
「停止」ボタンをクリックし、「ただちに強制停止」を選択します。
サーバーを停止するかどうか確認を求められたら、「はい」をクリックします。
表16-1は、このガイドで使用する管理コンソールおよびそのURLを示しています。
この項では、このドキュメントで説明しているアイデンティティ管理エンタープライズ・デプロイメントのモニタリングについて説明します。
この項の内容は次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlを使用すると、管理対象サーバーに加えて、Access Manager、Oracle Identity Manager、SOAなど、他のFusion Middlewareコンポーネントをモニターできます。詳細は、「はじめに」の「関連ドキュメント」の下に示されている各管理者ガイドを参照してください。
このドキュメントで説明している参照エンタープライズ・トポロジは、きわめてスケーラブルです。スケール・アップもスケール・アウトも可能です。トポロジがスケール・アップされる場合、すでに1つ以上のサーバー・インスタンスを実行しているノードに、新しいサーバー・インスタンスが追加されます。トポロジがスケール・アウトされる場合、新しいノードに新しいサーバーが追加されます。
この項の内容は次のとおりです。
このガイドで説明しているOracle Identity Managementトポロジには、アプリケーション層およびWeb層という2つの層があります。アプリケーション層内のコンポーネントは、すでに1つ以上のサーバー・インスタンスを実行しているノードに新しいサーバー・インスタンスを追加することで、スケール・アップできます。
Web層の場合は、同じ計算ノードに同じ構成名で2つのOracle Traffic Directorインスタンスを持つことができないため、スケール・アップできません。
ディレクトリ層には2つのOracle Unified Directoryノード(IDMHOST1およびIDMHOST2)があり、それぞれがOracle Unified Directoryインスタンスを実行しています。各ノードのOracle Unified Directoryバイナリを使用して、新しいOracle Unified Directoryインスタンスを作成できます。
新しいOracle Unified DirectoryインスタンスをいずれかのOracle Unified Directoryホストに追加するには、第8.4.3項「IDMHOST2での追加Oracle Unified Directoryインスタンスの構成」の手順に加えて、次の指示に従います。
手順2および手順4では、1389、1636または4444以外のポートを選択します。これらのポートは、ノード上の既存のOracle Unified Directoryインスタンスで使用されているためです。
新しいOracle Unified Directoryインスタンスの場所を、ORACLE_INSTANCEの値として使用します。
新しいOracle Unified Directoryインスタンスのホストとポートの情報で、ロード・バランサを再構成します。
アプリケーション層は、インストールされている製品に応じて、対になっている複数のノードで構成されます。これらのアプリケーション・サーバーでは、WebLogic管理対象サーバーを実行します。
新しい管理対象サーバーを追加する場合は、管理対象サーバーを追加した後で、Oracle Traffic Directorの構成を更新する必要があります。
新しい管理対象サーバーのOracle Traffic Directorを更新する手順は、次のとおりです。
Oracle Traffic Director管理コンソールにログインします。
左側のパネルの「サーバー・プール」をクリックします。
「oam-pool」をクリックします。
左側のパネルで、「新規オリジン・サーバー」をクリックします。
IDMHOST3, 14100というオリジン・サーバーを追加し、「次へ」をクリックします。
「新規オリジン・サーバー」をクリックし、「閉じる」をクリックします。
パネル上部の「変更のデプロイ」をクリックします。
Oracle Access Managerをスケール・アップする手順は、次のとおりです。
第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「チェンジ・センター」メニューで、「ロックして編集」をクリックします。
拡張するホスト上の既存のサーバーを選択します(例: WLS_OAM1)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前(例: WLS_OAM3)。
サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートは、ホスト内で一意にする必要があります。
「OK」をクリックします。
新しく作成したサーバー「WLS_OAM3」をクリックします。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーと、IDMHOSTnのノード・マネージャとの間で行われる通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名検証がすでに無効にされている場合、ホスト名検証の設定はクローン・サーバーに伝播されるため、これらの手順は不要です。ホスト名検証を無効にする手順は、次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
「チェンジ・センター」メニューで、構成のアクティブ化をクリックします。
新しい管理対象サーバーをOracle Access Managerに登録します。ここで、新しい管理対象サーバーをOracle Access Managerサーバーとして構成する必要があります。これは、Oracle OAMコンソールで行います。次の手順を実行します。
OAMコンソールにoamadminユーザーとしてログインします。第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用します。
「システム構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「アクション」メニューで、「作成」を選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行するホスト
ポート: 管理対象サーバーの作成時に割り当てられたリスニング・ポート
OAMプロキシ・ポート: Oracle Access Managerプロキシが実行されるポート。これはホストで一意です。
プロキシ・サーバーID: AccessServerConfigProxy
モード: 既存のOracle Access Managerサーバーが動作しているモードに応じて、「オープン」または「簡易」に設定します。
「コヒーレンス」タブをクリックします。
「ローカル・ポート」をホストで一意の値に設定します。
「適用」をクリックします。
第16.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。
新しく作成したOracle Access Managerサーバーを、Webgate_IDMやIAMSuiteAgentなど、このサーバーを使用する可能性があるすべてのWebゲート・プロファイルに追加します。
たとえば、Oracle Access ManagerサーバーをWebgate_IDMに追加するには、第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、OAMコンソールにアクセスします。続けて、次の手順を実行します。
第10.4項「アイデンティティ・ストアの準備」で作成したOracle Access Manager管理ユーザーとしてログインします。
「システム構成」タブをクリックします。
「Access Managerの設定」→「SSOエージェント」→「OAMエージェント」を開きます。
フォルダを開くアイコンをクリックし、「検索」をクリックします。
Webゲート・エージェントWebgate_IDMが表示されます。
エージェント「Webgate_IDM」をクリックします。
「アクション」メニューで、「編集」を選択します。
「プライマリ・サーバー」リスト(または、これがセカンダリ・サーバーの場合は「セカンダリ・サーバー」リスト)で、「+」をクリックします。
「サーバー」ドロップダウン・リストで、新しく作成した管理対象サーバーを選択します。
「最大接続数」を4に設定します。
「適用」をクリックします。
IAMSuiteAgentおよび使用している可能性がある他のすべてのWebゲートで、手順5から10を繰り返します。
この項の手順では、新しい管理対象サーバーまたはディレクトリ・インスタンスを作成する方法を示します。3番目のインスタンスをOracle Traffic Director OAMサーバー・プールに追加します。
3番目のインスタンスをOracle Traffic Director OAMサーバー・プールに追加する手順は次のとおりです。
Oracle Traffic Director管理コンソールにログインします。
左側のパネルの「サーバー・プール」をクリックします。
「oam-pool」をクリックします。
左側のパネルで、「新規オリジン・サーバー」をクリックします。
IDMHOST3, 14100というオリジン・サーバーを追加し、「次へ」をクリックします。
「新規オリジン・サーバー」をクリックし、「閉じる」をクリックします。
パネル上部の「変更のデプロイ」をクリックします。
第16.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、新しい管理対象サーバーを起動できます。
ここでは、管理対象サーバーを実行するノードが、Oracle SOA SuiteおよびOracle Identity Managerのコンポーネントを使用して、すでに構成されています。ノードには、ミドルウェア・ホーム、SOA Oracleホーム、Oracle Identity Manager Oracleホーム、および既存の管理対象サーバーのドメイン・ディレクトリが含まれています。
既存のインストール(ミドルウェア・ホームおよびドメイン・ディレクトリ)を使用して、新しいWLS_OIMサーバーとWLS_SOAサーバーを作成できます。Oracle Identity and Access ManagementまたはOracle SOA Suiteのバイナリを、新しい場所にインストールしたり、圧縮と解凍を実行したりする必要はありません。
トポロジをスケール・アップする手順は、次のとおりです。
第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、管理コンソールにログインします。WLS_OIM1またはWLS_SOA1を、新しい管理対象サーバーにクローニングします。クローン元の管理対象サーバーは、新しい管理対象サーバーが実行されるノード上に、すでに存在している必要があります。
管理対象サーバーをクローニングする手順は次のとおりです。
管理コンソールで、「環境」→「サーバー」を選択します。
「チェンジ・センター」メニューで、「ロックして編集」をクリックします。
クローニングする管理対象サーバーを選択します(例: WLS_OIM1またはWLS_SOA1)。
「クローンの作成」を選択します。
新しい管理対象サーバーに、WLS_OIMnまたはWLS_SOAnという名前を付けます。nは、新しい管理対象サーバーを識別する番号です。
この後の手順では、WLS_SOA1およびWLS_OIM1をすでに実行しているIDMHOST1に、新しいサーバーを追加することを想定しています。
リスニング・アドレスとして、この新しい管理対象サーバーで使用する、ホスト名またはIPアドレスを割り当てます。このサーバーで推奨されているサーバー移行を使用する予定の場合は、別のノードに移動できるように、VIP (フローティングIPとも呼ばれます)を指定する必要があります。VIPは、すでに実行されている管理対象サーバーで使用されているものとは、異なるものであることが必要です。
新しい管理対象サーバーに、SOA、Oracle Identity Manager、UMSおよびBPMの、JMSサーバーを作成します。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し、SOAJMSFileStore_Nなどの名前を付けます。ストアのパスを指定します。第4.3項「エンタープライズ・デプロイメント用の共有記憶域に関する推奨事項」で推奨されているように、これは共有記憶域のディレクトリである必要があります。
|
注意: 管理対象サーバーを起動する前に、このディレクトリが存在している必要があります。存在していない場合、起動の処理が失敗します。 |
ASERVER_HOME/jms/SOAJMSFileStore_N
SOAの新しいJMSサーバーを作成します(例: SOAJMSServer_auto_N)。このJMSサーバーでは、SOAJMSFileStore_Nを使用します。SOAJMSServer_auto_Nサーバーのターゲットを、最近作成した管理対象サーバー(WLS_SOAn)に設定します。
BPMの新しいJMSサーバーを作成します(例: BPMJMSServer_auto_N)。このJMSサーバーでは、BPMJMSServer_auto_Nを使用します。BPMJMSServer_auto_Nサーバーのターゲットを、最近作成した管理対象サーバー(WLS_SOAn)に設定します。
新しいBPMJMSServerの新しい永続ストアを作成します(例: BPMJMSFileStore_N)。ストアのパスを指定します。第4.3項「エンタープライズ・デプロイメント用の共有記憶域に関する推奨事項」で推奨されているように、これは共有記憶域のディレクトリである必要があります。
新しいUMSJMSServerの新しい永続ストアを作成します(例: UMSJMSFileStore_N)。このストアのパスを指定します。第4.3項「エンタープライズ・デプロイメント用の共有記憶域に関する推奨事項」で推奨されているように、これは共有記憶域のディレクトリである必要があります。
ASERVER_HOME/jms/UMSJMSFileStore_N.
|
注意: 管理対象サーバーを起動する前に、このディレクトリが存在している必要があります。存在していない場合、起動の処理が失敗します。 |
UMSの新しいJMSサーバーを作成します(例: UMSJMSServer_N)。このJMSサーバーでは、UMSJMSFileStore_Nを使用します。UMSJMSServer_Nサーバーのターゲットを、最近作成した管理対象サーバー(WLS_SOAn)に設定します。
新しいOIMJMSServerの新しい永続ストアを作成します(例: OIMJMSFileStore_N)。このストアのパスを指定します。第4.3項「エンタープライズ・デプロイメント用の共有記憶域に関する推奨事項」で推奨されているように、これは共有記憶域のディレクトリである必要があります。
ASERVER_HOME/jms/OIMJMSFileStore_N
|
注意: 管理対象サーバーを起動する前に、このディレクトリが存在している必要があります。存在していない場合、起動の処理が失敗します。 |
Oracle Identity Managerの新しいJMSサーバーを作成します(例: OIMJMSServer_N)。このJMSサーバーでは、OIMJMSFileStore_Nを使用します。OIMJMSServer_Nサーバーのターゲットを、最近作成した管理対象サーバー(WLS_OIMn)に設定します。
SOA JMSモジュールのサブデプロイメント・ターゲットを更新して、最近作成したSOA JMSサーバーを含めます。これを行うには、「サービス」ノードを開き、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、 |
SOAJMSServerXXXXXXというサブデプロイメントをクリックします。SOAJMSServer_NというSOAの新しいJMSサーバーを、このサブデプロイメントに追加します。「保存」をクリックします。
UMSJMSSystemResourceのサブデプロイメント・ターゲットを更新して、最近作成したUMS JMSサーバーを含めます。これを行うには、「サービス」ノードを開き、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列でハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、 |
UMSJMSServerXXXXXXというサブデプロイメントをクリックします。UMSJMSServer_NというUMSの新しいJMSサーバーを、このサブデプロイメントに追加します。「保存」をクリックします。
BPMJMSSystemResourceのサブデプロイメント・ターゲットを更新して、最近作成したBPM JMSサーバーを含めます。これを行うには、「サービス」ノードを開き、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「BPMJMSSystemResource」(表の「名前」列でハイパーリンクとして表示)をクリックします。BPMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。BPMJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、 |
BPMJMSServerXXXXXXというサブデプロイメントをクリックします。BPMJMSServer_NというBPMの新しいJMSサーバーを、このサブデプロイメントに追加します。「保存」をクリックします。
OIMJMSModuleのサブデプロイメント・ターゲットを更新して、最近作成したOracle Identity Manager JMSサーバーを含めます。これを行うには、「サービス」ノードを開き、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSModule」(表の「名前」列でハイパーリンクとして表示)をクリックします。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、 |
OIMJMSServerXXXXXXというサブデプロイメントをクリックします。OIMJMSServer_NというOracle Identity Managerの新しいJMSサーバーを、このサブデプロイメントに追加します。「保存」をクリックします。
第12.9項「コンポジットのデプロイのためのOracle Coherenceの構成」の説明に従って、Oracle Coherenceを構成します。
新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に示されているように、これは他のノードから参照できる場所にする必要があります。
管理コンソールで、サーバー名を選択し、「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルト永続ストアによってそのデータ・ファイルが格納されるフォルダへのパスを入力します。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOAn管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーと、IDMHOSTnのノード・マネージャとの間で行われる通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名検証がすでに無効にされている場合、これらの手順は不要です(ホスト名検証の設定はクローン・サーバーに伝播されます)。
ホスト名検証を無効にする手順は、次のとおりです。
Oracle Enterprise Manager Consoleで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、WLS_SOAnを選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
WLS_OIMnの各管理対象サーバーで、手順6aから6hを繰り返して、ホスト名検証を無効にします。手順dでは、表の「名前」列で、WLS_OIMnを選択します。
「チェンジ・センター」メニューで、「変更のアクティブ化」をクリックします。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAのホストとポートを更新します。次の手順を実行します。
ブラウザを開き、第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、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」に移動します。
Rmiurl属性の値を、新しいSOAサーバーのホストとポートで更新します。「適用」をクリックして、変更を保存します。
Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBへのアクセスで使用されます。これはアプリケーション・サーバーのURLです。この属性の値の例を、次に示します。
cluster:t3://soa_cluster
第16.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。
管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーを停止します。
新しく作成した管理対象サーバーWLS_SOAnが稼働していることを確認します。
新しく作成した管理対象サーバー上のアプリケーションにアクセスします(http://vip:port/soa-infra)。アプリケーションが機能する必要があります。
新しく作成した管理対象サーバーのサーバー移行を構成します。第14.6項「サーバー移行ターゲットの構成」の手順に従って、サーバー移行を構成します。
この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードから次の手順を実行します。
WLS_SOAn管理対象サーバーを停止します。
これを行うには、次を実行します。
kill -9 pid
pidには、管理対象サーバーのプロセスID (PID)を指定します。ノードのPIDは、次のコマンドで識別できます。
ps -ef | grep WLS_SOAn
ノード・マネージャ・コンソールを確認します。WLS_SOA1のフローティングIPアドレスが無効化されたことを示すメッセージが表示されます。
ノード・マネージャによって、WLS_SOAnの2回目の再起動が試行されるまで待ちます。ノード・マネージャは、この再起動を試行するまで、30秒間待機します。
ノード・マネージャがサーバーを再起動したら再度停止します。これにより、サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録します。
Oracle Traffic Directorをスケール・アップするには、次の手順を実行します。
第7.2項「WEBHOST1およびWEBHOST2でのOracle Traffic Directorのインストール」の説明に従って、Oracle Traffic Directorを新しいホスト上にインストールします。
第7.4項「管理ノードへのWEBHOST2の登録」の説明に従って、Oracle Traffic Directorの新しいインスタンスを新しいホスト上に作成します。
第7.10項「構成のデプロイと仮想サーバー・アドレスのテスト」の手順に従って、構成を新しいノードにデプロイします。
第7.11項「仮想ホストのフェイルオーバー・グループの作成」の説明に従って、新しいOracle Traffic Directorインスタンスの新しいフェイルオーバー・グループを作成します。
新しいOracle Traffic Directorフェイルオーバー・グループをハードウェア・ロード・バランサ・プールに追加します。
トポロジのスケール・アウトでは、新しいノードに新しいサーバーを追加します。このドキュメントに記載されているOracle Identity Managementトポロジの3つのすべての層のコンポーネントは、新しいノードに新しいサーバー・インスタンスを追加することによってスケール・アウトできます。
この項の内容は次のとおりです。
この項の手順では、新しい管理対象サーバーまたはディレクトリ・インスタンスを作成する方法を示します。3番目のインスタンスをOracle Traffic Director OAMサーバー・プールに追加します。
3番目のインスタンスをOracle Traffic Director OAMサーバー・プールに追加する手順は次のとおりです。
Oracle Traffic Director管理コンソールにログインします。
左側のパネルの「サーバー・プール」をクリックします。
「oam-pool」をクリックします。
左側のパネルで、「新規オリジン・サーバー」をクリックします。
IDMHOST3, 14100というオリジン・サーバーを追加し、「次へ」をクリックします。
「新規オリジン・サーバー」をクリックし、「閉じる」をクリックします。
パネル上部の「変更のデプロイ」をクリックします。
アプリケーション層には2つのノード(IDMHOST1およびIDMHOST2)があり、Oracle Access ManagerおよびOracle Identity Managerの管理対象サーバーがそれぞれ実行されています。
この項のいくつかの手順では、3番目のノードに新しいWebLogic管理対象サーバーを作成する方法を示しています。新しい管理対象サーバーをトポロジに追加する場合は、管理対象サーバーを追加した後で、Oracle Traffic Directorの構成ファイルを更新し(すべてのノードで)、新しいサーバーを既存のWebLogicクラスタ・ディレクティブに追加する必要があります。
この項の手順は、3番目のノードに新しい管理対象サーバーを作成する方法を示しています。
スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要があります。
新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic Serverまたはアイデンティティ管理のバイナリをインストールする必要はありませんが、圧縮と解凍を実行して、新しいノードでドメイン構成をブートストラップする必要があります。
|
注意: 共有記憶域を使用している場合は、その共有記憶域に新しいホストがアクセスできるようにします。 |
新しいノードで、SOAインストールとドメイン・ディレクトリが含まれている既存のミドルウェア・ホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
ミドルウェア・ホーム・リストを更新するには、IAM_MW_HOME/bea/beahomelistファイルを作成し(ノードに別のWebLogicインストールが存在する場合は編集します)、これにIAM_MW_HOME/product/fmwを追加します。
第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「チェンジ・センター」メニューで、「ロックして編集」をクリックします。
拡張するホスト上の既存のサーバーを選択します(例: WLS_OAM1)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前(例: WLS_OAM3)。
サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートは、ホスト内で一意にする必要があります。
「OK」をクリックします。
新しく作成したサーバー「WLS_OAM3」をクリックします。
SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホストで一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーと、IDMHOSTnのノード・マネージャとの間で行われる通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名検証がすでに無効にされている場合、ホスト名検証の設定はクローン・サーバーに伝播されるため、これらの手順は不要です。ホスト名検証を無効にするには、次の手順を実行します。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ペインで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
「チェンジ・センター」メニューで、構成のアクティブ化をクリックします。
第16.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。
次のコマンドを使用して、IDMHOST1上のドメインを圧縮します。
pack.sh -domain=ORACLE_BASE/config/domains/IDMDomain -template =/tmp/IDMDomain.jar -template_name="OAM Domain" -managed=true
pack.shスクリプトは、ORACLE_COMMON_HOME/common/binにあります。
次のコマンドを使用して、新しいホスト上でドメインを解凍します。
unpack.sh -domain=MSERVER_HOME/IDMDomain -template=/tmp/IDMDomain.jar -app_dir=MSERVER_HOME/applications
unpack.shスクリプトは、ORACLE_COMMON_HOME/common/binにあります。
ノード・マネージャを起動し、プロパティ・ファイルを更新します。
第16.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、ノード・マネージャを起動および停止します。
ORACLE_COMMON_HOME/common/binにあるスクリプトsetNMProps.shを実行して、ノード・マネージャのプロパティ・ファイルを更新します。次に例を示します。
cd ORACLE_COMMON_HOME/common/bin ./setNMProps.sh
第16.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、ノード・マネージャを再度起動します。
新しい管理対象サーバーをOracle Access Managerに登録します。ここで、新しい管理対象サーバーをOracle Access Managerサーバーとして構成する必要があります。これは、Oracle OAMコンソールで次の手順を実行して行います。
OAMコンソールにoamadminユーザーとしてログインします。第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用します。
「システム構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「アクション」メニューで、「作成」を選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーが実行されているホストIDMHOST3。
ポート: 管理対象サーバーの作成時に割り当てられたリスニング・ポート。
OAMプロキシ・ポート: Oracle Access Managerプロキシが実行されるポート。これはホストで一意です。
プロキシ・サーバーID: AccessServerConfigProxy。
モード: 既存のOracle Access Managerサーバーが動作しているモードに応じて、「オープン」または「簡易」に設定します。
「適用」をクリックします。
新しく作成したOracle Access Managerサーバーを、Webgate_IDMやIAMSuiteAgentなど、このサーバーを使用する可能性があるすべてのWebゲート・プロファイルに追加します。
たとえば、Oracle Access ManagerサーバーをWebgate_IDMに追加するには、第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、OAMコンソールにアクセスします。続けて、次の手順を実行します。
第10.4.3項「Oracle Access ManagerおよびOracle Identity Managerで使用するためのOracle Unified Directoryの構成」で作成したOracle Access Manager管理ユーザーとしてログインします。
「システム構成」タブをクリックします。
「Access Managerの設定」→「SSOエージェント」→「OAMエージェント」を開きます。
フォルダを開くアイコンをクリックし、「検索」をクリックします。
Webゲート・エージェントWebgate_IDMが表示されます。
エージェント「Webgate_IDM」をクリックします。
「アクション」メニューで、「編集」を選択します。
「プライマリ・サーバー」リスト(または、これがセカンダリ・サーバーの場合は「セカンダリ・サーバー」リスト)で、「+」をクリックします。
「サーバー」ドロップダウン・リストで、新しく作成した管理対象サーバーを選択します。
「最大接続数」を4に設定します。
「適用」をクリックします。
IAMSuiteAgentおよび使用している他のWebゲートで、手順5から10を繰り返します。
Web層を更新します。新しい管理対象サーバーが作成され、起動されたので、Web層ではそのサーバーへのリクエストの送信を開始します。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。
この項の手順では、新しい管理対象サーバーまたはディレクトリ・インスタンスを作成する方法を示します。Web層を構成し、3番目のインスタンスをOracle Traffic Director OAMサーバー・プールに追加する手順は次のとおりです。
3番目のインスタンスをOracle Traffic Director OAMサーバー・プールに追加する手順は次のとおりです。
Oracle Traffic Director管理コンソールにログインします。
左側のパネルの「サーバー・プール」をクリックします。
「oam-pool」をクリックします。
左側のパネルで、「新規オリジン・サーバー」をクリックします。
IDMHOST3, 14100というオリジン・サーバーを追加し、「次へ」をクリックします。
「新規オリジン・サーバー」をクリックし、「閉じる」をクリックします。
パネル上部の「変更のデプロイ」をクリックします。
トポロジをスケール・アウトする場合は、OIMとSOAで構成された新しい管理対象サーバーを新しいノードに追加します。
この項の手順を実行する前に、次の要件を満たしていることを確認します。
OIMとSOAで構成された管理対象サーバーを実行しているノードが、トポロジ内に存在すること。
新しいノードが、WebLogic Server、OIMおよびSOAの既存のホーム・ディレクトリにアクセスできること。
新しい管理対象サーバーWLS_SOAまたはWLS_OIMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic Server、OIMまたはSOAのバイナリをインストールする必要はありませんが、圧縮と解凍を実行して、新しいノードでドメイン構成をブートストラップする必要があります。
|
注意:
|
トポロジをスケール・アウトする手順は、次のとおりです。
新しいノードで、Oracle Fusion Middlewareインストールとドメイン・ディレクトリが含まれている既存のミドルウェア・ホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_BASEをローカルOracleインベントリにアタッチするには、次のコマンドを実行します。
cd IAM_MW_HOME/product/fmw/iam/oui/bin /attachHome.sh -jreLoc JAVA_HOME
ミドルウェア・ホーム・リストを更新するには、IAM_MW_HOME/bea/beahomelistファイルを作成し(ノードに別のWebLogicインストールが存在する場合は編集します)、これにIAM_MW_HOME/product/fmwを追加します。
第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic管理コンソールにログインします。
使用する新しいノード用の新しいマシンを作成し、そのマシンをドメインに追加します。
マシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマッピングします。
Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーWLS_OIMおよびWLS_SOA1を、新しい管理対象サーバーにクローニングします。それらに、それぞれWLS_SOAnおよびWLS_OIMnという名前を付けます。nは数字です。
|
注意: これらの手順では、管理対象サーバーが実行されていないノード |
新しい管理対象サーバーのリスニング・アドレスに、ホスト名またはIPアドレスを割り当てます。
このサーバーでサーバー移行を使用する予定の場合(これをお薦めします)、これは、サーバーのVIPアドレス(フローティングIPアドレスとも呼ばれます)を指定する必要があります。このVIPアドレスは、既存の管理対象サーバーで使用されているものとは、異なるものであることが必要です。
新しい管理対象サーバーに、SOA、Oracle Identity Manager (該当する場合)およびUMSの、JMSサーバーを作成します。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し、SOAJMSFileStore_Nなどの名前を付けます。ストアのパスを指定します。第4.3項「エンタープライズ・デプロイメント用の共有記憶域に関する推奨事項」で推奨されているように、これは共有記憶域のディレクトリである必要があります。次に例を示します。
ASERVER_HOME/jms/SOAJMSFileStore_N
|
注意: 管理対象サーバーを起動する前に、このディレクトリが存在している必要があります。存在していない場合、起動の処理が失敗します。 |
SOAの新しいJMSサーバーを作成します(例: SOAJMSServer_auto_N)。このJMSサーバーでは、SOAJMSFileStore_Nを使用します。SOAJMSServer_auto_Nサーバーのターゲットを、最近作成した管理対象サーバー(WLS_SOAn)に設定します。
新しいUMSJMSServerの新しい永続ストアを作成し、名前を指定します(例: UMSJMSFileStore_N)。ストアのパスを指定します。第4.3項「エンタープライズ・デプロイメント用の共有記憶域に関する推奨事項」で推奨されているように、これは共有記憶域のディレクトリである必要があります。
ASERVER_HOME/jms/UMSJMSFileStore_N
|
注意:
|
UMSの新しいJMSサーバーを作成します(例: UMSJMSServer_N)。このJMSサーバーでは、UMSJMSFileStore_Nを使用します。UMSJMSServer_Nサーバーのターゲットを、最近作成した管理対象サーバー(WLS_SOAn)に設定します。
新しいBPMJMSServerの新しい永続ストアを作成し、名前を指定します(例: BPMJMSFileStore_N)。ストアのパスを指定します。第4.3項「エンタープライズ・デプロイメント用の共有記憶域に関する推奨事項」で推奨されているように、これは共有記憶域のディレクトリである必要があります。
ASERVER_HOME/jms/BPMJMSFileStore_N
|
注意:
|
BPMの新しいJMSサーバーを作成します(例: BPMJMSServer_N)。このJMSサーバーでは、BPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーのターゲットを、最近作成した管理対象サーバー(WLS_SOAn)に設定します。
新しいOIMJMSServerの新しい永続ストアを作成し、名前を指定します(例: OIMJMSFileStore_N)。ストアのパスを指定します。第4.3項「エンタープライズ・デプロイメント用の共有記憶域に関する推奨事項」で推奨されているように、これは共有記憶域のディレクトリである必要があります。
ASERVER_HOME/jms/OIMJMSFileStore_N
|
注意:
|
Oracle Identity Managerの新しいJMSサーバーを作成します(例: OIMJMSServer_N)。このJMSサーバーでは、OIMJMSFileStore_Nを使用します。OIMJMSServer_Nサーバーのターゲットを、最近作成した管理対象サーバー(WLS_OIMn)に設定します。
BPMJMSSystemResourceのサブデプロイメント・ターゲットを更新して、最近作成したBPM JMSサーバーを含めます。これを行うには、「サービス」ノードを開き、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「BPMJMSSystemResource」(表の「名前」列でハイパーリンクとして表示)をクリックします。BPMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。BPMJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、 |
BPMJMSServerXXXXXXというサブデプロイメントをクリックします。BPMJMSServer_NというBPMの新しいJMSサーバーを、このサブデプロイメントに追加します。「保存」をクリックします。
SOA JMSモジュールのサブデプロイメント・ターゲットを更新して、最近作成したSOA JMSサーバーを含めます。これを行うには、「サービス」ノードを開き、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。SOAJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、 |
SOAJMSServerXXXXXXというサブデプロイメントをクリックします。SOAJMSServer_NというSOAの新しいJMSサーバーを、このサブデプロイメントに追加します。「保存」をクリックします。
UMSJMSSystemResourceのサブデプロイメント・ターゲットを更新して、最近作成したUMS JMSサーバーを含めます。これを行うには、「サービス」ノードを開き、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列でハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。UMSJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、 |
UMSJMSServerXXXXXXというサブデプロイメントをクリックします。UMSJMSServer_NというUMSの新しいJMSサーバーを、このサブデプロイメントに追加します。「保存」をクリックします。
OIMJMSModuleのサブデプロイメント・ターゲットを更新して、最近作成したOracle Identity Manager JMSサーバーを含めます。これを行うには、「サービス」ノードを開き、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSModule」(表の「名前」列でハイパーリンクとして表示)をクリックします。OIMJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュールは、 |
OIMJMSXXXXXXというサブデプロイメントをクリックします。OIMJMSServer_NというOracle Identity Managerの新しいJMSサーバーを、このサブデプロイメントに追加します。「保存」をクリックします。
「チェンジ・センター」メニューで、構成のアクティブ化をクリックします。
packコマンドを実行して、テンプレート・パックを作成します。これは、1つのドメインを使用している場合はIDMHOST1で、またはIDMHOST1で、実行します。次の手順を実行します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ASERVER_HOME -template=/templates/oim_domain.jar -template_name="OIM Domain"
IDMHOST1でscpコマンドを実行して、作成されたテンプレート・ファイルをIDMHOSTnにコピーします。次に例を示します。
scp /templates/oim_domain.jar IDMHOSTN:/templates/oim_domain.jar
次のように、IDMHOSTnでunpackコマンドを実行して、テンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
cd ORACLE_COMMON_HOME/oracle_common/bin ./unpack.sh -domain=MSERVER_HOME -template=/templates/oim_domain.jar -app_dir=MSERVER_HOME/applications
第12.9項「コンポジットのデプロイのためのOracle Coherenceの構成」の説明に従って、Oracle Coherenceを構成します。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAのホストとポートを更新します。次の手順を実行します。
ブラウザを開き、第16.2項「アイデンティティ管理コンソールのURLについて」に記載されているURLを使用して、Oracle Enterprise Manager Fusion Middleware Controlにアクセスします。
adminユーザー資格証明を使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。
|
注意: これらの手順を実行する際は、1つ以上のOracle Identity Manager管理対象サーバーが実行されている必要があります。 |
「Identity and Access」→「oim」に移動します。
「oim」を右クリックし、「システムMBeanブラウザ」に移動します。
「アプリケーション定義のMBean」で、「oracle.iam」→「アプリケーション: oim」→「XMLConfig」→「構成」→「XMLConfig.SOAConfig」→「SOAConfig」に移動します。
Rmiurl属性の値を、新しいSOAサーバーのホストとポートで更新します。「適用」をクリックして、変更を保存します。
Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBへのアクセスで使用されます。これはアプリケーション・サーバーのURLです。この属性の値の例を、次に示します。
cluster:t3://soa_cluster
新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に示されているように、これは他のノードから参照できる場所にする必要があります。
管理コンソールで、サーバー名を選択し、「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」の下で、デフォルト永続ストアによってそのデータ・ファイルが格納されるフォルダへのパスを入力します。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOAnおよびWLS_OIMn管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーと、IDMHOSTnのノード・マネージャとの間で行われる通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名検証がすでに無効にされている場合、これらの手順は不要です(ホスト名検証の設定はクローン・サーバーに伝播されます)。
WLS_SOAnのホスト名検証を無効にする手順は次のとおりです。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
Oracle Enterprise Manager Consoleで、「Oracle WebLogic Server管理コンソール」を選択します。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、WLS_SOAnを選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
WLS_OIMnのホスト名検証を無効にするには、同じ手順を繰り返します。ただし、手順dの「名前」でWLS_OIMnを選択します。
「チェンジ・センター」メニューで、構成のアクティブ化をクリックします。
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、既存のノードから共有記憶域のインストールを使用し、次のようにパラメータとして新しいノードのホスト名を渡すことによってノード・マネージャを起動します。
WL_HOME/server/bin/startNodeManager new_node_ip
Oracle WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーをすべて停止します。
新しく作成した管理対象サーバーWLS_SOAnおよびWLS_SOAnが実行されていることを確認します。
新しく作成した管理対象サーバー上のアプリケーションにアクセスします(http://vip:port/soa-infraおよびhttp://vip:port/oim)。アプリケーションが機能する必要があります。
新しい管理対象サーバーのサーバー移行を構成します。
|
注意: この新しいノードでは既存の共有記憶域インストールが使用されているため、ノードではノード・マネージャおよびサーバー移行用に構成された環境(ネットマスク、インタフェースおよび |
次の手順に従って、サーバー移行を構成します。
管理コンソールにログインします。
左側のペインで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバー(ハイパーリンクとして表示)を、表の「名前」から選択します。そのサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を有効にするマシンを選択し、右矢印をクリックします。
|
注意: 新しいサーバーの移行ターゲットとして、負荷が最も少ないマシンを指定します。このノードで追加管理対象サーバーの維持に十分なリソースを確保できるように、必要なキャパシティ・プランニングを行っておく必要があります。 |
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、ターゲット・ノードの障害が発生したサーバーを自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
次の手順に従って、新しいサーバーWLS_SOAnおよびWLS_OIMnのサーバー移行をテストします。
1. 次のコマンドを入力して、WLS_SOAn管理対象サーバーのPIDを判断します。
ps -ef | grep WLS_SOAn
2. 新しいサーバーを追加したノードで次のコマンドを入力して、WLS_SOAn管理対象サーバーを強制的に終了します。
kill -9 pid
3. ノード・マネージャ・コンソールを確認します。WLS_SOA1のフローティングIPアドレスが無効化されたことを示すメッセージが表示されます。
4. ノード・マネージャによって、WLS_SOAnの2回目の再起動が試行されるまで待ちます。ノード・マネージャは、この再起動を試行するまで、30秒間待機します。
5. ノード・マネージャがサーバーを再起動したら再度停止します。これにより、サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録します。
6. WLS_OIMnについて、手順1-5を繰り返します。
Oracle Fusion Middleware監査フレームワークは、Oracle Fusion Middleware 11gの新しいサービスであり、ミドルウェア製品ファミリの集中監査フレームワークを提供します。このフレームワークは、Oracle Platform Security Services (OPSS)やOracle Web Servicesなどのプラットフォーム・コンポーネントに対して監査サービスを提供します。また、Oracle独自のJavaEEコンポーネントをはじめとする、JavaEEアプリケーションのフレームワークも提供します。JavaEEアプリケーションは、アプリケーション固有の監査イベントを作成できます。監査フレームワークは、CやJavaSEのコンポーネントなど、ミドルウェア内のJavaEEでないOracleコンポーネントに対しても、JavaEEアプリケーションと同様のエンドツーエンドの構造を提供します。
図16-1は、Oracle Fusion Middleware監査フレームワークのアーキテクチャの概要を示しています。
Oracle Fusion Middleware監査フレームワークは、次の主要コンポーネントで構成されています。
監査API
このAPIは、Oracle Fusion Middleware監査フレームワークと統合されている監査対応のコンポーネント用に、監査フレームワークによって提供されています。アプリケーションの実行時に、アプリケーション・コード内で発生する特定のイベントに関する必要な情報を監査するために、これらのAPIを必要に応じてコールできます。アプリケーションはこのインタフェースにより、監査対象のイベントのコンテキストの提供に必要な、ユーザー名やその他の属性など、イベントの詳細を指定できます。
監査イベントと構成
Oracle Fusion Middleware監査フレームワークでは、アプリケーションの監査イベントに簡単にマッピングできる一連の汎用イベントが提供されます。これには認証などの共通イベントも含まれています。このフレームワークでは、アプリケーションはアプリケーション固有のイベントを定義することもできます。
これらのイベントの定義と構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。構成は、Enterprise Manager (UI)およびWLST (コマンド行ツール)で更新できます。
監査バスストップ
バスストップは、監査リポジトリにプッシュされる前の監査データが含まれているローカル・ファイルです。データベース・リポジトリが構成されていない場合は、このバスストップ・ファイルをファイルベースの監査リポジトリとして使用できます。バスストップ・ファイルは単純なテキスト・ファイルであり、簡単な問合せで特定の監査イベントを見つけることができます。DBベースのリポジトリが配置済の場合、バスストップはコンポーネントと監査リポジトリ間の仲介役として機能します。ローカル・ファイルは、構成可能な時間間隔に基づいて、定期的に監査リポジトリにアップロードされます。
監査ローダー
監査ローダーは、その名前が示すように、監査バスストップから監査リポジトリにファイルをロードします。プラットフォームおよびJavaEEアプリケーション監査の場合、監査ローダーは、JavaEEコンテナの起動の一部として起動されます。システム・コンポーネントの場合、監査ローダーは、定期的に生成されるプロセスです。
監査リポジトリ
監査リポジトリには、リポジトリ作成ユーティリティ (RCU)によって作成された、定義済のOracle Fusion Middleware監査フレームワーク・スキーマが含まれます。一度構成されると、すべての監査ローダーはリポジトリを認識し、定期的にデータをアップロードします。監査リポジトリ内の監査データは累積され、時間とともに増大します。これは、他のアプリケーションによって使用される運用データベースではなく、監査専用のスタンドアロンRDBMSであることが理想です。高可用性構成の場合は、監査データ・ストアとして、Oracle Real Application Clusters (Oracle RAC)データベースを使用することをお薦めします。
Oracle Business Intelligence Publisher
監査リポジトリ内のデータは、Oracle Business Intelligence Publisher内の事前定義済レポートにより公開されます。このレポートでは、様々な基準に基づいて監査データをドリルダウンできます。次に例を示します。
ユーザー名
時間範囲
アプリケーション・タイプ
実行コンテキスト識別子(ECID)
Oracle Fusion Middleware監査フレームワークの詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』の「Oracle Fusion Middleware監査フレームワークの概要」を参照してください。
Oracle Fusion Middleware監査フレームワーク用にリポジトリを構成する方法の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』の「監査の構成と管理」を参照してください。
EDGトポロジには、Oracle Fusion Middleware監査フレームワーク構成が含まれていません。監査データをバスストップ・ファイルに生成する機能と、監査ローダーの構成は、製品がインストールされた後で使用できるようになります。主な留意点は、監査データを保管する監査データベース・リポジトリです。監査データのボリュームと履歴特性により、運用ストアや他のミドルウェア・コンポーネントによって使用されるストアとは別のデータベースを使用することを、強くお薦めします。
構成の変更の前後にはトポロジをバックアップします。
データベースをバックアップします。これは、Oracle Recovery Manager (推奨)またはOSツール(可能な場合はコールド・バックアップのためのtarなど)を使用した全データベースのバックアップです(ホットとコールドのいずれか)。
管理サーバー・ドメイン・ディレクトリをバックアップし、ドメイン構成を保存します。構成ファイルは次のディレクトリにあります。
ASERVER_HOME
管理サーバーをバックアップするには、IDMHOST1上で次のコマンドを実行します。
tar -cvpf edgdomainback.tar ASERVER_HOME
Web層をバックアップします。構成ファイルは次のディレクトリにあります。
WEB_ORACLE_ADMININSTANCE
Oracle Traffic Director管理サーバーをバックアップするには、WEBHOST1上で次のコマンドを実行します。
tar -cvpf webasback.tar WEB_ORACLE_ADMININSTANCE
この項では、Oracle Fusion Middlewareのパッチ・ファイルを適用する方法、および最小限の停止時間でOracle Identity Managementコンポーネントにパッチを適用する方法について説明します。
この項の内容は次のとおりです。
Oracle Fusion Middlewareソース・ファイルへのパッチ適用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
シングル・ドメインのトポロジでは、次のようにパッチを適用します。
IDMDomainのMW_HOME
共通のパッチ
Oracle Access Managerのパッチ
Oracle Identity Managerのパッチ
IDMツールのパッチ
最小限の停止時間でOracle Identity Managementコンポーネントにパッチを適用するには、次のガイドラインに従うことをお薦めします。
LDAPトラフィックをIDMHOST1からIDMHOST2へルーティングします。
パッチを適用するホスト(IDMHOST1)のOracle Unified Directoryサーバーを停止します。
ホストでOracle Unified Directoryのパッチを適用します。
ホストでOracle Unified Directoryサーバーを起動します。
パッチをテストします。
トラフィックを再びIDMHOST1にルーティングします。
アプリケーションが正常に動作していることを確認します。
IDMHOST2上のLDAPトラフィックをIDMHOST1にルーティングします。
パッチを適用するホスト(IDMHOST2)のOracle Unified Directoryサーバーを停止します。
ホストでパッチ(Oracle Unified Directoryパッチ)を適用します。
ホストでOracle Unified Directoryサーバーを起動します。
パッチをテストします。
パッチを適用した両方のホスト(IDMHOST1およびIDMHOST2)にトラフィックをルーティングします。
ほとんどの本番デプロイメントでは、ファイアウォールが使用されます。データベース接続はファイアウォールにまたがって行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters (Oracle RAC)の場合、データベース接続はOracle RAC VIPとデータベース・リスナー・ポートを使用して行われます。ファイアウォールがこれらの接続をタイムアウトさせないように構成する必要があります。このような構成ができない場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルで、SQLNET.EXPIRE_TIME=nというパラメータを設定します。nは分単位の時間です。この値を、ネットワーク・デバイス、つまりファイアウォールの既知のタイムアウト値より小さい値に設定します。Oracle RACの場合、このパラメータをすべてのOracleホーム・ディレクトリで設定します。
この項では、管理サーバーをIDMHOST2にフェイルオーバーする方法と、これをIDMHOST1にフェイルバックする方法について説明します。
作成した各ドメインに、同じ手順を適用できます。
この項の内容は次のとおりです。
ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーをIDMHOST1からIDMHOST2にフェイルオーバーする方法について説明します。
前提:
管理サーバーは、ADMINVHN.mycompany.comをリスニングし、任意のアドレスをリスニングしないように構成されています。第9.4項「構成ウィザードの実行によるドメインの作成」を参照してください。
管理サーバーは、IDMHOST1からIDMHOST2にフェイルオーバーされます。この2つのノードのIPアドレスは、次のとおりです。
IDMHOST1: 192.168.20.3
IDMHOST2: 192.168.20.4
ADMINVHN: 10.10.30.1
これは、管理サーバーが実行されている仮想IPアドレスで、IDMHOST1またはIDMHOST2で使用可能なinterface:index (bond1:1など)に割り当てられています。
IDMHOST1内で管理サーバーが実行されているドメイン・ディレクトリは共有記憶域にあり、IDMHOST2からもマウントされています。
|
注意: IDMHOST2内のNMは、この時点ではドメインを制御しません。IDMHOST2上で |
Oracle WebLogic ServerおよびOracle Fusion Middlewareコンポーネントは、前の章に記載されているように、IDMHOST2にインストールされています。つまり、IDMHOST1に存在する、IDM_ORACLE_HOMEとMW_HOMEのパスは、IDMHOST2でも使用できます。
次の手順は、管理サーバーを異なるノード(IDMHOST2)にフェイルオーバーする方法を示します。
第16.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、管理サーバーを停止します。
IPアドレスを2番目のノードに移行します。
IDMHOST1で次のコマンドをrootとして実行します(x:yは、ADMINVHN.mycompany.comによって使用される現在のインタフェースです)。
/sbin/ifconfig x:y down
次に例を示します。
/sbin/ifconfig bond1:1 down
IDMHOST2で次のコマンドを実行します。
/sbin/ifconfig interface:index ADMINVHN netmask netmask
次に例を示します。
/sbin/ifconfig bond1:1 10.10.30.1 netmask 255.255.255.0
|
注意: 使用するネットマスクとインタフェースが、IDMHOST2の使用可能なネットワーク構成と一致していることを確認します。 |
arpingを使用してルーティング表を更新します。次に例を示します。
/sbin/arping -b -A -c 3 -I bond0 10.10.30.1
次の手順を実行して、IDMHOST2上のノード・マネージャを起動します。
IDMHOST1で、管理サーバー・ドメイン・ディレクトリをアンマウントします。次に例を示します。
umount /u01/oracle/config
IDMHOST2で、管理サーバー・ドメイン・ディレクトリをマウントします。次に例を示します。
mount /u01/oracle/config
次のコマンドを使用してノード・マネージャを起動します。
cd /u02/private/oracle/config/nodemanager ./startNodeManager.sh
ノード・マネージャ・プロセスを強制終了して、ノード・マネージャを停止します。
|
注意: この時点でのノード・マネージャの起動と停止は、ノード・マネージャを初めて実行する場合のみ必要です。起動と停止によって、事前定義済のテンプレートからプロパティ・ファイルが作成されます。次の手順では、そのプロパティ・ファイルにプロパティを追加します。 |
setNMProps.shスクリプトを実行して、ノード・マネージャを起動する前に、StartScriptEnabledプロパティをtrueに設定します。
cd MW_HOME/oracle_common/common/bin
./setNMProps.sh
|
注意:
|
第16.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、ノード・マネージャを起動します。
IDMHOST2で管理サーバーを起動します。
cd ORACLE_COMMON_HOME/common/bin ./wlst.sh
WLSTシェルで、次のコマンドを実行します。
nmConnect('Admin_User','Admin_Password', 'IDMHOST2','5556', 'IDMDomain','ASERVER_HOME')
nmStart('AdminServer')
次のように、IDMHOST2上の管理サーバーにアクセスできるかテストします。
次のアドレスを使用して、Oracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://ADMINVHN.mycompany.com:7001/console.
http://ADMINVHN.mycompany.com:7001/emにあるOracle Enterprise Manager内のコンポーネントのステータスにアクセスし、確認できるかどうかチェックします。
次のアドレスを使用して、Oracle WebLogic Server管理コンソールにアクセスできるかテストします。
http://ADMINVHN.mycompany.com:7001/console
次のアドレスを使用して、Oracle Enterprise Manager内のコンポーネントのステータスにアクセスし、確認できるかどうかチェックします。
http://ADMINVHN.mycompany.com:7001/em
この手順では、管理サーバーをフェイルバックできる、つまり、IDMHOST2上で停止し、IDMHOST1上で実行できることを確認します。これを行うには、次の手順に従って、ADMINVHNを元のIDMHOST1ノードに移行します。
管理サーバーが実行されていないことを確認します。実行中の場合は、WebLogicコンソールから停止するか、コマンドstopWeblogic.shをASERVER_HOME/binから実行して停止します。
IDMHOST2で、管理サーバー・ドメイン・ディレクトリをアンマウントします。次に例を示します。
umount /u01/oracle/config
IDMHOST1で、管理サーバー・ドメイン・ディレクトリをマウントします。次に例を示します。
mount /u01/oracle/config/IDMDomain/aserver/
IDMHOST2上のADMINVHN.mycompany.comの仮想IPアドレスを無効にして、IDMHOST2上で次のコマンドをrootとして実行します。
/sbin/ifconfig x:y down
x:yは、ADMINVHN.mycompany.comによって使用される現在のインタフェースです。
IDMHOST1で次のコマンドを実行します。
/sbin/ifconfig interface:index 10.10.30.1 netmask 255.255.255.0
|
注意: 使用するネットマスクとインタフェースが、IDMHOST1の使用可能なネットワーク構成と一致していることを確認します。 |
arpingを使用してルーティング表を更新します。次のコマンドをIDMHOST1から実行します。
/sbin/arping -b -A -c 3 -I interface 10.10.30.1
ノード・マネージャがIDMHOST1でまだ起動されていない場合は、第16.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って起動します。
IDMHOST1で管理サーバーを再起動します。
cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
WLSTシェルで、次のコマンドを実行します。
nmConnect(Admin_User,'Admin_Pasword, IDMHOST1,'5556',
'IDMDomain','/u01/oracle/config/domains/IDMDomain'
nmStart('AdminServer')
次のアドレスを使用して、Oracle WebLogic Server管理コンソールにアクセスできるかテストします。
http://ADMINVHN.mycompany.com:7001/console
次のアドレスを使用して、Oracle Enterprise Manager内のコンポーネントのステータスにアクセスし、確認できるかどうかチェックします。
http://ADMINVHN.mycompany.com:7001/em
この項では、このドキュメントで説明しているアイデンティティ管理エンタープライズ・デプロイメントで発生する可能性がある、一般的な問題のトラブルシューティング方法について説明します。
この項の内容は次のとおりです。
この項では、Access Managerで発生する可能性がある一般的な問題とその解決策について説明します。この項の内容は次のとおりです。
問題
Access Managerサーバーで次のようなエラー・メッセージが表示されます。
The user has already reached the maximum allowed number of sessions. Please close one of the existing sessions before trying to login again.
解決策
ログアウトせずに何度もログインすると、構成されているセッションの最大数を超えることがあります。OAM管理コンソールを使用して、構成されているセッションの最大数を変更できます。
OAM管理コンソールを使用して構成を変更するには、次の手順を実行します。
「システム構成」→「共通設定」→「セッション」に移動します。
どのユーザーにも予期されるすべての同時ログイン・セッションに対処できるように、「1ユーザー当たりの最大セッション数」フィールドの値を大きくします。このフィールドには、1以上の任意の値を指定できます。
問題
Oracle Access Managerの構成後、管理サーバーが起動するまでには時間がかかります。
解決策
OAMデータベースをチューニングします。Oracle Access Managerの構成後、管理サーバーを初めて起動すると、いくつかのデフォルト・ポリシーがデータベースに作成されます。データベースが遠方にある場合やチューニングが必要な場合、この処理に長時間かかることがあります。
Resources Authentication Policies Protected Higher Level Policy Protected Lower Level Policy Publicl Policy Authorization Policies Authorization Policies
これらの項目が表示されない場合は、初期移入が失敗しています。管理サーバーのログ・ファイルで詳細を確認します。
問題
保護されたリソースにアクセスすると、Oracle Access Managerからユーザー名とパスワードの入力が要求されます。たとえば、簡単なHTMLページを作成し、これをリソースとして追加すると、資格証明の入力画面が表示されます。
解決策
資格証明の入力画面が表示されない場合は、次の手順を実行します。
IDMDomainのホストの別名が設定されていることを確認します。IDMDomain:80、IDMDomain:Null:、admin.mycompany.com:80およびsso.mycompany.com:443の別名が必要です。
Webゲートがインストールされていることを確認します。
OBAccessClient.xmlがASERVER_HOME/outputからWebゲートのLibディレクトリにコピーされ、Oracle Traffic Directorが再起動されたことを確認します。
OBAccessClient.xmlが最初に作成されたとき、ファイルは書式設定されていません。Oracle Traffic Directorが再起動されたら、ファイルを再検査し、今度は書式設定されていることを確認します。Oracle Traffic Directorを初めて起動すると、新バージョンのファイルがOracle Access Managerから取得されます。
Oracle Access Managerサーバーを停止し、保護されたリソースへのアクセスを試みます。Oracle Access Managerサーバーが使用できないというエラーが表示されます。このエラーが表示されない場合は、Webゲートを再インストールします。
問題
OAMコンソールにログインできません。管理サーバーの診断ログに、次のようなエラー・メッセージが含まれることがあります。
Caused by: oracle.security.idm.OperationFailureException:
oracle.security.am.common.jndi.ldap.PoolingException [Root exception is oracle.ucp.UniversalConnectionPoolException:
Invalid life cycle state.
Check the status of the Universal Connection Pool]
at
oracle.security.idm.providers.stdldap.UCPool.acquireConnection(UCPool.java:112)
解決策
/tmp/UCP*のファイルを削除し、管理サーバーを再起動します。
この項では、Oracle Identity Managerで発生する可能性がある一般的な問題とその解決策について説明します。この項の内容は次のとおりです。
第16.10.2.1項「Oracle Identity Managerの構成実行時のjava.io.FileNotFoundException」
第16.10.2.2項「Oracle Identity Managerでユーザー作成時のResourceConnectionValidationxception」
問題
Oracle Identity Managerの構成実行時に、java.io.FileNotFoundException: soaconfigplan.xml (Permission denied)というエラーが表示され、Oracle Identity Managerの構成が失敗することがあります。
解決策
この問題を回避する手順は次のとおりです。
ファイル/tmp/oaconfigplan.xmlを削除します。
構成を再度起動します(IAM_ORACLE_HOME/bin/config.sh)。
問題
アクティブ/アクティブOracle Identity Manager構成において、Oracle Identity Managerでユーザーを作成していて(Oracle Identity Managerにログインし、「管理」タブをクリックし、「ユーザーの作成」リンクをクリックし、フィールドに必要な情報を入力し、「保存」をクリック)、そのリクエストを処理しているOracle Identity Managerサーバーに障害が発生した場合、Oracle Identity Managerのログ・ファイルに、次のようなResourceConnectionValidationxceptionが出力されることがあります。
[2010-06-14T15:14:48.738-07:00] [oim_server2] [ERROR] [] [XELLERATE.SERVER]
[tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: xelsysadm] [ecid:
004YGJGmYrtEkJV6u3M6UH00073A0005EI,0:1] [APP: oim#11.1.1.3.0] [dcid:
12eb0f9c6e8796f4:-785b18b3:12938857792:-7ffd-0000000000000037] [URI:
/admin/faces/pages/Admin.jspx] Class/Method:
PooledResourceConnection/heartbeat encounter some problems: Operation timed
out[[
com.oracle.oim.gcp.exceptions.ResourceConnectionValidationxception: Operation
timed out
at
oracle.iam.ldapsync.impl.repository.LDAPConnection.heartbeat(LDAPConnection.ja
va:162)
at
com.oracle.oim.gcp.ucp.PooledResourceConnection.heartbeat(PooledResourceConnec
tion.java:52)
.
.
.
解決策
この例外が発生しても、ユーザーは正常に作成されます。
この項では、Oracle SOA Suiteで発生する可能性がある一般的な問題とその解決策について説明します。この項の内容は次のとおりです。
問題: 次のトランザクション・タイムアウト・エラーがログに表示されます。
Internal Exception: java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: XA error: XAResource.XAER_NOTA start() failed on resource 'SOADataSource_soaedg_domain': XAER_NOTA : The XID is not valid
解決方法: トランザクション・タイムアウト設定を確認し、JTAトランザクション・タイムアウトがDataSource XAトランザクション・タイムアウト(これは(データベースの) distributed_lock_timeoutより小さい)より小さいことを確認します。
初期のままの構成では、SOAデータ・ソースでは、XAタイムアウトがいかなる値にも設定されていません。WebLogic Server管理コンソールで、Set XA Transaction Timeout構成パラメータが選択解除されています。この場合、データ・ソースでは、30に設定されているドメイン・レベルのJTAタイムアウトを使用します。また、データベースに対するデフォルトdistributed_lock_timeout値は60です。結果として、トランザクションの予想存続期間がこのような値より短いことが予想されるシステムでは、SOAの構成が正常に機能します。特定の操作にかかると予想されるトランザクション時間に応じて、これらの値を調整してください。
My Oracle Support (以前のMetaLink)を使用して、Oracle Fusion Middlewareの問題を解決できます。My Oracle Supportには、次のような役に立つトラブルシューティング・リソースがあります。
ナレッジ・ベース記事
コミュニティ・フォーラムとディスカッション
パッチとアップグレード
動作保証情報
|
注意: My Oracle Supportを使用してサービス・リクエストを登録することもできます。 |
My Oracle Supportにはhttps://support.oracle.comからアクセスできます。
OIMリコンシリエーション・ジョブの失敗、または次のメッセージが、ログ・ファイルに表示されます。
LDAP Error 53 : [LDAP: error code 53 - Full resync required. Reason: The provided cookie is older than the start of historical in the server for the replicated domain : dc=mycompany,dc=com ]]
このエラーは、一定の期間書き込まれていないOracle Unified Directoryが原因で、OUD変更ログCookieのデータは期限切れになっています。
解決方法:
ブラウザを開き、次の場所に移動します。
https://admin.mycompany.com
XelsysadmUserPswdを使用して、xelsysadmとしてログインします。
「System Management」の下で、「Scheduler」をクリックします。
「Search Scheduled Jobs」の下で、LDAP * (*の前には空白があります)を入力し、[Enter]を押します。
検索結果の各ジョブについて、左側のジョブ名をクリックしてから、右側の「Disable」をクリックします。
すべてのジョブについてこれを行います。ジョブがすでに無効になっている場合は、何もしません。
OUDHOST1で次のコマンドを実行します。
cd OUD_ORACLE_INSTANCE/OUD/bin
./ldapsearch -h idmhost1 -p 1389 -D "cn=oudadmin" -b "" -s base "objectclass=*" lastExternalChangelogCookie
Password for user 'cn=oudadmin': <OudAdminPwd>
dn:
lastExternalChangelogCookie: dc=mycompany,dc=com:00000140c682473c263600000862;
lastExternalChangelogCookie:に続く出力文字列をコピーします。この値は、次の手順で必要です。次に例を示します。
dc=mycompany,dc=com:00000140c682473c263600000862;
16進の部分の長さは、28文字である必要があります。この値に複数の16進の部分がある場合、28文字をそれぞれ空白で区切ります。次に例を示します。
dc=mycompany,dc=com:00000140c4ceb0c07a8d00000043 00000140c52bd0b9104200000042 00000140c52bd0ba17b9000002ac 00000140c3b290b076040000012c;
次のLDAPリコンシリエーション・ジョブをそれぞれ1回実行して、最終変更番号をリセットします。
LDAPロール削除完全リコンシリエーション
LDAPユーザー削除完全リコンシリエーション
LDAPロール作成更新完全リコンシリエーション
LDAPユーザー作成更新完全リコンシリエーション
LDAPロール階層完全リコンシリエーション
LDAPロール・メンバーシップ完全リコンシリエーション
ジョブを実行するには、次の手順を実行します。
ユーザーxelsysadmとしてOIMシステム管理コンソールにログインします。
「System Management」の下で、「Scheduler」をクリックします。
「Search Scheduled Jobs」の下で、LDAP * (*の前には空白があります)を入力し、[Enter]を押します。
実行するジョブをクリックします。
パラメータ「Last Change Number」を、手順6で取得した値に設定します。
次に例を示します。
dc=mycompany,dc=com:00000140c4ceb0c07a8d00000043 00000140c52bd0b9104200000042 00000140c52bd0ba17b9000002ac 00000140c3b290b076040000012c;
「Run Now」をクリックします。
この手順の最初にあるリストのジョブごとに繰り返します。
最終変更ログ番号がリセットされた各増分リコンシリエーション・ジョブに対して、ジョブを実行し、そのジョブが正常に完了していることを確認します。
ジョブが正常に実行されたら、要件に応じて、ジョブの定期的な実行を再度有効にします。
問題が発生したままの場合、各OUDインスタンスで次のコマンドを実行して、Cookie保存期間を2か月に増やします。
増分ジョブを再度有効化し、正常に実行した後で、エラーが再度表示される場合(「完全な再同期が必要です。理由: 提供されたCookieは...」)、OUD Cookie保存期間を増やします。この値について厳重なルールはありませんが、問題を回避するには、値を十分に長くします。しかし、OUDで不要なリソースを消費しなくて済むようにするには、値を短くします。1週間または2週間で十分です。次の例では、2週間に指定しています。
./dsconfig set-replication-server-prop --provider-name "Multimaster Synchronization" --set replication-purge-delay:2w -D cn=oudadmin --trustAll -p 4444 -h IDMHOST1 Password for user 'cn=oudadmin': <OudAdminPswd> Enter choice [f]: f
問題: 「IT resources」、「Directory」の下のシステム管理コンソールに、必要なもの以外の検索ベース・レベルが含まれています。
次に例を示します。
dc=com
かわりに、次のようになっています。
dc=mycompany, dc=com
解決方法:
次のディレクトリにあるadapters.os_xmlファイルを編集します。
DOMAIN_HOME/config/fmwconfig/ovd/oim
検索ベースを<remoteBase>および<root>に追加します。
***Changed IT Resource and applied the changes on sysadmin console to : dc=mycompany,dc=com
次のURLからシステム管理コンソールに移動します。
http://ssomycompany.com/sysadmin
要求されたら、管理IDおよびパスワードを入力します。
「Configuration」、「IT Resource」の順に移動します。
「Search」フィールドで、「Directory Services」と入力し、「Search」をクリックします。
dc=comからdc=mycompany,dc=comに編集し、「Save」をクリックします。
検索ベースの変更後に次のようなエラーが表示される場合、次を実行します。
INSUFFICIENT PRIVILEGES LDAP 50
両方のOUDサーバーのconfig.ldifファイルに、次のACIを追加します。
ds-cfg-global-aci: (targetcontrol="1.2.840.113556.1.4.319") (version 3.0; acl "page read control access"; allow(read) userdn="ldap:///cn=oimLDAP,cn=systemids,dc=mycompany,dc=com";)
