|
|
このマニュアルでは Oracle® WebLogic Operations Control を紹介します。
オペレーション センターでの仮想化テクノロジの導入では物理ハードウェアの最大限の利用が確保されますが、テクノロジから生じる複雑さによって、コンピューティング リソースを効率的に利用できる一方、アプリケーションがどの程度厳密にサービス レベル アグリーメント (SLA) に準拠するかを判別することが困難になります。
WebLogic Operations Control (WLOC) は、アプリケーションの仮想化に伴う重要な課題に対処する仮想化および非仮想化エンタープライズ Java アプリケーションのための管理フレームワークです。これらの課題に対処するために、WLOC では以下のことを行います。
WLOC では抽象レイヤが導入され、コンピューティング環境の複雑さと、オペレーション センターでサポートされる各 Java アプリケーションのユニークな要件を理解することが要求される代わりに、オペレーション スタッフは需要と供給の観点から業務を遂行できます。
需要サイドでは、WLOC を使用して Java アプリケーション (プロセス) を WLOC サービスに整理します。関連するプロセスのグループを単一のサービスに整理し、グループ単位で管理を行います。各プロセスごとに 1 つのサービスを作成できます。
供給サイドでは、WLOC を使用してオペレーション センターの計算リソースをリソースの集合、つまりリソース プールに整理します。WLOC リソース プールは、単一の物理マシン、またはハイパーバイザ ソフトウェアを通じて使用可能な仮想化されたリソースの集合を表現できます。
WLOC では、デプロイされたサービスの需要を満たすために、使用可能なリソースの供給が効率的に管理されます。
WLOC では、サービス レベル アグリーメント (SLA) を要件およびポリシーの集合としてカプセル化する環境が提供されます。オペレーション チームは、ハードウェアおよびソフトウェアのリソースの割り当てを管理するアプリケーションレベルの SLA に基づいたポリシーを定義できます。これにより、仮想化および非仮想化プラットフォーム間でサービス品質 (QoS) の目標が達成されます。あらかじめ定義された条件が発生すると、WLOC ではアクションがトリガされます。たとえば、WLOC ではサービスに対するリソースが動的に割り当てられます。
WLOC ではオペレーション センター全体のリソースの使用がモニタされ、リソース全体の最大限の使用効率が確保される方法で Java アプリケーションのデプロイメントが配布されます。
ユーザがサービスをデプロイしたり、WLOC アクションが追加のプロセスの起動を要求すると、サービスまたはプロセスをホストする場所を決定するために WLOC ではすべてのリソース プールが調査されます。リソース プールを選択するため、WLOC では IP アドレスまたはソフトウェア アクセスなどの依存関係を満たすことができないリソース プールが最初に除外されます。たとえば、サービスが WebLogic Server ソフトウェアへのアクセスを必要とする場合、WLOC では WebLogic Server ソフトウェアへのアクセスを提供できないリソース プールがすべて除外されます。
宣言された依存関係を検討した後、WLOC では残りの各リソース プールの容量、現在デプロイされているサービスの SLA、および各サービスに宣言された相対的な優先順位が検討されます。その後、ユーザが選択する以下のいずれかのアルゴリズムが使用されます。
たとえば、リソース プール A に 600 MHz の CPU と現在未使用の 600 MB の RAM があり、リソース プール B に 400 MHz の CPU と未使用の 400 MB の RAM がある場合、WLOC ではリソース プール A が選択されます。
たとえば、リソース プール A に 600 MHz の CPU と現在未使用の 600 MB の RAM があり、リソース プール B に 400 MHz の CPU と未使用の 400 MB の RAM があり、かつデプロイするサービスの最小要件が 200 MHz の CPU と 200 MB の RAM である場合、WLOC ではリソース プール B が選択されます。
一般的な WLOC デプロイメントには、単一の WLOC コントローラ (オペレーティング環境に関するデータを収集する中央のコンポーネント) と、リソースを管理およびモニタし、それらの情報をコントローラに提供する複数のエージェントが含まれます。WLOC 環境のビジュアルなコンフィグレーション、管理、およびモニタを実行できる WLOC Administration Console はコントローラでホストされます。
| 注意 : | すべてのコンポーネントは通信に HTTPS または HTTP を使用します。 |
以下の表は、上記の図に示す WLOC の各コンポーネントについて説明します。
WLOC コントローラは、オペレーティング環境およびデプロイされたサービスに関するデータをエージェントから収集し、順応的管理を提供する中央のコンポーネントです。コントローラでは、環境内のすべてのサービスのサービス レベル アグリーメント (SLA) に準拠するため、収集されたデータを使用して新しいサービスが適切にデプロイされ、ポリシーが評価および適用されます。
各 WLOC 環境には、以下の処理を行う単一のコントローラが含まれています。
コントローラのコンフィグレーションでは、コントローラが使用可能なエージェントにバインドされます。リソース プールを管理するため、コントローラはバインドされたエージェントと通信して各エージェントが割り当て可能なコンピューティング リソースを判別し、サービスをデプロイするために適切なリソース プールを選択します。
WLOC サービスは、WLOC が 1 つの単位として管理する 1 つまたは複数のプロセスの集まりです。各プロセスの実行に必要なサービスの詳細と関連付けられたメタデータを定義します。SLA を作成するには、デプロイメントと実行時の制約、およびこれらの制約が満たされない場合に実行されるアクションから成るサービス ポリシーを定義します。
デプロイされたすべてのサービスの SLA を適切に満たすように WLOC 環境を調整するため、コントローラはエージェントと通信してメトリックを収集します。ポリシーの制約はメトリックと比較され、サービスの動作が制約を越えた場合はアクションが呼び出されます。
WLOC エージェントは、CPU サイクルとマシン メモリ、または WLOC サービスで使用されるリソース プールとしての仮想リソースの集合を示すスタンドアロン Java プロセスです。
一般に、WLOC 環境には以下の処理を行う複数のエージェントが含まれています。
図 2 にあるとおり、WLOC では 2 種類のエージェントが提供されます。
VMware インフラストラクチャは、VMware ツールを使用してコンフィグレーションする必要があります。WLOC を使用して仮想化環境をコンフィグレーションすることはできず、使用可能なリソースを利用するためにのみ使用します。
WLOC Administration Console は、オペレーション センターのサービスのコンフィグレーション、管理、およびモニタに使用される Web ブラウザベースのグラフィカル ユーザ インタフェースです。これは、エージェントと通信してモニタ データを収集し、管理アクションを呼び出す WLOC コントローラによってホストされます。
以下の表に、WLOC Administration Console を使用して実行できるタスクの概要を示します。
WLOC Administration Console にアクセスできるのは、認証された WLOC ユーザのみです。
| 注意 : | セキュリティ データを除いて、WLOC では XML ファイルにコンフィグレーションが格納されます。必要であれば、WLOC Administration Console を使用する代わりに有効なテキスト エディタを使用して XML を直接編集することで、WLOC コンポーネントをコンフィグレーションできます。この場合、変更を有効にするためにコントローラまたはエージェントを再起動する必要があります。 |
WLOC Administration Console で以下の処理を行うことはできません。
WLOC サービスは、WLOC が 1 つの単位として管理する 1 つまたは複数のプロセスの集まりです。サービス内の各プロセスは、Java 仮想マシン (JVM) から起動し、JVM で実行するクラスが含まれているソフトウェア スタックです。同じ機能を実行し、同じ実行時特性を備えたプロセス (JVM プロセス) は、サービス内の「プロセス グループ」にまとめることができます。たとえば、クラスタ内のすべてのサーバをプロセス グループに整理できます。
サービスのデプロイメントまたは実行時の要件 (制約)、および SLA 制約が満たされない場合に実行されるアクションを指定する 1 つまたは複数のポリシーを定義できます。たとえば、ポリシーでは実行時環境に応じてサービスのサイズを展開または縮小できます。
制約は、1 つのプロセス、プロセスのグループ、またはサービスのすべてのプロセスに対して付与できます。管理対象プロセスが Java Management Extensions (JMX) を通じて管理データを公開する場合、プロセスの MBean 属性の値に基づく制約、または、プロセスあるいはプロセス グループの MBean 属性から取得された計算値に基づく制約を定義できます。
制約に違反した場合、WLOC ではコンフィグレーションされた Java クラス (アクション) が呼び出されます。WLOC で提供されるアクションをコンフィグレーションして、以下のことが行えます。
また、あらかじめ定義された時間にアクションをトリガするポリシーを定義できます。
アクションを組み合わせて、呼び出すアクションのシーケンスが指定されたアクション パイプラインを作成できます。アクションまたはアクション パイプラインは、サービスのポリシーで呼び出すか、または WLOC Administration Console から手動で呼び出すことができます。
たとえば、すべてが単一の WebLogic Server クラスタで実行される、外部向け Web サービス コレクションのプロセス グループを指定する WLOC サービスを作成します。以下のように、プロセス グループをコンフィグレーションできます。
サービスのデプロイ時、WLOC ではサービスが排他的に使用する 400 CPU サイクルおよび 600 MB の RAM が予約されます。WLOC ではサービスにプロセスが追加されるにつれ、サービスが使用する追加のリソースが最大まで要求されます。追加のリソースが他のプロセスで使用中の場合、予約された最小リソースが各プロセスで保持される限り、WLOC では優先順位の低いプロセスからリソースを削除することができます。
WLOC リソースのパフォーマンスをモニタするには、以下の手順を行います。
WLOC Administration Console へのアクセスを保護するため、WLOC ではロールベースのアクセス制御が使用され、異なるレベルの特権をさまざまなユーザまたはグループに割り当てることができます。WLOC で提供される一連のセキュリティ ロールにはアクセス特権があらかじめコンフィグレーションされています。多数のユーザの管理を簡素化するため、WLOC では一連のグループも提供され、1 つまたは複数の WLOC セキュリティ ロールにこれらをコンフィグレーションできます。WLOC Administration Console を使用すると、ユーザを作成してグループに割り当てたり、直接セキュリティ ロールに割り当てたりすることができます。
  
|
