1. Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントの共通の構成および管理手順
  3. エンタープライズ・デプロイメントの共通の構成および管理タスク

21 エンタープライズ・デプロイメントの共通の構成および管理タスク

この項では、エンタープライズ・デプロイメント環境で実行する必要性が見込まれる構成および管理タスクについて説明します。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

すべてのエンタープライズ・デプロイメントの構成および管理タスク

ここに示すのは、Oracle Fusion Middlewareエンタープライズ・デプロイメントで実行する必要性が高い一般的な構成および管理タスクです。

  • WLSSchemaDataSourceの適切なサイズ変更および構成の確認
    WLSSchemaDataSourceは、JMS JDBCストア、JTA JDBCストアおよびリース・サービスのFMWコンポーネントで使用するために予約されている共通データベースです。WLSSchemaDataSourceは、クリティカルなWLSインフラストラクチャ・サービスで競合を回避し、デッドロックに備えるために使用されます。
  • 管理サーバーの手動フェイルオーバーの確認
    ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次の各項で、OIMHOST1およびOIMHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証するステップについて説明します。
  • 動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成
    動的クラスタにおける動的な管理対象サーバーのデフォルト構成では、使用可能なネットワーク・インタフェースすべてでリスニングするようになっています。ほとんどの場合、これは望ましくありません。
  • エンタープライズ・ドメインでのuploadおよびstageディレクトリの絶対パスへの変更
    ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。また、AdminServerのアップロード・ディレクトリを、相対パスではなく、同じ絶対パスを持つように更新します。そうしないと、デプロイメントの問題が発生する可能性があります。動的クラスタを実装する場合、新しく追加した各クラスタに割り当てられたサーバー・テンプレートの構成を検証および更新する必要があります。そうでない場合、新しく追加したクラスタの静的に定義された各管理対象サーバーを検証および構成します。
  • WebLogicクラスタのフロントエンド・ホストおよびポートの設定
    Oracle SOA SuiteサーバーをホストするOracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。これらの値は、ドメインのプロパティを指定する際に構成ウィザードで指定できます。ただし、Oracle Identity and Access Managementエンタープライズ・デプロイメントの一部にSOAクラスタを追加する場合、このタスクはSOA管理対象サーバーの検証後に実行することをお薦めします。
  • 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化
    中間層とハードウェア・ロード・バランサ間のSSL通信を有効にする方法を理解することが重要です。
  • エンタープライズ・デプロイメントでのTLOGおよびJMSの永続ストアの使用
    永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。
  • Webサービス用のJDBC永続ストアについて
    デフォルトでは、Webサービスの永続性にはWebLogic Serverデフォルト永続ストアが使用されます。このストアはWebサービスに対して高パフォーマンスの記憶域ソリューションを提供します。
  • エンタープライズ・デプロイメントのバックアップとリカバリの実行
    Oracle Identity and Access Managementエンタープライズ・デプロイメントに必要なディレクトリと構成データを確実にバックアップするために、次に示すガイドラインに従うことをお薦めします。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理タスク

WLSSchemaDataSourceの適切なサイジングおよび構成の検証

WLSSchemaDataSourceは、JMS JDBCストア、JTA JDBCストアおよびリース・サービスのFMWコンポーネントで使用するために予約されている共通データベースです。WLSSchemaDataSourceは、クリティカルなWLSインフラストラクチャ・サービスで競合を回避し、デッドロックに備えるために使用されます。

WLSSchemaDataSourceの接続使用量を削減するには、JMS JDBCおよびTLOG JDBCストア接続キャッシュ・ポリシーを、各接続キャッシュ・ポリシー設定を使用して「デフォルト」から「最小」に変更します。バックエンド・データベース・システム内の接続数を削減する必要がある場合、キャッシュ・ポリシーを「最小」に設定することをお薦めします。キャッシュ・ポリシー「なし」を使用するとパフォーマンスが低下する可能性があるため、このポリシーは使用しないでください。JDBCストアで使用される接続についての詳細な推奨事項については、『WebLogic永続ストアの管理』で、JDBCストア接続キャッシュ・ポリシーの構成に関する項を参照してください。

WLSSchemaDataSource接続プールのデフォルト・サイズは75です(GridLinkデータ・ソースの場合はサイズが2倍になります)。FMWの各クラスタのサイズと、移行に構成する候補に応じて、このサイズは高い値にチューニングすることができます。たとえば、ストア当たりのワーカー・スレッドがデフォルト値である一般的なSOA EDGデプロイメントを考えてみます。25個を超えるJDBCストアまたはTLOG-in-DBインスタンス(あるいはその両方)が同じWebLogicサーバーにフェイルオーバーでき、「接続キャッシュ・ポリシー」が「デフォルト」から「最小」に変更されていない場合は、接続の競合問題が発生する可能性があります。このような場合は、デフォルトのWLSSchemaDataSourceプール・サイズ(最大容量)を増やす必要があります(各JMSストアは、最小で2つの接続を使用し、リースとJTAが追加されてもプールの競合が発生します)。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

管理サーバーの手動フェイルオーバーの確認

ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次の各項で、OIMHOST1およびOIMHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証するステップについて説明します。

前提条件:

  • 管理サーバーを、localhostまたは他の任意のホストのアドレスではなく、ADMINVHN上でリスニングするように構成します。

    ADMINVHN仮想IPアドレスの詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。

  • この手順では、管理サーバーのドメイン・ホーム(ASERVER_HOME)が両方のホスト・コンピュータにマウントされていることを前提にしています。これにより、管理サーバーのドメイン構成ファイルと永続ストアが、共有記憶域デバイスに保存されるようになります。

  • 管理サーバーはOIMHOST1からOIMHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。

    • OIMHOST1: 100.200.140.165

    • OIMHOST2: 100.200.140.205

    • ADMINVHN: 100.200.140.206。これは管理サーバーを実行している場所の仮想IPであり、OIMHOST1またはOIMHOST2で使用可能になるように仮想サブインタフェース(eth0:1など)に割り当てられます。

  • Oracle WebLogic ServerとOracle Fusion Middlewareのコンポーネントが、このガイドの個々の構成の章で示すように、OAMHOST2にインストールされています。

    具体的には、両方のホスト・コンピュータは、まったく同じパスを使用してOracleホームのバイナリ・ファイルを参照します。

ここでは、管理サーバーのフェイルオーバー手順のテストを実行する方法を詳しく説明します。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

Oracle HTTP Serverを介したOIMHOST2上の管理サーバーへのアクセスの検証

AdminServerにアクセスするようにWeb層を構成している場合、管理サーバーの手動フェイルオーバーを実行した後で、標準の管理URLを使用して管理サーバーにアクセスできるかどうかを確認することが重要です。

ロード・バランサから、次のURLにアクセスして、管理サーバーがOIMHOST2で稼働しているときにアクセスできることを確認します。

  • http://admin.example.com/console

    このURLによって、WebLogic Server管理コンソールが表示されます。

  • http://admin.example.com/em

    このURLによって、Oracle Enterprise Manager Fusion Middleware Controlが表示されます。

動的クラスタ・サーバー・テンプレートのリスニング・アドレスの構成

動的クラスタ内の動的管理対象サーバーのデフォルトの構成では、すべての使用可能なネットワーク・インタフェースをリスニングします。ほとんどの場合、これは望ましくありません。

障害時リカバリに備えて、別のデータ・センターの別のIPにマップできるホスト名の別名(たとえば、OIMHOST1、OIMHOST2)を使用して、それぞれのサーバーのリスニング・アドレスを特定のネットワーク・インタフェースに設定することをお薦めします。動的クラスタでは、それぞれのサーバーを限定的に構成することはできません。リスニング・アドレス構成は、クラスタのserver-templateに1つのみ存在します。クラスタ内の各動的サーバーのlisten-addressプロパティを効率的に設定するために、計算されるマクロを使用する必要があります。

WebLogic Serverには、クラスタ内の動的サーバーの索引番号に対応する"${id}"マクロがあります。この索引は、数字の"1"から始まり、現在のクラスタの管理対象サーバー数だけ増加されます。この連続採番されるサーバーIDマクロは、動的サーバーごとに特定のネットワーク・インタフェースでリスニングするようにリスニング・アドレスが計算される、推奨のホストのネーミング・パターンに使用できます。

このアプローチは、クラスタ当たりのホストごとに管理対象サーバーが1つのみ存在し、クラスタのスケールアウトが水平方向に限定されると見込まれるエンタープライズ・デプロイメント環境にお薦めします。

${id}マクロを使用してserver-templateのリスニング・アドレスを構成するには:

  1. /etc/hostsで、必要なエントリが、意図したマシンの適切なIPアドレスに構成されていることを確認します。
    たとえば:

    名前解決の要件の詳細は、「DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認」を参照してください。

  2. Oracle WebLogic Server管理コンソールに移動して、管理者の資格証明でサインインします。
    http://adminvhn:7001/console
  3. ドメインをロックして編集します。
  4. 「クラスタ」→「サーバー・テンプレート」に移動し、変更するサーバー・テンプレートを選択します。
  5. 「リスニング・アドレス」値を、抽象化された適切なリスナー・ホスト名に設定し、所定の変数を割り当てます。

    たとえば:

    wsmpm-server-template Listen Address = OIMHOST${id}

  6. 「保存」をクリックします。
  7. 別のサーバー・テンプレートを変更する必要がある場合は、ステップ4から繰り返します。
  8. 「変更のアクティブ化」をクリックします。
  9. テンプレートを使用するサーバーを再起動して、変更内容を有効にします。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。また、AdminServerのアップロード・ディレクトリを、相対パスではなく、同じ絶対パスを持つように更新します。そうしないと、デプロイメントの問題が発生する可能性があります。動的クラスタを実装する場合、新しく追加した各クラスタに割り当てられたサーバー・テンプレートの構成を検証および更新する必要があります。そうでない場合、新しく追加したクラスタの静的に定義された各管理対象サーバーを検証および構成します。

ノート:

このタスクはアクセス・インフラストラクチャでは不要です。

このステップは、リモート・デプロイメントの実行時の潜在的な問題の回避と、ステージ・モードが必要なデプロイメントのために必要です。

デプロイメント・ステージおよびアップロードの場所のディレクトリ・パスを更新するには、次のステップを実行します。

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

  2. 左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。

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

  4. 使用するクラスタ・タイプに適したオブジェクトに移動して編集します。

    1. 静的クラスタの場合は「サーバー」にナビゲートし、編集する管理対象サーバーの名前をクリックします。

    2. 動的クラスタの場合、「クラスタ」→「サーバー・テンプレート」に移動し、編集するサーバー・テンプレートの名前をクリックします。

  5. 編集する新しい管理対象サーバーまたはサーバー・テンプレートごとに、次の手順を実行します。

    1. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

    2. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。 

      MSERVER_HOME/servers/server_or_template_name/stage

      MSERVER_HOMEを MSERVER_HOMEディレクトリのフルパスに置き換えます。

      静的クラスタを使用する場合、編集対象の管理対象サーバーの正しい名前を使用して更新します。

      動的クラスタを使用する場合、テンプレート名はそのままにしておきます。たとえば: /u02/oracle/config/domains/iamedg_domain/servers/XYZ-server-template/stage

    3. 「アップロード・ディレクトリ名」を次の値に更新します。 

      ASERVER_HOME/servers/AdminServer/upload

      ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

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

    5. 「サーバーのサマリー」または「サーバー・テンプレートのサマリー」画面(該当する方)に戻ります。

  6. 新しい管理対象サーバーまたは動的クラスタ・サーバー・テンプレートごとに前のステップを繰り返します。

  7. AdminServerの「アップロード・ディレクトリ名」に移動して、その値を更新します。

    1. 「サーバー」に移動してAdminServerを選択します。

    2. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

    3. 「ステージング・ディレクトリ名」が次のような絶対パスに設定されていることを確認します。

      ASERVER_HOME/servers/AdminServer/stage

    4. 「アップロード・ディレクトリ名」を次の絶対パスに更新します。

      ASERVER_HOME/servers/AdminServer/upload

      ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

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

  8. 該当するすべてのオブジェクトを変更したら、「変更のアクティブ化」をクリックします。

  9. 変更内容を有効にするためにすべての管理対象サーバーを再起動します。

ノート:

これ以上のドメイン構成を直接続行する場合、この時点ではstageおよびuploadディレクトリの変更を有効にするための再起動は厳密には必要ありません。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

WebLogicクラスタのフロントエンド・ホストおよびポートの設定

Oracle SOA SuiteサーバーをホストするOracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。これらの値は、ドメインのプロパティを指定する際に構成ウィザードで指定できます。ただし、Oracle Identity and Access Managementエンタープライズ・デプロイメントの一部にSOAクラスタを追加する場合、このタスクはSOA管理対象サーバーの検証後に実行することをお薦めします。

Weblogic Server管理コンソールでフロントエンド・ホストおよびポートを設定するには:

  1. WebLogic Server管理コンソールにログインします。
  2. 「チェンジ・センター」で「ロックして編集」をクリックします。
  3. 「ドメイン構造」パネルで、「環境」を開き、「クラスタ」をクリックします。
  4. 「クラスタ」ページで、変更するクラスタをクリックし、「HTTP」タブを選択します。
  5. 表21-1の情報を使用して、必要なフロントエンド・ホスト名およびポートを各クラスタに追加します。

    表21-1 各クラスタのフロントエンド・ホスト名およびポート

    名前 フロントエンド・ホスト フロントエンドHTTPポート フロントエンドHTTPS

    OAM_Cluster

    login.example.com

    443

    AMA_Cluster

    iadadmin.example.com

    80

    OIM_Cluster

    SOA_Cluster

    igdinternal.example.com

    7777

    WSM-PM_Cluster

  6. 「保存」をクリックします。
  7. 「変更のアクティブ化」をクリックします。
  8. クラスタの管理対象サーバーを再起動します。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

中間層とハードウェア・ロード・バランサ間のSSL通信を有効化する方法を理解することは重要です。

ノート:

次のステップは、ハードウェア・ロード・バランサにSSLが構成されており、その結果システムのフロント・エンド・アドレスが保護されている場合に使用できます。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

中間層とロード・バランサ間のSSL通信が必要になるとき

エンタープライズ・デプロイメントには、中間層で実行されているソフトウェアが、ハードウェア・ロード・バランサのフロントエンドSSLアドレスにアクセスしなければならないシナリオがあります。このシナリオでは、ロード・バランサと起動サーバー間で、適切なSSLハンドシェイクが行われる必要があります。中間層の管理サーバーと管理対象サーバーが適切なSSL構成を使用して起動されていない場合は、このハンドシェイクを実行できません。

utils.CertGenユーティリティを使用した自己署名証明書の作成

この項では、OIMHOST1に自己署名証明書を作成する手順を説明します。各ホストのネットワーク名または別名を使用してすべてのアプリケーション層ホストの証明書を作成します。

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。KEYSTORE_HOMEロケーションに置かれるファイル・システムの仕様は、「エンタープライズ・デプロイメントの推奨ディレクトリ構造について」を参照してください。

かわりに信頼できるCA証明書を使用する方法は、『Oracle WebLogic Serverセキュリティの管理』のアイデンティティとトラストの構成に関する情報を参照してください。

パスワードについて

このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。

自己署名証明書を作成するには:

  1. 一時的に、次のスクリプトを実行して環境を設定します。
    . WL_HOME/server/bin/setWLSEnv.sh

    現在のシェル内のシェル・スクリプトをソースにするために、スクリプト名の前にはドット(.)とスペース( )が付いています。

  2. CLASSPATH環境変数が設定されていることを確認します。
    echo $CLASSPATH
  3. 「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明どおりに、正しく共有構成ディレクトリ・フォルダが作成され、共有記憶域にマウントされていることを確認します。

    たとえば、次のコマンドを使用して、共有構成ディレクトリが各ホストで使用可能であることを検証します。

    df -h | grep -B1 SHARED_CONFIG_DIR

    SHARED_CONFIG_DIRを、共有構成ディレクトリの実際のパスで置き換えます。

    また、ディレクトリのリスト表示を実行して、ホストでディレクトリが使用可能であると確認することもできます。

    ls -al SHARED_CONFIG_DIR
  4. キーストア・ホーム・フォルダ構造がまだない場合は、作成します。

    たとえば:

    cd SHARED_CONFIG_DIR
mkdir keystores
chown oracle:oinstall keystores
chmod 750 keystores
export KEYSTORE_HOME=SHARED_CONFIG_DIR/keystores
  5. ディレクトリをキーストア・ホームに変更します。
    cd KEYSTORE_HOME
  6. utils.CertGenツールを実行し、管理対象サーバーおよびノード・マネージャで使用されるホスト名または別名に対する証明書をホストごとに1つずつ作成します。

    ノート:

    utils.CertGenツールを実行して、管理対象サーバーを実行するその他すべてのホストの証明書を作成する必要があります。

    構文:

    java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [hostname]

    例:

    java utils.CertGen password ADMINVHN.example.com_cert \
      ADMINVHN.example.com_key domestic ADMINVHN.example.com

java utils.CertGen password OIMHOST1.example.com_cert \
      OIMHOST1.example.com_key domestic OIMHOST1.example.com
  7. システムで使用される残りのすべてのホストに対して、前のステップを繰り返します。
  8. 動的クラスタに対しては、ADMINVHNおよびホストごとに1つの証明書に加えて、ワイルドカードURLと一致する証明書も生成する必要があります。

    たとえば:

    java utils.CertGen password WILDCARD.example.com_cert \ 
WILDCARD.example.com_key domestic \*.example.com
utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成

この項では、OIMHOST1.example.comでアイデンティティ・キーストアを作成する方法について説明します。

前の項では、証明書とキーを作成して、それを共有記憶域に配置しました。この項では、すべてのホストおよびADMINVHNに対して前に作成した証明書と秘密キーが新しいアイデンティティ・ストアにインポートされます。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

ノート:

アイデンティティ・ストアは、utils.ImportPrivateKeyユーティリティを使用して証明書および対応するキーをインポートすることで作成されます(存在していない場合)。

  1. ADMINVHNおよびOIMHOST1の証明書と秘密キーをアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

    構文:

    java utils.ImportPrivateKey
      -certfile cert_file
      -keyfile private_key_file
      [-keyfilepass private_key_password]
      -keystore keystore
      -storepass storepass
      [-storetype storetype]
      -alias alias 
      [-keypass keypass]

    ノート:

    デフォルトのkeystore_typeはjksです。

    例:

    java utils.ImportPrivateKey\ 
     -certfile KEYSTORE_HOME/ADMINVHN.example.com_cert.pem\
     -keyfile KEYSTORE_HOME/ADMINVHN.example.com_key.pem\
     -keyfilepass password\
     -keystore appIdentityKeyStore.jks\ 
     -storepass password\
     -alias ADMINVHN\
     -keypass password

java utils.ImportPrivateKey\ 
     -certfile KEYSTORE_HOME/OAMHOST1.example.com_cert.pem\
     -keyfile KEYSTORE_HOME/OAMHOST1.example.com_key.pem\
     -keyfilepass password\
     -keystore appIdentityKeyStore.jks\
     -storepass password\ 
     -alias OIMHOST1\
     -keypass password
  2. 残りのホスト固有の証明書とキーの各組合せ(OAMHOST1、OAMHOST2など)について、java importPrivateKeyコマンドを繰り返します。

    ノート:

    インポートする証明書とキーの各組合せに対して一意の別名を使用してください。

  3. 動的クラスタの場合は、WILDCARDのカスタムID別名を使用して、ワイルドカード証明書と秘密キーのペアをインポートします。

    例:

    ${JAVA_HOME}/bin/java utils.ImportPrivateKey \ 
-certfile ${KEYSTORE_HOME}/WILDCARD.example.com_cert.pem \ 
-keyfile ${KEYSTORE_HOME}/WILDCARD.example.com_key.pem \ 
-keyfilepass password \ 
-keystore ${KEYSTORE_HOME}/appIdentityKeyStore.jks \ 
-storepass password \
-alias WILDCARD \ 
-keypass password
keytoolユーティリティを使用したトラスト・キーストアの作成

OIMHOST1.example.comに信頼キーストアを作成するには:

  1. 新しい信頼キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。

    標準のJava信頼キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアのCA証明書を、証明書のあるディレクトリにコピーします。たとえば: 

    cp WL_HOME/server/lib/cacerts KEYSTORE_HOME/appTrustKeyStore.jks
  2. keytoolユーティリティを使用して、デフォルトのパスワードを変更します。

    標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは、常に次のように変更することをお薦めします。 

    keytool -storepasswd -new NewPassword -keystore TrustKeyStore -storepass Original_Password

    たとえば:

    keytool -storepasswd -new password -keystore appTrustKeyStore.jks -storepass changeit
  3. keytoolユーティリティを使用してCA証明書をappTrustKeyStoreにインポートします。

    CA証明書CertGenCA.derは、utils.CertGenツールによって生成されるすべての証明書の署名に使用され、WL_HOME/server/libディレクトリに置かれています。

    次の構文を使用して、証明書をインポートします。

    keytool -import -v -noprompt -trustcacerts -alias AliasName -file CAFileLocation -keystore KeyStoreLocation -storepass KeyStore_Password

    たとえば:

    keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass password
トラスト・ストアへのロード・バランサ証明書のインポート

SSLハンドシェイクが適切に動作するには、ロード・バランサの証明書をWLSサーバーのトラスト・ストアに追加する必要があります。ロード・バランサの証明書を追加するには:

  1. ブラウザでSSLのサイトにアクセスします(これにより、サーバーの証明書がブラウザのリポジトリに追加されます)。
  2. ロード・バランサから証明書を取得します。ロード・バランサの証明書は、Firefoxなどのブラウザを使用して取得できます。ただし、証明書を取得する最も簡単な方法は、opensslコマンドを使用します。コマンドの構文は、次のとおりです。
    openssl s_client -connect LOADBALANCER -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM > SHARED_CONFIG_DIR/keystores/LOADBALANCER.pem

    たとえば:

    openssl s_client -connect prov.example.com:443 -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM > SHARED_CONFIG_DIR/keystores/prov.example.com.pem

  3. keytoolを使用して、ロード・バランサの証明書をトラスト・ストアにインポートします。

    たとえば:

    keytool -import -file SHARED_CONFIG_DIR/keystores/login.example.com -v -keystore appTrustKeyStore.jks -alias aliasLogin -storepass password
keytool -import -file SHARED_CONFIG_DIR/keystores/prov.example.com.crt -v -keystore appTrustKeyStore.jks -alias aliasProv -storepass password
  4. デプロイメントの各SSLロード・バランサ仮想ホストに対して、この手順を繰り返します。

ノート:

WLSサーバー・トラスト・ストアにロード・バランサ証明書を追加する必要があるのは、自己署名証明書の場合のみです。サードパーティの認証局が発行したロード・バランサ証明書の場合は、ルートの公開証明書と中間証明書をトラスト・ストアにインポートする必要があります。

Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加
Oracle WebLogic Serverでは、このリリースの時点でsetUserOverridesLate.shスクリプトがサポートされており、ドメイン内の管理サーバーおよび管理対象サーバーの起動時に呼び出されるsetDomainEnv.shスクリプトで設定されたデフォルト構成をオーバーライドする場合に使用する必要があります。setDomainEnv.shスクリプトは、圧縮または解凍操作の実行中に再生成されるため、このスクリプトを編集することはお薦めしません。setDomainEnv.shに対するカスタマイズ内容は失われるため、継続的なメンテナンスが必要になります。各サーバーが更新済のトラスト・ストアに正しくアクセスできるようにするには、エンタープライズ・デプロイメント内の各ドメイン・ホーム・ディレクトリのsetUserOverridesLate.shスクリプトを編集します。このファイルは、packコマンドまたはunpackコマンドの使用時にも適切に維持されます。

  1. OIMHOST1にサインインして、テキスト・エディタで次のファイルを開きます。
    IGD_ASERVER_HOME/bin/setUserOverridesLate.sh
  2. カスタム・トラスト・ストアの正しいパスおよびファイル名を使用して、EXTRA_JAVA_PROPERTIES変数のtrustStoreパラメータを設定するためのコマンドを追加します。
    たとえば: 
    KEYSTORE_HOME/appTrustKeyStore.jks

    ノート:

    EXTRA_JAVA_PROPERTIESのすべての値をファイル内に1行で記述し、その後の新規行にexportコマンドを記述する必要があります。 
    echo "" 
echo "*****************************************************" 
echo "** Executing setUserOverrideLate.sh" 
echo "*****************************************************" 
echo ""  

# 
# Customize SSL Trust Store 
# 
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Djavax.net.ssl.trustStore=/u01/oracle/config/keystores/appTrustKeyStore.jks " 
export EXTRA_JAVA_PROPERTIES  

echo "EXTRA_JAVA_PROPERTIES=\"${EXTRA_JAVA_PROPERTIES}\"" 
echo "" 
echo "*****************************************************" 
echo "** End of setUserOverrideLate.sh" 
echo "*****************************************************" 
echo ""
  3. OIMHOST1、OIMHOST2、OAMHOST1およびOAMHOST2のMSERVER_HOME/binディレクトリに、ASERVER_HOME/bin/setUserOverridesLate.shファイルをコピーします。

    ノート:

    setUserOverrides.shスクリプトではなくsetUserOverridesLate.shスクリプトを使用する必要があります。これを使用しないと、一部の製品コンポーネントによってsetUserOverrides.shスクリプトで設定された値がオーバーライドされることがあります。packおよびunpackツールの使用時には、setUserOverridesLate.shも伝播されます。
カスタム・キーストアを使用するためのWebLogic Serverの構成
Oracle WebLogic Server管理コンソールを使用して、カスタム・キーストアを使用するためにWebLogic Serverを構成します。SSL上のフロント・エンドLBRへのアクセスが必要な管理サーバーおよび管理対象サーバーに対して、次の手順を実行します。

アイデンティティ・キーストアおよび信頼キーストアを構成するには:

  1. 管理コンソールにログインして「ロックして編集」をクリックします。
  2. 管理対象サーバーのタイプに基づいて移動します。
    構成済の管理対象サーバーの場合:
    1. 「ドメイン構造」ペインで「環境」を開き、「サーバー」を選択します。
    2. アイデンティティ・キーストアおよび信頼キーストアを構成するサーバーの名前をクリックします。
    動的な管理対象サーバーの場合:
    1. 「ドメイン構造」ペインで、「環境」、「クラスタ」を開いて、「サーバー・テンプレート」を選択します。
    2. アイデンティティ・キーストアおよび信頼キーストアを構成する適切なサーバー・テンプレートの名前をクリックします。
  3. 「構成」を選択して、「キーストア」を選択します。
  4. 「キーストア」フィールドで、「変更」をクリックし、秘密キー/デジタル証明書のペアおよび信頼できるCA証明書の格納および管理に使用するための「カスタムIDとカスタム信頼」方法を選択して、「保存」をクリックします。
  5. 「ID」セクションで、アイデンティティ・キーストアの属性を定義します。

    • カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。

      KEYSTORE_HOME/appIdentityKeyStore.jks

    • カスタムIDキーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

    • カスタム・アイデンティティ・キーストアのパスフレーズ: 「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で指定したパスワードKeystore_Passwordを入力します

      この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアに、キーストアを書き込むためのパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

  6. 「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。

    • カスタム信頼キーストア: トラスト・キーストアの完全修飾パスを入力します。

      KEYSTORE_HOME/appTrustKeyStore.jks

    • カスタム信頼キーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

    • カスタム信頼キーストアのパスフレーズを確認: Keytoolユーティリティを使用した信頼キーストアの作成でNew_Passwordの値として指定したパスワード。

      前のステップで説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。

  7. 「保存」をクリックします。
  8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
  9. 「ロックして編集」をクリックします。
  10. 「構成」をクリックし、「SSL」をクリックします。
  11. 次のように、SSLアイデンティティの詳細を更新します。
    1. 「秘密キーの別名」フィールドに、適切な秘密キーの別名値を入力します。

      • 静的クラスタに対して: 管理対象サーバーがリスニングするホスト名に対応する別名を入力します。

      • 動的クラスタに対して: 動的な管理対象サーバーが任意のサーバーに一致するように、ワイルドカード別名を入力します。

    2. 「秘密キーのパスフレーズ」フィールドと「秘密キーのパスフレーズを確認」フィールドで、「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。
  12. 「保存」をクリックします。
  13. 動的クラスタのサーバー・テンプレートのSSL構成を更新する場合は、次の追加タスクを実行します。
    1. SSLビューの下部にある「詳細」リンクをクリックします。
    2. 「ホスト名の検証」メニューから「カスタム・ホスト名の検証」オプションを選択します。
    3. 「カスタム・ホスト名の検証」の値をweblogic.security.utils.SSLWLSWildcardHostnameVerifierに設定します。
    4. 「保存」をクリックします。
  14. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。
  15. 管理サーバーを再起動します。
  16. キーストアが更新された管理対象サーバーを再起動します。

    ノート:

    管理コンソール/ノード・マネージャを使用してサーバーを再起動できるということは、ノード・マネージャ、管理サーバー、および管理対象サーバー間の通信が正常であるということです。

  17. Oracle Traffic Directorを使用する場合は、ノード・マネージャ・キーストアが更新されたOTDインスタンスを再起動します。

エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用

永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。

たとえば、JMSサブシステムは、永続JMSメッセージおよび恒久サブスクライバを格納し、JTAトランザクション・ログ(TLOG)は、サーバーが調整するが完了していない可能性のあるコミットされたトランザクションに関する情報を格納します。永続ストアは、ファイルベースのストアまたはJDBC対応データベースの永続性をサポートします。永続ストアの高可用性は、サーバーまたはサービスの移行により提供されます。サーバーまたはサービスの移行では、WebLogicクラスタのすべてのメンバーが、同一のトランザクションとJMS永続ストア(ファイルベースかデータベースベースかを問わない)にアクセスできる必要があります。

エンタープライズ・デプロイメントの場合、トランザクション・ログ(TLOG)とJMSにはJDBC永続ストアを使用することをお薦めします。

この項では、JDBCとファイル永続ストアを比較して利点を分析し、サポートされるデータベースで永続ストアを構成する手順を説明します。JDBCストアではなくファイル永続ストアを使用する場合に、これを構成する手順も、この項で説明します。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

JMS永続ストアとTLOGを使用する製品およびコンポーネント

永続ストアを利用するFMW製品およびコンポーネントを決定するには、WebLogic Serverコンソールの「ドメイン構造」ナビゲーションで、ドメイン名 > 「サービス」 > 「永続ストアを使用します。リストには、ストア、ストア・タイプ(FileStoreおよびJDBC)、およびストアのターゲットが示されます。リストされている中でMDSに関連するストアについてはこの章では扱わず、考慮されません。

これらのコンポーネントは(必要に応じて)ストアをデフォルトで使用します。
コンポーネント/製品 JMSストア TLOGストア

B2B

はい

はい

BAM

はい

はい

BPM

はい

はい

ESS

いいえ

いいえ

HC

はい

はい

Insight

はい

はい

MFT

はい

はい

OSB

はい

はい

SOA

はい

はい

WSM

いいえ

いいえ
コンポーネント/製品 JMSストア TLOGストア

OAM

いいえ

いいえ

OIM

はい

はい
JDBC永続ストアとファイル永続ストアの比較

Oracle Fusion Middlewareは、Oracle WebLogic Serverトランザクション・ログ(TLOG)およびJMSのために、データベースベースとファイルベース両方の永続ストアをサポートします。環境の永続ストア戦略を決定する前に、各アプローチのメリットとデメリットを検討してください。

ノート:

選択するストレージ方法に関係なく、トランザクションの整合性および一貫性を確保するために、JMSとTLOGの両方に同じタイプのストアを使用することをお薦めします。

JMSおよびTLOGのためのJDBC永続ストアについて

OracleデータベースでTLOGおよびJMSデータを格納すると、データベースのレプリケーションや高可用性の機能を利用できます。たとえば、Oracle Data Guardを使用するとサイト間の同期が簡単になります。これは、障害時リカバリ構成にOracle Fusion Middlewareをデプロイしている場合に特に重要です。

また、TLOGおよびJMSデータをデータベースに格納すると、そのデータについて共有記憶域内の特定の場所を指定する必要がありません。ただし、エンタープライズ・デプロイメントの他の観点からも共有記憶域が必要であることに注意してください。たとえば、管理サーバー構成(管理サーバーのフェイルオーバーをサポートするため)、デプロイメント・プラン、ファイルおよびFTPアダプタ制御や処理ファイルなどのアダプタ・アーティファクトには必要です。

TLOGおよびJMSストアを共有記憶域デバイスに格納する場合、適切な複製およびバックアップ戦略を使用してデータ損失ゼロを保証することで、このデータを保護できます。また、システム・パフォーマンスも向上する可能性があります。ただし、ファイル・システムの保護機能はOracle Databaseによって提供される保護機能ほど優れていません。

データベース・ベースのTLOGおよびJMSストアを使用する場合のパフォーマンスへの影響の詳細は、「TLOGおよびJMS永続ストアへのパフォーマンスの考慮事項」を参照してください。

TLOGおよびJMS永続ストアのパフォーマンスの考慮事項

トランザクション・ログとJMSの永続ストアの格納方法を選択する際の重要な考慮事項の1つは、パフォーマンスに対する潜在的な影響です。ここでは、TLOGおよびJMSのJDBC永続ストアの使用によるパフォーマンスの影響を判別するために役立つガイドラインと詳細情報を説明します。

トランザクション・ログおよびJMSストアのパフォーマンスへの影響

トランザクション・ログの場合、ログの性質から非常に一過性が高いため、JDBCストア使用の影響は相対的にわずかです。一般的に、システムの他のデータベース操作と比べると影響は最小です。

一方、JMSデータベース・ストアは、アプリケーションでのJMS使用率が高い場合にパフォーマンスに大きな影響を及ぼすことがあります。

パフォーマンスに影響する要因

JMS DBストアをカスタム宛先で使用するとき、システムのパフォーマンスに影響する要因は複数あります。主なものは、次のとおりです。

  • 関連するカスタム宛先とそのタイプ

  • 永続化されるペイロード

  • SOAシステムでの同時実行性(宛先のコンシューマに対するプロデューサ)

前述のそれぞれの影響の程度に応じて、パフォーマンスを改善するために次に関して様々な設定を構成できます。

  • JMS表に使用されるデータ型のタイプ(RAWの使用対LOBの使用)

  • JMS表のセグメント定義(索引および表レベルのパーティション)

JMSトピックの影響

システムでトピックが集中的に使用されている場合、同時実行性が高まるにつれて、Oracle RACデータベースのパフォーマンス低下はキューの場合よりも大きくなります。JMSを使用するOracleで行ったテストでは、様々なペイロード・サイズと様々な同時実行性での平均パフォーマンス低下はキューの場合は30%未満でした。トピックの場合、影響は40%を超えました。データベース・ストアを使用するかどうかを決めるときには、リカバリの観点からこのような宛先の重要性を検討してください。

データ型とペイロード・サイズの影響

ペイロードで使用するためにRAWデータ型またはSecureFiles LOBデータ型を選択するときは、永続化するペイロードのサイズを考慮します。たとえば、ペイロード・サイズが100バイトから20KBまでの場合、SecureFiles LOBで必要なデータベース時間はRAWデータ型の場合よりも少し長くなります。

具体的には、ペイロード・サイズが約4KBになると、SecureFilesで必要なデータベース時間が長くなります。4KBになると書込みが行の外に移動するためです。ペイロード・サイズが約20KBになると、SecureFilesデータの効率がよくなります。ペイロード・サイズが20KBを超えると、RAWデータ型に設定されたペイロードではデータベース時間が長くなります。

SecureFilesのもう1つの利点は、ペイロードが500KB以上に増加すると、発生するデータベース時間が安定することです。すなわち、その時点で、(SecureFilesにとって)データが500k、1MBまたは2MBのいずれのペイロードを格納しているかは関係なくなります。書込みが非同期化され、すべてのケースで競合が同じになるためです。

ペイロード・サイズが50kに達するまで、キューのスループットに対する同時実行性(プロデューサおよびコンシューマ)の影響はRAWでもSecureFilesでも同じです。ペイロードが小さい場合は、同時実行性を変更しても影響は実質的に同じです(RAWのスケーラビリティが少し上回ります)。ペイロードが50KBを超えると、SecureFilesのスケーラビリティが高くなります。

同時実行性、ワーカー・スレッドおよびデータベース・パーティション化の影響

永続ストアに定義された同時実行性とワーカー・スレッドによって、RACデータベースの索引およびグローバル・キャッシュ・レベルで競合が発生することがあります。1つのサーバーで複数のワーカー・スレッドを有効にするときに逆索引を使用する、または複数のOracle WebLogic Serverクラスタを使用すると、逆索引を使用すると状況が改善する可能性があります。ただし、Oracle Databaseのパーティション化オプションが使用可能な場合は、索引のグローバル・ハッシュ・パーティションをかわりに使用してください。こうすると、索引の競合とグローバル・キャッシュ・バッファの待機が減少し、それによってアプリケーションのレスポンス時間が短縮されます。パーティション化はどのケースでも効果がありますが、逆索引を使用しても大きく改善されないことがあります。

エンタープライズ・デプロイメントのTLOGおよびJMSでのJDBC永続ストアの使用

この項では、トランザクション・ログ(TLOG)およびJMSにJDBC永続ストアを使用するためのガイドラインを説明します。サポートされているデータベースで永続ストアを構成するための手順も説明します。

  • TLOGとJMSデータ・ソース結合の推奨事項
    データ・ソースの集計と接続使用状況の緩和を達成するために、JMS永続ストアとTLOG永続ストアの両方に1つの接続プールを使用します。
  • TLOG用のJDBC永続ストア構成のロードマップ
    次のトピックでは、トランザクション・ログ用にデータベースベースの永続ストアを構成する方法を説明します。
  • JMS用のJDBC永続ストア構成のロードマップ
    次のトピックでは、JMS用にデータベースベースの永続ストアを構成する方法を説明します。
  • TLOG用のユーザーと表領域の作成
    トランザクション・ログ用にデータベースベースの永続ストアを作成する前に、サポートされるデータベースにユーザーと表領域を作成する必要があります。
  • JMS用のユーザーと表領域の作成
    JMS用にデータベースベースの永続ストアを作成する前に、サポートされるデータベースにユーザーと表領域を作成する必要があります。
  • TLOGおよびJMSストアのGridLinkデータ・ソースの作成
    JMSおよびTLOGにデータベースベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。
  • 管理対象サーバーへのTLOG JDBCストアの割当て
    データ・ソース集計を完了するには、TLOG永続ストアの<PREFIX>_WLS表領域およびWLSSchemaDatasourceを再利用します。あるいは、データベースでユーザーと表領域を作成し、データ・ソースが作成済であることを必要な各管理対象サーバーにTLOGストアを割り当てる前に確認します。
  • JDBC JMSストアの作成
    JMS永続ストアのユーザーと表領域をデータベースに作成し、JMS永続ストアのデータ・ソースを作成した後で、管理コンソールを使用してストアを作成できます。
  • JMSサーバーへのJMS JDBCストアの割当て
    データベースでJMSの表領域とユーザーを作成し、JMSデータ・ソースを作成し、JDBCストアを作成した後で、JMS永続ストアを必須のJMSサーバーそれぞれに割り当てることができます。
  • JMS JDBCストアに必要な表の作成
    JMS用のJDBC永続ストアを使用する最後のステップは、必要なJDBCストア表を作成することです。このタスクは、ドメインで管理対象サーバーを再起動する前に実行します。

親トピック: エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用

TLOGとJMSデータ・ソース結合の推奨事項

データ・ソースの結合および接続の使用を減らすには、JMSおよびTLOG永続ストアの両方に単独接続プールを使用します。

作業負荷が高くない場合、およびWLSSchemaDatasourceプール・サイズの増加を考慮する場合は、TLOGおよびJMS永続ストアに対してWLSSchemaDatasourceをそのまま再利用することをお薦めします。データ・ソースを再利用すると、同じスキーマと表領域が必然的に使用され、PREFIX_WLS表領域のPREFIX_WLS_RUNTIMEスキーマがTLOGおよびJMSメッセージの両方に対して使用されます。

データ・ソースに高い負荷がかかっている場合(JMSアクティビティが活発な場合など)および競合が発生している場合は、安定性およびパフォーマンスに問題が発生する可能性があります。たとえば:

  • プールでJMSメッセージを保持するための接続が使用できない場合、データ・ソースで強度の競合が発生すると永続ストアでエラーが発生する可能性があります。

  • プールでトランザクション・ログ更新のための接続が使用できない場合、データ・ソースで強度の競合が発生すると、トランザクションで問題が発生する可能性があります。

これらのケースでは、TLOGとストアに対して個別のデータ・ソース、および異なるストアに対して個別のデータ・ソースを使用します。PREFIX_WLS_RUNTIMEスキーマの再利用も可能ですが、競合の問題を解決するには、同じスキーマに対して個別のカスタム・データ・ソースを構成します。

TLOG用のJDBC永続ストア構成のロードマップ

ここでは、トランザクション・ログ用にデータベースベースの永続ストアを構成する方法を説明します。

  1. TLOGのユーザーと表領域の作成

  2. TLOGおよびJMSストアのGridLinkデータ・ソースの作成

  3. 管理対象サーバーへのTLOG JDBCストアの割当て

ノート:

ステップ1と2はオプションです。データ・ソース連結および接続の使用を削減するには、PREFIX_WLS表領域およびWLSSchemaDatasourceを、「TLOGおよびJMSデータ・ソース結合の推奨事項」に従って再利用します。

JMS用のJDBC永続ストア構成のロードマップ

ここでは、JMSのためにデータベースベースの永続ストアを構成する方法を説明します。

  1. JMSのユーザーと表領域の作成

  2. TLOGおよびJMSストアのGridLinkデータ・ソースの作成

  3. JDBC JMSストアの作成

  4. JMSサーバーへのJMS JDBCストアの割当て

  5. JMS JDBCストアで必要な表の作成

ノート:

ステップ1と2はオプションです。データ・ソース連結および接続の使用を削減するには、PREFIX_WLS表領域およびWLSSchemaDatasourceを、「TLOGおよびJMSデータ・ソース結合の推奨事項」に従って再利用します。

TLOGのユーザーと表領域の作成

トランザクション・ログにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。

  1. tlogsという表領域を作成します。

    たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。 

    SQL> create tablespace tlogs
        logging datafile 'path-to-data-file-or-+asmvolume'
        size 32m autoextend on next 32m maxsize 2048m extent management local;
  2. TLOGSという名前のユーザーを作成し、そのユーザーにtlogs表領域を割り当てます。

    たとえば:

    SQL> create user TLOGS identified by password;

SQL> grant create table to TLOGS;

SQL> grant create session to TLOGS;

SQL> alter user TLOGS default tablespace tlogs;

SQL> alter user TLOGS quota unlimited on tlogs;
JMSのユーザーと表領域の作成

JMSにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。

  1. jmsという表領域を作成します。

    たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。 

    SQL> create tablespace jms
        logging datafile 'path-to-data-file-or-+asmvolume'
        size 32m autoextend on next 32m maxsize 2048m extent management local;
  2. JMSという名前のユーザーを作成し、そのユーザーにjms表領域を割り当てます。

    たとえば:

    SQL> create user JMS identified by password;

SQL> grant create table to JMS;

SQL> grant create session to JMS;

SQL> alter user JMS default tablespace jms;

SQL> alter user JMS quota unlimited on jms;
TLOGおよびJMSストアのGridLinkデータ・ソースの作成

JMSおよびTLOGにデータベース・ベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。

エンタープライズ・デプロイメントでは、TLOGおよびJMSストアでGridLinkデータ・ソースを使用する必要があります。GridLinkデータ・ソースを作成するには:

  1. Oracle WebLogic Server管理コンソールにサインインします。
  2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。
  3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
  4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

    • 「名前」フィールドに、データ・ソースの論理名を入力します。

      TLOGストアの場合はTLOGを入力し、JMSストアの場合はJMSを入力します。

    • JNDIの名前を入力します。

      TLOGストアの場合はjdbc/tlogsを入力し、JMSストアの場合はjdbc/jmsを入力します。

    • 「データベース・ドライバ」には、Oracle Driver (Thin) for GridLink Connections Versions: Anyを選択します。

    • 「次」をクリックします。

  5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」チェック・ボックスをクリアして「次へ」をクリックします。
    「グローバル・トランザクションのサポート」チェックボックス
  6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。
  7. 次の接続プロパティを入力します。

    • サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。たとえば:

      iamedg.example.com

    • ホスト名とポート: RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。たとえば: 

      db-scan.example.com:1521

      「追加」をクリックして、フィールドの下のリスト・ボックスにホスト名とポートを追加します。

      図21-1 RACデータベースのホスト名とポートの詳細の追加

      図21-1の説明が続きます
      「図21-1 RACデータベースのホスト名とポートの詳細の追加」の説明

      SCANアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せると、確認できます。

      SQL>show parameter remote_listener;

NAME                 TYPE        VALUE
 
--------------------------------------------------
 
remote_listener     string      db-scan.example.com

      ノート:

      Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。たとえば: 

      dbhost1-vip.example.com (port 1521)

      および

      dbhost2-vip.example.com (1521)

    • データベース・ユーザー名: 次のように入力します。

      TLOGストアの場合はTLOGSを入力し、JMS永続ストアの場合はJMSを入力します。

    • パスワード: データベースでユーザーを作成した際に使用したパスワードを入力します。

    • パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

  8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。

    接続が成功したときに表示される通知の一例を示します。

    Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan.example.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=iamedg.example.com))) succeeded.

    「次」をクリックします。

  9. 「ONSクライアント構成」ページで、次の手順を実行します。

    • 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

    • SCANアドレス: RACデータベースのONSリモート・ポート、データベースから報告されたONSリモート・ポートを入力し(次の例を参照)、「追加」をクリックします。 

      [orcl@db-scan1 ~]$ srvctl config nodeapps -s
 
ONS exists: Local port 6100, remote port 6200, EM port 2016

    • 「次」をクリックします。

    ノート:

    Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。たとえば: 

    custdbhost1.example.com (port 6200)

    および

    custdbhost2.example.com (6200)
  10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。

    接続が成功したときに表示される通知の一例を示します。

    Connection test for db-scan.example.com:6200 succeeded.

    「次」をクリックします。

  11. 「ターゲットの選択」ページで、永続ストアを使用するクラスタを選択し、「クラスタのすべてのサーバー」を選択します。
  12. 「終了」をクリックします。
  13. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
  14. ステップ4から13を繰り返して、JMSファイル・ストア用のGridLinkデータ・ソースを作成します。
管理対象サーバーへのTLOG JDBCストアの割当て

データ・ソース集計を完了するには、TLOG永続ストアの<PREFIX>_WLS表領域およびWLSSchemaDatasourceを再利用します。あるいは、データベースでユーザーと表領域を作成し、データ・ソースが作成済であることを必要な各管理対象サーバーにTLOGストアを割り当てる前に確認します。

  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「チェンジ・センター」で、「ロックして編集」をクリックします。
  3. 管理対象サーバーのTLOGを構成するには、ドメイン構造ツリーで:
    1. 静的クラスタの場合: 「環境」、「サーバー」の順に開き、管理対象サーバーの名前をクリックします。
    2. 動的クラスタの場合: 「環境」、「クラスタ」、「サーバー・テンプレート」の順に開きます。サーバー・テンプレートの名前をクリックします。
  4. 「構成」>「サービス」タブを選択します。
  5. 「トランザクション・ログ・ストア」で、「タイプ」 メニューから「JDBC」を選択します。
  6. 「データ・ソース」メニューからWLSSchemaDatasourceを選択し、データ・ソースの集計を実行します。TLOGには、<PREFIX>_WLS表領域が使用されます。
  7. 「接頭辞名」フィールドで、構成された各JDBC TLOGストアに一意のJDBC TLOGストア名を生成するための接頭辞名を指定します。
  8. 「保存」をクリックします。
  9. 追加の管理対象サーバーまたはサーバー・テンプレートごとに、ステップ3から7を繰り返します。
  10. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
JDBC JMSストアの作成

データベースでJMS永続ストア・ユーザーと表領域を作成し、JMS永続ストアのデータ・ソースを作成したら、管理コンソールを使用してストアを作成できます。

  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。
  3. 「ドメイン構造」ツリーで「サービス」を開き、「永続ストア」を選択します。
  4. 「新規」をクリックしてから「JDBCストア」をクリックします。
  5. 永続ストアを使用するJMSサーバーとすぐに関連付けることができる永続ストア名を入力します。

    ノート:

    DBがリリース12.2.x.x.x以下の場合は、接頭辞名が30文字を超えないようにしてください。

  6. データ・ソース集計を完了するには、WLSSchemaDatasourceを選択します。JMS永続ストアには、<PREFIX>_WLS表領域が使用されます。
  7. JTAサービスをホストするエンティティをストアの対象として設定します。

    静的クラスタで、サービス移行を使用するサーバーの場合、このエンティティはJMSサーバーが所属する移行可能ターゲットです。

    動的クラスタの場合は、クラスタ自体をターゲットにします。

    動的クラスタの詳細は、『Oracle WebLogic Server JMSリソースの管理』で、簡素化されたJMS集計と高可用性の拡張機能に関する項を参照してください。

  8. クラスタの追加JMSサーバーごとに、ステップ3から7を繰り返します。
  9. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
JMSサーバーへのJMS JDBCストアの割当て

データベースでJMSの表領域とユーザーを作成し、JMSデータ・ソースを作成し、JDBCストアを作成した後で、JMS永続ストアを必須のJMSサーバーそれぞれに割り当てることができます。

JMSサーバーに対してJMS永続ストアを割り当てるには:
  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「チェンジ・センター」で、「ロックして編集」をクリックします。
  3. 「ドメイン構造」ツリーで、「サービス」、「メッセージング」、「JMSサーバー」の順に開きます。
  4. 永続ストアを使用するJMSサーバーの名前をクリックします。
  5. 「永続ストア」メニューで、前に作成したJMS永続ストアを選択します。
  6. 「保存」をクリックします。
  7. クラスタ内の追加のJMSサーバーごとに、ステップ3から6を繰り返します。
  8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
JMS JDBCストアで必要な表の作成

JMSにJDBC永続ストアを使用する最後のステップは、必要なJDBCストア表を作成することです。このタスクは、ドメインで管理対象サーバーを再起動する前に実行します。

  1. 「TLOGおよびJMS永続ストアのパフォーマンスの考慮事項」の情報を確認し、現在の環境に適切な表の機能を決定します。

    このリリースで提供されるOracle DBスキーマ定義は3つあり、前のステップで確認用に抽出されています。基本の定義には、索引用のパーティションがないRAWデータ型が含まれます。2つ目のスキーマではblobデータ型を使用し、3つ目ではblobデータ型およびセキュア・ファイルを使用します。

  2. 共有記憶域でカスタムDDLファイルにドメイン固有の名前の付いたフォルダ構造を作成します。すべてのサーバーで使用できるように、ORACLE_RUNTIME共有ボリュームをお薦めします。

    例:

    mkdir -p ORACLE_RUNTIME/domain_name/ddl
  3. 要件分析に基づいて新しい共有ddlフォルダにjms_custom.ddlファイルを作成します。
    たとえば、セキュア・ファイルとハッシュ・パーティション化の両方を使用する最適化されたスキーマ定義を実装するには、次の内容のjms_custom.ddlファイルを作成します。 
    CREATE TABLE $TABLE (
  id     int  not null,
  type   int  not null,
  handle int  not null,
  record blob not null,
PRIMARY KEY (ID) USING INDEX GLOBAL PARTITION BY HASH (ID) PARTITIONS 8)
LOB (RECORD) STORE AS SECUREFILE (ENABLE STORAGE IN ROW);

    この例をJMSストアのデフォルト・スキーマ定義と比較してください。デフォルトのスキーマ定義では、RAWデータ型が使用され、索引のパーティションはありません。

    パーティション数は2の累乗にする必要があることに注意してください。これにより、各パーティションがほぼ同じサイズになります。推奨するパーティション数は、表または索引サイズの増大をどのように予期するかによって変わります。時間経過に伴う表サイズの増大の分析と、それに応じた表の調整を、データベース管理者(DBA)に依頼する必要があります。『Database VLDBおよびパーティショニング・ガイド』のパーティション化の概念に関する項を参照してください。

  4. 管理コンソールを使用して、前に作成した既存のJDBCストアを編集します。JMSデータのために使用される表を作成します。
    1. Oracle WebLogic Server管理コンソールにログインします。
    2. 「チェンジ・センター」で、「ロックして編集」をクリックします。
    3. 「ドメイン構造」ツリーで「サービス」、「永続ストア」の順に開きます。
    4. 前に作成した永続ストアをクリックします。
    5. 「詳細」オプションで、DDLファイルからの表の作成」フィールドにORACLE_RUNTIME/domain_name/ddl/jms_custom.ddlを入力します。
    6. 「保存」をクリックします。
    7. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
  5. 管理対象サーバーを再起動します。
エンタープライズ・デプロイメントでのTLOGおよびJMSに対するファイル永続ストアの使用
この項では、共有フォルダでTLOGおよびJMSファイル永続ストアを構成するための手順を説明します。
共有フォルダでのTLOGファイル永続ストアの構成

Oracle WebLogic Serverでは、トランザクション・ログを使用してシステムのクラッシュやネットワーク障害からリカバリします。

静的クラスタを使用する共有フォルダのTLOGファイル永続ストアの構成

静的クラスタ内の各管理対象サーバーにデフォルト永続ストアの場所を設定するには、次のステップを実行します。

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

    ADMINVHN:7001/console

    ノート:

    Web層がすでに構成されている場合は、http://admin.example.com/consoleを使用します。

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

  3. クラスタ内の管理対象サーバーごとに、次を実行します。

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

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

    2. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。

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

    3. 「構成」タブで、「サービス」タブをクリックします。

    4. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。

      エンタープライズ・デプロイメントでは、ORACLE_RUNTIMEディレクトリの場所を使用します。このサブディレクトリは、クラスタのトランザクション・ログにとって中心的な共有場所の役割を果たします。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

      たとえば:

      ORACLE_RUNTIME/domain_name/cluster_name/tlogs

      この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。cluster_nameを、先ほど作成したクラスタ名で置き換えます。

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

  4. SOA_Cluster内のすべてのサーバーについて、ステップ3を実行します。

  5. 「変更のアクティブ化」をクリックします。

ノート:

構成手順の後半で、トランザクション・ログの場所と作成について検証します。

動的クラスタを使用した共有フォルダでのTLOGファイル永続ストアの構成

動的クラスタの場合、デフォルトの永続ストアの場所を設定するには、サーバー・テンプレートを更新します。

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

    ADMINVHN:7001/console

    ノート:

    Web層がすでに構成されている場合は、http://admin.example.com/consoleを使用します。

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

  3. クラスタのサーバー・テンプレートに移動します。

    1. 「ドメイン構造」ウィンドウで、「環境」および「クラスタ」ノードを開いて「サーバー・テンプレート」ノードをクリックします。

      「サーバー・テンプレートのサマリー」ページが表示されます。

    2. 表の「名前」列で、サーバー・テンプレートの名前(ハイパーリンクとして表示)をクリックします。

      選択したサーバー・テンプレートの設定ページが開き、「構成」タブがデフォルトで表示されます。

    3. 「構成」タブで、「サービス」タブをクリックします。

    4. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。

      エンタープライズ・デプロイメントでは、ORACLE_RUNTIMEディレクトリの場所を使用します。このサブディレクトリは、クラスタのトランザクション・ログにとって中心的な共有場所の役割を果たします。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

      たとえば:

      ORACLE_RUNTIME/domain_name/cluster_name/tlogs

      この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。cluster_nameを、先ほど作成したクラスタ名で置き換えます。

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

  4. 「変更のアクティブ化」をクリックします。

ノート:

構成手順の後半で、トランザクション・ログの場所と作成について検証します。

トランザクション・ログの場所と作成の検証

WLS_SERVER_TYPE1およびWLS_SERVER_TYPE2管理対象サーバーが稼働したら、「静的クラスタによる共有フォルダでのTLOGファイル永続ストアの構成」と「動的クラスタによる共有フォルダでのTLOGファイル永続ストアの構成」で実行したステップに基づいて、トランザクション・ログ・ディレクトリとトランザクション・ログが想定どおりに作成されていることを確認します。

ORACLE_RUNTIME/domain_name/OSB_Cluster/tlogs

  • _WLS_WLS_SERVER_TYPE1000000.DAT

  • _WLS_WLS_SERVER_TYPE2000000.DAT

共有フォルダでのJMSファイル永続ストアの構成

ドメインをすでに構成および拡張している場合、JMS永続ファイルは共有の場所にすでに構成されています。他の永続ストア・ファイルを共有フォルダに変更する場合は、次のステップを実行します。

  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「ドメイン」→「サービス」→「永続ストア」にナビゲートし、共有フォルダに移動する永続ストアの名前をクリックします。
    「構成: 一般」タブが表示されます
  3. ディレクトリをORACLE_RUNTIME/domain_name/soa_cluster/jmsに変更します。
  4. 「保存」をクリックします。
  5. 「変更のアクティブ化」をクリックします。

WebサービスのJDBC永続ストアについて

デフォルトでは、Webサービスの永続性にはWebLogic Serverデフォルト永続ストアが使用されます。このストアはWebサービスに対して高パフォーマンスの記憶域ソリューションを提供します。

デフォルトWebサービス永続ストアは、次の拡張機能で使用されます。

  • 信頼性のあるメッセージング

  • 接続

  • セキュア通信

  • メッセージ・バッファリング

デフォルト・ストアではなく、JDBC永続ストアをWebLogic ServerのWebサービスで使用することもできます。Webサービスの永続性の詳細は、Webサービスの永続性の管理を参照してください。

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

エンタープライズ・デプロイメントのバックアップとリカバリの実行

Oracle Identity and Access Managementエンタープライズ・デプロイメントに必要なディレクトリと構成データを確実にバックアップするために、次に示すガイドラインに従うことをお薦めします。

ノート:

この項で示す静的なランタイム・アーティファクトの一部は、Network Attached Storage (NAS)からホストされています。可能であれば、これらのボリュームをアプリケーション・サーバーからではなくNASファイラから直接バックアップおよびリカバリします。

Oracle Fusion Middleware製品のバックアップとリカバリの一般情報は、『Oracle Fusion Middlewareの管理』の次の項を参照してください。

表21-2は、一般的なOracle Identity and Access Managementエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。

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

タイプ ホスト 層

データベースOracleホーム

DBHOST1およびDBHOST2

データ層

Oracle Fusion Middleware Oracleホーム

WEBHOST1およびWEBHOST2

Web層

Oracle Fusion Middleware Oracleホーム

OIMHOST1およびOIMHOST2 (またはNASファイラ)

アプリケーション層

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

WEBHOST1、WEHOST2および共有記憶域

該当なし

表21-3は、一般的なOracle Identity and Access Managementエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。

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

タイプ ホスト 層

管理サーバーのドメイン・ホーム(ASERVER_HOME)

OIMHOST1 (またはNASファイラ)

アプリケーション層

アプリケーション・ホーム(APPLICATION_HOME)

OIMHOST1 (またはNASファイラ)

アプリケーション層

Oracle RACデータベース

DBHOST1およびDBHOST2

データ層

スクリプトとカスタマイズ

ホスト当たり

アプリケーション層

デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME)

OIMHOST1 (またはNASファイラ)

アプリケーション層

OHS/OTD構成ディレクトリ

WEBHOST1およびWEBHOST2

Web層

親トピック: すべてのエンタープライズ・デプロイメントの構成および管理タスク

Oracle Identity and Access Managementエンタープライズ・デプロイメントの構成および管理タスク

Oracle Identity and Access Managementエンタープライズ・デプロイメントで実行する必要性が高い、いくつかの主要な構成および管理タスクについて説明します。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理タスク

デプロイメント・プランおよびSOAインフラストラクチャ・アプリケーション更新での共有記憶域の使用

SOAクラスタ内のSOAインフラストラクチャ・アプリケーションまたはリソース・アダプタを再デプロイするときは、デプロイメント・プランとアプリケーション・ビットに、クラスタ内の全サーバーからアクセスできる必要があります。

SOAのアプリケーションおよびリソース・アダプタは、nostageデプロイメント・モードを使用してインストールされます。nostageデプロイメント・モードを選択した場合、管理サーバーはアーカイブ・ファイルをソースの場所からコピーしないため、各サーバーが同じデプロイメント・プランにアクセスできるようにしておく必要があります。

デプロイメント・プランの場所がドメイン内のすべてのサーバーで利用できるようにするには、「このガイドで使用するファイル・システムとディレクトリ変数」で示され、エンタープライズ・デプロイメント・ワークブック内のDEPLOY_PLAN_HOME変数で表される、デプロイメント・プランのホームの場所を使用します。

親トピック: Oracle Identity and Access Managementエンタープライズ・デプロイメントの構成および管理タスク

SOAサーバーでのJMSメッセージの管理

SOAサーバーでJMSメッセージを管理する手順は、いくつかあります。スケール・イン操作の間にメッセージを保持する場合など、一部シナリオでは、これらの手順に従う必要があることがあります。

この項では、これらの手順のいくつかを詳しく説明します。

親トピック: Oracle Identity and Access Managementエンタープライズ・デプロイメントの構成および管理タスク

SOAサーバーからのJMSメッセージの排出

JMSメッセージの排出のプロセスは、特定のWebLogicサーバーからメッセージをクリアするために役立ちます。ストアを排出するための基本的な手法は、適切なJMSサーバーでのメッセージ生成の停止、およびアプリケーションへのメッセージ使用の許可で構成されています。

ただし、この手順は、アプリケーションによって異なり、かかる時間を予測できない可能性があります。別の方法として、ここでは、現在のJMS宛先からの現在のメッセージを保存して、必要な場合にそれらを別のサーバーにインポートするための、一般的な手順を示します。

排出手順は、1つ以上のサーバーを削除することでクラスタのサイズが縮小されるため、スケール・インやスケール・ダウンのシナリオで役立ちます。削除するサーバーからメッセージを排出し、それらをクラスタ内の別のサーバーにインポートすることで、メッセージが失われないようにすることができます。

一部の障害回復保守シナリオで、スナップショット・スタンバイ・データベースを使用することでセカンダリの場所でサーバーを起動するときに、この手順を使用することもできます。この場合は、ドメインの起動時にスタンバイ・ドメインで使用されないようにするために、セカンダリの場所でドメインを起動する前に、ドメインからメッセージを排出する必要があることがあります(そうしないと、実行が重複する可能性があります)。このシナリオでは、メッセージをインポートできません。

サーバーからJMSメッセージを排出するには、次のステップを実行します。
  1. JMSサーバーに対して生成を一時停止することで、新しいワークロードを停止します。操作の影響を受けるサーバーのJMSサーバーごとに、このアクティビティを実行する必要があります。
    1. WebLogicコンソールに移動し、「環境」→「サービス」→「JMSサーバー」→<JMSサーバー名>→「制御」をクリックします。
    2. 削除するサーバーの「JMSサーバー」を選択します。
    3. 「生成」、「休止」の順にクリックします。
  2. 宛先からメッセージを排出します。JMSメッセージを排出するには、アプリケーションで保留中メッセージを使用します。ただし、このタスクは、アプリケーションによって異なり、時間がかかる可能性があります。そのため、各宛先のメッセージをエクスポートすることをお薦めします。どの宛先にメッセージがあるかの確認:
    1. WebLogicコンソールに移動し、「環境」→「サービス」→「JMSサーバー」→「モニタリング」→「アクティブな宛先」をクリックします。
    2. 削除するサーバーの宛先メンバーに現在のメッセージがあるかどうかを確認します。宛先名とそのJMSモジュールを特定します。
    3. 削除するサーバーで実行されているJMSサーバーごとに、このアクティビティを繰り返します。

    • キューからのメッセージの排出: 現在のメッセージがあるキュー宛先の場合:

      1. WebLogicコンソールに移動し、「環境」→「サービス」→「JMSモジュール」→<JMSモジュール名>→<宛先名>をクリックします。

      2. 「モニタリング」をクリックします。

      3. 削除するサーバーとやり取りしているキューを選択し、「メッセージの表示」をクリックします。

      4. 「エクスポート」→「すべてエクスポート」を選択し、メッセージをファイルにエクスポートします。後で使用するために、ファイル名をノートにとります。

      5. 「すべて削除」オプションを使用して、エクスポートしたメッセージを削除します。このステップは、メッセージの重複を避けるために重要となります。

    • トピックからのメッセージの排出

      重大なビジネス・インパクトがある場合のみ、トピックからメッセージを排出およびインポートするようにすることをお薦めします。各トピックの用途およびビジネス・インパクトの詳細は、表21-4を参照してください。EDNによって使用される、トピックdist_EDNTopic_auto内のメッセージの損失のみ、ビジネス・インパクトがあります。

      表21-4 コンポーネントの各トピックの用途とビジネス・インパクトの詳細

      コンポーネント JMSモジュール JMSトピック名 用途 メッセージ損失のビジネス・インパクト

      SOA

      SOAJMSModule

      dist_B2BBroadcastTopic_auto

      B2Bによって使用されます。メッセージは、すぐに使用するためのものです。

      影響なし。

      SOA

      SOAJMSModule

      dist_EDNTopic_auto

      EDN用に使用されます。アプリケーションのイベント・メッセージが含まれています。

      ビジネス・インパクト。

      これらのEDNイベント・メッセージを使用するアプリケーションは、それらを失うことになります。

      SOA

      SOAJMSModule

      dist_TenantTopic_auto

      使用されなくなりました。

      影響なし。

      SOA

      SOAJMSModule

      dist_XmlSchemaChangeNotificationTopic_auto

      使用されなくなりました。

      影響なし。
      トピックからメッセージを排出するには、次のステップに従います。

      1. WebLogicコンソールに移動し、「環境」→「サービス」→「JMSモジュール」→<JMSモジュール名>→<トピック名>をクリックします。

      2. 「モニタリング」、「恒久サブスクライバ」の順に選択します。

      3. 削除するサーバーに対応するトピックを選択し、「適用」をクリックします。ページに、選択したメンバー・トピックについてのみサブスクリプションが表示されます。

      4. 現在のメッセージがある恒久サブスクライバを選択し、「メッセージの表示」をクリックします。

      5. 「エクスポート」→「すべてエクスポート」をクリックし、メッセージをファイルにエクスポートします。後で使用するために、ファイル名をノートにとります。

      6. 「削除」→「すべて削除」をクリックして、サブスクライバからエクスポートしたメッセージを削除します。このステップは、メッセージの重複を避けるために重要となります。

      7. 現在のメッセージがあるトピック内の任意のサブスクライバに対してエクスポート・プロセスを繰り返します。

クロス・コンポーネント・ワイヤリングについての考慮事項

クロス・コンポーネント・ワイヤリング(CCW)を利用すると、FMWコンポーネントは、特定のAPIを使用することによってWLSドメインで使用可能なサービスの一部をパブリッシュし、それにバインドすることができます。

CCWがワイヤリング情報のバインドを実行するのは、構成ウィザードのセッション中のみ、またはWLSドメイン管理者によって手動で強制実行されたときだけです。クラスタにWeblogic Serverを追加するとき(静的または動的クラスタでのスケール・アウトおよびスケール・アップ操作で)、新しいサーバーはサービスを公開しますが、そのサービスを使用するクライアントのすべてが自動的に更新されて、新しいサービス・プロバイダにバインドされるわけではありません。CCW表にすでにバインドされている既存のサーバーは、クラスタに新しいメンバーが追加されたことを自動的に認識しないため、更新は実行されません。これは、ESSおよびWSMPMがSOAにサービスを提供する場合と同じです(両者はサービスをサービス表に動的に公開しますが、SOAサーバーはバインドが再び強制されないかぎり、これらの更新を認識しません)。

ノート:

OHS構成によって使用されるのと似た、追加のクロス・コンポーネント・ワイヤリング情報があります。これはプロキシ・プラグインの動作のため、このワイヤリングによって影響されません。詳細は、次の項を参照してください。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理タスク

WSMPMおよびESS用のクロス・コンポーネント・ワイヤリング

クロス・コンポーネント・ワイヤリングのt3情報は、JNDI呼出しURLで使用されるサーバーのリスト取得する際に、WSMPMとESSによって使用されます。

CCWのt3情報は、動的更新が欠落していてもその影響を制限します。呼出しが完了すると、JNDI URLを使用してRMIスタブとクラスタのメンバーのリストが取得されます。JNDI URLが、サーバーのリスト全体を含んでいる必要はありません。RMIスタブには常にクラスタ内のすべてのサーバーのリストが含まれており、それら全体でのリクエストのロード・バランスに使用されます。そのため、バインドなしに、クラスタに追加されたサーバーが(バインドURLに存在していなくても)使用されます。唯一の欠点は、クラスタの拡張または縮小時にシステムを動作させ続けるために、最初のCCWバインドで指定される元のサーバーのうち少なくとも1つが稼働している必要があるという点です。この問題を回避するために、メンバーの静的リストを使用するかわりにサービス表でクラスタ名構文を使用できます。

クラスタ名構文は、次のとおりです。 
cluster:t3://cluster_name

cluster:t3://cluster_nameを使用すると、CCW呼出しによって常にクラスタ内のすべてのメンバーのリストがフェッチされるため、初期サーバーに依存することなく、そのとき存在するすべてのメンバーが対象になります。

親トピック: クロス・コンポーネント・ワイヤリングの考慮事項

WSMPMでのcluster_name構文の使用

この手順では、WSMPMでt3構文を使用することにより、WSMPMクラスタでサーバーを追加または削除する場合にCCW情報を再更新することを不要にします。

CCW t3情報は、デフォルトでクラスタ構文を使用するように構成されています。クラスタ構文が使用されていることを確認し、必要があれば編集するだけです。

  1. 管理者のアカウントを使用してFusion Middleware Controlにサインインします。たとえば、weblogic_iamです。
  2. 「WebLogicドメイン」ドロップダウン・メニューから、「クロス・コンポーネント・ワイヤリング」-「サービス表」を選択します。
  3. 「OWSMポリシー・マネージャ」のurn:oracle:fmw.owsm-pm:t3行を選択します。
  4. クラスタ構文が使用されていることを確認します。そうでない場合、「編集」をクリックして、クラスタ名構文を使用してt3およびt3sの値を更新します。
  5. 「OK」をクリックします。
  6. 「WebLogicドメイン」ドロップダウン・メニューから、「クロス・コンポーネント・ワイヤリング」-「コンポーネント」を選択します。
  7. 「OWSMエージェント」を選択します。
  8. 「クライアント構成」セクションで、owsm-pm-connection-t3行を選択して「バインド」をクリックします。
  9. 「OK」をクリックします。

ノート:

ワイヤリング表は、クラスタのスケール・アウトまたはスケール・アップのたびに更新されますが、手動の再バインドを使用しないかぎり、クラスタ構文を置き換えはしません。したがって、クラスタのライフサイクルのあらゆる更新(追加、削除)の影響を受けません。

親トピック: クロス・コンポーネント・ワイヤリングの考慮事項

動的クラスタ内のサーバーの起動と停止

構成済の静的クラスタ内のサーバー・インスタンスの起動および停止に使用する方法と同じ方法を使用して、動的クラスタ内のサーバー・インスタンスを起動および停止できます。

構成済クラスタ内のサーバー・インスタンスを起動および停止する方法は次のとおりです。

  • WebLogic Server管理コンソール

  • Fusion Middleware Control

  • WLSTのstartコマンドとshutdownコマンド

  • ノード・マネージャ

  • 起動スクリプト

選択する起動方法や実行済のタスクに応じて、サーバー・インスタンスを起動する前に他の手順の実行が必要になる場合があります。『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。

ノート:

始める前に、WebLogic Serverが、サーバー・インスタンスを実行するすべてのホストにインストールされていることを確認します。ノード・マネージャを使用してサーバー・インスタンスを起動および停止する場合は、それらのホスト上でノード・マネージャも実行する必要があります。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理タスク

動的クラスタの拡張と縮小

動的クラスタを作成すると、WebLogic Serverでは指定した数の動的サーバーが生成されます。サーバー・インスタンスの数を決定する前に、希望の数を処理するための性能があることを確認してください。

使用可能な動的サーバー・インスタンスの数は、特定の動的クラスタのサーバー・テンプレートで指定されている構成済の最大値に基づいています。容量要件の一時的な変更は、クラスタ内の使用可能な管理対象サーバーの一部を起動または停止することにより簡単に実現できます。高可用性を維持するためには、少なくとも2台か3台必要であることに注意してください。

最初に指定した数のサーバー・インスタンスに追加が必要となった場合、動的クラスタの構成で動的サーバーの最大数を増やすことができます。動的クラスタ内のサーバー・インスタンスの数を減らすには、動的サーバーの属性の最大数の値を減らします。この値を小さくする前に、削除する予定のサーバー・インスタンスを停止します。

WLSTのscaleUpコマンドとscaleDownコマンドを使用して、動的クラスタを管理することもできます。動的クラスタ内の動的サーバーの数を増やすには、scaleUpコマンドを使用して、updateConfiguration引数を有効にします。WLSTでは、指定した数のサーバーの分だけクラスタの最大サイズを増やし、サーバー・インスタンスを起動します。

scaleUpコマンドにより、指定した動的クラスタの実行サーバーの数が増加します。サーバーIDが最も小さい非実行サーバー・インスタンスが最初に起動し、指定した数のサーバー・インスタンスが起動するまで、次に大きなIDの非実行サーバー・インスタンスの起動が続きます。

動的クラスタ内で1つ、すべて、または任意の数のサーバー・インスタンスを起動するには、scaleUpコマンドでnumServers引数を使用して目的の数を指定します。利用可能なすべてのサーバー・インスタンスがすでに実行している場合、指定した数のサーバーを起動する前に、scaleUpコマンドにより、リクエストしたサーバー・インスタンスの最小数までクラスタのサイズを増やします。

動的クラスタの最大サイズを減らすには、scaleDownコマンドを使用して、updateConfiguration引数を有効にします。WLSTでは、指定した数の実行サーバー・インスタンスを適切に停止して、それらを動的クラスタから削除します。『WebLogic Server WLSTコマンド・リファレンス』のscaleUpに関する項およびscaleDownに関する項を参照してください。scaleDownコマンドでは、指定した数の実行サーバーを適切に停止します。サーバーIDが最も大きいサーバー・インスタンスが最初に停止し、指定した数のサーバー・インスタンスが停止するまで、次に大きなIDのサーバー・インスタンスの停止が続きます。

ノート:

動的サーバー・インスタンスでは、WLSTのscaleUpコマンドとscaleDownコマンドのみ使用できます。手動で構成したサーバー・インスタンスと動的サーバー・インスタンスの両方が含まれる混在クラスタの場合、scaleUpコマンドとscaleDownコマンドでは、構成済サーバーが無視されます。混在クラスタ内の構成済サーバー・インスタンスを手動で起動して停止する必要があります。

たとえば、クラスタ内に、実行中の動的サーバー2台と実行していない構成済サーバー2台があるとします。scaleUpコマンドを使用する場合、WLSTでは、クラスタに動的サーバー・インスタンスを1つ追加して、動的サーバーを起動します。

WLSTのscaleUpコマンドとscaleDownコマンドには、動的クラスタを手動でスケーリングする方法が用意されています。自動スケーリングの場合、動的クラスタの拡張度を構成できます。拡張度を使用する場合、動的クラスタでは、要求に反応して、あるいはカレンダ・ベースのスケジュールのとおりにスケーリング操作や再プロビジョニング操作を自動で実行できます。WebLogic Serverでは、WebLogic診断フレームワーク(WLDF)のポリシーおよびアクション・システムによって動的クラスタに拡張度が提供されます。「Oracle WebLogic Server動的クラスタの拡張度の構成」を参照してください。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理タスク