| Oracle® Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド 11gリリース1 (11.1.1.7.0) B55900-07 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド 11gリリース1 (11.1.1.7.0) B55900-07 |
|
前 |
次 |
この章では、トポロジを設定した後に実行できる操作について説明します。この操作には、トポロジの監視、スケーリングおよびバックアップがあります。
この章の内容は次のとおりです。
WebCenter Portalエンタープライズ・デプロイメントを構成したら、この章の情報を使用してトポロジを管理します。
トポロジの監視とWebCenter Portalアプリケーションの詳細は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのOracle WebCenter Portalのパフォーマンスの監視に関する説明を参照してください。
スケール・アップやスケール・アウトなどの方法で、トポロジの拡張が必要になることがあります。スケール・アップとスケール・アウトの違いおよびこれらのタスクの実行方法の詳細は、第16.4項「トポロジのスケール・アップ(管理対象サーバーを既存ノードに追加)」および第16.5項「トポロジのスケール・アウト(新しいノードへの管理対象サーバーの追加)」を参照してください。
構成の変更前後にはトポロジをバックアップします。構成変更後の問題発生に対応するためバックアップしておく必要のあるディレクトリとファイルについては、第16.6項「WebCenter Portalデプロイメントにおけるバックアップとリカバリの実行」で説明します。
この章では、トポロジの構成後に発生する可能性のある既知の問題の解決方法も示します。
すべてのコンポジットでデータベースが頻繁に使用されるわけではありませんが、サービス・エンジンは大量のデータをCUBE_INSTANCEスキーマとMEDIATOR_INSTANCEスキーマで生成します。データベースの領域が不足していると、SOAコンポジットが機能しなくなる可能性があります。
SOAインフラストラクチャ・データベースでスペースを管理する手順は次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlコンソール(のダッシュボードなど)で"Oracle.fabric.common.FabricInvocationException"などの汎用エラーがないか確認します。
SOAサーバーのログで次のようなエラーを検索します。
Error Code: 1691 ... ORA-01691: unable to extend lob segment SOAINFRA.SYS_LOB0000108469C00017$$ by 128 in tablespace SOAINFRA
これらのメッセージは通常、データベースの領域の問題を示しています。たとえば、既存のファイルにデータ・ファイルまたは領域を追加する必要があるような場合です。SOAデータベース管理者は、領域の追加で使用される拡張方針とパラメータを決定する必要があります。
古いコンポジット・インスタンスをパージしてSOAインフラストラクチャ・データベースのサイズを縮小します。このタイプの操作に、Oracle Enterprise Manager Fusion Middleware Controlを使用することはお薦めしません。操作でトランザクション・タイム・アウトが高い確率で発生します。リポジトリ作成ユーティリティでは、インスタンスを消去するための特別なパッケージが提供されています。次に例を示します。
DECLARE
FILTER INSTANCE_FILTER := INSTANCE_FILTER();
MAX_INSTANCES NUMBER;
DELETED_INSTANCES NUMBER;
PURGE_PARTITIONED_DATA BOOLEAN := TRUE;
BEGIN
.
FILTER.COMPOSITE_PARTITION_NAME:="default";
FILTER.COMPOSITE_NAME := "FlatStructure";
FILTER.COMPOSITE_REVISION := "10.0";
FILTER.STATE := fabric. STATE_UNKNOWN;
FILTER.MIN_CREATED_DATE := to_timestamp("2010-09-07","YYYY-MM-DD");
FILTER.MAX_CREATED_DATE := to_timestamp("2010-09-08","YYYY-MM-DD");
MAX_INSTANCES := 1000;
.
DELETED_INSTANCES := FABRIC.DELETE_COMPOSITE_INSTANCES(
FILTER => FILTER,
MAX_INSTANCES => MAX_INSTANCES,
PURGE_PARTITIONED_DATA => PURGE_PARTITIONED_DATA
);
これにより、2010-09-07から2010-09-08までの間に作成されたUNKNOWN状態のFlatStructureコンポジット(バージョン10)の最初の1000個のインスタンスが削除されます。提供されるSQLパッケージに含まれている可能性のある操作の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のSOAコンポジット・アプリケーションの管理に関する項を参照してください。必ず、適切に消去できるようにするために提供されているスクリプトを使用してください。composite_dn表からのみ行を削除すると、Oracle Fusion Middleware SOAインフラストラクチャが使用するその他の表の参照が解決されなくなる場合があります。
UMSドライバの構成情報は、SOAクラスタに自動的には伝播されません。UMSドライバの構成をクラスタに伝播する手順は次のとおりです。
UMSドライバの構成を、そのドライバを使用するエンタープライズ・デプロイメント・トポロジ内のすべてのサーバーに適用します。
サーバー移行を使用する場合、サーバーは別のノードのドメイン・ディレクトリに移動します。フェイルオーバー・ノード内でUMSドライバ構成をあらかじめ作成しておきます。UMSドライバの構成ファイルは、次のディレクトリにあります。
ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml
*は、デプロイ中にOracle WebLogic Serverによってランダムに生成されるディレクトリ名を表します。たとえば、3682yqなどです。
フェイルオーバーに備え、強制的にサーバー移行を実行しファイルをソース・ノードからコピーする方法でUMSドライバ構成ファイルを作成します。
これまでに行った変更を有効にする(変更後の構成情報をドライバに読み取らせる)ためにドライバを再起動する必要があります。ドライバを再起動する手順は次のとおりです。
Oracle WebLogic管理コンソールにログインします。
ナビゲーション・ツリーの環境ノードを開きます。
「デプロイメント」をクリックします。
ドライバを選択します。
「停止」→「作業完了時」をクリックして、操作を確定します。
ドライバの状態が「準備完了」に変化するまで待ちます(必要に応じて、管理コンソール・ページを更新します)。
ドライバをもう一度選択し、「起動」→「すべてのリクエストを処理」をクリックして、操作を確定します。
ドライバのプロパティが保持されていることを、Oracle Enterprise Manager Fusion Middleware Controlで確認します。
トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。新しい管理対象サーバーを作成する場合は、このような既存のノード・インストール(WebLogic Serverホーム、Oracle Fusion Middlewareホーム、ドメイン・ディレクトリなど)を使用します。WebLogic Server、SOAまたはWebCenter Portalのバイナリを新しい場所にインストールしたり、packとunpackを実行したりする必要はありません。
サーバー移行を使用してサーバーのスケール・アップを行う場合は、必要となる容量およびリソース割当てについて計画します。例として、次のシナリオについて考えてみます。
サーバー1がノード1上にあり、このサーバーはノード2上のサーバー2を使用するクラスタ内サーバー移行を使用します。
スケールアップ操作によって、ノード1のクラスタにサーバー3が追加されます。これもサーバー移行を使用します。
このシナリオでは、ノード1またはノード2のいずれかですべてのサーバー(サーバー1、サーバー2、サーバー3および管理サーバー)が実行される恐れがあります。つまり、サーバー移行を使用するすべてのサーバーが1つのノード上(サーバー移行候補マシンの構成で定義される)で実行される最悪のケースに対応できるように、各ノードを十分なリソースで設計する必要があるということです。
|
注意:
|
この項の内容は次のとおりです。
SOAトポロジ(WSMを含む)をスケール・アップするには、次の手順を実行します。
Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1またはWLS_WSM1をクローニングして新しい管理対象サーバーを作成します。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成するには:
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。
「ロックして編集」をクリックして、クローニングする管理対象サーバー(たとえばWLS_SOA1)を選択します。
「クローンの作成」をクリックします。
新しい管理対象サーバーの名前をWLS_SOAnにします。nは、新しい管理対象サーバーの識別番号です。ここでは、WLS_SOA1が実行されていたノード1に新しいサーバーを追加します。
以降の手順は、新しいサーバーをSOAHOST1に追加します。このホストではすでにWLS_SOA1が実行されています。
リスニング・アドレスには、この新しい管理対象サーバーで使用するホスト名またはIPを指定します。推奨されているとおりにサーバー移行を使用する場合、サーバーを別のノードに移動できるようにVIP(浮動IPとも呼ばれる)を指定します。このVIPは、実行されている管理対象サーバーとは別のものを使用してください。
WLS_WSMサーバーの場合は、第8.6項「Oracle WSMについてのJavaオブジェクト・キャッシュの構成」で説明されているように、Javaオブジェクト・キャッシュの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。同じノードの複数のWLS_WSMサーバー用に同じディスカバリ・ポートを使用できます。第8.6項「Oracle WSMについてのJavaオブジェクト・キャッシュの構成」の手順をWLS_WSMサーバーごとに繰り返すと、サーバー・リストが更新されます。
SOA用およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。 |
SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいUMS JMSサーバー用の新しい永続ストアを作成し(UMS JMSサーバーの作成方法は後述します)、UMSJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。 |
|
注意: 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
BPMシステムの場合のみ: 新しいBPMJMSServer用の新しい永続ストア(たとえばBPMJMSFileStore_N)を作成します。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。 SOAJMSFileStore_Nを新しいBPM JMSサーバーのストアとして割り当てることも可能です。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
BPMシステムの場合のみ: BPM用の新しいJMSサーバー(たとえばBPMJMSServer_N)を作成します。このJMSServerにはBPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。
SOA、UMSおよび(適用可能な場合)BPM JMSモジュールのサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。
そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA: SOAJMSModule用、BPM: BPMJMSMOdule用およびUMS: UMSSYtemResource用)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。
|
注意: このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBPMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。 |
このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。「保存してアクティブ化」をクリックします。
新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順は、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。
|
注意: 変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。
|
管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=myPassword1
「保存してアクティブ化」をクリックします。
新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAn管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
新しい管理対象サーバー用のサーバー移行を構成します。Oracle WebLogic Server管理コンソールを使用してサーバー移行を構成する手順は次のとおりです。
|
注意: これはスケールアップ操作であるため、ノードにノード・マネージャが存在していること、およびサーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済であることが必要です。新しいSOA管理対象サーバー用の浮動IPも、すでに存在している必要があります。 |
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列で、移行を構成するサーバーの名前(ハイパーリンクとして表示される)をクリックします。選択したサーバーの「設定」ページが表示されます。
「移行」サブタブをクリックします。
「移行の構成」セクションで、移行に参加するサーバーを「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、SOAHOST1(すでにWLS_SOA1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_SOA2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。
|
注意: 移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。 |
「サーバーの自動移行を有効化」オプションを選択します。これにより、ターゲット・ノードで障害の発生したサーバーをノード・マネージャが自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。
新しいサーバーを含むように、クラスタのアドレスを更新します。
管理コンソールで、「環境」を選択し、「クラスタ」を選択します。
SOA_Clusterサーバーをクリックします。
SOA_Clusterの「設定」画面が表示されます。
「ロックして編集」をクリックします。
新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例: SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOST1VHN1:8001
変更を保存してアクティブ化します。
この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。
WLS_SOAn管理対象サーバーを停止します。
停止するには、run kill -9 <pid>を管理対象サーバーのPIDに対して実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを実行します。
ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
WebCenter Portalトポロジをスケール・アップするには、次の手順を実行します。
|
注意: 1つのノード上における複数の管理対象サーバーの実行は、WC_SpacesおよびWC_Portletサーバーに対してのみサポートされています。 |
WebLogic Server管理コンソールを使用して、WC_Spaces1またはWC_Portlet1のクローンを作成し、新しい管理対象サーバーにします。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成するには:
管理コンソールで、「環境」を選択し、「サーバー」を選択します。
「ロックして編集」をクリックします。
クローンを作成する管理対象サーバー(WC_Spaces1やWC_Portlet1など)を選択します。
「クローン」を選択します。
新しい管理対象サーバーにWC_SERVERNAMEnという名前を付けます(ここで、nは新しい管理対象サーバーを識別する番号です)。
以降の手順では、すでにWC_Spaces1またはWC_Portlet1が実行されている新しいサーバーにWCPHOST1を追加します。
リスニング・アドレスには、この新しい管理対象サーバーに使用するホスト名またはIPアドレス(既存サーバーと同じもの)を割り当てます。
この管理対象サーバーのポート番号が、このノードで使用可能であることを確認します。
新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します。詳細は、第10.5項「Spaces_Cluster用のJavaオブジェクト・キャッシュの構成」を参照してください。
Oracle HTTP Serverモジュールをクラスタの新規メンバーで再構成します。詳細は、第10.11.1項「WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成」を参照してください。WebLogicClusterパラメータの終わりに、新しいサーバーのホストとポートを追加します。
WC_Spacesの場合は、メンバーを/webcenter、/webcenterhelp、/rss、/restのLocationブロックに追加します。
WC_Portletの場合は、メンバーを/portalTools、/wsrp-tools、/pageletsのLocationブロックに追加します。
1つのドメイン、1つのノードに対して、Oracle WebCenter Content管理対象サーバー1台のみが、Oracle Fusion Middlewareによってサポートされます。Oracle WebCenter Content管理対象サーバーを追加するには、Oracle Fusion Middleware Oracle Enterprise Content Management Suiteエンタープライズ・デプロイメント・ガイドのOracle WebCenter Contentのスケールアウト手順に関する説明に従って、Oracle WebCenter Content管理対象サーバーを新しいノードに追加します。
トポロジをスケール・アウトするには、SOA、WebCenter PortalまたはWebCenter Contentを構成した新しい管理対象サーバーを新しいノードに追加します。
この項の内容は次のとおりです。
トポロジをスケールアウトするには、SOAまたはWSM-PMを構成した新しい管理対象サーバーを新しいノードに追加します。
この項の手順を実行する前に、次の要件が満たされていることを確認してください。
前提条件
SOAまたはWSM-PMを構成した管理対象サーバーが、トポロジ内の既存のノードで実行されている必要があります。
新しいノードが、WebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること(新しい管理対象サーバーWLS_SOAまたはWLS_WSMを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerやSOAのバイナリを新しい場所にインストールする必要はありませんが、新しいノードでpackとunpackを実行してドメイン構成をブートストラップする必要はあります)。
ORACLE_HOMEまたはWL_HOMEが別のノード上の複数のサーバーで共有されている場合、パッチのインストールと適用の一貫性を維持するために、これらのノードにあるOracleインベントリおよびミドルウェア・ホーム・リストを常に最新にしておきます。ノード内のoraInventoryを更新し、これに共有記憶域のインストールをアタッチするには、次の場所でattachHome.shスクリプトを使用します。
ORACLE_HOME/oui/bin/
ミドルウェア・ホーム・リストを更新してWL_HOMEを追加または削除するには、次のディレクトリにあるbeahomelistファイルを編集します。
user_home/bea/
トポロジをスケール・アウトするには:
新しいノード上に、既存のMW_Home(SOAインストールとドメイン・ディレクトリが存在する)をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、SOAHOSTnで次のコマンドを実行します。
cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh ./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>
ミドルウェア・ホーム・リストを更新するには、$HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合は、このファイルを編集)、MW_HOMEをこのファイルに追加します。
Oracle WebLogic管理コンソールにログインします。
新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。
マシンのノード・マネージャのアドレスを更新し、スケールアウトに使用しているノードのIPをマッピングします。
Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1またはWLS_WSM1をクローニングして新しい管理対象サーバーを作成します。この管理対象サーバーには、WLS_SOAnまたはWLS_WLS_WSMnという名前を付けます(nは番号です)。
|
注意: この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。 |
新しい管理対象サーバーのリスニング・アドレスとして使用するホスト名またはIPを指定します。
このサーバーでサーバー移行を実行する場合(推奨)、ここでサーバーのVIP(浮動IPとも呼ばれる)を指定します。このVIPは、既存の管理対象サーバーとは別のものを使用してください。
WLS_WSMサーバーの場合は、第8.6項「Oracle WSMでのJava Object Cacheの構成」で説明されているように、Java Object Cacheの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。
SOA用、BPM用および(適用可能な場合)UMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。
|
注意: この手順は、WLS_SOA管理対象サーバーの場合にのみ実行し、WLS_WSM管理対象サーバーをスケール・アウトする場合は不要です。 |
SOA用およびUMS用のJMSサーバーを作成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。 |
SOA用の新しいJMSサーバーを作成します(例: SOAJMSServer_N)。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいUMSJMSServer用の新しい永続ストアを作成し、UMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」でJMS永続ストアのディレクトリとして推奨されているパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。 |
|
注意: 新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
BPMシステムの場合のみ: 新しいBPMJMSServer用の新しい永続ストア(たとえばBPMJMSFileStore_N)を作成します。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms
|
注意: このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。 SOAJMSFileStore_Nを新しいBPM JMSサーバーのストアとして割り当てることも可能です。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。 |
BPMシステムの場合のみ: BPM用の新しいJMSサーバー(たとえばBPMJMSServer_N)を作成します。このJMSServerにはBPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
SOA、UMSおよび(適用可能な場合)BPM JMSモジュールのサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA: SOAJMSModule用、BPM: BPMJMSModule用およびUMS: UMSSYtemResource用)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。
|
注意: このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBPMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。 |
このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。「保存してアクティブ化」をクリックします。
UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。
次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
SOAHOST1で次のコマンドを実行し、テンプレート・ファイルをSOAHOSTnにコピーします。
SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_COMMON_HOME/common/bin
次のように、unpackコマンドをSOAHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
cd ORACLE_COMMON_HOME/common/bin
./unpack.sh -domain=ORACLE_BASE/admin/domain_name /mserver/domain_name/ -template=soadomaintemplateScale.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications -overwrite_domain=true
新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順は、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。
|
注意: 変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。
|
管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=myPassword1
「保存してアクティブ化」をクリックします。
新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。
新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAn管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。
Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。
表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。
「SSL」タブをクリックします。
「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
「保存」をクリックします。
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、既存のノードの共有記憶域内にあるインストールを使用してから、次のように新しいノードのホスト名をパラメータとして渡します。
SOAHOSTN> WL_HOME/server/bin/startNodeManager
Oracle WebLogic Server管理コンソールで、新しい管理対象サーバーを起動してテストします。
新たに作成した管理対象サーバー、WLS_SOAnが実行されていることを確認します。
ロード・バランサ上(https://soa.mycompany.com/soa-infra)のアプリケーションにアクセスします。アプリケーションが機能している必要があります。
|
注意: トポロジ内のHTTP Serverでは、新たに追加されたサーバーへのリクエストをラウンド・ロビン方式で処理する必要があります(新しいリクエストは、クラスタ内のサーバー数に応じて、新しいサーバーにヒットする必要があります)。Oracle HTTP Serverの |
新しい管理対象サーバー用のサーバー移行を構成します。
|
注意: この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいSOA管理対象サーバー用の浮動IPも、新しいノードにすでに存在します。 |
Oracle WebLogic Server管理コンソールにログインし､サーバーの移行を構成します。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。
表の「名前」列で、移行を構成するサーバー(ハイパーリンクとして表示される)を選択します。そのサーバーの「設定」ページが表示されます。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。
|
注意: マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要な容量計画をあらかじめ行ってください。 |
「サーバーの自動移行を有効化」を選択します。これにより、ターゲット・ノードで障害の発生したサーバーをノード・マネージャが自動的に起動できるようになります。
「保存」をクリックします。
管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。
新しいサーバーを含むように、クラスタのアドレスを更新します。
管理コンソールで、「環境」を選択し、「クラスタ」を選択します。
SOA_Clusterサーバーをクリックします。
SOA_Clusterの「設定」画面が表示されます。
「ロックして編集」をクリックします。
新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。たとえば、ADMINVHN:8011,SOAHOST2VHN1:8011,SOAHOSTNVHN1:8001と入力します。
変更を保存してアクティブ化します。
この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。
管理対象サーバーのPID (プロセスID)で次のコマンドを実行して、WLS_SOAn管理対象サーバーを停止します。
kill -9 pid
ノードのPIDは次のコマンドで特定できます。
ps -ef | grep WLS_SOAn
|
注意: Windowsの場合は、
taskkill /f /pid pid
pidは、管理対象サーバーのプロセスIDを表します。 WLS_SOAn管理対象サーバーのプロセスIDを確認するには、次のコマンドを実行します。
MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v
|
ノード・マネージャのコンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーがローカルで再び再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
トポロジのスケール・アウトでは、Oracle WebCenter Portalアプリケーションを使用して構成されている新しい管理対象サーバーを新しいノードに追加します。
この項の手順を実行する前に、次の要件が満たされていることを確認してください。
前提条件
WebCenter Portalで構成された管理対象サーバーを実行しているノードがトポロジ内に存在しています。
新しいノードは、WebLogic ServerおよびOracle WebCenter Portal用の既存のホーム・ディレクトリにアクセスできます。新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerまたはWebCenter Portalのバイナリを新しい場所にインストールする必要はありませんが、packとunpackを実行して管理対象サーバーのドメインを作成する必要があります。
WC_SpacesとWC_Utilitiesサーバーは、どちらも新しいノードでスケール・アウトされるか、どちらもスケール・アウトされない必要があります。これは、WebCenter Portal: SpacesとAnalyticsアプリケーションの間のローカル・アフィニティによるものです。
トポロジをスケール・アウトするには:
新しいノードで、WebCenter Portalのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するために、次のコマンドを実行します。
WCPHOSTn> cd ORACLE_BASE/product/fmw/wc/ WCPHOSTn> ./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>
Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。
Oracle WebLogic管理コンソールにログインします。
新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。
Oracle WebLogic Server管理コンソールを使用して、WC_Spaces1、WC_Portlet1、WC_Collaboration1またはWC_Utilities1のクローンを新しい管理対象サーバーに作成します。それにWC_XXXnという名前を付けます(nはその新しいマシンに割り当てる番号です)。
リスニング・アドレスには、新しい管理対象サーバーに使用するホスト名またはIPを割り当てます。次の手順に従って、管理対象サーバーのリスニング・アドレスを設定します。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーの概要」ページが表示されます。
表の「名前」列で、リスニング・アドレスを変更する管理対象サーバーを選択します。その管理対象サーバーの「設定」ページが表示されます。
「リスニング・アドレス」をWCPHOSTnに設定します(ここで、WCPHOSTnは、新しいマシンのDNS名です)。
「保存」をクリックします。
変更を保存してアクティブ化します。
変更内容は、管理対象サーバーが再起動されるまでは有効になりません。
packコマンドをSOAHOST1上で実行してテンプレート・パックを作成し、WCPHOSTnに解凍します。
これらの手順は、第10.4.1項「unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播」に記載されています。
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。
WCPHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip
新しい管理対象のCollaborationサーバーの場合:
第10.7項「ディスカッション・サーバーでのクラスタリングの構成」の手順に従って新しいディスカッション・サーバーのクラスタリングを構成します。
また、第10.6項「マルチキャストからユニキャストへのディスカッションの変換」の手順を、coherence.localhostパラメータに新しいホストのホスト名を使用して実行済であることも確認します。
これが新しいユーティリティ管理対象サーバーである場合は、第10.9項「アクティビティ・グラフの構成」の手順に従ってアクティビティ・グラフを無効化済であることを確認します。また、ユーティリティとローカルSpacesサーバー用に、第10.8項「Analyticsの構成」の新しいAnalyticsコレクタの構成手順が実行済であることも確認します。
Oracle WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。
新たに作成した管理対象サーバー、WLS_SOAnが実行されていることを確認します。
ロード・バランサ上(https://soa.mycompany.com/soa-infra)のアプリケーションにアクセスします。アプリケーションが機能している必要があります。
|
注意: トポロジ内のHTTP Serverでは、新たに追加されたサーバーへのリクエストをラウンド・ロビン方式で処理する必要があります(新しいリクエストは、クラスタ内のサーバー数に応じて、新しいサーバーにヒットする必要があります)。Oracle HTTP Serverの |
表16-1は、WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。
表16-1 WebCenter Portal (11g)エンタープライズ・デプロイメントでバックアップする静的アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
ORACLEホーム(DB) |
RACデータベース・ホスト - CUSTDBHOST1およびCUSTDBHOST2 |
ユーザー定義 |
データ層 |
|
Oracleホーム(OHS) |
WEBHOST1およびWEBHOST2 |
|
Web層 |
|
MWホーム(SOAおよびWC) |
SOAHOST1およびSOAHOST2 - SOA WCPHOST1とWCPHOST2 - WC |
すべてのホスト上のMW_HOME |
アプリケーション層 |
|
ORACLE HOME (WCC) |
WCPHOST1とWCPHOST2 |
共有ディスク上: 各ホストの |
アプリケーション層 |
|
インストール関連ファイル |
OraInventory
user_home/bea/beahomelist, oraInst.loc, oratab
|
表16-2は、WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。
表16-2 WebCenter Portal (11g)エンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
ドメイン・ホーム |
SOAHOST1 SOAHOST2 WCPHOST1 WCPHOST2 |
ORACLE_BASE/admin/domain_name/ mserver/domain_name |
アプリケーション層 |
|
アプリケーション・アーティファクト(earおよびwarファイル) |
SOAHOST1 SOAHOST2 WCPHOST1 WCPHOST2 |
管理コンソールですべてのデプロイメントを確認し、すべてのアプリケーション・アーティファクトをバックアップする |
アプリケーション層 |
|
OHSインスタンス・ホーム |
WEBHOST1およびWEBHOST2 |
ORACLE_BASE/admin/instance_name |
Web層 |
|
OHS WCC構成ファイル |
WEBHOST1およびWEBHOST2 |
各ホストの |
Web層 |
|
RACデータベース |
CUSTDBHOST1およびCUSTDBHOST2 |
ユーザー定義 |
データ層 |
|
Oracle WebCenter Contentリポジトリ |
データベース・ベース |
データ層 |
Oracle Fusion Middlewareのコンポーネントのバックアップとリカバリの詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。
ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。次に、SOAHOST1およびSOAHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。
前提条件:
管理サーバーを、任意のアドレスではなくADMINVHN上でリスニングするように構成します。第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」の手順14を参照してください。
これらの手順では、2つのノードがそれぞれ別々のドメイン・ディレクトリを使用していることおよびこれらのディレクトリがローカル記憶域または別のボリュームにある共有記憶域に配置されていることを想定しています。
管理サーバーはSOAHOST1からSOAHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。
SOAHOST1: 100.200.140.165
SOAHOST2: 100.200.140.205
ADMINVHN: 100.200.140.206.これは管理サーバーを実行している場所の仮想IPであり、ethX:Yに割り当てられており、SOAHOST1とSOAHOST2からアクセスできます。
SOAHOST1での管理サーバーの実行場所であるドメイン・ディレクトリは共有記憶域にあり、SOAHOST2からもマウントされています。
第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」の説明のとおり、Oracle WebLogic ServerおよびOracle Fusion MiddlewareコンポーネントはSOAHOST2にインストールされています(つまり、SOAHOST1に存在するORACLE_HOMEおよびMW_HOMEのパスをSOAHOST2でも使用できます)。
この項の内容は次のとおりです。
次の手順は、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーしたうえで、同じWebLogic Serverマシン(これは物理マシンではなく論理マシンです)を引き続きその管理サーバーで使用する方法を示しています。
管理サーバーを別ノードにフェイルオーバーする手順は次のとおりです。
管理サーバーを停止します。
IPを第2ノードに移行します。
SOAHOST1上で次のコマンドをroot権限で実行します(X:YはADMINVHNで現在使用しているインタフェース)。
/sbin/ifconfig ethX:Y down
次のコマンドをSOAHOST2上で実行します。
/sbin/ifconfig interface:index IP_Address netmask netmask
たとえば、次のようにします。
/sbin/ifconfig eth0:1 10.0.0.1 netmask 255.255.255.0
|
注意: 使用するネットマスクとインタフェースは、SOAHOST2で使用可能なネットワーク構成と一致している必要があります。 |
arpingを使用してルーティング表を更新します。次のコマンドをSOAHOST1から実行します。
/sbin/arping -q -U -c 3 -I eth0 10.0.0.1
SOAHOST2上の管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して起動します。
次の方法でSOAHOST2上の管理サーバーにアクセスできることをテストします。
次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://ADMINVHN:7001/console
次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。
http://ADMINVHN:7001/em
|
注意: 管理サーバーでは、フェイルオーバーにノード・マネージャを使用しません。手動でフェイルオーバーした後、サーバーの管理コンソールの「現在のマシン」フィールドに表示されるマシン名は、フェイルオーバー・マシン「SOAHOST2」でなく、「SOAHOST1」になります。ノード・マネージャでは管理サーバーを監視しないので、「現在のマシン」フィールドに表示されるマシン名は関係ないため、無視してかまいません。 |
第8.7.5項「Oracle HTTP Serverを介したアクセスの検証」と同じ手順を実行します。この目的は、SOAHOST2で実行している管理サーバーにもアクセスできることを確認することです。
この手順では、管理サーバーをフェイルバックできることを確認します。フェイルバックとは、SOAHOST2で実行している管理サーバーを停止し、ADMINVHNをSOAHOST1ノードに戻して、SOAHOST1で再び管理サーバーを実行することです。
ADMINVHNをSOAHOST1に戻す手順は次のとおりです。
管理サーバーが起動されていないことを確認します。
次のコマンドをSOAHOST2上で実行します。
/sbin/ifconfig ethZ:N down
次のコマンドをSOAHOST1上で実行します。
/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
|
注意: 使用するネットマスクとインタフェースは、SOAHOST1で使用可能なネットワーク構成と一致している必要があります。 |
arpingを使用してルーティング表を更新します。次のコマンドをSOAHOST1から実行します。
/sbin/arping -q -U -c 3 -I ethZ 100.200.140.206
第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して、SOAHOST1上の管理サーバーを再度起動します。
cd ORACLE_BASE/admin/domain_name/aserver/domain_name/bin ./startWebLogic.sh
次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。
http://ADMINVHN:7001/console
次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。
http://ADMINVHN:7001/em
エンタープライズ・デプロイメントの本番デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Cluster(Oracle RAC)については、データベース接続はOracle RAC VIPとデータベース・リスナー・ポートを使用して確立されます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。このような構成が不可能である場合は、次のディレクトリにあるsqlnet.oraファイル内の*SQLNET.EXPIRE_TIME=n*パラメータを設定します。
ORACLE_HOME/network/admin
nは分単位の時間です。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。Oracle RACについては、このパラメータをすべてのOracleホーム・ディレクトリで設定します。
この項では、WebCenter Portalエンタープライズ・デプロイメントで発生する可能性のある問題を示し、その解決方法を提案します。
この項の内容は次のとおりです。
問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。
An error occurred during activation of changes, please see the log for details. [Management:141190]The commit phase of the configuration update failed with an exception: In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean
解決方法: このエラーが発生するのは、サーバーの起動パラメータが管理コンソールで変更された場合です。この場合は、構成を変更しようとしていたサーバーの起動構成の一部であるユーザー名/パスワードの情報を管理コンソールで指定するか、<password-encrypted></password-encrypted>エントリをconfig.xmlファイルから削除してください(管理サーバーの再起動が必要)。
問題: Oracle WebLogic管理コンソールにアクセスするためにOHSおよびロード・バランサを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。
解決方法: この問題は、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、管理コンソールがその変更を反映しようとすると発生します。変更内容によっては、管理サーバーのリスニング・アドレスにリダイレクトすることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。ユーザーは再度ログインする必要はなく、URLをwcp.mycompany.com/console/console.portalに変更すれば、管理コンソールのホーム・ページに直接アクセスできます。
|
注意: この項で説明する変更の追跡を無効にしている場合、この問題は発生しません。 |
問題: OAMを構成した後でなんらかの変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされるようになります(アクティブ化の実行場所であるコンテキスト・メニューには戻りません)。
解決方法: これは、OAM SSOが構成済のときに発生する現象で、管理サーバーによってリダイレクトが実行された結果です。このリダイレクトにかかわらず、アクティブ化は完了します。必要であれば、ユーザーは手動で目的のコンテキスト・メニューに戻ることができます。
問題: unpackユーティリティを使用し、SOAHOST2、WCPHOST1およびWCPHOST2にドメイン構成を伝播した後、WC_Spacesサーバーを起動できません。
[Deployer:149158]No application files exist at '/u01/app/oracle/admin/wcpedg_domain/apps/wcpedg_domain/custom.webcenter.spaces.fwk'...
解決方法: 管理対象サーバー・アプリケーションの場所から、管理対象サーバーのデプロイヤが期待している場所にすべてのファイルをコピーします。次に例を示します。
cp /u01/app/oracle/admin/wcpedg_domain/mserver/applications/* /u01/app/oracle/admin/wcpedg_domain/apps/wcpedg_domain/
|
注意: コンテンツのコピー前に |
問題: 管理サーバー・ノードに障害が発生して別のノードへの手動フェイルオーバーが実行された後で、管理サーバーの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。
<Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/soadomain/aserver/soadomain/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>
解決方法: ノードの障害発生後にノードを復旧させるときに、ドメイン・ディレクトリに共有記憶域が使用されている場合、ロック・クリーンアップの失敗が原因で、管理サーバーのログにこのエラーが記録されることがあります。このエラーを解決するには、ファイルを削除します。
ORACLE_BASE/ admin/domain_name/aserver/domain_name/servers/AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lok
問題: Spaces内でページを作成しているときに、そのページにポートレットを追加した後でデータベース・フェイルオーバーが発生すると、エラーがあるコンポーネントがページに表示されます。
"Error" "Portlet unavailable"
このメッセージは、ページをリフレッシュしたり、いったんログアウトしてページを再表示してもなくなりません。
解決方法: この問題を解決するには、該当のコンポーネントを削除してからもう一度追加します。
問題: Javaオブジェクト・キャッシュ(OWSM、WebCenter Portal管理対象サーバーなど)を使用している管理対象サーバーの起動に失敗します。次のエラーがログに表示されます。
J2EE JOC-058 distributed cache initialization failure J2EE JOC-043 base exception: J2EE JOC-803 unexpected EOF during read.
解決方法: JOCが取得しようとしているポートと同じポートを別のプロセスが使用しています。このプロセスを停止するか、または推奨ポート範囲内の別のポートを使用するようにこのクラスタのJOCを再構成します。
問題: soa-createUDD.pyスクリプトに渡されたパラメータに誤りがあるか、別の誤りによってSOAクラスタのJMS構成で障害が発生しています。
解決方法: soa-createUDD.pyを使用して、構成をリストアします。
SOAクラスタがOracle Fusion Middleware構成ウィザードから作成された後でsoa-createUDD.pyスクリプトを実行しているときに、なんらかの誤りが生じた(誤ったオプションが使用された、ターゲットが変更された、またはモジュールが間違って削除された)場合。このような状況では、soa-createUDD.pyスクリプトを使用し、次の手順で適切なJMS構成をリストアできます。
既存のSOA JMSリソース(SOAインフラストラクチャ・システムが所有するJMSモジュール)を削除します。
soa-createUDD.pyを再実行します。このスクリプトは、SOA用に作成されたJMSサーバーが保持され、SOA用の共通分散送り先を使用するために必要な宛先とサブデプロイメント・モジュールが作成されることを想定しています。この場合、オプション--soaclusterを指定してスクリプトが実行される必要があります。スクリプトを再実行後、WebLogic Server管理コンソールから次のアーティファクト(ドメイン構造、サービス、メッセージング、JMSモジュール)が存在することを確認します。
SOAJMSModuleUDDs ---->SOAJMSSubDM targeted to SOAJMSServer_auto_1 and SOAJMSServer_auto_2 UMSJMSSystemResource ---->UMSJMSSubDMSOA targeted to UMSJMSServer_auto_1 and UMSJMSServer_auto_2
問題: OAM構成ツールを使用して、複数のURLをまとめてOracle Access Managerのポリシーに追加しました。1つ以上のURLが不正です。正しいURLを指定してOAM構成ツールをもう一度実行すると、処理は正常に完了しますが、ポリシー・マネージャには誤ったURLが依然として表示されます。
解決方法: 同じapp_domain名を指定してOAM構成ツールを実行したときは、既存ポリシーへの新しいURLの追加のみが行われます。特定のURLを削除するには、OAMのポリシー・マネージャ・コンソールを使用してください。OAMのアクセス管理サイトにログインして、「ポリシー・ドメイン」をクリックし、作成されたポリシー・ドメイン(WebCenter_EDG)→「リソース」タブをクリックし、誤ったURLを削除します。
問題: RESTポリシーの構成後、その後の認証でもOAMを介した外部のクライアントの認証が要求されます。
解決方法: 2次認証はWebLogicに由来しています。WebLogicの資格証明の要求を無効にするには、次のようにセキュリティ・ポリシーを更新する必要があります。
次のファイルを探します。
/aserver/domain_name/config/config.xml
セキュリティの構成の終わりの部分で(つまり</security-configuration>の前に)、次の行を追加します。
<enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credenti als>
ドメイン内のすべてのサーバーを再起動します。
問題: サーバー移行のためwlsifconfigを実行すると、次の警告が表示されます。
sudo: sorry, you must have a tty to run sudo
解決方法: WebLogicユーザー('oracle')がバックグラウンドでsudoを実行できません。この問題を解決するには、次の行を/etc/sudoersに追加します。
Defaults:oracle !requiretty
詳細は、第14.5項「wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定」を参照してください。
問題: 次のトランザクション・タイムアウト・エラーがログに記録されます。
Internal Exception: java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: XA error: XAResource.XAER_NOTA start() failed on resource 'SOADataSource_wcpedg_domain': XAER_NOTA : The XID is not valid
解決方法: トランザクション・タイムアウト設定を確認し、JTAトランザクション・タイムアウトがデータ・ソースXAトランザクション・タイムアウトよりも短いことを確認します(後者はデータベースでのdistributed_lock_timeoutよりも短い)。
出荷時の設定では、SOAデータ・ソースではXAタイムアウト値は設定されていません。WebLogic Server管理コンソールでは、Set XA Transaction Timeout構成パラメータのチェック・ボックスの選択が解除されています。この場合、データ・ソースはドメイン・レベルのJTAタイムアウトを使用します。これは30に設定されています。また、データベースに対するデフォルトのdistributed_lock_timeout値は60です。このため、トランザクションの期間がこれらの値より低いことが想定されるシステムでは、SOA構成は正しく機能します。特定の処理にかかると想定されるトランザクション時間に応じてこれらの値を調整してください。
問題: SOAクラスタで複合ルールを編集して保存すると、サーバーの出力ファイルに、レプリケーション・メッセージの最大サイズを超えたことを報告するエラー・メッセージが記録されることがあります。次に例を示します。
<rws3211539-v2.company.com> <WLS_SOA1> <ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'> <<WLS Kernel>> <> <> <1326464549135> <BEA-000403> <IOException occurred on socket: Socket[addr=/10.10.10.10,port=48290,localport=8001] weblogic.socket.MaxMessageSizeExceededException: Incoming message of size: '10000080' bytes exceeds the configured maximum of: '10000000' bytes for protocol: 't3'. weblogic.socket.MaxMessageSizeExceededException: Incoming message of size: '10000080' bytes exceeds the configured maximum of: '10000000' bytes for protocol: 't3'
解決方法: このエラーは、HTTPセッションに配置され、クラスタにレプリケートされたシリアル化メッセージのサイズが大きいために発生します。使用しているルールのサイズに応じて最大メッセージ・サイズを大きくします。
最大メッセージ・サイズを大きくする手順は次のとおりです。
WebLogic管理コンソールにログインします。
「サーバー」→Server_name→「プロトコル」→「一般」を選択します。
必要に応じて「最大メッセージ・サイズ」フィールドを変更します。
