| Oracle® Fusion Middleware WebLogic Server Multitenantの使用 12c (12.2.1.3.0) E90313-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
リソース・グループは、アプリケーションとそれらが使用するリソースを、ドメイン内の個別の管理単位にグループ化します。通常、指定されたリソース・グループ内でリソースがなんらかの方法で関連付けられます。たとえば、それらが単一のアプリケーション・スイートを構成します。
リソースとアプリケーションには、それらのリソースを開始したりそれらに接続するために必要なすべての情報(データ・ソースに接続するための資格証明やアプリケーションのターゲット指定情報を含む)があります。リソース・グループにデプロイされたアプリケーションは、起動可能な状態にする必要があります。
リソース・グループは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プロバイダなどの構成が含まれます。
「リソース・グループの構成: 主な手順および例」を参照してください。
この例では、次の操作を実行しています。
ドメイン・パーティションを作成します。
仮想ターゲットを作成します。
仮想ターゲットのホスト名および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)
リソース・グループの構成には、一般設定、デプロイメント・オプション、サービス(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システム・リソースの構成設定を表示するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・グループのJDBC設定の構成に関する項を参照してください。
このリソース・グループで作成されたJDBCシステム・データ・ソースの構成の詳細は、「JDBCの構成」を参照してください。
この項では、次のタスクを取り上げます。
このリソース・グループに作成されたJMSサーバーの構成設定を表示するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJMSサーバー設定の構成に関する項を参照してください。
このリソース・グループで構成されたJMSサーバーの構成の詳細は、「JMSサーバーの構成」を参照してください。
このリソース・グループに作成されたストア・アンド・フォワード(SAF)エージェントの構成設定を表示するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のSAFエージェント設定の構成に関する項を参照してください。
このリソース・グループで構成されたSAFエージェントの構成の詳細は、「ストア・アンド・フォワード・エージェントの構成」を参照してください。
リソース・グループのリソース設定をモニターするには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のSAFエージェント設定の構成に関する項を参照してください。
既存のJMSリソースの構成の詳細は、「JMSシステム・リソースおよびアプリケーション・スコープのJMSモジュールの構成」を参照してください。
リソース・グループのJMSモジュールを構成するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJMSモジュール設定の構成に関する項を参照してください。
既存のJMSモジュールの構成の詳細は、「メッセージング・コンポーネントの構成」を参照してください。
リソース・グループのメッセージング・ブリッジ設定を構成するには、次のようにします。
これらのタスクについては、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のメッセージング・ブリッジの構成に関する項を参照してください。
このリソース・グループで構成されたメッセージング・ブリッジの構成の詳細は、「メッセージング・ブリッジの構成」を参照してください。
リソース・グループの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プロバイダの構成設定を表示するには、次のようにします。
これらのタスクについては、『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の管理』の仮想ターゲットの構成に関する項を参照してください。
実際の仮想ターゲットの構成の詳細は、「仮想ターゲットの構成」を参照してください。
リソース・グループのノートを作成するには、次のようにします。
この例では、次の操作を実行しています。
ドメイン・パーティションを作成します。
仮想ターゲットを作成します。
仮想ターゲットのホスト名および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
リソース・グループを削除する前に、まずそれを停止する必要があります。リソース・グループを停止すると、リソース・グループのアプリケーションとリソースは処理を停止し、メモリーから削除されます。
この例では、次の操作を実行しています。
ドメイン・パーティションを作成します。
仮想ターゲットを作成します。
仮想ターゲットのホスト名および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)
リソース・グループを起動すると、現在実行されていないアプリケーションのデプロイメントとリソースがアクティブになります。リソース・グループを停止すると、リソース・グループのアプリケーションとリソースは処理を停止し、メモリーから削除されます。これは、アプリケーションまたはリソースのアンデプロイと同等のランタイムです。ただし、実際のアンデプロイメントで行われるように、config.xmlファイルからアプリケーションまたはリソースの構成が削除されることはありません。
リソース・グループを制御するには、次のようにします。
リソース・グループの停止
次の例は、「リソース・グループの作成: 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/>
リソース・グループを移行する場合、リソース・グループが使用している仮想ターゲットを、ある物理ターゲット(クラスタまたはサーバー)から別の物理ターゲットに変更します。移行後、仮想ターゲットは新しい物理ターゲット(クラスタまたはサーバー)を参照します。この変更は、この仮想ターゲットを使用しているパーティション・レベルまたはドメイン・レベルのリソース・グループに影響を及ぼします。
Fusion Middleware Controlを使用してリソース・グループを移行するには、次の手順を実行します。
この例では、次の操作を実行しています。
ドメイン・パーティションを作成します。
仮想ターゲットを作成します。
仮想ターゲットのホスト名および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状態になります。アプリケーションはパーティションで実行されていません。パーティション管理者はパーティションを管理できません。
