プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド
12c (12.2.1.4.0)
E96110-02
目次へ移動
目次
前
前 		次
次

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

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

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

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

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

前提条件:

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

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

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

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

    • BIHOST1: 100.200.140.165

    • BIHOST2: 100.200.140.205

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

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

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

ここでは、管理サーバーのフェイルオーバー手順のテストを実行する方法を詳しく説明します。
  • 別のホストへの管理サーバーのフェイルオーバー
    次の手順は、管理サーバーを別のノード(BIHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。
  • Oracle HTTP Serverを介したBIHOST2上の管理サーバーへのアクセスの検証
    Web階層を構成してAdminServerにアクセスする場合、管理サーバーのフェイルオーバーを手動で実行した後、標準管理URLを使用して管理サーバーにアクセスできることを検証することが重要です。
  • エンタープライズ・デプロイメントの管理用のロールの構成
    単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理するには、特定の管理ロールまたはグループを必要とする製品を理解することに加え、製品固有の管理ロールをエンタープライズ・デプロイメント管理グループに追加する方法を理解することが必要です。
  • BIHOST1への管理サーバーのフェイルバック
    管理サーバーの手動フェイルオーバーをテストして、フェイルオーバー後に管理URLにアクセスできることを検証した後、管理サーバーをその元のホストに移行できます。

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

13.1.1 別のホストへの管理サーバーのフェイルオーバー

次の手順は、管理サーバーを別のノード(BIHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。

この手順では、エンタープライズ・トポロジに対してドメインごとのノード・マネージャを構成していることが前提となります。「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください

管理サーバーを別のホストにフェイルオーバーするには:

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

  2. 管理サーバー・ドメイン・ディレクトリ(ASERVER_HOME)のノード・マネージャを停止します。

  3. ADMINVHN仮想IPアドレスを第2ホストに移行します。

    1. 次のコマンドをBIHOST1上でrootとして実行し、仮想IPアドレスをそのCIDRでチェックします。

      ip addr show dev ethX

      ここで、XはADMINVHNで現在使用されているインタフェースです。

      次に例を示します。
      ip addr show dev eth0

    2. BIHOST1で次のコマンドをroot権限で実行します(X:YはADMINVHNで現在使用しているインタフェース)。

      ip addr del ADMINVHN/CIDR dev ethX:Y

      ここで、X:YはADMINVHNで現在使用されているインタフェースです。

      次に例を示します。
      ip addr del 100.200.140.206/24 dev eth0:1

    3. BIHOST2で次のコマンドをルートとして実行します。

      ip addr add ADMINVHN/CIDR dev ethX label ethX:Y

      ここで、X:YはADMINVHNで現在使用されているインタフェースです。

      次に例を示します。
      ip addr add 100.200.140.206/24 dev eth0 label eth0:1

      注意:

      使用するネットマスクとインタフェースを表すCIDRは、BIHOST2で使用可能なネットワーク構成と一致している必要があります。

      特に冗長結合インタフェースを持つシステムの場合、ネットワーク・インタフェースのデバイス名がX以外のものである場合があります。

  4. 次の例のように、arpingを使用してルーティング表を更新します。

    arping -b -A -c 3 -I eth0 100.200.140.206

  5. BIHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。

  6. BIHOST2で管理サーバーを起動します。

  7. 次の方法でBIHOST2上の管理サーバーにアクセスできることをテストします。

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

      http://ADMINVHN:7001/console

    2. 次のURLを使用して、Fusion Middleware Controlのコンポーネントにアクセスできることを確認し、そのステータスを検証します。

      http://ADMINVHN:7001/em

親トピック: 管理サーバーの手動フェイルオーバーの検証

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

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

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

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

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

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

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

親トピック: 管理サーバーの手動フェイルオーバーの検証

13.1.3 エンタープライズ・デプロイメントの管理用ロールの構成

単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理するには、特定の管理ロールまたはグループを必要とする製品を理解することに加え、製品固有の管理ロールをエンタープライズ・デプロイメント管理グループに追加する方法を理解することが必要です。

各エンタープライズ・デプロイメントは複数の製品で構成されています。製品の一部には、各製品への管理アクセスの制御に使用される、特定の管理ユーザー、ロールまたはグループが存在します。

ただし、複数の製品で構成されているエンタープライズ・デプロイメントでは、単一のLDAPベースの認可プロバイダと、単一の管理ユーザーおよびグループを使用して、デプロイメントのあらゆる側面に対するアクセスを制御できます。「新しいLDAPオーセンティケータの作成と新しいエンタープライズ・デプロイメント管理者ユーザーおよび管理者グループのプロビジョニング」を参照してください。

単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理できるようにするには、特定の管理ロールまたはグループを必要とする製品を理解すること、単一の共通エンタープライズ・デプロイメントの管理グループに特定の製品管理ロールを追加する方法を知ること、さらに必要な場合は、必須の製品固有の管理グループにエンタープライズ・デプロイメントの管理ユーザーを追加する方法を知ることが必要になります。

詳細な情報は、次のトピックを参照してください

親トピック: 管理サーバーの手動フェイルオーバーの検証

13.1.3.1 製品固有の管理グループへのエンタープライズ・デプロイメントの管理ユーザーの追加

製品固有の管理グループを持つ製品では、次の手順を使用して、エンタープライズ・デプロイメントの管理ユーザー(weblogic_bi)をグループに追加します。これにより、Enterprise Managerの管理者ユーザーを使用して製品を管理できるようになります。

  1. 以下に示すような、product_admin_group.ldifというLDIFファイルを作成します。
    dn: cn=product-specific_group_name, cn=groups, dc=us, dc=oracle, dc=com
displayname: product-specific_group_display_name
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
uniquemember: cn=weblogic_bi,cn=users,dc=us,dc=oracle,dc=com
cn: product-specific_group_name
description: Administrators Group for the Domain

    product-specific_group_display_nameを、LDAPサーバーの管理コンソールとOracle WebLogic Server管理コンソールに表示されるグループの表示名と置き換えます。

  2. LDIFファイルを使用して、エンタープライズ・デプロイメントの管理者ユーザーを製品固有の管理グループに追加します。

    Oracle Unified Directoryの場合:

    OUD_INSTANCE_HOME/bin/ldapmodify -a 
                                 -D "cn=Administrator" 
                                 -X 
                                 -p 1389 
                                 -f product_admin_group.ldif

    Oracle Internet Directoryの場合:

    OID_ORACLE_HOME/bin/ldapadd -h oid.example.com 
                            -p 389 
                            -D cn="orcladmin" 
                            -w <password> 
                            -c 
                            -v 
                            -f product_admin_group.ldif

親トピック: エンタープライズ・デプロイメントの管理用のロールの構成

13.1.4 BIHOST1への管理サーバーのフェイルバック

管理サーバーの手動フェイルオーバーをテストして、フェイルオーバー後に管理URLにアクセスできることを検証した後、管理サーバーをその元のホストに移行できます。

  1. 管理サーバーを停止します。
  2. 管理サーバー・ドメイン・ディレクトリ(ASERVER_HOME)のノード・マネージャを停止します。
  3. ADMINVHN仮想IPアドレスを第2ホストに移行します。

    1. 次のコマンドをBIHOST2上でrootとして実行し、仮想IPアドレスをそのCIDRでチェックします。

      ip addr show dev ethX

      ここで、XはADMINVHNで現在使用されているインタフェースです。

      次に例を示します。
      ip addr show dev eth0

    2. BIHOST2で次のコマンドをroot権限で実行します(X:YはADMINVHNで現在使用しているインタフェース)。

      ip addr del ADMINVHN/CIDR dev ethX:Y

      ここで、X:YはADMINVHNで現在使用されているインタフェースです。

      次に例を示します。
      ip addr del 100.200.140.206/24 dev eth0:1

    3. BIHOST1で次のコマンドをrootとして実行します。

      ip addr add ADMINVHN/CIDR dev ethX label ethX:Y

      ここで、X:YはADMINVHNで現在使用されているインタフェースです。

      次に例を示します。
      ip addr add 100.200.140.206/24 dev eth0 label eth0:1

      注意:

      使用するネットマスクとインタフェースを表すCIDRは、BIHOST1で使用可能なネットワーク構成と一致している必要があります。

  4. 次の例のように、arpingを使用してルーティング表を更新します。
    arping -b -A -c 3 -I eht0 100.200.140.206
  5. BIHOST1上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。
  6. BIHOST1上で管理サーバーを起動します。
  7. 次の方法でBIHOST1上の管理サーバーにアクセスできることをテストします。

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

      http://ADMINVHN:7001/console

    2. 次のURLを使用して、Fusion Middleware Controlのコンポーネントにアクセスできることを確認し、そのステータスを検証します。

      http://ADMINVHN:7001/em

親トピック: 管理サーバーの手動フェイルオーバーの検証

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

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

注意:

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

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

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

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

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

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

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

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(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 BIHOST1.example.com_cert \
      BIHOST1.example.com_key domestic BIHOST1.example.com

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

    次に例を示します。

    java utils.CertGen password WILDCARD.example.com_cert \ 
WILDCARD.example.com_key domestic \*.example.com

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

13.2.3 utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

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

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

注意:

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

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

    構文:

    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/BIHOST1.example.com_cert.pem\
     -keyfile KEYSTORE_HOME/BIHOST1.example.com_key.pem\
     -keyfilepass password\
     -keystore appIdentityKeyStore.jks\
     -storepass password\ 
     -alias BIHOST1\
     -keypass password
  2. ホストに固有の残りの証明書とキーの組合せに対して(たとえば、BIHOST1、BIHOST2に対して)、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

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

13.2.4 Keytoolユーティリティを使用した信頼キーストアの作成

BIHOST1.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通信の有効化

13.2.5 トラスト・ストアへのロード・バランサ証明書のインポート

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 login.example.com:443 -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM > SHARED_CONFIG_DIR/keystores/login.example.com.pem

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

    次に例を示します。

    keytool -import -file /oracle/certificates/bi.example.com.crt -v -keystore appTrustKeyStore.jks

注意:

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

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

13.2.6 Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

setDomainEnv.shスクリプトは、Oracle WebLogic Serverによって提供され、ドメイン内の管理サーバーと管理対象サーバーの起動に使用されます。各サーバーが更新済のトラスト・ストアにアクセスできるようにするには、エンタープライズ・デプロイメント内の各ドメイン・ホーム・ディレクトリのsetDomainEnv.shスクリプトを次のように編集します。
  1. BIHOST1にログインして、テキスト・エディタで次のファイルを開きます。
    ASERVER_HOME/bin/setDomainEnv.sh
  2. 既存のDemoTrust.jksエントリへの参照を、次のエントリに置き換えます。

    注意:

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

    EXTRA_JAVA_PROPERTIES="-Djavax.net.ssl.trustStore=/u01/oracle/config/keystores/appTrustKeyStore.jks ${EXTRA_JAVA_PROPERTIES} ......." 
export EXTRA_JAVA_PROPERTIES
  3. BIHOST1、BIHOST2、WEBHOST1およびWEBHOST2のMSERVER_HOME/binディレクトリにあるsetDomainEnv.shファイルに、同じ変更を行います。

    注意:

    setDomainEnv.shファイルは、ASERVER_HOME/binとMSERVER_HOME/binとの間でコピーすることはできません。これは、これら2つのドメイン・ホームの場所のファイルに違いがあるためです。MSERVER_HOME/bin/setDomainEnv.shファイルは、ホスト間でコピーできます。

    ドメイン拡張のたびに、WebLogic Serverは自動的にsetDomainEnv.shファイルを上書きします。また、一部のパッチによって、このファイルが置き換えることもあります。この種の保守操作が終わるたびに、setDomainEnv.shへのカスタマイズを検証してください。

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

13.2.7 カスタム・キーストアを使用するためのノード・マネージャの構成

カスタム・キーストアを使用するようにノード・マネージャを構成するには、すべてのノード内のASERVER_HOME/nodemanagerディレクトリとMSERVER_HOME/nodemanagerディレクトリの両方にあるnodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity KeyStore
CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd
CustomIdentityAlias=Identity Key Store Alias
CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate

ノード・マネージャのリスニング・アドレスのCustomIdentityAliasには必ず正しい値を使用してください。たとえば、utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成に関する項の手順に従って、BIHOST1 MSERVER_HOMEで別名BIHOST1を使用し、BIHOST1のASERVER_HOMEで別名ADMINVHNを使用します。

Example for BIHOST1:
KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=KEYSTORE_HOME/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=BIHOST1
CustomIdentityPrivateKeyPassPhrase=password

nodemanager.propertiesファイルのパスフレーズ・エントリは、ノード・マネージャの起動時に暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイルのエントリが暗号化されていない状態になる時間は最小限に抑えてください。ファイルを編集した後、できるだけ速やかにノード・マネージャを再起動し、エントリを暗号化します。

注意:

この構成の実行後、ドメインを拡張するたびにCustomIdentityAliasを修正する必要があります。解凍操作によって、ドメイン構成が書き込まれるときにCustomIdentityAliasが管理サーバーの値に置き換えられます。

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

13.2.8 カスタム・キーストアを使用するためのWebLogic Serverの構成

Oracle WebLogic Server管理コンソールを使用して、カスタム・キーストアを使用するためにWebLogic Serverを構成します。SSL上のフロント・エンドLBRへのアクセスが必要な管理サーバーおよび管理対象サーバーに対して、次の手順を実行します。

IDキーストアおよび信頼キーストアを構成するには:

  1. 管理コンソールにログインして「ロックして編集」をクリックします。
  2. 管理対象サーバーのタイプに基づいて移動します。
    構成済の管理対象サーバーの場合:
    1. 「ドメイン構造」ペインで「環境」を開き、「サーバー」を選択します。
    2. IDキーストアおよび信頼キーストアを構成するサーバーの名前をクリックします。
    動的な管理対象サーバーの場合:
    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インスタンスを再起動します。

親トピック: 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

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

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

注意:

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

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

  • 環境のバックアップ

  • 環境のリカバリ

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

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

タイプ ホスト 層

データベースOracleホーム

DBHOST1およびDBHOST2

データ層

Oracle Fusion Middleware Oracleホーム

WEBHOST1およびWEBHOST2

Web層

Oracle Fusion Middleware Oracleホーム

BIHOST1およびBIHOST2 (またはNASファイラ)

アプリケーション層

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

WEBHOST1、WEHOST2および共有記憶域

N/A

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

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

タイプ ホスト 層

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

BIHOST1 (またはNASファイラ)

アプリケーション層

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

BIHOST1 (またはNASファイラ)

アプリケーション層

Oracle RACデータベース

DBHOST1およびDBHOST2

データ層

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

ホスト当たり

アプリケーション層

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

BIHOST1 (またはNASファイラ)

アプリケーション層

OHS/OTD構成ディレクトリ

WEBHOST1およびWEBHOST2

Web層

シングルトン・データ・ディレクトリ(SDD)

BIHOST1 (またはNASファイラ)

アプリケーション層

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

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

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

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

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

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

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

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

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

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

B2B

あり

あり

BAM

あり

あり

BPM

あり

あり

ESS

なし

なし

HC

あり

あり

Insight

あり

あり

MFT

あり

あり

OSB

あり

あり

SOA

あり

あり

WSM

なし

なし
コンポーネント/製品 JMSストア TLOGストア

OAM

なし

なし

OIM

あり

あり

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

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

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

注意:

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

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

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

TLOGおよびJMSデータをOracleデータベースに格納する場合、データベースの複製機能と高可用性機能を利用できます。たとえば、Oracle Data Guardを使用するとサイト間の同期が簡単になります。これは、Oracle Fusion Middlewareを障害回復構成でデプロイする場合に特に重要です。

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

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

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

親トピック: JDBC永続ストアとファイル永続ストアの比較

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

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

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

トランザクション・ログの場合、ログは本質的に一時的であるため、JDBCストアの使用による影響は比較的小さくて済みます。通常、システム内の他のデータベース操作と比較した場合、影響はほとんどありません。

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

パフォーマンスに影響を与える要素

カスタム宛先にJMS DBストアを使用する場合、複数の要素がパフォーマンスに影響を与えます。主なものは、次のとおりです。

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

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

  • SOAシステムの同時実行性(宛先のコンシューマおよびプロデューサ)

上述のいずれかの影響に応じて、次の領域に様々な設定を構成し、パフォーマンスを向上させることができます。

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

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

JMSトピックの影響

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

データ型およびペイロード・サイズの影響

ペイロードで使用するためにRAWデータ型またはSecureFiles LOBデータ型を選択するときは、永続化するペイロードのサイズを考慮します。たとえば、ペイロード・サイズの範囲が100bから20kの場合、SecureFiles LOBデータ型で必要とされるデータベース時間の量はRAWデータ型よりも若干多くなります。

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

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

ペイロード・サイズが50kに達するまで、キューのスループットに対する同時実行性(プロデューサおよびコンシューマ)の影響はRAWでもSecureFilesでも同じです。ペイロードが小さい場合、同時実行性が変化してもその影響はほぼ同じですが、RAWの方がスケーラビリティがやや優れています。ペイロードが50kを超える場合、SecureFilesの方がスケーラビリティが優れています。

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

永続ストアに定義された同時実行性とワーカー・スレッドは、索引レベルおよびグローバル・キャッシュ・レベルでRACデータベースの競合の原因になることがあります。1つの単一サーバーで複数のワーカー・スレッドを有効にする場合、または複数のOracle WebLogic Serverクラスタを使用する場合、リバース索引を使用することで様々なことを改善できます。ただし、Oracle Databaseのパーティション化オプションを使用できる場合、かわりにグローバル・ハッシュ・パーティション索引を使用する必要があります。これにより、索引の競合およびグローバル・キャッシュ・バッファ待機が減少し、アプリケーションのレスポンス時間が改善されます。パーティション化はどのケースでも適切に機能しますが、リバース索引で大幅な改善が認められない場合もあります。

親トピック: JDBC永続ストアとファイル永続ストアの比較

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

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

  • TLOGおよびJMS永続ストアのパフォーマンスの考慮事項
    データ・ソースの結合および接続の使用を減らすには、JMSとTLOG永続ストアの両方に単独接続プールを使用します。
  • 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に対する永続ストアの使用

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:

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

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

13.4.3.3 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およびJMSでのJDBC永続ストアの使用

13.4.3.4 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;

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

13.4.3.5 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でのJDBC永続ストアの使用

13.4.3.6 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のサービス名を入力します。次に例を示します。

      biedg.example.com

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

      db-scan.example.com:1521

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

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

      図13-1の説明が続きます
      「図13-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=biedg.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およびJMSでのJDBC永続ストアの使用

13.4.3.7 管理対象サーバーへの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. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

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

13.4.3.8 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. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

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

13.4.3.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. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

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

13.4.3.10 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);

    この例を、索引パーティションなしでRAWデータ型が使用される、JMSストアのデフォルトのスキーマ定義と比較することができます。

    パーティションの数は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でのJDBC永続ストアの使用

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

この項では、共有フォルダでTLOGおよびJMSファイル永続ストアを構成するための手順を説明します。

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

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

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

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

13.4.4.1.1 静的クラスタを使用する共有フォルダの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. 「変更のアクティブ化」をクリックします。

注意:

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

13.4.4.1.2 動的クラスタを使用した共有フォルダでの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. 「変更のアクティブ化」をクリックします。

注意:

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

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

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

ORACLE_RUNTIME/domain_name/OSB_Cluster/tlogs

  • _WLS_WLS_SERVER_TYPE1000000.DAT

  • _WLS_WLS_SERVER_TYPE2000000.DAT

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

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

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

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

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

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

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

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

  • 接続

  • セキュア通信

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

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

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

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

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

注意:

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

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

  • 環境のバックアップ

  • 環境のリカバリ

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

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

タイプ ホスト 層

データベースOracleホーム

DBHOST1およびDBHOST2

データ層

Oracle Fusion Middleware Oracleホーム

WEBHOST1およびWEBHOST2

Web層

Oracle Fusion Middleware Oracleホーム

BIHOST1およびBIHOST2 (またはNASファイラ)

アプリケーション層

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

WEBHOST1、WEHOST2および共有記憶域

N/A

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

表13-4 Oracle Business Intelligenceエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト

タイプ ホスト 層

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

BIHOST1 (またはNASファイラ)

アプリケーション層

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

BIHOST1 (またはNASファイラ)

アプリケーション層

Oracle RACデータベース

DBHOST1およびDBHOST2

データ層

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

ホスト当たり

アプリケーション層

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

BIHOST1 (またはNASファイラ)

アプリケーション層

OHS/OTD構成ディレクトリ

WEBHOST1およびWEBHOST2

Web層

シングルトン・データ・ディレクトリ(SDD)

BIHOST1 (またはNASファイラ)

アプリケーション層

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

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

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

Weblogic Server管理コンソールでフロントエンド・ホストおよびポートを設定する手順は次のとおりです。

  1. WebLogic Server管理コンソールにログインします。
  2. 「チェンジ・センター」で「ロックして編集」をクリックします。
  3. 「ドメイン構造」パネルで、「環境」を開き、「クラスタ」をクリックします。
  4. 「クラスタ」ページで、変更するクラスタをクリックし、「HTTP」タブを選択します。
  5. 次の値を設定します。

    • クラスタ名: BI_Cluster

    • フロントエンド・ホスト: bi.example.com

    • フロントエンドHTTPポート: 80

    • フロントエンドHTTPSポート: 442

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

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

前
前 		次
次
目次へ移動
目次