| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11gリリース1(11.1.1.5) B61378-02 |
|
 前へ |
 次へ |
| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11gリリース1(11.1.1.5) B61378-02 |
|
前へ |
次へ |
この章では、セットアップしたIdentity Managementエンタープライズ・デプロイメントの管理について説明します。
この章の内容は次のとおりです。
この項では、Oracle Identity Managementエンタープライズ・デプロイメントの各種コンポーネントを起動、停止および再起動する方法を説明します。
この項の内容は次のとおりです。
インフラストラクチャ全体を起動するときは、次の順序で各コンポーネントを起動します。
データベース
データベース・リスナー
Oracle Internet Directory
Oracle Virtual Directory
Oracle Access Managerサーバー
OAAMサーバー
WebLogic管理サーバー
Oracle HTTP Server
SOAサーバー
Oracle Identity Managerサーバー
Oracle Virtual Directoryを起動および停止するには、次のようにします。
次のコマンドを入力して、Oracle Virtual Directoryなどのシステム・コンポーネントを起動します。
ORACLE_INSTANCE/bin/opmnctl startall
次を実行することでシステム・コンポーネントが起動されていることを確認できます。
ORACLE_INSTANCE/bin/opmnctl status -l
Oracle Internet Directoryを起動および停止するには、次のようにします。
次のコマンドを入力して、Oracle Internet Directoryなどのシステム・コンポーネントを起動します。
ORACLE_INSTANCE/bin/opmnctl startall
次を実行することでシステム・コンポーネントが起動されていることを確認できます。
ORACLE_INSTANCE/bin/opmnctl status -l
Oracle HTTP Serverを起動または停止する前に、環境変数WEB_ORACLE_HOMEおよびORACLE_INSTANCEが定義済であり、PATHにORACLE_HOME/opmn/binが記述済であることを確認します。次に例を示します。
export ORACLE_HOME=WEB_ORACLE_HOME
export ORACLE_INSTANCE=/u01/app/oracle/admin/web[1-2]
export PATH=$ORACLE_HOME/opmn/bin:$PATH
次のコマンドを実行して、Web層を停止します。
opmnctl stopall
前述を実行すると、Web層全体が停止します。
opmnctl stoproc process-type=OHS
前述を実行すると、Oracle HTTP Serverのみが停止します。
ノード・マネージャを起動および停止するには、次のようにします。
起動しようとするノード・マネージャが、管理サーバー(IDMHOST1またはIDMHOST2)を制御するノード・マネージャである場合は、その起動の前に次のコマンドを発行します。
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
ノード・マネージャを起動するには、次のコマンドを実行します。
IDMHOST> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
IDMHOST> ./startNodeManager.sh
IDMHOST1> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin IDMHOST1> export JAVA_OPTIONS=-DDomainRegistrationEnabled=true IDMHOST1> ./startNodeManager.sh
|
注意: 管理サーバーを管理するノード・マネージャを起動する場合は、 |
WebLogic管理サーバーを起動および停止するには、次のようにします。
管理サーバーを起動するために推奨される方法は、WLSTを使用してノード・マネージャに接続することです。
IDMHOST1> cd ORACLE_BASE/product/fmw/oracle_common/common/bin
IDMHOST1> ./wlst.sh
wlstシェルで一度、次を実行します。
wls:/offline> nmConnect('Admin_User','Admin_Password','ADMINHOST1','5556',
'IDMDomain','/u01/app/oracle/admin/domain_name/aserver/IDMDomain')
wls:/nm/domain_name> nmStart('AdminServer')
または、次のコマンドを使用して管理サーバーを起動することもできます。
DOMAIN_HOME/bin/startWeblogic.sh
管理サーバーを停止するには、URL: http://admin.mycompany.com/consoleを使用してWebLogicコンソールにログインします。
次のように実行します。
「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。
「制御」タブをクリックします。
「AdminServer(admin)」を選択します。
「停止」をクリックし、「ただちに強制停止」を選択します。
管理サーバーを停止してよいか確認を求められたら「はい」をクリックします。
Oracle Identity ManagerサーバーとOracle SOA Suiteサーバーを起動および停止するには、次のようにします。
Oracle Identity Manager管理対象サーバーを起動するには、URL: http://admin.mycompany.com/consoleを使用して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管理対象サーバーを起動するには、URL: http://admin.mycompany.com/consoleを使用してWebLogicコンソールにログインします。次のように実行します。
「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。
「制御」タブをクリックします。
OIMサーバー(WLS_OIM1またはWLS_OIM2、あるいはその両方)および(WLS_SOA1またはWLS_SOA2、あるいはその両方)を選択します。
「停止」ボタンをクリックし、「ただちに強制停止」を選択します。
サーバーを停止してよいか確認を求められたら、「はい」をクリックします。
Oracle Access Managerの管理対象サーバーを起動および停止するには、次のようにします。
Oracle Access Manager管理対象サーバーを起動するには、URL: http://admin.mycompany.com/consoleを使用してWebLogicコンソールにログインします。
次のように実行します。
「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。
「制御」タブをクリックします。
OAMサーバー(WLS_OAM1またはWLS_OAM2、あるいはその両方)を選択します。
「起動」ボタンをクリックします。
サーバーを起動してよいか確認を求められたら、「はい」をクリックします。
Oracle Access Manager管理対象サーバーを停止するには、URL: http://admin.mycompany.com/consoleを使用してWebLogicコンソールにログインします。次のように実行します。
「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。
「制御」タブをクリックします。
OAMサーバー(WLS_OAM1またはWLS_OAM2、あるいはその両方)を選択します。
「停止」ボタンをクリックし、「ただちに強制停止」を選択します。
サーバーを停止してよいか確認を求められたら、「はい」をクリックします。
Oracle Adaptive Access Managerを起動および停止するには、次のようにします。
OAAM管理対象サーバーを起動するには、URL: http://admin.mycompany.com/consoleを使用してWebLogicコンソールにログインします。次のように実行します。
「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。
「制御」タブをクリックします。
OAAMサーバー(WLS_OAAM1またはWLS_OAAM2、あるいはその両方)を選択します。
「起動」ボタンをクリックします。
サーバーを起動してよいか確認を求められたら、「はい」をクリックします。
OAAM管理対象サーバーを停止するには、URL: http://admin.mycompany.com/consoleを使用してWebLogicコンソールにログインします。次のように実行します。
「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。
「制御」タブをクリックします。
OAAMサーバー(WLS_OAAM1またはWLS_OAAM2、あるいはその両方)を選択します。
「停止」をクリックし、「ただちに強制停止」を選択します。
サーバーを停止してよいか確認を求められたら、「はい」をクリックします。
Oracle Identity Federation管理対象サーバーを起動および停止するには、次のようにします。
Oracle Identity Federation管理対象サーバーを起動するには、http://admin.mycompany.com/consoleのWebLogicコンソールにログインします。次のように実行します。
「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
OIFサーバー(WLS_OIF1またはWLS_OIF2(あるいはその両方))を選択します。
「起動」をクリックします。
サーバーを起動してよいか確認を求められたら、「はい」をクリックします。
Oracle Identity Federation管理対象サーバーを停止するには、http://admin.mycompany.com/consoleのWebLogicコンソールにログインします。次のように実行します。
「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
OIFサーバー(WLS_OIF1またはWLS_OIF2(あるいはその両方))を選択します。
「停止」をクリックし、「ただちに強制停止」を選択します。
サーバーを停止してよいか確認を求められたら、「はい」をクリックします。
次のコマンドを実行して、Oracle Identity FederationのインスタンスとEMAgentを起動します。
ORACLE_INSTANCE/bin/opmnctl startall
次のコマンドを実行して、インスタンスが正常に起動されたことを確認できます。
ORACLE_INSTANCE/bin/opmnctl status -l
この項では、このマニュアルで説明しているIdentity Managementエンタープライズ・デプロイメントの監視について説明します。
この項の内容は次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、次のようにOracle Internet Directoryを監視できます。
アイデンティティ管理ドメインのファームのホーム・ページで、Fusion Middlewareの円グラフを表示します。このグラフには、Oracle Fusion Middlewareの各コンポーネントのステータスが表示されます。グラフの緑色の部分は、起動され正常に実行されているコンポーネントを示し、赤色の部分は、起動されていないコンポーネントを示しています。
グラフの下の「Identity and Access」セクションには、個別のOracle Internet Directoryインスタンスの名前(例: oid1、oid2)、そのステータス、ホスト名およびCPU使用率が表示されます。「ステータス」列の緑の矢印は、そのインスタンスが正常に稼働していることを示し、赤い矢印はそのインスタンスが停止していることを示します。個別のOracle Internet Directoryインスタンスの名前をクリックすると、そのインスタンスのホーム・ページが表示されます。
インスタンスのホーム・ページには、そのインスタンスのメトリックが表示されます。たとえば、パフォーマンス、負荷、セキュリティ、レスポンス、CPU使用率、メモリー使用率などです。
Oracle Identity Management 11gインストーラを使用してOracle Internet Directoryのインストールを実行した場合、インストーラによってそのOracle Internet Directoryインスタンスに割り当てられるデフォルトのコンポーネント名は「oid1」です。このコンポーネント名は変更できません。
このOracle Internet Directoryインスタンスのインスタンス固有構成エントリは、「cn=oid1, cn=osdldapd, cn=subconfigsubentry」です。
別のコンピュータ上で2回目のOracle Internet Directoryインストールを実行した場合に、そのOracle Internet Directoryインスタンスが1つ目のインスタンスと同じデータベースを使用する場合、インストーラは、同じOracleデータベースを使用する他方のコンピュータ上のインストール済Oracle Internet Directoryインスタンスを検知するため、2つ目のOracle Internet Directoryインスタンスには「oid2」というコンポーネント名を割り当てます。
2つ目のOracle Internet Directoryインスタンスのインスタンス固有構成エントリは、「cn=oid2, cn=osdldapd, cn=subconfigsubentry」です。cn=oid2, cn=osdldapd, cn=subconfigsubentryというエントリでプロパティを変更しても、1つ目のインスタンス(oid1)は影響を受けません。
別のコンピュータ上で3回目のOracle Internet Directoryインストールを実行した場合に、そのインスタンスが1つ目と2つ目のインスタンスと同じデータベースを使用する場合、インストーラは、3つ目のOracle Internet Directoryインスタンスに「oid3」というコンポーネント名を割り当てます。同様に、同じデータベースを使用する別のホスト上の追加のインスタンスにも、この規則に従って順番にコンポーネント名が割り当てられます。
すべてのOracle Internet Directoryインスタンスの共有構成は、「cn=dsaconfig, cn=configsets,cn=oracle internet directory」です。このエントリでの変更は、Oracle Internet Directoryのすべてのインスタンスに影響します。
この命名規則では、Oracle Internet Directoryインスタンスごとに異なるコンポーネント名が割り当てられるため、Oracle Enterprise Managerを使用してドメインを表示する際に混乱が避けられます。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、次のようにOracle Virtual Directoryを監視できます。
アイデンティティ管理ドメインのファームのホーム・ページで、Fusion Middlewareの円グラフを表示します。このグラフには、Oracle Fusion Middlewareの各コンポーネントのステータスが表示されます。グラフの緑色の部分は、起動され正常に実行されているコンポーネントを示し、赤色の部分は、起動されていないコンポーネントを示しています。
グラフの下の「Identity and Access」セクションには、Oracle Virtual Directoryアプリケーションの各インスタンスの名前(例: ovd1、ovd2)、そのステータスおよびホスト名が表示されます。「ステータス」列の緑の矢印は、そのOracle Virtual Directoryインスタンスが正常に稼働していることを示し、赤い矢印はそのインスタンスが停止していることを示します。個別のOracle Virtual Directoryインスタンスの名前をクリックすると、そのインスタンスのホーム・ページが表示されます。
インスタンスのホーム・ページには、そのインスタンスの次のようなメトリックや構成が表示されます。
Oracle Virtual Directoryのステータス: ページ上部のOracle Virtual Directoryインスタンス名の横に表示される緑の矢印は、そのインスタンスが正常に稼働していることを示し、赤い矢印はそのインスタンスが停止していることを示します。
現行ロード: このOracle Virtual Directoryのインスタンスの現在の作業負荷を示します。ここには、「オープン接続」、「個別に接続しているユーザー」および「個別に接続されたIPアドレス」の3種類のメトリックが示されます。
平均レスポンス時間メトリック: ここには、LDAP検索リクエストを完了するのにかかる平均時間(ミリ秒単位)が表示されます。
操作メトリック: ここには、終了したLDAP検索リクエストにおけるミリ秒当たりの平均数が表示されます。
リスナー: この表には、クライアントにサービスを提供するためにそのOracle Virtual Directoryインスタンス用に構成されたリスナーが一覧表示されます。
アダプタ: この表には、そのOracle Virtual Directoryインスタンスとともに構成された既存のアダプタが一覧表示されます。Oracle Virtual Directoryは、アダプタを使用して各種の基盤データ・リポジトリに接続します。
リソース使用率: ページの右側にCPUとメモリーの使用率メトリックが表示され、そのOracle Virtual Directoryインスタンスによって使用されているシステム・リソースが示されます。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、次のようにOracle Directory Integration Platformを監視できます。
アイデンティティ管理ドメインのファームのホーム・ページで、Fusion Middlewareの円グラフを表示します。このグラフには、Oracle Fusion Middlewareの各コンポーネントのステータスが表示されます。グラフの緑色の部分は、起動され正常に実行されているコンポーネントを示し、赤色の部分は、起動されていないコンポーネントを示しています。
グラフの下の「Identity and Access」セクションには、Oracle Directory Integration Platformアプリケーションの各インスタンスの名前(すべて「DIP (11.1.1.1.0)」という名前)、そのステータスおよびホスト名が表示されます。それぞれのOracle Directory Integration Platformインスタンスは、異なる管理対象サーバーにデプロイされています。「ステータス」列の緑の矢印は、そのOracle Directory Integration Platformインスタンスが正常に稼働していることを示し、赤い矢印はそのインスタンスが停止していることを示します。個別のOracle Directory Integration Platformインスタンスの名前をクリックすると、そのインスタンスのホーム・ページが表示されます。
インスタンスのホーム・ページには、そのインスタンスの次のようなメトリックが表示されます。
Oracle Directory Integration Platformのステータス: ページ上部のOracle Directory Integration Platformインスタンス名の横に表示される緑の矢印は、そのインスタンスが正常に稼働していることを示し、赤い矢印はそのインスタンスが停止していることを示します。
DIPコンポーネント・ステータス: この表には次のメトリックが含まれています。
クォーツ・スケジューラ: ここには、タスクを同期向けにスケジュール設定できるかどうかが示されます。緑の矢印は、そのスケジューラが稼働していることを示し、赤い矢印はそのスケジューラが停止していることを示します。
MBean: ここには、ユーザーがプロファイル管理を実行できるかどうかが示されます。緑の矢印は、プロファイル管理を実行できることを示し、赤い矢印はプロファイル管理を実行できないことを示します。
同期プロファイル: ここには、登録済プロファイルとそれらの実行ステータスが表示されます。高可用性デプロイメントでは、すべてのインスタンスでプロファイルの同じリストが表示されます。
プロビジョニング・プロファイル: ここには、登録済プロビジョニング・プロファイルとそれらの実行ステータスが表示されます。高可用性デプロイメントでは、すべてのインスタンスでプロファイルの同じリストが表示されます。
リソース使用率: ページの右側にはCPUとメモリーの使用率メトリックが表示され、そのOracle Directory Integration Platformインスタンスによるリソース使用率が示されます。
Oracle Enterprise Manager Fusion Middleware Controlを使用すると、管理対象サーバーおよび、Oracle Access Manager、Oracle Identity Manager、SOA、Oracle Identity Federationなど他のFusion Middlewareコンポーネントを監視できます。詳細は、「関連ドキュメント」の「はじめに」で一覧表示されている各管理者ガイドを参照してください。
このマニュアルで取り上げている参照エンタープライズ・トポロジはきわめてスケーラブルです。スケール・アップもスケール・アウトも可能です。トポロジをスケール・アップすると、すでに1つ以上のサーバー・インスタンスを実行しているノードに新しいサーバー・インスタンスが追加されます。トポロジをスケール・アウトすると、新しいノードに新しいサーバーが追加されます。
この項の内容は次のとおりです。
このガイドで説明しているOracle Identity Managementトポロジには、ディレクトリ層、アプリケーション層およびWeb層という3つの層があります。すでに1つ以上のサーバー・インスタンスが実行されているノードに新しいサーバー・インスタンスを追加することで、3つすべての層内のコンポーネントをスケール・アップできます。
この項で説明する手順では、管理対象サーバーまたは管理対象ディレクトリの新しいインスタンスを作成する方法を示します。新しい管理対象サーバーを追加する場合は、その管理対象サーバーを追加した後で、Oracle HTTP Serverの構成ファイルをすべてのノードで更新し、既存のWebLogicクラスタ・ディレクティブにその新しいサーバーを追加する必要があります。
たとえば、新しいOracle Access Managerサーバーを追加する場合は、その新しい管理対象サーバーが含まれるようにoam.confを更新する必要があります。
次のようにoam.confを更新します。
<Location /oam>
SetHandler weblogic-handler
WebLogicCluster
idmhost1.mycompany.com:14100,idmhost2.mycompany.com:14100,idmhost3.mycompany.com:14100
</Location>
oam.confを更新した後、第21.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってOracle HTTPサーバーを再起動します。サービスの損失を防止するために、これを1つずつ順番に実施することをお薦めします。
ディレクトリ層は、2つのOracle Internet Directoryノード(OIDHOST1とOIDHOST2)および2つのOracle Virtual Directoryノード(OVDHOST1とOVDHOST2)で構成されます。これらのOracle Internet Directoryノードでは、それぞれでOracle Internet Directoryのインスタンスを実行し、Oracle Virtual Directoryノードでは、それぞれでOracle Virtual Directoryのインスタンスを実行しています。このOracle Internet DirectoryインスタンスまたはOracle Virtual Directoryインスタンスは、いずれかのノードまたは両方のノードでスケール・アップできます。
ディレクトリ層には2つのOracle Internet Directoryノード(OIDHOST1とOIDHOST2)があり、それぞれでOracle Internet Directoryのインスタンスを実行しています。Oracle Internet Directoryの新しいインスタンスを作成するために、いずれかのノードにある既存のOracle Identity Managementバイナリを使用できます。
新しいOracle Internet DirectoryインスタンスをどちらかのOracle Internet Directoryノードに追加するには、第7.3.2項「追加のOracle Internet Directoryインスタンスの構成」の手順に加えて、次の指示に従ってください。
手順2と手順4では、389と636以外のポートを選択します。これらのポートは、ノード上の既存のOracle Internet Directoryインスタンスによって使用されているからです。
第7.4.1項「WebLogicサーバー・ドメインへのOracle Internet Directoryの登録」の手順に従って、新しいOracle Internet DirectoryインスタンスをWebLogicドメインに登録します。新しいOracle Internet Directoryインスタンスの場所をORACLE_INSTANCEの値として使用します。
新しいOracle Internet Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。
このトポロジでシングル・サインオンを有効にしている場合は、第20.5項「Webゲートのインストールと構成」の手順に従い、シングル・サインオンのWeb層構成を更新する必要があります。
第6.10項「WebLogic ServerへのOracle HTTP Serverの登録」の手順に従い、Oracle HTTP Serverの新しいインスタンスを登録します。
ディレクトリ層には2つのノード(OVDHOST1とOVDHOST2)があり、それぞれでOracle Virtual Directoryのインスタンスを実行しています。Oracle Virtual Directoryの新しいインスタンスを作成するために、いずれかのノードにある既存のOracle Identity Managementバイナリを使用できます。
いずれかのOracle Virtual DirectoryノードにOracle Virtual Directoryの新しいインスタンスを追加するには、第9.3.2項「追加のOracle Virtual Directoryの構成」の手順に従います。ただし、次の点が異なります。
手順2と手順4では、6501と7501以外のポートを選択します。これらのポートは、ノード上の既存のOracle Virtual Directoryインスタンスによって使用されているからです。
次の各項の手順に従って、WebLogicドメインにOracle Virtual Directoryの新しいインスタンスを登録します。新しいOracle Virtual Directoryインスタンスの場所をORACLE_INSTANCEの値として使用します。
新しいOracle Virtual Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。
アプリケーション層は、インストールされている製品に応じて、対になっているいくつかのノードで構成されます。これらのアプリケーション・サーバーでは、Oracle Directory Services(OID/OVD)、Oracle HTTP ServerまたはWebLogic管理対象サーバーを実行します。
この項で説明する手順では、新しいWebLogic管理対象サーバーを作成する方法を示します。トポロジに新しい管理対象サーバーを追加する場合は、その管理対象サーバーを追加した後で、Oracle HTTP Serverの構成ファイルをすべてのノードで更新し、既存のWebLogicクラスタ・ディレクティブにその新しいサーバーを追加する必要があります。
たとえば、新しいOracle Access Managerサーバーを追加する場合は、その新しい管理対象サーバーが含まれるようにoam.confを更新する必要があります。
次のようにoam.confを更新します。
<Location /oam>
SetHandler weblogic-handler
WebLogicCluster
idmhost1.mycompany.com:14100,idmhost2.mycompany.com:14100,idmhost3.mycompany.com:14100
</Location>
oam.confを更新した後、第21.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってOracle HTTPサーバーを再起動します。サービスの損失を防止するために、これを1つずつ順番に実施することをお薦めします。
アプリケーション層には、Oracle Directory Integration PlatformおよびOracle Directory Services Managerのコンポーネントとともに構成された管理対象サーバーが実行されているノード(IDMHOST2)がすでに存在します。このノードには、ローカル・ディスク上のOracle Fusion Middleware Identity ManagementホームとWebLogic Serverホームが含まれています。
既存のインストール内容(WebLogic Serverホーム、Oracle Fusion Middlewareホームおよびドメイン・ディレクトリ)を使用して、Oracle Directory Integration PlatformとOracle Directory Services Managerのコンポーネント用の新しい管理対象サーバーを作成できます。
第8.2項「Oracle Directory Integration PlatformとODSMクラスタの拡張」の手順に従います。
ポートには、すでに使用されている7499以外のポートを選択します。
新しい管理対象サーバーとともにOracle HTTP Serverモジュールを再構成します。第5章「Web層の構成」の手順に従ってこのタスクを完了します。
次の手順でOracle Access Managerをスケール・アップします。
http://admin.mycompany.com/consoleでOracle WebLogic Server管理コンソールにログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「ロックして編集」を「チェンジ・センター」メニューでクリックします。
拡張するホスト上の既存サーバーを選択します(例: WLS_OAM1)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。
サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新しく作成したサーバーWLS_OAM3をクリックします。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。OAMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名検証を無効にする手順は次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
Oracle Access Managerに新しい管理対象サーバーを登録します。この時点で、新しい管理対象サーバーをOracle Access Managerサーバーとして構成する必要があります。Oracle OAMコンソールでこれを行います。次のように実行します。
http://admin.mycompany.com/oamconsoleでOAMコンソールにoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「作成」を「アクション」メニューで選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行するホスト。
ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポートです。
OAMプロキシ・ポート: Oracle Access Managerプロキシの実行対象とするポート。これは当該ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: 既存のOracle Access Managerサーバーが動作しているモードに応じて、「オープン」または「簡易」を選択します。
「コヒーレンス」タブをクリックします。
ホストで一意な値に「ローカル・ポート」を設定します。
「適用」をクリックします。
第21.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。
新しく作成したOracle Access Managerサーバーを使用する可能性のあるすべてのWebゲート・プロファイル(Webgate_IDMやIAMSuiteAgent)にそのサーバーを追加します。
たとえば、Webgate_IDMにOracle Access Managerサーバーを追加するには、http://admin.mycompany.com/oamconsoleのOAMコンソールにアクセスして次の手順に従います。
第11.4.2項「Oracle Access Manager用のユーザーとグループの作成」で作成した、Oracle Access Managerの管理ユーザーとしてログインします。
「システム構成」タブをクリックします。
「Access Managerの設定」→「SSOエージェント」→「OAMエージェント」を開きます。
フォルダを開くアイコンをクリックして「検索」をクリックします。
Webゲート・エージェントWebgate_IDMが表示されます。
エージェントWebgate_IDMをクリックします。
「アクション」メニューで「編集」を選択します。
「プライマリ・サーバー」リスト(これがセカンダリ・サーバーである場合は「セカンダリ・サーバー」リスト)で「+」をクリックします。
新しく作成した管理対象サーバーを「サーバー」ドロップダウン・リストで選択します。
「最大接続数」を4に設定します。
「適用」をクリックします。
IAMSuiteAgentおよび、使用している可能性のあるその他すべてのWebゲートで、手順5～10を繰り返します。
Web層を更新します。新しい管理対象サーバーが作成され、起動されると、Web層から各種の要求がそのサーバーに送られるようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。
このためには、各Web層のOAM.confファイルを更新します。このファイルは、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>
このファイルを保存し、第21.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってOracle HTTP Serverを再起動します。
これで第21.1項「Oracle Identity Managementコンポーネントの起動と停止」の手順に従い、新しい管理対象サーバーを起動できるようになります。
OAAMをスケール・アップするには、OAAMサーバーとOAAM管理サーバーの両方について同じ手順を実行します。
http://admin.mycompany.com/consoleでOracle WebLogic Serverコンソールにログインします。次のように実行します。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「ロックして編集」を「チェンジ・センター」メニューでクリックします。
拡張するホスト上の既存サーバーを選択します(例: WLS_OAAM1やWLS_OAAM_ADMIN1)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です(例: WLS_OAAM3)。
サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新規作成サーバーの「WLS_OAAM3」をクリックします。
SSLリスニング・ポートを設定します。管理対象サーバーを実行しているホスト上で一意にする必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。OAAMHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名検証を無効にする手順は次のとおりです。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「環境」ノードを「ドメイン構造」ペインで開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
この時点で、新しい管理対象サーバーをOracle Access Managerサーバーとして構成する必要があります。Oracle OAMコンソールでこれを行います。次のように実行します。
http://admin.mycompany.com/oamconsoleでOAMコンソールにoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「作成」を「アクション」メニューで選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行しているホスト。
ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポート。
OAMプロキシ・ポート: Oracle Access Managerプロキシの実行対象とするポート。これは各ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: オープン
「適用」をクリックします。
「コヒーレンス」タブをクリックします。
ホストで一意な値に「ローカル・ポート」を設定します。
「適用」をクリックします。
これでOracle Access Managerサーバーを起動できます。ただし、サーバーを使用するには、それが存在していることをすべてのWebゲートに通知する必要があります。この操作は次のように実行します。
http://admin.mycompany.com/oamconsoleでOAMコンソールにoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「エージェント」→「OAMエージェント」→「10gエージェント」を開きます。
変更するWebゲートをダブルクリックします。
「+」をクリックして、新しいサーバーを「プライマリ・サーバー」リストまたは「セカンダリ・サーバー」リストに追加します。
サーバー名をリストから選択します。
「適用」をクリックします。
このケースでは、SOAコンポーネントとともに構成された管理対象サーバーが実行されているノードがすでに存在しています。このノードには、既存の管理対象サーバー用のミドルウェア・ホーム、Oracleホーム(SOA)およびドメイン・ディレクトリが含まれています。
既存のインストール内容(ミドルウェア・ホームおよびドメイン・ディレクトリ)を使用して、新しいWLS_OIMサーバーとWLS_SOAサーバーを作成できます。Oracle Identity ManagerとOracle SOA Suiteのバイナリを新しい場所にインストールしたり、パックと解凍を実行したりする必要はありません。
次の手順に従って、トポロジをスケール・アップします。
管理コンソールを使用して、WLS_OIM1またはWLS_SOA1をクローニングして新しい管理対象サーバーを作成します。クローニング元となるソース管理対象サーバーは、新しい管理対象サーバーを実行するノード上にすでに存在している必要があります。
管理対象サーバーをクローニングする手順は次のとおりです。
管理コンソールで「環境」→「サーバー」を選択します。
「チェンジ・センター」メニューで「ロックして編集」をクリックします。
クローニングする管理対象サーバーを選択します(例: WLS_OIM1やWLS_SOA1)。
「クローンの作成」を選択します。
新しい管理対象サーバーに、WLS_OIMnまたはWLS_SOAnという名前を付けます。nには、新しい管理対象サーバーを識別するための番号を指定します。
残りの手順では、WLS_SOA1とWLS_OIM1がすでに実行されているOIMHOST1に新しいサーバーを追加することを前提にしています。
リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPアドレスを割り当てます。このサーバーでお薦めしているサーバー移行を実行する予定の場合は、別のノードへの移動を可能にするために、このアドレスはVIP(別称: 浮動IP)である必要があります。このVIPは、すでに実行されている管理対象サーバーで使用されているものとは異なっている必要があります。
新しい管理対象サーバー上に、SOA、Oracle Identity Manager、UMSおよびBPMそれぞれのJMSサーバーを作成します。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成して名前を付けます(例: SOAJMSFileStore_N)。ストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。
|
注意: このディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。 |
ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/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を作成します。ストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。
新しいUMSJMSServerの新しい永続ストアを作成します。たとえば、UMSJMSFileStore_Nを作成します。そして、このストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_N.
|
注意: このディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。新しいUMS JMSサーバーのストアとして |
UMS用の新しいJMSサーバーを作成します。たとえば、UMSJMSServer_Nを作成します。このJMSサーバーに対して、UMSJMSFileStore_Nを使用します。UMSJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいOIMJMSServerの新しい永続ストアを作成します。たとえば、OIMJMSFileStore_Nを作成します。そして、このストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_N
|
注意: このディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。Oracle Identity Managerの新しいJMSサーバーのストアとして |
Oracle Identity Managerの新しいJMSサーバーを作成します。たとえば、OIMJMSServer_Nを作成します。このJMSサーバーに対して、OIMJMSFileStore_Nを使用します。OIMJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_OIMn)を指定します。
SOA JMSモジュールのSubDeploymentターゲットを更新して、先ほど作成したSOA JMSサーバーを含めます。このためには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、 |
「SOAJMSServerXXXXXX」サブデプロイメントをクリックします。SOAの新しいJMSサーバーであるSOAJMSServer_Nをこのサブデプロイメントに追加します。「保存」をクリックします。
UMSJMSSystemResourceのSubDeploymentターゲットを更新して、先ほど作成したUMS用JMSサーバーを含めます。このためには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、 |
「UMSJMSServerXXXXXX」サブデプロイメントをクリックします。UMSの新しいJMSサーバーであるUMSJMSServer_Nをこのサブデプロイメントに追加します。「保存」をクリックします。
新たに作成されたBPM JMSサーバーが含まれるように、BPMJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。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」サブデプロイメントをクリックします。Oracle Identity Managerの新しいJMSサーバーであるOIMJMSServer_Nをこのサブデプロイメントに追加します。「保存」をクリックします。
第15.6.1項「SOA管理対象サーバーのコヒーレンス構成の更新」の説明に従って、Oracle Coherenceを構成します。
新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。
管理コンソールで、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の下の「ディレクトリ」に、デフォルト永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOAn管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。SOAHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。
ホスト名検証を無効にする手順は次のとおりです。
Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウで「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
WLS_OIMnの各管理対象サーバーでも、手順6a～6hを繰り返してホスト名検証を無効にします。手順6dでは、表の「名前」列で「WLS_OIMn」を選択します。
「チェンジ・センター」で「変更のアクティブ化」をクリックします。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAのホストとポートを更新します。次の手順に従います。
ブラウザを開いて、http://admin.mycompany.com/emのOracle Enterprise Manager Fusion Middleware Controlに移動します。
管理ユーザー資格証明を使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。
|
注意: 前述の手順を実行する際に、1つ以上のOracle Identity Manager管理対象サーバーを実行している必要があります。 |
「Identity and Access」→「oim」に移動します。
「oim」を右クリックして「システムMBeanブラウザ」に移動します。
「アプリケーション定義のMBean」で、「oracle.iam」→「アプリケーション: oim」→「XMLConfig」→「構成」→「XMLConfig.SOAConfig」→「SOAConfig」に移動します。
新しいSOAサーバーのホストとポートでRmiurl属性の値を更新します。「適用」をクリックして、変更を保存します。
Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBにアクセスするために使用されます。これがアプリケーション・サーバーのURLです。Oracle Identity Managerのクラスタ化デプロイメントの場合は、すべてのSOA管理対象サーバーURLのカンマ区切りのリストです。次はこの属性の値の例です。
t3://oimhost1.mycompany.com:8001,oimhost2.mycompany.com:8001,oimhost3.mycompany.com:8001
第21.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。
管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーを停止します。
新規作成した管理対象サーバーであるWLS_SOAnが稼働していることを確認します。
新しく作成した管理対象サーバー(http://vip:port/soa-infra)上のアプリケーションにアクセスします。アプリケーションは機能している必要があります。
新しく作成した管理対象サーバーを、サーバー移行ができるように構成します。第18.5項「サーバー移行ターゲットの構成」の手順に従って、サーバー移行を構成します。
この新規サーバーのサーバー移行をテストします。新規サーバーの追加先となったノードで、次の手順を実行します。
管理対象サーバーWLS_SOAnを停止します。
このためには、次のコマンドを実行します。
kill -9 pid
このコマンドでは、その管理対象サーバーのプロセスID(PID)を指定します。ノードのPIDを確認するには、次のコマンドを使用します。
ps -ef | grep WLS_SOAn
ノード・マネージャ・コンソールを参照します。WLS_SOA1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待ちます。これを再起動する前に、分離するまでノード・マネージャで30秒待ちます。
ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。
アプリケーション層には、Oracle Identity Federationを使用して構成した管理対象サーバーを実行しているノード(OIFHOST2)がすでに存在します。このノードには、ローカル・ディスク上のOracle Fusion Middleware Identity ManagementホームとWebLogic Serverホームが含まれています。
既存のインストール内容(WebLogic Serverホーム、Oracle Fusion Middlewareホームおよびドメイン・ディレクトリ)を使用して、Oracle Identity Federationの新しい管理対象サーバーを作成できます。
第16.3項「OIFHOST2におけるOracle Identity Federationの構成」の手順に従って、Oracle Identity Federationのトポロジをスケール・アップします。
ポートには、すでに使用されている7499以外のポートを選択します。
第16.4項「管理対象サーバーのローカル・ディスクへのプロビジョニング」の手順に従って、ローカル・ディスク上でOracle Identity Federationの新しい管理対象サーバーをプロビジョニングします。
新しい管理対象サーバーとともにOracle HTTP Serverモジュールを再構成します。第5章「Web層の構成」の手順に従ってこのタスクを完了します。
Web層には、Oracle HTTP Serverのインスタンスが実行されている1つのノードがすでにあります。既存のOracle HTTP Serverバイナリを使用して、新しいOracle HTTP Serverインスタンスを作成できます。Oracle HTTP Serverをスケール・アップするには、第5章「Web層の構成」の手順を実行します。
第5章「Web層の構成」の説明に従い、Oracle Fusion Middleware 11gのWeb層ユーティリティ構成ウィザードを使用してトポロジをスケール・アップします。
既存のWeb層構成のORACLE_INSTANCE/config/OHS/component/moduleconf内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。
第6.10項「WebLogic ServerへのOracle HTTP Serverの登録」の説明に従って、Oracle HTTP Serverの新しいインスタンスを登録します。
新しいOracle HTTP Serverインスタンスのホスト情報とポート情報に基づいてロード・バランサを再構成します。
トポロジをスケール・アウトする際は、新しいサーバーを新しいノードに追加します。このマニュアルで説明しているOracle Identity Managementトポロジの3つすべての層内のコンポーネントは、新しいノードに新しいサーバー・インスタンスを追加することでスケール・アウトできます。
ディレクトリ層は、2つのOracle Internet Directoryノード(OIDHOST1とOIDHOST2)および2つのOracle Virtual Directoryノード(OVDHOST1とOVDHOST2)で構成されます。これらのOracle Internet Directoryノードでは、それぞれでOracle Internet Directoryのインスタンスを実行し、Oracle Virtual Directoryノードでは、それぞれでOracle Virtual Directoryのインスタンスを実行しています。ディレクトリ層に新しいノードを追加することで、Oracle Internet DirectoryのインスタンスまたはOracle Virtual Directoryのインスタンスをスケール・アウトできます。
ディレクトリ層には2つのOracle Internet Directoryノード(OIDHOST1とOIDHOST2)があり、それぞれでOracle Internet Directoryのインスタンスを実行しています。既存のOracle Internet Directoryクラスタに新しいノードを追加することで、Oracle Internet Directoryのインスタンスをスケール・アウトできます。Oracle Internet Directoryのインスタンスをスケール・アウトする手順は次のとおりです。
第7.3.2項「追加のOracle Internet Directoryインスタンスの構成」の手順に従って、Oracle Internet Directoryを実行する新しいノードを追加します。
第7.4.1項「WebLogicサーバー・ドメインへのOracle Internet Directoryの登録」の手順に従って、新しいOracle Internet DirectoryインスタンスをWebLogicドメインに登録します。
新しいインスタンスのSSLサーバー認証モードを構成します。
新しいOracle Internet Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。
ディレクトリ層には2つのノード(OVDHOST1とOVDHOST2)があり、それぞれでOracle Virtual Directoryのインスタンスを実行しています。Oracle Virtual Directoryを実行するように構成した新しいノードをディレクトリ層に追加することで、Oracle Virtual Directoryをスケール・アウトできます。Oracle Virtual Directoryのインスタンスをスケール・アウトする手順は次のとおりです。
第9.3.2項「追加のOracle Virtual Directoryインスタンスの構成」の手順に従って、Oracle Virtual Directoryを実行する新しいノードを追加します。
次の各項の手順に従って、WebLogicドメインにOracle Virtual Directoryの新しいインスタンスを登録します。
新しいOracle Virtual Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。
アプリケーション層には、Oracle Directory Integration PlatformとOracle Directory Services Managerの管理対象サーバーを実行している2つのノード(IDMHOST1とIDMHOST2)およびOracle Access Managerサーバーを実行している2つのノード(OAMHOST1とOAMHOST2)があります。
この項で説明する手順では、新しいWebLogic管理対象サーバーを作成する方法を示します。トポロジに新しい管理対象サーバーを追加する場合は、その管理対象サーバーを追加した後で、Oracle HTTP Serverの構成ファイルをすべてのノードで更新し、既存のWebLogicクラスタ・ディレクティブにその新しいサーバーを追加する必要があります。
たとえば、新しいOracle Access Managerサーバーを追加する場合は、その新しい管理対象サーバーが含まれるようにoam.confを更新する必要があります。
次のようにoam.confを更新します。
<Location /oam>
SetHandler weblogic-handler
WebLogicCluster
idmhost1.mycompany.com:14100,idmhost2.mycompany.com:14100,idmhost3.mycompany.com:14100
</Location>
oam.confを更新した後、第21.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってOracle HTTPサーバーを再起動します。サービスの損失を防止するために、これを1つずつ順番に実施することをお薦めします。
アプリケーション層には、Oracle Identity Federationを使用して構成した管理対象サーバーを実行している2つのノード(OIFHOST1とOIFHOST2)があります。管理対象サーバーを持つ新しいノードを既存のクラスタに追加することで、Oracle Identity Federationのインスタンスをスケール・アウトできます。
新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやIdentity Managementのバイナリをインストールする必要はありませんが、新しいノードでドメイン構成をブートストラップするためにパックと解凍を実行する必要があります。
Oracle Identity Federationのインスタンスをスケール・アウトする手順は次のとおりです。
次の各項の手順に従って、トポロジの中でOracle Identity Federationインスタンスをスケール・アウトします。
第16.8項「Oracle Web Tierと連携するためのOracle Identity Federationの構成」の手順に従って、新しく追加した管理対象サーバーのホスト名とポートをWebLogicClusterパラメータのリストに追加します。
アプリケーション層には、Oracle Directory Integration PlatformとOracle Directory Services Managerとともに構成された管理対象サーバーが実行されている2つのノード(IDMHOST1とIDMHOST2)がすでに存在します。Oracle Directory Integration PlatformとOracle Directory Services Managerのインスタンスは、管理対象サーバーが配置された新しいノードを既存のクラスタに追加することでスケール・アウトできます。
新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやIdentity Managementのバイナリをインストールする必要はありませんが、新しいノードでドメイン構成をブートストラップするためにパックと解凍を実行する必要があります。
DIPとODSMのインスタンスをスケール・アウトするには、次の手順を実行します。
第8.2項「Oracle Directory Integration PlatformとODSMクラスタの拡張」の手順に従って、トポロジ内のOracle Directory Integration PlatformインスタンスとOracle Directory Services Managerインスタンスをスケール・アウトします。
新しい管理対象サーバーとともにOracle HTTP Serverモジュールを再構成します。
第8.4項「Oracle Web層と連携するためのODSMの構成」の手順に従って、このタスクを完了します。
新たに追加した管理対象サーバーのホスト名とポートをWebLogicClusterパラメータリストに追加します。
スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。
新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやIdentity Managementのバイナリをインストールする必要はありませんが、新しいノードでドメイン構成をブートストラップするためにパックと解凍を実行する必要があります。
|
注意: 共有記憶域を使用している場合は、その共有記憶域に新しいホストがアクセスできるようにします。 |
新しいノードで、SOAのインストール内容とドメイン・ディレクトリが含まれている既存のミドルウェア・ホームをマウントして、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
ミドルウェア・ホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成して(別のWebLogicがそのノードにインストールされている場合は編集します)、ORACLE_BASE/product/fmwをこのファイルに追加します。
http://admin.mycompany.com/consoleでOracle WebLogic Server管理コンソールにログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「ロックして編集」を「チェンジ・センター」メニューでクリックします。
拡張するホスト上の既存サーバーを選択します(例: WLS_OAM1)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。
サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新規作成したサーバーである「WLS_OAM3」をクリックします。
SSLリスニング・ポートを設定します。このポートは、管理対象サーバーが実行されるホスト上で一意である必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。IDMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名の検証を無効化する手順は、次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
「環境」ノードを「ドメイン構造」ペインで開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
第21.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。
次のコマンドを使用してIDMHOST1上のドメインをパックします。
pack.sh -domain=ORACLE_BASE/admin/IDMDomain/aserver/IDMDomain -template =/tmp/IDMDomain.jar -template_name="OAM Domain" -managed=true
pack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
次のコマンドを使用して新しいホスト上でドメインを解凍します。
unpack.sh -domain=ORACLE_BASE/admin/IDMDomain/mserver/IDMDomain -template=/tmp/IDMDomain.jar -app_dir=ORACLE_BASE/admin/IDMDomain/mserver/applications
unpack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
ノード・マネージャを起動して、プロパティ・ファイルを更新します。
第21.1項「Oracle Identity Managementコンポーネントの起動と停止」の手順に従い、ノード・マネージャを起動および停止します。
ORACLE_COMMON_HOME/common/binにあるスクリプトsetNMProps.shを実行して、ノード・マネージャのプロパティ・ファイルを更新します。たとえば、次のように指定します。
cd ORACLE_COMMON_HOME/common/bin ./setNMProps.sh
第21.1項「Oracle Identity Managementコンポーネントの起動と停止」の手順に従い、ノード・マネージャを再度起動します。
Oracle Access Managerに新しい管理対象サーバーを登録します。この時点で、新しい管理対象サーバーをOracle Access Managerサーバーとして構成する必要があります。このためには、Oracle OAMコンソールで次の手順を実行します。
http://admin.mycompany.com/oamconsoleで、OAMコンソールにoamadminユーザーとしてログインします。
「システム構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「作成」を「アクション」メニューで選択します。
次の情報を入力します。
サーバー名: WLS_OAM3
ホスト: サーバーを実行しているホストIDMHOST3。
ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポート。
OAMプロキシ・ポート: Oracle Access Managerプロキシの実行対象とするポート。これは当該ホストについて一意のポートです。
プロキシ・サーバーID: AccessServerConfigProxy
モード: 既存のOracle Access Managerサーバーが動作しているモードに応じて、「オープン」または「簡易」を選択します。
「適用」をクリックします。
新しく作成したOracle Access Managerサーバーを使用する可能性のあるすべてのWebゲート・プロファイル(Webgate_IDMやIAMSuiteAgent)にそのサーバーを追加します。
たとえば、Webgate_IDMにOracle Access Managerサーバーを追加するには、http://admin.mycompany.com/oamconsoleのOAMコンソールにアクセスして次の手順に従います。
1. 第11.4.2項「Oracle Access Manager用のユーザーとグループの作成」で作成したOracle Access Managerの管理ユーザーとしてログインします。
2. 「システム構成」タブをクリックします。
3. 「Access Managerの設定」→「SSOエージェント」→「OAMエージェント」を開きます。
4. フォルダを開くアイコンをクリックして「検索」をクリックします。
Webゲート・エージェントWebgate_IDMが表示されます。
5. エージェント「Webgate_IDM」をクリックします。
6. 「アクション」メニューで「編集」を選択します。
7. 「プライマリ・サーバー」リスト(これがセカンダリ・サーバーである場合は「セカンダリ・サーバー」リスト)で「+」をクリックします。
8. 新しく作成した管理対象サーバーを「サーバー」ドロップダウン・リストで選択します。
9. 「最大接続数」を4に設定します。
10.「適用」をクリックします。
IAMSuiteAgentおよび、使用しているその他すべてのWebゲートで、手順5～10を繰り返します。
Web層を更新します。これで新しい管理対象サーバーが作成され、起動されたので、Web層から各種の要求がそのサーバーに送られるようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。
このためには、各Web層のOAM.confファイルを更新します。このファイルは、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>
スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。
新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやIdentity Managementのバイナリをインストールする必要はありませんが、新しいノードでドメイン構成をブートストラップするためにパックと解凍を実行する必要があります。
次のように実行します。
新しいノードで、SOAのインストール内容とドメイン・ディレクトリが含まれている既存のミドルウェア・ホームをマウントして、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
ミドルウェア・ホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成して(別のWebLogicがそのノードにインストールされている場合は編集します)、ORACLE_BASE/product/fmwをこのファイルに追加します。
http://admin.mycompany.com/consoleでWebLogicコンソールにログインします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
「ロックして編集」を「チェンジ・センター」メニューでクリックします。
拡張するホスト上の既存サーバーを選択します(例: WLS_OAAM1やWLS_OAAM_ADMIN1)。
「クローンの作成」をクリックします。
次の情報を入力します。
サーバー名: サーバーの新しい名前です(例: WLS_OAAM3)。
サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。
サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
「OK」をクリックします。
新規作成サーバーの「WLS_OAAM3」をクリックします。
SSLリスニング・ポートを設定します。管理対象サーバーを実行しているホスト上で一意にする必要があります。
「保存」をクリックします。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。OAAMHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名検証を無効にする手順は次のとおりです。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「環境」ノードを「ドメイン構造」ペインで開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
次のコマンドを使用してIDMHOST1上のドメインをパックします。
pack.sh -domain=ORACLE_BASE/admin/IDMDomain/aserver/IDMDomain -template =/tmp/IDMDomain.jar -template_name="OAAM Domain" -managed=true
pack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
次のコマンドを使用して新しいホスト上でドメインを解凍します。
unpack.sh -domain=ORACLE_BASE/admin/IDMDomain/mserver/IDMDomain -template=/tmp/IDMDomain.jar -template_name="OAAM Domain" -app_dir=ORACLE_BASE/admin/IDMDomain/mserver/applications
unpack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
コンソールから管理対象サーバーを起動する前に、スクリプトsetNMProps.shを実行してOAAMHOST2上にノード・マネージャのプロパティ・ファイルを作成しておく必要があります。setNMProps.shスクリプトは、MW_HOME/oracle_common/common/binにあります。次を入力します。
cd MW_HOME/oracle_common/common/bin
./setNMProps.sh
新しいホストでノード・マネージャと新しい管理対象サーバーを起動します。
これで新しい管理対象サーバーが作成され、起動されたので、Web層から各種の要求がそのサーバーに送られるようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。
このためには、各Web層のoaam.confファイルを更新します。このファイルは、ORACLE_INSTANCE/config/OHS/component_name/moduleconfディレクトリにあります。
新しいサーバーをこのファイル内のWebLogicClusterディレクティブに追加します。次に変更前の例を示します。
<Location /oaam_admin>
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassthrough ON
WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200
</Location>
変更後は次のようになります。
<Location /oaam_admin>
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassthrough ON
WebLogicCluster
oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200,oaamhsot3.mycompany.com:14300
</Location>
トポロジをスケール・アウトする際は、SOAとともに構成された新しい管理対象サーバーを新しいノードに追加します。
この項の手順を実行する前に、次の要件を満たしていることを確認してください。
SOAとともに構成された管理対象サーバーが実行されている既存のノードがトポロジ内に存在していること。
新しいノードがWebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること。
新しい管理対象サーバーWLS_SOAまたはWLS_OIMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやSOAのバイナリをインストールする必要はありませんが、新しいノードでドメイン構成をブートストラップするためにパックと解凍を実行する必要があります。
|
注意:
|
次の手順に従って、トポロジをスケール・アウトします。
新しいノードで、Oracle Fusion Middlewareのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできるようにします。
共有記憶域内のIAM_HOMEをローカルOracleインベントリにアタッチするには、次のコマンドを実行します。
SOAHOSTn> cd ORACLE_BASE/product/fmw/soa/oui/bin SOAHOSTn> ./attachHome.sh -jreLoc JAVA_HOME
ミドルウェア・ホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成して(別のWebLogicがそのノードにインストールされている場合は編集します)、ORACLE_BASE/product/fmwをこのファイルに追加します。
Oracle WebLogic管理コンソールにログインします。
使用する新しいノード用の新しいマシンを作成して、そのマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。
Oracle WebLogic Server管理コンソールを使用して、WLS_SOA1をクローニングして新しい管理対象サーバーを作成します。このサーバーにWLS_SOAnという名前を付けます(nには番号を指定します)。
|
注意: これらの手順では、管理対象サーバーが実行されていないノード |
新しい管理対象サーバー用に使用するホスト名またはIPアドレスを、その管理対象サーバーのリスニング・アドレスとして割り当てます。
このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーのVIPアドレス(別称: 浮動IPアドレス)である必要があります。このVIPアドレスは、既存の管理対象サーバーで使用されているものとは異なっている必要があります。
新しい管理対象サーバー上に、SOA、Oracle Identity Manager(該当する場合)およびUMSのそれぞれのJMSサーバーを作成します。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成して名前を付けます(例: SOAJMSFileStore_N)。ストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。次に例を示します。
ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_N
|
注意: このディレクトリは、管理対象サーバーを起動する前に存在する必要があります。存在しないと、起動操作は失敗します。 |
SOAの新しいJMSサーバーを作成します。たとえば、SOAJMSServer_auto_Nを作成します。このJMSサーバーに対して、SOAJMSFileStore_Nを使用します。SOAJMSServer_auto_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいUMSJMSServer用の新しい永続ストアを作成して、名前を付けます(例: UMSJMSFileStore_N)。ストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_N
|
注意:
|
UMS用の新しいJMSサーバーを作成します。たとえば、UMSJMSServer_Nを作成します。このJMSサーバー用に、UMSJMSFileStore_Nを使用します。UMSJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいBPMJMSServer用の新しい永続ストアを作成して、名前を付けます(例: BPMJMSFileStore_N)。ストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_N
|
注意:
|
BPMの新しいJMSサーバーを作成します。たとえば、BPMJMSServer_Nを作成します。このJMSサーバーに対して、BPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいOIMJMSServer用の新しい永続ストアを作成して、名前を付けます(例: OIMJMSFileStore_N)。ストアのパスを指定します。第2.4項「共有記憶域と推奨ディレクトリ構造」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_N
|
注意:
|
Oracle Identity Managerの新しいJMSサーバーを作成します。たとえば、OIMJMSServer_Nを作成します。このJMSサーバー用に、OIMJMSFileStore_Nを使用します。OIMJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_OIMn)を指定します。
新たに作成されたBPM JMSサーバーが含まれるように、BPMJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「BPMJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。BPMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。BPMJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は、 |
「BPMJMSServerXXXXXX」サブデプロイメントをクリックします。BPMの新しいJMSサーバーであるBPMJMSServer_Nをこのサブデプロイメントに追加します。「保存」をクリックします。
SOA JMSモジュールのSubDeploymentターゲットを更新して、先ほど作成したSOA JMSサーバーを含めます。このためには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。SOAJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュール名は |
「SOAJMSServerXXXXXX」サブデプロイメントをクリックします。SOAの新しいJMSサーバーであるSOAJMSServer_Nをこのサブデプロイメントに追加します。「保存」をクリックします。
UMSJMSSystemResourceのSubDeploymentターゲットを更新して、先ほど作成したUMS用JMSサーバーを含めます。このためには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。UMSJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュールは |
「UMSJMSServerXXXXXX」サブデプロイメントをクリックします。UMSの新しいJMSサーバーであるUMSJMSServer_Nをこのサブデプロイメントに追加します。「保存」をクリックします。
OIMJMSModuleのサブデプロイメント・ターゲットを更新して、先ほど作成したOracle Identity Manager用JMSサーバーを含めます。このためには、「サービス」ノード→「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSModule」(表の「名前」列でハイパーリンクとして表示されています)をクリックします。OIMJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
|
注意: このサブデプロイメント・モジュールは |
「OIMJMSXXXXXX」サブデプロイメントをクリックします。Oracle Identity Managerの新しいJMSサーバーであるOIMJMSServer_Nをこのサブデプロイメントに追加します。「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
次のようにpackコマンドをSOAHOST1上で実行して、テンプレート・パックを作成します。
Prompt> cd ORACLE_COMMON_HOME/common/bin
Prompt> ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
次のコマンドをSOAHOST1上で実行して、作成されたテンプレート・ファイルをSOAHOSTNにコピーします。
Prompt> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ORACLE_BASE/product/fmw/soa/common/bin
次のようにunpackコマンドをSOAHOSTN上で実行して、管理対象サーバーのドメイン・ディレクトリ内にテンプレートを解凍します。
SOAHOSTN> cd ORACLE_BASE/product/fmw/soa/common/bin SOAHOSTN> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar -app_dir=ORACLE_BASE/admin/IDMDomain/mserver/applications
第15.6.1項「SOA管理対象サーバーのコヒーレンス構成の更新」の説明に従って、Oracle Coherenceを構成します。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAのホストとポートを更新します。次の手順に従います。
ブラウザを開き、次のOracle Enterprise Manager Fusion Middleware Controlに移動します。
http://admin.mycompany.com/em
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」に移動します。
新しいSOAサーバーのホストとポートでRmiurl属性の値を更新します。「適用」をクリックして、変更を保存します。
Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBにアクセスするために使用されます。これがアプリケーション・サーバーのURLです。Oracle Identity Managerのクラスタ化デプロイメントの場合は、すべてのSOA管理対象サーバーURLのカンマ区切りのリストです。次はこの属性の値の例です。
t3://oimhost1.mycompany.com:8001
oimhost2.mycompany.com:8001
oimhost3.mycompany.com:8001
新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。
管理コンソールで、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の下の「ディレクトリ」に、デフォルト永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOAn管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。SOAHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。
ホスト名検証を無効にする手順は次のとおりです。
「環境」ノードを「ドメイン構造」ウィンドウで開きます。
Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
新しいノード上でノード・マネージャを起動します。ノード・マネージャを起動するには、既存ノードの共有記憶域内のインストール内容を使用して、次のように新しいノードのホスト名をパラメータとして渡してノード・マネージャを起動します。
SOAHOSTN> WL_HOME/server/bin/startNodeManager new_node_ip
Oracle WebLogic Server管理コンソールから、新しい管理対象サーバーを起動してテストします。
クラスタ内の既存の管理対象サーバーをすべて停止します。
新規作成した管理対象サーバーであるWLS_SOAnが稼働していることを確認します。
新しく作成した管理対象サーバー(http://vip:port/soa-infra)上のアプリケーションにアクセスします。アプリケーションは機能している必要があります。
新しい管理対象サーバーのサーバー移行を構成します。
|
注意: この新しいノードでは既存の共有記憶域のインストール内容が使用されているため、このノードではすでにノード・マネージャが使用されているとともに、ネットマスク、インタフェースおよび |
次の手順に従ってサーバー移行を構成します。
管理コンソールにログインします。
左側のペインで「環境」を開き、「サーバー」を選択します。
移行を構成する対象となるサーバー(ハイパーリンクとして表示)を表の「名前」列から選択します。そのサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を有効にするマシンを選択して、右矢印をクリックします。
|
注意: 新しいサーバーの移行ターゲットとして、最も負荷が小さいマシンを指定してください。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要な容量計画をあらかじめ行ってください。 |
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
この新規サーバーのサーバー移行をテストします。新規サーバーの追加先となったノードで、次の手順を実行します。
1.WLS_SOAn管理対象サーバーを強制的に停止します。
2.このためには、次のコマンドを実行します。
kill -9 pid
このコマンドでは、当該管理対象サーバーのプロセスID(PID)を指定します。ノードのPIDを確認するには、次のコマンドを使用します。
ps -ef | grep WLS_SOAn
3.ノード・マネージャ・コンソールを参照します。WLS_SOA1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。
4.ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待ちます。これを再起動する前に、分離するまでノード・マネージャで30秒待ちます。
5.ノード・マネージャによって再起動されたサーバーを再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。
Web層には2つのノードがあり、それぞれOracle HTTP Serverインスタンスが実行されています。Oracle HTTP Serverを実行するように構成された新しいノードをWeb層に追加することで、Oracle HTTP Serverのコンポーネントをスケール・アウトできます。Oracle HTTP Serverをスケール・アウトするには、次の手順を実行します。
第4.4項「Oracle HTTP Serverのインストール」の手順に従います。共有記憶域を使用している場合は、新しいノード上で既存のMiddlewareホームをマウントする方法もあります。
第5章「Web層の構成」の手順に従います。
既存のWeb層構成のORACLE_INSTANCE/config/OHS/component/moduleconf内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。
このトポロジでシングル・サインオンを有効にしている場合は、第20.5項「Webゲートのインストールと構成」の手順に従い、シングル・サインオンのWeb層構成を更新する必要があります。
第6.10項「WebLogic ServerへのOracle HTTP Serverの登録」の手順に従い、Oracle HTTP Serverの新しいインスタンスを登録します。
新しいOracle HTTP Serverインスタンスのホスト情報とポート情報に基づいてロード・バランサを再構成します。
表21-1には、11g Oracle Identity Managementエンタープライズ・デプロイメントでバックアップする静的アーティファクトを示しています。
表21-1 Identity Managementエンタープライズ・デプロイメントでバックアップする静的アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
Oracleホーム(データベース) |
Oracle RACデータベースのホスト:
|
ユーザー定義 |
ディレクトリ層 |
|
|
|
Middlewareホーム、
Identity Management Oracleホーム、
|
ディレクトリ層 |
|
|
|
Middlewareホーム、
Identity Management Oracleホーム、
|
ディレクトリ層 |
|
|
|
Middleware Oracleホーム、
Identity Management OracleホームDIP/ODSM、
管理サーバーOracleホーム、
|
アプリケーション層 |
|
|
|
Middleware Oracleホーム、
Web Oracleホーム、
Web Oracleホーム、 WEBHOST2における |
Web層 |
|
関連ファイルのインストール |
各ホスト |
OraInventory:
Windowsレジストリ: ( |
対象外 |
表21-2には、11g Oracle Identity Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクトを示しています。
表21-2 Identity Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
ドメイン・ホーム |
|
|
アプリケーション層 |
|
アプリケーション・アーティファクト(earファイルとwarファイル) |
|
WebLogic Server管理コンソールからすべてのデプロイメント(Oracle Directory Integration PlatformとOracle Directory Services Managerを含む)を参照して、すべてのアプリケーション・アーティファクトを特定してください。 |
アプリケーション層 |
|
インスタンス・ホーム(OHS) |
|
|
Web層 |
|
OIDインスタンス・ホーム |
|
ORACLE_BASE/admin/oid_inst1
ORACLE_BASE/admin/oid_inst2 |
ディレクトリ層 |
|
OVDインスタンス・ホーム |
|
|
ディレクトリ層 |
|
Oracle RACデータベース |
|
ユーザー定義 |
ディレクトリ層 |
|
OAM |
|
すべての構成は、この表で示しているそれぞれのホーム・ディレクトリ内にあります。インスタンス・ホームはありません。 |
アプリケーション層 |
Oracle Fusion Middlewareコンポーネントのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
この項では、Oracle Fusion Middlewareのパッチ・ファイルを適用する方法、および最小限の停止時間でOracle Identity Managementコンポーネントにパッチを適用する方法を説明します。
この項の内容は次のとおりです。
Oracle Fusion Middlewareソース・ファイルへのパッチ適用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
最小限の停止時間でOracle Identity Managementコンポーネントにパッチを適用するには、次の指示に従うことをお薦めします。
OIDHOST1とOVDHOST1のLDAPトラフィックをOIDHOST2とOVDHOST2にルーティングします。
パッチを適用する場所となるホスト(OIDHOST1またはOVDHOST1)上のOracle Internet DirectoryサーバーまたはOracle Virtual Directoryサーバーを停止します。
Oracle Internet DirectoryパッチまたはOracle Virtual Directoryパッチをホストで適用します。
Oracle Internet DirectoryまたはOracle Virtual Directoryのサーバーをホストで起動します。
パッチをテストします。
トラフィックを再びOIDHOST1またはOVDHOST1にルーティングします。
アプリケーションが正常に動作していることを確認します。
OIDHOST2とOVDHOST2のLDAPトラフィックをOIDHOST1とOVDHOST1にルーティングします。
パッチを適用する場所となるホスト(OIDHOST2またはOVDHOST2)上のOracle Internet DirectoryサーバーまたはOracle Virtual Directoryサーバーを停止します。
Oracle Internet DirectoryパッチまたはOracle Virtual Directoryパッチをホストで適用します。
Oracle Internet DirectoryまたはOracle Virtual Directoryのサーバーをホストで起動します。
パッチをテストします。
パッチを適用した両方のホスト(OIDHOST1とOIDHOST2、またはOVDHOST1とOVDHOST2)にトラフィックをルーティングします。
この項では、このマニュアルで説明しているIdentity Managementエンタープライズ・デプロイメントで発生する可能性のある一般的な問題のトラブルシューティング方法を説明します。
この項の内容は次のとおりです。
この項では、Oracle Internet Directoryで発生する可能性のある一般的な問題とその解決策を紹介します。
問題
Oracle Internet Directoryサーバーが応答しません。監視のため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
問題
TNSNAMES.ORAやTAFの構成に関連した問題があります。
ソリューション
Oracle Databaseの高可用性の概要に関するマニュアルを参照してください。
この項では、Oracle Virtual Directoryで発生する可能性のある一般的な問題とその解決策を紹介します。
問題
SSLServerConfig.shを実行すると、次のようにcommand not foundエラーが発生します。
./SSLServerConfig.sh: line 169: 20110520125611: command not found
ソリューション
ファイルorapki.bat(Windowsの場合)または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=ovd_inst1,component=ovd1 not found. Use ls(a) to view theattributes
ソリューション
この問題は断続的に発生するものなので、このスクリプトを再実行することで回避できます。
この項では、Oracle Directory Integration Platformで発生する可能性のある一般的な問題とその解決策を紹介します。
問題
インスタンスが正常に動作していません。
ソリューション
インスタンスの個別ログをチェックします。たとえば、WLS_ODS1にデプロイされているインスタンスが動作していない場合は、WLS_ODS1-diagnostic.logファイルをチェックします。
問題
Oracle RACフェイルオーバー時に、Oracle Directory Integration Platformアプリケーションが実行されている管理対象サーバーのログ・ファイルに次のような例外が記録されます。
RuntimeException:
[2008-11-21T00:11:10.915-08:00] [WLS_ODS] [ERROR] []
[org.quartz.impl.jdbcjobstore.JobStoreTX] [tid: 25] [userId: <anonymous>]
[ecid: 0000Hqy69UiFW7V6u3FCEH199aj0000009,0] [APP: DIP] ClusterManager: Error
managing cluster: Failed to obtain DB connection from data source
'schedulerDS': java.sql.SQLException: Could not retrieve datasource via JNDI
url 'jdbc/schedulerDS' java.sql.SQLException: Cannot obtain connection:
driverURL = jdbc:weblogic:pool:schedulerDS, props =
{EmulateTwoPhaseCommit=false, connectionPoolID=schedulerDS,
jdbcTxDataSource=true, LoggingLastResource=false,
dataSourceName=schedulerDS}.[[
Nested Exception: java.lang.RuntimeException: Failed to setAutoCommit to true
for pool connection
AuthenticationException while connecting to OID:
[2008-11-21T00:12:08.812-08:00] [WLS_ODS] [ERROR] [DIP-10581] [oracle.dip]
[tid: 11] [userId: <anonymous>] [ecid: 0000Hqy6m54FW7V6u3FCEH199apO000000,0]
[APP: DIP] DIP was not able to get the context with the given details {0}[[
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
Credentials]
ほとんどの例外は、次の例のようにスケジューラまたはLDAPに関連するものです。
1. 'jdbc/schedulerDS' java.sql.SQLExceptionというJNDI urlを通じてデータソースを取得できませんでした。
2. javax.naming.AuthenticationException: [LDAPエラー・コード49 - 無効な資格証明]
ソリューション
Oracle RACフェイルオーバー時に、Oracle Directory Integration Platformアプリケーションが実行されている管理対象サーバーのログ・ファイルに例外が記録されます。これらのエラーが発生するのは、WebLogic Serverプラットフォーム上で構成されたマルチ・データソースが、フェイルオーバー時にOracle RACデータベース・インスタンスの状態を確認しようとしたときです。これらは無害なエラーであるため、無視してかまいません。Oracle Directory Integration Platformアプリケーションはリカバリして、1～2分後に正常な機能を開始します。Oracle RACフェイルオーバーでは、1つのインスタンスが常に実行状態になっていれば、Oracle Directory Integration Platformに停止時間は発生しません。
この項では、Oracle Directory Services Managerで発生する可能性のある一般的な問題とその解決策を紹介します。
Oracle Directory Services Managerにログインしたら、同じブラウザ・ウィンドウから複数のディレクトリ・インスタンスに接続できます。
同じブラウザ・プログラムの複数のウィンドウを使用して、それぞれ異なるディレクトリに同時に接続することは避けてください。このようにすると、ターゲット到達不能エラーが発生します。
Internet ExplorerやFirefoxなどの様々なブラウザ・プログラムから同じOracle Directory Services Managerインスタンスにログインして、それぞれ別々のディレクトリ・インスタンスに接続できます。
ブラウザの言語設定を変更する場合、新しい設定を使用するにはセッションを更新する必要があります。セッションを更新するには、現在のサーバー接続を切断するか、ブラウザ・ページをリフレッシュして([F5]を押すか、Oracle Directory Services ManagerのURLをURLフィールドに再入力して[Enter]を押します)同じサーバーに再接続するか、またはブラウザを終了してから再起動します。
問題
Oracle Enterprise Manager Fusion Middleware ControlからOracle Directory Services Managerを起動するために、「Oracle Internet Directory」ターゲット内の「Oracle Internet Directory」メニューで「Directory Services Manager」を選択してから、「データ・ブラウザ」、「スキーマ」、「セキュリティ」または「拡張」を選択しました。
しかし、Oracle Directory Services Managerが開きません。場合によっては、エラー・メッセージが表示されます。
ソリューション
これはインストールに問題がある可能性があります。『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
問題
Oracle HTTP Serverを使用してOracle Directory Services Managerフェイルオーバーを実行すると、フェイルオーバーが透過的になりません。次の手順を実行すると、この動作を確認できます。
Oracle HTTP Serverを使用して、高可用性アクティブ/アクティブ構成でOracle Directory Services Managerはデプロイされています。
Oracle HTTP Serverの名前とポート番号を使用して、Oracle Directory Services Managerのページを表示します。
Oracle Internet Directoryサーバーに接続します。
Oracle Directory Services Manager Oracle HTTP Serverの現在のホストとポートを使用して、Oracle Internet Directoryサーバーを操作します。
WebLogic Server管理コンソールを使用した際、管理対象サーバーを1つずつ停止します。
Oracle Directory Services Managerのページとポート、およびOracle Internet Directoryに対して以前に確立された接続に戻ります。
これを実行すると、Oracle Directory Services Managerのページと新しい接続を再確立するように求めるメッセージが表示されます。
ソリューション
この問題が発生した場合、次の手順を実行します。
Webブラウザで、現在のOracle Directory Services Managerページを終了します。
新しいWebブラウザ・ページを起動し、Oracle Directory Services Manager Oracle HTTP Serverの同じ名前とポートを指定します。
以前に操作していたOracle Internet Directoryサーバーへの新しい接続を再確立します。
問題
Oracle Directory Services Managerでは、Oracle Internet Directoryとの接続が一時的に切断されて、LDAPサーバーが停止しているというメッセージが表示されます。
ソリューション
Oracle Directory Services Managerがロード・バランサを介してOracle Internet Directoryに接続されている高可用性構成では、Oracle Directory Services Managerは、Oracle Internet Directoryのいずれかのインスタンスから別のインスタンスへのフェイルオーバー時に、サーバーが停止していることを報告します。他の構成では、このメッセージでは、Oracle Internet Directoryが停止されてから再起動されたことが示される場合があります。いずれの場合も、接続の再確立にかかる時間はわずかで、再度ログインすることなく続行できます。
問題
Oracle Directory Services Managerでは、Oracle RACデータベースを使用しているOracle Internet Directoryインスタンスとの接続が一時的に切断されます。Oracle Directory Services Managerでは、次のメッセージが表示されることがあります。
LDAPエラー・コード53 - この機能は組み込まれていません
ソリューション
このエラーは、Oracle Internet Directoryインスタンスが使用しているOracle Databaseのフェイルオーバー時に発生する可能性があります。いずれの場合も、接続の再確立にかかる時間はわずかで、再度ログインすることなく続行できます。
問題
クラスタ化されたOracle WebLogic Server環境でOracle Directory Services Managerのリクエストを複数のOracle WebLogic ServerにルーティングするようOracle HTTP Serverを構成するには、次の手順に従います。
ソリューション
次の手順を実行します。
Oracle HTTP Serverのadmin.confファイルのバックアップ・コピーを作成します。このファイルはORACLE_INSTANCE/configにあります。この手順の実行後に問題が起きた場合、バックアップ・コピーがあると、元の状態に戻すことができます。
次のテキストをOracle HTTP Serverのadmin.confファイルの最後に追加し、変数プレースホルダ値を環境に固有のホスト名と管理対象サーバー・ポート番号に置き換えます。先頭行として必ず「<Location /odsm/ >」を入力してください。「<Location /odsm/faces >」や「<Location /odsm/faces/odsm.jspx >」を入力すると、Oracle Directory Services Managerのインタフェースが正しく表示されないことがあります。
<Location /odsm/ >
SetHandler weblogic-handler
WebLogicCluster host-name-1:managed-server-port,host-name_2:managed_server_port
</Location>
第21.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを再起動し、構成の変更内容をアクティブ化します。
|
注意: Oracle Directory Services Managerの接続先であるクラスタ内のOracle WebLogic Serverで障害が発生すると、Oracle Directory Services Managerの接続が切断されて、セッション・タイムアウトのメッセージが表示されます。Oracle Directory Services Managerに再びログインした後で、httpd.confファイルで指定したクラスタ内のセカンダリOracle WebLogic Serverに、Oracle Directory Services Managerリクエストがルーティングされます。 |
問題
Webブラウザを使用してOracle Directory Services Managerにアクセスできません。
ソリューション
Oracle Virtual Directoryサーバーが稼働していることを確認します。Oracle Directory Services ManagerからOracle Virtual Directoryサーバーに接続するには、このサーバーが稼働している必要があります。
「サーバー」、「ポート」、「ユーザー名」および「パスワード」の各フィールドに正しい資格証明を入力したことを確認します。ldapbindコマンドをターゲットのOracle Virtual Directoryサーバーに対して実行することで、サーバー、ユーザー名およびパスワードの資格証明を確認できます。
サポートされているブラウザを使用していることを確認します。Oracle Directory Services Managerは、次のブラウザをサポートしています。
Internet Explorer 7
Firefox 2.0.0.2および3.0
Safari 3.1.2(デスクトップ)
Google Chrome 0.2.149.30
|
注意: Oracle Directory Services Managerはこれらのブラウザをすべてサポートしていますが、認定されているのはInternet Explorer 7とFirefox 2.0.0.2のみです。 |
問題
Oracle Enterprise Manager Fusion Middleware ControlからOracle Directory Services Managerを起動するために、「Oracle Virtual Directory」ターゲットで「Oracle Virtual Directory」メニューの「Directory Services Manager」エントリからいずれかのオプションを選択しても、Oracle Directory Services Managerが開きません。
ソリューション
これはインストールに問題がある可能性があります。『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
問題
Oracle HTTP Serverを使用してOracle Directory Services Managerフェイルオーバーを実行すると、フェイルオーバーが透過的になりません。次の手順を実行すると、この動作を確認できます。
Oracle HTTP Serverを使用して、高可用性アクティブ/アクティブ構成でOracle Directory Services Managerはデプロイされています。
Oracle HTTP Serverの名前とポート番号を使用して、Oracle Directory Services Managerのページを表示します。
Oracle Virtual Directoryサーバーに接続します。
Oracle Directory Services Manager Oracle HTTP Serverの現在のホストとポートを使用して、Oracle Virtual Directoryサーバーを操作します。
WebLogic Server管理コンソールを使用した際、管理対象サーバーを1つずつ停止します。
Oracle Directory Services Managerのページとポート、およびOracle Virtual Directoryに対して以前に確立された接続に戻ります。これを実行すると、Oracle Directory Services Managerのページと新しい接続を再確立するように求めるメッセージが表示されます。
ソリューション
この問題が発生した場合、次の手順を実行します。
Webブラウザで、現在のOracle Directory Services Managerページを終了します。
新しいWebブラウザ・ページを起動し、Oracle Directory Services Manager Oracle HTTP Serverの同じ名前とポートを指定します。
以前に操作していたOracle Virtual Directoryサーバーへの新しい接続を再確立します。
問題
Oracle Directory Services Managerでは、Oracle RACデータベースを使用しているOracle Virtual Directoryインスタンスとの接続が一時的に切断されます。Oracle Directory Services Managerでは、「LDAPエラー・コード53 - この機能は組み込まれていません」というメッセージが表示されることがあります。
ソリューション
このエラーは、Oracle Virtual Directoryインスタンスが使用しているOracle Databaseのフェイルオーバー時に発生する可能性があります。いずれの場合も、接続の再確立にかかる時間はわずかで、再度ログインすることなく続行できます。
この項では、Oracle Access Managerで発生する可能性のある一般的な問題とその解決策を紹介します。
問題
Oracle Access Manager 11gサーバーで次のようなエラー・メッセージが表示されます。
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ゲートがインストールされていることを確認します。
DOMAIN_HOME/outputからWebゲートのLibディレクトリにOBAccessClient.xmlがコピーされ、OHSが再起動されたことを確認します。
OBAccessClient.xmlが最初に作成されたとき、このファイルは適切な形式になっていません。OHSを再起動すると、そのファイルが再検査されて適切な形式になります。OHSを初めて起動すると、このファイルの新しいバージョンがOracle Access Managerから取得されます。
Oracle Access Managerサーバーを停止し、保護されたリソースへのアクセスを試みます。Oracle Access Managerサーバーが使用できないというエラーが表示されます。このエラーが表示されない場合は、Webゲートをインストールしなおします。
この項では、Oracle Identity Managerで発生する可能性のある一般的な問題とその解決策を紹介します。
問題
Oracle Identity Manager構成を実行すると、java.io.FileNotFoundException: soaconfigplan.xml (Permission denied)のエラーが表示され、Oracle Identity Manager構成が失敗することがあります。
ソリューション
この問題を回避するには、次の手順を実行します。
ファイル/tmp/oaconfigplan.xmlを削除します。
構成を再開します(OH/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 Identity Federationで発生する可能性のある一般的な問題とその解決策を紹介します。
問題
WindowsシステムでOracle Identity Federationサーバーを実行していても、それにログインできません。
ソリューション
Oracle Identity Federationサーバー以外のすべてでIPv4を使用している場合は、Oracle Identity FederationサーバーもIPv4を使用していることを確認します。
これを確認するには、OIFHOST1およびOIFHOST2でDOMAIN_HOME/bin/setDomainEnv.cmdファイルを調べます。
行EXTRA_JAVA_PROPERTIESを探し、そこに次のエントリが存在しない場合はこれを追加します。
-Djava.net.preferIPv6Addresses -DuseIPv6Address=false -Djava.net.preferIPv6Addresses=false
このファイルを保存し、第21.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってOracle Identity Federationサーバーを再起動します。
問題
管理対象サーバーを作成する手順でOracle Identity Managerをインストールすると、Oracle Identity Federationでのドメインの拡張に失敗します。
ソリューション
IDMHOST1のDOMAIN_HOME/binからOIFHOST1に、ファイルsetDomainEnv.shをコピーします。
操作を再試行します。
問題
Oracle Enterprise Manager Fusion Middleware Controlを使用してOracle Identity Federationのパラメータを変更できません。次のメッセージが表示されます。
Configuration settings are unavailable because .....OIF ...... is down
これは、Oracle Identity Federationが稼働していても発生します。
ソリューション
一般的な原因と解決方法は次のとおりです。
Oracle Identity Federationは稼働していますが、EMエージェントが停止しています。
次を実行して、EMエージェントのステータスを確認します。
ORACLE_INSTANCE/EMAGENT/EMAGENT/bin/emctl status agent
EMエージェントが停止している場合は、次を実行してEMエージェントを起動します。
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=EMAGENT
Fusion Middleware Controlに再度ログインします。
Oracle Identity FederationとEMエージェントは稼働していますが、OIFホーム・ページとFusion Middleware Controlの構成ページにはOIFは停止していますと表示されます。
次を実行して、EMエージェントが正しいFusion Middleware Controlを指していることを確認します。
ORACLE_INSTANCE/EMAGENT/EMAGENT/bin/emctl status agent
プロパティRepository URLのhostおよびportの値が、Fusion Middleware Controlのホストおよびポートと同じであることを確認します。
hostおよびportが対応する値と一致していない場合は、次を実行して、EMエージェントのRepository URLを正しいFusion Middleware Controlに変更します。
ORACLE_INSTANCE/EMAGENT/EMAGENT/bin/emctl switchOMS http(s)://Host:Port/em/upload'
Fusion Middleware Controlに再度ログインします。
これでも問題が解決しない場合は、Fusion Middleware Controlにログインし、「ファーム」→「エージェントの監視中のターゲット」(ページの左上)に移動して、Oracle Identity Federationを参照している行の「構成」アイコンをクリックします。次のページで、すべての情報が正しく、不足がないことを確認します。「OK」をクリックして続行します。
WebLogicのユーザー名とパスワードが存在していることを確認します。
ホストの値を確認します。これがIPv6アドレス形式で指定されている可能性があります。
問題が解決しない場合はEMエージェントを再起動します。
次を実行してEMエージェントを停止します。
INST_HOME/bin/opmnctl stopproc ias-component=EMAGENT
次を実行してEMエージェントを起動します。
INST_HOME/bin/opmnctl startproc ias-component=EMAGENT
Oracle Enterprise Manager Fusion Middleware Controlに再度ログインします。
この項では、Oracle Identity Managementエンタープライズ・デプロイメントに関する他の推奨事項を紹介します。
ほとんどの本番デプロイメント環境ではファイアウォールが使用されます。データベース接続は複数のファイアウォールにまたがって確立されるため、データベース接続がタイムアウトにならないようにファイアウォールを構成することをお薦めします。Oracle Real Application Cluster(Oracle RAC)については、データベース接続はOracle RAC VIPとデータベース・リスナー・ポートを使用して確立されます。ファイアウォールがこれらの接続をタイムアウトさせないように構成する必要があります。そのような構成が不可能な場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルで、SQLNET.EXPIRE_TIME=nというパラメータを設定します(nは分単位の時間)。この値を、ネットワーク・デバイス(ファイアウォール)の既知のタイムアウト値より小さい値に設定します。Oracle RACについては、このパラメータをすべてのOracleホーム・ディレクトリで設定します。
