| Oracle® Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド 11gリリース2 (11.1.2.2.0) B71694-10 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド 11gリリース2 (11.1.2.2.0) B71694-10 |
|
前 |
次 |
この章では、Identity Management and Accessのトポロジの設定後に実行できる操作について説明します。実行できる操作には、トポロジの監視、スケーリング、バックアップ、トラブルシューティングなどがあります。
この章の内容は次のとおりです。
この項では、Oracleエンタープライズ・デプロイメントの各種コンポーネントを起動、停止および再起動する方法を説明します。
この項には次のトピックが含まれます:
インフラストラクチャ全体を起動するときは、次の順序で各コンポーネントを起動します(トポロジ内に存在しないコンポーネントは無視してください)。
データベース
データベース・リスナー
LDAPホスト
OAMホスト
OIMホスト
Webホスト
Oracle Identity Manager管理対象サーバー
アイデンティティ・アクセス・ドメインのWebLogic管理サーバー
Oracle Access Management Access Managerサーバー
OAAM管理サーバー
OAAM管理対象サーバー(OAAMがトポロジの一部の場合)
Oracle HTTP Server
環境内のすべてのサーバーを起動および停止するためのスクリプトが、デプロイメント中にSHARED_CONFIG_DIR/config/scriptsディレクトリに作成されています。コマンド行から使用してすべてのIdentity and Access Managementサーバーを起動および停止できるスクリプトが2つあります。残りのスクリプトは内部的に使用され、コマンド行からは実行しません。
|
注意: これらのスクリプトは、データベースの起動および停止は行いません。 |
特定のサーバーのコンポーネントすべてを起動するには、デプロイメントで作成されたstartall.shというファイルを使用します。すべてを正しい順序で起動するには、ホスト上で次の順序でコマンドを実行します。
統合トポロジ
LDAPHOST1
LDAPHOST2
IAMHOST1
IAMHOST2
WEBHOST1
WEBHOST2
分散トポロジ
LDAPHOST1
LDAPHOST2
OAMHOST1
OIMHOST1
OAMHOST2
OIMHOST2
WEBHOST1
WEBHOST2
単一のホスト上のサービスを起動するには、そのホスト上でコマンドを実行します。
実行中、Weblogicおよびノード・マネージャの管理者パスワードを入力するように要求されます。
スクリプトにより、特定のホストにインストールされているコンポーネントが次の順序で起動されます。何が起動されるかは、スクリプトを実行中のホストにインストールされているものによって異なります。
Oracle Unified Directory
ノード・マネージャ
管理サーバー
SOA管理対象サーバー
OIM管理対象サーバー
OAM管理対象サーバー
Oracle HTTP Server
OAAM管理対象サーバー
次の各項での説明に従って、個々のIdentity and Access Managementコンポーネントを起動および停止します。
Oracle Unified Directoryは次のように起動および停止します。
Oracle Unified Directoryを起動するには、次のコマンドを実行します。
OUD_ORACLE_INSTANCE/OUD/bin/start-ds
通常、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','IAD_MSERVER_HOME')
nmStart('wls_oam1')
ここで、PortはNMGR_PORT、domain_nameはドメインの名前、Admin_UserおよびAdmin_Passwordはノード・マネージャのユーザー名およびパスワードです。たとえば、次のようになります。
nmConnect('weblogic','password', 'OAMHOST1','5556', 'IAMAccessDomain','IAD_MSERVER_HOME')
Access Manager管理対象サーバーがすでに実行している場合、他のWebLogic管理対象サーバーを起動するのと同じように、WebLogic管理コンソールからAccess Manager管理対象サーバーを起動できます。
次の項の説明に従って、WebLogic管理サーバーの起動と停止を行います。
|
注意:
|
管理サーバーを起動するために推奨される方法は、WLSTを使用してノード・マネージャに接続することです。
cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
ここで、ORACLE_COMMON_HOMEは、起動または停止するドメインに関連するMW_HOMEのものです。
アクセス・ドメインで管理サーバーを起動するには、次のコマンドを使用します。
nmConnect('Admin_User','Admin_Password','IADADMINVHN','5556', 'IAMAccessDomain','IAD_ASERVER_HOME')
nmStart('AdminServer')
例:
nmConnect('Admin_User','Admin_Password','IADADMINVHN','5556', 'IAMAccessDomain','/u01/oracle/config/domains/IAMAccessDomain')
nmStart('AdminServer')
次のコマンドを実行して、ガバナンス・ドメインで管理サーバーを起動します。
nmConnect('Admin_User','Admin_Password','IGDADMINVHN','5556', 'IAMGovernanceDomain','IGD_ASERVER_HOME')
nmStart('AdminServer')
例:
nmConnect('weblogic','password', 'IADADMINVHN','5556', 'IAMAccessDomain','IAD_MSERVER_HOME')
または、次のコマンドを使用して管理サーバーを起動することもできます。
ASERVER_HOME/bin/startWebLogic.sh
管理サーバーを停止するには、第15章「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。
次のように実行します。
「制御」タブをクリックします。
「AdminServer(admin)」を選択します。
「停止」をクリックし、「ただちに強制停止」を選択します。
管理サーバーを停止してよいか確認を求められたら「はい」をクリックします。
管理対象サーバーは次のように起動および停止します。
管理対象サーバーを起動するには、第15章「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。
次のように実行します。
「制御」タブをクリックします。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
wls_oim1などの管理対象サーバーを選択します。
「起動」ボタンをクリックします。
サーバーを起動してよいか確認を求められたら、「はい」をクリックします。
管理対象サーバーを停止するには、第15章「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。その後、次のようにします。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブをクリックします。
wls_oim1などの管理対象サーバーを選択します。
「停止」ボタンをクリックしてから、「ただちに強制停止」を選択します。
サーバーを停止してよいか確認を求められたら、「はい」をクリックします。
ノード・マネージャを起動および停止するには、次のようにします。
起動しようとするノード・マネージャが、管理サーバーを制御するノード・マネージャである場合は、その起動の前に次のコマンドを発行します。
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
ノード・マネージャを起動するには、次のコマンドを実行します。
cd SHARED_CONFIG_DIR/nodemanager/hostname ./startNodeManagerWrapper.sh
表15-1は、このガイドの中で使用されている管理コンソールとそのURLの一覧です。
表15-1 コンソールのURL
| ドメイン | コンソール | URL | ユーザー名 |
|---|---|---|---|
|
IAMAccessDomain |
WebLogic管理コンソール |
|
|
|
Enterprise Manager FMWコントロール |
|
|
|
|
Access Managementコンソール |
|
|
|
|
OAAMサーバー |
|
n/a |
|
|
OAAM管理コンソール |
|
|
|
|
IAMGovernanceDomain |
WebLogic管理コンソール |
|
|
|
Enterprise Manager FMWコントロール |
|
|
|
|
Identity Managerシステム管理コンソール |
|
|
|
|
Identity Managerセルフ・サービス・コンソール |
|
|
|
|
認可ポリシー・マネージャ |
|
|
この項では、このマニュアルで説明しているIdentity and Access Managementエンタープライズ・デプロイメントの監視について説明します。
この項には次のトピックが含まれます:
次のコマンドを実行することによって、Oracle Unified Directoryのステータスを確認できます。
OUD_ORACLE_INSTANCE/OUD/bin/status
このコマンドは、ローカルで実行されているOracle Unified Directoryのインスタンスにアクセスし、ディレクトリのステータスをレポートします(レプリケーションの有効/無効、LDAPまたはLDAPSの有効/無効など)。
Oracle Enterprise Manager Fusion Middleware Controlを使用すると、管理対象サーバーおよび他のFusion Middlewareコンポーネント(Access Manager、Oracle Identity Manager、Oracle Identity Federation、SOAなど)を監視できます。詳細は、「関連ドキュメント」の「はじめに」で一覧表示されている各管理者ガイドを参照してください。
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アプリケーションと同様、エンドツーエンドのフレームワーク構造を実現します。
図15-1は、Oracle Fusion Middleware監査フレームワーク・アーキテクチャの概要図です。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
Oracle Fusion Middleware監査フレームワークは、次の主要コンポーネントで構成されます。
監査API
このAPIは、Oracle Fusion Middleware監査フレームワークと統合される監査対応の任意のコンポーネントのために、監査フレームワークによって提供されます。これらのAPIは、実行中にアプリケーション・コード内で発生している特定イベントに関する必要な情報を監査するためにアプリケーションによってコールします。アプリケーションはこのインタフェースにより、監視対象イベントのコンテキストの提供に必要な、ユーザー名やその他属性などのイベント詳細を指定できます。
監査イベントと構成
Oracle Fusion Middleware監査フレームワークでは、アプリケーションの監査イベントに簡単にマッピングできる一連の汎用イベントが提供されます。それらの汎用イベントには、認証などの共通のイベントも含まれています。このフレームワークでは、アプリケーションでアプリケーション固有イベントも定義できます。
これらのイベントの定義と構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。構成は、Enterprise Manager (UI)およびWLST(コマンド行ツール)で更新できます。
監査バスストップ
バスストップは、監査リポジトリに送られる前の監査データを含むローカル・ファイルです。データベース・リポジトリが構成されていない場合には、バスストップ・ファイルをファイル・ベースの監査リポジトリとして使用できます。バスストップ・ファイルは、問い合せて特定の監査イベントを簡単に見つけることができるシンプルなテキスト・ファイルです。DBベースのリポジトリが作成されると、バスストップはコンポーネントと監査リポジトリの間で仲介役を勤めます。ローカル・ファイルは構成された周期で定期的に監査リポジトリにアップロードされます。
監査ローダー
名前が示すように、監査ローダーは監査バスストップから監査リポジトリにファイルをロードします。プラットフォームおよびJavaEEアプリケーション監査の場合、監査ローダーはJavaEEコンテナの起動と同時に起動されます。システム・コンポーネントの場合、監査ローダーは定期的に発生するプロセスです。
監査リポジトリ
監査リポジトリには、リポジトリ作成ユーティリティ(RCU)によって作成された定義済Oracle Fusion Middleware監査フレームワーク・スキーマが含まれます。一度構成されると、すべての監査ローダーはリポジトリを認識し、それに定期的にデータをアップロードします。監査リポジトリ内の監査データは累積され時間の経過とともに増加します。監査ストアは、他のアプリケーションによって使用される運用データベースではなく、監査専用のスタンドアロン型RDBMSであるのが理想的です。高可用性構成の場合、監査データ・ストアとしてOracle Real Application Cluster (RAC)データベースの使用をお薦めします。
Oracle Business Intelligence Publisher
監査リポジトリ内のデータは、Oracle Business Intelligence Publisherの定義済レポートにより出力されます。このレポートでは、監査データを様々な条件に基づいてドリルダウンできます。例:
ユーザー名
時間範囲
アプリケーション・タイプ
実行コンテキストID (ECID)
Oracle Fusion Middleware監査フレームワークの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「Oracle Fusion Middleware監査フレームワークの概要」を参照してください。
Oracle Fusion Middleware監査フレームワーク用にリポジトリを構成する方法の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査の構成と管理」を参照してください。
EDGトポロジには、Oracle Fusion Middleware監査フレームワーク構成が含まれていません。監査データをバスストップ・ファイルに生成する機能と監査ローダーの構成は、製品がインストールされた後に使用可能になります。主な留意点は、監査データを保管する監査データベース・リポジトリです。監査データのボリュームと履歴特性により、運用中のストアや他のミドルウェア・コンポーネントによって使用されるストアとは別のデータベースを使用することを強くお薦めします。
ほとんどのバックアップでは、UNIXのtarコマンドを使用できます。一般的な使用方法は次のとおりです。
tar -czvpsPf BACKUP_LOCATION/backup_file.tar directories
また、リカバリでもUNIXのtarコマンドを使用できます。一般的な使用方法は次のとおりです。
tar -xzvpsPf BACKUP_LOCATION/backup_file.tar
データベースのバックアップとリカバリでは、データベース・ユーティリティのRMANを使用できます。このコマンドの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
この項には次のトピックが含まれます:
システムを構築するとき、およびOracleバイナリなどの静的なアーティファクトを更新するためのパッチを適用するときに、ベースライン・バックアップを実行します。
ベースライン・バックアップを実行した後は、ランタイム・バックアップも実行します。
表15-2 Identity and Access Managementエンタープライズ・デプロイメントでバックアップする静的アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
Oracleホーム(データベース) |
Oracle RACデータベースのホスト: IAMDBHOST1 IAMDBHOST2 |
ユーザー定義 |
データベース |
|
Oracle Unified Directoryバイナリ |
LDAPHOST1 LDAPHOST2 |
Middlewareホーム: |
ディレクトリ層 |
|
Oracle Access Managementバイナリ |
OAMHOST1 OAMHOST2 |
Middlewareホーム: |
アプリケーション層 |
|
Oracle Identity Governanceバイナリ |
OIMHOST1 OIMHOST2 |
Middlewareホーム: |
アプリケーション層 |
|
Web層バイナリ |
WEBHOST1 WEBHOST2 |
Middleware Oracleホーム、 |
Web層 |
|
インストール関連ファイル |
各ホスト |
OraInventory:
|
対象外 |
|
注意: ロード・バランサの構成もバックアップすることをお薦めします。その方法については、ベンダーのドキュメントを参照してください。 |
Oracle Fusion Middlewareコンポーネントのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
ランタイム・バックアップは継続的に実行します。ランタイム・バックアップには、データベース内のデータ、ドメイン構成情報、LDAPディレクトリ内のアイデンティティ情報など、頻繁に変更される項目の情報が含まれます。
表15-3 Identity and Access Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
IAMAccessDomainホーム |
OAMHOST1 OAMHOST2 |
管理サーバーおよび共有ファイル: 管理対象サーバー: |
アプリケーション層 |
|
IAMGovernanceDomainホーム |
OIMHOST1 OIMHOST2 |
管理サーバーおよび共有ファイル: 管理対象サーバー: |
アプリケーション層 |
|
Oracle HTTP Server |
WEBHOST1 WEBHOST2 |
|
Web層 |
|
Oracle RACデータベース |
IAMDBHOST1 IAMDBHOST2 |
ユーザー定義 |
ディレクトリ層 |
|
Oracle Unified Directory |
LDAPHOST1 LDAPHOST2 |
|
アプリケーション層 |
ベスト・プラクティスとしては、インストールと各層の構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。
詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
この項には次のトピックが含まれます:
新しいMiddlewareホームを作成する場合、またはMiddlewareホームにコンポーネントを追加する場合には、必ずMiddlewareホームをバックアップします。このガイドで使用されるMiddlewareホームは、表15-2に示されるOracle Identity ManagementおよびOracle Identity and Access Managementです。
LDAPのデータを更新する操作を実行する場合は、必ずディレクトリ・コンテンツをバックアップします。
この項には次のトピックが含まれます:
Oracle Unified Directoryをバックアップするには、次の手順を実行します。
第15.1項「コンポーネントの起動と停止」の説明に従って、Oracle Unified Directoryのインスタンスを停止します。
各ホスト上のOUD_ORACLE_INSTANCEディレクトリをバックアップします。
第15.1項「コンポーネントの起動と停止」の説明に従って、Oracle Unified Directoryのインスタンスを再起動します。
ディレクトリのバックアップの詳細は、オペレーティング・システムのベンダーのドキュメントを参照してください。
構成にコンポーネントを追加して作成する場合は、必ずIAMDBデータベースをバックアップします。このバックアップは、ドメインの作成またはOracle Access Management Access ManagerまたはOracle Identity Managerなどのコンポーネントの追加後に実行します。
WebLogicドメインをバックアップするには、次の手順を実行します。
第15.1項「コンポーネントの起動と停止」の説明に従って、ドメインで実行されているWebLogic管理サーバーとすべての管理対象サーバーを停止します。
共有記憶域のIGD_ASERVER_HOMEディレクトリをバックアップします。
各ホストのIGD_MSERVER_HOMEディレクトリをバックアップします。
WebLogic管理サーバーおよび管理対象サーバーを再起動します。
WebLogicドメインをバックアップするには、次の手順を実行します。
第15.1項「コンポーネントの起動と停止」の説明に従って、ドメインで実行されているWebLogic管理サーバーとすべての管理対象サーバーを停止します。
共有記憶域のIAD_ASERVER_HOMEディレクトリをバックアップします。
各ホストのIAD_MSERVER_HOMEディレクトリをバックアップします。
WebLogic管理サーバーおよび管理対象サーバーを再起動します。
Web層をバックアップするには、次の手順を実行します。
次のように、Oracle HTTP Serverをバックアップします。
第15.1項「コンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを停止します。
ローカル記憶域上のWEB_ORACLE_INSTANCEディレクトリをバックアップします。
第15.1項「コンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを起動します。
Identity and Access Managementライフサイクル・ツールとともに含まれる自動パッチ適用ソリューションを使用して、エンタープライズ・デプロイメントにパッチを適用することをお薦めします。
次にパッチ適用のプロセスをまとめます。
パッチ最上位を作成します。パッチ最上位ディレクトリには、パッチが適用される各製品ごとに分類されたパッチが含まれます。
パッチ・マネージャを実行して、パッチ計画を生成します。デプロイメント・トポロジおよび提供されたパッチに基づいて、マネージャがそれらのパッチに適用する最適な計画を作成します。
計画による影響を受けるすべてのホストに対してPatcherを実行します。特定の計画で必要とされる場合、特定のホストで複数回Patcherを実行する必要がある場合があります。各Patcherの実行が完了するごとに、次のPatcherを実行する場所が指示されます。
Patcherを実行する際に、必要に応じてサーバー・インスタンスを停止または起動し、パッチが正しい順序で適用されて依存性が満たされるようにします。
IDMパッチ適用フレームワークの使用方法の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementパッチ適用ガイド』に記載されています。また、このガイドには、必要に応じてOPatchツールを使用して手動でデプロイメントにパッチ適用する説明も記載されています。
ほとんどの本番デプロイメント環境ではファイアウォールが使用されます。データベース接続は複数のファイアウォールにまたがって確立されるため、データベース接続がタイムアウトにならないようにファイアウォールを構成することをお薦めします。Oracle Real Application Cluster (Oracle RAC)については、データベース接続はOracle RAC VIPとデータベース・リスナー・ポートを使用して確立されます。ファイアウォールがこれらの接続をタイムアウトさせないように構成する必要があります。そのような構成が不可能な場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルで、SQLNET.EXPIRE_TIME=nというパラメータを設定します(nは分単位の時間)。この値を、ネットワーク・デバイス(ファイアウォール)の既知のタイムアウト値より小さい値に設定します。Oracle RACについては、このパラメータをすべてのOracleホーム・ディレクトリで設定します。
この項では、プライマリ・ホストに障害が発生した後に、管理サーバーを新しいホストにフェイルオーバーする方法について説明します。この項の例では、Access Management管理サーバーをOAMHOST1からOAMHOST2にフェイルオーバーする方法を示します。Oracle Identity Manager管理サーバーをフェイルオーバーする場合には、そのドメイン用に適した値に置き換えてください。
この項には次のトピックが含まれます:
あるノードで障害が発生した場合、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーをOAMHOST1からOAMHOST2にフェイルオーバーする方法について説明します。
前提事項:
管理サーバーがIADADMINVHN.mycompany.comをリスニングし、任意のアドレスをリスニングしないように構成されている。
管理サーバーはOAMHOST1からOAMHOST2にフェイルオーバーされ、この2つのノードに次のIPアドレスがある。
OAMHOST1: 100.200.140.165
OAMHOST2: 100.200.140.205
IADADMINVHN: 100.200.140.206
これは、管理サーバーが稼働している仮想IPアドレスで、OAMHOST1とOAMHOST2で使用可能なinterface:index (eth1:2など)に割り当てられています。
管理サーバーがOAMHOST1内で実行されるドメイン・ディレクトリは、共有記憶域にあり、OAMHOST2からもマウントされている。
|
注意: OAMHOST2内のNMは、この時点ではドメインを制御しません。これは、 |
Oracle WebLogic ServerおよびOracle Fusion Middlewareコンポーネントは、前の章の説明のとおり、OAMHOST2にインストールされている。つまり、OAMHOST1に存在するIAD_ORACLE_HOMEとIAD_MW_HOMEのパスは、OAMHOST2でも使用できます。
次の手順は、管理サーバーを異なるノード(OAMHOST2)にフェイルオーバーする方法を示します。
15.1項「コンポーネントの起動と停止」の説明に従い、OAMHOST1上の管理サーバーを停止します。
IPアドレスを2番目のノードに移行します。
OAMHOST1で次のコマンドをrootとして実行します(ここでx:yはIADADMINVHN.mycompany.comが使用する現在のインタフェースです)。
/sbin/ifconfig x:y down
例:
/sbin/ifconfig eth0:1 down
OAMHOST2で次のコマンドを実行します。
/sbin/ifconfig interface:index IP_Address netmask netmask
例:
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
|
注意: 使用するネットマスクおよびインタフェースがOAMHOST2の使用可能なネットワーク構成と一致することを確認します。 |
OAMHOST2上でarpingを使用してルーティング表を更新します。例:
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
次の手順を実行して、OAMHOST2上でノード・マネージャを起動します。
OAMHOST2にまだ管理サーバー・ドメイン・ディレクトリがマウントされていない場合は、これをマウントします。たとえば、次のようにします。
mount /u01/oracle
次のコマンドを使用してノード・マネージャを起動します。
cd WL_HOME/server/bin
./startNodeManager.sh
ノード・マネージャ・プロセスを強制終了してノード・マネージャを停止します。
|
注意: この時点でのノード・マネージャの起動および停止は、ノード・マネージャを初めて実行するときにのみ必要です。起動および停止により、前もって定義されたテンプレートからプロパティ・ファイルが作成されます。次の手順では、そのプロパティ・ファイルにプロパティを追加します。 |
setNMProps.shスクリプトを実行して、ノード・マネージャを起動する前にStartScriptEnabledプロパティをtrueに設定します。
cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh
|
注意: クラスのロード障害などの問題が発生しないようにするには、 |
第15.1項「コンポーネントの起動と停止」の説明に従い、ノード・マネージャを起動します。
OAMHOST2上で管理サーバーを起動します。
cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
WLSTシェルで一度、次のコマンドを実行します。
nmConnect('admin','Admin_Password', 'OAMHOST2','5556', 'IAMAccessDomain','/u1/oracle/config/domains/IAMAccessDomain')
nmStart('AdminServer')
次の方法でOAMHOST2上の管理サーバーにアクセスできることをテストします。
次のアドレスを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://IADADMINVHN.mycompany.com/console
http://IADADMINVHN.mycompany.com/emで、Oracle Enterprise Managerのコンポーネントのステータスにアクセスし、検証できることを確認します。
第11.1.1項「接続の確認」と同じ手順を実行します。この目的は、OAMHOST2で稼働中の管理サーバーにアクセスできることを確認することにあります。
この手順では、管理サーバーをフェイルバックできる(つまり、OAMHOST2上で停止し、OAMHOST1上で実行できる)ことを確認します。これを行うには、次の手順に従って、IADADMINVHNを元のOAMHOST1ノードに移行して戻します。
OAMHOST2上で管理サーバーが実行されていないことを確認します。その場合は、WebLogicコンソールから停止するか、またはコマンドstopWeblogic.shをIAD_ASERVER_HOME/binから実行します。
OAMHOST2上で、管理サーバー・ドメイン・ディレクトリをアンマウントします。たとえば、次のようにします。
umount /u01/oracle
OAMHOST1上で、管理サーバー・ドメイン・ディレクトリをマウントします。たとえば、次のようにします。
mount /u01/oracle
OAMHOST2上のIADADMINVHN.mycompany.comの仮想IPアドレスを無効にして、OAMHOST2で次のコマンドをrootとして実行します。
/sbin/ifconfig x:y down
ここで、x:yはIADADMINVHN.mycompany.comが使用する現在のインタフェースです。
OAMHOST1で次のコマンドを実行します。
/sbin/ifconfig interface:index 100.200.140.206 netmask 255.255.255.0
|
注意: 使用するネットマスクおよびインタフェースがOAMHOST1の使用可能なネットワーク構成と一致することを確認します。 |
arpingを使用してルーティング表を更新します。次のコマンドをOAMHOST1から実行します。
/sbin/arping -q -U -c 3 -I interface 100.200.140.206
ノード・マネージャがまだOAMHOST1上で起動されていない場合は、第15.1項「コンポーネントの起動と停止」の説明に従って起動します。
OAMHOST1で管理サーバーを再起動します。
cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
WLSTシェルが開始されたら、次のコマンドを実行します。
nmConnect(admin,'Admin_Pasword, OAMHOST1,'5556',
'IAMAccessDomain','/u01/oracle/config/domains/IAMAccessDomain'
nmStart('AdminServer')
次のアドレスを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://IADADMINVHN.mycompany.com:7001/console
ここで、7001は第7.1項「Identity and Access Managementのデプロイメントのための情報収集」のWLS_ADMIN_PORTです。
次のアドレスを使用してOracle Enterprise Managerのコンポーネントのステータスにアクセスし、検証できることを確認します。
http://IADADMIN.mycompany.com/em
環境がデプロイされたときに、トポロジのコンポーネントを起動および停止するために起動および停止スクリプトが生成されています。デプロイメント時に、アクセス・ドメイン管理サーバーはOAMHOST1上で起動するように構成されています。これをOAMHOST2上で起動するように永続的に変更するには、次の手順を実行します。
サーバーおよびホストの名前を変更する手順と同じ手順を使用して、ガバナンス・ドメイン管理サーバーをOIMHOST1ではなくOIMHOST2で起動するように変更します。
SHARED_CONFIG_DIR/scriptsディレクトリにあるserverInstancesInfo.txtファイルを編集します。
次のような行を探します。
OAMHOST1.mycompany.com AS AdminServer
OAMHOST1をOAMHOST2に変更し、ファイルを保存します。
この項では、このマニュアルで説明しているIdentity and Access Managementエンタープライズ・デプロイメントで発生する可能性のある一般的な問題のトラブルシューティング方法を説明します。
この項には次のトピックが含まれます:
第15.10.1項「Identity and Access Managementのデプロイメントのトラブルシューティング」
第15.10.3項「Oracle Access Management Access Manager 11gのトラブルシューティング」
この項では、デプロイメントに関する一般的な問題について説明します。次のトピックが含まれます:
問題
次のようなエラーでデプロイメントが失敗します。
Incorrect host format for attibute : PRIMARY_OAM_SERVERS : server-123.mycompany.com
バグにより、デプロイメント処理中に起動されたツールのいずれかがハイフン(-)文字を含むホスト名またはドメイン名を処理できません。
ソリューション
ハイフン(-)文字を含まないホスト名およびドメイン名を使用してください。
この項では、起動または停止スクリプトに関する一般的な問題について説明します。次のトピックが含まれます:
問題
事前検査を実行する際、ディレクトリIDM_TOPに使用可能な領域が十分にあることを確認します。IDM_TOP/productsおよびIDM_TOP/configに対して別々のマウント・ポイントを作成した場合、事前検査では2つのマウント・ポイントに割り当てられた領域を合計しないため、チェックは不適切に失敗します。
ソリューション
次のファイルを編集して、空き領域のチェックを無効にします。
LCM_HOME/provisioning/idm-provisioning-build/idm-common-preverify-build.xml
エントリを探します。
<target name="common-preverify-tasks">
次のエントリをコメントアウトして、編集後に次のようになるようにします。
<!--antcall target="private-preverify-free-space"/-->
ファイルを保存します。
問題
問題: 起動または停止スクリプトが管理対象サーバーの起動または停止に失敗します。
SHARED_CONFIG_DIR/scripts/logsディレクトリの起動または停止ログには、次のようなエラーが含まれています。
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****
at weblogic.server.ServerLifeCycleRuntime.getStateRemote(ServerLifeCycleRuntime.java:734)
at weblogic.server.ServerLifeCycleRuntime.getState(ServerLifeCycleRuntime.java:581)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
ソリューション
失敗した管理対象サーバーを停止します。プロセスを停止する必要のある場合があります。
管理対象サーバーのLDAPデータをバックアップしてから削除します。たとえば、次のようにします。
rm –rf LOCAL_CONFIG_DIR/domains/IAMAccessDomain/servers/server_name/data/ldap
server_nameは失敗した管理対象サーバーの名前です。
管理対象サーバーを再起動します。
この項では、Access Managerで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:
問題
Access Managerがしばらく実行した後、次のエラー・メッセージが出力されます。
Attempting to allocate 1G bytes There is insufficient native memory for the Java Runtime Environment to continue.
考えられる理由:
システムで物理RAMまたはスワップ領域が不足している。
32ビット・モードでプロセスのサイズ制限に到達した。
解決策
システムのメモリー・ロードを減らします。
物理メモリーまたはスワップ領域を増やします。
スワップのバックエンドのデータストアが一杯かどうかを確認します。
64ビットOSで64ビットJavaを使用します。
Javaヒープ・サイズを減らします(-Xmx/-Xms)。
Javaスレッドの数を減らします。
Javaスレッドのスタック・サイズを減らします(-Xss)。
圧縮参照を無効にします(-XXcompressedRefs=false)。
コマンド行からコマンド行ツールadrciを実行できることを確認します。
at oracle.dfw.impl.incident.ADRHelper.invoke(ADRHelper.java:1309)
at oracle.dfw.impl.incident.ADRHelper.createIncident(ADRHelper.java:929)
at oracle.dfw.impl.incident.DiagnosticsDataExtractorImpl.createADRIncident(DiagnosticsDataExtractorImpl.java:1116)
OAMHOST1上およびOAMHOST2上で、IAD_MSERVER_HOME/binにあるファイルsetSOADomainEnv.shを編集し、次のように開始する行を探します。
PORT_MEM_ARGS=
この行を次を読み取るように変更します。
PORT_MEM_ARGS="-Xms768m -Xmx2560m"
問題
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.
ソリューション
ログアウトせずに何回もログインすると、構成されているセッションの最大数を超えることがあります。Access Management管理コンソールを使用して、構成されているセッションの最大数を変更できます。
Access Management管理コンソールを使用してこの構成を変更するには、次の手順に従います。
「システム構成」→「共通構成」→「セッション」を選択します。
どのユーザーにも想定されるすべての同時ログイン・セッションに対処できるように、「1ユーザー当たりの最大セッション数」フィールドの値を大きくします。このフィールドには、1以上の任意の値を指定できます。
問題
Access Managerを構成した後、管理サーバーの起動に長時間を要します。
ソリューション
Access Managerのデータベースを調整します。Access Managerを構成した後で管理サーバーを初めて起動すると、データベースにいくつかのデフォルト・ポリシーが作成されます。データベースが遠方にある場合やチューニングを必要とする場合は、この作業に膨大な時間を要することがあります。
Resources Authentication Policies Protected Higher Level Policy Protected Lower Level Policy Publicl Policy Authorization Policies Authorization Policies
これらの項目が表示されない場合は、最初の移入に失敗しています。管理サーバーのログ・ファイルで詳細を確認します。
問題
保護されたリソースにアクセスすると、本来はAccess Managerからユーザー名とパスワードの入力を要求されます。たとえば、簡単なHTMLページを作成してリソースとして追加すると、資格証明の入力画面が表示されます。
ソリューション
資格証明の入力画面が表示されない場合は、次の手順を実行します。
IAMAccessDomainのホストの別名が設定されていることを確認します。IAMAccessDomain:80、IAMAccessDomain:Null、IADADMIN.mycompany.com:80およびSSO.mycompany.com:443の別名が必要です。ここで、ポート80はHTTP_PORT、ポート443はHTTP_SSL_PORTです。
Webゲートがインストールされていることを確認します。
IAD_ASERVER_HOME/outputからWebゲートのLibディレクトリにObAccessClient.xmlがコピーされ、OHSが再起動されたことを確認します。
ObAccessClient.xmlが最初に作成されたとき、このファイルは適切な形式になっていません。OHSを再起動すると、そのファイルが再検査されて適切な形式になります。OHSを初めて起動すると、このファイルの新しいバージョンがAccess Managerから取得されます。
Access Managerサーバーを停止し、保護されたリソースへのアクセスを試みます。Access Managerサーバーが使用できないというエラーが表示されます。このエラーが表示されない場合は、Webゲートをインストールしなおします。
問題
Access Managementコンソールにログインできません。管理サーバーの診断ログに次のようなエラー・メッセージが含まれる場合があります。
Caused by: oracle.security.idm.OperationFailureException:
oracle.security.am.common.jndi.ldap.PoolingException [Root exception is oracle.ucp.UniversalConnectionPoolException:
Invalid life cycle state.
Check the status of the Universal Connection Pool]
at
oracle.security.idm.providers.stdldap.UCPool.acquireConnection(UCPool.java:112)
ソリューション
/tmp/UCP*のファイルを削除し、管理サーバーを再起動します。
この項では、Oracle Identity Managerで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:
第15.10.4.1項「Oracle Identity Managerの構成実行時のjava.io.FileNotFoundException」
第15.10.4.2項「Oracle Identity Managerでのユーザー作成時のResourceConnectionValidationxception」
問題
Oracle Identity Manager構成を実行すると、java.io.FileNotFoundException: soaconfigplan.xml (Permission denied)のエラーが表示され、Oracle Identity Manager構成が失敗することがあります。
ソリューション
この問題を回避するには、次の手順を実行します。
ファイル/tmp/soaconfigplan.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 Managerのリコンシリエーション・ジョブが失敗するか、ログ・ファイルに次のメッセージが示されます。
LDAP Error 53 : [LDAP: error code 53 - Full resync required. Reason: The provided cookie is older than the start of historical in the server for the replicated domain : dc=mycompany,dc=com]
このエラーは、Oracle Unified Directoryが特定期間書き込まれなかったために、Oracle Unified Directory変更ログCookieのデータが期限切れになったことにより発生します。
解決策:
ブラウザを開いて、次の場所に移動します。
http://igdadmin.mycompany.com/sysasdmin
COMMON_IDM_PASSWORDを使用して、xelsysadmとしてログインします。
「システム管理」で「スケジューラ」をクリックします。
「スケジュール済ジョブの検索」で、LDAP * (*の前にスペースあり)と入力し[Enter]を押します。
検索結果のジョブごとに、左側のジョブ名をクリックし、右側の「無効化」をクリックします。
すべてのジョブに対してこれを行います。ジョブがすでに無効化されている場合には何もしません。
LDAPHOST1で次のコマンドを実行します。
cd OUD_ORACLE_INSTANCE/OUD/bin
./ldapsearch -h ldaphost1 -p 1389 -D "cn=oudadmin" -b "" -s base "objectclass=*" lastExternalChangelogCookie
Password for user 'cn=oudadmin': <OudAdminPwd>
dn: lastExternalChangelogCookie: dc=mycompany,dc=com:00000140c682473c263600000862;
lastExternalChangelogCookie:に続く出力文字列をコピーします。この値は次の手順で必要になります。たとえば、次のようにします。
dc=mycompany,dc=com:00000140c682473c263600000862;
16進数部は28文字の長さである必要があります。値が2つ以上の16進数部を持つ場合、28文字部分をスペースで分けます。たとえば、次のようにします。
dc=mycompany,dc=com:00000140c4ceb0c07a8d00000043 00000140c52bd0b9104200000042 00000140c52bd0ba17b9000002ac 00000140c3b290b076040000012c;
次の各LDAPリコンシリエーション・ジョブを1回ずつ実行し、最後の変更番号をリセットします。
LDAPロール削除のリコンシリエーション
LDAPユーザー削除のリコンシリエーション
LDAPロール作成および更新のリコンシリエーション
LDAPユーザー作成および更新のリコンシリエーション
LDAPロール階層のリコンシリエーション
LDAPロール・メンバーシップのリコンシリエーション
ジョブを実行する手順:
OIMシステム管理コンソールにユーザーxelsysadmとしてログインします。
「システム管理」で「スケジューラ」をクリックします。
「スケジュール済ジョブの検索」で、LDAP * (*の前にスペースあり)と入力し[Enter]を押します。
実行するジョブをクリックします。
パラメータ「最終変更番号」を手順6で取得した値に設定します。
例:
dc=mycompany,dc=com:00000140c4ceb0c07a8d00000043 00000140c52bd0b9104200000042 00000140c52bd0ba17b9000002ac 00000140c3b290b076040000012c;
「即時実行」をクリックします。
リストのジョブごとに、この手順の最初から繰り返します。
最後の変更ログ番号がリセットされている増分リコンシリエーション・ジョブごとに、ジョブを実行し、ジョブが正常に完了したことを確認します。
ジョブが正常に実行されたら、要件に従い、ジョブの定期的な実行を再有効化します。
問題の発生が続く場合、各OUDインスタンスで次のコマンドを実行して、Cookieの保持期間を2か月延ばします。
増分ジョブを再有効化して正常に実行した後に、エラーが再度表示される場合(完全再同期が必要です。理由: 指定したCookieが古くなっています...)、OUD Cookieの保存期間を延ばします。この値に関する杓子定規はありませんが、問題を回避するには十分長くする一方、OUDでの不要なリソース消費を回避するには十分短くする必要があります。1-2週間で十分ですが、次の例では2週間が指定されています。
./dsconfig set-replication-server-prop --provider-name "Multimaster Synchronization" --set replication-purge-delay:8w -D cn=oudadmin --trustAll -p 4444 -h LDAPHOST1 Password for user 'cn=oudadmin': <OudAdminPswd> Enter choice [f]: f
この項では、Oracle SOA Suiteで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:
問題: 次のトランザクション・タイムアウト・エラーがログに表示されます。
Internal Exception: java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: XA error: XAResource.XAER_NOTA start() failed on resource 'SOADataSource_soaedg_domain': XAER_NOTA : The XID is not valid
解決方法: トランザクション・タイムアウト設定を確認し、JTAトランザクション・タイムアウトがデータ・ソースXAトランザクション・タイムアウトよりも短いことを確認します(後者はデータベースでのdistributed_lock_timeoutよりも短い)。
出荷時の設定では、SOAデータ・ソースではXAタイムアウト値は設定されていません。Set XA Transaction Timeout構成パラメータはWebLogic Server管理コンソールでは確認されません。この場合、データ・ソースはドメイン・レベルのJTAタイムアウトを使用します。これは30に設定されています。また、データベースのdistributed_lock_timeoutのデフォルト値は60です。この結果、トランザクションにかかる時間がこれらの値よりも短いと想定されるシステムでは、SOA構成は正しく動作します。特定の操作に想定されるトランザクション時間に合せて、これらの値を調整します。
