| Oracle® Fusion Middleware WebLogic Server Multitenantの使用 12c (12.2.1) E67376-02 |
|
 前 |
 次 |
この章では、サーバー・インスタンスに配置されたドメイン・パーティションによって、リソース割当ての公平性を保証し、共有リソースの競合を減らす、リソース消費管理(RCM)の使用方法について説明します。Fusion Middleware Control (FMWC)またはWLSTを使用してRCMポリシーを作成して、MT環境におけるドメイン・パーティションの一貫したパフォーマンスを提供できます。
この章の内容は次のとおりです。
リソース消費管理(RCM)は、共有リソースを管理し、MT環境でドメイン・パーティションの一貫したパフォーマンスを提供するために、WebLogic Serverシステム管理者に柔軟性のある動的なメカニズムを提供します。
RCMポリシーは、リソース・マネージャとして構成されます。ドメイン・レベルのグローバル・スコープでリソース・マネージャを作成して、ドメイン内の任意のパーティションに対してRCMポリシーとして使用できます。パーティションにそのパーティションに固有のRCM特性がある場合は、パーティション・スコープのリソース・マネージャを作成することもできます。「リソース消費管理の構成: 主な手順」を参照してください
アプリケーションが複数のドメイン・パーティションにデプロイされた場合、低レベルのリソース(CPU、ヒープ、ネットワーク、ファイル・ディスクリプタなど)を共有すると、リソース割当て中に不公正となる可能性があります。高トラフィック、アプリケーション設計、悪質なコードなどの様々な理由により、異常なリソース消費のリクエストが発生する可能性があります。これらのリクエスト・タイプにより、別に配置されたドメイン・パーティションがリソースにアクセスしないように、共有リソースの容量が過負荷となります。ドメイン・パーティション・レベルで適切なRCMポリシーを使用することによって、リソース消費管理は、あるパーティションのアプリケーションが他のパーティションのアプリケーションに悪影響を及ぼさないようにします。
次のJVM引数を設定して、環境内でWebLogic RCMを有効化します。
-XX:+UnlockCommercialFeatures -XX:+ResourceManagement -XX:+UseG1GC
このフラグは、RCMが有効化されるすべてのサーバー・インスタンス(JVM)に適用する必要があります。
代替方法は、ドメインの作成時に作成されるstartWeblogic.shファイル内の次のJAVA_OPTIONSをコメント解除することです。
#JAVA_OPTIONS="-XX:+UnlockCommercialFeatures -XX:+ResourceManagement -XX:+UseG1GC ${SAVE_JAVA_OPTIONS}
これは、各サーバー・インスタンスで行う必要があり、WebLogic Serverインスタンスの起動前に行う必要があります。
WebLogic ServerでJavaセキュリティ・マネージャが使用される場合、WebLogicリソース消費管理は、weblogic.policyで次の権限を付与する必要があります。
permission RuntimePermission("jdk.management.resource.getResourceContextFactory")
Javaセキュリティ・マネージャを使用したWebLogicのリソースの保護の詳細は、『Oracle WebLogic ServerでのWebLogicセキュリティ・サービスによるアプリケーションの開発』のJavaセキュリティ・マネージャを使用したWebLogicリソースの保護に関する項を参照してください。
次の共有リソースは、RCMポリシーで管理できます。
FileOpen: パーティションで使用中の開いているファイル・ディスクリプタの数。これには、FileInputStream、FileOutputstream、RandomAccessFileおよびNIO Fileのチャネルを介して開いているファイルが含まれます。
HeapRetained: パーティションで保存される/使用中のヒープの量(MB)。
CpuUtilization: WebLogicプロセスの使用可能なCPU時間に対する、パーティションで使用されるCPU時間の割合。
システム管理者は、リソース・マネージャを使用して、ドメインのパーティションごとに共有リソースに対するリソース消費管理ポリシーを指定します。リソース・マネージャは、1つ以上の共有リソースに対する1つ以上のポリシーで構成されます。各ポリシーは、リソースに対する制約値と、制約値に達したときにWebLogic Serverインスタンスによって実行される指定されたアクションで構成されます。
次のRCMポリシー・タイプがサポートされています。
トリガーは、許可されるリソース使用量の静的制約値を定義します。そのリソースの使用量が制約値を超えると、指定したアクションが実行されます。このポリシー・タイプは、ドメインのパーティションによるリソース使用率が予測可能である環境に最適です。
システム管理者は、トリガー・ポリシーの作成時に、次のアクションを選択できます。
Notify: 制約値に達したことがシステム管理者に通知されます。リソースに複数のNotifyトリガーを追加できます。たとえば、Open Filesが20を超えたときにNotify、Open Filesが50を超えたときにNotifyなどです。また、WebLogic診断フレームワーク(WLDF)を使用して、ログ・メッセージをリスニングするようにウォッチ・ルールを作成し、拡張通知を行うことができます。
Slow: リソースの消費率を低下します。Slowアクションがトリガーされると、パーティション・ワーク・マネージャのフェア・シェア値が減少し、パーティションで使用可能になったthread-usage timeが減少します。パーティション・ワーク・マネージャの詳細は、「パーティション・ワーク・マネージャの構成」を参照してください。
Fail: 使用量が制約値を下回るまで、リソースのリソース消費リクエストが失敗します。
|
注意: FailはOpen Filesに対してのみ適用可能で、その他のリソースには適用できません。 |
たとえば、パーティションP1の開かれたファイルの数を100ファイル未満に制限するには、P1パーティションに対してOpen Filesリソースの100個の制約値とFailアクションを持つトリガー・ポリシーを含むリソース・マネージャを作成します。
Shutdown: クリーンアップを許可しているときにパーティションの停止を開始します。このアクションは、パーティションが既知の制約値を超え、ドメイン内の他のパーティションによって使用される共有リソースの悪影響が予想される場合に役立ちます。パーティションは、制約値に達した管理対象サーバーでのみ停止し、クラスタ環境での継続的な可用性が実現します。FailトリガーとShutdownトリガーは一緒に使用しないでください。
|
注意: ポリシー・アクションは、アクション・タイプに応じて同期的にも非同期的にも実装されます。たとえば、Failアクションは、開いているファイルをリクエストしたスレッドを同期的に使用します。その他のアクション(「保存されるヒープ」リソースに構成されたSlowアクションなど)は、非同期的に続行します。 |
フェア・シェア・ポリシーにより、システム管理者が、ドメイン内の各パーティションの代表的な負荷に基づき、シェア(使用可能リソースのパーセンテージ)を割り当てることができます。フェア・シェア・ポリシーが使用されるのは、リソースの使用量の正確な要件を決定できない場合、またはリソースを効率的および公平に利用できるようにリソース・マネージャを使用する際に実装することが現実的ではない場合です。特定のリソースについてドメインのパーティション間で競合がない場合、各パーティションでその即時のワークロードに必要なリソースの量を使用できます。特定のリソースについてパーティション間で競合がある場合、各パーティションは使用可能リソースのフェア・シェアのみの使用に制約されます。メモリー消費全体が使用可能な最大メモリー(メモリー不足例外となる)を超えないように、制限が設定されていることを確認します。
シェアは、リソースの指定された量を使用するための割当てです。システム管理者が、関連するリソース・マネージャのフェア・シェア・ポリシーで1から1000までの整数値を指定して、パーティションにシェアを割り当てます。ドメインの同じリソースのすべてのフェア・シェア値の合計に対する、特定のパーティションのその構成されたフェア・シェア値の比率によって、割り当てられるリソースの量が決定します。
たとえば、システム管理者がパーティションP1でリソースに対して150のフェア・シェア値を指定し、パーティションP2で同じリソースに対して100の値を指定します。ワークロードが両方のパーティションでそのリソースの競合を作成するのに十分に高い場合、パーティションP1のリソース割当ては、150/(150+100)または使用可能なリソースの60パーセントです。
リソース・マネージャは、1つ以上の共有リソースに対する1つ以上のポリシーで構成されます。各ポリシーは、リソースに対する制約値と、制約値に達したときにWebLogic Serverインスタンスによって実行される指定されたアクションで構成されます。
リソース・マネージャを構成するには、次を参照してください。
『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・マネージャの作成に関する項。
次に示すのは、「リソース消費管理の構成: WLSTの例」に表示されたWLSTの例に類似した、注釈が付いたRCM構成です。
例11-1 リソース消費管理のconfig.xmlの構成例
<domain>
...
<!--Define RCM Configuration -->
<resource-management>
<resource-manager>
<name>Approved</name>
<file-open>
<trigger>
<name>Approved2000</name>
<value>2000</value><!-- in units-->
<action>shutdown</action>
</trigger>
<trigger>
<name>Approved1700</name>
<value>1700</value>
<action>slow</action>
</trigger>
<trigger>
<name>Approved1500</name>
<value>1500</value>
<action>notify</action>
</trigger>
</file-open>
<heap-retained>
<trigger>
<name>Approved2GB</name>
<value>2097152</value>
<action>shutdown</action>
</trigger>
<fair-share-constraint>
<name>FS-ApprovedShare</name>
<value>60</value>
</fair-share-constraint>
</heap-retained>
</resource-manager>
<resource-manager>
<name>Trial</name>
<file-open>
<trigger>
<name>Trial1000</name>
<value>1000</value><!-- in units-->
<action>shutdown</action>
</trigger>
<trigger>
<name>Trial700</name>
<value>700</value>
<action>slow</action>
</trigger>
<trigger>
<name>Trial500</name>
<value>500</value>
<action>notify</action>
</trigger>
</file-open>
...
</resource-manager>
</resource-management>
<partition>
<name>Partition-0</name>
<resource-group>
<name>ResourceTemplate-0_group</name>
<resource-group-template>ResourceTemplate-0</resource-group-template>
</resource-group>
...
<partition-id>1741ad19-8ca7-4339-b6d3-78e56d8a5858</partition-id>
<!-- RCM Managers are
then targetted to Partitions during partition creation time or later
by system administrators -->
<resource-manager-ref>Approved</resource-manager-ref>
...
</partition>
..
</domain>
ドメイン・パーティションから、リソース管理ポリシーを動的に適用または削除できます。リソース管理ポリシーへの変更は、そのポリシーを使用するすべてのドメイン・パーティションに適用されます。
アクティブなドメイン・パーティションのポリシー更新が、リソースの現在の使用量より低いリソースに対してトリガー値を設定した場合、そのリソースのその後の使用量には、ポリシーのリコース・アクションが適用されています。ポリシーを変更すると、現在の使用量の値に基づいてアクティブなドメイン・パーティションが即時停止される場合、その変更は、動的再構成の変更として受け入れられません。
パーティション内の共有リソースのリソース消費メトリックは、PartitionResourceMetricsRuntimeMBeanを介して使用可能になります。
これらのメトリックは次のために使用できます。
パーティションでの現在のリソース使用率のモニター。
パーティションのリソース消費をプロファイルおよび分析して、有効なリソース・マネージャとWLDFウォッチおよび通知を作成するために必要な、代表的な負荷、ピーク負荷、ピーク負荷時間などのデータを生成します。
FMWCでリソース・マネージャをモニターするには、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・マネージャのモニターに関する項を参照してください。
デフォルトでは、リソース・メーターの即時登録は無効です。そのため、特定のリソースについてリソース消費メトリックの問合せが初めて行われたときに作成されます。その場合、リソース・アカウンティングが遅れて開始されていて、リソース消費メトリックから返される値がパーティションで消費されたリソースの実際の値と異なることがあります。
パーティションで消費されたリソース量が正しく反映された値を得るには、メーターをパーティションの起動時に即座に登録する必要があります。リソース・メーターの即時登録を有効にするには、WebLogic Serverインスタンスの起動時、JVM引数としてweblogic.rcm.enable-eager-resource-meter-registrationプロパティをtrueに設定します。
次の各項では、リソース管理ポリシーを開発するシステム管理者のベスト・プラクティスと考慮事項について説明します。
リコース・アクションは、システム管理者が慎重に選択する必要があります。多くのリソース間には、複雑な相互作用があります。たとえば、CPU使用率を小さくする(ドメイン・パーティションに割り当てられるスレッドが少なくなるなる)と、ヒープの常駐が増加する可能性があり、これにより、保存されるヒープ使用量に影響を与えます。
遅れたリコース・アクションを有効にするために、アプリケーションがスレッドを作成または管理することはできません。アプリケーションは、WebLogic Serverで提供されている機能(EJBタイマー、Common Jワーク・マネージャおよびタイマー、管理対象エグゼキュータ・サービス、バッチAPIなど)のいずれかを使用して、遅れたリコース・アクションが有効になるようにタスクを管理することをお薦めします。
リソース消費管理ポリシーを指定する前に、システム管理者は、リソースの使用状況データの平均値と最大値をモニターし、十分なヘッドルームでポリシーを構成して、リソースを効率的に使用することとSLAを満たすことのバランスをとることをお薦めします。「リソース消費管理の構成: リソース使用率のモニタリング」を参照してください
対応するトリガーを実行する必要がある正確な限度を管理者が認識している場合に、トリガーを使用します。トリガーは、ファイルなどのリソースに対して構成されたしきい値を超えると実行され、ヒープやCPUなどのリソースに対して遅れる可能性があります。
フェア・シェア・ポリシーは、通常、バインド・サイズ共有のリソースが、競合するコンシューマによって効率的に(さらに十分に)共有されていることをシステム管理者が確認するために使用します。また、フェア・シェア・ポリシーは、パーティションによるリソースの正しい使用量を事前に正確に決定できないことをよく理解している場合に、システム管理者によって使用することもでき、システム管理者は、共在するパーティションへの共有リソースの公平な割当てが確実に行われるようにしながら、リソースを有効に利用します。パーティション間のリソースに補足的ワークロードがある場合に、環境内でフェア・シェア・ポリシーを使用します。「補足的ワークロードの使用」を参照してください
可能な場合、ピーク使用時間とその平均の合計が重複しないようにパーティション間のピーク使用時間のバランスをとることによるリソースの最大密度は、最大ピーク値を超えません。他方の対立するワークロードでは最大使用時間が重複し、平均の合計が最大のピーク値を超過します。
異なるリソースを実行するパーティション・ワークロードを配置することも考えてみます。たとえば、大部分がCPUバインドされたワークロードを持ち、それ以外はメモリー・バインドされたワークロードを持つパーティションをホストすると、密度が改善され、リソース使用率全体が向上します。
パーティションに固有のリソース要件がある場合に、パーティション・スコープ(アドホック)のRCMポリシーを使用します。これにより、既存のドメインに対するパーティションRCMポリシーのインポートおよびエクスポートが容易になります。
リソース管理ポリシーがパーティションで明示的に設定されていない場合、そのパーティションの使用可能な共有リソースへのアクセスには制約がありません。
CPU使用率は、配置されたドメイン・パーティションによってCPUの競合を追跡する優れたメトリックで、CPUバインドされたワークロードのフェア・シェア・ポリシーで特に役立ちます。RCMポリシーを使用してCPUを最大限使用する場合は、次を考慮します。
ドメイン内のすべてのパーティションのワークロード(統合ワークロード)を考慮したときに、CPUの最大使用率がCPUの平均使用率を大きく超えないようにする必要があります。CPUの最大負荷とCPUの平均負荷の差を最小限にすると、ドメインのCPUを最大限利用できます。
CPU使用率の約75%がドメインのパーティションに格納されたアプリケーションに使用されるようにRCMのCPUポリシーを構成することをお薦めします。残りの25%の10%ほどは操作タスク(バックアップ、スケジュール済タスクおよびその他の管理)に、15%ほどはクラスタ・フェイルオーバーに割り当てる必要があります。
ドメインおよびその他のシステム・ワークに十分使用可能なヒープ(ヘッドルーム)を提供し続けながら、パーティションのアプリケーションの要件をサポートするメモリー使用プランを作成します。ドメインのヒープ要件を評価する際に、各パーティションの代表的なワークロードの低、平均、安定した状態および最大のHeap Retainedの使用率の値を考慮します。
次のRCMの制限事項に注意してください。
ヒープ・リソース消費の追跡および管理は、G1ガベージ・コレクタで実行される場合のみサポートされます(他のJDKコレクタではRCMはサポートされません)。
JNI/ネイティブ・コードで発生するアクティビティのリソース消費メトリックの測定および計上はサポートされていません。
保存されるヒープとCPU使用率の測定は非同期的に実行されるため、現在の(ポイント・イン・タイムの)値を表しません。
静的フィールド内のオブジェクトのヒープ使用状況の区別、およびシステムからロードされたクラスおよび共有クラス・ローダーのシングルトン・オブジェクトに問題があり、最終会計値で正確に表されない可能性があります。システムからロードされたクラスおよび共有クラス・ローダーのインスタンスがパーティションによってロードされた場合、インスタンスのヒープの使用がそのパーティションに対して計上されます。
ガベージ・コレクション・アクティビティは、Oracle JDK 8u40を使用したWebLogic Server 12.2.1の特定のドメイン・パーティションに分離されません。
サーバー・インスタンスでリソース消費の追加の追跡および管理が発生したため、WebLogic ServerのRCM機能を有効にする際にパフォーマンスの影響があります。
WLSTを使用して、リソース消費管理ポリシーを実装およびモニターできます。
次に、WLSTを使用してRCM構成を作成する例を示します。この例では、システム管理者によって次が定義されています。
ドメインのすべてのProduction層を持つドメイン・パーティションに対してシステム管理者が確立する一連のリソース消費管理ポリシーを表すProductionリソース・マネージャ。Productionリソース・マネージャには様々なリソースに対するポリシーがあります。
FileOpenリソース・タイプには、3つのトリガーが指定されています。Production2000トリガーにより、開いているファイル・ディスクリプタの数が2000に達したときにパーティションが停止します。Production1700トリガーにより、開いているファイル・ディスクリプタの数が1700を超えたときにドメイン・パーティションを停止する必要があることが指定されています。Production1500トリガーにより、通知アクションが指定されます。
HeapRetainedリソース・タイプでは、Production2GBトリガーが作成され、パーティションの保存されるヒープ値が2GBに達したときにパーティションが停止します。Productionリソース・マネージャに、60のフェア・シェア値が割り当てられています。
Trialリソース・マネージャは同様に定義しますが、一連のポリシーが減少します。
Partition-0という名前のパーティション。
このスクリプトが完了すると、Partition-0にProductionリソース・マネージャが割り当てられます。
「RCMのWLSTの例: 概要」で説明されているポリシーは、次のWLSTスクリプトを使用して作成できます。
例11-2 リソース消費管理のWLSTの例
startEdit()
cd('/ResourceManagement')
cd(domainName)
rm=cmo.createResourceManager('Approved')
fo=rm.createFileOpen('Approved-FO')
fo.createTrigger('Approved2000',2000,'shutdown')
fo.createTrigger('Approved1700',1700,'slow')
fo.createTrigger('Approved1500',1500,'notify')
hr=rm.createHeapRetained('Approved-HR')
hr.createTrigger('Approved2GB',2097152,'shutdown')
hr.createFairShareConstraint('FS-ApprovedShare', 60)
cd('/ResourceManagement')
cd(domainName)
rm=cmo.createResourceManager('Trial')
fo=rm.createFileOpen('Trial-FO')
fo.createTrigger('Trial1000',1000,'shutdown')
fo.createTrigger('Trial700',700,'slow')
fo.createTrigger('Trial500',500,'notify')
save()
activate()
startEdit()
cd('/Partitions')
cd(partition-0)
cmo.setResourceManagerRef(getMBean('/ResourceManagement/'+domainName+'/ResourceManager/Approved'))
save()
activate()
この項では、環境へのRCMの実装時に便利な追加情報を示します。
ガベージファースト(G1)ガベージ・コレクタはサーバー形式のガベージ・コレクタで、大容量のメモリーを搭載するマルチプロセッサ・マシンを対象としています。ガベージ・コレクション(GC)一時停止時間目標を高い確率で満たしながら、高いスループットを実現します。http://docs.oracle.com/javase/8/docs/technotes/guides/vm/G1.htmlを参照してください。
共在するアプリケーションのリソースの分離と管理を提供するその他のWebLogic Server機能は、次のとおりです。
クラス・ローダー・ベースの分離 - アプリケーションの共有ライブラリに属していないクラスは、相互に分離されます。『Oracle WebLogic Serverアプリケーションの開発』の共有アプリケーション・クラス・ローダーの構成に関する項およびWebLogic Serverアプリケーションのクラスローディングの理解に関する項を参照してください。
WebLogic Serverワーク・マネージャ - 一連のスケジューリング・ガイドラインを構成することによって、作業の実行を優先します。これにより、ワーク・マネージャは、アプリケーションに割り当てられたスレッドの管理、およびそのスレッドへのワーク・マネージャ・インスタンスのスケジューリングの管理が可能で、サービス・レベル合意の維持に役立ちます。『Oracle WebLogic Serverサーバー環境の管理』のパーティション・ワーク・マネージャの構成に関する項およびワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください
追加情報は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のマルチテナントのチューニングの推奨事項に関する項を参照してください。
