8 リソース・グループの構成
注意:
WebLogic Server Multitenantドメイン・パーティション、リソース・グループ、リソース・グループ・テンプレート、仮想ターゲットおよびリソース消費管理は、WebLogic Server 12.2.1.4.0で非推奨になり、次のリリースで削除されます。この章の内容は次のとおりです。
リソース・グループの構成: 概要
リソース・グループは、アプリケーションとそれらが使用するリソースを、ドメイン内の個別の管理単位にグループ化します。通常、指定されたリソース・グループ内でリソースがなんらかの方法で関連付けられます。たとえば、それらが単一のアプリケーション・スイートを構成します。
リソースとアプリケーションには、それらのリソースを開始したりそれらに接続するために必要なすべての情報(データ・ソースに接続するための資格証明やアプリケーションのターゲット指定情報を含む)があります。リソース・グループにデプロイされたアプリケーションは、起動可能な状態にする必要があります。
リソース・グループとは
リソース・グループはResourceGroupMBean
に基づくもので、次のリソースを含めることができます。
-
一般(名前、スコープ、リソース・グループ・テンプレートに基づくかどうか)
-
デプロイメント
-
サービス:
-
JDBC
-
メッセージ
-
メール・セッション
-
永続ストア
-
外部JNDIプロバイダ
-
OSGiフレームワーク
-
診断
-
-
ターゲット
-
モニタリング機能(JDBC、メッセージ)
-
制御機能(JDBC、メッセージ、移行)
-
ノート
リソース・グループとオーバーライド
リソース・オーバーライドによって、パーティション・レベルでリソースをカスタマイズできます。リソース・グループ・テンプレートから導出されたリソース設定をオーバーライドできます。
オーバーライドには、主に2つのタイプがあります。
-
リソース・オーバーライド構成MBeanおよびリソース・デプロイメント・プランを使用して、特定のリソースのリソース設定をオーバーライドできます。
-
別のデプロイメント・プランを指定して、リソース・グループ・テンプレートに定義されているアプリケーションおよびモジュールのデフォルト・アプリケーション構成をオーバーライドできます。アプリケーションまたはモジュールは、アプリケーション構成用の新しいデプロイメント・プランを使用して再デプロイされます。
リソース・オーバーライドの詳細は、「リソース・オーバーライドの構成」を参照してください。アプリケーション・オーバーライドの詳細は、「パーティション・リソース・グループへのアプリケーションのデプロイ」を参照してください。
グローバル・スコープおよびパーティションでのリソース・グループ
リソース・グループは、ドメイン・レベルで作成することも、ドメイン・パーティションに固有のものとして作成することもできます。ドメイン・レベルでリソース・グループを作成する場合、それにグローバル・スコープが指定され、非パーティション環境のドメイン・レベルと同等になります。ドメイン・レベルで実行されるアプリケーションまたはクラスはドメイン全体で使用できますが、パーティションでは使用できません。
パーティション・レベルで作成したリソース・グループは、そのパーティションにのみスコープ指定されます。パーティション・レベルで実行されるアプリケーションまたはクラスはそのパーティションで使用できますが、ドメイン・レベルまたは他のパーティションでは使用できません。
複数のターゲットへのリソース・グループのターゲット設定
複数の仮想ターゲットを持つようにリソース・グループを構成できます。たとえば、リソース・グループをCluster1
、Cluster2
およびCluster3
の仮想ターゲットにターゲット設定して、リソース・グループのアプリケーションが3つすべてのクラスタで実行できます。
ただし、2つの重要な制限が存在します。
-
一部のリソース・グループ構成には、複数のターゲットに適用されないターゲット固有のリソースがある場合があります。次にこのようなリソースの例を示します(これらに限定されるものではありません)。
-
JMSサーバー
-
メッセージング・ブリッジ
-
パス・サービス
-
JMSブリッジ宛先
-
ファイル・ストア
-
JDBCストア
-
JMSシステム・リソース
リソース・グループのターゲットとして複数の仮想ターゲットを指定しようとしたときに、これらのリソースのいずれかが存在する場合、WebLogic Server MTでエラーが生成されます。
-
-
同じ物理サーバーをターゲットとしている複数の仮想ターゲットには、リソース・グループをターゲット設定できません。
たとえば、リソース・グループ
RG
のターゲットとしてVT1
およびVT2
が指定され、かつVT1
とVT2
の両方のターゲットとしてServer1
が指定されている場合は、WebLogic Server MTによってエラーが生成されます。
リソース・グループの作成: 主なステップおよび例
リソース・グループを作成する場合、新しいリソース・グループを作成する方法と、リソース・グループ・テンプレートに基づいてリソース・グループを作成する方法の2つがあります。
新しいリソース・グループの作成により、リソース・グループの基本構造が作成されます。次に、このリソース・グループを必要に応じて編集する必要があります。一方、リソース・グループ・テンプレートからリソース・グループを作成すると、構成がテンプレートから新しいリソース・グループにコピーされます。次に、リソース・グループ・テンプレートからの値を必要に応じて編集およびオーバーライドする必要があります。リソース・グループ・テンプレートの詳細は、「リソース・グループ・テンプレートの構成」を参照してください。
パーティションまたはグローバル・スコープで新しいリソース・グループを作成するには、次のようにします。
-
必要に応じて、パーティションまたはドメイン・レベルに移動します。
次の移動の相違点に注意してください。
-
Fusion Middleware Controlを使用している場合は、「WebLogicドメイン」→「環境」→「リソース・グループ」に移動して、パーティション・レベルまたはドメイン・レベルでリソース・グループを作成できます。
-
Oracle WebLogic Server管理コンソールを使用している場合は、「WebLogicドメイン」→「環境」→「リソース・グループ」に移動して、ドメイン・レベルでリソース・グループを作成します。
「WebLogicドメイン」→「ドメイン・パーティション」→「パーティション」→「リソース・グループ」に移動して、パーティション・レベルでリソース・グループを作成します。
-
-
新しいリソース・グループを作成します。
-
新しいリソース・グループに対して、次の構成設定を定義できます。
-
新しいリソース・グループの名前を入力します
-
パーティション・レベルかドメイン・レベルかを選択します。
-
オプションで、この新しいリソース・グループに使用するリソース・グループ・テンプレートを選択します
-
この新しいリソース・グループのターゲットを選択します。
-
新しいリソース・グループのノートを入力します
-
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループの作成に関する項を参照してください。
リソース・グループをリソース・グループ・テンプレートから作成しなかった場合、最初のリソース・グループ構成は基本スケルトンで、使用する前に構成する必要があります。リソース・グループまたはリソース・グループのオーバーライドの構成時に、パーティションに必要な構成のほとんどを実行します。タスクには、JDBCシステム・データ・ソース、JMSサーバーおよびリソース、外部JNDIプロバイダなどの構成が含まれます。
「リソース・グループの構成: 主なステップおよび例」を参照してください。
リソース・グループの作成: WLSTの例
この例では、次の操作を実行しています。
-
ドメイン・パーティションを作成します。
-
仮想ターゲットを作成します。
-
仮想ターゲットのホスト名およびURI接頭辞を設定します。
-
この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。
-
リソース・グループを作成します。
-
仮想ターゲットをリソース・グループに追加します。
-
変更をアクティブ化します。
-
パーティションを起動します。
注意:
これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。
# Create Pep partition and ResourceGroup edit() startEdit() wls:/base_domain/edit/ !> domain=getMBean('/') wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep') wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT') wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String)) wls:/base_domain/edit/ !> vt.setUriPrefix('/foo') wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt) wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG') wls:/base_domain/edit/ !> peprg.addTarget(vt) wls:/base_domain/edit/ !> activate() wls:/base_domain/edit/ !> startPartitionWait(peppart)
リソース・グループの作成: RESTの例
RESTを使用したリソース・グループの作成の例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のパーティションの作成に関する項を参照してください。
特に、新しいパーティションのリソース・グループの作成に関する項を参照してください。
リソース・グループの構成: 主なステップおよび例
リソース・グループの構成には、一般設定、デプロイメント・オプション、サービス(JDBC、JMS、メール・セッション、永続ストア、外部JNDIプロバイダなど)の指定、およびリソース・グループのターゲットの指定などの複数のタスクが含まれることがあります。
リソース・グループの一般設定の構成
リソース・グループの一般設定を表示および定義するには、次のようにします。
-
構成するリソース・グループを選択します。
-
次のような、リソース・グループの一般的な構成設定を表示および定義します。
-
名前
-
スコープ
-
リソース・グループ・テンプレート
-
-
変更内容を保存します。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループの一般設定の構成に関する項を参照してください。
リソース・グループのデプロイメント設定の構成
リソース・グループのデプロイメント設定を表示および定義するには、次のようにします。
-
構成するリソース・グループを選択します。
-
次のデプロイメント・アクションを実行できます。
-
デプロイ
-
再デプロイ
-
アンデプロイ
-
デプロイメント・プランのフェッチ
-
オーバーライドの追加
-
オーバーライドの削除
-
起動
-
停止
-
-
変更内容を保存します。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループのデプロイメント設定の構成に関する項を参照してください。
リソース・グループへのアプリケーションのデプロイ
アプリケーションをデプロイすると、物理ファイルまたはディレクトリがWebLogic Serverで認識されます。
リソース・グループにアプリケーションをデプロイするには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループへのアプリケーションのデプロイに関する項を参照してください。
リソース・グループへのアプリケーションの再デプロイ
アプリケーションを再デプロイすると、アーカイブ・ファイルまたは展開済ディレクトリが再デプロイされます。アプリケーションを変更し、その変更がWebLogic Serverクライアントで使用されるようにする場合に、アプリケーションを再デプロイします。
リソース・グループにアプリケーションまたはモジュールを再デプロイするには、次のようにします。
- 構成するリソース・グループを選択します。
- 再デプロイするアプリケーションを選択します。
- デプロイメント・プランをアップロードするか、新しいデプロイメント・プランを作成するかを決定します。
- 必要に応じてアプリケーションの分散を更新します。
- オプションで、デプロイメント・プランを編集し、より高度なデプロイメント・オプションを設定して、ローカル・ディスクにデプロイメント・プランを保存します。
- アプリケーションを再デプロイして、このアプリケーションの再デプロイメントを完了します。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループへのアプリケーションの再デプロイに関する項を参照してください。
リソース・グループからのアプリケーションのアンデプロイ
アプリケーションをアンデプロイすると、アプリケーションがデプロイされているドメインの各ターゲットからアプリケーションが削除されます。アプリケーションをドメインからアンデプロイした後で、WebLogic Serverクライアントでアプリケーションを使用できるようにするには、再度アプリケーションをデプロイする必要があります。WebLogic Serverクライアントでアプリケーションを一時的に使用できないようにするには、アプリケーションをアンデプロイするのではなく、停止します。
パーティション・リソース・グループからアプリケーションをアンデプロイするには、次のようにします。
- 構成するリソース・グループを選択します。
- デプロイ済アプリケーションからアンデプロイするアプリケーションを選択します。
- アプリケーションをアンデプロイします。
- 削除されたアプリケーションを後でデプロイする場合は、「リソース・グループへのアプリケーションのデプロイ」を参照してください。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループからのアプリケーションのアンデプロイに関する項を参照してください。
リソース・グループのサービス設定の構成
この項では、次のタスクを取り上げます。
リソース・グループのJDBC設定の構成
このリソース・グループで作成されたJDBCシステム・リソースの構成設定を表示するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループのJDBC設定の構成に関する項を参照してください。
このリソース・グループで作成されたJDBCシステム・データ・ソースの構成の詳細は、「JDBCの構成」を参照してください。
リソース・グループのJMS設定の構成
この項では、次のタスクを取り上げます。
JMSサーバー設定の構成
このリソース・グループに作成されたJMSサーバーの構成設定を表示するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJMSサーバー設定の構成に関する項を参照してください。
このリソース・グループで構成されたJMSサーバーの構成の詳細は、「JMSサーバーの構成」を参照してください。
SAFエージェント設定の構成
このリソース・グループに作成されたストア・アンド・フォワード(SAF)エージェントの構成設定を表示するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のSAFエージェント設定の構成に関する項を参照してください。
このリソース・グループで構成されたSAFエージェントの構成の詳細は、「ストア・アンド・フォワード・エージェントの構成」を参照してください。
JMSリソース設定の構成
リソース・グループのリソース設定をモニターするには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のSAFエージェント設定の構成に関する項を参照してください。
既存のJMSリソースの構成の詳細は、「JMSシステム・リソースおよびアプリケーション・スコープのJMSモジュールの構成」を参照してください。
JMSモジュール設定の構成
リソース・グループのJMSモジュールを構成するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJMSモジュール設定の構成に関する項を参照してください。
既存のJMSモジュールの構成の詳細は、「メッセージング・コンポーネントの構成」を参照してください。
メッセージング・ブリッジの構成
リソース・グループのメッセージング・ブリッジ設定を構成するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のメッセージング・ブリッジの構成に関する項を参照してください。
このリソース・グループで構成されたメッセージング・ブリッジの構成の詳細は、「メッセージング・ブリッジの構成」を参照してください。
JMSブリッジ宛先の構成
リソース・グループのJMSブリッジ宛先設定を構成するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJMSブリッジ宛先の構成に関する項を参照してください。
パス・サービスの構成
リソース・グループのパス・サービス設定を構成するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のパス・サービスの構成に関する項を参照してください。
既存のパス・サービスの構成の詳細は、「分散宛先による順序単位の使用をサポートするパス・サービスの構成」を参照してください。
リソース・グループのメール・セッション設定の構成
このリソース・グループで作成されたメール・セッションの構成設定を表示するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』の「WebLogic Serverメール・セッション」を参照してください。
リソース・グループの永続ストア設定の構成
このリソース・グループで作成された永続ストアの構成設定を表示するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』の「WebLogic Server永続ストア」を参照してください。
既存の永続ストアの構成の詳細は、「JDBCまたはファイル永続ストアの構成」を参照してください。
リソース・グループの外部JNDIプロバイダ設定の構成
このリソース・グループで作成された外部JNDIプロバイダの構成設定を表示するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』の「WebLogic Server外部JNDIプロバイダ」を参照してください。
既存の外部JNDIプロバイダの構成の詳細は、「JNDIの構成とプログラミング」を参照してください。
リソース・グループの診断システム・モジュール設定の構成
このリソース・グループで作成された診断システム・モジュールの構成設定を表示するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』の「WebLogic Server診断」を参照してください。
既存の診断システム・モジュールの構成の詳細は、「パーティションのモニタリングおよびデバッグ」を参照してください。
リソース・グループのターゲットの構成
このリソース・グループのターゲットを指定するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』の仮想ターゲットの構成に関する項を参照してください。
実際の仮想ターゲットの構成の詳細は、「仮想ターゲットの構成」を参照してください。
リソース・グループのノートの構成
リソース・グループのノートを作成するには、次のようにします。
- 構成するリソース・グループを選択します。
- 「ノート」に移動します。
- ノートを入力します。
- 変更を保存します。
リソース・グループの構成: WLSTの例
この例では、次の操作を実行しています。
-
ドメイン・パーティションを作成します。
-
仮想ターゲットを作成します。
-
仮想ターゲットのホスト名およびURI接頭辞を設定します。
-
この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。
-
リソース・グループを作成します。
-
仮想ターゲットをリソース・グループに追加します。
-
変更をアクティブ化します。
-
パーティションを起動します。
注意:
これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。
-
アプリケーション
MySimpleEjb
をリソース・グループにデプロイします。
# Create Pep partition and ResourceGroup edit() startEdit() wls:/base_domain/edit/ !> domain=getMBean('/') wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep') wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT') wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String)) wls:/base_domain/edit/ !> vt.setUriPrefix('/foo') wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt) wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG') wls:/base_domain/edit/ !> peprg.addTarget(vt) wls:/base_domain/edit/ !> activate() wls:/base_domain/edit/ !> startPartitionWait(peppart) wls:/base_domain/edit/ !> deploy(appName='MySimpleEjb', path='c:/webservices/MySimpleEjb.jar', partition='Pep', resourceGroup='TestRG', deploymentOrder=10,securityModel='DDOnly') : Completed the deployment of Application with status completed Current Status of your Deployment: Deployment command type: deploy Deployment State : completed Deployment Message : no message
リソース・グループの構成: RESTの例
RESTを使用したリソース・グループの構成の例は、『RESTful管理サービスによるOracle WebLogic Serverの管理』のパーティションの作成に関する項を参照してください。
特に、新しいパーティションのリソース・グループの表示に関する項およびシステム・リソースを構成するパーティション・デプロイヤの説明に関する項を参照してください。
リソース・グループの削除: 主なステップおよびWLSTの例
リソース・グループを削除する前に、まずそれを停止する必要があります。リソース・グループを停止すると、リソース・グループのアプリケーションとリソースは処理を停止し、メモリーから削除されます。
- 削除するリソース・グループを選択します。
- 「制御」→「停止」に移動します。通常、作業の完了時にリソース・グループを停止するよう選択する必要があります。
- リソース・グループを停止します。
- リソース・グループを削除します。
リソース・グループの削除: WLSTの例
この例では、次の操作を実行しています。
-
ドメイン・パーティションを作成します。
-
仮想ターゲットを作成します。
-
仮想ターゲットのホスト名およびURI接頭辞を設定します。
-
この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。
-
リソース・グループを作成します。
-
仮想ターゲットをリソース・グループに追加します。
-
リソース・グループの設定を解除します。
-
リソース・グループを削除します。
-
別のリソース・グループを作成します。
-
そのリソース・グループに仮想ターゲットを追加します。
-
変更をアクティブ化します。
-
パーティションを起動します。
注意:
これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。
# Create Pep partition and Resource Group. Remove Resouce Group edit() startEdit() wls:/base_domain/edit/ !> domain=getMBean('/') wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep') wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT') wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String)) wls:/base_domain/edit/ !> vt.setUriPrefix('/foo') wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt) wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG') wls:/base_domain/edit/ !> peprg.addTarget(vt) wls:/base_domain/edit/ !> peppart.unSet('ResourceGroups') wls:/base_domain/edit/ !> peprg=peppart.destroyResourceGroup(peprg) wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG2') wls:/base_domain/edit/ !> peprg.addTarget(vt) wls:/base_domain/edit/ !> activate() wls:/base_domain/edit/ !> startPartitionWait(peppart)
リソース・グループの制御: 主なステップおよびWLSTの例
リソース・グループを起動すると、現在実行されていないアプリケーションのデプロイメントとリソースがアクティブになります。リソース・グループを停止すると、リソース・グループのアプリケーションとリソースは処理を停止し、メモリーから削除されます。これは、アプリケーションまたはリソースのアンデプロイと同等のランタイムです。ただし、実際のアンデプロイメントで行われるように、config.xml
ファイルからアプリケーションまたはリソースの構成が削除されることはありません。
リソース・グループを制御するには、次のようにします。
リソース・グループの制御: WLSTの例
リソース・グループの停止
次の例は、「リソース・グループの作成: WLSTの例」に示すWLSTの例を基に作成されています。ResourceGroupLifeCycleRuntime
MBeanへのナビゲーションを示し、リソース・グループTestRG
を停止します。
wls:/base_domain/serverConfig/> domainRuntime() wls:/base_domain/domainRuntime/> domain=cmo wls:/base_domain/domainRuntime/> partrun = cmo.lookupDomainPartitionRuntime('Pep') wls:/base_domain/domainRuntime/> partliferun = partrun.getPartitionLifeCycleRuntime() wls:/base_domain/domainRuntime/> rgliferun = partliferun.lookupResourceGroupLifeCycleRuntime('TestRG') wls:/base_domain/domainRuntime/> rgliferun.shutdown() [MBeanServerInvocationHandler]com.bea:Name=_2_SHUTDOWN,Type=ResourceGroupLifeCyc leTaskRuntime,DomainPartitionRuntime=Pep,ResourceGroupLifeCycleRuntime=TestRG,Pa rtitionLifeCycleRuntime=Pep
リソース・グループの起動
次の例は、「リソース・グループの作成: WLSTの例」に示すWLSTの例を基に作成されています。ResourceGroupLifeCycleRuntime
MBeanへのナビゲーションを示し、リソース・グループTestRG
を起動します。
wls:/base_domain/serverConfig/> domainRuntime() wls:/base_domain/domainRuntime/> domain=cmo wls:/base_domain/domainRuntime/> partrun = cmo.lookupDomainPartitionRuntime('Pep') wls:/base_domain/domainRuntime/> partliferun = partrun.getPartitionLifeCycleRuntime() wls:/base_domain/domainRuntime/> rgliferun = partliferun.lookupResourceGroupLifeCycleRuntime('TestRG') wls:/base_domain/domainRuntime/> rgliferun.start() [MBeanServerInvocationHandler]com.bea:Name=_4_START,Type=ResourceGroupLifeCycleT askRuntime,DomainPartitionRuntime=Pep,ResourceGroupLifeCycleRuntime=TestRG,Parti tionLifeCycleRuntime=Pep wls:/base_domain/domainRuntime/>
リソース・グループの移行: 主なステップおよびWLSTの例
リソース・グループを移行する場合、リソース・グループが使用している仮想ターゲットを、ある物理ターゲット(クラスタまたはサーバー)から別の物理ターゲットに変更します。移行後、仮想ターゲットは新しい物理ターゲット(クラスタまたはサーバー)を参照します。この変更は、この仮想ターゲットを使用しているパーティション・レベルまたはドメイン・レベルのリソース・グループに影響を及ぼします。
Fusion Middleware Controlを使用してリソース・グループを移行するには、次の手順を実行します。
リソース・グループの移行: WLSTの例
この例では、次の操作を実行しています。
-
ドメイン・パーティションを作成します。
-
仮想ターゲットを作成します。
-
仮想ターゲットのホスト名およびURI接頭辞を設定します。
-
仮想ターゲットを管理サーバーにターゲット設定します。(通常は、仮想ターゲットのターゲットとして管理サーバーを指定することはありません。)
-
この仮想ターゲットを、使用可能なターゲットとしてパーティションに追加します。
-
リソース・グループを作成します。
-
仮想ターゲットをリソース・グループに追加します。
-
変更をアクティブ化します。
-
パーティションを起動します。
注意:
これが本番モードで作成する最初のパーティションの場合は、管理サーバーを再起動する必要があり、その後でパーティションが起動可能になります。
-
ターゲットとしての管理サーバーを削除します。
-
仮想ターゲットを
Cluster-0
に移行(ターゲット指定)します。
# Create Pep partition and ResourceGroup edit() startEdit() wls:/base_domain/edit/ !> domain=getMBean('/') wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep') wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT') wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String)) wls:/base_domain/edit/ !> vt.setUriPrefix('/foo') wls:/base_domain/edit/ !> tgt=getMBean('/Servers/AdminServer') wls:/base_domain/edit/ !> vt.addTarget(tgt) wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt) wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG') wls:/base_domain/edit/ !> peprg.addTarget(vt) wls:/base_domain/edit/ !> activate() wls:/base_domain/edit/ !> startPartitionWait(peppart) startEdit() wls:/base_domain/edit/ !> vt.removeTarget(tgt) wls:/base_domain/edit/ !> tgt=getMBean('/Clusters/Cluster-0') wls:/base_domain/edit/ !> vt.addTarget(tgt) wls:/base_domain/edit/ !> activate()
注意:
非ライブ移行中、パーティションのジョブ・スケジューラ・サービスで使用されるデータ・ソースを管理リソース・グループで構成する必要があります。これは、移行前にパーティションが停止したときに管理リソース・グループは停止しないためです。管理リソース・グループの詳細は、「パーティション・リソース・グループでの管理アプリケーションおよびリソースの管理」を参照してください。
パーティション・リソース・グループでの管理アプリケーションおよびリソースの管理
管理対象サーバーおよびクラスタで実行されるアプリケーション・コードに加えて、多数のアプリケーションおよびサービスに管理用とみなされるコンポーネントが含まれています。管理コンポーネントは主に管理サーバー上で実行され、パーティションが停止していても、これらのコンポーネントは実行を継続する必要があります。
管理アプリケーションは、1つ以上のエンド・ユーザー・アプリケーションで使用される一部のサポート・インフラストラクチャを管理します。通常、エンド・ユーザーには管理アプリケーションへのアクセス権はありません。例としては、企業向け製品や部品番号カタログ管理アプリケーションなどがあります。新製品の追加や、製品の販売終了に伴って内部ユーザーがカタログを更新する一方、エンド・ユーザー・アプリケーションは、エンド・ユーザー・トランザクションを実行するときにこのカタログを参照します。管理リソースの例として、カタログ・データが格納されているデータベースにアクセスするためにアプリケーションで使用するJDBCシステム・リソースをあげることができます。
管理アプリケーションおよびリソースが含まれているリソース・グループを管理リソース・グループに指定すると、パーティションを(SHUTDOWN.HALTED
状態からSHUTDOWN.BOOTED
状態にして)ブートしたときに、それらのアプリケーションは使用可能になりますが、エンド・ユーザー向けの非管理アプリケーションは使用可能になりません。パーティションのライフサイクル状態の詳細は、「パーティションのライフサイクル状態および遷移について」を参照してください。
管理リソース・グループの特徴:
-
管理アプリケーションおよびリソースが含まれています。
-
通常は、管理サーバーがターゲットとして指定されます。
-
パーティション・ライフサイクル操作によって独自の方法で処理されます。「パーティションのライフサイクル状態および遷移について」を参照してください。
このリリースでは、次のことが可能です。
-
アプリケーションおよびリソースを管理リソース・グループに配置して、これらを管理用として指定します。
-
パーティションの停止時に、管理アプリケーションおよびリソースの実行を継続します。
-
管理アプリケーションおよびリソースのターゲットとして管理サーバーを自動的に指定します。「管理リソース・グループのターゲット指定」を参照してください。
管理リソース・グループの作成
パーティション管理リソース・グループ内のすべてのアプリケーションおよびリソースは(リソース・グループで直接定義されているか、リソース・グループ・テンプレートを使用して間接的に定義されているかに関係なく)、管理アプリケーションおよびリソースとみなされます。
管理リソース・グループを作成するには、リソース・グループのAdministrative
属性をtrue
に設定します。
WLST編集セッションが進行中で、rg
が対象のResourceGroupMBean
を含む変数であると仮定すると、次のようになります。
rg.setAdministrative(true)
パーティションには、ゼロ個以上の管理リソース・グループを含めることができます。
管理リソース・グループのターゲット指定
他のリソース・グループと同様、管理リソース・グループのターゲットとして、仮想ターゲットまたはパーティションの管理用仮想ターゲット(使用可能である場合)を指定できます。「パーティションの管理用仮想ターゲットについて」を参照してください。
このリリースでは、リソース・グループに新しいブール属性autoTargetAdminServer
があり、これはデフォルトではfalseになっています。システム管理者がこの属性をtrueに設定すると、リソース・グループのターゲットとして管理サーバーが指定され、このことは、パーティションの管理用仮想ターゲットをリソース・グループ・ターゲットとして明示的に追加することと同じです。
WLST編集セッションが進行中で、rg
が対象のResourceGroupMBean
を含む変数であると仮定すると、次のようになります。
rg.setAutoTargetAdminServer(true)
パーティションの管理用仮想ターゲットの詳細は、「パーティションの管理用仮想ターゲットについて」を参照してください。
パーティションのライフサイクル状態および遷移について
パーティション・ライフサイクルの状態を図8-1に示しています。このリリースでは、パーティション・ライフサイクルの状態は変更されていませんが、BOOTED
およびHALTED
の2つのサブ状態がSHUTDOWN
状態に追加されています。
図8-1 パーティション・ライフサイクルの状態
パーティションを停止すると、SHUTDOWN.BOOTED
状態になります。パーティションがSHUTDOWN.BOOTED
状態である場合、管理リソース・グループは実行されていますが、その他すべてのリソース・グループは停止されています。
パーティションがSHUTDOWN.HALTED
状態である場合、パーティションのすべてのリソース・グループは停止されており、パーティションはすべてのターゲット上で完全に停止されています。
新しく作成されるパーティションはSHUTDOWN.HALTED
状態で作成されます。パーティションは、SHUTDOWN.BOOTED
またはSHUTDOWN.HALTED
のいずれかの状態から起動できます。
次の表に、パーティションの作成から実行までの、パーティション・ライフサイクルの状態の考えられるワークフローの1つを示します。
操作 | パーティションの状態 | パーティションのサブ状態 | リソース・グループのアクティビティ |
---|---|---|---|
パーティションの作成 |
|
|
該当せず |
管理リソース・グループおよび非管理リソース・グループの作成 |
|
|
リソース・グループは実行されていません。 |
パーティションおよびリソース・グループのターゲット指定 |
|
|
リソース・グループは実行されていません。 |
パーティションの起動 |
|
|
すべてのリソース・グループが実行されています。 |
パーティションの停止 |
|
|
管理リソース・グループのみが実行されています。 |
パーティションの一時停止 |
|
|
リソース・グループは実行されていません。 |
パーティション構成の変更の中には、有効にするためにパーティションの再起動を必要とするものがあります。このことは、通常、パーティションを停止してから再起動することで行います。管理リソース・グループに対する変更の場合は、パーティションを一時停止してから起動するか、管理リソース・グループを個別に再起動する必要があります。
次の新しいライフサイクル操作がパーティションでサポートされます。
-
halt()
: パーティションはSHUTDOWN.BOOTED
、ADMIN
またはRUNNING
状態からSHUTDOWN.HALTED
状態になります。 -
boot()
: パーティションはSHUTDOWN.HALTED
状態からSHUTDOWN.BOOTED
状態になります。
まとめると、次のようになります。
-
パーティションをブートすると、
SHUTDOWN.HALTED
状態からSHUTDOWN.BOOTED
状態になります。管理アプリケーションのみが実行されています。パーティション管理者はパーティションを管理できますが、エンド・ユーザーはエンド・ユーザー向けアプリケーションにアクセスできません(アプリケーションが実行されていないため)。 -
パーティションを起動すると、
SHUTDOWN
状態(SHUTDOWN.HALTED
またはSHUTDOWN.BOOTED
状態)からRUNNING状態になります。すべてのアプリケーションが実行されています。 -
パーティションを停止すると、
RUNNING
またはADMIN
状態からSHUTDOWN.BOOTED
状態になります。管理アプリケーションが実行されています。パーティション管理者はパーティションを管理できますが、エンド・ユーザーはアプリケーションにアクセスできません。 -
パーティションを一時停止すると、
RUNNING
またはADMIN
状態またはSHUTDOWN.BOOTED
状態からSHUTDOWN.HALTED
状態になります。アプリケーションはパーティションで実行されていません。パーティション管理者はパーティションを管理できません。