19 エンタープライズ・デプロイメントの共通の構成および管理タスク
構成タスクには、サイジング情報の確認やバックアップとリカバリの実行など、すべてのエンタープライズ・デプロイメントに共通するいくつかの手順が含まれます。エンタープライズ・デプロイメントへのパッチ適用およびコンポーネントのクロス・ワイヤリングは、その他の共通タスクです。
この章の内容は次のとおりです。
- すべてのエンタープライズ・デプロイメントの構成および管理タスク
Oracle Fusion Middlewareエンタープライズ・デプロイメントに適用されるこれらの共通の構成タスクを完了します。これらのタスクには、デプロイメントのサイジング要件の確認、Webサービス用のJDBC永続ストアの使用、およびデプロイメントのバックアップの取得が含まれます。 - Oracle Identity and Access Managementエンタープライズ・デプロイメントの構成および管理タスク
Oracle Identity and Access Managementエンタープライズ・デプロイメントで実行する必要性が高い重要な構成および管理タスクの一部です。 - クロス・コンポーネント・ワイヤリングについての考慮事項
クロス・コンポーネント・ワイヤリング(CCW)を利用すると、FMWコンポーネントは、特定のAPIを使用することによってWLSドメインで使用可能なサービスの一部をパブリッシュし、それにバインドできます。 - 動的クラスタ内のサーバーの起動と停止
構成済の静的クラスタ内のサーバー・インスタンスの起動および停止に使用する方法と同じ方法を使用して、動的クラスタ内のサーバー・インスタンスを起動および停止できます。 - 動的クラスタの拡張と縮小
動的クラスタを作成すると、指定した数の動的サーバーがWebLogic Serverによって生成されます。サーバー・インスタンスの数を決定する前に、希望の数を処理するための性能があることを確認してください。
すべてのエンタープライズ・デプロイメントの構成および管理タスク
Oracle Fusion Middlewareエンタープライズ・デプロイメントに適用されるこれらの共通の構成タスクを完了します。これらのタスクには、デプロイメントのサイジング要件の確認、Webサービス用のJDBC永続ストアの使用、およびデプロイメントのバックアップの取得が含まれます。
- WLSSchemaDataSourceの適切なサイズ変更および構成の確認
WLSSchemaDataSource
は、JMS JDBCストア、JTA JDBCストアおよびリース・サービスのFMWコンポーネントで使用するために予約されている共通データベースです。WLSSchemaDataSource
は、クリティカルなWLSインフラストラクチャ・サービスで競合を回避し、デッドロックに備えるために使用されます。 - 管理サーバーの手動フェイルオーバーの確認
ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次の各項で、OIMHOST1およびOIMHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証するステップについて説明します。 - 動的クラスタ・サーバー・テンプレートでのリスニング・アドレスの構成
動的クラスタにおける動的な管理対象サーバーのデフォルト構成では、使用可能なネットワーク・インタフェースすべてでリスニングするようになっています。ほとんどの場合、これは望ましくありません。 - エンタープライズ・ドメインでのuploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。また、AdminServerのアップロード・ディレクトリを、相対パスではなく、同じ絶対パスを持つように更新します。そうしないと、デプロイメントの問題が発生する可能性があります。動的クラスタを実装する場合、新しく追加した各クラスタに割り当てられたサーバー・テンプレートの構成を検証および更新する必要があります。そうでない場合、新しく追加したクラスタの静的に定義された各管理対象サーバーを検証および構成します。 - WebLogicクラスタのフロントエンド・ホストおよびポートの設定
Oracle Identity and Access ManagementサーバーをホストするOracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。これらの値は、ドメインのプロパティを指定する際に構成ウィザードで指定できます。 - 中間層とハードウェア・ロード・バランサ間の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上の管理サーバーへのアクセスの検証
Web階層を構成してAdminServerにアクセスする場合、管理サーバーのフェイルオーバーを手動で実行した後、標準管理URLを使用して管理サーバーにアクセスできることを検証することが重要です。
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が表示されます。
親トピック: 管理サーバーの手動フェイルオーバーの検証
動的クラスタ・サーバー・テンプレートのリスニング・アドレスの構成
動的クラスタ内の動的管理対象サーバーのデフォルトの構成では、すべての使用可能なネットワーク・インタフェースをリスニングします。ほとんどの場合、これは望ましくありません。
WebLogic Serverには、クラスタ内の動的サーバーの索引番号に対応する"${id}"マクロがあります。この索引は、数字の"1"から始まり、現在のクラスタの管理対象サーバー数だけ増加されます。この連続採番されるサーバーIDマクロは、動的サーバーごとに特定のネットワーク・インタフェースでリスニングするようにリスニング・アドレスが計算される、推奨のホストのネーミング・パターンに使用できます。
このアプローチは、クラスタ当たりのホストごとに管理対象サーバーが1つのみ存在し、クラスタのスケールアウトが水平方向に限定されると見込まれるエンタープライズ・デプロイメント環境にお薦めします。
${id}マクロを使用してserver-templateのリスニング・アドレスを構成するには:
エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。また、AdminServerのアップロード・ディレクトリを、相対パスではなく、同じ絶対パスを持つように更新します。そうしないと、デプロイメントの問題が発生する可能性があります。動的クラスタを実装する場合、新しく追加した各クラスタに割り当てられたサーバー・テンプレートの構成を検証および更新する必要があります。そうでない場合、新しく追加したクラスタの静的に定義された各管理対象サーバーを検証および構成します。
ノート:
このタスクはアクセス・インフラストラクチャでは不要です。このステップは、リモート・デプロイメントの実行時の潜在的な問題の回避と、ステージ・モードが必要なデプロイメントのために必要です。
デプロイメント・ステージおよびアップロードの場所のディレクトリ・パスを更新するには、次のステップを実行します。
-
Oracle WebLogic Server管理コンソールにログインします。
-
左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。
-
「ロックして編集」をクリックします。
-
使用するクラスタ・タイプに適したオブジェクトに移動して編集します。
-
静的クラスタの場合は「サーバー」にナビゲートし、編集する管理対象サーバーの名前をクリックします。
-
動的クラスタの場合、「クラスタ」→「サーバー・テンプレート」に移動し、編集するサーバー・テンプレートの名前をクリックします。
-
-
編集する新しい管理対象サーバーまたはサーバー・テンプレートごとに、次の手順を実行します。
-
「構成」タブをクリックし、「デプロイメント」タブをクリックします。
-
「ステージング・ディレクトリ名」が次のように設定されていることを確認します。
MSERVER_HOME/servers/server_or_template_name/stage
MSERVER_HOME
をMSERVER_HOME
ディレクトリのフルパスに置き換えます。静的クラスタを使用する場合、編集対象の管理対象サーバーの正しい名前を使用して更新します。
動的クラスタを使用する場合、テンプレート名はそのままにしておきます。たとえば:
/u02/oracle/config/domains/
iamedg_domain
/servers/XYZ-server-template/stage -
「アップロード・ディレクトリ名」を次の値に更新します。
ASERVER_HOME/servers/AdminServer/upload
ASERVER_HOME
をASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。 -
「保存」をクリックします。
-
「サーバーのサマリー」または「サーバー・テンプレートのサマリー」画面(該当する方)に戻ります。
-
-
新しい管理対象サーバーまたは動的クラスタ・サーバー・テンプレートごとに前のステップを繰り返します。
-
AdminServerの「アップロード・ディレクトリ名」に移動して、その値を更新します。
-
「サーバー」に移動してAdminServerを選択します。
-
「構成」タブをクリックし、「デプロイメント」タブをクリックします。
-
「ステージング・ディレクトリ名」が次のような絶対パスに設定されていることを確認します。
ASERVER_HOME/servers/AdminServer/stage
-
「アップロード・ディレクトリ名」を次の絶対パスに更新します。
ASERVER_HOME/servers/AdminServer/upload
ASERVER_HOME
をASERVER_HOME
ディレクトリのディレクトリ・パスに置き換えます。 -
「保存」をクリックします。
-
-
該当するすべてのオブジェクトを変更したら、「変更のアクティブ化」をクリックします。
-
変更内容を有効にするためにすべての管理対象サーバーを再起動します。
ノート:
これ以上のドメイン構成を直接続行する場合、この時点ではstageおよびuploadディレクトリの変更を有効にするための再起動は厳密には必要ありません。WebLogicクラスタのフロントエンド・ホストおよびポートの設定
Oracle Identity and Access ManagementサーバーをホストするOracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。これらの値は、ドメインのプロパティを指定する際に構成ウィザードで指定できます。
ただし、Oracle Identity and Access Managementエンタープライズ・デプロイメントの一部にSOAクラスタを追加する場合、このタスクはSOA管理対象サーバーの検証後に実行することをお薦めします。
Weblogic Server管理コンソールでフロントエンド・ホストおよびポートを設定するには:
中間層とハードウェア・ロード・バランサ間のSSL通信の有効化
中間層とハードウェア・ロード・バランサ間のSSL通信を有効化する方法を理解することは重要です。
ノート:
次のステップは、ハードウェア・ロード・バランサにSSLが構成されており、その結果システムのフロント・エンド・アドレスが保護されている場合に使用できます。
中間層とロード・バランサ間のSSL通信が必要になるとき
エンタープライズ・デプロイメントには、中間層で実行されているソフトウェアが、ハードウェア・ロード・バランサのフロントエンドSSLアドレスにアクセスしなければならないシナリオがあります。このシナリオでは、ロード・バランサと起動サーバー間で、適切なSSLハンドシェイクが行われる必要があります。中間層の管理サーバーと管理対象サーバーが適切なSSL構成を使用して起動されていない場合は、このハンドシェイクを実行できません。
utils.CertGenユーティリティを使用した自己署名証明書の作成
この項では、OIMHOST1に自己署名証明書を作成する手順を説明します。各ホストのネットワーク名または別名を使用してすべてのアプリケーション層ホストの証明書を作成します。
キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。KEYSTORE_HOMEロケーションに置かれるファイル・システムの仕様は、「エンタープライズ・デプロイメントの推奨ディレクトリ構造について」を参照してください。
かわりに信頼できるCA証明書を使用する方法は、『Oracle WebLogic Serverセキュリティの管理』のアイデンティティとトラストの構成に関する情報を参照してください。
パスワードについて
このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。
自己署名証明書を作成するには:
utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成
この項では、OIMHOST1.example.com
でアイデンティティ・キーストアを作成する方法について説明します。
前の項では、証明書とキーを作成して、それを共有記憶域に配置しました。この項では、すべてのホストおよびADMINVHNに対して前に作成した証明書と秘密キーが新しいアイデンティティ・ストアにインポートされます。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
ノート:
アイデンティティ・ストアは、utils.ImportPrivateKey
ユーティリティを使用して証明書および対応するキーをインポートすることで作成されます(存在していない場合)。
トラスト・ストアへのロード・バランサ証明書のインポート
SSLハンドシェイクが適切に動作するには、ロード・バランサの証明書をWLSサーバーのトラスト・ストアに追加する必要があります。ロード・バランサの証明書を追加するには:
ノート:
WLSサーバー・トラスト・ストアにロード・バランサ証明書を追加する必要があるのは、自己署名証明書の場合のみです。サードパーティの認証局が発行したロード・バランサ証明書の場合は、ルートの公開証明書と中間証明書をトラスト・ストアにインポートする必要があります。
Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加
setUserOverridesLate.sh
スクリプトがサポートされており、ドメイン内の管理サーバーおよび管理対象サーバーの起動時に呼び出されるsetDomainEnv.sh
スクリプトで設定されたデフォルト構成をオーバーライドする場合に使用する必要があります。setDomainEnv.sh
スクリプトは、圧縮または解凍操作の実行中に再生成されるため、このスクリプトを編集することはお薦めしません。setDomainEnv.sh
に対するカスタマイズ内容は失われるため、継続的なメンテナンスが必要になります。各サーバーが更新済のトラスト・ストアに正しくアクセスできるようにするには、エンタープライズ・デプロイメント内の各ドメイン・ホーム・ディレクトリのsetUserOverridesLate.sh
スクリプトを編集します。このファイルは、packコマンドまたはunpackコマンドの使用時にも適切に維持されます。
エンタープライズ・デプロイメントでの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永続ストアへのパフォーマンスの考慮事項」を参照してください。
親トピック: JDBC永続ストアとファイル永続ストアの比較
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のパーティション化オプションが使用可能な場合は、索引のグローバル・ハッシュ・パーティションをかわりに使用してください。こうすると、索引の競合とグローバル・キャッシュ・バッファの待機が減少し、それによってアプリケーションのレスポンス時間が短縮されます。パーティション化はどのケースでも効果がありますが、逆索引を使用しても大きく改善されないことがあります。
親トピック: JDBC永続ストアとファイル永続ストアの比較
エンタープライズ・デプロイメントの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データ・ソース結合の推奨事項
データ・ソースの結合および接続の使用を減らすには、JMSおよびTLOG永続ストアの両方に単独接続プールを使用します。
作業負荷が高くない場合、およびWLSSchemaDatasource
プール・サイズの増加を考慮する場合は、TLOGおよびJMS永続ストアに対してWLSSchemaDatasource
をそのまま再利用することをお薦めします。データ・ソースを再利用すると、同じスキーマと表領域が必然的に使用され、PREFIX_WLS
表領域のPREFIX_WLS_RUNTIME
スキーマがTLOGおよびJMSメッセージの両方に対して使用されます。
-
プールでJMSメッセージを保持するための接続が使用できない場合、データ・ソースで強度の競合が発生すると永続ストアでエラーが発生する可能性があります。
-
プールでトランザクション・ログ更新のための接続が使用できない場合、データ・ソースで強度の競合が発生すると、トランザクションで問題が発生する可能性があります。
これらのケースでは、TLOGとストアに対して個別のデータ・ソース、および異なるストアに対して個別のデータ・ソースを使用します。PREFIX_WLS_RUNTIME
スキーマの再利用も可能ですが、競合の問題を解決するには、同じスキーマに対して個別のカスタム・データ・ソースを構成します。
TLOG用のJDBC永続ストア構成のロードマップ
ここでは、トランザクション・ログ用にデータベースベースの永続ストアを構成する方法を説明します。
ノート:
ステップ1と2はオプションです。データ・ソース連結および接続の使用を削減するには、PREFIX_WLS
表領域およびWLSSchemaDatasource
を、「TLOGおよびJMSデータ・ソース結合の推奨事項」に従って再利用します。
JMS用のJDBC永続ストア構成のロードマップ
ここでは、JMSのためにデータベースベースの永続ストアを構成する方法を説明します。
ノート:
ステップ1と2はオプションです。データ・ソース連結および接続の使用を削減するには、PREFIX_WLS
表領域およびWLSSchemaDatasource
を、「TLOGおよびJMSデータ・ソース結合の推奨事項」に従って再利用します。
TLOGおよびJMSストアのGridLinkデータ・ソースの作成
JMSおよびTLOGにデータベース・ベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。
エンタープライズ・デプロイメントでは、TLOGおよびJMSストアでGridLinkデータ・ソースを使用する必要があります。GridLinkデータ・ソースを作成するには:
管理対象サーバーへのTLOG JDBCストアの割当て
データ・ソース集計を完了するには、TLOG永続ストアの<PREFIX>_WLS
表領域およびWLSSchemaDatasource
を再利用します。あるいは、データベースでユーザーと表領域を作成し、データ・ソースが作成済であることを必要な各管理対象サーバーにTLOGストアを割り当てる前に確認します。
- Oracle WebLogic Server管理コンソールにログインします。
- 「チェンジ・センター」で、「ロックして編集」をクリックします。
- 管理対象サーバーのTLOGを構成するには、ドメイン構造ツリーで:
- 静的クラスタの場合: 「環境」、「サーバー」の順に開き、管理対象サーバーの名前をクリックします。
- 動的クラスタの場合: 「環境」、「クラスタ」、「サーバー・テンプレート」の順に開きます。サーバー・テンプレートの名前をクリックします。
- 「構成」>「サービス」タブを選択します。
- 「トランザクション・ログ・ストア」で、「タイプ」 メニューから「JDBC」を選択します。
- 「データ・ソース」メニューからWLSSchemaDatasourceを選択し、データ・ソースの集計を実行します。TLOGには、
<PREFIX>_WLS
表領域が使用されます。 - 「接頭辞名」フィールドで、構成された各JDBC TLOGストアに一意のJDBC TLOGストア名を生成するための接頭辞名を指定します。
- 「保存」をクリックします。
- 追加の管理対象サーバーまたはサーバー・テンプレートごとに、ステップ3から7を繰り返します。
- 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
JMSサーバーへのJMS JDBCストアの割当て
データベースでJMSの表領域とユーザーを作成し、JMSデータ・ソースを作成し、JDBCストアを作成した後で、JMS永続ストアを必須のJMSサーバーそれぞれに割り当てることができます。
- Oracle WebLogic Server管理コンソールにログインします。
- 「チェンジ・センター」で、「ロックして編集」をクリックします。
- 「ドメイン構造」ツリーで、「サービス」、「メッセージング」、「JMSサーバー」の順に開きます。
- 永続ストアを使用するJMSサーバーの名前をクリックします。
- 「永続ストア」メニューで、前に作成したJMS永続ストアを選択します。
- 「保存」をクリックします。
- クラスタ内の追加のJMSサーバーごとに、ステップ3から6を繰り返します。
- 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
エンタープライズ・デプロイメントでのTLOGおよびJMSに対するファイル永続ストアの使用
共有フォルダでのTLOGファイル永続ストアの構成
Oracle WebLogic Serverでは、トランザクション・ログを使用してシステムのクラッシュやネットワーク障害からリカバリします。
静的クラスタを使用する共有フォルダのTLOGファイル永続ストアの構成
静的クラスタ内の各管理対象サーバーにデフォルト永続ストアの場所を設定するには、次のステップを実行します。
-
Oracle WebLogic Server管理コンソールにログインします。
ADMINVHN:7001/console
ノート:
Web層がすでに構成されている場合は、
http://admin.example.com/console
を使用します。 -
「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
-
クラスタ内の管理対象サーバーごとに、次を実行します。
-
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。
-
表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
-
「構成」タブで、「サービス」タブをクリックします。
-
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
エンタープライズ・デプロイメントでは、ORACLE_RUNTIMEディレクトリの場所を使用します。このサブディレクトリは、クラスタのトランザクション・ログにとって中心的な共有場所の役割を果たします。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。
たとえば:
ORACLE_RUNTIME/domain_name/cluster_name/tlogs
この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。cluster_nameを、先ほど作成したクラスタ名で置き換えます。
-
「保存」をクリックします。
-
-
SOA_Cluster内のすべてのサーバーについて、ステップ3を実行します。
-
「変更のアクティブ化」をクリックします。
ノート:
構成手順の後半で、トランザクション・ログの場所と作成について検証します。
親トピック: 共有フォルダでのTLOGファイル永続ストアの構成
動的クラスタを使用した共有フォルダでのTLOGファイル永続ストアの構成
動的クラスタの場合、デフォルトの永続ストアの場所を設定するには、サーバー・テンプレートを更新します。
-
Oracle WebLogic Server管理コンソールにログインします。
ADMINVHN:7001/console
ノート:
Web層がすでに構成されている場合は、
http://admin.example.com/console
を使用します。 -
「チェンジ・センター」セクションで、「ロックして編集」をクリックします。
-
クラスタのサーバー・テンプレートに移動します。
-
「ドメイン構造」ウィンドウで、「環境」および「クラスタ」ノードを開いて「サーバー・テンプレート」ノードをクリックします。
「サーバー・テンプレートのサマリー」ページが表示されます。
-
表の「名前」列で、サーバー・テンプレートの名前(ハイパーリンクとして表示)をクリックします。
選択したサーバー・テンプレートの設定ページが開き、「構成」タブがデフォルトで表示されます。
-
「構成」タブで、「サービス」タブをクリックします。
-
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
エンタープライズ・デプロイメントでは、ORACLE_RUNTIMEディレクトリの場所を使用します。このサブディレクトリは、クラスタのトランザクション・ログにとって中心的な共有場所の役割を果たします。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。
たとえば:
ORACLE_RUNTIME/domain_name/cluster_name/tlogs
この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。cluster_nameを、先ほど作成したクラスタ名で置き換えます。
-
「保存」をクリックします。
-
-
「変更のアクティブ化」をクリックします。
ノート:
構成手順の後半で、トランザクション・ログの場所と作成について検証します。
親トピック: 共有フォルダでのTLOGファイル永続ストアの構成
トランザクション・ログの場所と作成の検証
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
親トピック: 共有フォルダでのTLOGファイル永続ストアの構成
WebサービスのJDBC永続ストアについて
デフォルトでは、Webサービスの永続性にはWebLogic Serverデフォルト永続ストアが使用されます。このストアはWebサービスに対して高パフォーマンスの記憶域ソリューションを提供します。
-
信頼性のあるメッセージング
-
接続
-
セキュア通信
-
メッセージ・バッファリング
デフォルト・ストアではなく、JDBC永続ストアをWebLogic ServerのWebサービスで使用することもできます。Webサービスの永続性の詳細は、Webサービスの永続性の管理を参照してください。
エンタープライズ・デプロイメントのバックアップとリカバリの実行
Oracle Identity and Access Managementエンタープライズ・デプロイメントに必要なディレクトリと構成データを確実にバックアップするために、次に示すガイドラインに従うことをお薦めします。
ノート:
この項で示す静的なランタイム・アーティファクトの一部は、Network Attached Storage (NAS)からホストされています。可能であれば、これらのボリュームをアプリケーション・サーバーからではなくNASファイラから直接バックアップおよびリカバリします。
Oracle Fusion Middleware製品のバックアップとリカバリの一般情報は、『Oracle Fusion Middlewareの管理』の次の項を参照してください。
表19-2は、一般的なOracle Identity and Access Managementエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。
表19-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および共有記憶域 |
該当なし |
表19-3は、一般的なOracle Identity and Access Managementエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。
表19-3 Oracle Identity and Access Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト
タイプ | ホスト | 層 |
---|---|---|
管理サーバーのドメイン・ホーム(ASERVER_HOME) |
OIMHOST1 (またはNASファイラ) |
アプリケーション層 |
アプリケーション・ホーム(APPLICATION_HOME) |
OIMHOST1 (またはNASファイラ) |
アプリケーション層 |
Oracle RACデータベース |
DBHOST1およびDBHOST2 |
データ層 |
スクリプトとカスタマイズ |
ホスト当たり |
アプリケーション層 |
デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME) |
OIMHOST1 (またはNASファイラ) |
アプリケーション層 |
OHS構成ディレクトリ |
WEBHOST1およびWEBHOST2 |
Web層 |
Oracle Identity and Access Managementエンタープライズ・デプロイメントの構成および管理タスク
Oracle Identity and Access Managementエンタープライズ・デプロイメントで実行する必要性が高い、いくつかの主要な構成および管理タスクについて説明します。
デプロイメント・プランおよびSOAインフラストラクチャ・アプリケーション更新での共有記憶域の使用
SOAクラスタ内のSOAインフラストラクチャ・アプリケーションまたはリソース・アダプタを再デプロイするときは、デプロイメント・プランとアプリケーション・ビットに、クラスタ内の全サーバーからアクセスできる必要があります。
SOAのアプリケーションおよびリソース・アダプタは、nostageデプロイメント・モードを使用してインストールされます。nostageデプロイメント・モードを選択した場合、管理サーバーはアーカイブ・ファイルをソースの場所からコピーしないため、各サーバーが同じデプロイメント・プランにアクセスできるようにしておく必要があります。
デプロイメント・プランの場所がドメイン内のすべてのサーバーで利用できるようにするには、「このガイドで使用するファイル・システムとディレクトリ変数」で示され、エンタープライズ・デプロイメント・ワークブック内のDEPLOY_PLAN_HOME変数で表される、デプロイメント・プランのホームの場所を使用します。
SOAサーバーでのJMSメッセージの管理
SOAサーバーでJMSメッセージを管理する手順は、いくつかあります。スケール・イン操作の間にメッセージを保持する場合など、一部シナリオでは、これらの手順に従う必要があることがあります。
この項では、これらの手順のいくつかを詳しく説明します。
SOAサーバーからのJMSメッセージの排出
JMSメッセージの排出のプロセスは、特定のWebLogicサーバーからメッセージをクリアするために役立ちます。ストアを排出するための基本的な手法は、適切なJMSサーバーでのメッセージ生成の停止、およびアプリケーションへのメッセージ使用の許可で構成されています。
ただし、この手順は、アプリケーションによって異なり、かかる時間を予測できない可能性があります。別の方法として、ここでは、現在のJMS宛先からの現在のメッセージを保存して、必要な場合にそれらを別のサーバーにインポートするための、一般的な手順を示します。
排出手順は、1つ以上のサーバーを削除することでクラスタのサイズが縮小されるため、スケール・インやスケール・ダウンのシナリオで役立ちます。削除するサーバーからメッセージを排出し、それらをクラスタ内の別のサーバーにインポートすることで、メッセージが失われないようにすることができます。
一部の障害回復保守シナリオで、スナップショット・スタンバイ・データベースを使用することでセカンダリの場所でサーバーを起動するときに、この手順を使用することもできます。この場合は、ドメインの起動時にスタンバイ・ドメインで使用されないようにするために、セカンダリの場所でドメインを起動する前に、ドメインからメッセージを排出する必要があることがあります(そうしないと、実行が重複する可能性があります)。このシナリオでは、メッセージをインポートできません。
親トピック: SOAサーバーでのJMSメッセージの管理
クロス・コンポーネント・ワイヤリングについての考慮事項
クロス・コンポーネント・ワイヤリング(CCW)を利用すると、FMWコンポーネントは、特定のAPIを使用することによってWLSドメインで使用可能なサービスの一部をパブリッシュし、それにバインドすることができます。
CCWがワイヤリング情報のバインドを実行するのは、構成ウィザードのセッション中のみ、またはWLSドメイン管理者によって手動で強制実行されたときだけです。クラスタにWeblogic Serverを追加するとき(静的または動的クラスタでのスケール・アウトおよびスケール・アップ操作で)、新しいサーバーはサービスを公開しますが、そのサービスを使用するクライアントのすべてが自動的に更新されて、新しいサービス・プロバイダにバインドされるわけではありません。CCW表にすでにバインドされている既存のサーバーは、クラスタに新しいメンバーが追加されたことを自動的に認識しないため、更新は実行されません。これは、ESSおよびWSMPMがSOAにサービスを提供する場合と同じです(両者はサービスをサービス表に動的に公開しますが、SOAサーバーはバインドが再び強制されないかぎり、これらの更新を認識しません)。
ノート:
-
『Oracle Fusion Middlewareの管理』の連携するコンポーネントのワイヤリング。
-
『Oracle HTTP Serverの管理』の、Oracle HTTP用にオラクルが開発したモジュールに関する項
- WSMPMおよびESS用のクロス・コンポーネント・ワイヤリング
クロス・コンポーネント・ワイヤリングのt3情報は、JNDI呼出しURLで使用されるサーバーのリストを取得する際に、WSMPMとESSによって使用されます。 - WSMPMでのcluster_name構文の使用
この手順では、WSMPMでt3構文を使用することにより、WSMPMクラスタでサーバーを追加または削除する場合にCCW情報を再更新することを不要にします。
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情報は、デフォルトでクラスタ構文を使用するように構成されています。クラスタ構文が使用されていることを確認し、必要があれば編集するだけです。
- 管理者のアカウントを使用してFusion Middleware Controlにサインインします。たとえば、
weblogic_iam
です。 - 「WebLogicドメイン」ドロップダウン・メニューから、「クロス・コンポーネント・ワイヤリング」-「サービス表」を選択します。
- 「OWSMポリシー・マネージャ」のurn:oracle:fmw.owsm-pm:t3行を選択します。
- クラスタ構文が使用されていることを確認します。そうでない場合、「編集」をクリックして、クラスタ名構文を使用してt3およびt3sの値を更新します。
- 「OK」をクリックします。
- 「WebLogicドメイン」ドロップダウン・メニューから、「クロス・コンポーネント・ワイヤリング」-「コンポーネント」を選択します。
- 「OWSMエージェント」を選択します。
- 「クライアント構成」セクションで、owsm-pm-connection-t3行を選択して「バインド」をクリックします。
- 「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動的クラスタの拡張度の構成」を参照してください。