Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11g リリース2 (11.1.2.1) B71694-06 |
|
![]() 前 |
![]() 次 |
この章では、Identity Managementのトポロジの設定後に実行できる操作について説明します。実行できる操作には、トポロジの監視、スケーリング、バックアップ、トラブルシューティングなどがあります。
この章の内容は次のとおりです。
この項では、Oracle Identity Managementエンタープライズ・デプロイメントの各種コンポーネントを起動、停止および再起動する方法を説明します。
この項には次のトピックが含まれます:
インフラストラクチャ全体を起動するときは、次の順序で各コンポーネントを起動します(トポロジ内に存在しないコンポーネントは無視してください)。
データベース
データベース・リスナー
LDAPディレクトリ・サーバー
ノード・マネージャ
Oracle Access Managerサーバー
WebLogic管理サーバー
Oracle HTTP Server
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は第B.3項のNMGR_PORT
、domain_name
はドメインの名前、Admin_User
およびAdmin_Password
は第8.5.5項「ノード・マネージャ資格証明の更新」の手順2で入力したノード・マネージャのユーザー名とパスワードです。例:
nmConnect('weblogic','password', 'IDMHOST1','5556', 'IDMDomain','MSERVER_HOME')
nmStart('WLS_OAM1')
すでに別のOracle Access Manager管理対象サーバーが実行されている場合にさらに管理対象サーバーを起動するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。
次のように実行します。
「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。
「制御」タブをクリックします。
OAMサーバー(WLS_OAM1またはWLS_OAM2、あるいはその両方)を選択します。
「起動」ボタンをクリックします。
サーバーを起動してよいか確認を求められたら、「はい」をクリックします。
Oracle Access Manager管理対象サーバーを停止するには、第17.2項「Identity Managementコンソールの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
管理サーバーを停止するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。
次のように実行します。
「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。
「制御」タブをクリックします。
「AdminServer(admin)」を選択します。
「停止」をクリックし、「ただちに強制停止」を選択します。
管理サーバーを停止してよいか確認を求められたら「はい」をクリックします。
ノード・マネージャを起動および停止するには、次のようにします。
起動しようとするノード・マネージャが、管理サーバー(IDMHOST1またはIDMHOST2)を制御するノード・マネージャである場合は、その起動の前に次のコマンドを発行します。
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
ノード・マネージャで共有記憶域を使用している場合は、第13.3.5項「共通または共有記憶域インストールの使用」の説明に従ってJAVA_OPTIONS
を設定します。
ノード・マネージャを起動するには、次のコマンドを実行します。
cd IAM_MW_HOME/wlserver_10.3/server/bin
./startNodeManager.sh
cd WL_HOME/server/bin
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
./startNodeManager.sh
注意: 管理サーバーを管理するノード・マネージャを起動する場合は、 |
Oracle HTTP Serverを起動または停止する前に、環境変数WEB_ORACLE_HOME
およびORACLE_INSTANCE
が定義済であり、PATH
にORACLE_HOME
/opmn/bin
が記述済であることを確認します。例:
export ORACLE_HOME=WEB_ORACLE_HOME export ORACLE_INSTANCE=WEB_ORACLE_INSTANCE export PATH=$ORACLE_HOME/opmn/bin:$PATH
次のコマンドを実行して、Web層を停止します。
opmnctl stopall
前述を実行すると、Web層全体が停止します。
opmnctl stoproc process-type=OHS
前述を実行すると、Oracle HTTP Serverのみが停止します。
Oracle Identity ManagerサーバーとOracle SOA Suiteサーバーを起動および停止するには、次のようにします。
Oracle Identity Manager管理対象サーバーを起動するには、第17.2項「Identity Managementコンソールの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管理対象サーバーを停止するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインし、次の手順を実行します。
「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。
「制御」タブをクリックします。
OIMサーバー(WLS_OIM1またはWLS_OIM2、あるいはその両方)および(WLS_SOA1またはWLS_SOA2、あるいはその両方)を選択します。
「停止」ボタンをクリックし、「ただちに強制停止」を選択します。
サーバーを停止してよいか確認を求められたら、「はい」をクリックします。
表17-1は、このガイドの中で使用されている管理コンソールとそのURLの一覧です。
表17-1 コンソールのURL
ドメイン | コンソール | URL |
---|---|---|
IDMDomain |
WebLogic管理コンソール |
|
Enterprise Manager FMWコントロール |
|
|
OAMコンソール |
|
|
ODSM |
|
|
OIMDomain |
OIMコンソール |
|
OIMDomain |
WebLogic管理コンソール |
|
OIMDomain |
Enterprise Manager FMWコントロール |
|
OIMDomain |
認可ポリシー・マネージャ |
|
この項では、このマニュアルで説明しているIdentity Managementエンタープライズ・デプロイメントの監視について説明します。
この項には次のトピックが含まれます:
Oracle Enterprise Manager Fusion Middleware Controlを使用すると、管理対象サーバーや他のFusion Middlewareコンポーネント(Access Manager、Oracle Identity Manager、SOAなど)を監視できます。詳細は、「関連ドキュメント」の「はじめに」で一覧表示されている各管理者ガイドを参照してください。
次のコマンドを実行することによって、Oracle Unified Directoryのステータスを確認できます。
OUD_ORACLE_INSTANCE/OUD/bin/status
このコマンドは、ローカルで実行されているOracle Unified Directoryのインスタンスにアクセスし、ディレクトリのステータスをレポートします(レプリケーションの有効/無効、LDAPまたはLDAPSの有効/無効など)。
このマニュアルで取り上げている参照エンタープライズ・トポロジはきわめてスケーラブルです。スケール・アップもスケール・アウトも可能です。トポロジをスケール・アップすると、すでに1つ以上のサーバー・インスタンスを実行しているノードに新しいサーバー・インスタンスが追加されます。トポロジをスケール・アウトすると、新しいノードに新しいサーバーが追加されます。
この項には次のトピックが含まれます:
このガイドで説明しているOracle Identity Managementトポロジには、データベース層、アプリケーション層およびWeb層という3つの層があります。すでに1つ以上のサーバー・インスタンスが実行されているノードに新しいサーバー・インスタンスを追加することで、3つすべての層内のコンポーネントをスケール・アップできます。
この項で説明する手順では、管理対象サーバーまたは管理対象ディレクトリの新しいインスタンスを作成する方法を示します。新しい管理対象サーバーを追加する場合は、その管理対象サーバーを追加した後で、Oracle HTTP Serverの構成ファイルをすべてのノードで更新し、既存のWebLogicクラスタ・ディレクティブにその新しいサーバーを追加する必要があります。
たとえば、Oracle Access Managerの新しいサーバーを追加する場合は、WEB_ORACLE_INSTANCE
/config/OHS/
component_name
/moduleconf/sso_vh.conf
を更新して、この新しい管理対象サーバーを含める必要があります。
sso_vh.conf
を次のように更新します。
<Location /oam>
SetHandler weblogic-handler
WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST3.mycompany.com:14100
</Location>
sso_vh.conf
を更新したら、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってOracle HTTPサーバーを再起動します。サービスの停止を防止するため、再起動は順次的に行うことをお薦めします。
この項には次のトピックが含まれます:
ディレクトリにはOracle Unified Directoryの2つのノード(IDMHOST1とIDMHOST2)があり、それぞれでOracle Unified Directoryインスタンスが実行されます。各ノードのOracle Unified Directoryバイナリを使用して、Oracle Unified Directoryの新しいインスタンスを作成できます。
Oracle Unified DirectoryのいずれかのホストにOracle Unified Directoryの新しいインスタンスを追加するには、第7.4.3項「IDMHOST2での追加のOracle Unified Directoryインスタンスの構成」の手順を実行します。ただし、手順に次の変更を加えます。
手順2および手順4で、1389 (LDAP_DIR_PORT)、1636 (LDAP_DIR_SSL_PORT)、4444 (LDAP_DIR_ADMIN_PORT)以外のポートを選択します。これらのポートは、ノード上の既存のOracle Unified Directoryインスタンスですでに使用されているためです。
Oracle Unified Directoryの新しいインスタンスの場所をORACLE_INSTANCEの値として使用します。
新しいOracle Unified Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。
次の手順でOracle Access Managerをスケール・アップします。
第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「ロックして編集」を「チェンジ・センター」メニューでクリックします。
拡張するホスト上の既存サーバーを選択します(例: WLS_OAM1
)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3
です。
サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新しく作成したサーバーWLS_OAM3をクリックします。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3
管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。IDMHOST
n
上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名検証を無効にする手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし
」に設定します。
「保存」をクリックします。
「チェンジ・センター」で「変更のアクティブ化」をクリックします。
Oracle Access Managerに新しい管理対象サーバーを登録します。この時点で、新しい管理対象サーバーをOracle Access Managerサーバーとして構成する必要があります。Oracle OAMコンソールでこれを行います。次のように実行します。
oamadmin
ユーザーでOAMコンソールにログインします。第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用します。
「システム構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「作成」を「アクション」メニューで選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行するホスト。
ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポートです。
OAMプロキシ・ポート: Oracle Access Managerプロキシの実行対象とするポート。これは当該ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: 既存のOracle Access Managerサーバーが動作しているモードに応じて、「オープン」
または「簡易」
を選択します。
Coherenceローカル・ポート: 「ローカル・ポート」にホストで一意の値を設定します。
「適用」をクリックします。
第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。
新しく作成したOracle Access Managerサーバーを使用する可能性のあるすべてのWebゲート・プロファイル(Webgate_IDM
やIAMSuiteAgent
)にそのサーバーを追加します。
たとえば、Oracle Access ManagerサーバーをWebgate_IDM
に追加するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してOAMコンソールにアクセスし、次の手順を実行します。
第9.4項「アイデンティティ・ストアの準備」で作成したOracle Access Manager管理ユーザーとしてログインします。
「システム構成」タブをクリックします。
「Access Manager」→「SSOエージェント」→「OAMエージェント」を開きます。
フォルダを開くアイコンをクリックして「検索」をクリックします。
Webゲート・エージェントWebgate_IDMが表示されます。
エージェントWebgate_IDMをクリックします。
「アクション」メニューで「編集」を選択します。
「プライマリ・サーバー」リスト(これがセカンダリ・サーバーである場合は「セカンダリ・サーバー」リスト)で「+」
をクリックします。
「サーバー」リストから、新しく作成した管理対象サーバーを選択します。
「接続の最大数」を10
に設定します。
「適用」をクリックします。
IAMSuiteAgentおよび、使用している可能性のあるその他すべてのWebゲートで、手順5 - 10を繰り返します。
Web層を更新します。新しい管理対象サーバーが作成され、起動されると、Web層から各種の要求がそのサーバーに送られるようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。
これを行うには、各Web層でファイルsso_vh.conf
を更新します。このファイルは、ディレクトリWEB_ORACLE_INSTANCE
/config/OHS/
component_name
/moduleconf
にあります。
新しいサーバーをこのファイル内のWebLogicCluster
ディレクティブに追加します。次に変更前の例を示します。
<Location /oam> SetHandler weblogic-handler WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100 </Location>
変更後は次のようになります。
<Location /oam>
SetHandler weblogic-handler
WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST1.mycompany.com:14101
</Location>
このファイルを保存し、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってOracle HTTP Serverを再起動します。
これで第17.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バイナリをインストールする必要はありません。また、パックと解凍を実行する必要もありません。
次の手順に従って、トポロジをスケール・アップします。
第17.2項「Identity Managementコンソールの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サーバーを作成します。この操作は次のように実行します。
WebLogic管理コンソールにログインし、「サービス」→「メッセージング」→「JMSサーバー」に移動します。
「新規」をクリックします。
「名前」に、BPMJMSServer_auto_3
などの値を入力します。
「新しいファイル・ストアの作成」をクリックします。
リストからFileStore
を選択します。
「次へ」をクリックします。
「名前」に、BPMJMSFileStore_auto_3
などの値を入力します。
次の値を入力します。
ターゲット: 現在作成している新しいサーバー。
ディレクトリ: ASERVER_HOME
/jms/BPMJMSFileStore_auto_3
注意: ディレクトリが存在していることを確認してください。存在しない場合、WLS_OIM3またはWLS_SOA3を起動できません。 |
「OK」をクリックします。
「JMSサーバー」画面に戻り、新しく作成したファイル・ストアをリストから選択します。
「次へ」をクリックします。
次の画面で、「ターゲット」を作成しているサーバーに設定します。
「終了」をクリックします。
作成する管理対象サーバーに応じて、次のJMSキューを作成します。
サーバー | JMSサーバー名 | ファイル・ストア名 | ディレクトリ | ターゲット |
---|---|---|---|---|
WLS_SOAn |
BPMJMSServer_auto_n |
BPMJMSFileStore_auto_n |
|
WLS_SOAn |
WLS_SOAn |
SOAJMSServer_auto_n |
SOAJMSFileStore_auto_n |
|
WLS_SOAn |
WLS_SOAn |
UMSJMSServer_auto_n |
UMSJMSFileStore_auto_n |
|
WLS_SOAn |
WLS_OIMn |
OIMJMSServer_auto_n |
OIMJMSFileStore_auto_n |
|
WLS_OIMn |
WLS_OIMn |
JRFWSAsyncJmsServer_auto_n |
JRFWSAsyncFileStore_auto_n |
|
WLS_OIMn |
次の手順を実行して、新しく作成したJMSキューを既存のJMSモジュールに追加します。
WebLogic管理コンソールにログインします。
「サービス」→「メッセージング」→「JMSモジュール」に移動します。
SOAJMSModuleなどのJMSモジュールをクリックします。
「サブデプロイメント」タブをクリックします。
表示されたサブ・デプロイメントをクリックします。
注意: このサブデプロイメント・モジュール名は、JMSServerNameXXXXXXという形式のランダムな名前で、構成ウィザードJMS構成から生成されます。 |
新しく作成したJMSサーバーを割り当てます(SOAJMSServer_auto_3など)。
「保存」をクリックします。
これを、次の表に記載されている各JMSモジュールに対して実行します。
JMSモジュール | JMSサーバー |
---|---|
BPMJMSModule |
BPMJMSServer_auto_n |
JRFWSAsyncJmsModule |
JRFWSAsyncJmsServer_auto_n |
OIMJMSModule |
OIMJMSServer_auto_n |
SOAJMSModule |
SOAJMSServer_auto_n |
UMSJMSSystemResource |
UMSJMSServer_auto_n |
第12.9項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従ってOracle Coherenceを構成します。
注意: 変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。 |
管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory; java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001; java.naming.security.principal=weblogic; java.naming.security.credentials=weblogic1
新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。
Oracle WebLogic Server管理コンソールにログインします。
「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いてから、「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。
表の「名前」列で、Oracle Identity ManagerまたはSOAサーバーの名前(ハイパーリンクで表示されています)をクリックします。
選択したサーバーの「設定」ページが表示され、「構成」タブにデフォルト設定されます。
「サービス」サブタブを開きます。
ページの「デフォルト・ストア」セクションで、共有記憶域にあるデフォルトの永続ストアへのパスを指定します。パスのディレクトリ構造は次のとおりです。
Oracle Identity Managerサーバー: ASERVER_HOME
/tlogs
SOAサーバー: ASERVER_HOME
/tlogs
保存してアクティブ化するをクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOA
n
管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。IDMHOST
n
上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。
ホスト名検証を無効にする手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_SOAn
」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし
」に設定します。
「保存」をクリックします。
WLS_OIM
n
の各管理対象サーバーでも、手順6a - 6hを繰り返してホスト名検証を無効にします。手順6dでは、表の「名前」列で「WLS_OIMn」
を選択します。
クラスタ・アドレス・リストに新しいサーバーを追加します。
WebLogic管理コンソールの「ドメイン構造」ウィンドウで「環境」ノードを展開します。
「クラスタ」をクリックします。「クラスタの概要」ページが表示されます。
クラスタ名oim_clusterをクリックします。「クラスタのプロパティ」ページが表示されます。
クラスタ・アドレス・リストに新しいOIM管理対象サーバーを追加します。
「保存」をクリックします。
「チェンジ・センター」で「変更のアクティブ化」をクリックします。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAのホストとポートを更新します。次の手順に従います。
ブラウザを開き、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してOracle Enterprise Manager Fusion Middleware Controlにアクセスします。
管理ユーザー資格証明を使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。
注意: 前述の手順を実行する際に、1つ以上のOracle Identity Manager管理対象サーバーを実行している必要があります。 |
「Farm_IDMDomain」→「Identity and Access」→「OIM」→「oim(11.1.2.0.0)」を選択します。
メニューから「システムMBeanブラウザ」を選択するか、または右クリックしてこの項目を選択します。
「アプリケーション」を選択し、定義済Mbean→「oracle.iam」を選択します。「サーバー」には「WLS_OIM1」、「アプリケーション」には「oim」を選択します。XML構成→「構成」を選択し、「XMLConfig.SOAConfig」→「SOAConfig」を選択します。
新しいSOAサーバーのホストとポートでRmiurl属性の値を更新します。「適用」をクリックして、変更を保存します。
Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBにアクセスするために使用されます。これがアプリケーション・サーバーのURLです。この属性の値の例を次に示します。
cluster:t3://soa_cluster
第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。
管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーを停止します。
新規作成した管理対象サーバーであるWLS_SOA
nが稼働していることを確認します。
新しく作成した管理対象サーバー(http://vip:port/soa-infra
)上のアプリケーションにアクセスします。アプリケーションは機能している必要があります。
新しく作成した管理対象サーバーを、サーバー移行ができるように構成します。第14.6項「サーバー移行ターゲットの構成」の手順に従って、サーバー移行を構成します。
この新規サーバーのサーバー移行をテストします。新規サーバーの追加先となったノードで、次の手順を実行します。
管理対象サーバーWLS_SOA
nを停止します。
このためには、次のコマンドを実行します。
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をスケール・アップするには、第10章「エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成」の手順に従います。
第10章「エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成」の説明に従い、Oracle Fusion Middleware 11gのWeb層ユーティリティ構成ウィザードを使用してトポロジをスケール・アップします。
既存のWeb層構成のORACLE_INSTANCE
/config/OHS/
component
/moduleconf
内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。
新しいOracle HTTP Serverインスタンスのホスト情報とポート情報に基づいてロード・バランサを再構成します。
トポロジをスケール・アウトする際は、新しいサーバーを新しいノードに追加します。このマニュアルで説明しているOracle Identity Managementトポロジのコンポーネントは、新しいノードに新しいサーバー・インスタンスを追加することでスケール・アウトできます。
この項で説明する手順では、新しいWebLogic管理対象サーバーを作成する方法を示します。トポロジに新しい管理対象サーバーを追加する場合は、その管理対象サーバーを追加した後で、Oracle HTTP Serverの構成ファイルをすべてのノードで更新し、既存のWebLogicクラスタ・ディレクティブにその新しいサーバーを追加する必要があります。
たとえば、Oracle Access Managerの新しいサーバーを追加する場合は、WEB_ORACLE_INSTANCE
/config/OHS/
component_name
/moduleconf/sso_vh.conf
を更新して、この新しい管理対象サーバーを含める必要があります。
sso_vh.conf
を次のように更新します。
<Location /oam>
SetHandler weblogic-handler
WebLogicCluster
IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST3.mycompany.com:14100
</Location>
sso_vh.conf
を更新したら、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってOracle HTTPサーバーを再起動します。サービスの停止を防止するため、再起動は順次的に行うことをお薦めします。
この項には次のトピックが含まれます:
ディレクトリにはOracle Unified Directoryの2つのノード(IDMHOST1とIDMHOST2)があり、それぞれでOracle Unified Directoryインスタンスが実行されます。Oracle Unified Directoryのインスタンスは、次に示すように、構成に新しいノードを追加することによってスケール・アウトできます。
第7.3項「Oracle Unified Directoryのインストール」の手順に従って、新しいホストにOUDバイナリをインストールします。
第7.4.3項「IDMHOST2での追加のOracle Unified Directoryインスタンスの構成」の手順に従います。
新しいOracle Unified Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。
スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。
新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやIdentity Managementのバイナリをインストールする必要はありませんが、新しいノードでドメイン構成をブートストラップするためにパックと解凍を実行する必要があります。
注意: 共有記憶域を使用している場合は、その共有記憶域に新しいホストがアクセスできるようにします。 |
新しいノードで、Identity and Access Managementのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできるようにします。
ミドルウェア・ホーム・リストを更新するには、IAM_MW_HOME
/bea/beahomelist
ファイルを作成して(別のWebLogicがそのノードにインストールされている場合は編集します)、IAM_MW_HOME
/product/fmw
をこのファイルに追加します。
第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「ロックして編集」を「チェンジ・センター」メニューでクリックします。
拡張するホスト上の既存サーバーを選択します(例: WLS_OAM1)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3
です。
サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新規作成したサーバーである「WLS_OAM3」をクリックします。
SSLリスニング・ポートを設定します。このポートは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。IDMHOSTn
上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名の検証を無効化する手順は、次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「環境」ノードを「ドメイン構造」ペインで開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
「チェンジ・センター」で「変更のアクティブ化」をクリックします。
第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。
次のコマンドを使用してIDMHOST1上のドメインをパックします。
pack.sh -domain=ASERVER_HOME -template=/tmp/IDMDomain.jar -template_name="OAM Domain" -managed=true
pack.sh
スクリプトは、ORACLE_COMMON_HOME
/common/bin
にあります。
次のコマンドを使用して新しいホスト上でドメインを解凍します。
unpack.sh -domain=MSERVER_HOME -template=/tmp/IDMDomain.jar -app_dir=MSERVER_HOME/applications
unpack.sh
スクリプトは、ORACLE_COMMON_HOME
/common/bin
にあります。
ノード・マネージャを起動して、プロパティ・ファイルを更新します。
第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の手順に従い、ノード・マネージャを起動および停止します。
ORACLE_COMMON_HOME
/common/bin
にあるスクリプトsetNMProps.sh
を実行して、ノード・マネージャのプロパティ・ファイルを更新します。たとえば、次のように指定します。
cd ORACLE_COMMON_HOME/common/bin ./setNMProps.sh
第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の手順に従い、ノード・マネージャを再度起動します。
Oracle Access Managerに新しい管理対象サーバーを登録します。この時点で、新しい管理対象サーバーをOracle Access Managerサーバーとして構成する必要があります。このためには、Oracle OAMコンソールで次の手順を実行します。
oamadmin
ユーザーでOAMコンソールにログインします。第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用します。
「システム構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「作成」を「アクション」メニューで選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行しているホストIDMHOST3
。
ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポート。
OAMプロキシ・ポート: Oracle Access Managerプロキシの実行対象とするポート。これは当該ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: 既存のOracle Access Managerサーバーが動作しているモードに応じて、「オープン」
または「簡易」
を選択します。
「適用」をクリックします。
新しく作成したOracle Access Managerサーバーを使用する可能性のあるすべてのWebゲート・プロファイル(Webgate_IDM
やIAMSuiteAgent
)にそのサーバーを追加します。
たとえば、Oracle Access ManagerサーバーをWebgate_IDMに追加するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してOAMコンソールにアクセスし、次の手順を実行します。
第9.4項「アイデンティティ・ストアの準備」で作成したOracle Access Manager管理ユーザーとしてログインします。
「システム構成」タブをクリックします。
「Access Manager」→「SSOエージェント」→「OAMエージェント」を開きます。
フォルダを開くアイコンをクリックして「検索」をクリックします。
Webゲート・エージェントWebgate_IDMが表示されます。
エージェントWebgate_IDMをクリックします。
「アクション」メニューで「編集」を選択します。
「プライマリ・サーバー」リスト(これがセカンダリ・サーバーである場合は「セカンダリ・サーバー」リスト)で「+」
をクリックします。
「サーバー」リストから、新しく作成した管理対象サーバーを選択します。
「最大接続数」を4
に設定します。
「適用」をクリックします。
IAMSuiteAgent
および、使用しているその他すべてのWebゲートで、手順5 - 10を繰り返します。
Web層を更新します。これで新しい管理対象サーバーが作成され、起動されたので、Web層から各種の要求がそのサーバーに送られるようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。
これを行うには、各Web層でファイルsso_vh.conf
を更新します。このファイルは、ディレクトリWEB_ORACLE_INSTANCE
/config/OHS/
component_name
/moduleconf
にあります。
新しいサーバーをこのファイル内のWebLogicCluster
ディレクティブに追加します。次に変更前の例を示します。
<Location /oam> SetHandler weblogic-handler WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100 </Location>
変更後は次のようになります。
<Location /oam> SetHandler weblogic-handler WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST3.mycompany.com:14100 </Location>
トポロジをスケール・アウトする際は、OIMおよびSOAとともに構成された新しい管理対象サーバーを新しいノードに追加します。
この項の手順を実行する前に、次の要件を満たしていることを確認してください。
OIMおよびSOAとともに構成された管理対象サーバーが実行されている既存のノードがトポロジ内に存在していること。
新しいノードがWebLogic Server、OIMおよびSOAの既存のホーム・ディレクトリにアクセスできること。
新しい管理対象サーバーWLS_SOAまたはWLS_OIMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic Server、OIMまたはSOAのバイナリをインストールする必要はありませんが、新しいノードでドメイン構成をブートストラップするためにパックと解凍を実行する必要があります。
注意:
|
次の手順に従って、トポロジをスケール・アウトします。
新しいノードで、Oracle Fusion Middlewareのインストールとドメイン・ディレクトリが格納されている既存の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
をこのファイルに追加します。
第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic管理コンソールにログインします。
使用する新しいノード用の新しいマシンを作成して、そのマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。
Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーWLS_OIM1
およびWLS_SOA1
を新しい管理対象サーバーにクローニングします。それらの管理対象サーバーに、それぞれWLS_SOA
n
およびWLS_OIM
n
という名前を付けます。n
は数字です。
注意: これらの手順では、管理対象サーバーが実行されていないノード |
新しい管理対象サーバーのリスニング・アドレスにホスト名またはIPアドレスを割り当てます。
管理対象サーバーを新しく作成したマシンに割り当てます。
このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーのVIPアドレス(別称: 浮動IPアドレス)である必要があります。このVIPアドレスは、既存の管理対象サーバーで使用されているものとは異なっている必要があります。
新しい管理対象サーバー上に、SOA、Oracle Identity Manager、UMSおよびBPMそれぞれのJMSサーバーを作成します。この操作は次のように実行します。
WebLogic管理コンソールにログインし、「サービス」→「メッセージング」→「JMSサーバー」に移動します。
「新規」をクリックします。
「名前」に、BPMJMSServer_auto_3
などの値を入力します。
「新しいファイル・ストアの作成」をクリックします。
リストからFileStore
を選択します。
「次へ」をクリックします。
「名前」に、BPMJMSFileStore_3
などの値を入力します。
次の値を入力します。
ターゲット: 現在作成している新しいサーバー。
ディレクトリ: ASERVER_HOME
/jms/BPMJMSFileStore_3
「OK」をクリックします。
「JMSサーバー」画面に戻り、新しく作成したファイル・ストアをリストから選択します。
「次へ」をクリックします。
次の画面で、「ターゲット」を作成しているサーバーに設定します。
「終了」をクリックします。
作成する管理対象サーバーに応じて、次のJMSキューを作成します。
サーバー | JMSサーバー名 | ファイル・ストア名 | ディレクトリ | ターゲット |
---|---|---|---|---|
WLS_SOAn |
BPMJMSServer_auto_n |
BPMJMSFileStore_n |
|
WLS_SOAn |
WLS_SOAn |
SOAJMSServer_auto_n |
SOAJMSFileStore_n |
|
WLS_SOAn |
WLS_SOAn |
UMSJMSServer_auto_n |
UMSJMSFileStore_n |
|
WLS_SOAn |
WLS_OIMn |
OIMJMSServer_auto_n |
OIMJMSFileStore_n |
|
WLS_OIMn |
WLS_OIMn |
JRFWSAsyncJmsServer_auto_n |
JRFWSAsyncJmsServer_n |
|
WLS_OIMn |
次の手順を実行して、新しく作成したJMSキューを既存のJMSモジュールに追加します。
WebLogic管理コンソールにログインします。
「サービス」→「メッセージング」→「JMSモジュール」に移動します。
SOAJMSModuleなどのJMSモジュールをクリックします。
「サブデプロイメント」タブをクリックします。
表示されたサブ・デプロイメントをクリックします。
注意: このサブデプロイメント・モジュール名は、JMSServerNameXXXXXXという形式のランダムな名前で、構成ウィザードJMS構成から生成されます。 |
新しく作成したJMSサーバーを割り当てます(SOAJMSServer_auto_3など)。
「保存」をクリックします。
これを、次の表に記載されている各JMSモジュールに対して実行します。
JMSモジュール | JMSサーバー |
---|---|
BPMJMSModule |
BPMJMSServer_auto_n |
JRFWSAsyncJmsModule |
JRFWSAsyncJmsServer_auto_n |
OIMJMSModule |
OIMJMSServer_auto_n |
SOAJMSModule |
SOAJMSServer_auto_n |
UMSJMSSystemResource |
UMSJMSServer_auto_n |
「チェンジ・センター」で「変更のアクティブ化」をクリックします。
pack
、scp
およびunpack
コマンドを使用して、ドメインのバックアップを作成します。これを行うには、次の手順を実行します。
IDMHOST1上でpack
コマンドを実行して、テンプレートを作成します。
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を構成します。
注意: 変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。 |
Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAのホストとポートを更新します。次の手順に従います。
ブラウザを開き、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してOracle Enterprise Manager Fusion Middleware Controlにアクセスします。
WebLogic管理アカウントweblogic_idm
を使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。
注意: 前述の手順を実行する際に、1つ以上のOracle Identity Manager管理対象サーバーを実行している必要があります。 |
「Farm_IDMDomain」→「Identity and Access」→「OIM」→「oim(11.1.2.0.0)」を選択します。
メニューから「システムMBeanブラウザ」を選択するか、または右クリックしてこの項目を選択します。
「アプリケーション」を選択し、定義済Mbean→「oracle.iam」を選択します。「サーバー」には「WLS_OIM1」、「アプリケーション」には「oim」を選択します。XML構成→「構成」を選択し、「XMLConfig.SOAConfig」→「SOAConfig」を選択します。
新しいSOAサーバーのホストとポートでRmiurl属性の値を更新します。「適用」をクリックして、変更を保存します。
Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBにアクセスするために使用されます。これがアプリケーション・サーバーのURLです。この属性の値の例を次に示します。
cluster:t3://soa_cluster
クラスタ・アドレス・リストに新しいサーバーを追加します。
WebLogic管理コンソールの「ドメイン構造」ウィンドウで「環境」ノードを展開します。
「クラスタ」をクリックします。「クラスタの概要」ページが表示されます。
クラスタ名oim_clusterをクリックします。「クラスタのプロパティ」ページが表示されます。
クラスタ・アドレス・リストに新しいOIM管理対象サーバーを追加します。
「保存」をクリックします。
この手順を繰り返して、すべての新しいSOA管理対象サーバーをsoa_clusterアドレス・リストに追加します。
新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。
管理コンソールで、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の下の「ディレクトリ」に、デフォルト永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名検証を無効にします。管理対象サーバーWLS_SOAnおよびWLS_OIMnを起動して検証する前に、ホスト名検証を無効にする必要があります。IDMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。
WLS_SOAnのホスト名検証を無効化する手順は次のとおりです。
「環境」ノードを「ドメイン構造」ウィンドウで開きます。
Oracle WebLogic Server管理コンソールにログインします。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_SOAn
」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし
」に設定します。
「保存」をクリックします。
WLS_OIMnのホスト名検証を無効にするには、手順dで「名前」列にWLS_OIMn
を選択し、それ以外は同じ手順を繰り返します。
「チェンジ・センター」で「変更のアクティブ化」をクリックします。
新しいノード上でノード・マネージャを起動します。ノード・マネージャを起動するには、既存ノードの共有記憶域内のインストール内容を使用して、次のように新しいノードのホスト名をパラメータとして渡してノード・マネージャを起動します。
WL_HOME/server/bin/startNodeManager.sh
Oracle WebLogic Server管理コンソールから、新しい管理対象サーバーを起動してテストします。
クラスタ内の既存の管理対象サーバーをすべて停止します。
新しく作成した管理対象サーバーであるWLS_SOAn
とWLS_OIMnが実行されていることを確認します。
新しく作成した管理対象サーバー上のアプリケーションにアクセスします(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を繰り返します。
Web層には2つのノードがあり、それぞれOracle HTTP Serverインスタンスが実行されています。Oracle HTTP Serverを実行するように構成された新しいノードをWeb層に追加することで、Oracle HTTP Serverのコンポーネントをスケール・アウトできます。Oracle HTTP Serverをスケール・アウトするには、次の手順を実行します。
第10.2.3項「Oracle HTTP Serverのインストール」の手順を実行します。または、共有記憶域を使用している場合は、新しいノード上で既存のミドルウェア・ホームをマウントします。
既存のWeb層構成のWEB_ORACLE_INSTANCE
/config/OHS/
component_name
/moduleconf
内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。
このトポロジでシングル・サインオンを有効にしている場合は、第15.7項「Webゲート11gのインストールと構成」の説明に従って、シングル・サインオンのWeb層構成を更新する必要があります。
新しいOracle HTTP Serverインスタンスのホスト情報とポート情報に基づいてロード・バランサを再構成します。
Oracle Fusion Middleware監査フレームワークは、Oracle Fusion Middleware 11gで追加された新しいサービスであり、ミドルウェア製品ファミリの集中監査フレームワークです。このフレームワークでは、Oracle Platform Security Services (OPSS)やOracle Web Servicesなどのプラットフォーム・コンポーネントに対して監査サービスが提供されます。また、これは、Oracle固有のJavaEEコンポーネントをはじめ、様々なJavaEEアプリケーションのフレームワークとしても機能します。Java EEアプリケーションは、アプリケーション固有の監査イベントを作成できます。ミドルウェアのOracleコンポーネントのうちJavaEE以外のもの、たとえばCやJavaSEのコンポーネントについても、JavaEEアプリケーションと同様、エンドツーエンドのフレームワーク構造を実現します。
図17-1は、Oracle Fusion Middleware監査フレームワーク・アーキテクチャの概要図です。詳細は、『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 Cluster (RAC)データベースの使用をお薦めします。
Oracle Business Intelligence Publisher
監査リポジトリ内のデータは、Oracle Business Intelligence Publisherの定義済レポートにより出力されます。このレポートでは、監査データを様々な条件に基づいてドリルダウンできます。例:
ユーザー名
時間範囲
アプリケーション・タイプ
実行コンテキストID (ECID)
Oracle Fusion Middleware監査フレームワークの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「Oracle Fusion Middleware監査フレームワークの概要」を参照してください。
Oracle Fusion Middleware監査フレームワーク用にリポジトリを構成する方法の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査の構成と管理」を参照してください。
EDGトポロジには、Oracle Fusion Middleware監査フレームワーク構成が含まれていません。監査データをバスストップ・ファイルに生成する機能と監査ローダーの構成は、製品がインストールされた後に使用可能になります。主な留意点は、監査データを保管する監査データベース・リポジトリです。監査データのボリュームと履歴特性により、運用中のストアや他のミドルウェア・コンポーネントによって使用されるストアとは別のデータベースを使用することを強くお薦めします。
ほとんどのバックアップでは、UNIXのtar
コマンドを使用できます。一般的な使用方法は次のとおりです。
tar -cvpf BACKUP_LOCATION/backup_file.tar directories
また、リカバリでもUNIXのtar
コマンドを使用できます。一般的な使用方法は次のとおりです。
tar -xvf BACKUP_LOCATION/backup_file.tar
データベースのバックアップとリカバリでは、データベース・ユーティリティのRMANを使用できます。このコマンドの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
この項には次のトピックが含まれます:
システムを構築するとき、およびOracleバイナリなどの静的なアーティファクトを更新するためのパッチを適用するときに、ベースライン・バックアップを実行します。
ベースライン・バックアップを実行した後は、ランタイム・バックアップも実行します。
表17-2 Identity Managementエンタープライズ・デプロイメントでバックアップする静的アーティファクト
タイプ | 場所 | タイプ | コメント |
---|---|---|---|
データベース |
ORACLE_HOME GridのORACLE_HOME |
ファイル・コピー |
詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
ミドルウェア・ホーム |
|
ファイル・コピー |
共有記憶域にあるため、1つのホストでバックアップすることのみ必要です。 |
Webミドルウェア・ホーム |
ミドルウェア・ホーム: |
ファイル・コピー |
ローカル記憶域に置かれます。それぞれのWEBHOSTを個別にバックアップします。 |
インストール関連 |
|
ファイル・コピー |
ローカル記憶域に置かれます。それぞれのホストを個別にバックアップします。 |
ロード・バランサ |
ファイル・コピー |
ロード・バランサの構成をバックアップします。ベンダーのドキュメントを参照してください。 |
|
サーバー |
オペレーティング・システムをバックアップします。ベンダーのドキュメントを参照してください。 |
脚注 1 分割ドメインのみ
脚注 2 Oracle Internet DirectoryまたはOracle Virtual Directoryのインストールのミドルウェア・ホーム。Oracle Identity Managementのインストールと構成については、このガイドでは扱っていません。
注意: ロード・バランサの構成もバックアップすることをお薦めします。その方法については、ベンダーのドキュメントを参照してください。 |
Oracle Fusion Middlewareコンポーネントのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
ランタイム・バックアップは継続的に実行します。ランタイム・バックアップには、データベース内のデータ、ドメイン構成情報、LDAPディレクトリ内のアイデンティティ情報など、頻繁に変更される項目の情報が含まれます。
表17-3 Identity Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト
タイプ | 場所 | タイプ | コメント |
---|---|---|---|
データベース |
データ |
RMAN |
詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
Oracle Unified Directory |
Oracle Unified Directoryのデータ |
ファイル・コピー Oracle Unified Directoryのバックアップ |
ローカル記憶域に置かれます。それぞれのWEBHOSTを個別にバックアップします。 詳細は、『Oracle Fusion Middleware Oracle Unified Directory管理者ガイド』を参照してください。 コールド・バックアップの実行では、 |
Oracle Internet Directory |
Oracle Internet Directoryのインスタンス データベース内のOracle Internet Directoryのデータ |
ファイル・コピー RMAN |
詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。 |
Oracle Virtual Directory |
Oracle Virtual Directoryのインスタンス |
ファイル・コピー |
詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。 |
サード・パーティのLDAP |
バイナリ LDAPデータ |
ベンダーのドキュメントを参照してください。 |
|
ドメイン・ホーム |
|
ファイル・コピー |
|
Oracle HTTP Server |
|
ファイル・コピー |
|
ベスト・プラクティスとしては、インストールと各層の構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
この項には次のトピックが含まれます:
新しいミドルウェア・ホームを作成する場合、またはミドルウェア・ホームにコンポーネントを追加する場合は、必ずミドルウェア・ホームをバックアップします。
LDAPのデータを更新する操作を実行する場合は、必ずディレクトリ・コンテンツをバックアップします。
この項には次のトピックが含まれます:
Oracle Unified Directoryをバックアップするには、次の手順を実行します。
第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle Unified Directoryのインスタンスを停止します。
各ホスト上のOracle Unified Directoryインスタンスのディレクトリをバックアップします。
第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle Unified Directoryのインスタンスを再起動します。
Oracle Internet Directoryのインスタンスをバックアップするには、次の手順を実行します。
OID_ORACLE_INSTANCE
/bin
ディレクトリにあるopmnctl
を使用してインスタンスを停止します。
OID_ORACLE_INSTANCE/bin/opmnctl stopall
Oracle Internet Directoryのデータをホストしているデータベース、および各ホスト上のOracle Internet Directoryインスタンス・ホームをバックアップします。
OID_ORACLE_INSTANCE
/bin
ディレクトリにあるopmnctl
を使用してインスタンスを起動します。
OID_ORACLE_INSTANCE/bin/opmnctl startall
Oracle Virtual Directoryのインスタンスをバックアップするには、次の手順を実行します。
OVD_ORACLE_INSTANCE
/bin
ディレクトリにあるopmnctl
を使用してインスタンスを停止します。
OVD_ORACLE_INSTANCE/bin/opmnctl stopall
各LDAPホスト上のOracle Virtual Directoryインスタンス・ホームをバックアップします。
OVD_ORACLE_INSTANCE
/bin
ディレクトリにあるopmnctl
を使用してインスタンスを起動します。
OVD_ORACLE_INSTANCE/bin/opmnctl startall
ディレクトリのバックアップの詳細は、オペレーティング・システムのベンダーのドキュメントを参照してください。
構成にコンポーネントを追加して作成する場合は、必ずIDMDBデータベースをバックアップします。このバックアップは、ドメインを作成した後、またはAccess Managerなどのコンポーネントを追加した後に実行します。
WebLogicドメインをバックアップするには、次の手順を実行します。
第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、ドメインで実行されているWebLogic管理サーバーとすべての管理対象サーバーを停止します。
共有記憶域のASERVER_HOME
ディレクトリをバックアップします。
各ホストのMSERVER_HOME
ディレクトリをバックアップします。
Web層をバックアップするには、次の手順を実行します。
第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを停止します。
WEB_ORACLE_INSTANCE
をバックアップします。
第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを起動します。
この項では、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 Virtual Directoryサーバーを停止します。
パッチを適用します。
Oracle Unified Directoryを再起動します。
パッチをテストします。
トラフィックを再びLDAPHOST1にルーティングします。
アプリケーションが正常に動作していることを確認します。
IDMHOST2のLDAPのトラフィックをIDMHOST1にルーティングします。
IDMHOST2に関しても手順2-5を繰り返します。
パッチを適用した両方のホスト(IDMHOST1とIDMHOST2)にトラフィックをルーティングします。
ほとんどの本番デプロイメント環境ではファイアウォールが使用されます。データベース接続は複数のファイアウォールにまたがって確立されるため、データベース接続がタイムアウトにならないようにファイアウォールを構成することをお薦めします。Oracle Real Application Cluster (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
をリスニングし、任意の
アドレスをリスニングしないように構成されている。第8.4項「構成ウィザードを実行してドメインを作成する方法」を参照してください。
管理サーバーはIDMHOST1からIDMHOST2にフェイルオーバーされ、この2つのノードに次のIPアドレスがある。
IDMHOST1: 100.200.140.165
IDMHOST2: 100.200.140.205
ADMINVHN: 100.200.140.206
これは、管理サーバーが稼働している仮想IPアドレスで、IDMHOST1とIDMHOST2で使用可能なinterface:index (eth1:2など)に割り当てられています。
管理サーバーがIDMHOST1内で実行されるドメイン・ディレクトリは、共有記憶域にあり、IDMHOST2からもマウントされている。
注意: IDMHOST2内のNMは、この時点ではドメインを制御しません。これは、 |
Oracle WebLogic ServerおよびOracle Fusion Middlewareコンポーネントは前の章の説明のとおり、IDMHOST2にインストールされている。つまり、IDMHOST1に存在するIDM_ORACLE_HOME
とMW_HOME
のパスは、IDMHOST2でも使用できます。
次の手順は、管理サーバーを異なるノード(IDMHOST2)にフェイルオーバーする方法を示します。
Linux
第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、管理サーバーを停止します。
IPアドレスを2番目のノードに移行します。
IDMHOST1で次のコマンドをrootとして実行します(ここでx:yはADMINVHN.mycompany.com
が使用する現在のインタフェースです)。
/sbin/ifconfig x:y down
例:
/sbin/ifconfig eth0:1 down
IDMHOST2で次のコマンドを実行します。
/sbin/ifconfig interface:index IP_Address netmask netmask
例:
/sbin/ifconfig eth0:1 10.0.0.1 netmask 255.255.255.0
注意: 使用するネットマスクおよびインタフェースがIDMHOST2の使用可能なネットワーク構成と一致することを確認します。 |
arping
を使用してルーティング表を更新します。例:
/sbin/arping -q -U -c 3 -I eth0 10.0.0.1
次の手順を実行して、IDMHOST2上でノード・マネージャを起動します。
IDMHOST1上で、管理サーバー・ドメイン・ディレクトリをアンマウントします。例:
umount /u01/oracle
IDMHOST2で、管理サーバー・ドメイン・ディレクトリをマウントします。例:
mount /u01/oracle
次のコマンドを使用してノード・マネージャを起動します。
cd WL_HOME/server/bin
./startNodeManager.sh
ノード・マネージャ・プロセスを強制終了してノード・マネージャを停止します。
注意: この時点でのノード・マネージャの起動および停止は、ノード・マネージャを初めて実行するときにのみ必要です。起動および停止により、前もって定義されたテンプレートからプロパティ・ファイルが作成されます。次の手順では、そのプロパティ・ファイルにプロパティを追加します。 |
setNMProps.shスクリプトを実行して、ノード・マネージャを起動する前にStartScriptEnabled
プロパティをtrue
に設定します。
cd MW_HOME/oracle_common/common/bin
./setNMProps.sh
注意: クラスのロード障害などの問題が発生しないようにするには、 |
第17.1.5.3項「管理サーバーのノード・マネージャの起動」を参照して、ノード・マネージャを起動します。
IDMHOST2上で管理サーバーを起動します。
cd ORACLE_COMMON_HOME/common/bin ./wlst.sh
WLSTシェルで一度、次のコマンドを実行します。
nmConnect('Admin_User','Admin_Password', 'IDMHOST2','5556', 'IDMDomain','ASERVER_HOME')
nmStart('AdminServer')
注意: WLSTの |
次のアドレスを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://ADMINVHN.mycompany.com/console
ここで、7001
は第B.3項のWLS_ADMIN_PORT
に相当します。
次のアドレスを使用してOracle Enterprise Managerのコンポーネントのステータスにアクセスし、検証できることを確認します。
http://ADMINVHN.mycompany.com/em
分割ドメイン・トポロジを使用しており、IDMHOST2で管理サーバーが実行されている場合は、同じ手順を実行してその管理サーバーにアクセスできることを確認します。
この手順では、管理サーバーをフェイルバックできる(つまり、IDMHOST2上で停止し、IDMHOST1上で実行できる)ことを確認します。これを行うには、次の手順に従って、ADMINVHNを元のIDMHOST1ノードに移行して戻します。
管理サーバーが実行されていないことを確認してください。管理サーバーが実行中の場合、WebLogicコンソールから停止するか、またはコマンドstopWebLogic.sh
をASERVER_HOME
/bin
から実行します。
IDMHOST2上で、管理サーバー・ドメイン・ディレクトリをアンマウントします。例:
umount /u01/oracle
IDMHOST1上で、管理サーバー・ドメイン・ディレクトリをマウントします。例:
mount /u01/oracle
IDMHOST2上のADMINVHN.mycompany.com
の仮想IPアドレスを無効にして、IDMHOST2で次のコマンドをroot
として実行します。
/sbin/ifconfig x:y down
例:
/sbin/ifconfig eth0:1 down
IDMHOST1で次のコマンドを実行します。
/sbin/ifconfig interface:index IP_Address netmask netmask
例:
/sbin/ifconfig interface:index 100.200.140.206 netmask 255.255.255.0
注意: 使用するネットマスクおよびインタフェースがIDMHOST1の使用可能なネットワーク構成と一致することを確認します。 |
次のコマンドを実行してルーティング表を更新します。
/sbin/arping -q -U -c 3 -I interface 100.200.140.206
たとえば、IDMHOST1から次のコマンドを実行します。
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
ノード・マネージャがまだIDMHOST1上で起動されていない場合は、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って起動します。
IDMHOST1で管理サーバーを再起動します。
cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
WLSTシェルが開始されたら、次のコマンドを実行します。
nmConnect(Admin_User,'Admin_Password, IDMHOST1,'5556','IDMDomain','ASERVER_HOME') nmStart('AdminServer')
次のアドレスを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://ADMINVHN.mycompany.com:7001/console
ここで、7001
は第B.3項のWLS_ADMIN_PORT
に相当します。
次のアドレスを使用してOracle Enterprise Managerのコンポーネントのステータスにアクセスし、検証できることを確認します。
http://ADMINVHN.mycompany.com:7001/em
この項では、このマニュアルで説明しているIdentity Managementエンタープライズ・デプロイメントで発生する可能性のある一般的な問題のトラブルシューティング方法を説明します。
この項には次のトピックが含まれます:
この項では、Oracle Internet Directoryで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:
問題
Oracle Internet Directoryサーバーが応答しません。監視のためLDAP SSLポートにICMPメッセージを送信するようにロード・バランシング・ルーターを構成すると、SSLネゴシエーションを開始したOracle Internet Directoryサーバーがハングすることがあります。これにより、ロード・バランシング・ルーターでは、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
この項では、Oracle Virtual Directoryで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:
問題
SSLServerConfig.sh
を実行すると、次のようにcommand not found
エラーが発生します。
./SSLServerConfig.sh: line 169: 20110520125611: command not found
ソリューション
ファイルorapki.sh
(Linuxの場合)を編集して、ファイル末尾にある空白行をすべて削除します。このファイルを保存して、SSLServerConfig.sh
を再度実行します。
問題
Oracle Virtual Directoryが応答しません。監視のためLDAP SSLポートにICMPメッセージを送信するようにロード・バランシング・ルーターを構成すると、SSLネゴシエーションを開始したOracle Virtual Directoryサーバーがハングすることがあります。これにより、ロード・バランシング・ルーターでは、LDAP SSLポートを監視するためのICMPメッセージを使用できません。
ソリューション
TCPやLDAPのプロトコル自体など、別のものを使用してください。
また、LDAPの非SSLポートを監視することも、LDAP可用性を検出するのに十分です。
問題
Oracle Virtual DirectoryサーバーへのSSO/LDAPアプリケーション接続が切断されています。
ソリューション
ロード・バランシング・ルーターのタイムアウトとSSO/Applicationタイムアウト構成パラメータを確認してください。SSO/LDAPアプリケーションのタイムアウト値は、LBR IDLEタイムアウト値未満にする必要があります。
問題
TNSNAMES.ORAやTAFの構成に関連した問題があります。
ソリューション
Oracle Databaseの高可用性の概要に関するマニュアルを参照してください。
問題
コンポーネントOVDでSSLServerConfig.sh
を実行すると、次のようなエラーが発生して失敗することがあります。
>>>Enter password for weblogic: >>>Enter your keystore name [ovdks1.jks]: Checking the existence of ovdks1.jks in the OVD... >>>Failed to configure your SSL server wallet >>>Please check /scratch/aime1/edgfa/idm//rootCA/keystores/ovd/ks_check.log for more information
ログ・ファイルには次のようなエラー・メッセージが記録されています。
Problem invoking WLST - Traceback (innermost last): File "/scratch/aime1/edgfa/idm/rootCA/keystores/ovd/ovdssl-check.py", line 8, in ? File "<iostream>", line 182, in cd File "<iostream>", line 1848, in raiseWLSTExceptionWLSTException: Error occured while performing cd : Attributeoracle.as.ovd:type=component.listenersconfig.sslconfig,name=LDAP SSLEndpoint,instance=ovd1,component=ovd1 not found. Use ls(a) to view theattributes
ソリューション
この問題は断続的に発生します。この問題を回避するには、スクリプトを再実行します。
この項では、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
の別名が必要です。ここで、ポート80
はHTTP_PORT
、ポート443
はHTTP_SSL_PORT
です。
Webゲートがインストールされていることを確認します。
ASERVER_HOME
/output
からWebゲートのLibディレクトリにOBAccessClient.xml
がコピーされ、OHSが再起動されたことを確認します。
OBAccessClient.xmlが最初に作成されたとき、このファイルは適切な形式になっていません。OHSを再起動すると、そのファイルが再検査されて適切な形式になります。OHSを初めて起動すると、このファイルの新しいバージョンが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で発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:
第17.10.4.1項「Oracle Identity Managerの構成実行時のjava.io.FileNotFoundException」
第17.10.4.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トランザクション・タイムアウトがデータ・ソースXAトランザクション・タイムアウトよりも短いことを確認します(後者はデータベースでのdistributed_lock_timeout
よりも短い)。
出荷時の設定では、SOAデータ・ソースではXAタイムアウト値は設定されていません。Set XA Transaction Timeout
構成パラメータはWebLogic Server管理コンソールでは確認されません。この場合、データ・ソースはドメイン・レベルのJTAタイムアウトを使用します。これは30
に設定されています。また、データベースのdistributed_lock_timeout
のデフォルト値は60
です。この結果、トランザクションにかかる時間がこれらの値よりも短いと想定されるシステムでは、SOA構成は正しく動作します。特定の操作に想定されるトランザクション時間に合せて、これらの値を調整します。
Oracle Fusion Middlewareの問題の解決にMy Oracle Support(以前のMetaLink)を使用できます。My Oracle Supportには、次のような有用なトラブルシューティング・リソースが含まれています。
ナレッジ・ベース記事
コミュニティ・フォーラムとディスカッション
パッチとアップグレード
動作保証情報
注意: サービス・リクエストを登録する場合にMy Oracle Supportを使用することもできます。 |
My Oracle Supportにはhttps://support.oracle.com
からアクセスできます。