ヘッダーをスキップ
Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド
11gリリース1（11.1.1）
B55900-01
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

11 トポロジの管理

この章では、トポロジを設定した後に実行できる操作について説明します。この操作には、トポロジの監視、スケーリングおよびバックアップがあります。

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

11.1 トポロジの監視

トポロジの監視方法の詳細は、『Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter』の第15章を参照してください。

11.2 UMSドライバの構成

UMSドライバの構成情報は、SOAクラスタに自動的には伝播されません。したがって、ユーザーが次の作業を行う必要があります。

  1. UMSドライバの構成情報を、そのドライバを使用するEDGトポロジ内のすべてのサーバーに適用します。

  2. サーバーの移行機能を使用すると、サーバーは別のノードのドメイン・ディレクトリに移動します。UMSドライバ構成は、フェイルオーバー・ノード内であらかじめ作成しておく必要があります。UMSドライバ構成ファイルの場所は次のとおりです。

    ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/servers/<server_name>/tmp/_WL_user/<ums_driver_name>/*/configuration/driverconfig.xml

    （「*」はデプロイメント時にランダムに生成されるディレクトリ名、たとえば「3682yq」を表します）。

フェイルオーバーに備えてファイルを作成するには、強制的にサーバー移行を実行してファイルをソース・ノードからコピーしてください。

これまでに行った変更を有効にする（変更後の構成情報をドライバに読み取らせる）ためにドライバを再起動する必要があります。ドライバを再起動する手順は次のとおりです。

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

  2. ナビゲーション・ツリーの環境ノードを開きます。

  3. 「デプロイメント」をクリックします。

  4. ドライバを選択します。

  5. 「停止」→「作業完了時」をクリックし、操作を確定します。

  6. ドライバの状態が「準備完了」に変化するまで待ちます（必要に応じて、管理コンソール・ページを更新する）。

  7. ドライバをもう一度選択して「起動」→「すべての要求を処理」をクリックし、操作を確定します。

ドライバのプロパティが保持されていることを、Oracle Enterprise Manager Fusion Middleware Controlで確認してください。

11.3 トポロジのスケーリング

エンタープライズ・トポロジは、スケールアウトまたはスケールアップできます。トポロジのスケールアップとは、1つ以上の管理対象サーバーをすでに実行しているノードに新しい管理対象サーバーを追加することです。トポロジのスケールアウトとは、新しいノードに新しい管理対象サーバーを追加することです。

この項の項目は次のとおりです。

11.3.1 トポロジのスケールアップ（管理対象サーバーを既存ノードに追加）

この場合は、WebCenterコンポーネントを使用して構成されている管理対象サーバーまたはWSM-PMを含む管理対象サーバーを実行するノードがすでに存在します。このノードには、共有記憶域内にWebLogic ServerホームとOracle Fusion Middleware WebCenterホームが存在します。

新しいOracle WebCenterサーバーとWLS_WSMサーバーの作成には、既存のインストール（WebLogic Serverホーム、Oracle Fusion Middlewareホームおよびドメイン・ディレクトリ）を使用できます。WLSバイナリまたはWebCenterバイナリを新しい場所にインストールしたり、圧縮と解凍を実行する必要はありません。

トポロジをスケールアップする手順は次のとおりです。

  1. 管理コンソールを使用して、WLS_Spaces1、WLS_Portlet1、WLS_Services1またはWLS_WSM1を新しい管理対象サーバーにクローニングします。クローニング元の管理対象サーバーとして選択できるのは、新しい管理対象サーバーを実行するノード上にすでに存在しているサーバーです。

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

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

    2. クローニングする管理対象サーバー（WLS_Spaces1やWLS_Portlet1など）を選択します。

    3. 「クローン」を選択します。

    新しい管理対象サーバー(SERVER_NAME)nに名前を付けます。このnは、新しい管理対象サーバーを識別する番号です。

  2. リスニング・アドレスには、この新しい管理対象サーバーで使用するホスト名またはIPを指定します。

  3. スケールアウトされている管理対象サーバーがWLS_Servicesの場合、次の追加手順を実行します。

    1. 管理対象サーバーを最低でも1回は起動し、Oracle Wikiの管理対象サーバー用のデプロイメント・ディレクトリを作成します。その後、管理対象サーバーを停止します。

    2. この新しいサーバーの構成ディレクトリから共有のWikiサーバー・ディレクトリへのソフト・リンクを作成します。

      $ ln -s <DOMAIN_HOME>/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/attachments/ /shared/owc_wiki/attachments
$ ln -s <DOMAIN_HOME>/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/templates/ /shared/owc_wiki/templates

  4. クラスタ内の新しいメンバーを使用してOracle HTTP Serverモジュールを再構成します。Oracle HTTP Serverの構成を参照してください。

  5. 新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します（第6.13項「Javaオブジェクト・キャッシュの設定」を参照）。

11.3.2 トポロジのスケールアウト（新しいノードへの管理対象サーバーの追加）

トポロジのスケールアウトでは、Oracle WebCenterアプリケーション、WSM-PMまたはその両方を使用して構成された新しい管理対象サーバーを新しいノードに追加します。

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

  • トポロジ内に、Oracle WebCenterアプリケーション、WSM-PMまたはその両方を使用して構成された管理対象サーバーを実行している既存のノードが存在する。

  • 新しいノードがWebLogic ServerおよびOracle WebCenter用の既存のホーム・ディレクトリにアクセスできる。新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerのバイナリやWebCenterのバイナリを新しい場所にインストールする必要はありませんが、新しいノードでpackとunpackを実行してドメインの構成をブートストラップする必要はあります。

トポロジをスケールアウトする手順は次のとおりです。

  1. 新しいノード上に、既存のミドルウェア・ホーム（WebCenterインストールとドメイン・ディレクトリが存在する）をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。

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

    SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/
SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_05_R27.6.2-20

    ミドルウェア・ホーム・リストを更新するには、$HOME/bea/beahomelistファイルを作成し（別のWebLogicインストールがノード内に存在する場合は、このファイルを編集する）、ORACLE_BASE/product/fmwをこのファイルに追加します。

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

  4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。

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

  6. 管理コンソールを使用して、WLS_Spaces1/WLS_Portlet1/WLS_Services1/WLS_WSM1を新しい管理対象サーバーにクローニングし、WLS_(SERVER_TYPE)nと名付けます。このnは番号です。

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

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

  8. スケールアウトされている管理対象サーバーがWLS_Servicesの場合、次の追加手順を実行します。

    1. 管理対象サーバーを最低でも1回は起動し、Oracle Wikiの管理対象サーバー用のデプロイメント・ディレクトリを作成します。その後、管理対象サーバーを停止します。

    2. この新しいサーバーの構成ディレクトリから共有のWikiサーバー・ディレクトリへのソフト・リンクを作成します。

      $ ln -s <DOMAIN_HOME>/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/attachments/ /shared/owc_wiki/attachments
$ ln -s <DOMAIN_HOME>/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/templates/ /shared/owc_wiki/templates

  9. クラスタ内の新しいメンバーを使用してOracle HTTP Serverモジュールを再構成します（Oracle HTTP Serverの構成を参照）。

  10. 新しいノードでノード・マネージャを起動します。既存のノードの共有記憶域にあるインストールを使用してノード・マネージャを起動しますが、その際に新しいノードのホスト名をパラメータとして渡します。

    NEW_NODE> WL_HOME/server/bin/startNodeManager <new_node_ip>

    第4.1.1項「Oracle WebLogic Serverのインストール」に示されているパスを使用する場合、WL_HOMEはORACLE_BASE/wlsになります。

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

    新たに作成した管理対象サーバー上のアプリケーションにアクセスします（http://HOST:port/webcenterまたはhttp://host:port/wsm-pm）。このアプリケーションが正常に機能している必要があります。

  12. 新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します（第6.13項「Javaオブジェクト・キャッシュの設定」を参照）。

11.3.3 Oracle Content Server（OCS）トポロジのスケールアウト

各Content Serverノードは、共有記憶域の<content_server_dir>/binにあるクラスタ・インストーラを使用してインストールされます。

別のContent Serverノードのインストール

新しいノード（SOAHOSTn）で次のコマンドを実行します（全体を1行で指定）。

Installer
-set-ClusterNodeIntradocDir=<ocs-stub>
-set-ClusterNodeName=<nodename>
-set-ClusterNodeAddress=<ip_of_node>
-set-ClusterBinDirRule=<local|shared>
ConfigureClusterNode
ConfigureAdminClusterNode

<nodename>には、SOAHOSTnを指定します。

<stellent-stub>には、ローカル・ディレクトリ（/u01/app/oracle/product/ucmなど）を使用します。

Set-ClusterBinDirRuleには、localを指定します。

インストール後の手順

ノードを設定した後は、次の行を<stellent-stub>/binディレクトリと<stellent-stub>/admin/etcディレクトリのintradoc.cfgファイルに追加します。

DisableSharedCacheChecking=true
ClusterNodeName=<nodename>
ClusterGroup=<cluster_name>
SocketServerAddress=<server_IP_address>

<nodename>はノードの識別子です。

<cluster_name>はクラスタの識別子です。

すべてのノードには別々のノード名が必要ですが、クラスタ・グループ名は同じである必要があります。たとえば、SOAHOSTnの行は次のようになります。

DisableSharedCacheChecking=true
ClusterNodeName=SOAHOSTn
ClusterGroup=ucmcluster
SocketServerAddress=<IP_of_SOAHOSTn>

サーバーの起動

各ノードで<ocs-stub>/binにあるバイナリを使用して、Oracle Content Serverと管理サーバーを起動します。

ログ・ファイルとPIDファイルが<ocs-stub>/admin/etcディレクトリと<ocs-stub>/etcディレクトリに作成されていることを確認します。

ロード・バランサの構成

ロード・バランサは、この新しいホストに対してもソケット・ロード・バランサとして機能するように再構成する必要があります。これは、Oracle HTTP ServerおよびWebCenterからのソケット接続を確立するために使用されます。例:

ロード・バランサ上の仮想ホスト: wcinternal.mycompany.com:9054

マッピング先: WCHOST1:9054、WCHOST2:9054、SOAHOSTn:9054

ロード・バランシング・メソッド: ラウンド・ロビン

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

表11-1は、11gのOracle WebCenterエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。

表11-1 11gのOracle WebCenterエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト

タイプ ホスト 場所 層

ORACLEホーム（DB）

RACデータベース・ホスト: CUSTDBHOST1およびCUSTDBHOST2

ユーザー定義

ディレクトリ層

MWホーム（SOAおよびWC）

SOAHOST1およびSOAHOST2: SOA

WCHOST1およびWCHOST2: WC

すべてのホストのORACLE_BASE/product/fmw

アプリケーション層

Oracleホーム（OHS）

WEBHOST1およびWEBHOST2

ORACLE_BASE/admin/<instance_name>

Web層

Oracleホーム（OCS）

WCHOST1およびWCHOST2

共有ディスク上: /share/oracle/ucm

各ホスト: ORACLE_HOME/ucmにあるローカル・ファイル

アプリケーション層

インストール関連ファイル

OraInventory、<user_home>/bea/beahomelist、oraInst.loc、oratab

表11-2は、11gのOracle WebCenterエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。

表11-2 11gのOracle WebCenterエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト

タイプ ホスト 場所 層

ドメイン・ホーム

SOAHOST1

SOAHOST2

WCHOST1

WCHOST2

ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>

アプリケーション層

アプリケーション・アーティファクト（earおよびwarファイル）

SOAHOST1

SOAHOST2

WCHOST1

WCHOST2

管理コンソールですべてのデプロイメントを確認し、すべてのアプリケーション・アーティファクトを取得する

アプリケーション層

OHSインスタンス・ホーム

WEBHOST1およびWEBHOST2

WEBHOST1上: ORACLE_HOME/ohs_1/instances/instance1

WEBHOST2上: ORACLE_HOME/ohs_2/instances/instance2

Web層

OHS OCS構成ファイル

WEBHOST1およびWEBHOST2

各ホストの/share/oracle/ucm（ローカル・ファイル・システム）

Web層

RACデータベース

CUSTDBHOST1およびCUSTDBHOST2

ユーザー定義

ディレクトリ層

OCSコンテンツ・リポジトリ

データベース・ベース

ディレクトリ層

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


注意:

ORACLE_HOMEのバックアップは、B2B設定の一部であるXEngine構成が変更されたときに実行する必要があります。対象のファイルは、ORACLE_HOME/soa/thirdparty/edifecs/XEngineにあります。ORACLE_HOMEをバックアップするには、次のコマンドを実行してください。 
SOAHOST1> tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw

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

この項の項目は次のとおりです。

11.6 ベスト・プラクティス

この項の項目は次のとおりです。

11.6.1 SQLNet接続のタイムアウト防止

EDG本番デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters（RAC）の場合、データベース接続はOracle RACのVIPとデータベース・リスナー・ポートに対して行われます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。そのように構成できない場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルの*SQLNET.EXPIRE_TIME=n*パラメータを設定してください。nは分単位の数値です。この値を、ネットワーク・デバイス（つまりファイアウォール）の既知のタイムアウト値よりも小さくしてください。RACの場合、このパラメータをすべてのOracleホーム・ディレクトリで設定してください。

11.6.2 処理するファイル数が30,000を超える場合の表領域のAUTOEXTENDの設定

処理したファイル数が30,000を超えると、表領域はそれ以上拡張されません。上限に達したときは、表領域のAUTOEXTENDを有効化する必要があります。プロセスを開始する前に、表領域のAUTOEXTENDを推奨値に設定しておくことをお薦めします。表領域の自動拡張の詳細は、『Oracle Database管理者ガイド』も参照してください。

11.6.3 監査

Oracle Fusion Middleware監査フレームワークは、Oracle Fusion Middleware 11gで追加された新しいサービスです。これは、ミドルウェア製品ファミリの集中監査フレームワークです。このフレームワークでは、Oracle Platform Security Services（OPSS）やOracle Web Servicesなどのプラットフォーム・コンポーネントに対して監査サービスが提供されます。また、Oracle固有のJavaEEコンポーネントをはじめ、様々なJavaEEアプリケーションのフレームワークとしても機能します。また、このようなJavaEEアプリケーションで、アプリケーション固有の監査イベントを作成できます。ミドルウェアのOracleコンポーネントのうちJavaEE以外のもの、たとえばCやJavaSEのコンポーネントについても、JavaEEアプリケーションと同様、エンドツーエンドのフレームワーク構造を実現します。

図11-1は、Oracle Fusion Middleware監査フレームワーク・アーキテクチャの概要図です。

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

図11-1の説明
「図11-1 監査イベント・フロー」の説明

Oracle Fusion Middleware監査フレームワークを構成する主なコンポーネントは次のとおりです。

  • 監査API

    Oracle Fusion Middleware監査フレームワークに統合される監査対応コンポーネント用のAPIです。実行時にアプリケーションからこのAPIを呼び出すと、アプリケーション・コード内で発生した特定のイベントに関する必要な情報の監査を行うことができます。監査対象のイベントのコンテキストを示すために、イベントの詳細情報、たとえばユーザー名や属性を、このAPIを通してアプリケーション側で指定できます。

  • 監査イベントと構成

    Oracle Fusion Middleware監査フレームワークには、汎用イベントがあらかじめ用意されており、アプリケーション監査イベントを簡単にマッピングできるようになっています。この汎用イベントとは、認証などの一般的なイベントです。このフレームワークでは、アプリケーション側でアプリケーション固有イベントも定義できます。

    このイベント定義および構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。構成の更新は、Enterprise Manager（UI）およびWLST（コマンドライン・ツール）から実行できます。

  • 監査バスストップ

    バスストップとは、監査リポジトリにプッシュされる前の監査データが格納されるローカル・ファイルです。データベース・リポジトリが1つも構成されていない場合は、このバスストップ・ファイルをファイルベースの監査リポジトリとして使用できます。バスストップ・ファイルは単純なテキスト・ファイルであり、特定の監査イベントの検索も簡単に実行できます。データベース・リポジトリがある場合、バスストップはコンポーネントと監査リポジトリの間の中間ファイルになります。ローカル・ファイルは、構成したアップロード間隔に基づいて、定期的に監査リポジトリにアップロードされます。

  • 監査ローダー

    その名のとおり、監査ローダーの機能は、監査バスストップのファイルを監査リポジトリにロードすることです。 プラットフォームおよびJavaEEアプリケーションの監査の場合、JavaEEコンテナ起動時に監査ローダーも起動されます。 システム・コンポーネントの場合、監査ローダーは定期的に生成されるプロセスになります。

  • 監査リポジトリ

    監査リポジトリに格納されるのは、事前定義されたOracle Fusion Middleware監査フレームワークのスキーマです。これは、リポジトリ作成ユーティリティ（RCU）によって作成されます。構成が完了すると、すべての監査ローダーがリポジトリを認識し、そのリポジトリに定期的にデータをアップロードするようになります。監査データは監査リポジトリ内に蓄積されるため、時間とともに増加します。監査リポジトリには、他のアプリケーションが使用している運用データベースではなく、監査専用のスタンドアロンのRDBMSを使用するのが理想的です。高可用性構成の場合は、Oracle Real Application Clusters（RAC）データベースを監査データ・ストアとして使用することをお薦めします。

  • Oracle Business Intelligence Publisher

    監査リポジトリ内のデータは、Oracle Business Intelligence Publisherの事前定義済レポートとして公開されます。このレポートでは、監査データを様々な条件に基づいてドリルダウンできます。次に例を示します。

    • ユーザー名

    • 時間範囲

    • アプリケーション・タイプ

    • 実行コンテキスト識別子（ECID）

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

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

EDGトポロジには、Oracle Fusion Middleware監査フレームワーク構成は含まれません。バスストップ・ファイルへの監査データの出力、および監査ローダーの構成は、製品をインストールした後に実行できるようになります。最大の懸念事項は、監査データが格納される監査データベース・リポジトリです。監査データはサイズが大きく、過去のデータが蓄積されていくため、他のミドルウェア・コンポーネントの運用ストアとは別に、専用のデータベースを用意することを強くお薦めします。

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引