Lina Xu's Blog

Lina Xu's Homepage
Lina Xu is a Senior Software Engineer at BEA Systems in the System Test team. For the past 6 years she has worked on various projects including WebLogic Server, Core Engine, WLS-VE and currently working on WLOC (WebLogic Operations Control). She graduated from University of Massachusetts Lowell where she received a Masters of Computer Science degree.

Lifecycle of the Services Managed by WLOC

In the first blog, I mentioned service transitioning states such as starting, stopping, staging and destroying in deployment-state-constraint description. I realized the service lifecycle could be confusing for new users, hopefully this blog entry could be helpful :)

Service Lifecycles

The diagram above demonstrates the service lifecycles in WLOC, as we can see, each service has 3 lifecycle states "undeployed", "staged", "deployed", and 4 transitioning states "staging", "starting", "stopping" and "destroying".

• undeployed: Services in this state has nothing created or running, that's the initial state after the service is created.
• staged: This stage is created mainly for WLS-VE instances that are running on VMware ESX server. For WLS-VE1.1 instances, the VMs can be created on virtual disk on ESXServer, and the virtual hard disk is a .vmdk file. When a WLS-VE1.1 instance starts, a two-step process is involved. First, a .vmdk file is created and allocated to the virtual machine, then we can populate the virtual disk and start the virtual machine. Similarly, when shutting down the virtual machine, first the virtual machine is stopped, and then we can destroy the virtual machine meaning removing the .vmdk file. Having "staged" as an interim state is important as it allows us to keep the .vmdk file in scenarios such as populating the virtual disk by copying file from other places before virtual machine's initial boot, or having runtime information of the virtual machines that could be modified and reused when later the virtual machine is restarted.
• deployed: Services in this state has all the required instances created and running.

I don't think I need to explain more about the other "staging", "starting", "stopping" and "destroying" states, they reflect the states of the services transitioning between lifecycle states, the above diagram clearly says it.

deployment-state-constraint

So here is a re-visit of the deployment-state-constraint described before, we can define deployment-state-constraint with different transitioning states and bind it with different service action. So for example, I have the following constraint bindings defined for LOC-service1 which is in "undeployed" state:

<ns2:constraint-binding>
    <ns2:constraint-key>LOC-service1stage-constraint-key</ns2:constraint-key>
    <ns2:action-key>service-stage-action</ns2:action-key>
</ns2:constraint-binding> 
<ns2:constraint-binding>
    <ns2:constraint-key>LOC-service1deploy-key</ns2:constraint-key>
    <ns2:action-key>LOC-service1startserviceaction</ns2:action-key>
</ns2:constraint-binding> 
<ns2:deployment-state-constraint>
    <ns2:name>LOC-service1stage-constraint</ns2:name>
    <ns2:key>LOC-service1stage-constraint-key</ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>staging</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
</ns2:deployment-state-constraint>
<ns2:deployment-state-constraint>
    <ns2:name>LOC-service1-service-deploy</ns2:name>
    <ns2:key>LOC-service1deploy-key</ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>starting</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
</ns2:deployment-state-constraint> 
<ns2:action>
    <ns2:name>service-stage-action</ns2:name>
    <ns2:key>service-stage-action</ns2:key>
    <ns2:impl-class>com.bea.adaptive.actions.internal.StageServiceAction</ns2:impl-class>
    <ns2:adjudicate>false</ns2:adjudicate>
    <ns2:properties/>
</ns2:action> 
<ns2:action>
    <ns2:name>LOC-service1startserviceaction</ns2:name>
    <ns2:key>LOC-service1startserviceaction</ns2:key>
    <ns2:impl-class>com.bea.adaptive.actions.internal.StartServiceAction</ns2:impl-class>
    <ns2:adjudicate>false</ns2:adjudicate>
    <ns2:properties/>
</ns2:action> 

When WLOC receives a command to start this LOC-service1, it first executes the StageServiceAction to transition the service from "undeployed" state to "staged" state; and then it executes StartServiceAction to transition the service from "staged" state to "deployed" state.

Remember these constraints are not required, if they are not defined, WLOC will implicitly execute the actions. So in the above example, if there is no deployment-state-constraint, WLOC will first execute the StageServiceAction and then StartServiceAction just like they were defined. In fact, most of the time you don't define those constraints, the scenarios where you want to explicitly define those constraints are when you want to override the default actions such as StageServiceAction/StartServiceAction with a custom pipeline or when you want to set a property on those actions.

Console Deployment

From the service table in WLOC console, there are four operations that can be applied to each service to move service into a different state:

• Stage: WLOC will create .vmdk file for the WLS-VE instances, and put the service from "undeployed" to "staged" state; for the plain WLS instances, this is a noop, WLOC simply puts the service into "staged" and does nothing else.
• Start: WLOC will try to put the service into "deployed" state.
  • If the service is in "staged" state, WLOC will directly start the required instances in the service and put it into target "deployed" state.
  • If the service is in "undeployed" state initially, WLOC will implicitly run the StageServiceAction to put the service into "staged" state first, and then start all the required instances in the service and put it into target "deployed" state.
• Stop: WLOC will stop all the instances in the service that's in "deployed" state, and put the service into a "staged" state. Note that for WLS-VE instances that on virtual disk, the .vmdk files will be kept.
• Unstage: WLOC will try to put the service into the initial "undeployed" state
  • If the service is in "staged" state, for WLS-VE instances, WLOC will run the DestroyServiceAction to remove the .vmdk file and put the service into "undeployed" state. For the plain WLS instances, this is a noop, WLOC simply puts the service back into "undeployed" state and does nothing else.
  • If the serivce is in "deployed" state, WLOC will implicitly run the StopServiceAction to shutdown all the instances and put the service into "staged" state first, and then run the DestroyServiceAction to remove the .vmdk file if necessary.

How to Configure WLOC Components to Manage WLS-VE Instances

We have pretty detailed use case examples on how to configure WLOC from scratch to manage WebLogic Server instances in a non-virtualization environment, I myself found some configuration in WLOC to manage WLS-VE (WebLogic Server Virtual Edition, versions 1.0 and 1.1) instances is more complicated and I'd like to talk about some of it in this blog entry.

Configure ESX Agent

Connection to Virtual Center

To configure ESX agent for WLS-VE, we need to pre-define the 'Data Center", "Compute Resource" and "Resource Pools" in VMware Virtual Center that the agent will communicate with. WLOC agent configuration wizard provides this nice dynamic configuration support that allows us to enter the VMware Virtual Center identification and it will connect to it and automatically retrieve these information, so we don't have to manually type in all the data.

Note: On the step of connecting to the Virtual Center in the WLOC agent configuration wizard, we have the option to either use secure or non-secure connection depending on whether the Virtual Center has been configured on listening to unsecured web service. By default the Virtual Center is configured with secure web services on port 443, but sometimes for development environment, the Virtual Center is configured to support non-SSL HTTP connection as well, in that case you can just use the non-secure connection. To enable the non-SSL HTTP connection in Virtual Center, follow the VMware instructions, on section "Modifying the Server Configuration to Support HTTP".

ISO software

WLOC agent configuration wizard requires us to configure at least one ISO software availability during agent configuration time. This ISO software specifies the location of the required ISO image (reside on the local disk of the hypervisor's host machine, SAN, or NAS) that has the required software for the Virtual Machine to start up. In WLS-VE case, this ISO image contains the WebLogic Server 9.2 classes and LiquidVM executables. Note that the ISO images for WLS-VE 1.0 and WLS-VE 1.1 are different, so we'll need to define two different ISO softwares if we have mixed WLS-VE end points.

Here is a snapshot of configuring the ISO software in the wizard for WLS-VE1.0 and WLS-VE1.1 (WLSVE921-ISO and WLSVE922-ISO):

Note: You can also configure ISO softwares in WLOC console.

NFS software

In WLS-VE1.0, NFS is required to read and write domain/application configuration files, log files, etc, while in WLS-VE1.1 the NFS dependency is removed with the "Virtual Local Disk" feature, we may still want to copy over the config.xml, security files, application files or the license file, etc from the NFS mounts to WLS-VE1.1 file system on local disk. In order for the agents to surface the mount points topology to be used, we need to configure the NFS software availability for the NFS mount points where those files are located.

Besides the NFS mount points described above, I normally define another NFS software availability to override the stdout location for WLS-VE1.1 instances. By default, there is no stdout directory specified for the WLS-VE1.1 instances, so the stdout files go to the working directory of the instances which is in their file system on the local disk. While we are recommended to use ssh to retrieve the files for security purpose, I found it's not easy to use especially when the instance starts abnormally and shutdown immediately during initial boot, I have no idea what could have gone wrong when it happens as the instance has already shut down and using ssh won't work. So if we are in the stage of setting up the domain and testing it, I would recommend to override the stdout directory temporarily to be on NFS, and change it to be on local disk later in production. To do that, we can create the NFS software availability for the stdout NFS mount point, and then override the stdout location in the agent configuration with the NFS mount name in WLOC console at: Agents (tab) > your_esx_agent_name_in_the_table > Resource Pool (tab) > General (tab) > Standard Out Directory.

Here is a snapshot of configuring the NFS mounts availability for the WLS domain and stdout directory in the WLOC configuration wizard:

Note: You can also configure NFS softwares in WLOC console.

For the rest of detailed information of ESX Agent configuration, please check the WLOC edoc site.

Service Configuration

Once we've configured the ESX agent and WLOC controller, we can proceed to create the service definition from WLOC console. I'll skip the most steps as the use case examples describe it in great detail, the following two areas have configuration specific to the WLS-VE case and I think are worth bringing up.

JVM Metadata Configuration

• Classpath: The classpath has all the required classes for the VM to run. For WLS-VE instances, remember that the classes are WebLogic Server 9.2 classes and LiquidVM executables that are located in the ISO image, so the classpath should follow the path structure in the ISO image, the following is one example of the classpath of WLS-VE instance, note they are located under "/appliance/...".

/appliance/bea/weblogic92/server/lib/weblogic_sp.jar:/appliance/java/lib/tools.jar:/appliance/bea/weblogic92/server/lib/weblogic.jar:/appliance/bea/weblogic92/server/lib/webservices.jar

 

It can also contain the patch classes that could be either in NFS or local disk (in WLS-VE1.1):

/nfsDomainDir/patch_weblogic921/profiles/default/sys_manifest_classpath/weblogic_patch.jar:/appliance/java/lib/tools.jar:/appliance/bea/weblogic92/server/lib/weblogic.jar:/appliance/bea/weblogic92/server/lib/webservices.jar:

Note: "/nfsDomainDir" in the above example is a reference to the software availability for the NFS software mount point ("/domain") created during agent configuration, I'll explain it more in the following "software-constraint" bullet.

• Instance Directory: It is the working directory of the WLS-VE instances where the configuration files, security files, etc. are stored, it is also the location where the stdout files of the instances will go to if the "stdout" property is not specified in the agent configuration. For WLS-VE1.0 instances, the "instance-dir" is the NFS mount point for the WebLogic Server domain; and for WLS-VE1.1 instances, the "instance-dir" could be anywhere in the file system on the virtual local disk, and if the configuration files, security files, license file etc. need to be pre-populated under "instance-dir" before the instances boot, we can copy them over when the instances are created and virtual local disk is initialized, WLOC provides this copies configuration on the software-constraint and on the JVM instance, the difference is the copies configuration on the software-constraint applies to entire process group where the constraint is bound to, while the copies configuration on the JVM instance definition only applies to that JVM. See below "software-constraint".

In the following example for WLS-VE1.0 instance, the instance directory "/nfsDomainDir" refers to the software availability for the NFS software mount point ("/domain") created during agent configuration:

<ns2:instance-dir>/nfsDomainDir</ns2:instance-dir>

Here the instance directory "/esxDomainDir" is a directory in the file system on WLS-VE1.1 instance's local disk:

<ns2:instance-dir>/esxDomainDir</ns2:instance-dir>

• "bea.home" in JVM Args: If we want to override the WLS-VE evaluate license in the ISO image, we can specify in the JVM arguments "-Dbea.home" where the desired license file will be loaded.

For WLS-VE1.0 instances, the license file has to be located on NFS:

<ns2:arg>-Dbea.home=/nfsDomainDir/licenses</ns2:arg>

For WLS-VE1.1 instances, the license file could be on the local disk, and to use it on local disk, as I mentioned above, we need to copy the license file over during instance creation time, and the copies configuration can be specified on the software-constraint definition.  See below "software-constraint".

<ns2:arg>-Dbea.home=/esxDomainDir/licenses</ns2:arg>

Policy Configuration

After the services are created, we can define policies on them, each policy consists of a constraint and an action/pipeline. WLOC defines the software requirement in the form of constraints, and those constraints must be bound to an internal action whose value is INTERNAL. These constraints are used for JVM placement, so the WLS-VE instances that have the ISO/NFS software dependencies will not be able to be created/started if any of these constraints is not met. So for those instances, we must define the following constraints:

• iso-constraint: The constraints for the ISO software availability created during agent configuration.

<ns2:iso-constraint>
    <ns2:name>WLSVE922-iso</ns2:name>
    <ns2:key>WLSVE922-iso</ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>deployed</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
    <ns2:iso-name>WLSVE922-ISO</ns2:iso-name>
    <ns2:copies-at-create/>
</ns2:iso-constraint>

Note:

1. "iso-name" should match the name entered during ISO software configuration in agent wizard, in my example, it is "WLSVE922-ISO". See the following snippet from agent configuration:

   <iso-software>
         <name>WLSVE922-ISO</name>
         <description>WLSVE922-ISO</description>
         <path>[NFS-Storage] wlsve922.iso</path>
         <version>1.1</version>
   </iso-software>

2. We can do copies configuration here (copies-at-create) to copy files from the read-only ISO image to the file system on local disk (for WLS-VE1.1 instances).

• software-constraint: The constraints for the NFS software availability created during agent configuration.

<ns2:software-constraint>
    <ns2:name>domains922-root-software-constraint</ns2:name>
    <ns2:key>domains922-root-software-constraint</ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>deployed</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
    <ns2:software-name>/domainRoot</ns2:software-name>
    <ns2:software-mount-point>domain922</ns2:software-mount-point>
    <ns2:copies-at-create>
        <ns2:copy>
            <ns2:from>/licenses/license.bea</ns2:from>
            <ns2:to>/esxDomainDir/licenses/license.bea</ns2:to>
        </ns2:copy>
    </ns2:copies-at-create>
    <ns2:copies-at-shutdown/>
</ns2:software-constraint>

Note:

1. <software-name> "/domainRoot" is used as a reference for this NFS mount throughout the rest of service configuration, and it maps to the <software-mount-point> "domain922". For example, you can use "/domainRoot" when pointing to the patch location on NFS in this instance's classpath:

   /domainRoot/patch_weblogic/profiles/default/sys_manifest_classpath/weblogic_patch.jar:/appliance/java/lib/tools.jar:/appliance/bea/weblogic92/server/lib/weblogic.jar:/appliance/bea/weblogic92/server/lib/webservices.jar:

2. <software-mount-point> "domain922" has to match the name entered during this NFS software created during agent configuration. The following is a snippet from the agent configuration:

   <nfs-software>
        <name>domain922</name>
        <description>domain nfs directory for ve11</description>
        <path>glimfeather:/glimnfs/domaindirs/bea/wls922/user_projects/lx_HoggingServletDomain_ga-BP,uid=13947,gid=10</path>
        <mode>EXCLUSIVE</mode>
   </nfs-software>

    
3. In the "software-constraint" definition, the <from> value of <copies-at-create> is relative to the <software-mount-point>, and the <to> value is the absolute path in WLS-VE instance's file system on local disk. So in my example, it copies the license file from "domain922/licenses/license.bea" to "/esxDomainDir/licenses/license.bea" where "domain922" is the domain NFS mount point and "esxDomainDir" is the domain directory under the root "/" in the instance's file system on local disk.

• local-disk-size-constraint: The constraints define the size of the disk(in MBytes) to be allocated for the local disk attached to the LiquidVM.

<ns2:local-disk-size-constraint>
    <ns2:name>WLSVE922-disk-size</ns2:name>
    <ns2:key>WLSVE922-disk-size</ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>deployed</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
    <ns2:value>1024</ns2:value>
</ns2:local-disk-size-constraint>

Note: To be able to use the copies configuration on JVM instance , WLOC requires the "local-disk-size-constraint" to be bound to the same process group that the JVM belongs to.

Last but not the least, we need bind all those constraints to the appropriate services/process groups for them to be evaluated in service runtime.

WebLogic Operations Control (WLOC) Introduction

Base Introduction to Virtualization

When corporate data centers continuously grow to reach their physical limits, adding more servers and renting more space is not always a solution. Research on X86 servers running on Windows have shown that the usage of the capacity is < 15%. Virtualization comes into place to dramatically increase the data center utilization and save space, power and cooling cost. It’s a technique that makes one physical machine appear as one or more virtual machines, each of which has it own “Guest Operating System” and share the same underlying hardware without knowing the existence of each other.

Virtualization Challenges and WLOC Solution

With more and more adoption of virtualization, IT staff start facing the following difficulties:

• Understand the complexity of the operational environment and unique requirement of each Java application
• Determine how closely the applications honor their service level agreements (SLAs)
• Ensure the application to make the best use of computing resources overall

To provide a solution to these problems, BEA is bringing a product to market in March 2008, WebLogic Operations Control (WLOC). WLOC:

• Hides the complexity of the underlying operational environment and presents the resources and Java applications in a simple supply and demand mode. On the supply side, the resources are grouped into resource pools and on the demand side, the Java applications are grouped into process types, which are further grouped into services. Typically Java applications in the same process type have the same SLAs.
• Offers a policy-driven framework that enables the users to define and enforce the SLAs. Once the supply and demand is properly configured, IT staff can continue using WLOC to define the SLAs such as computer power, memory, software, topology, QoS, etc. If any SLA constraint is not met, one or more actions configured will be taken. For example, one can define a SLA constraint such that if the aggregate throughput of serviceA is higher than some value, start one more process to serve the spike in customer demand for serviceA.
• Deploys the services efficiently by monitoring the resources from all the resource pools. Based on the supply/demand and SLA configuration, WLOC intelligently chooses the right resource pool to deploy the service.
• Offers a web browser based console for visualizing the configuration, runtime monitoring and management operations.

For further information, BEA published the WLOC documentation; it's still in beta version as of now and subject to change.

Also, you can go to Mike Jasnowski's blog (Mike is working on the UI portion of WLOC) where he talks about WLOC and details on features presented by the WLOC Console.

WLOC main components

Figure: WLOC Architecture Overview (from WLOC edoc site)

Controller

WLOC controller is the central brain of the operational environment, based on the supply and demand information (discussed above), The controller deploys the services in the way that best serves the SLAs. The controller gathers runtime data such as available resources, application metric, etc from the agents and enforces SLAs based on the defined polices. If any QoS rule is violated, the controller sends process control commands to the agents and optionally sends out notifications. WLOC console is also hosted by the controller.

Agents

WLOC agents monitor the Java processes, provide the runtime data to the controller, and carry out the actions requested by the controller. Based on the type of the managed Java processes (virtualized or non-virtualized), there are two kinds of agents: ESX Agent and Plain Agent.

Managed Java Processes

WLOC V1 supports WLS-VE (WebLogic Server Virtual Edition, versions 1.0 and V1.1) as its managed Java application in a virtualized environment. WLOC plus WLS-VE provides an optimal virtualization solution based on manageability and performance.

Introduction of WLS-VE

While virtualization brings efficiency, it also inevitably leads to a performance penalty due to the extra layers introduced by the virtualization hypervisor.

To solve this problem:

• The latest hypervisors like VMWare ESX eliminated the need for the hardware server’s OS so they can run directly on the “bare metal” of the server, which helped to gain back some performance lost due to virtualization.
• BEA has taken this to the next level and offered WLS-VE that enables Java applications to run more efficiently on virtualized hardware. It eliminated each Java application’s “guest OS” in the same way that the hypervisor eliminated the “host OS”; thus, allowing Java application run directly on hypervisor. The installation includes an ISO image containing the WebLogic Server 9.2 classes and LiquidVM executables used to run WLS and the applications on the hypervisor host (i.e. the VMware ESX server)

Having said all above, WLOC by no means excludes the support of WLS Java instances in the non-virtualization environment. From a user’s perspective, there is not much difference between a virtualized and non-virtualized process. It’s still the same supply-and-demand mode, only in the non-virtualized case, the supply is a resource pool representing a single physical machine. In the virtualized case, the supply consists of one or more resource pools representing resources from one or more virtualized host machine. From the demand side, the service configuration of the non-virtualized case could be simpler due to the absence of virtualization. By providing the same SLAs, non-virtualized Java applications will be under the same management of WLOC. WLOC is also able to manage non-WLS Java instances in both virtualized and non-virtualized environments.

WLOC Basic Concepts

Service

A set of Java processes managed by LOC; inside a service, the processes can be further grouped into different process types.

Process Type

A group of instances that can be treated equivalently and adhere to the same constraints. For example, Admin ProcessType, Cluster1 ProcessType, etc.

Instance

The managed Java application; WLOC supports any Java application, either virtualized or non-virtualized.

Constraint

A standardized expression of user defined service level agreement. It typically provides a value that will be compared against a runtime metric. There are different types of constraints:

• basic metric constraints: constraints using MBean attributes, such as the primitive-typed ones like: IntConstraint, FloatConstraint, StringConstraint, etc. For example, the following constraint will be triggered if the RestartsTotalCount attribute on WLS adminServer’s ServerRuntimeMBean exceeds 5: 

<ns2:int-constraint>
   <ns2:name>constraint1</ns2:name>
   <ns2:key>constraint1-key</ns2:key>
   <ns2:priority>0</ns2:priority>
   <ns2:state>deployed</ns2:state>
   <ns2:evaluation-period>0</ns2:evaluation-period>
   <ns2:instance-name>com.bea:Name=adminServer,Type=ServerRuntime</ns2:instance-name>
   <ns2:instance-type>weblogic.management.runtime.ServerRuntimeMBean</ns2:instance-type>
   <ns2:attribute-name>RestartsTotalCount</ns2:attribute-name>
   <ns2:match-undefined>false</ns2:match-undefined>
   <ns2:constraint-type>max</ns2:constraint-type>
   <ns2:value>5</ns2:value>
</ns2:int-constraint>

• process constraints: constraints on the number of process instances. It’s called MinProcessConstraint and MaxProcessConstraint. For example, if you want to have at least 4 instances for some process type when the service is deployed, define the following constraint:

<ns2:min-process-constraint>
    <ns2:name>StartWLS-VE-Cluster</ns2:name>
    <ns2:key>StartWLS-VE-Cluster-key</ns2:key>
    <ns2:priority>8</ns2:priority>
    <ns2:state>deployed</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
    <ns2:value>4</ns2:value>
</ns2:min-process-constraint>

service deployment constraints: constraints for services in transitioning states such as starting, stopping, staging and destroying. I will discuss these service lifecycles in detail in a future blog entry. These constraints explicitly call out the bound actions for the services in different transition states. For example, if you bind the StartServiceAction with the following constraint, WLOC will start the service and all required JVMs. Note that these service deployment constraints are not required, WLOC runs implicit actions in cases where these explicit deployment constraints are not defined. Reasons why you would want to explicitly define them include binding a custom pipeline to these constraints or setting a property on the action.

<ns2:deployment-state-constraint>
    <ns2:name> service-deploy</ns2:name>
    <ns2:key>service-deploy-key</ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>starting</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
</ns2:deployment-state-constraint>

• time based constraints: constraint based on a specific date or time. They can be bound at the service level with deployment actions to start/stop all instances in that service at a specified time, such as CronDeploymentConstraint /CronUndeploymentConstraint. Or with service level actions to send out a notification such as cron-service-event-constraint. You can also use cron-process-type-event-constraint at the process type level if you want to start/stop an extra instance in a process type at a specified time. For example, you want to deploy a service at 5 AM everyday:

<ns2:cron-deployment-constraint>
    <ns2:name>Cron-Start-LOC-services</ns2:name>
    <ns2:key>Cron-Start-LOC-services-key</ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>undeployed</ns2:state>
    <ns2:cron-string>0 0 5 * * ? *</ns2:cron-string>
</ns2:cron-deployment-constraint>

Or start an extra server at 6:30AM everyday:

<ns2:cron-process-type-event-constraint>
    <ns2:name>cron-start-wls-cluster1-managed-constraint2</ns2:name>
    <ns2:key>cron-start-wls-cluster1-managed-constraint2-key</ns2:key>
    <ns2:priority>7</ns2:priority>
    <ns2:state>deployed</ns2:state>
    <ns2:cron-string>0 30 6 * * ? *</ns2:cron-string>
</ns2:cron-process-type-event-constraint>

Note: To start multiple instances in the same process type with cron-process-type-event-constraint, you can define a pipeline with the same StartServerAction multiple times, and then bind the cron-process-type-event-constraint to this pipeline.

• action/event constraints: constrains based on the outcome of a previous action or event that is generated when a constraint is violated. For example, if you have a constraint that’s bound to a StartServerAction, if the server fails to start, you want to do something such as receive an email notification. To do that, you can define a process-type-event-constraint that’s against the event generated by this constraint firing, or you can define a process-type-action-constraint against the StartServerAction. The process-type-action-constraint is similar but it can cut across events, so if any StartServerAction fails(doesn’t matter which constraint is the StartServerAction bound to), we’ll get a notification. Here are two examples:

<ns2:process-type-event-constraint>
     <ns2:name>admin-event-constraint-succ</ns2:name>
     <ns2:key>admin-event-constraint-succ-key</ns2:key>
     <ns2:priority>3</ns2:priority>
     <ns2:state>deployed</ns2:state>
     <ns2:evaluation-period>60000</ns2:evaluation-period>
     <!-- here the event-name matches to the constraint key that fires the event -->
     <ns2:event-name>StartAdmin-key</ns2:event-name>
     <ns2:event-status>failed</ns2:event-status>
 </ns2:process-type-event-constraint>

<ns2:process-type-action-constraint>
    <ns2:name>admin-action-constraint-succ</ns2:name>
    <ns2:key>admin-action-constraint-succ-key</ns2:key>
    <ns2:priority>3</ns2:priority>
    <ns2:state>deployed</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
    <!-- StartAdmin is the action name for StartServerAction -->
    <ns2:action-name>StartAdmin</ns2:action-name>
    <ns2:action-status>failed</ns2:action-status>
</ns2:process-type-action-constraint>

• resource constraints: these constraints make sure that the physical resources such as CPU, memory, IP addresses and local disk (for WLS-VE1.1 Java applications) are available and reserved for the service. Note that an IP address constraint can ONLY be bound with single instance because multiple instances can’t share the same IP address. See the example below. The following are examples for the memory, CPU and local disk size constraints I just mentioned:

<!—allocate minimal 200MB memory --> 
<ns2:min-memory-constraint>
    <ns2:name>Server-min-memory-constraint</ns2:name>
    <ns2:key>Server-min-memory-constraint-key</ns2:key>
    <ns2:priority>10</ns2:priority>
    <ns2:state>deployed</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
    <ns2:value>200</ns2:value>
</ns2:min-memory-constraint>

 

<!—allocate minimal 500MHz CPU --> 
<ns2:min-cpu-constraint>
    <ns2:name>Server-min-cpu-constraint</ns2:name>
    <ns2:key>Server-min-cpu-constraint-key</ns2:key>
    <ns2:priority>10</ns2:priority>
    <ns2:state>deployed</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
    <ns2:value>500</ns2:value>
</ns2:min-cpu-constraint>

 

<!—allocate 1024 MB as the local disk size for the WLS-VE instance when it’s created --> 
<ns2:local-disk-size-constraint>
    <ns2:name>WLSVE922-disk-size</ns2:name>
    <ns2:key>WLSVE922-disk-size</ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>deployed</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
    <ns2:value>1024</ns2:value>
</ns2:local-disk-size-constraint>

<!—make sure that some_ip_address is available for some_server -->
<ns2:ip-address-constraint>
    <ns2:name>LOC-service2ProcessType0</ns2:name>
    <ns2:key> ip-constraint </ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>deployed</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
    <ns2:address>some_ip_address</ns2:address>
</ns2:ip-address-constraint>

<!—note ip-address-constraint can only bound to a single instance and not to a process type -->
<ns2:constraint-binding>                                                      
    <ns2:constraint-key>ip-constraint</ns2:constraint-key>
    <ns2:action-key>internal</ns2:action-key>
    <ns2:process-instance-name>some_server</ns2:process-instance-name>
</ns2:constraint-binding>

• software constraints : these constraints make sure that the required software is available, such as the NFS mount points where normally the domain and license files are and the ISO that’s used by the hypervisor to launch the Java applications. If any of them is not available, the Java application will fail to be started during the JVM placement stage. In the following examples, note that the software-mount-point and ISO-name must match the software and ISO configuration during agent creation, and they map to the NFS mount locations. Don’t worry if you are confused at this point. In my next blog, I plan to talk about the configuration, including the software configurations from the scratch.

<ns2:software-constraint>
    <ns2:name>domains-root-software-constraint</ns2:name>
    <ns2:key>domains-root-software-constraint</ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>deployed</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
    <ns2:software-name>domain</ns2:software-name>
    <ns2:software-mount-point>/domain</ns2:software-mount-point>
</ns2:software-constraint>

 

<ns2:iso-constraint>
    <ns2:name>WLSVE921-iso</ns2:name>
    <ns2:key>WLSVE921-iso</ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>deployed</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
    <ns2:iso-name>WLSVE921-ISO</ns2:iso-name>
    <ns2:copies-at-create/>
</ns2:iso-constraint> 

Action

An activity initiated by the controller in response to a violated defined constraint. It is a Java class that can be run in the controller or agents. There are different types of actions:

• service control actions: these actions are bound to the service deployment constraint to start/stop/stage/destroy the services. Again the details of service lifecycle will follow.
• instance control actions: these actions are bound to the process constraints to start/stop the Java instances.
• resource control actions: to change the CPU and memory physical resources on the associated services.
• notification actions: JMS/JMX/SMTP/SNMP/Console notification will be generated. I want to explain a little on the Console Notification, as it’s new in WLOC. It will send an event message to the WLOC console and message will be displayed in the Event Viewer tab. Also, it will change the object color based on the configuration in the action, such as turning the name of the managed object red.
• configuration actions: to make JMX changes. I haven’t included this type of action in my test, but the support is there.
  • First you need to create the connection factory for the managed endpoint product such as WebLogic, WebSphere from WLOC console Controller/Connections tab.
  • Then create the connection for each managed Java application also from the WLOC console Controller/Connections tab.
  • Finally define the JMX actions from Policies/Definitions/Actions tab; it supports create, destroy, set and invoke commands on the MBeans.

Pipeline

A sequence of actions that can be bound to the same constraint. Once the constraint is violated, all the actions will be executed in serial. (Parallel execution is not supported in V1). Here is an example to start the admin server and then send out an email notification:

<ns2:pipeline>
    <ns2:name>StartAdminPipeline</ns2:name>
    <ns2:key>StartAdminPipeline-key</ns2:key>
    <ns2:adjudicate>false</ns2:adjudicate>
    <ns2:actions>
        <ns2:action>
            <ns2:action-key>StartServerAction-key</ns2:action-key>
            <ns2:sequence>1</ns2:sequence>
        </ns2:action>
        <ns2:action>
            <ns2:action-key>email-StartServerAction-key</ns2:action-key>
            <ns2:sequence>2</ns2:sequence>
        </ns2:action>
    </ns2:actions>
</ns2:pipeline>

Constraint binding

Also called “policy”, it binds a constraint to a service or process type or can even be bound globally. If it’s in the global scope, the constraint binding will apply to ALL Java instances. If it’s in the service scope, the constraint binding will apply to all process types in the service. Finally if it’s in the process type scope, it will apply to all Java instances in that process type. It defines the SLAs of the services and consists of a constraint and an action or pipeline that’s bound to it. The following example shows a service definition with one constraint binding Cron-Start-LOC-services-key at the service level and another one StartWLS-Cluster1-key at the process type level:

<ns2:service>
    <ns2:name>LOC-service2</ns2:name>
    <ns2:state>undeployed</ns2:state>
    <ns2:priority>1</ns2:priority>
    <ns2:constraint-bindings>
        <ns2:constraint-binding>
            <ns2:constraint-key>Cron-Start-LOC-services-key</ns2:constraint-key>
            <ns2:action-key>StartServerAction-key</ns2:action-key>
        </ns2:constraint-binding>
    </ns2:constraint-bindings>
    <ns2:process-types>
        <ns2:process-type>
            <ns2:constraint-bindings>
                <ns2:constraint-binding>
                    <ns2:constraint-key>StartWLS-Cluster1-key</ns2:constraint-key>
                    <ns2:action-key>StartServerAction-key</ns2:action-key>
                </ns2:constraint-binding>
            </ns2:constraint-bindings>
            <ns2:name>WLS-Cluster1</ns2:name>
            <ns2:metadata-key>WLS-Cluster1-key</ns2:metadata-key>
        </ns2:process-type>
    </ns2:process-types>
    <ns2:max-failed-event-retry-count>3</ns2:max-failed-event-retry-count>
</ns2:service>

Instance Metadata

Metadata defines all the parameters required to start the Java instance. JVM instance metadata can be grouped into “metadata group” with a unique key that can be referenced in the process type definition.

• ready-information: some JMX metric information that the agent observer will contact the instance to retrieve. The instance start action won’t be considered complete until the metric is received. Before that, the next instance to be started in the same process type won’t be started until this instance’s start is complete. One usage in which we need to define the ready-information is to assure the admin server is up and ready before starting the rest of the managed servers that are in the same process type. If no ready-information is defined, the start of the instance won’t wait; it essentially means all the instances in the same process type start in parallel.

<!—example of admin server metadata with ready-information in it -->
<ns2:metadata-group>
    <ns2:name>WLS922-Admin</ns2:name>
    <ns2:key>WLS922-Admin-key</ns2:key>
    <ns2:instances>
        <ns2:jvm-instance>
            <ns2:name>adminServer</ns2:name>
            <ns2:main-class>weblogic.Server</ns2:main-class>
            <ns2:ready-information>
                <ns2:check-type>ValueExists</ns2:check-type>
                <ns2:max-wait-period>300000</ns2:max-wait-period>
                <ns2:instance>com.bea:Name=adminServer,Type=ServerRuntime</ns2:instance>
                <ns2:attribute>RestartsTotalCount</ns2:attribute>
            </ns2:ready-information>
            <!--  arguments used to start the JVM -->
            <ns2:jvm-args>
                <ns2:arg>-Xmx256m</ns2:arg>
                <ns2:arg>-Xms64m</ns2:arg>
                <ns2:arg>-cp</ns2:arg>
                <ns2:arg>C:/bea/xlina/wls920mp2/ga/jrockit90_150_10/lib/tools.jar;C:/bea/xlina/wls920mp2/ga/jrockit90_150_10/lib/tools/sa-jdi.jar;C:/bea/xlina/wls920mp2/ga/jrockit90_150_10/lib/jconsole.jar;C:/bea/xlina/wls920mp2/ga/jrockit90_150_10/lib/dt.jar;C:/bea/xlina/wls920mp2/ga/weblogic92/server/lib/weblogic_sp.jar;C:/bea/xlina/wls920mp2/ga/weblogic92/server/lib/weblogic.jar;C:/bea/xlina/wls920mp2/ga/weblogic92/common/eval/pointbase/lib/pbclient52.jar;C:/bea/xlina/wls920mp2/ga/weblogic92/server/lib/xqrl.jar</ns2:arg>
                <ns2:arg>-Dweblogic.Name=adminServer</ns2:arg>
                <ns2:arg>-Dweblogic.management.username=weblogic</ns2:arg>
                <ns2:arg>-Dweblogic.management.password=weblogic</ns2:arg>
                <ns2:arg>-Djava.security.policy=C:/bea/xlina/wls920mp2/ga/weblogic92/server/lib/weblogic.policy</ns2:arg>
            </ns2:jvm-args>
            <ns2:java-args>
                <ns2:arg>60000</ns2:arg>
            </ns2:java-args>
            <!-- the working directory of the JVM -->
            <ns2:instance-dir>C:/bea/xlina/wls920mp2/user_projects/lx_HoggingServletDomain_ga-BP</ns2:instance-dir> 
            <!-- set it to true if you want to use standard j2se way if it is a generic JVM -->
            <ns2:native-jmx>false</ns2:native-jmx>
            < !—the following host, port, username and password are used to establish the JMX MBeanServer connection after the JVM is started to retrieve monitoring information -->
            <ns2:host>10.254.6.246</ns2:host>
            <ns2:port>8801</ns2:port>
            <ns2:username>weblogic</ns2:username>
            <ns2:password>{Salted-3DES}7oaHDfE+yhoXtbI4vcLVhA==</ns2:password>
            <ns2:ssh-enabled>false</ns2:ssh-enabled>
            <ns2:wait-for-ssh>false</ns2:wait-for-ssh>
            <ns2:priority>0</ns2:priority>
            <ns2:copies-at-create/>
            <ns2:copies-at-shutdown/>
        </ns2:jvm-instance>
    </ns2:instances>
</ns2:metadata-group>

Note: All the above samples are generated through WLOC console.

April 2008

Search this blog:

Archives

April 2008
March 2008

Categories

Recent Entries

Lifecycle of the Services Managed by WLOC

How to Configure WLOC Components to Manage WLS-VE Instances

WebLogic Operations Control (WLOC) Introduction