ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド
11g リリース2 (11.1.2.1)
B71694-06
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

17 エンタープライズ・デプロイメント用のトポロジの管理

この章では、Identity Managementのトポロジの設定後に実行できる操作について説明します。実行できる操作には、トポロジの監視、スケーリング、バックアップ、トラブルシューティングなどがあります。

この章の内容は次のとおりです。

17.1Oracle Identity Managementコンポーネントの起動と停止

この項では、Oracle Identity Managementエンタープライズ・デプロイメントの各種コンポーネントを起動、停止および再起動する方法を説明します。

この項には次のトピックが含まれます:

17.1.1 起動順序

インフラストラクチャ全体を起動するときは、次の順序で各コンポーネントを起動します(トポロジ内に存在しないコンポーネントは無視してください)。

  1. データベース

  2. データベース・リスナー

  3. LDAPディレクトリ・サーバー

  4. ノード・マネージャ

  5. Oracle Access Managerサーバー

  6. WebLogic管理サーバー

  7. Oracle HTTP Server

  8. SOAサーバー

  9. Oracle Identity Managerサーバー

17.1.2 Oracle Unified Directoryの起動と停止

Oracle Unified Directoryは次のように起動および停止します。

17.1.2.1 Oracle Unified Directoryの起動

Oracle Unified Directoryを起動するには、次のコマンドを実行します。

OUD_ORACLE_INSTANCE/OUD/bin/start-ds

17.1.2.2 Oracle Unified Directoryの停止

Oracle Unified Directoryを停止するには、次のコマンドを実行します。

OUD_ORACLE_INSTANCE/OUD/bin/stop-ds

17.1.3 Access Managerの管理対象サーバーの起動、停止および再起動

Oracle Access Managerの管理対象サーバーを起動および停止するには、次のようにします。

17.1.3.1 Access Manager管理対象サーバーが1つも実行されていない場合の管理対象サーバーの起動

通常、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')

17.1.3.1 別のAccess Manager管理対象サーバーが実行されている場合の管理対象サーバーの起動

すでに別のOracle Access Manager管理対象サーバーが実行されている場合にさらに管理対象サーバーを起動するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。

次のように実行します。

  1. 「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。

  2. 「制御」タブをクリックします。

  3. OAMサーバー(WLS_OAM1またはWLS_OAM2、あるいはその両方)を選択します。

  4. 「起動」ボタンをクリックします。

  5. サーバーを起動してよいか確認を求められたら、「はい」をクリックします。

17.1.3.3 Access Manager管理対象サーバーの停止

Oracle Access Manager管理対象サーバーを停止するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインし、次の手順を実行します。

  1. 「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。

  2. 「制御」タブをクリックします。

  3. OAMサーバー(WLS_OAM1またはWLS_OAM2、あるいはその両方)を選択します。

  4. 「停止」ボタンをクリックし、「ただちに強制停止」を選択します。

  5. サーバーを停止してよいか確認を求められたら、「はい」をクリックします。

17.1.3.4 Access Manager管理対象サーバーの再起動

前の各項で、停止と起動の手順を実行してサーバーを再起動します。

17.1.4 WebLogic管理サーバーの起動、停止および再起動

次の項の説明に従って、WebLogic管理サーバーの起動と停止を行います。


注意:

Admin_UserとAdmin_Passwordのみを使用して、ノード・マネージャとクライアントとの間における接続を認証します。これらはサーバー管理IDおよびパスワードとは独立しており、ASERVER_HOME/config/nodemanager/nm_password.propertiesファイルに格納されています。

17.1.4.1 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.1.4.2 WebLogic管理サーバーの停止

管理サーバーを停止するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。

次のように実行します。

  1. 「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。

  2. 「制御」タブをクリックします。

  3. 「AdminServer(admin)」を選択します。

  4. 「停止」をクリックし、「ただちに強制停止」を選択します。

  5. 管理サーバーを停止してよいか確認を求められたら「はい」をクリックします。

17.1.4.3 WebLogic管理サーバーの再起動

前の各項で、停止と起動の手順を実行してサーバーを再起動します。

17.1.5 ノード・マネージャの起動と停止

ノード・マネージャを起動および停止するには、次のようにします。

17.1.5.1 ノード・マネージャの起動

起動しようとするノード・マネージャが、管理サーバー(IDMHOST1またはIDMHOST2)を制御するノード・マネージャである場合は、その起動の前に次のコマンドを発行します。

export JAVA_OPTIONS=-DDomainRegistrationEnabled=true

ノード・マネージャで共有記憶域を使用している場合は、第13.3.5項「共通または共有記憶域インストールの使用」の説明に従ってJAVA_OPTIONSを設定します。

ノード・マネージャを起動するには、次のコマンドを実行します。

cd IAM_MW_HOME/wlserver_10.3/server/bin
./startNodeManager.sh

17.1.5.2 ノード・マネージャの停止

ノード・マネージャを停止するには、前の項で起動したプロセスを強制終了します。

17.1.5.3 管理サーバーのノード・マネージャの起動

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
./startNodeManager.sh

注意:

管理サーバーを管理するノード・マネージャを起動する場合は、-DDomainRegistrationEnabled=trueを設定することが重要です。

17.1.6 Oracle HTTP Serverの起動、停止および再起動

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

17.1.6.1 Oracle HTTP Serverの起動

次のコマンドを発行して、Oracle Web層を起動します。

opmnctl startall

17.1.6.2 Oracle HTTP Serverの停止

次のコマンドを実行して、Web層を停止します。

opmnctl stopall

前述を実行すると、Web層全体が停止します。

opmnctl stoproc process-type=OHS

前述を実行すると、Oracle HTTP Serverのみが停止します。

17.1.6.3 Oracle HTTP Serverの再起動

Web層を再起動するには、前述の各項における記載のとおりstopコマンドを実行してからstartコマンドを実行します。

Oracle HTTP Serverのみを再起動するには、次のコマンドを使用します。

opmnctl restartproc process-type=OHS

17.1.7 Oracle Identity Managerの起動、停止および再起動

Oracle Identity ManagerサーバーとOracle SOA Suiteサーバーを起動および停止するには、次のようにします。

17.1.7.1 Oracle Identity Managerの起動

Oracle Identity Manager管理対象サーバーを起動するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。

次のように実行します。

  1. 「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。

  2. 「制御」タブをクリックします。

  3. SOAサーバー(WLS_SOA1またはWLS_SOA2、あるいはその両方)を選択します。


    注意:

    Oracle Identity ManagerサーバーとOracle SOA Suiteサーバーは相互に独立して起動できます。これらの起動順序には依存関係はありません。ただし、Oracle Identity Managerの機能をすべて使用可能にするには、SOAサーバーが起動され、実行されていることが必要です。

  4. 「起動」ボタンをクリックします。

  5. サーバーを起動してよいか確認を求められたら、「はい」をクリックします。

  6. WLS_SOA1またはWLS_SOA2(あるいはその両方)が起動されたら、WLS_OIM1またはWLS_OIM2(あるいはその両方)を選択します。

  7. 「起動」をクリックします。

  8. サーバーを起動してよいか確認を求められたら、「はい」をクリックします。

17.1.7.2 Oracle Identity Managerの停止

Oracle Identity Manager管理対象サーバーを停止するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインし、次の手順を実行します。

  1. 「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。

  2. 「制御」タブをクリックします。

  3. OIMサーバー(WLS_OIM1またはWLS_OIM2、あるいはその両方)および(WLS_SOA1またはWLS_SOA2、あるいはその両方)を選択します。

  4. 「停止」ボタンをクリックし、「ただちに強制停止」を選択します。

  5. サーバーを停止してよいか確認を求められたら、「はい」をクリックします。

17.1.7.3 Oracle Identity Managerの再起動

前の各項で、停止と起動の手順を実行してサーバーを再起動します。

17.2 Identity ManagementコンソールのURLについて

表17-1は、このガイドの中で使用されている管理コンソールとそのURLの一覧です。

表17-1 コンソールのURL

ドメイン コンソール URL

IDMDomain

WebLogic管理コンソール

http://ADMIN.mycompany.com/console

Enterprise Manager FMWコントロール

http://ADMIN.mycompany.com/em

OAMコンソール

http://ADMIN.mycompany.com/oamconsole

ODSM

http://ADMIN.mycompany.com/odsm

OIMDomain

OIMコンソール

https://SSO.mycompany.com/identity

OIMDomain

WebLogic管理コンソール

http://OIMADMIN.mycompany.com/console

OIMDomain

Enterprise Manager FMWコントロール

http://OIMADMIN.mycompany.com/em

OIMDomain

認可ポリシー・マネージャ

http://OIMADMIN.mycompany.com/apm

17.3 エンタープライズ・デプロイメントの監視

この項では、このマニュアルで説明しているIdentity Managementエンタープライズ・デプロイメントの監視について説明します。

この項には次のトピックが含まれます:

17.3.1 WebLogic管理対象サーバーの監視

Oracle Enterprise Manager Fusion Middleware Controlを使用すると、管理対象サーバーや他のFusion Middlewareコンポーネント(Access Manager、Oracle Identity Manager、SOAなど)を監視できます。詳細は、「関連ドキュメント」の「はじめに」で一覧表示されている各管理者ガイドを参照してください。

17.3.2 Oracle Unified Directoryの監視

次のコマンドを実行することによって、Oracle Unified Directoryのステータスを確認できます。

OUD_ORACLE_INSTANCE/OUD/bin/status

このコマンドは、ローカルで実行されているOracle Unified Directoryのインスタンスにアクセスし、ディレクトリのステータスをレポートします(レプリケーションの有効/無効、LDAPまたはLDAPSの有効/無効など)。

17.4 エンタープライズ・デプロイメントのスケーリング

このマニュアルで取り上げている参照エンタープライズ・トポロジはきわめてスケーラブルです。スケール・アップもスケール・アウトも可能です。トポロジをスケール・アップすると、すでに1つ以上のサーバー・インスタンスを実行しているノードに新しいサーバー・インスタンスが追加されます。トポロジをスケール・アウトすると、新しいノードに新しいサーバーが追加されます。

この項には次のトピックが含まれます:

17.4.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サーバーを再起動します。サービスの停止を防止するため、再起動は順次的に行うことをお薦めします。

この項には次のトピックが含まれます:

17.4.1.1 Oracle Unified Directoryのスケール・アップ

ディレクトリには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インスタンスにおけるホストとポートの情報でロード・バランサを再構成します。

17.4.1.2 Oracle Access Manager 11gのスケール・アップ

次の手順でOracle Access Managerをスケール・アップします。

第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

  1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。

  2. 「ロックして編集」を「チェンジ・センター」メニューでクリックします。

  3. 拡張するホスト上の既存サーバーを選択します(例: WLS_OAM1)。

  4. 「クローンの作成」をクリックします。

  5. 次の情報を入力します。

    • サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。

    • サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。

    • サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。

  6. 「OK」をクリックします。

  7. 新しく作成したサーバーWLS_OAM3をクリックします。

  8. 「保存」をクリックします。

  9. 新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。IDMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。

    新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名検証を無効にする手順は次のとおりです。

    1. Oracle WebLogic Server管理コンソールにログインします。

    2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

    3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

    4. 表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。

    5. 「SSL」タブをクリックします。

    6. 「詳細」をクリックします。

    7. 「ホスト名の検証」を「なし」に設定します。

    8. 「保存」をクリックします。

  10. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

Oracle Access Managerに新しい管理対象サーバーを登録します。この時点で、新しい管理対象サーバーをOracle Access Managerサーバーとして構成する必要があります。Oracle OAMコンソールでこれを行います。次のように実行します。

  1. oamadminユーザーでOAMコンソールにログインします。第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用します。

  2. 「システム構成」タブをクリックします。

  3. 「サーバー・インスタンス」をクリックします。

  4. 「作成」を「アクション」メニューで選択します。

  5. 次の情報を入力します。

    • サーバー名: WLS_OAM3

    • ホスト: サーバーを実行するホスト。

    • ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポートです。

    • OAMプロキシ・ポート: Oracle Access Managerプロキシの実行対象とするポート。これは当該ホストについて一意のポートです。

    • プロキシ・サーバーID: AccessServerConfigProxy

    • モード: 既存のOracle Access Managerサーバーが動作しているモードに応じて、「オープン」または「簡易」を選択します。

    • Coherenceローカル・ポート: 「ローカル・ポート」にホストで一意の値を設定します。

  6. 「適用」をクリックします。

  7. 第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コンソールにアクセスし、次の手順を実行します。

  1. 第9.4項「アイデンティティ・ストアの準備」で作成したOracle Access Manager管理ユーザーとしてログインします。

  2. 「システム構成」タブをクリックします。

  3. 「Access Manager」→「SSOエージェント」→「OAMエージェント」を開きます。

  4. フォルダを開くアイコンをクリックして「検索」をクリックします。

    Webゲート・エージェントWebgate_IDMが表示されます。

  5. エージェントWebgate_IDMをクリックします。

  6. 「アクション」メニューで「編集」を選択します。

  7. 「プライマリ・サーバー」リスト(これがセカンダリ・サーバーである場合は「セカンダリ・サーバー」リスト)で「+」をクリックします。

  8. 「サーバー」リストから、新しく作成した管理対象サーバーを選択します。

  9. 「接続の最大数」を10に設定します。

  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コンポーネントの起動と停止」の手順に従い、新しい管理対象サーバーを起動できるようになります。

17.4.1.3 Oracle Identity Managerのスケール・アップ

この場合は、すでに管理対象サーバーを実行するノードがOracle SOA SuiteおよびOracle Identity Managerのコンポーネントを使用するように構成されています。このノードには、ミドルウェア・ホーム、SOA Oracleホーム、Oracle Identity Manager Oracleホーム、および既存の管理対象サーバーのドメイン・ディレクトリが含まれています。

既存のインストール内容(ミドルウェア・ホームおよびドメイン・ディレクトリ)を使用して、新しいWLS_OIMサーバーとWLS_SOAサーバーを作成できます。新しい場所にOracle Identity and Access ManagementまたはOracle SOA Suiteバイナリをインストールする必要はありません。また、パックと解凍を実行する必要もありません。

次の手順に従って、トポロジをスケール・アップします。

  1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して管理コンソールにログインします。WLS_OIM1またはWLS_SOA1のいずれかを新しい管理対象サーバーにクローニングします。クローニング元となるソース管理対象サーバーは、新しい管理対象サーバーを実行するノード上にすでに存在している必要があります。

    管理対象サーバーをクローニングする手順は次のとおりです。

    1. 管理コンソールで「環境」→「サーバー」を選択します。

    2. 「チェンジ・センター」メニューで「ロックして編集」をクリックします。

    3. クローニングする管理対象サーバーを選択します(例: WLS_OIM1やWLS_SOA1)。

    4. 「クローンの作成」を選択します。

    新しい管理対象サーバーに、WLS_OIMnまたはWLS_SOAnという名前を付けます。nには、新しい管理対象サーバーを識別するための番号を指定します。

    この後の手順では、すでにWLS_SOA1およびWLS_OIM1を実行しているIDMHOST1に新しいサーバーを追加することを想定しています。

  2. リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPアドレスを割り当てます。このサーバーでお薦めしているサーバー移行を実行する予定の場合は、別のノードへの移動を可能にするために、このアドレスはVIP(別称: 浮動IP)である必要があります。このVIPは、すでに実行されている管理対象サーバーで使用されているものとは異なっている必要があります。

  3. 新しい管理対象サーバー上に、SOA、Oracle Identity Manager、UMSおよびBPMそれぞれのJMSサーバーを作成します。この操作は次のように実行します。

    1. WebLogic管理コンソールにログインし、「サービス」→「メッセージング」→「JMSサーバー」に移動します。

    2. 「新規」をクリックします。

    3. 「名前」に、BPMJMSServer_auto_3などの値を入力します。

    4. 「新しいファイル・ストアの作成」をクリックします。

    5. リストからFileStoreを選択します。

    6. 「次へ」をクリックします。

    7. 「名前」に、BPMJMSFileStore_auto_3などの値を入力します。

    8. 次の値を入力します。

      ターゲット: 現在作成している新しいサーバー。

      ディレクトリ: ASERVER_HOME/jms/BPMJMSFileStore_auto_3


      注意:

      ディレクトリが存在していることを確認してください。存在しない場合、WLS_OIM3またはWLS_SOA3を起動できません。

    9. 「OK」をクリックします。

    10. 「JMSサーバー」画面に戻り、新しく作成したファイル・ストアをリストから選択します。

    11. 「次へ」をクリックします。

    12. 次の画面で、「ターゲット」を作成しているサーバーに設定します。

    13. 「終了」をクリックします。

    作成する管理対象サーバーに応じて、次のJMSキューを作成します。

    サーバー JMSサーバー名 ファイル・ストア名 ディレクトリ ターゲット

    WLS_SOAn

    BPMJMSServer_auto_n

    BPMJMSFileStore_auto_n

    ASERVER_HOME/jms/BPMJMSFileStore_auto_n

    WLS_SOAn

    WLS_SOAn

    SOAJMSServer_auto_n

    SOAJMSFileStore_auto_n

    ASERVER_HOME/jms/SOAJMSFileStore_auto_n

    WLS_SOAn

    WLS_SOAn

    UMSJMSServer_auto_n

    UMSJMSFileStore_auto_n

    ASERVER_HOME/jms/UMSJMSFileStore_auto_n

    WLS_SOAn

    WLS_OIMn

    OIMJMSServer_auto_n

    OIMJMSFileStore_auto_n

    ASERVER_HOME/jms/OIMJMSFileStore_auto_n

    WLS_OIMn

    WLS_OIMn

    JRFWSAsyncJmsServer_auto_n

    JRFWSAsyncFileStore_auto_n

    ASERVER_HOME/jms/JRFWSAsyncFileStore_auto_n

    WLS_OIMn

  4. 次の手順を実行して、新しく作成したJMSキューを既存のJMSモジュールに追加します。

    1. WebLogic管理コンソールにログインします。

    2. 「サービス」→「メッセージング」→「JMSモジュール」に移動します。

    3. SOAJMSModuleなどのJMSモジュールをクリックします。

    4. 「サブデプロイメント」タブをクリックします。

    5. 表示されたサブ・デプロイメントをクリックします。


      注意:

      このサブデプロイメント・モジュール名は、JMSServerNameXXXXXXという形式のランダムな名前で、構成ウィザードJMS構成から生成されます。

    6. 新しく作成したJMSサーバーを割り当てます(SOAJMSServer_auto_3など)。

    7. 「保存」をクリックします。

    これを、次の表に記載されている各JMSモジュールに対して実行します。

    JMSモジュール JMSサーバー

    BPMJMSModule

    BPMJMSServer_auto_n

    JRFWSAsyncJmsModule

    JRFWSAsyncJmsServer_auto_n

    OIMJMSModule

    OIMJMSServer_auto_n

    SOAJMSModule

    SOAJMSServer_auto_n

    UMSJMSSystemResource

    UMSJMSServer_auto_n

  5. 第12.9項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従ってOracle Coherenceを構成します。


    注意:

    変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。

  6. 管理コンソールの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

  7. 新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。

    1. Oracle WebLogic Server管理コンソールにログインします。

    2. 「ロックして編集」をクリックします。

    3. 「ドメイン構造」ウィンドウで、「環境」ノードを開いてから、「サーバー」ノードをクリックします。

      「サーバーのサマリー」ページが表示されます。

    4. 表の「名前」列で、Oracle Identity ManagerまたはSOAサーバーの名前(ハイパーリンクで表示されています)をクリックします。

    5. 選択したサーバーの「設定」ページが表示され、「構成」タブにデフォルト設定されます。

    6. 「サービス」サブタブを開きます。

    7. ページの「デフォルト・ストア」セクションで、共有記憶域にあるデフォルトの永続ストアへのパスを指定します。パスのディレクトリ構造は次のとおりです。

      Oracle Identity Managerサーバー: ASERVER_HOME/tlogs

      SOAサーバー: ASERVER_HOME/tlogs

    8. 保存してアクティブ化するをクリックします。

  8. 新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOAn管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。IDMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。

    ホスト名検証を無効にする手順は次のとおりです。

    1. Oracle WebLogic Server管理コンソールにログインします。

    2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

    3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

    4. 表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。

    5. 「SSL」タブをクリックします。

    6. 「詳細」をクリックします。

    7. 「ホスト名の検証」を「なし」に設定します。

    8. 「保存」をクリックします。

  9. WLS_OIMnの各管理対象サーバーでも、手順6a - 6hを繰り返してホスト名検証を無効にします。手順6dでは、表の「名前」列で「WLS_OIMn」を選択します。

  10. クラスタ・アドレス・リストに新しいサーバーを追加します。

    1. WebLogic管理コンソールの「ドメイン構造」ウィンドウで「環境」ノードを展開します。

    2. 「クラスタ」をクリックします。「クラスタの概要」ページが表示されます。

    3. クラスタ名oim_clusterをクリックします。「クラスタのプロパティ」ページが表示されます。

    4. クラスタ・アドレス・リストに新しいOIM管理対象サーバーを追加します。

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

  11. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

  12. Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAのホストとポートを更新します。次の手順に従います。

    1. ブラウザを開き、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してOracle Enterprise Manager Fusion Middleware Controlにアクセスします。

    2. 管理ユーザー資格証明を使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。


      注意:

      前述の手順を実行する際に、1つ以上のOracle Identity Manager管理対象サーバーを実行している必要があります。

    3. 「Farm_IDMDomain」→「Identity and Access」→「OIM」→「oim(11.1.2.0.0)」を選択します。

    4. メニューから「システムMBeanブラウザ」を選択するか、または右クリックしてこの項目を選択します。

    5. 「アプリケーション」を選択し、定義済Mbean→「oracle.iam」を選択します。「サーバー」には「WLS_OIM1」、「アプリケーション」には「oim」を選択します。XML構成→「構成」を選択し、「XMLConfig.SOAConfig」→「SOAConfig」を選択します。

    6. 新しいSOAサーバーのホストとポートでRmiurl属性の値を更新します。「適用」をクリックして、変更を保存します。

    7. Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBにアクセスするために使用されます。これがアプリケーション・サーバーのURLです。この属性の値の例を次に示します。

      cluster:t3://soa_cluster

  13. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。

  14. 管理コンソールから新しい管理対象サーバーを起動して、テストします。

    1. クラスタ内の既存の管理対象サーバーを停止します。

    2. 新規作成した管理対象サーバーであるWLS_SOAnが稼働していることを確認します。

    3. 新しく作成した管理対象サーバー(http://vip:port/soa-infra)上のアプリケーションにアクセスします。アプリケーションは機能している必要があります。

  15. 新しく作成した管理対象サーバーを、サーバー移行ができるように構成します。第14.6項「サーバー移行ターゲットの構成」の手順に従って、サーバー移行を構成します。

  16. この新規サーバーのサーバー移行をテストします。新規サーバーの追加先となったノードで、次の手順を実行します。

    1. 管理対象サーバーWLS_SOAnを停止します。

      このためには、次のコマンドを実行します。

      kill -9 pid

      このコマンドでは、その管理対象サーバーのプロセスID (PID)を指定します。ノードのPIDを確認するには、次のコマンドを使用します。

       ps -ef | grep WLS_SOAn

    2. ノード・マネージャ・コンソールを参照します。WLS_SOA1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。

    3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。これを再起動する前に、分離するまでノード・マネージャで30秒待ちます。

    4. ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。

17.4.1.4 Oracle HTTP Serverのスケール・アップ

Web層には、Oracle HTTP Serverのインスタンスが実行されている1つのノードがすでにあります。既存のOracle HTTP Serverバイナリを使用して、新しいOracle HTTP Serverインスタンスを作成できます。Oracle HTTP Serverをスケール・アップするには、第10章「エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成」の手順に従います。

  1. 第10章「エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成」の説明に従い、Oracle Fusion Middleware 11gのWeb層ユーティリティ構成ウィザードを使用してトポロジをスケール・アップします。

  2. 既存のWeb層構成のORACLE_INSTANCE/config/OHS/component/moduleconf内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。

  3. 新しいOracle HTTP Serverインスタンスのホスト情報とポート情報に基づいてロード・バランサを再構成します。

17.4.2 トポロジのスケール・アウト

トポロジをスケール・アウトする際は、新しいサーバーを新しいノードに追加します。このマニュアルで説明している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サーバーを再起動します。サービスの停止を防止するため、再起動は順次的に行うことをお薦めします。

この項には次のトピックが含まれます:

17.4.2.1 Oracle Unified Directoryのスケール・アウト

ディレクトリにはOracle Unified Directoryの2つのノード(IDMHOST1とIDMHOST2)があり、それぞれでOracle Unified Directoryインスタンスが実行されます。Oracle Unified Directoryのインスタンスは、次に示すように、構成に新しいノードを追加することによってスケール・アウトできます。

  1. 第7.3項「Oracle Unified Directoryのインストール」の手順に従って、新しいホストにOUDバイナリをインストールします。

  2. 第7.4.3項「IDMHOST2での追加のOracle Unified Directoryインスタンスの構成」の手順に従います。

  3. 新しいOracle Unified Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。

17.4.2.2 Oracle Access Manager 11gのスケール・アウト

スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。

新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやIdentity Managementのバイナリをインストールする必要はありませんが、新しいノードでドメイン構成をブートストラップするためにパックと解凍を実行する必要があります。


注意:

共有記憶域を使用している場合は、その共有記憶域に新しいホストがアクセスできるようにします。

  1. 新しいノードで、Identity and Access Managementのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできるようにします。

  2. ミドルウェア・ホーム・リストを更新するには、IAM_MW_HOME/bea/beahomelistファイルを作成して(別のWebLogicがそのノードにインストールされている場合は編集します)、IAM_MW_HOME/product/fmwをこのファイルに追加します。

  3. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

  4. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。

  5. 「ロックして編集」を「チェンジ・センター」メニューでクリックします。

  6. 拡張するホスト上の既存サーバーを選択します(例: WLS_OAM1)。

  7. 「クローンの作成」をクリックします。

  8. 次の情報を入力します。

    • サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。

    • サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。

    • サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。

  9. 「OK」をクリックします。

  10. 新規作成したサーバーである「WLS_OAM3」をクリックします。

  11. SSLリスニング・ポートを設定します。このポートは、管理対象サーバーが実行されるホスト上で一意である必要があります。

  12. 「保存」をクリックします。

  13. 新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。IDMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。

    新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名の検証を無効化する手順は、次のとおりです。

    1. Oracle WebLogic Server管理コンソールにログインします。

    2. 「環境」ノードを「ドメイン構造」ペインで開きます。

    3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

    4. 表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。

    5. 「SSL」タブをクリックします。

    6. 「詳細」をクリックします。

    7. 「ホスト名の検証」を「なし」に設定します。

    8. 「保存」をクリックします。

  14. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

  15. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。

  16. 次のコマンドを使用してIDMHOST1上のドメインをパックします。

    pack.sh -domain=ASERVER_HOME -template=/tmp/IDMDomain.jar -template_name="OAM Domain" -managed=true

    pack.shスクリプトは、ORACLE_COMMON_HOME/common/binにあります。

  17. 次のコマンドを使用して新しいホスト上でドメインを解凍します。

    unpack.sh -domain=MSERVER_HOME -template=/tmp/IDMDomain.jar -app_dir=MSERVER_HOME/applications

    unpack.shスクリプトは、ORACLE_COMMON_HOME/common/binにあります。

  18. ノード・マネージャを起動して、プロパティ・ファイルを更新します。

    1. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の手順に従い、ノード・マネージャを起動および停止します。

    2. ORACLE_COMMON_HOME/common/binにあるスクリプトsetNMProps.shを実行して、ノード・マネージャのプロパティ・ファイルを更新します。たとえば、次のように指定します。

      cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh

    3. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の手順に従い、ノード・マネージャを再度起動します。

Oracle Access Managerに新しい管理対象サーバーを登録します。この時点で、新しい管理対象サーバーをOracle Access Managerサーバーとして構成する必要があります。このためには、Oracle OAMコンソールで次の手順を実行します。

  1. oamadminユーザーでOAMコンソールにログインします。第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用します。

  2. 「システム構成」タブをクリックします。

  3. 「サーバー・インスタンス」をクリックします。

  4. 「作成」を「アクション」メニューで選択します。

  5. 次の情報を入力します。

    • サーバー名: WLS_OAM3

    • ホスト: サーバーを実行しているホストIDMHOST3。

    • ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポート。

    • OAMプロキシ・ポート: Oracle Access Managerプロキシの実行対象とするポート。これは当該ホストについて一意のポートです。

    • プロキシ・サーバーID: AccessServerConfigProxy

    • モード: 既存のOracle Access Managerサーバーが動作しているモードに応じて、「オープン」または「簡易」を選択します。

  6. 「適用」をクリックします。

新しく作成したOracle Access Managerサーバーを使用する可能性のあるすべてのWebゲート・プロファイル(Webgate_IDMやIAMSuiteAgent)にそのサーバーを追加します。

たとえば、Oracle Access ManagerサーバーをWebgate_IDMに追加するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してOAMコンソールにアクセスし、次の手順を実行します。

  1. 第9.4項「アイデンティティ・ストアの準備」で作成した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層でファイル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>

17.4.2.3 Oracle Identity Managerのスケール・アウト

トポロジをスケール・アウトする際は、OIMおよびSOAとともに構成された新しい管理対象サーバーを新しいノードに追加します。

この項の手順を実行する前に、次の要件を満たしていることを確認してください。

  • OIMおよびSOAとともに構成された管理対象サーバーが実行されている既存のノードがトポロジ内に存在していること。

  • 新しいノードがWebLogic Server、OIMおよびSOAの既存のホーム・ディレクトリにアクセスできること。

    新しい管理対象サーバーWLS_SOAまたはWLS_OIMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic Server、OIMまたはSOAのバイナリをインストールする必要はありませんが、新しいノードでドメイン構成をブートストラップするためにパックと解凍を実行する必要があります。


    注意:

    • 共有記憶域に既存のインストールが存在しない場合は、第12.9項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従って、新しいノードにWebLogic Server、IAMおよびSOAをインストールする必要があります。

    • ORACLE_HOMEまたはWL_HOMEが異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して、共有記憶域内のインストール内容をそれにアタッチするには、次のスクリプトを使用します。

      OIM_ORACLE_HOME/oui/bin/attachHome.sh

    • Middlewareホームの一覧を更新してWL_HOMEを追加または削除するには、user_home/bea/beahomelistファイルを編集します。次の手順を参照してください。

次の手順に従って、トポロジをスケール・アウトします。

  1. 新しいノードで、Oracle Fusion Middlewareのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできるようにします。

  2. 共有記憶域内のORACLE_BASEをローカルOracleインベントリにアタッチするには、次のコマンドを実行します。

    cd IAM_MW_HOME/product/fmw/iam/oui/bin
/attachHome.sh -jreLoc JAVA_HOME

  3. ミドルウェア・ホーム・リストを更新するには、IAM_MW_HOME/bea/beahomelistファイルを作成して(別のWebLogicがそのノードにインストールされている場合は編集します)、IAM_MW_HOME/product/fmwをこのファイルに追加します。

  4. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic管理コンソールにログインします。

  5. 使用する新しいノード用の新しいマシンを作成して、そのマシンをドメインに追加します。

  6. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。

  7. Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーWLS_OIM1およびWLS_SOA1を新しい管理対象サーバーにクローニングします。それらの管理対象サーバーに、それぞれWLS_SOAnおよびWLS_OIMnという名前を付けます。nは数字です。


    注意:

    これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。

  8. 新しい管理対象サーバーのリスニング・アドレスにホスト名またはIPアドレスを割り当てます。

  9. 管理対象サーバーを新しく作成したマシンに割り当てます。

  10. このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーのVIPアドレス(別称: 浮動IPアドレス)である必要があります。このVIPアドレスは、既存の管理対象サーバーで使用されているものとは異なっている必要があります。

  11. 新しい管理対象サーバー上に、SOA、Oracle Identity Manager、UMSおよびBPMそれぞれのJMSサーバーを作成します。この操作は次のように実行します。

    1. WebLogic管理コンソールにログインし、「サービス」→「メッセージング」→「JMSサーバー」に移動します。

    2. 「新規」をクリックします。

    3. 「名前」に、BPMJMSServer_auto_3などの値を入力します。

    4. 「新しいファイル・ストアの作成」をクリックします。

    5. リストからFileStoreを選択します。

    6. 「次へ」をクリックします。

    7. 「名前」に、BPMJMSFileStore_3などの値を入力します。

    8. 次の値を入力します。

      ターゲット: 現在作成している新しいサーバー。

      ディレクトリ: ASERVER_HOME/jms/BPMJMSFileStore_3

    9. 「OK」をクリックします。

    10. 「JMSサーバー」画面に戻り、新しく作成したファイル・ストアをリストから選択します。

    11. 「次へ」をクリックします。

    12. 次の画面で、「ターゲット」を作成しているサーバーに設定します。

    13. 「終了」をクリックします。

    作成する管理対象サーバーに応じて、次のJMSキューを作成します。

    サーバー JMSサーバー名 ファイル・ストア名 ディレクトリ ターゲット

    WLS_SOAn

    BPMJMSServer_auto_n

    BPMJMSFileStore_n

    ASERVER_HOME/jms/BPMJMSFileStore_n

    WLS_SOAn

    WLS_SOAn

    SOAJMSServer_auto_n

    SOAJMSFileStore_n

    ASERVER_HOME/jms/SOAJMSFileStore_n

    WLS_SOAn

    WLS_SOAn

    UMSJMSServer_auto_n

    UMSJMSFileStore_n

    ASERVER_HOME/jms/UMSJMSFileStore_n

    WLS_SOAn

    WLS_OIMn

    OIMJMSServer_auto_n

    OIMJMSFileStore_n

    ASERVER_HOME/jms/OIMJMSFileStore_n

    WLS_OIMn

    WLS_OIMn

    JRFWSAsyncJmsServer_auto_n

    JRFWSAsyncJmsServer_n

    ASERVER_HOME/jms/JRFWSAsyncJmsServerJMSFileStore_n

    WLS_OIMn

  12. 次の手順を実行して、新しく作成したJMSキューを既存のJMSモジュールに追加します。

    1. WebLogic管理コンソールにログインします。

    2. 「サービス」→「メッセージング」→「JMSモジュール」に移動します。

    3. SOAJMSModuleなどのJMSモジュールをクリックします。

    4. 「サブデプロイメント」タブをクリックします。

    5. 表示されたサブ・デプロイメントをクリックします。


      注意:

      このサブデプロイメント・モジュール名は、JMSServerNameXXXXXXという形式のランダムな名前で、構成ウィザードJMS構成から生成されます。

    6. 新しく作成したJMSサーバーを割り当てます(SOAJMSServer_auto_3など)。

    7. 「保存」をクリックします。

    これを、次の表に記載されている各JMSモジュールに対して実行します。

    JMSモジュール JMSサーバー

    BPMJMSModule

    BPMJMSServer_auto_n

    JRFWSAsyncJmsModule

    JRFWSAsyncJmsServer_auto_n

    OIMJMSModule

    OIMJMSServer_auto_n

    SOAJMSModule

    SOAJMSServer_auto_n

    UMSJMSSystemResource

    UMSJMSServer_auto_n

  13. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

  14. pack、scpおよびunpackコマンドを使用して、ドメインのバックアップを作成します。これを行うには、次の手順を実行します。

    1. IDMHOST1上でpackコマンドを実行して、テンプレートを作成します。

      cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=true -domain=ASERVER_HOME -template=/templates/oim_domain.jar -template_name="OIM Domain"

    2. IDMHOST1上でscpコマンドを実行して、作成されたテンプレート・ファイルをIDMHOSTnにコピーします。例:

      scp /templates/oim_domain.jar IDMHOSTN:/templates/oim_domain.jar

    3. 次のようにIDMHOSTn上でunpackコマンドを実行し、テンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

      cd ORACLE_COMMON_HOME/oracle_common/bin
./unpack.sh -domain=MSERVER_HOME -template=/templates/oim_domain.jar -app_dir=MSERVER_HOME/applications

  15. 第12.9項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従ってOracle Coherenceを構成します。


    注意:

    変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。

  16. Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAのホストとポートを更新します。次の手順に従います。

    1. ブラウザを開き、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してOracle Enterprise Manager Fusion Middleware Controlにアクセスします。

    2. WebLogic管理アカウントweblogic_idmを使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。


      注意:

      前述の手順を実行する際に、1つ以上のOracle Identity Manager管理対象サーバーを実行している必要があります。

    3. 「Farm_IDMDomain」→「Identity and Access」→「OIM」→「oim(11.1.2.0.0)」を選択します。

    4. メニューから「システムMBeanブラウザ」を選択するか、または右クリックしてこの項目を選択します。

    5. 「アプリケーション」を選択し、定義済Mbean→「oracle.iam」を選択します。「サーバー」には「WLS_OIM1」、「アプリケーション」には「oim」を選択します。XML構成→「構成」を選択し、「XMLConfig.SOAConfig」→「SOAConfig」を選択します。

    6. 新しいSOAサーバーのホストとポートでRmiurl属性の値を更新します。「適用」をクリックして、変更を保存します。

    7. Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBにアクセスするために使用されます。これがアプリケーション・サーバーのURLです。この属性の値の例を次に示します。

      cluster:t3://soa_cluster

  17. クラスタ・アドレス・リストに新しいサーバーを追加します。

    1. WebLogic管理コンソールの「ドメイン構造」ウィンドウで「環境」ノードを展開します。

    2. 「クラスタ」をクリックします。「クラスタの概要」ページが表示されます。

    3. クラスタ名oim_clusterをクリックします。「クラスタのプロパティ」ページが表示されます。

    4. クラスタ・アドレス・リストに新しいOIM管理対象サーバーを追加します。

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

    6. この手順を繰り返して、すべての新しいSOA管理対象サーバーをsoa_clusterアドレス・リストに追加します。

  18. 新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。

    管理コンソールで、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の下の「ディレクトリ」に、デフォルト永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

  19. 新しい管理対象サーバーのホスト名検証を無効にします。管理対象サーバーWLS_SOAnおよびWLS_OIMnを起動して検証する前に、ホスト名検証を無効にする必要があります。IDMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。

    WLS_SOAnのホスト名検証を無効化する手順は次のとおりです。

    1. 「環境」ノードを「ドメイン構造」ウィンドウで開きます。

    2. Oracle WebLogic Server管理コンソールにログインします。

    3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

    4. 表の「名前」列で「WLS_SOAn」を選択します。

      サーバーの「設定」ページが表示されます。

    5. 「SSL」タブをクリックします。

    6. 「詳細」をクリックします。

    7. 「ホスト名の検証」を「なし」に設定します。

    8. 「保存」をクリックします。

    WLS_OIMnのホスト名検証を無効にするには、手順dで「名前」列にWLS_OIMnを選択し、それ以外は同じ手順を繰り返します。

  20. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

  21. 新しいノード上でノード・マネージャを起動します。ノード・マネージャを起動するには、既存ノードの共有記憶域内のインストール内容を使用して、次のように新しいノードのホスト名をパラメータとして渡してノード・マネージャを起動します。

    WL_HOME/server/bin/startNodeManager.sh

  22. Oracle WebLogic Server管理コンソールから、新しい管理対象サーバーを起動してテストします。

    1. クラスタ内の既存の管理対象サーバーをすべて停止します。

    2. 新しく作成した管理対象サーバーであるWLS_SOAnとWLS_OIMnが実行されていることを確認します。

    3. 新しく作成した管理対象サーバー上のアプリケーションにアクセスします(http://vip:port/soa-infraおよびhttp://vip:port/oim)。アプリケーションが機能している必要があります。

  23. 新しい管理対象サーバーのサーバー移行を構成します。


    注意:

    この新しいノードでは既存の共有記憶域のインストール内容が使用されているため、このノードではすでにノード・マネージャが使用されているとともに、ネットマスク、インタフェースおよびwlsifconfigスクリプトのスーパーユーザー権限が含まれたサーバー移行向けに構成された環境が使用されています。新しいノードには、すでに新しい管理対象サーバーの浮動IPアドレスが存在します。

    次の手順に従ってサーバー移行を構成します。

    1. 管理コンソールにログインします。

    2. 左側のペインで「環境」を開き、「サーバー」を選択します。

    3. 移行を構成する対象となるサーバー(ハイパーリンクとして表示)を表の「名前」列から選択します。そのサーバーの「設定」ページが表示されます。

    4. 「移行」タブをクリックします。

    5. 「移行の構成」セクションの「使用可能」フィールドで、移行を有効にするマシンを選択して、右矢印をクリックします。


      注意:

      新しいサーバーの移行ターゲットとして、最も負荷が小さいマシンを指定してください。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニング をあらかじめ行ってください。

    6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

    7. 「保存」をクリックします。

    8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

    9. 新しいサーバー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を繰り返します。

17.4.2.4 Oracle HTTP Serverのスケール・アウト

Web層には2つのノードがあり、それぞれOracle HTTP Serverインスタンスが実行されています。Oracle HTTP Serverを実行するように構成された新しいノードをWeb層に追加することで、Oracle HTTP Serverのコンポーネントをスケール・アウトできます。Oracle HTTP Serverをスケール・アウトするには、次の手順を実行します。

  1. 第10.2.3項「Oracle HTTP Serverのインストール」の手順を実行します。または、共有記憶域を使用している場合は、新しいノード上で既存のミドルウェア・ホームをマウントします。

  2. 第10章「エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成」の手順を実行します。

  3. 既存のWeb層構成のWEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconf内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。

  4. このトポロジでシングル・サインオンを有効にしている場合は、第15.7項「Webゲート11gのインストールと構成」の説明に従って、シングル・サインオンのWeb層構成を更新する必要があります。

  5. 新しいOracle HTTP Serverインスタンスのホスト情報とポート情報に基づいてロード・バランサを再構成します。

17.5 アイデンティティ管理の監査

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アプリケーション・セキュリティ・ガイド』を参照してください。

図17-1 監査イベント・フロー

図17-1については周囲のテキストで説明しています。

Oracle Fusion Middleware監査フレームワークは、次の主要コンポーネントで構成されます。

Oracle Fusion Middleware監査フレームワークの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「Oracle Fusion Middleware監査フレームワークの概要」を参照してください。

Oracle Fusion Middleware監査フレームワーク用にリポジトリを構成する方法の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査の構成と管理」を参照してください。

EDGトポロジには、Oracle Fusion Middleware監査フレームワーク構成が含まれていません。監査データをバスストップ・ファイルに生成する機能と監査ローダーの構成は、製品がインストールされた後に使用可能になります。主な留意点は、監査データを保管する監査データベース・リポジトリです。監査データのボリュームと履歴特性により、運用中のストアや他のミドルウェア・コンポーネントによって使用されるストアとは別のデータベースを使用することを強くお薦めします。

17.6 バックアップとリカバリの実行

ほとんどのバックアップでは、UNIXのtarコマンドを使用できます。一般的な使用方法は次のとおりです。

tar -cvpf BACKUP_LOCATION/backup_file.tar directories

また、リカバリでもUNIXのtarコマンドを使用できます。一般的な使用方法は次のとおりです。

tar -xvf BACKUP_LOCATION/backup_file.tar

データベースのバックアップとリカバリでは、データベース・ユーティリティのRMANを使用できます。このコマンドの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

この項には次のトピックが含まれます:

17.6.1 ベースライン・バックアップの実行

システムを構築するとき、およびOracleバイナリなどの静的なアーティファクトを更新するためのパッチを適用するときに、ベースライン・バックアップを実行します。

ベースライン・バックアップを実行した後は、ランタイム・バックアップも実行します。

表17-2 Identity Managementエンタープライズ・デプロイメントでバックアップする静的アーティファクト

タイプ 場所 タイプ コメント

データベース

ORACLE_HOME

GridのORACLE_HOME

ファイル・コピー

詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

ミドルウェア・ホーム

IAM_MW_HOME

OIM_MW_HOME脚注 1 

DIR_MW_HOME脚注 2 

ファイル・コピー

共有記憶域にあるため、1つのホストでバックアップすることのみ必要です。

Webミドルウェア・ホーム

ミドルウェア・ホーム: WEB_MW_HOME

ファイル・コピー

ローカル記憶域に置かれます。それぞれのWEBHOSTを個別にバックアップします。

インストール関連

ORACLE_BASE/orainventory

/etc/oratab、/etc/oraInst.loc

HOME/bea/beahomelist

ファイル・コピー

ローカル記憶域に置かれます。それぞれのホストを個別にバックアップします。

ロード・バランサ

ファイル・コピー

ロード・バランサの構成をバックアップします。ベンダーのドキュメントを参照してください。

サーバー

オペレーティング・システムをバックアップします。ベンダーのドキュメントを参照してください。

脚注 1 分割ドメインのみ

脚注 2 Oracle Internet DirectoryまたはOracle Virtual Directoryのインストールのミドルウェア・ホーム。Oracle Identity Managementのインストールと構成については、このガイドでは扱っていません。


注意:

ロード・バランサの構成もバックアップすることをお薦めします。その方法については、ベンダーのドキュメントを参照してください。

Oracle Fusion Middlewareコンポーネントのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

17.6.2 ランタイム・バックアップの実行

ランタイム・バックアップは継続的に実行します。ランタイム・バックアップには、データベース内のデータ、ドメイン構成情報、LDAPディレクトリ内のアイデンティティ情報など、頻繁に変更される項目の情報が含まれます。

表17-3 Identity Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト

タイプ 場所 タイプ コメント

データベース

データ

RMAN

詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

Oracle Unified Directory

OUD_ORACLE_INSTANCE

Oracle Unified Directoryのデータ

ファイル・コピー

Oracle Unified Directoryのバックアップ

ローカル記憶域に置かれます。それぞれのWEBHOSTを個別にバックアップします。

詳細は、『Oracle Fusion Middleware Oracle Unified Directory管理者ガイド』を参照してください。

コールド・バックアップの実行では、OUD_INSTANCE_HOMEのバックアップで十分です。

Oracle Internet Directory

Oracle Internet Directoryのインスタンス

データベース内のOracle Internet Directoryのデータ

ファイル・コピー

RMAN

詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

Oracle Virtual Directory

Oracle Virtual Directoryのインスタンス

ファイル・コピー

詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

サード・パーティのLDAP

バイナリ

LDAPデータ

ベンダーのドキュメントを参照してください。

ドメイン・ホーム

ASERVER_HOME

MSERVER_HOME

ファイル・コピー

ASERVER_HOMEは共有記憶域にあるため、1つのホストでバックアップすることのみ必要です。

MSERVER_HOMEはローカル記憶域に置かれます。それぞれのホストを個別にバックアップします。

Oracle HTTP Server

WEB_ORACLE_INSTANCE

ファイル・コピー

WEB_ORACLE_INSTANCEはローカル記憶域に置かれます。それぞれのWEBHOSTを個別にバックアップします。

17.6.3 インストール時および構成時のバックアップの実行

ベスト・プラクティスとしては、インストールと各層の構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

この項には次のトピックが含まれます:

17.6.3.1 ミドルウェア・ホームのバックアップ

新しいミドルウェア・ホームを作成する場合、またはミドルウェア・ホームにコンポーネントを追加する場合は、必ずミドルウェア・ホームをバックアップします。

17.6.3.2 LDAPディレクトリのバックアップ

LDAPのデータを更新する操作を実行する場合は、必ずディレクトリ・コンテンツをバックアップします。

この項には次のトピックが含まれます:

17.6.3.2.1 Oracle Unified Directoryのバックアップ

Oracle Unified Directoryをバックアップするには、次の手順を実行します。

  1. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle Unified Directoryのインスタンスを停止します。

  2. 各ホスト上のOracle Unified Directoryインスタンスのディレクトリをバックアップします。

  3. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle Unified Directoryのインスタンスを再起動します。

17.6.3.2.2 Oracle Internet Directoryのバックアップ

Oracle Internet Directoryのインスタンスをバックアップするには、次の手順を実行します。

  1. OID_ORACLE_INSTANCE/binディレクトリにあるopmnctlを使用してインスタンスを停止します。

    OID_ORACLE_INSTANCE/bin/opmnctl stopall

  2. Oracle Internet Directoryのデータをホストしているデータベース、および各ホスト上のOracle Internet Directoryインスタンス・ホームをバックアップします。

  3. OID_ORACLE_INSTANCE/binディレクトリにあるopmnctlを使用してインスタンスを起動します。

    OID_ORACLE_INSTANCE/bin/opmnctl startall
17.6.3.2.3 Oracle Virtual Directoryのバックアップ

Oracle Virtual Directoryのインスタンスをバックアップするには、次の手順を実行します。

  1. OVD_ORACLE_INSTANCE/binディレクトリにあるopmnctlを使用してインスタンスを停止します。

    OVD_ORACLE_INSTANCE/bin/opmnctl stopall

  2. 各LDAPホスト上のOracle Virtual Directoryインスタンス・ホームをバックアップします。

  3. OVD_ORACLE_INSTANCE/binディレクトリにあるopmnctlを使用してインスタンスを起動します。

    OVD_ORACLE_INSTANCE/bin/opmnctl startall
17.6.3.2.4 サード・パーティのディレクトリのバックアップ

ディレクトリのバックアップの詳細は、オペレーティング・システムのベンダーのドキュメントを参照してください。

17.6.3.3 データベースのバックアップ

構成にコンポーネントを追加して作成する場合は、必ずIDMDBデータベースをバックアップします。このバックアップは、ドメインを作成した後、またはAccess Managerなどのコンポーネントを追加した後に実行します。

17.6.3.4 WebLogicドメインのバックアップ

WebLogicドメインをバックアップするには、次の手順を実行します。

  1. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、ドメインで実行されているWebLogic管理サーバーとすべての管理対象サーバーを停止します。

  2. 共有記憶域のASERVER_HOMEディレクトリをバックアップします。

  3. 各ホストのMSERVER_HOMEディレクトリをバックアップします。

17.6.3.5 Web層のバックアップ

Web層をバックアップするには、次の手順を実行します。

  1. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを停止します。

  2. WEB_ORACLE_INSTANCEをバックアップします。

  3. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを起動します。

17.7 エンタープライズ・デプロイメントへのパッチ適用

この項では、Oracle Fusion Middlewareのパッチ・ファイルを適用する方法、および最小限の停止時間でOracle Identity Managementコンポーネントにパッチを適用する方法を説明します。

この項には次のトピックが含まれます:

17.7.1 Oracle Fusion Middlewareソース・ファイルへのパッチ適用

Oracle Fusion Middlewareソース・ファイルへのパッチ適用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

17.7.2 Identity and Access Managementへのパッチ適用

シングル・ドメインのトポロジでは、次のようにパッチを適用します。

IDMDomainのMW_HOME

  • 共通のパッチ

  • Oracle Access Managerのパッチ

  • Oracle Identity Managerのパッチ

  • IDMツールのパッチ

17.7.3 Oracle Unified Directoryのコンポーネントへのパッチ適用

最小限の停止時間でOracle Identity Managementコンポーネントにパッチを適用するには、次の指示に従うことをお薦めします。

  1. LDAPのトラフィックをIDMHOST1からIDMHOST2にルーティングします。

  2. パッチを適用するホスト(IDMHOST1)のOracle Unified DirectoryサーバーまたはOracle Virtual Directoryサーバーを停止します。

  3. パッチを適用します。

  4. Oracle Unified Directoryを再起動します。

  5. パッチをテストします。

  6. トラフィックを再びLDAPHOST1にルーティングします。

  7. アプリケーションが正常に動作していることを確認します。

  8. IDMHOST2のLDAPのトラフィックをIDMHOST1にルーティングします。

  9. IDMHOST2に関しても手順2-5を繰り返します。

  10. パッチを適用した両方のホスト(IDMHOST1とIDMHOST2)にトラフィックをルーティングします。

17.8 SQLのタイムアウトの防止

ほとんどの本番デプロイメント環境ではファイアウォールが使用されます。データベース接続は複数のファイアウォールにまたがって確立されるため、データベース接続がタイムアウトにならないようにファイアウォールを構成することをお薦めします。Oracle Real Application Cluster (Oracle RAC)については、データベース接続はOracle RAC VIPとデータベース・リスナー・ポートを使用して確立されます。ファイアウォールがこれらの接続をタイムアウトさせないように構成する必要があります。そのような構成が不可能な場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルで、SQLNET.EXPIRE_TIME=nというパラメータを設定します(nは分単位の時間)。この値を、ネットワーク・デバイス(ファイアウォール)の既知のタイムアウト値より小さい値に設定します。Oracle RACについては、このパラメータをすべてのOracleホーム・ディレクトリで設定します。

17.9 WebLogic管理サーバーの手動フェイルオーバー

この項では、管理サーバーをIDMHOST2にフェイルオーバーする方法と、これをIDMHOST1にフェイルバックする方法について説明します。

作成したすべてのドメインに同じ手順を適用できます。

この項には次のトピックが含まれます:

17.9.1 IDMHOST2への管理サーバーのフェイルオーバー

あるノードで障害が発生した場合、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーを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は、この時点ではドメインを制御しません。これは、unpack/nmEnrollがまだIDMHOST2上で実行されていないからです。ただし、AdminServerのフェイルオーバー、およびAdminServer自体の制御に対しては、ノード・マネージャは完全に機能します。

  • Oracle WebLogic ServerおよびOracle Fusion Middlewareコンポーネントは前の章の説明のとおり、IDMHOST2にインストールされている。つまり、IDMHOST1に存在するIDM_ORACLE_HOMEとMW_HOMEのパスは、IDMHOST2でも使用できます。

次の手順は、管理サーバーを異なるノード(IDMHOST2)にフェイルオーバーする方法を示します。

Linux

  1. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、管理サーバーを停止します。

  2. IPアドレスを2番目のノードに移行します。

    1. IDMHOST1で次のコマンドをrootとして実行します(ここでx:yはADMINVHN.mycompany.comが使用する現在のインタフェースです)。

      /sbin/ifconfig x:y down

      例:

      /sbin/ifconfig eth0:1 down

    2. IDMHOST2で次のコマンドを実行します。

      /sbin/ifconfig interface:index IP_Address netmask netmask

      例:

      /sbin/ifconfig eth0:1 10.0.0.1 netmask 255.255.255.0

    注意:

    使用するネットマスクおよびインタフェースがIDMHOST2の使用可能なネットワーク構成と一致することを確認します。

  3. arpingを使用してルーティング表を更新します。例:

    /sbin/arping -q -U -c 3 -I eth0 10.0.0.1

17.9.2 IDMHOST2上での管理サーバーの起動

次の手順を実行して、IDMHOST2上でノード・マネージャを起動します。

  1. IDMHOST1上で、管理サーバー・ドメイン・ディレクトリをアンマウントします。例:

    umount /u01/oracle

  2. IDMHOST2で、管理サーバー・ドメイン・ディレクトリをマウントします。例:

    mount /u01/oracle

  3. 次のコマンドを使用してノード・マネージャを起動します。

    cd WL_HOME/server/bin
./startNodeManager.sh

  4. ノード・マネージャ・プロセスを強制終了してノード・マネージャを停止します。


    注意:

    この時点でのノード・マネージャの起動および停止は、ノード・マネージャを初めて実行するときにのみ必要です。起動および停止により、前もって定義されたテンプレートからプロパティ・ファイルが作成されます。次の手順では、そのプロパティ・ファイルにプロパティを追加します。

  5. setNMProps.shスクリプトを実行して、ノード・マネージャを起動する前にStartScriptEnabledプロパティをtrueに設定します。

    cd MW_HOME/oracle_common/common/bin
./setNMProps.sh

    注意:

    クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。

  6. 第17.1.5.3項「管理サーバーのノード・マネージャの起動」を参照して、ノード・マネージャを起動します。

  7. IDMHOST2上で管理サーバーを起動します。

    cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

    WLSTシェルで一度、次のコマンドを実行します。

    nmConnect('Admin_User','Admin_Password', 'IDMHOST2','5556', 'IDMDomain','ASERVER_HOME')
nmStart('AdminServer')

    注意:

    WLSTのnmConnectコマンドのASERVER_HOMEにはフルパス名を使用します。

17.9.3 Oracle HTTP Serverを使用したIDMHOST2へのアクセスの検証

  1. 次のアドレスを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。

    http://ADMINVHN.mycompany.com/console

    ここで、7001は第B.3項のWLS_ADMIN_PORTに相当します。

  2. 次のアドレスを使用してOracle Enterprise Managerのコンポーネントのステータスにアクセスし、検証できることを確認します。

    http://ADMINVHN.mycompany.com/em

分割ドメイン・トポロジを使用しており、IDMHOST2で管理サーバーが実行されている場合は、同じ手順を実行してその管理サーバーにアクセスできることを確認します。

17.9.4 IDMHOST1への管理サーバーのフェイルバック

この手順では、管理サーバーをフェイルバックできる(つまり、IDMHOST2上で停止し、IDMHOST1上で実行できる)ことを確認します。これを行うには、次の手順に従って、ADMINVHNを元のIDMHOST1ノードに移行して戻します。

  1. 管理サーバーが実行されていないことを確認してください。管理サーバーが実行中の場合、WebLogicコンソールから停止するか、またはコマンドstopWebLogic.shをASERVER_HOME/binから実行します。

  2. IDMHOST2上で、管理サーバー・ドメイン・ディレクトリをアンマウントします。例:

    umount /u01/oracle

  3. IDMHOST1上で、管理サーバー・ドメイン・ディレクトリをマウントします。例:

    mount /u01/oracle

  4. IDMHOST2上のADMINVHN.mycompany.comの仮想IPアドレスを無効にして、IDMHOST2で次のコマンドをrootとして実行します。

    /sbin/ifconfig x:y down

    例:

    /sbin/ifconfig eth0:1 down

  5. IDMHOST1で次のコマンドを実行します。

    /sbin/ifconfig interface:index IP_Address netmask netmask

    例:

    /sbin/ifconfig interface:index 100.200.140.206 netmask 255.255.255.0

    注意:

    使用するネットマスクおよびインタフェースがIDMHOST1の使用可能なネットワーク構成と一致することを確認します。

  6. 次のコマンドを実行してルーティング表を更新します。

    /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

  7. ノード・マネージャがまだIDMHOST1上で起動されていない場合は、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って起動します。

  8. IDMHOST1で管理サーバーを再起動します。

    cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

    WLSTシェルが開始されたら、次のコマンドを実行します。

    nmConnect(Admin_User,'Admin_Password, IDMHOST1,'5556','IDMDomain','ASERVER_HOME')
nmStart('AdminServer')

  9. 次のアドレスを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。

    http://ADMINVHN.mycompany.com:7001/console

    ここで、7001は第B.3項のWLS_ADMIN_PORTに相当します。

  10. 次のアドレスを使用してOracle Enterprise Managerのコンポーネントのステータスにアクセスし、検証できることを確認します。

    http://ADMINVHN.mycompany.com:7001/em

17.10 トラブルシューティング

この項では、このマニュアルで説明しているIdentity Managementエンタープライズ・デプロイメントで発生する可能性のある一般的な問題のトラブルシューティング方法を説明します。

この項には次のトピックが含まれます:

17.10.1 Oracle Internet Directoryのトラブルシューティング

この項では、Oracle Internet Directoryで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

17.10.1.1 Oracle Internet Directoryサーバーが応答しない

問題

Oracle Internet Directoryサーバーが応答しません。監視のためLDAP SSLポートにICMPメッセージを送信するようにロード・バランシング・ルーターを構成すると、SSLネゴシエーションを開始したOracle Internet Directoryサーバーがハングすることがあります。これにより、ロード・バランシング・ルーターでは、LDAP SSLポートを監視するためのICMPメッセージを使用できません。

ソリューション

TCPやLDAPのプロトコル自体など、別のものを使用してください。

また、LDAPの非SSLポートを監視することも、LDAP可用性を検出するのに十分です。

17.10.1.2 SSO/LDAPアプリケーションの接続のタイムアウト

問題

Oracle Internet DirectoryサーバーへのSSO/LDAPアプリケーション接続が切断されています。

ソリューション

ロード・バランシング・ルーターのタイムアウトとSSO/Applicationタイムアウト構成パラメータを確認してください。SSO/LDAPアプリケーションのタイムアウト値は、LBR IDLEタイムアウト値未満にする必要があります。

17.10.1.3 LDAPアプリケーションがLDAPエラー53を受け取る(DSAが動作しない)

問題

LDAPアプリケーションがLDAPエラー53 (DSAが動作しようとしない)を受信しています。LDAPトランザクションの途中でいずれかのデータベース・ノードが停止すると、Oracle Internet Directoryサーバーはエラー53をLDAPクライアントに送信します。

ソリューション

Oracle Internet Directoryデータベース・ノードが停止した理由を確認するには、次の場所にあるOracle Internet Directoryのログを参照してください。

ORACLE_INSTANCE/diagnostics/logs/OID/oidldapd01s*.log

17.10.1.4 TNSNAMES.ORA、TAF構成および関連する問題

問題

TNSNAMES.ORAやTAFの構成に関連した問題があります。

ソリューション

Oracle Databaseの高可用性の概要に関するマニュアルを参照してください。

17.10.2 Oracle Virtual Directoryのトラブルシューティング

この項では、Oracle Virtual Directoryで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

17.10.2.1 SSLServerConfig.sh実行時のコマンドが見つからないエラー

問題

SSLServerConfig.shを実行すると、次のようにcommand not foundエラーが発生します。

./SSLServerConfig.sh: line 169: 20110520125611: command not found

ソリューション

ファイルorapki.sh (Linuxの場合)を編集して、ファイル末尾にある空白行をすべて削除します。このファイルを保存して、SSLServerConfig.shを再度実行します。

17.10.2.2 Oracle Virtual Directoryが応答しない

問題

Oracle Virtual Directoryが応答しません。監視のためLDAP SSLポートにICMPメッセージを送信するようにロード・バランシング・ルーターを構成すると、SSLネゴシエーションを開始したOracle Virtual Directoryサーバーがハングすることがあります。これにより、ロード・バランシング・ルーターでは、LDAP SSLポートを監視するためのICMPメッセージを使用できません。

ソリューション

TCPやLDAPのプロトコル自体など、別のものを使用してください。

また、LDAPの非SSLポートを監視することも、LDAP可用性を検出するのに十分です。

17.10.2.3 SSO/LDAPアプリケーションの接続のタイムアウト

問題

Oracle Virtual DirectoryサーバーへのSSO/LDAPアプリケーション接続が切断されています。

ソリューション

ロード・バランシング・ルーターのタイムアウトとSSO/Applicationタイムアウト構成パラメータを確認してください。SSO/LDAPアプリケーションのタイムアウト値は、LBR IDLEタイムアウト値未満にする必要があります。

17.10.2.4 TNSNAMES.ORA、TAF構成および関連する問題

問題

TNSNAMES.ORAやTAFの構成に関連した問題があります。

ソリューション

Oracle Databaseの高可用性の概要に関するマニュアルを参照してください。

17.10.2.5 SSLServerConfig.shがエラーで失敗する

問題

コンポーネント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

ソリューション

この問題は断続的に発生します。この問題を回避するには、スクリプトを再実行します。

17.10.3 Access Manager 11gのトラブルシューティング

この項では、Access Managerで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

17.10.3.1 セッション数が最大許容値に達した

問題

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. 「システム構成」→「共通構成」→「セッション」を選択します。

  2. どのユーザーにも想定されるすべての同時ログイン・セッションに対処できるように、「1ユーザー当たりの最大セッション数」フィールドの値を大きくします。このフィールドには、1以上の任意の値を指定できます。

17.10.3.2 Oracle Access Managerを初めてインストールしたときにポリシーが作成されない

問題

Oracle Access Managerを構成した後、管理サーバーの起動に長時間を要します。

ソリューション

OAMデータベースをチューニングします。Oracle Access Managerを構成した後で管理サーバーを初めて起動すると、データベースにいくつかのデフォルト・ポリシーが作成されます。データベースが遠方にある場合やチューニングを必要とする場合は、この作業に膨大な時間を要することがあります。

Resources
Authentication Policies
   Protected Higher Level Policy
   Protected Lower Level Policy
   Publicl Policy
Authorization Policies
   Authorization Policies

これらの項目が表示されない場合は、最初の移入に失敗しています。管理サーバーのログ・ファイルで詳細を確認します。

17.10.3.3 保護されたリソースにアクセスしても、資格証明を要求するメッセージが表示されない

問題

保護されたリソースにアクセスすると、本来はOracle Access Managerからユーザー名とパスワードの入力を要求されます。たとえば、簡単なHTMLページを作成してリソースとして追加すると、資格証明の入力画面が表示されます。

ソリューション

資格証明の入力画面が表示されない場合は、次の手順を実行します。

  1. IDMDomainのホストの別名が設定されていることを確認します。IDMDomain:80、IDMDomain:Null、ADMIN.mycompany.com:80およびSSO.mycompany.com:443の別名が必要です。ここで、ポート80はHTTP_PORT、ポート443はHTTP_SSL_PORTです。

  2. Webゲートがインストールされていることを確認します。

  3. ASERVER_HOME/outputからWebゲートのLibディレクトリにOBAccessClient.xmlがコピーされ、OHSが再起動されたことを確認します。

  4. OBAccessClient.xmlが最初に作成されたとき、このファイルは適切な形式になっていません。OHSを再起動すると、そのファイルが再検査されて適切な形式になります。OHSを初めて起動すると、このファイルの新しいバージョンがOracle Access Managerから取得されます。

  5. Oracle Access Managerサーバーを停止し、保護されたリソースへのアクセスを試みます。Oracle Access Managerサーバーが使用できないというエラーが表示されます。このエラーが表示されない場合は、Webゲートをインストールしなおします。

17.10.3.4 OAMコンソールにログインできない

問題

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*のファイルを削除し、管理サーバーを再起動します。

17.10.4 Oracle Identity Managerのトラブルシューティング

この項では、Oracle Identity Managerで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

17.10.4.1 Oracle Identity Managerの構成実行時のjava.io.FileNotFoundException

問題

Oracle Identity Manager構成を実行すると、java.io.FileNotFoundException: soaconfigplan.xml (Permission denied)のエラーが表示され、Oracle Identity Manager構成が失敗することがあります。

ソリューション

この問題を回避するには、次の手順を実行します。

  1. ファイル/tmp/oaconfigplan.xmlを削除します。

  2. 構成を再度起動します(IAM_ORACLE_HOME/bin/config.sh)。

17.10.4.2 Oracle Identity Managerでのユーザー作成時のResourceConnectionValidationxception

問題

アクティブ/アクティブ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)
         .
         .
         .

ソリューション

この例外が発生しても、ユーザーは正しく作成されます。

17.10.5 Oracle SOA Suiteのトラブルシューティング

この項では、Oracle SOA Suiteで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

17.10.5.1 トランザクション・タイムアウト・エラー

問題: 次のトランザクション・タイムアウト・エラーがログに表示されます。

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構成は正しく動作します。特定の操作に想定されるトランザクション時間に合せて、これらの値を調整します。

17.10.6 My Oracle Supportを使用したその他のトラブルシューティング情報

Oracle Fusion Middlewareの問題の解決にMy Oracle Support(以前のMetaLink)を使用できます。My Oracle Supportには、次のような有用なトラブルシューティング・リソースが含まれています。

  • ナレッジ・ベース記事

  • コミュニティ・フォーラムとディスカッション

  • パッチとアップグレード

  • 動作保証情報


注意:

サービス・リクエストを登録する場合にMy Oracle Supportを使用することもできます。

My Oracle Supportにはhttps://support.oracle.comからアクセスできます。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引