This section describes configuration tasks associated with WLOC services. It contains the following sections:
A service is a set of processes managed by WLOC. A process is typically a stack that contains the JVM, the application container, and application logic. For example, a service can be used to manage one or more WebLogic Server instances a domain.
A service’s configuration includes such information as:
A typical service manages a group of processes that are logically related and organized in process groups. When configuring a process group, you need to specify information required by WLOC to instantiate it, including:
When defining the process group, the console prompts for information about its processes. Table 5-1 describes in more detail the information needed to define a process group.
The classpath for the class or JAR file that instantiates this process. For information about obtaining classpath information, see Classpath.
|
|
JVM arguments to use with the command that instantiates the process. These arguments are passed as java options. Separate each Java argument using a space.
For more detailed information, see JVM Arguments.
|
|
Information about the metric that WLOC obtains from the JVM instance and uses to determine whether or not a process is available.
For more detailed information, see Ready Metrics.
|
|
The required minimum and maximum amount of CPU and memory. For more information, see Resource Requirements.
|
|
The primary tool for defining services is the WLOC Administration Console. Services you define or modify using the console will take place in real time. See the WLOC Administration Console help system for step-by-step instructions.
When defining the service’s processes in the console, you can manually enter the required information or use a number of helper functions the console provides for importing much of the information. These include:
It is also possible to define or modify a service by directly editing the metadata configuration file. The location and name of this file is:
BEA_HOME\user_projects
\controller\config\metada-config.xml
Note that direct modifications to the file do not take effect until the Controller is restarted. In addition, manual changes are not validated or error-checked until they are loaded by the next controller boot.
There are number of resources to help you obtain more information about metadata-config.xml
file. This includes:
\schemas\loc-metadata.xsd
. This file may
may also be accessed at
http://download.oracle.com/docs/cd/E13217_01/wloc/docs10/schemaref/metadata/loc-metadata.xsd.BEA_HOME\user_projects
\controller\config\metadata-config.xml.SAMPLE
.
When using the console to define a service’s processes, the console solicits information about the service’s resource requirements. This information constitutes the service’s out-of-gate deployment policies and is saved in the form of constraints and actions.
Resource requirements specify the required amount physical computing resources for each instance in a process group. For example, to create a process group that includes a WebLogic Server domain, specify resource requirements for running all WebLogic Server instances. You can specify that a WebLogic cluster needs a minimum of 400 MHz of CPU cycles and 400 MB of RAM and can scale up to a maximum of 800 MHz of CPU and 800 MB of RAM.
Note: | For CPU measurement, WLOC uses normalized megahertz (MHz) across CPU architectures so that a megahertz of processing on an i386 processor is comparable to a megahertz on processors types. |
These requirements do not include resources needed to run software outside of the process group, but declared as a dependency. For example, if a process group specifies that it requires a RDBMS system, the resource requirements do not include computing resources for the RDBMS.
Resource requirements are specified in terms of minimum and maximum amounts. The minimum requirement specifies the smallest amount of resources that must be reserved for exclusive use by a process group. As the resources consumed by a process group approach the minimum, a WLOC policy can request additional resources up to the maximum requirement.
WLOC may not be able to actually obtain additional resources if all available resources are being consumed by other WLOC resource pools or non-WLOC applications. For example, Figure 5-1 shows a hypervisor resource pool containing two WLOC resource pools. Although the pool provides 600 MB of memory, the WLOC Resource Pool has two services, each configured for a minimum of 200 MB and maximum of 400 MB. While both services can consume the minimum required memory (200 MB) at the same time, they cannot simultaneously consume the maximum. In Figure 5-1, service 1 is consuming 400 MB, so the total amount of consumed memory is 600 MB. Service 2 cannot use additional memory until service 1 decreases its memory consumption.
WLOC needs to know when a process has successfully started and is ready for work. This is made possible by specifying the process group’s ready metric. When defined, the action to start an instance is not considered complete until the ready metric is satisfied. If the ready metric isn't satisfied in a configurable amount of time, then the instance is considered failed and will be stopped.
Ready metric information is described in Table 5-2.
For more information about the format to use to specify MBean attributes, see
WebLogic Server MBean Reference.
|
|
Table 5-3 specifies a ready metric that reports a JVM instance is in RUNNING state:
Listing 5-1 shows how this ready metric as contained in metadata-config.xml
.
<ns2:ready-information>
<ns2:check-type>ValueEquals</ns2:check-type>
<ns2:max-wait-period>300000</ns2:max-wait-period>
<ns2:instance>com.bea:Name=AdminServer,Type=ServerRuntime</ns2:instance>
<ns2:attribute>State</ns2:attribute>
<ns2:value>RUNNING</ns2:value>
<ns2:value-type>java.lang.String</ns2:value-type>
</ns2:ready-information>
For proper operation and tuning, managed applications must typically start with a specific set of JVM arguments . For each process group, you can specify the JVM arguments to use when the process starts.
The WLOC plain agent uses a management server to obtain the current CPU and memory use of a service. For plain agents, you must be sure to turn on the management server. To do so, include the following JVM arguments in the process group specification. Note that the port number must be a unique on each machine. The default port is 7091.
For JVMs running on JRockit before version 150_11, use the following single argument:
-Xmanagement-Djrockit.managementserver.port=<port-number>
For JVMs running on JRockit version 150_11 and above, use the following two arguments:
-Djrockit.managementserver.port=<
port-number>
-Xmanagement:ssl=false,authenticate=false
These arguments are not needed for process groups managed by a Hypervisor Agent.
Listing 5-2 shows the JVM arguments used to start the administration server.
-Xmanagement -Dcom.sun.management.jmxremote.port=7091
-Xmx128m
-Xms64m
-Dweblogic.Name=examplesServer
-Dweblogic.management.username=weblogic
-Dweblogic.management.password={Salted-3DES}L9NHXoCmDmOXAobBz2ennw==</
-Djava.security.policy=C:/files/bea/weblogic92/server/lib/weblogic.policy
-Dwls.home=C:/files/bea/weblogic92/server
-Dweblogic.RootDirectory=C:\files\bea\weblogic92\samples\domains\wl_server
Listing 5-3 provides an example of the JVM arguments as contained in metadata-config.xml.
<ns2:jvm-args>
<ns2:arg>-Xmx128m</ns2:arg>
<ns2:arg>-Xms64m</ns2:arg>
<ns2:arg>-da</ns2:arg>
<ns2:arg>-cp</ns2:arg>
<ns2:arg>CLASSPATH=C:\bea\patch_weblogic921\profiles\default\
sys_manifest_classpath\weblogic_patch.jar;C:\bea\WEBLOG~1\server\
lib\weblogic_sp.jar;C:\bea\WEBLOG~1\server\lib\weblogic.jar;C:\bea\
WEBLOG~1\server\lib\webservices.jar;</ns2:arg>
<ns2:arg>-Dwls.home=C:\bea\weblogic92\server</ns2:arg>
<ns2:arg>-Dweblogic.management.discover=true</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\weblogic92\server\lib\
weblogic.policy</ns2:arg>
<ns2:arg>-Dweblogic.RootDirectory=C:\bea\user_projects\domains\
WLOCdomain</ns2:arg>
</ns2:jvm-args>
For additional information about JVM arguments to use when starting WebLogic Server instances, see the weblogic.Server Command-Line Reference.
Among the JVM required arguments is the classpath needed to start the JVM instance. This section describes how to obtain the classpath in different environments.
setDomainEnv
command and obtain the WLS classpath by echoing CLASSPATH environment variable. Examples:
Windows — \bin\setDomainEnv.cmd
Solaris/Linux — ./bin/setDomainEnv.sh
Windows — c:\apps\myapp\lib\myapp1.jar;C:\apps\myapp\lib\myapp2.jar
Solaris/Linux — /apps/myapp/lib/myapp1.jar;C:/apps/myapp/lib/myapp2.jar
Classpath elements can be sourced anywhere from LiquidVM file system. If the element is in the iso, the path must begin with '/appliance
' since the iso is mounted on '/appliance
'. If the element is in a NFS share, then the path must begin with the NFS mount point. If the element is in the local disk, then the path would begin with '/
'.
commonStartVE
script is: /bea/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
commonStartVE
script is: /bea/patch_weblogic922/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:
/mynfs/patches/myapp_patch1.jar:/patches/myapp_patch2.jar:/appliance/applications/myapp/lib/myapp1.jar:/appliance/applications/myapp/lib/myapp2.jar
The state of a service is undeployed until it is started. When the service is started, the following occurs:
When WLOC deploys a service, it first searches for the set of placement organizations that match the given constraints for memory, CPU, and such factors as software and IP address. A service’s placement-algorithm attribute affects placement organization and specifies whether you want VMs placed into pools so that there is as little memory resource left over as possible (PreferSmaller
) or as much left over as possible (PreferLarger
). The default is PreferLarger
.