6 ポリシーベースのスケーリング
ポリシーベースのスケーリングとは
WLDFには2つのエラスティック・アクション、スケール・アップおよびスケール・ダウンが用意されており、スケーリング操作を実行するポリシーに割り当てることができます。スケール・アップおよびスケール・ダウン・アクションの詳細は、「エラスティック・アクション」を参照してください。1つのスケーリング・アクションのみ、指定のポリシーに割り当てることができます。
たとえば、例6-1は、起動するとスケール・アップ・アクションを実行するポリシーを作成、構成するWLSTコマンドを示しています。次の点に注意してください。
-
スケール・アップ・アクション
scaleUp
が作成されます。このアクションは、動的クラスタDynamicCluster
を、サーバー・インスタンス1つのみスケール・アップするように構成されます。 -
highMark
という名前のポリシーが、10秒ごとに評価されるように構成されます。 -
ポリシーが起動される、つまり
true
と評価されると、対応するスケール・アップ・アクションが実行されます。
同様に、例6-2は、起動するとスケール・ダウン・アクションを実行するポリシーの構成を示しています。次の点に注意してください。
-
スケール・ダウン・アクション
scaleDown
が作成されます。このアクションは、動的クラスタDynamicCluster
を、サーバー・インスタンス1つのみスケール・ダウンするように構成されます。 -
LowMark
という名前のポリシーが、10秒ごとに評価されるように構成されます。 -
ポリシーが起動される、つまり
true
と評価されると、対応するスケール・ダウン・アクションが実行されます。
例6-1 動的クラスタをスケール・アップするポリシーの作成
scaleUp=wn.lookupScaleUpAction('scaleUp') if scaleUp == None: print "Creating scale up action" scaleUp=wn.createScaleUpAction('scaleUp') scaleUp.setScalingSize(1) scaleUp.setClusterName(DynamicCluster) high=wn.createWatch('highMark') high.setExpressionLanguage('EL') high.getSchedule().setMinute('*') high.getSchedule().setSecond('*/10') high.getRuleType() high.setAlarmType('AutomaticReset') high.setAlarmResetPeriod(150000) high.setRuleExpression("wls:ClusterHighThroughput('"+DynamicCluster+"', '10s', '30s', 250, 60)") high.addNotification(scaleUp) high.setEnabled(true)
例6-2 動的クラスタをスケール・ダウンするポリシーの作成
scaleDown=wn.lookupScaleDownAction('scaleDown') if scaleDown == None: print "Creating scale down action" scaleDown=wn.createScaleDownAction('scaleDown') scaleDown.setScalingSize(1) scaleDown.setClusterName(DynamicCluster) low=wn.createWatch('lowMark') low.setExpressionLanguage('EL') low.getSchedule().setMinute('*') low.getSchedule().setSecond('*/10') low.getRuleType() low.setAlarmType('AutomaticReset') low.setAlarmResetPeriod(60000) low.setRuleExpression("wls:ClusterLowThroughput('"+DynamicCluster+"', '10s', '60s', 50, 75)") low.addNotification(scaleDown) low.setEnabled(true)
ノート:
動的クラスタの自動拡張度を構成するには、スケーリング・ポリシーとそれに対応するエラスティック・アクションを定義したドメイン・スコープの診断システム・モジュールを作成し、その診断モジュールのターゲットを管理サーバーに設定する必要があります。
スマート・ルールの導入
スマート・ルールは、一連の設定可能パラメータを持ち、その設定可能パラメータの値を指定することで複合ポリシー式を作成できるようにする、事前パッケージ済のファンクションです。
スマート・ルールは、単独で、または複合ポリシー式を作成するために他の述語とともに、ポリシー式内で述語として使用できます。スマート・ルールのポリシー式は、Java Expression Language (EL)を使用して指定されます。『Oracle WebLogic Server診断フレームワークの構成と使用』のスマート・ルールベースのポリシーの構成に関する項を参照してください。
ポリシーベースのスケーリングでは、スマート・ルールが使用できます。「ポリシーベースのスケーリング例」では、スマート・ルールのwls:ClusterHighThroughput()
およびwls:ClusterLowThroughput()
をルール式で使用するポリシーの使用方法を説明します。これら2つのスマート・ルールは、例6-1および例6-2でも示しています。
-
例6-1は、
wls:ClusterHighThroughput()
スマート・ルールを示しています。このスマート・ルールは、各管理対象サーバーのThreadPoolRuntimeMBean.Throughput
属性の平均値によって示される、クラスタにおける平均スループットが増大しているかどうかを測定します。例に示されているように、このスマート・ルールは、動的クラスタ
DynamicCluster
内の少なくとも60パーセントのサーバーにおいて、10秒間隔で収集した過去30秒の平均Throughput
値が250以上の場合に起動されます(つまりtrue
と評価されます)。このスマート・ルールが起動されると、スケール・アップ・アクションscaleUp
が実行され、クラスタでサーバー・インスタンスが起動されます。 -
例6-2は、
wls:ClusterLowThroughput()
スマート・ルールを示しています。このスマート・ルールは、各管理対象サーバーのThreadPoolRuntimeMBean.Throughput
属性の平均値によって示される、クラスタにおける平均スループットが減少しているかどうかを測定します。例に示されているように、このスマート・ルールは、動的クラスタ
DynamicCluster
内の少なくとも75パーセントのサーバーにおいて、10秒間隔で収集した過去60秒の平均Throughput
値が50未満の場合に起動されます(つまりtrue
と評価されます)。このスマート・ルールが起動されると、スケール・ダウン・アクションscaleDown
が実行され、クラスタでサーバー・インスタンスが停止されます。
WebLogic Server管理コンソールおよびFusion Middleware Controlを使用したスマート・ルールベースのポリシーの作成および構成の詳細は、次の項を参照してください。
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの診断システム・モジュールに対するスマート・ルール・ベースのポリシーの作成
-
Fusion Middleware ControlによるOracle WebLogic Serverの管理のポリシーおよびアクションの作成と構成
『Oracle WebLogic Server診断フレームワークの構成と使用』のスマート・ルール・リファレンスに関する項を参照してください。
ポリシーベースのスケーリング例
wls:HighThroughput()
およびwls:LowThroughput()
スマート・ルールを使用して高負荷時に動的クラスタをスケール・アップし、要求が減少したら動的クラスタをスケール・ダウンするポリシーを作成できます。
ノート:
この項の例では、WebLogic Serverおよび同じ場所に配置されたOracle Traffic Director 12cをWindows上で使用します。
前提条件
正常にこの例を実行するには、先に環境を準備して、この例で使用する必要なファイルをダウンロードします。
この項では、次のタスクを取り上げます。
必要なソフトウェアのインストール
この例を実行するには、次のソフトウェアをダウンロードしてインストールします。
-
Oracle WebLogic Server—手順および詳細は、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』の「Oracle WebLogic ServerとCoherenceのソフトウェアのインストール」を参照してください。
ノート:
この例のためにWebLogic Serverをインストールして使用するには、有効なJDK 8がある必要があります。『Oracle WebLogic Serverの新機能』のJDK 8認定に関する項を参照してください。
-
Visual Studio用のMicrosoft Visual C++再頒布可能パッケージ - ドメインを解凍し、Oracle Traffic Directorを起動するには、その前にVisual C++がインストールされている必要があります。ダウンロードは、
https://www.microsoft.com/en-us/download/confirmation.aspx?id=40784
にあります。 -
Oracle Traffic Director (OTD) - Oracle Traffic Directorのダウンロードは、
http://www.oracle.com/technetwork/middleware/otd/downloads/index.html
から可能です。この例は、WebLogic Serverを介して管理される、同じ場所に配置されたOracle Traffic Directorを使用します。WebLogic Serverをインストールしたのと同じ
ORACLE_HOME
ディレクトリに、Oracle Traffic Directorをインストールします。インストール時に、「インストール・タイプ」画面で同じ場所に配置されたOTDを選択します。『Oracle Traffic Directorの管理』のOracle Traffic Directorの概要に関する項を参照してください。
-
Apache JMeter - Apache JMeterは、
http://jmeter.apache.org/download_jmeter.cgi
から、説明を表示してダウンロードおよびインストールできます。
必要なファイルのダウンロードと解凍
拡張度デモのJARファイルは、次の場所にあるWebLogic Serverブログの記事動的クラスタの拡張度からダウンロードできます。
https://cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916/File/540d5bc5bdb70b2b779130ee381cf061/otd_wls_elasticity_demo.zip
この例で使用する拡張度JARから、次のファイルを解凍します。
ノート:
同じディレクトリに、次のファイルをすべて保存します。この例では、このディレクトリをDEMO_HOME
と呼びます。
-
collocated_wls_otd_elasticity_domain.jar
- この例で使用するドメイン・テンプレート。このドメイン・テンプレートは、必要な動的クラスタ、Oracle Traffic Directorインスタンスおよびポリシーとアクションを作成し、動的クラスタにweb.war
アプリケーションをデプロイするなどして、ドメインを設定します。 -
unpack-elasticity-domain
スクリプト - このスクリプトは、unpack
コマンドを実行してcollocated_wls_otd_elasitcity_domain.jar
ファイルを解凍し、この例で使用するドメインelasticity_domain
を作成します。このスクリプトのWindowsバージョンの名前は、
unpack-elasticity-domain.cmd
です。Unixバージョンは、unpack-elasticity-domain.sh
です。 -
Elasticity5MinuteDemo.jmx
- この例で使用するJMeterテスト・プラン。 -
Elasticity1HourDemo.jmx
- オプションの、より長いJMeterテスト・プラン。
環境の設定
WebLogic ServerおよびOracle Traffic Directorを同じORACLE_HOME
ディレクトリにインストールしたら、setWLSEnv
スクリプト・コマンドを実行して、この例に環境変数を設定します。
-
コマンド・ウィンドウを開きます。
ノート:
Windowsシステム上でこのデモを実行する場合、管理者権限が必要になる場合があります。その場合は、次のとおりにコマンド・ウィンドウを開きます。
-
「起動」をクリックします。
-
コマンド・プロンプトを右クリックして「管理者として実行」を選択します。
「スタート」メニューに「コマンド プロンプト」がない場合、「検索」フィールドに
「コマンド」
と入力し、「コマンド プロンプト」を右クリックします。 -
求められたら、管理者の資格証明を入力します。
-
-
コマンド・ウィンドウで、
ORACLE_HOME
/wlserver/server/bin
ディレクトリに移動します。 -
setWLSEnv
スクリプトを実行します。たとえば:Windows:
ORACLE_HOME\wlserver\server\bin> setWLSEnv.cmd
Unix:
prompt> sh setWLSEnv.sh
ドメイン・テンプレートの解凍
ドメイン・テンプレートcollocated_wls_otd_elasticity_domain.jar
を解凍すると、この例のドメインが、次のように設定されます。
-
elasticity_domain
ドメインとディレクトリを作成します。 -
動的クラスタ
DynamicCluster
と4つの動的サーバーDynamicCluster-1
、DynamicCluster-2
、DynamicCluster-3
およびDynamicCluster-4
を作成し、構成します。 -
ラウンドロビン・ロード・バランシングおよび動的検出のために構成された新しいサーバー・プール
origin-server-pool-1
などの、Oracle Traffic Directorインスタンスelasticity-otd
を作成し、構成します。 -
スマート・ルールベースのポリシー
highMark
とlowMark
、およびエラスティック・アクションscaleDown
とscaleUp
を作成して構成します。
ドメイン・テンプレートを解凍するには:
『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のunpackコマンドに関する項を参照してください。
管理サーバーとノード・マネージャの起動
ドメイン・テンプレートを解凍したら、次のようにstart-servers
スクリプトを実行することによって、管理サーバーおよびノード・マネージャを起動します。
Windows:
DEMO_HOME> start-servers.cmd
Unix:
DEMO_HOME> sh start-servers.sh
start-servers
スクリプトも、Oracle Traffic Directorインスタンスを起動しようとします。ただし、初めてこのスクリプトを実行する場合は、次のエラー・メッセージが表示される可能性があります。
Error starting otd_elasticity-otd_localhost, likely already running or not yet configured
Oracle Traffic Directorインスタンスの起動で説明しているように、このメッセージは、Oracle Traffic Directorインスタンスがまだ構成されない場合に生成されます。
ノート:
このデモのためのWebLogic Server管理コンソールおよびFusion Middleware Controlは、ポート20001にあります。これらのコンソールに関する情報は、「Oracle Traffic Directorインスタンスの起動」および「動的サーバーの構成とアクティビティの表示」を参照してください。
『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。
『Oracle WebLogic Serverのノード・マネージャの管理』のノード・マネージャの起動と停止に関する項 を参照してください。
Oracle Traffic Directorインスタンスの起動
このデモを始めて実行する場合は、create-otd
スクリプトを実行する必要があります。その後は、管理サーバーとノード・マネージャの起動で説明しているように、サーバー・インスタンスを起動するとOracle Traffic Directorが起動されます。
create-otd
スクリプトを実行するには、管理サーバーとノード・マネージャを起動したコマンド・ウィンドウで、次のコマンドを入力します。
Windows:
DEMO_HOME> create-otd.cmd
Unix:
DEMO_HOME> sh create-otd.sh
このスクリプトでは次のことを行います。
-
ポート
20009
に、新しいOracle Traffic Directorインスタンスelasticity-otd
を作成します。 -
新しいサーバー・プール
origin-server-pool-1
を作成します。 -
ラウンドロビン・ロード・バランシングおよび動的検出のためのサーバー・プールを構成します。
『Oracle Traffic Directorの管理』のOracle Traffic Directorインスタンスの起動、停止および再起動に関する項を参照してください。
Fusion Middleware Controlを使用してOracle Traffic Directorインスタンスを表示するには:
ブラウザにURLhttp://localhost:20009/web/HelloServlet
を入力することで、Oracle Traffic Directorインスタンスをテストすることもできます。ページを数回リフレッシュして、ロード・バランシングが機能していることを確認します。ページ上の番号表示が変わるはずです。
WLSTを使用してインスタンスの状態を確認し、確実に実行中であるようにするには、次のコマンドを入力します。
state("elasticity-otd")
動的サーバーの構成とアクティビティの表示
start-servers
スクリプトを実行すると、管理サーバーとノード・マネージャの起動で説明されているように、次のWebLogic Serverインスタンスが起動します。
-
管理サーバー
-
DynamicCluster
という名前が付いた、動的クラスタにある次の2つのサーバー・インスタンス:-
DynamicCluster-1
-
DynamicCluster-2
-
WebLogic Server管理コンソールかFusion Middleware Controlを使用して、DynamicCluster
の構成と、クラスタ内で実行中デモとして現在実行中のサーバー・インスタンスの数を表示できます。
たとえば、WebLogic Server管理コンソールにDynamicCluster
を表示するには、次のようにします。
『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。
監視ダッシュボードを使用したスケーリング操作の監視
JMeterでテスト・プランを起動したら、WebLogic Server管理コンソールの管理ダッシュボードを使用して、JMeterテストにより生成されるサーバー・アクティビティを表示できます。実行中のサーバー・インスタンス数が負荷に応じて4までランプアップすることを確認できます。シナリオが完了すると、追加のインスタンスは、最小実行サーバー・インスタンス数の2つに達するまでスケール・ダウンされます。このシナリオ全体は、5分間続きます。
モニタリング・ダッシュボードにアクセスするには:
図6-3で、次に注目してください。
-
上部の4つのグラフに、管理対象サーバー・インスタンス
DynamicCluster-1
、DynamicCluster-2
、DynamicCluster-3
およびDynamicCluster-4
に関するスループットが表示されています。 -
上2つのグラフに表示されているサーバー・インスタンス
DynamicCluster-1
およびDynamicCluster-2
は、スループットのスパイクが2:42:00頃に始まっています。 -
DynamicCluster-3
のグラフは、サーバー・インスタンスDynamicCluster-1
およびDynamicCluster-2
でスループットのスパイクが発生したときにこの第3のサーバーが起動されたことを示しています。 -
下部のグラフは、クラスタ内のアクティブな管理対象サーバーの数(
ClusterRuntimeMBean
インスタンスのAliveServerCount
属性の値)を示しています。このグラフは、第3および第4のサーバー・インスタンスがいつ頃に起動されたかを示しています。 -
第3のサーバー・インスタンス
DynamicCluster-3
は、2:42:00と2:43:30の間に起動されました。 -
第4のサーバー・インスタンス
DynamicCluster-4
は、最初の3つのサーバー・インスタンスにおけるスループットの増加と軌を一にして、2:46:00の直後に起動されたことに注目してください。 -
新しいサーバー・インスタンスが起動されると、他のサーバー・インスタンス上のスループットが、それに対応して低下することに注目してください。