この章の内容は次のとおりです。
動的クラスタは、アプリケーションのリソース・ニーズを満たすように動的にスケール・アップできるサーバー・インスタンスで構成されます。動的クラスタは、指定した数の生成された(動的)サーバー・インスタンスの構成を定義する単一のサーバー・テンプレートを使用します。動的クラスタを作成すると、動的サーバーが事前構成され、自動的に生成されます。これにより、追加のサーバー容量が必要な場合に動的クラスタ内のサーバー・インスタンスの数を簡単にスケール・アップできます。動的サーバーは、最初に手動で構成してそれをクラスタに追加する必要はなく、単に起動するだけで使用できます。
最初に指定した数のサーバー・インスタンスに追加が必要となった場合、動的クラスタの構成でサーバー・インスタンス(動的)の最大数を増やすか、構成済サーバー・インスタンスを手動で動的クラスタに追加することが可能です。動的サーバー・インスタンスと構成済サーバー・インスタンスの両方が含まれた動的クラスタを複合クラスタと呼びます。
次の表に、動的クラスタに関連する用語の定義を示します。
用語 | 定義 |
---|---|
動的クラスタ |
1つの共有サーバー・テンプレートに基づいた生成済(動的)サーバー・インスタンスを1つ以上備えたクラスタ。 |
構成済クラスタ |
手動で構成し、各サーバー・インスタンスを追加するクラスタ。 |
動的サーバー |
動的クラスタの作成時にWebLogic Serverで生成されるサーバー・インスタンス。構成は、共有サーバー・テンプレートに基づきます。 |
構成済サーバー |
属性を手動で構成するサーバー・インスタンス。 |
複合クラスタ |
動的サーバー・インスタンスと構成済サーバー・インスタンスの両方を備えたクラスタ。 |
サーバー・テンプレート |
一連のサーバー・インスタンスに割り当てることができ、テンプレートの構成を継承する、デフォルト以外の共通の設定と属性が含まれたプロトタイプ・サーバーの定義。動的クラスタでは、サーバー・テンプレートを使用して動的サーバーを生成します。Oracle WebLogic Serverドメイン構成の理解のサーバー・テンプレートを参照してください。 |
動的サーバーは個別に構成できません。動的クラスタを使用する際には、config.xml
ファイルにサーバー・インスタンスの定義が存在しません。したがって、サーバー・テンプレートをサーバー固有の属性でオーバーライドしたり、アプリケーションを個別の動的サーバー・インスタンスにターゲット指定したりできません。例11-1は、動的クラスタを含むconfig.xml
ファイルの例を示しています。
例11-1 動的クラスタを使用するconfig.xmlファイルの例
<server-template> <name>dynamic-cluster-server-template</name> <accept-backlog>2000</accept-backlog> <auto-restart>true</auto-restart> <restart-max>10</restart-max> <startup-timeout>600</startup-timeout> </server-template> <cluster> <name>dynamic-cluster</name> <dynamic-servers> <server-template>dynamic-cluster-server-template</server-template> <maximum-dynamic-server-count>10</maximum-dynamic-server-count> <calculated-machine-names>true</calculated-machine-names> <machine-name-match-expression>dyn-machine*</machine-name-match-expression> <server-name-prefix>dynamic-server-</server-name-prefix> </dynamic-servers> </cluster>
動的クラスタを使用すると、サーバーの容量を追加する必要があるときに、1つまたは複数の構成済動的サーバー・インスタンスを起動するだけで、簡単にクラスタをスケール・アップできます。新しいサーバー・インスタンスを手動で構成してそれをクラスタに追加したり、システムの再起動を実行する必要はありません。
次の各項では、動的クラスタの使用方法について説明します。
動的クラスタを作成する場合には、次の処理を実行します。
ピーク負荷時に必要となると考えられるサーバー・インスタンスの数の指定
サーバーの構成の基準とするサーバー・テンプレートの作成または選択
WebLogic Serverでサーバー固有の属性を計算する方法の定義
WebLogic Serverでは、指定された数の動的サーバー・インスタンスを生成し、各動的サーバー・インスタンスに計算した属性値を適用します。
注意:
動的クラスタの構成に指定したサーバー・インスタンスの最大数を処理できる性能があることを確認します。クラスタを作成する際の設計およびデプロイメントに関するベスト・プラクティスは、クラスタリングのベスト・プラクティスを参照してください。
WebLogic Scripting Tool (WLST)、WebLogic Server管理コンソールまたはEnterprise Manager (EM)のFusion Middleware Control (FMWC)コンポーネントを使用して、動的クラスタを作成します。
例11-2はWLSTを使用した場合の例を示しています。WebLogic Server管理コンソールの使用の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの動的クラスタの作成を参照してください。FMWCの使用の詳細は、Oracle Fusion Middleware Fusion Middleware ControlによるOracle WebLogic Serverの管理の新しい動的クラスタの作成を参照してください。いずれかのコンソールで動的クラスタを作成する際、WebLogic Serverにより、サーバー・テンプレート、動的クラスタ、および指定された数のサーバー・インスタンスが作成されます。それらを別々に指定する必要はありません。動的クラスタを構成するには、Oracle WebLogic Serverの理解のシステム管理ツールおよびAPIの概要にリストされた、いずれかの管理ツールを使用します。
サーバー・テンプレートは、一連のサーバー・インスタンスが共有する構成属性を定義します。動的クラスタでは、動的サーバーの構成にサーバー・テンプレートが使用されます。
サーバー・テンプレートの詳細は、Oracle WebLogic Serverドメイン構成の理解のサーバー・テンプレートを参照してください。
動的クラスタを使用する際には、動的サーバー・インスタンスを個別に構成したり、動的サーバー・レベルでサーバー・テンプレートの値をオーバーライドしたりできません。サーバー名、マシン、リスニング・ポートなどのサーバー固有の属性は、動的クラスタを作成する際に提供された情報を使用して計算する必要があります。
注意:
JTAトランザクション回復サービスをホストすることになる管理対象サーバーのインスタンスには、一意のリスニング・アドレス値を設定する必要があります。そうしないと、移行は失敗します。
WebLogic Serverは、動的サーバーのインスタンスIDを使用して、次のサーバー固有の属性を計算して適用します。
サーバー名
(オプション)リスニング・ポート(クリア・テキストおよびSSL)
(オプション)ネットワーク・アクセス・ポイントのリスニング・ポート
(オプション)マシンまたは仮想マシン
計算済のサーバー名は、ServerNamePrefix
属性によって制御されます。サーバー名には、指定された接頭辞が付き、その後に索引番号が続きます。たとえば、接頭辞がdyn-server-
に設定されている場合、動的サーバーの名前は、(指定したサーバー・インスタンスの数に応じて)dyn-server-1
、dyn-server-2
などのようになります。
動的クラスタの構成やサーバー・テンプレートにおける設定に応じて、動的クラスタ内のサーバー・インスタンスのリスニング・ポートが決まります。動的クラスタを作成する際にリスニング・ポートを計算しない場合には、WebLogic Serverではサーバー・テンプレート内の値が使用されます。動的クラスタ構成やサーバー・テンプレート内でリスニング・ポートを定義しない場合、WebLogic Serverではデフォルト値が使用されます。リスニング・ポート設定は、CalculatedListenPorts
属性によって制御されます。これらの設定の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの動的クラスタの作成を参照してください。
サーバー・テンプレートまたは動的クラスタ構成で動的クラスタの基本リスニング・ポートを明示的に定義すると、最初の動的サーバー・インスタンスのリスニング・ポート値は基本のリスニング・ポートになり、値が1ずつ増えていきます。動的サーバー・インスタンスを追加するたびに、リスニング・ポート値は1ずつ増えていきます。デフォルトの基本リスニング・ポートを使用する場合、WebLogic Serverは、動的サーバー・インスタンスごとに、百の位を1つ増やし、そこから続けます。表11-1に、計算されたリスニング・ポート値を示します。
表11-1 リスニング・ポートの計算
リスニング・ポートのタイプ | サーバー・テンプレート内の構成設定 | 動的サーバーのリスニング・ポート値 |
---|---|---|
サーバーのリスニング・ポート |
基本リスニング・ポートは設定されません |
dyn-server-1: 7101 dyn-server-2: 7102 ... |
サーバーのリスニング・ポート |
基本リスニング・ポートは7300に設定されます |
dyn-server-1: 7301 dyn-server-2: 7302 ... |
サーバーのSSLリスニング・ポート |
SSL基本リスニング・ポートは設定されません |
dyn-server-1: 8101 dyn-server-2: 8102 ... |
サーバーのSSLリスニング・ポート |
SSL基本リスニング・ポートは8200に設定されます |
dyn-server-1: 8201 dyn-server-2: 8202 ... |
サーバーのネットワーク・アクセス・ポイントのリスニング・ポート |
ネットワーク・アクセス・ポイントのリスニング・ポートは設定されません |
dyn-server-1: 9101 dyn-server-2: 9102 ... |
サーバーのネットワーク・アクセス・ポイントのリスニング・ポート |
ネットワーク・アクセス・ポイントのリスニング・ポートは9200に設定されます |
dyn-server-1: 9201 dyn-server-2: 9202 ... |
サーバーのレプリケーション・ポート |
レプリケーション・ポートは8100に設定されます |
dyn-server-1: 8100 dyn-server-2: 8101 ... |
サーバーのレプリケーション・ポート |
レプリケーション・ポートは8100-8104に設定されます |
dyn-server-1: 8100-8104 dyn-server-2: 8105-8109 dyn-server-3: 8110-8114 ... |
システム・プロパティを使用して、サーバーの起動時にリスニング・ポートをオーバーライドできます。次に例を示します。
リスニング・ポートをオーバーライドする手順は次のとおりです。
-Dweblogic.ListenPort=7305
SSLリスニング・ポートをオーバーライドする手順は次のとおりです。
-Dweblogic.ssl.ListenPort=7403
mynap
という名前のネットワーク・アクセス・ポイントのリスニング・ポートをオーバーライドする手順は次のとおりです。
-Dweblogic.networkaccesspoint.mynap.ListenPort=8201
動的クラスタのCalculatedMachineNames
属性およびMachineNameMatchExpression
属性は、動的クラスタ内のサーバー・インスタンスがマシンにどのように割り当てられるかを制御します。CalculatedMachineNames
属性がfalse
に設定されている場合、動的クラスタはマシンに割り当てられません。CalculatedMachineNames
属性がtrue
に設定されている場合、MachineNameMatchExpression
属性が使用されて、動的サーバーで使用されているマシンのセットが選択されます。MachineNameMatchExpression
属性が設定されていない場合、ドメイン内のすべてのマシンが選択されます。割当は、ラウンド・ロビン・アルゴリズムを使用して行われます。表11-2は、動的クラスタにおけるマシン割当の例を示しています。
表11-2 マシン名の計算
ドメイン内のマシン | MachineNameMatchExpression構成 | 動的サーバーのマシン割当 |
---|---|---|
M1、M2 |
設定されません |
dyn-server-1: M1 dyn-server-2: M2 dyn-server-3: M1 ... |
Ma1、Ma2、Mb1、Mb2 |
Ma1、Mb* |
dyn-server-1: Ma1 dyn-server-2: Mb1 dyn-server-3: Mb2 dyn-server-4: Ma1 ... |
動的クラスタ内のサーバーの起動と停止を簡単に管理するには、WLSTのscaleUp
コマンドとscaleDown
コマンドを使用します。
scaleUp
コマンドにより、指定した動的クラスタの実行サーバーの数が増加します。サーバーIDが最も小さい非実行サーバー・インスタンスが最初に起動し、指定した数のサーバー・インスタンスが起動するまで、次に大きなIDの非実行サーバー・インスタンスの起動が続きます。
動的クラスタ内で1つ、すべて、または任意の数のサーバー・インスタンスを起動するには、scaleUp
コマンドでnumServers
引数を使用して目的の数を指定します。利用可能なすべてのサーバー・インスタンスがすでに実行している場合、指定した数のサーバーを起動する前に、scaleUp
コマンドにより、リクエストしたサーバー・インスタンスの最小数までクラスタのサイズを増やします。クラスタ・サイズの拡張の詳細は、「動的クラスタの拡張と縮小」を参照してください。
scaleDown
コマンドでは、指定した数の実行サーバーを適切に停止します。サーバーIDが最も大きいサーバー・インスタンスが最初に停止し、指定した数のサーバー・インスタンスが停止するまで、次に大きなIDのサーバー・インスタンスの停止が続きます。詳細は、WebLogic Server WLSTコマンド・リファレンスのscaleUpおよびscaleDownを参照してください。
構成済クラスタ内のサーバー・インスタンスの起動および停止に使用する方法と同じ方法で、動的クラスタ内のサーバー・インスタンスを起動および停止することもできます。つまり、WebLogic Server管理コンソール、Fusion Middleware Control、WLSTのstart
コマンドとshutdown
コマンド、ノード・マネージャおよび起動スクリプトを使用します。選択する起動方法や実行済のタスクに応じて、サーバー・インスタンスを起動する前に他の手順の実行が必要になる場合があります。詳細は、Oracle WebLogic Serverサーバーの起動と停止の管理のサーバーの起動と停止を参照してください。
注意:
始める前に、WebLogic Serverが、サーバー・インスタンスを実行するすべてのホストにインストールされていることを確認します。ノード・マネージャを使用してサーバー・インスタンスを起動および停止する場合は、それらのホスト上でノード・マネージャも実行する必要があります。
動的クラスタを作成すると、WebLogic Serverでは指定した数の動的サーバーが生成されます。サーバー・インスタンスの数を決定する前に、希望の数を処理するための性能があることを確認してください。
動的サーバー・インスタンスは、サーバー・テンプレートで指定した構成と計算された属性に基づいています。
クラスタを拡張するには、任意の数の構成済動的サーバーを指定します。
動的クラスタを縮小するには、余分な数の動的サーバーを停止します。
最初に指定した数のサーバー・インスタンスに追加が必要となった場合、動的クラスタの構成で動的サーバーの最大数を増やします。動的クラスタ内のサーバー・インスタンスの数を減らすには、動的サーバーの属性の最大数の値を減らします。この値を小さくする前に、削除する予定のサーバー・インスタンスを停止します。
WLSTのscaleUp
コマンドとscaleDown
コマンドを使用して、動的クラスタを管理することもできます。動的クラスタ内の動的サーバーの数を増やすには、scaleUpコマンドを使用して、updateConfiguration
引数を有効にします。WLSTでは、指定した数のサーバーの分だけクラスタの最大サイズを増やし、サーバー・インスタンスを起動します。
動的クラスタの最大サイズを減らすには、scaleDownコマンドを使用して、updateConfiguration
引数を有効にします。WLSTでは、指定した数の実行サーバー・インスタンスを適切に停止して、それらを動的クラスタから削除します。詳細は、『WebLogic Server WLSTコマンド・リファレンス』のscaleUpおよびscaleDownを参照してください。
注意:
動的サーバー・インスタンスでは、WLSTのscaleUp
コマンドとscaleDown
コマンドのみ使用できます。手動で構成したサーバー・インスタンスと動的サーバー・インスタンスの両方が含まれる混在クラスタの場合、scaleUp
コマンドとscaleDown
コマンドでは、構成済サーバーが無視されます。混在クラスタ内の構成済サーバー・インスタンスを手動で起動して停止する必要があります。
たとえば、クラスタ内に、実行中の動的サーバー2台と実行していない構成済サーバー2台があるとします。scaleUp
コマンドを使用する場合、WLSTでは、クラスタに動的サーバー・インスタンスを1つ追加して、動的サーバーを起動します。
WLSTのscaleUp
コマンドとscaleDown
コマンドには、動的クラスタを手動でスケーリングする方法が用意されています。自動スケーリングの場合、動的クラスタの拡張度を構成できます。拡張度を使用する場合、動的クラスタでは、要求に反応して、あるいはカレンダ・ベースのスケジュールのとおりにスケーリング操作や再プロビジョニング操作を自動で実行できます。WebLogic Serverでは、WebLogic診断フレームワーク(WLDF)のポリシーおよびアクション・システムによって動的クラスタに拡張度が提供されます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server動的クラスタの拡張度の構成』を参照してください。
WebLogic Serverでは、動的クラスタおよび複合クラスタでのサーバー全体の移行がサポートされています。クラスタの種類に応じて構成は異なりますが、サーバー全体の移行の動作はすべてのクラスタで同じです。動的クラスタのサーバー全体の移行を有効化する方法の詳細は、「動的クラスタおよび複合クラスタでのサーバー全体の移行」を参照してください。
アプリケーションを動的クラスタにデプロイする際には、そのアプリケーションをクラスタ全体にターゲット指定する必要があります。動的クラスタには個別の動的サーバー構成がないため、アプリケーションを個別のサーバー・インスタンスにターゲット指定できません。アプリケーションを動的クラスタにデプロイする際には、動的クラスタと静的クラスタの両方のクラスタ内のすべてのサーバーがそのアプリケーションをデプロイします。
アプリケーションを動的クラスタにデプロイするには、構成済クラスタへのデプロイと同じ手順を実行します。詳細は、アプリケーションをデプロイするおよびクラスタ化構成でのアプリケーションのデプロイメントを参照してください。
デプロイメントに関する全般的なトピックは、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
動的クラスタでは構成済クラスタと同じWebLogic Webサーバー・プラグインが提供されます。デフォルトで、Webサーバー・プラグインはDynamicServerList
パラメータを使用して、構成済クラスタまたは動的クラスタ内の新しいサーバー・インスタンスなどの、クラスタ変更の情報を受信します。クラスタ・メンバーシップの変更の再構成時に、プラグインは自動的にそのサーバー・リストを更新します。
WebLogic ServerでのWebサーバー・プラグインの使用の詳細は、『Oracle WebLogic Serverプロキシ・プラグインの使用』 12.2.1.2を参照してください。DynamicServerList
パラメータまたはWebLogicCluster
パラメータ(WebLogic Serverクラスタへのプロキシ中に必要)の詳細は、Oracle WebLogic Serverプロキシ・プラグイン12.2.1.2の使用のWebサーバー・プラグインの一般的なパラメータを参照してください
WebLogic Serverで動的クラスタを使用する際には、次の制限と考慮事項に注意してください。
動的クラスタを使用する場合、config.xml
ファイル内に個別サーバーの定義が存在しないため、個別の動的サーバー・レベルではサーバー・テンプレートの値をオーバーライドできません。
LLR_DYN_SRV_${id}
に設定します。${id}
は、動的サーバーごとの実行時のサーバー番号に置き換えられます。
動的クラスタの構成に指定したサーバー・インスタンスの最大数を処理できる性能があることを確認する必要があります。
動的クラスタでは、個別の動的サーバー・インスタンスに対するターゲット指定はサポートされていません。したがって、次の項目は動的クラスタでは使用できません。
移行可能ターゲットを含む、クラスタへのターゲット指定ができないデプロイメント。そのため、動的クラスタ用の移行可能ターゲットは作成できません。
個々のサーバーを参照する構成属性。これには、JTA移行可能ターゲット、制約付き候補サーバー、ユーザーの優先サーバー、すべての候補サーバーおよびホスト・サーバーが含まれます。そのため、移行可能ターゲットのユーザー優先サーバーとして動的サーバーを指定できません。
サーバー固有の構成属性。これには、レプリケーション・グループ、セカンダリ・プリファレンス・グループおよび候補マシン(サーバー・レベル)が含まれます。
シングルトン・サービスに対する控えの候補。動的サーバーへのシングルトン・サービスを制限できません。
動的クラスタでサーバー全体を移行する場合、サーバー・テンプレートで候補マシンをリストしないため、動的クラスタが指定する候補マシンのリストを制限できません。
動的クラスタにもJMS制限があります。詳細は、Oracle WebLogic Server JMSリソースの管理の簡略化JMSクラスタの構成を参照してください。
複数のネットワーク・チャネルが構成される動的サーバーでは、それらのチャネルが様々なインタフェースに対してリスニングすることはできません。
例11-2では、WLSTを使用して動的クラスタを作成する方法を示します。この例には、インライン・コメントと次の作業の実行方法が示されています。
サーバー・テンプレートを作成し、サーバー・テンプレートで必要なサーバー属性を指定します。
動的クラスタを作成し、必要なクラスタ属性を指定します。
動的クラスタのサーバー・テンプレートを設定します。
動的クラスタで希望のサーバー・インスタンスの最大数を設定します。
動的クラスタ内のサーバーを起動および停止します。
例11-2 WLSTでの動的クラスタの作成
# # This example demonstrates the WLST commands needed to create a dynamic cluster # (dynamic-cluster). The dynamic cluster uses a server template # dynamic-cluster-server-template. To keep this example simple, error handling # was omitted. # connect() edit() startEdit() # # Create the server template for the dynamic servers and set the attributes for # the dynamic servers. Setting the cluster is not required. # dynamicServerTemplate=cmo.createServerTemplate("dynamic-cluster-server-template") dynamicServerTemplate.setAcceptBacklog(2000) dynamicServerTemplate.setAutoRestart(true) dynamicServerTemplate.setRestartMax(10) dynamicServerTemplate.setStartupTimeout(600) # # Create the dynamic cluster, set the number of dynamic servers, and designate the server template. # dynCluster=cmo.createCluster("dynamic-cluster") dynServers=dynCluster.getDynamicServers() dynServers.setMaximumDynamicServerCount(10) dynServers.setServerTemplate(dynamicServerTemplate) # # Dynamic server names will be dynamic-server-1, dynamic-server-2, ..., # dynamic-server-10. # dynServers.setServerNamePrefix("dynamic-server-") # # Listen ports and machines assignments will be calculated. Using a round-robin # algorithm, servers will be assigned to machines with names that start with # dyn-machine. # dynServers.setCalculatedMachineNames(true) dynServers.setMachineNameMatchExpression("dyn-machine*") # # activate the changes # activate()
この結果得られるconfig.xml
ファイルは次のようになります。
<server-template> <name>dynamic-cluster-server-template</name> <accept-backlog>2000</accept-backlog> <auto-restart>true</auto-restart> <restart-max>10</restart-max> <startup-timeout>600</startup-timeout> </server-template> <cluster> <name>dynamic-cluster</name> <dynamic-servers> <server-template>dynamic-cluster-server-template</server-template> <maximum-dynamic-server-count>10</maximum-dynamic-server-count> <calculated-machine-names>true</calculated-machine-names> <machine-name-match-expression>dyn-machine*</machine-name-match-expression> <server-name-prefix>dynamic-server-</server-name-prefix> </dynamic-servers> </cluster>