|
|
This document provides an introduction to Oracle® WebLogic Operations Control.
While the introduction of virtualization technology into the operations center offers the promise of maximizing the use of your physical hardware, the technology also introduces complexities that can make it difficult to determine how closely your applications honor their service level agreements (SLAs) while making the most efficient use of computing resources.
WebLogic Operations Control (WLOC) is a management framework for virtualized and non-virtualized enterprise Java applications that addresses the key challenges involved in application virtualization. To address these challenges, WLOC:
WLOC introduces a layer of abstraction that enables your operations staff to think in terms of supply and demand instead of requiring them to understand the complexities of your computing environment and the unique requirement of each Java application that you support in your operations center.
On the demand side, you use WLOC to organize Java applications (processes) into WLOC services. You organize a group of related processes into a single service and manage the group as a unit; you can create one service for each process.
On the supply side, you use WLOC to organize the compute resources in your operations center into collections of resources, or resource pools. A WLOC resource pool can represent a single physical machine or a collection of virtualized resources that are made available through Hypervisor software.
WLOC effectively manages the supply of available resources in order to meet the demands of the deployed services.
WLOC provides an environment for encapsulating service level agreements (SLAs) as a collection of requirements and policies. The operations team can define policies based on application-level SLAs that govern the allocation of hardware and software resources, ensuring that Quality of Service (QoS) goals are met across virtualized and non-virtualized platforms. When predefined conditions occur, WLOC triggers an action. For example, WLOC might dynamically allocate resources to a service.
WLOC monitors the use of resources across the operations center and distributes the deployment of Java applications in a manner that ensures the most efficient use of resources overall.
When you deploy a service or when a WLOC action requests that an additional process be started, WLOC examines all resource pools to determine where to host the service or process. To choose a resource pool, WLOC first eliminates any resource pool that cannot satisfy such dependencies as IP addresses or access to software. For example, if a service requires access to WebLogic Server software, WLOC eliminates any resource pools that cannot provide access to WebLogic Server software.
After considering declared dependencies, WLOC considers the capacity of each remaining resource pool, the SLAs of any services that are currently deployed, and the relative priorities declared for each service. It then uses one of the following algorithms that you select:
For example, if resource pool A has 600 MHz of CPU and 600 MB of RAM that are currently unused and resource pool B has 400 MHz of CPU and 400 MB of RAM that are unused, WLOC chooses resource pool A.
For example, if resource pool A has 600 MHz of CPU and 600 MB of RAM that are currently unused and resource pool B has 400 MHz of CPU and 400 MB of RAM that are unused, and if you deploy a service with a minimal requirement of 200 MHz of CPU and 200 MB of RAM, WLOC chooses resource pool B.
A typical WLOC deployment contains a single WLOC Controller—the centralized component that gathers data about the operating environment—and multiple Agents that manage and monitor resources and communicate that information back to the Controller. The Controller hosts the WLOC Administration Console that enables you to visually configure, manage, and monitor the WLOC environment.
| Note: | All of the components use HTTPS or HTTP to communicate. |
Each WLOC component shown in the previous figure is described in the following table.
Centralized component that gathers data from Agents about the operating environment and deployed services to deliver adaptive management. The Controller uses the data gathered to enforce policies and to deploy new services in a way that best honors the Service Level Agreements (SLAs) of all deployed services. The Controller hosts the WLOC Administration Console. For more information, see Controller.
|
|
Provide information about the environment to the Controller, start and stop processes, and invoke other actions at the request of the Controller. Each Agent operates within a narrow scope: a plain Agent gathers data and manages processes on a single physical machine and an ESX Agent gathers data and manages processes on a VMware resource pool.The Hypervisor software makes available to WLOC a collection of virtualized resources, which can be supported by one or more physical hosts. For more information, see Agents.
|
|
Web browser-based, graphical user interface that you use to configure, manage, and monitor services in your operations center. It is hosted by the Controller. For more information, see Defining Services to Organize Processes.
|
|
An ESX Agent communicates with VMware Virtual Center to gather data about the VMware resource pool that is available for use by WLOC and to manage instances of LVM, such as WLS-VE. After an LVM instance starts, the Agent communicates with that LVM instance to gather monitoring data and invoke management actions. In this way, the VMware Virtual Center manages the supply of resources, whereas WLOC manages the demand on the resources.
|
The WLOC Controller is the centralized component that gathers data from Agents about the operating environment and deployed services to deliver adaptive management. The Controller uses the data gathered to intelligently deploy new services and to evaluate and enforce policies to honor the Service Level Agreements (SLAs) for all services in the environment.
Each WLOC environment includes a single Controller that is responsible for the following:
During the configuration of the Controller, you bind the Controller to the available Agents. To manage resource pools, the Controller communicates with the Agents to which it is bound to determine the computing resources that each Agent is capable of allocating and selects appropriate resource pools for deploying services.
A WLOC service is a collection of one or more processes that WLOC manages as a unit. You define the service details and the associated metadata required to run each of the processes. To create SLAs, you define service policies that consist of deployment and runtime constraints and the actions to take if those constraints are not met.
To adapt the WLOC environment to best meet the SLAs of all deployed services, the Controller communicates with Agents to gather metrics. It compares policy constraints against the metrics and invokes actions when services operate outside the constraints.
A WLOC Agent is a standalone Java process that renders the CPU cycles and memory of a machine or a collection of virtual resources as a resource pool for use by WLOC services.
Typically, a WLOC environment has multiple Agents that are responsible for the following:
As shown in Figure 2, WLOC provides two types of Agents:
The VMware infrastructure must be configured using VMware tools. You cannot use WLOC to configure the virtualized environment, only to leverage the resources that are available.
The WLOC Administration Console is the Web browser-based, graphical user interface that you use to configure, manage, and monitor services in your operations center. It is hosted by the WLOC Controller, which communicates with Agents to gather monitoring data and to invoke management actions.
The following table summarizes the tasks that you can perform using the WLOC Administration Console.
Only authenticated WLOC users can access the WLOC Administration Console.
| Note: | Except for security data, WLOC stores its configuration in XML files. If you prefer, you can configure the WLOC components by editing the XML directly using a validating text editor instead of using the WLOC Administration Console. In this case, you will need to restart the Controller or Agent in order for the changes to take effect. |
You cannot use the WLOC Administration Console to:
A WLOC service is a collection of one or more processes that WLOC manages as a unit. Each process in a service is a software stack starting from the Java Virtual machine (JVM) and including the classes that are running in the JVM. You organize processes (JVMs) that perform the same function and have the same runtime characteristics into process groups within the service. For example, you can organize all of the servers in a cluster within a process group.
For each process group you specify the following:
You can define one or more policies that specify the deployment or runtime requirements (constraints) for the service and the actions to take if the SLA constraint is not met. For example, a policy can expand or shrink a service’s footprint in response to the runtime environment.
You can place constraints on a process, a group of processes, or all processes in a service. If your managed processes expose management data through Java Management Extensions (JMX), you can define a constraint based upon the value of an MBean attribute in your processes or based upon a calculated value derived form an MBean attribute in your process or group of processes.
When a constraint is violated, WLOC invokes a Java class (action) that you configure. WLOC provides actions that you can configure to do the following:
In addition, you can define policies that trigger actions at a predefined time.
You can combine actions into an action pipeline that specifies a sequence of actions to invoke. You can invoke actions or action pipelines from service policies or manually from the WLOC Administration Console.
For example, you create a WLOC service that specifies a process group for a collection of externally-facing Web services, all of which run on a single WebLogic Server cluster. You can configure the process group as follows:
When you deploy the service, WLOC reserves 400 CPU cycles and 600 MB of RAM for exclusive use by the service. As WLOC adds processes to the service, it requests additional resources for use by the service up to the maximum. If the additional resources are currently being used by other processes, WLOC can remove resources from lower-priority processes, as long as each process retains its minimal reserve.
You can monitor the performance of WLOC resources in the following ways:
To secure access to the WLOC Administration Console, WLOC uses role-based access control which enables you to assign different levels of privileges to different users or groups. WLOC provides a set of security roles with pre-configured access privileges. To facilitate the administration of large numbers of users, WLOC also provides a set of groups that you can configure to be in one or more WLOC security roles. You use the WLOC Administration Console to create users and assign them to groups or directly to security roles.
The WLOC documentation set includes the following:
|
