This chapter includes the following sections:
Traditional Oracle WebLogic Server domains may contain many types of deployable resources: applications, JMS servers and queues, data sources, and such. In this traditional model, if an application suite contains multiple applications and various resources that support those applications, then the administrator defines these resources and deploys these applications individually rather than as a coherent unit.
Resource groups gather together applications and the resources they use into a distinct administrative unit within the domain. Typically, the resources in a given resource group are related in some way. For example, they make up a single application suite.
The resources and applications have all the information needed to start or connect to those resources, including credentials for connecting to a data source and targeting information for applications. Applications deployed to a resource group should be ready to be started.
You can create a resource group in two ways:
Create a new resource group. This creates the basic structure for the resource group. You must then edit this resource group as needed.
Create the new resource group based on a resource group template. (For information about resource group templates, see Configuring Resource Group Templates.) The configuration is copied from the template to the new resource group. You must then edit and override values from the resource group template as needed.
This section describes the following topics:
Resource groups are based on the ResourceGroupMBean
and can include the following resources:
General (name, scope, whether or not based on a resource group template)
Deployments
Services:
JDBC
Messaging
Mail sessions
Persistent stores
Foreign JNDI providers
OSGi frameworks
Diagnostics
Targets
Monitoring features (JDBC, messaging)
Control features (JDBC, messaging, migration)
Notes
Resource overriding lets you customize resources at the partition level. You can override resource settings that are derived from a resource group template.
There are two principal types of overrides:
You can override resource settings for certain resources using resource override configuration MBeans and resource deployment plans.
You can override the default application configuration for applications and modules defined to the resource group template by specifying a different deployment plan. The application or module is then redeployed using the new deployment plan for its application configuration.
For more information about resource overrides, see Configuring Resource Overrides. For information about application overrides, see Deploying Applications to Partition Resource Groups.
You can create resource groups at the domain level, or specific to a domain partition. If you create the resource group at the domain level, then it has a global scope, which is the equivalent of the domain level in a nonpartitioned environment. Applications or classes running at the domain level are available across the domain, but are not available in partitions.
If you create the resource group at the partition level, then it is scoped only to that partition. Applications or classes running at the partition level are available to the partition, but are not available at the domain level or in other partitions.
You can configure a resource group to have more than one virtual target. For example, you might target a resource group to virtual targets for Cluster1
, Cluster2
, and Cluster3
so that the applications in the resource group run on all three clusters.
However, there are two notable restrictions:
Some resource group configurations may have target-specific resources that do not apply across multiple targets. These resources include but are not limited to:
JMS server
Messaging bridge
Path service
JMS bridge destination
File store
JDBC store
JMS system resource
If you try to target a resource group to multiple virtual targets and any one of these resources is present, then WebLogic Server MT generates an error.
You cannot target a resource group to more than one virtual target if the virtual targets target the same physical server.
For example, if resource group RG
targets VT1
and VT2
, and both VT1
and VT2
target Server1
, then WebLogic Server MT generates an error.
To create a new resource group at the partition or global scope:
Go to the partition or the domain level, as needed.
Note the following navigational differences:
If you are using Fusion Middleware Control, you can go to WebLogic Domain > Environment > Resource Groups and create a resource group at either the partition level or domain level.
If you are using the Oracle WebLogic Server Administration Console, go to WebLogic Domain > Environment > Resource Groups to create a resource group at the domain level.
Go to WebLogic Domain > Domain Partitions > Partition > Resource Groups to create a resource group at the partition level.
Create a new resource group.
You can define the following configuration settings for your new resource group:
Enter a name for the new resource group.
Select either partition level or domain level.
Optionally, select a resource group template to use for this new resource group.
Select the targets for this new resource group.
Enter notes for the new resource group.
These tasks are described in "Create resource groups" in Administering Oracle WebLogic Server with Fusion Middleware Control.
If you did not create the resource group from a resource group template, then the initial resource group configuration is a basic skeleton and you must configure it before you can use it. You perform most of the configuration required for a partition when you configure the resource group or resource group overrides. The tasks include configuring JDBC system data sources, JMS servers and resources, foreign JNDI providers, and so forth.
For more information, see Configuring Resource Groups: Main Steps and Examples.
The example does the following:
Creates a domain partition.
Creates a virtual target.
Sets the host name and URI prefix for the virtual target.
Adds the virtual target as an available target in the partition.
Creates the resource group.
Adds the virtual target to the resource group.
Activates the changes.
Starts the partition.
Note:
If this is the first partition created in production mode, then you must restart the Administration Server before you can start the partition.
# 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)
For an example of creating resource groups using REST, see "Creating Partitions" in Administering Oracle WebLogic Server with RESTful Management Services.
In particular, see the section "Create a resource group for the new partition."
This section includes the following tasks:
To view and define general resource group settings:
Select the resource group that you want to configure.
View and define general configuration settings for the resource group, such as:
Name
Scope
Resource Group Template
Save your changes.
These tasks are described in "Configure resource groups general settings" in Administering Oracle WebLogic Server with Fusion Middleware Control.
To view and define resource group deployment settings:
Select the resource group that you want to configure.
You can take the following deployment actions:
Deploy
Redeploy
Undeploy
Fetch deployment plan
Add override
Remove override
Start
Stop
Save your changes.
These tasks are described in "Configure resource group deployment settings" in Administering Oracle WebLogic Server with Fusion Middleware Control.
Deploying an application makes its physical file or directory known to WebLogic Server.
To deploy an application to a resource group:
These tasks are described in "Deploy applications to a resource group" in Administering Oracle WebLogic Server with Fusion Middleware Control.
Redeploying an application redeploys the archive file or exploded directory. Redeploy an application if you have made changes to it and want to make the changes available to WebLogic Server clients.
To redeploy an application or module to a resource group:
These tasks are described in "Redeploy applications to a resource group" in Administering Oracle WebLogic Server with Fusion Middleware Control.
Undeploying an application removes it from every target of the domain to which the application is deployed. After you undeploy an application from the domain, you must deploy it again if you want to make it available to WebLogic Server clients. To temporarily make applications unavailable to WebLogic Server clients, you can stop them instead of undeploying them.
To undeploy an application from a partition resource group:
These tasks are described in "Undeploy applications from a resource group" in Administering Oracle WebLogic Server with Fusion Middleware Control.
This section includes the following tasks:
To view configuration settings for the JDBC system resources that have been created in this resource group:
These tasks are described in "Configure resource group JDBC Settings" in Administering Oracle WebLogic Server with Fusion Middleware Control.
For information about configuring the JDBC system data sources that have been created in this resource group, see Configuring JDBC.
This section includes the following tasks:
To view configuration settings for the JMS servers that have been created for this resource group:
These tasks are described in "Configure JMS Server Settings" in Administering Oracle WebLogic Server with Fusion Middleware Control.
For information about configuring the JMS servers that have been configured in this resource group, see Configuring JMS Servers.
To view configuration settings for the Store-and-Forward (SAF) agents that have been created for this resource group:
These tasks are described in "Configure SAF Agent Settings" in Administering Oracle WebLogic Server with Fusion Middleware Control.
For information about configuring the SAF agents that have been configured in this resource group, see Configuring Store-and-Forward Agents.
To monitor the resource settings for a resource group:
These tasks are described in "Configure SAF Agent Settings" in Administering Oracle WebLogic Server with Fusion Middleware Control.
For information about configuring existing JMS resources, see Configuring JMS System Resources and Application-Scoped JMS Modules.
To configure the JMS modules for a resource group:
These tasks are described in "Configure JMS module settings" in Administering Oracle WebLogic Server with Fusion Middleware Control.
For information about configuring existing JMS modules, see Configuring Messaging Components.
To configure the messaging bridge settings for a resource group:
These tasks are described in "Configure messaging bridges" in Administering Oracle WebLogic Server with Fusion Middleware Control.
For information about configuring the messaging bridges that have been configured in this resource group, see Configuring Messaging Bridges.
To configure the JMS bridge destination settings for a resource group:
These tasks are described in "Configure JMS bridge destinations" in Administering Oracle WebLogic Server with Fusion Middleware Control.
To configure the path services settings for a resource group:
These tasks are described in "Configure path services" in Administering Oracle WebLogic Server with Fusion Middleware Control.
For information about configuring existing path services, see Configuring Path Services to Support Using Unit-of-Order with Distributed Destinations.
To view configuration settings for the mail sessions that have been created in this resource group:
These tasks are described in "WebLogic Server Mail Sessions" in Administering Oracle WebLogic Server with Fusion Middleware Control.
To view configuration settings for the persistent stores that have been created in this resource group:
These tasks are described in "WebLogic Server Persistent Stores" in Administering Oracle WebLogic Server with Fusion Middleware Control.
For information about configuring existing persistent stores, see Configuring JDBC or File Persistent Stores.
To view configuration settings for the foreign JNDI providers that have been created in this resource group:
These tasks are described in "WebLogic Server Foreign JNDI Providers" in Administering Oracle WebLogic Server with Fusion Middleware Control.
For information about configuring existing foreign JNDI providers, see Configuring and Programming JNDI.
To view configuration settings for the diagnostic system modules that have been created in this resource group:
These tasks are described in "WebLogic Server Diagnostics" in Administering Oracle WebLogic Server with Fusion Middleware Control.
For information about configuring existing diagnostic system modules, see Monitoring and Debugging Partitions.
To specify the targets for this resource group:
These tasks are described in "Configure virtual targets" in Administering Oracle WebLogic Server with Fusion Middleware Control.
For information about configuring the actual virtual target, see Configuring Virtual Targets.
To create notes for a resource group:
The example does the following:
Creates a domain partition.
Creates a virtual target.
Sets the host name and URI prefix for the virtual target.
Adds the virtual target as an available target in the partition.
Creates the resource group.
Adds the virtual target to the resource group.
Activates the changes.
Starts the partition.
Note:
If this is the first partition created in production mode, then you must restart the Administration Server before you can start the partition.
Deploys the application MySimpleEjb
to the resource group.
# 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
For an example of configuring resource groups using REST, see "Creating Partitions" in Administering Oracle WebLogic Server with RESTful Management Services.
In particular, see the sections "View the new partition's resource groups" and "Demonstrate a partition deployer configuring system resources."
You must first stop a resource group before you can delete it. Stopping the resource group causes applications and resources in the resource group to cease operating and to be removed from memory.
The example does the following:
Creates a domain partition.
Creates a virtual target.
Sets the host name and URI prefix for the virtual target.
Adds the virtual target as an available target in the partition.
Creates the resource group.
Adds the virtual target to the resource group.
Unsets the resource group.
Deletes the resource group.
Creates a different resource group.
Adds the virtual target to that resource group.
Activates the changes.
Starts the partition.
Note:
If this is the first partition created in production mode, then you must restart the Administration Server before you can start the partition.
# 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)
To control a resource group:
Stopping a Resource Group
The following example builds on the WLST example shown in Creating Resource Groups: WLST Example. It shows navigation to the ResourceGroupLifeCycleRuntime
MBean and stops the resource group 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
Starting a Resource Group
The following example builds on the WLST example shown in Creating Resource Groups: WLST Example. It shows navigation to the ResourceGroupLifeCycleRuntime
MBean and starts the resource group 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/>
When you migrate a resource group, you change the virtual target used by the resource group from one physical target (cluster/server) to another. After migration, the virtual target points to the new physical target (cluster/server).
Note that this change affects any partition-level or domain-level resource group that uses this virtual target.
To use Fusion Middleware Control to migrate a resource group:
The example does the following:
Creates a domain partition.
Creates a virtual target.
Sets the host name and URI prefix for the virtual target.
Targets the virtual target to the Administration Server. (You would typically not target the virtual target to the Administration Server.)
Adds the virtual target as an available target in the partition.
Creates the resource group.
Adds the virtual target to the resource group.
Activates the changes.
Starts the partition.
Note:
If this is the first partition created in production mode, then you must restart the Administration Server before you can start the partition.
Removes the Administration Server as a target.
Migrates (targets) the virtual target to 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()
Note:
During non-live migration, the data source used for the partition job scheduler service should be configured in an administrative resource group, meaning that it is not shut down when the partition is shutdown, before the migration. For more information about administrative resource groups, see Managing Administrative Applications and Resources in Partition Resource Groups.
In addition to application code that runs on Managed Servers and clusters, many applications and services include components that are considered administrative. Administrative components primarily run on the Administration Server, and even when a partition is shutdown, it is required that these components continue to run.
An administrative application manages some supporting infrastructure used by one or more end-user applications. Typically, end users do not have access to administrative applications. An example might be a corporate product and part number catalog maintenance application. Internal users would update the catalog as products come and go, while end-user applications would refer to the catalog as they run end-user transactions. The JDBC system resource that the application uses to access the database where the catalog data is stored would be an example of an administrative resource.
If you designate the resource group containing administrative applications and resources an administrative resource group, then when you boot the partition (moving it from the SHUTDOWN.HALTED
to the SHUTDOWN.BOOTED
state) those applications will be available but none of the non-administrative, end-user-facing applications will be. For more information about the partition lifecycle states, see About Partition Lifecycle States and Transitions.
Administrative resource groups:
Contain administrative applications and resources.
Are usually targeted to the Administration Server.
Are handled in a unique manner by partition life cycle operations. For more information, see About Partition Lifecycle States and Transitions.
In this release, you can:
Designate applications and resources as administrative by placing them in an administrative resource group.
Keep administrative applications and resources running when the partition is shutdown.
Target administrative applications and resources to the Administration Server automatically. For more information, see Targeting Administrative Resource Groups.
All applications and resources in a partition administrative resource group (whether defined directly in the resource group or indirectly through a resource group template) are considered administrative applications and resources.
To create an administrative resource group, set the resource group Administrative
attribute to true
.
Assuming that you have a WLST edit session in progress and rg
is a variable containing the ResourceGroupMBean
of interest:
rg.setAdministrative(true)
You may have zero or more administrative resource groups in a partition.
You can target administrative resource groups like any other resource group, to a virtual target or the partition administrative virtual target, assuming it is available. For more information, see About Partition Administrative Virtual Targets.
In this release, resource groups have a new boolean attribute, autoTargetAdminServer
, that by default, is false. When system administrators set this attribute to true, they target the resource group to the Administration Server, the same as explicitly adding the partition administrative virtual target as a resource group target.
Assuming that you have a WLST edit session in progress and rg
is a variable containing the ResourceGroupMBean
of interest:
rg.setAutoTargetAdminServer(true)
For more information about partition administrative virtual targets, see About Partition Administrative Virtual Targets.
The partition lifecycle states are shown in Figure 8-1. In this release, the partition lifecycle states are unchanged, but two substates have been added to the SHUTDOWN
state: BOOTED
and HALTED
.
Figure 8-1 Partition Lifecycle States
Shutting down a partition takes it to the SHUTDOWN.BOOTED
state. When a partition is in the SHUTDOWN.BOOTED
state, administrative resource groups are running, but all other resource groups are shutdown.
When a partition is in the SHUTDOWN.HALTED
state, all resource groups in the partition are shutdown and the partition is fully shutdown on all targets.
Newly created partitions are created in the SHUTDOWN.HALTED
state. You can start a partition from either the SHUTDOWN.BOOTED
or the SHUTDOWN.HALTED
state.
The following table shows one possible workflow of partition lifecycle states going from partition creation to running.
Operation | Partition State | Partition Substate | Resource Group Activity |
---|---|---|---|
Create partition |
|
|
NA |
Create administrative resource groups and non-administrative resource groups |
|
|
No resource groups are running |
Target partition and resource groups |
|
|
No resource groups are running |
Start partition |
|
|
All resource groups are running |
Shut down partition |
|
|
Only administrative resource groups are running |
Halt partition |
|
|
No resource groups are running |
Some partition configuration changes require a partition restart to have them applied. That is typically done by shutting down the partition and then restarting it. For changes to administrative resource groups, the partition must be halted and then started or the administrative resource group must individually be restarted.
The following new lifecycle operations are supported on a partition:
halt()
: takes a partition from the SHUTDOWN.BOOTED
, ADMIN
, or RUNNING
state to the SHUTDOWN.HALTED
state.
boot()
: takes a partition from the SHUTDOWN.HALTED
state to the SHUTDOWN.BOOTED
state.
In summary:
Booting a partition takes it from the SHUTDOWN.HALTED
state to the SHUTDOWN.BOOTED
state. Only the administrative applications are running. Partition administrators can manage the partition but end users cannot access the end-user-facing applications (because they are not running).
Starting a partition takes it from the SHUTDOWN
state (either the SHUTDOWN.HALTED
or the SHUTDOWN.BOOTED
state) to running. All applications are running.
Shutting down a partition takes it from the RUNNING
or ADMIN
state to the SHUTDOWN.BOOTED
state. Administrative applications are running. Partition administrators can manage the partition; end users cannot access applications.
Halting a partition takes it from the RUNNING
or ADMIN
state or the SHUTDOWN.BOOTED
state to the SHUTDOWN.HALTED
state. No applications are running in the partition. Partition administrators cannot manage the partition.