1. Using Oracle WebLogic Server Multitenant (Deprecated)
  2. Configuring Resource Groups

8 Configuring Resource Groups

You perform most of the configuration required for a partition when you configure its resource groups or resource group overrides. The tasks include configuring JDBC system data sources, JMS servers and resources, foreign JNDI providers, and such.

Note:

WebLogic Server Multitenant domain partitions, resource groups, resource group templates, virtual targets, and Resource Consumption Management are deprecated in WebLogic Server 12.2.1.4.0 and will be removed in the next release.

This chapter includes the following sections:

Configuring Resource Groups: Overview

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.

What Is in a Resource Group?

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 Groups and Overrides

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.

Resource Groups in Global Scope and Partitions

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.

Targeting a Resource Group to More Than One Target

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.

Creating Resource Groups: Main Steps and Examples

You can create a resource group in two ways: create a new resource group or create the resource group based on a resource group template.

Creating a new resource group creates the basic structure for the resource group. You must then edit this resource group as needed. Whereas, when creating a resource group from a resource group template, 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. For information about resource group templates, see Configuring Resource Group Templates.

To create a new resource group at the partition or global scope:

  1. 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.

  2. Create a new resource group.

  3. 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.

See Configuring Resource Groups: Main Steps and Examples.

Creating Resource Groups: WLST Example

The example does the following:

  1. Creates a domain partition.

  2. Creates a virtual target.

  3. Sets the host name and URI prefix for the virtual target.

  4. Adds the virtual target as an available target in the partition.

  5. Creates the resource group.

  6. Adds the virtual target to the resource group.

  7. Activates the changes.

  8. 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)

Creating Resource Groups: REST Example

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."

Configuring Resource Groups: Main Steps and Examples

Configuring resource groups may include several tasks, such as specifying general settings, deployment options, services, such as JDBC, JMS, mail sessions, persistent stores, and foreign JNDI providers, and specifying the targets for the resource groups.

Configuring Resource Group General Settings

To view and define general resource group settings:

  1. Select the resource group that you want to configure.

  2. View and define general configuration settings for the resource group, such as:

    • Name

    • Scope

    • Resource Group Template

  3. Save your changes.

These tasks are described in Configure resource groups general settings in Administering Oracle WebLogic Server with Fusion Middleware Control.

Configuring Resource Group Deployment Settings

To view and define resource group deployment settings:

  1. Select the resource group that you want to configure.

  2. You can take the following deployment actions:

    • Deploy

    • Redeploy

    • Undeploy

    • Fetch deployment plan

    • Add override

    • Remove override

    • Start

    • Stop

  3. Save your changes.

These tasks are described in Configure resource group deployment settings in Administering Oracle WebLogic Server with Fusion Middleware Control.

Deploying Applications to a Resource Group

Deploying an application makes its physical file or directory known to WebLogic Server.

To deploy an application to a resource group:

  1. Select the resource group that you want to configure.
  2. Locate the application that you want to deploy and choose whether to upload a deployment plan or create a new deployment plan.
  3. Update the application attributes as desired. These attributes include:

    • Application name

    • Distribution

    • Source accessibility

  4. Deploy the application.
  5. Update the deployment settings or complete the deployment of this application.

These tasks are described in Deploy applications to a resource group in Administering Oracle WebLogic Server with Fusion Middleware Control.

Redeploying Applications to a Resource Group

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:

  1. Select the resource group that you want to configure.
  2. Select the application that you want to redeploy.
  3. Decide whether to upload a deployment plan or to create a new deployment plan.
  4. Update the application distribution as needed.
  5. Optionally, edit the deployment plan to set more advanced deployment options, and save the deployment plan to your local disk.
  6. Redeploy the application to complete redeployment of this application.

These tasks are described in Redeploy applications to a resource group in Administering Oracle WebLogic Server with Fusion Middleware Control.

Undeploying Applications from a Resource Group

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:

  1. Select the resource group that you want to configure.
  2. Select the application that you want to undeploy from the deployed applications.
  3. Undeploy the application.
  4. If you later want to deploy the removed application, see Deploying Applications to a Resource Group.

These tasks are described in Undeploy applications from a resource group in Administering Oracle WebLogic Server with Fusion Middleware Control.

Configuring Resource Group Services Settings

This section includes the following tasks:

Configuring Resource Group JDBC Settings

To view configuration settings for the JDBC system resources that have been created in this resource group:

  1. Select the resource group that you want to configure.
  2. Go to Services > JDBC.

    The read-only JDBC information for a resource group includes:

    • Name

    • JNDI name

    • Type

    • Targets

    • Algorithm type

    • Row prefetch enabled

    • Row prefetch size

    • Stream chunk size

  3. Create or delete the system data sources as needed.
  4. Save your changes.

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.

Configuring Resource Group JMS settings
Configuring JMS Server Settings

To view configuration settings for the JMS servers that have been created for this resource group:

  1. Select the resource group that you want to configure.
  2. Go to Services > Messaging > JMS Servers.

    The following read-only information is available for JMS servers already configured in this resource group:

    • Name

    • Health

    • Health reason

    • Persistent store

    • Temporary template name

    • Bytes maximum

    • Messages maximum

    • Bytes threshold high

    • Bytes threshold low

    • Messages threshold high

  3. Create or delete JMS servers as needed.
  4. Save your changes.

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.

Configuring SAF Agent Settings

To view configuration settings for the Store-and-Forward (SAF) agents that have been created for this resource group:

  1. Select the resource group that you want to configure.
  2. Go to Services > Messaging > SAF Agents.

    The following read-only information is available for the SAF agents configured in this resource group:

    • Name

    • Agent type

    • Persistent store

  3. Create or delete SAF agents as needed.
  4. Save your changes.

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.

Configuring JMS Resource Settings

To monitor the resource settings for a resource group:

  1. Select the resource group that you want to configure.
  2. Go to Services > Messaging > JMS Resources.

    The following read-only information is available for the JMS resources configured in this resource group:

    • Name

    • Type

    • JMS module name

    • JNDI name

    • Subdeployment

  3. Create or delete JMS resources as needed.
  4. Save your changes.

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.

Configuring JMS Module Settings

To configure the JMS modules for a resource group:

  1. Select the resource group that you want to configure.
  2. Go to Services > Messaging > JMS Modules > JMS Modules.

    The following read-only information is available for the JMS modules configured in this resource group:

    • Name

    • Queues

    • Topics

    • Connection factories

    • Distributed queues

    • Distributed topics

    • Foreign servers

    • Quotas

    • SAF error handlers

    • SAF imported destinations

    • SAF remote contexts

    • Templates

    • Uniform distributed queues

    • Uniform distributed topics

    • Destination keys

    • Type

  3. Create or delete JMS modules as needed.
  4. Save your changes.

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.

Configuring Messaging Bridges

To configure the messaging bridge settings for a resource group:

  1. Select the resource group that you want to configure.
  2. Go to Services > Messaging > Messaging Bridges.

    The following read-only information is available for the messaging bridges configured in this resource group:

    • Name

    • Source bridge destination

    • Target bridge destination

  3. Create or delete messaging bridges as needed.
  4. Save your changes.

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.

Configuring JMS Bridge Destinations

To configure the JMS bridge destination settings for a resource group:

  1. Select the resource group that you want to configure.
  2. Go to Services > Messaging > Bridge Destinations.

    The following read-only information is available for the JMS bridge destinations configured in this resource group:

    • Name

    • Adapter JNDI name

  3. Create or delete JMS bridge destinations as needed.
  4. Save your changes.

These tasks are described in Configure JMS bridge destinations in Administering Oracle WebLogic Server with Fusion Middleware Control.

Configuring Path Services

To configure the path services settings for a resource group:

  1. Select the resource group that you want to configure.
  2. Go to Services > Messaging > Path Services.

    The following read-only information is available for the path services configured in this resource group:

    • Name

    • Persistent store

  3. Create or delete path services as needed.
  4. Save your changes.

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.

Configuring Resource Group Mail Session Settings

To view configuration settings for the mail sessions that have been created in this resource group:

  1. Select the resource group that you want to configure.
  2. Go to Services > Mail.

    The following read-only information is available for mail sessions configured in this resource group:

    • Name

    • JNDI name

  3. Create or delete mail sessions as needed.
  4. Save your changes.

These tasks are described in WebLogic Server Mail Sessions in Administering Oracle WebLogic Server with Fusion Middleware Control.

Configuring Resource Group Persistent Store Settings

To view configuration settings for the persistent stores that have been created in this resource group:

  1. Select the resource group that you want to configure.
  2. Go to Services > Persistent Stores.

    The following read-only information is available for the persistent stores configured in this resource group:

    • Name

    • Type

  3. Create or delete persistent stores as needed.
  4. Save your changes.

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.

Configuring Resource Group Foreign JNDI Provider Settings

To view configuration settings for the foreign JNDI providers that have been created in this resource group:

  1. Select the resource group that you want to configure.
  2. Go to Services > Foreign JNDI Providers.

    The following read-only information is available for the foreign JNDI providers configured in this resource group:

    • Name

    • Initial context factory

    • Provider URL

    • User

    • Targets

  3. Create or delete foreign JNDI providers as needed.
  4. Save your changes.

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.

Configuring Resource Group Diagnostic System Module Settings

To view configuration settings for the diagnostic system modules that have been created in this resource group:

  1. Select the resource group that you want to configure.
  2. Go to Services > Diagnostics.

    The following read-only information is available for the diagnostic system modules configured in this resource group:

    • Name

    • Description

    • Targets

  3. Create or delete diagnostic system modules as needed.
  4. Save your changes.

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.

Configuring Resource Group Targets

To specify the targets for this resource group:

  1. Select the resource group that you want to configure.
  2. Go to Targets.
  3. Specify one or more virtual targets to which this resource group is targeted.

    For important considerations when targeting a resource group to more than one virtual target, see Targeting a Resource Group to More Than One Target.

    A virtual target can be used by many resource groups within a partition, or by many resource groups at the domain level.

  4. Save your changes.

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.

Configuring Resource Group Notes

To create notes for a resource group:

  1. Select the resource group that you want to configure.
  2. Go to Notes.
  3. Enter your notes.
  4. Save your changes.

Configuring Resource Groups: WLST Example

The example does the following:

  1. Creates a domain partition.

  2. Creates a virtual target.

  3. Sets the host name and URI prefix for the virtual target.

  4. Adds the virtual target as an available target in the partition.

  5. Creates the resource group.

  6. Adds the virtual target to the resource group.

  7. Activates the changes.

  8. 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.

  9. 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

Configuring Resource Groups: REST Example

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."

Deleting Resource Groups: Main Steps and WLST Example

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.

  1. Select the resource group that you want to delete.
  2. Go to Control > Stop. You should generally choose to stop the resource group when work completes.
  3. Stop the resource group.
  4. Delete the resource group.

Deleting Resource Groups: WLST Example

The example does the following:

  1. Creates a domain partition.

  2. Creates a virtual target.

  3. Sets the host name and URI prefix for the virtual target.

  4. Adds the virtual target as an available target in the partition.

  5. Creates the resource group.

  6. Adds the virtual target to the resource group.

  7. Unsets the resource group.

  8. Deletes the resource group.

  9. Creates a different resource group.

  10. Adds the virtual target to that resource group.

  11. Activates the changes.

  12. 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)

Controlling Resource Groups: Main Steps and WLST Example

Starting a resource group causes application deployments and resources that are not currently running to become active. Stopping a resource group causes applications and resources in the resource group to cease operating and to be removed from memory. It is the runtime equivalent to undeploying the application or resource, except that the configuration for the application or resource is not removed from the config.xml file as it would be in a true undeployment.

To control a resource group:

  1. Select the resource group that you want to configure.
  2. Go to Control.

    You can perform the following actions:

    • Start

    • Stop

Controlling Resource Groups: WLST Example

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/>

Migrating Resource Groups: Main Steps and WLST Example

When you migrate a resource group, you change the virtual target used by the resource group from one physical target (cluster or server) to another. After migration, the virtual target points to the new physical target (cluster or 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:

  1. From the WebLogic Domain menu, select Environment, then select Resource Groups.

    The Resource Groups table displays information about each resource group that has been configured in the current domain.

  2. In the Resource Groups table, select the resource group that you want to configure.
  3. Go to Migrate.
  4. Choose a new target for the virtual target associated with the resource group. You can choose a single Managed Server or a single cluster.
  5. Save your changes.

Migrating Resource Groups: WLST Example

The example does the following:

  1. Creates a domain partition.

  2. Creates a virtual target.

  3. Sets the host name and URI prefix for the virtual target.

  4. Targets the virtual target to the Administration Server. (You would typically not target the virtual target to the Administration Server.)

  5. Adds the virtual target as an available target in the partition.

  6. Creates the resource group.

  7. Adds the virtual target to the resource group.

  8. Activates the changes.

  9. 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.

  10. Removes the Administration Server as a target.

  11. 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.

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:

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. See Targeting Administrative Resource Groups.

Creating 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.

Targeting Administrative Resource Groups

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. 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.

About Partition Lifecycle States and Transitions

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

This figure shows the partition lifecyle 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

SHUTDOWN

HALTED

NA

Create administrative resource groups and non-administrative resource groups

SHUTDOWN

HALTED

No resource groups are running

Target partition and resource groups

SHUTDOWN

HALTED

No resource groups are running

Start partition

RUNNING

NA

All resource groups are running

Shut down partition

SHUTDOWN

BOOTED

Only administrative resource groups are running

Halt partition

SHUTDOWN

HALTED

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.

Configuring Resource Groups: Related Tasks and Links