 | Level: Introductory Indran Naick (indrann@us.ibm.com), e-Business Architect, IBM
13 Jul 2004 Businesses, and their IT environments, must adapt to constantly changing market demands. Many over provision IT resources based on their worst-case scenario, peak demands, and often on an application-by-application basis, with specific servers dedicated to specific business processes. For an IT organization to become adaptive, proactive, and responsive, it must move from just-in-case provisioning to On Demand. This article describes how the IBM® Tivoli® Provisioning Manager and IBM Tivoli Intelligent Orchestrator can provide the autonomic computing capabilities needed to get you to On Demand. On Demand and autonomic computing
Recently there has been a lot of discussion about On Demand. IBM defines On Demand as an enterprise whose business processes, integrated end-to-end across the company and with key partners, suppliers, and customers, can respond quickly to any customer demand, market opportunity, or external threat. The supporting IT infrastructure to support this business model, called the On Demand operating environment, has two key characteristics:
- The ability to support integration across people, processes, and data
- A simplified operating environment
Operating environments in large data centers have become increasingly complex. The centers usually require a long time to modify their environments, so most provision for the worst-case scenario. They provision more hardware than is needed just in case a peak is experienced.This results in inefficiencies because most hardware and other resources are underused. High capital and running costs also occur. And, there is still an unresolved issue of surges beyond what has been provisioned. For example, in Figure 1, there are three separately provisioned environments, two of which are experiencing low utilization and have excess capacity, and a third environment that is experiencing high utilization at a certain point in time. As the time changes the utilization might change depending on the workload, but because there is a defined set of resources the capacity is static and capped.
Figure 1. Provisioning independently for specific environments
You need a level of automation, as shown in Figure 2, that lets you quickly and efficiently add resources when and where they are needed. The goal is to simplify, and autonomic computing is key to that vision.
Figure 2. Pooling resources for efficiency
The autonomic computing architecture consists of several core capabilities. This article discusses two key IBM products that provide orchestration and provisioning capabilities to address On Demand issues with autonomic computing.
Provisioning and orchestration
Provisioning and orchestration let you automatically manage resources within your data center. Resources can be storage space, a new server, network bandwidth, software, or virtually any of the components of your data center. Currently, to add resources, an IT person must manually take physical action. Automated provisioning lets the IT staff store their knowledge into a reusable element. Tasks such as installing an operating system, adding a new server, installing a software patch, enabling a network port, and so on can be automated.
Orchestration provides the ability to act on events that occur within the data center. These events are usually acted on by the IT staff. Again, the IT staff can capture best practices into reusable elements that can be automatically initiated when certain conditions or service levels are threatened.
At a higher level, IBM Tivoli Intelligent ThinkDynamic Orchestrator (ITITO) lets you define service levels or service objectives. You can specify at what threshold new resources should be provisioned. It also defines customer tiers that allow decisions to be made based on the defined tier when there is resource contention.
The IBM Tivoli Provisioning Manager (ITPM), which is part of ITITO, provides the provisioning function, and ITITO provides the orchestration functions for data center automation.
Autonomic managers
ITITO and ITPM are three-tier Java 2 Platform, Enterprise Edition (J2EE) applications. The applications create a virtual view of the data center. All physical and some logical objects are defined in the data center model. The data center can be populated by either a graphical user interface (GUI) or an XML import function. Figure 3 shows the GUI, which contains the categories of objects that can be defined. Most of the functions available with the GUI are also available with a Web services interface.
Figure 3. Viwing the Web based interface
The user interacts with the physical objects through their logical representations within the model. The objects within the data center have defined relationships. Figure 4 shows a graphical representation available in the product. The graphical interface is meant to represent, as closely as possible, the relationship between the physical and logical assets within the data center.
Figure 4. Data center model
In Figure 4, the stacks at the back of the figure represent resource pools, or free hardware that can be provisioned. Each pool can serve one or more application tiers. The applications, which belong to customers, are represented by the gray blocks. Each application might be made up of a number of tiers. For example, a Web server and a database server might be hosting a single application with two tiers.
Workflows
Interaction with any of the physical devices is through workflows, which are functionally similar to scripts. Workflows represent the set of steps that must be followed in a data center environment to carry out an operation. You could use a workflow to:
- Allocate or remove a server to a cluster
- Run remote commands
- Configure network devices
- Enable a network port
- Install and uninstall software
Workflows are managed with the GUI. You can use this interface to capture best practices. Workflows are reusable, and one workflow can call another workflow. Using this architecture, software vendors can write workflows for their software and allow it to be manipulated in an On Demand environment. Workflows for a single product can be packaged into an automation package to be distributed.
Autonomic managers and the control loop
Within the autonomic computing context, ITITO and ITPM are autonomic managers. As shown in Figure 5, autonomic managers define a control loop (MAPE-K loop) with the following parts:
- Monitor
- Analyze
- Plan
- Execute
Figure 5. Autonomic manager control loop
Actions are taken through effector operations. Sensors look at the current state of the managed resources, and effectors can change the current state. The entire data center is the set of managed resources.
ITITO and ITPM autonomic managers continuously monitor the system and handle events that need action to be taken. As with other managers, they monitor the environment using sensor operations and analyze what is found. ITITO and ITPM then plan and execute any specific actions needed. If no actions are needed, the autonomic manager returns to monitoring. For example, if servers in a cluster are experiencing high utilization, the system could decide to provision an additional machine. The system can then return to monitoring, and if utilization drops, the server can be deprovisioned and made available to other clusters. The components within ITITO and ITPM that perform these functions are described in Core components.
Core components
ITITO and ITPM have several interoperating components that provide the overall functions of the products. These components can also interoperate with other products, which is covered in Integration. The core components are:
Figure 6 shows the relationships between the core components. The actual data center containing all the physical and logical resources is represented at the bottom.
Figure 6. ITITO and ITPM core components
Data acquisition engine
Status information about resources within the data center are collected by the data acquisition engine. This engine represents the sensor in the MAPE-K loop. The data acquisition engine can collect information about:
- SQL transactions per second
- Load balancer arrival rate
- Operating system I/O and memory utilization
- Server CPU resources
The information collected by the data acquisition engine is fed into the application controller.
Application controller
The application controller is responsible for making decisions about what resources are requested for each of the managed applications. Therefore, there are multiple instances of the application controller; one for each set of applications defined. The application controller represents the monitor in the MAPE-K loop, but it also, in a way, contains its own MAPE-K loop. The three subcomponents of the application controller are:
- Prediction component
- This does what its name implies; it uses the data it gathers, historical metrics, and predicts future demand. It analyzes the data for trends and patterns such as peak usage at a particular time or day of the week. It is also able to distinguish between one-time spikes and periodic events. The prediction component is always on and cannot be manipulated.
- Workload modeling component
- This is used to estimate each application environment's response to incoming traffic using the predicted demand load from its predictive component, and data gathered from the data acquisition engine. It uses a linear regression model to determine how the application environment will perform. This component looks only at CPU utilization.
- Classification component
- This uses all this information to decide if the defined service level objectives (SLOs) will be breached. If so, it passes requirements on to the global resource manager (GRM).
Global resource manager
The GRM manages the overall data center. It receives requests from each of the application controllers and uses several subcomponents to make an optimal decision. The GRM represents the analyze, plan, and knowledge components in the MAPE-K loop. The GRM has four primary subcomponents:
- Resource broker
- Manages all the resource pools and service requests from the application controllers
- Optimization and stabilization components
- Assist in deciding how requests for competing resources should be handled, and stabilize the data center as these changes are processed
- Resource pool manager
- Determines exactly which server needs to be added or removed from each of the application environments
After the GRM has decided on a set of actions, it passes the requests on to the deployment engine.
Deployment engine
The deployment engine is responsible for creating, storing, and running the repeatable steps, called workflows, that automate the configuration and allocation of data center assets. A single workflow can represent, for example, a software installation, a parameter change, or a server deallocation. The deployment engine represents the execute and effector components of the MAPE-K loop, and also contains some of the knowledge features.
The deployment engine converts generic, high-level configuration requests to corresponding device-specific configuration commands, thereby abstracting the operator from the actual device. The deployment engine can also accept manual commands from the console. So, an operator could issue a command, such as turn port off, without knowing the actual command that executes under the covers.
All workflows are stored in a database. When a request is received, the deployment engine searches the database to find and execute the workflow. When a workflow executes, the following steps are performed:
- Each step in the workflow is examined to identify the device that must run the command.
- A command corresponding to the step is created.
- The command is converted to a format that the target device can recognize and process.
- The formatted command is sent to the target device.
- The target device sends a response to indicate success or failure.
- Depending on whether there is success or failure, appropriate action is taken based on the workflow logic.
- When all workflow steps are complete, the status of the device is updated in the data center model.
Integration
With the workflow architecture, ITITO and ITPM can be made to perform a large variety of functions. However, its strength is really in orchestrating and provisioning. Currently, ITITO and ITPM can use performance metrics gathered from IBM Tivoli Monitoring (ITM), and ITM can act as the sensor and monitor. There are many tools that monitor performance, distribute software, or do event correlation. These tools are mature, and have extensive capabilities. ITITO and ITPM can use their functions by integrating with many of these products, such as Tivoli Enterprise Console, IBM Tivoli Monitoring, IBM Tivoli Configuration Manager and more.
| | Simple Object Access Protocol (SOAP) is a popular Web service protocol. |
|
When a workflow error occurs, ITITO and ITPM can send an event to IBM Tivoli Enterprise Console. In turn, many systems management consoles could initiate workflows using ITITO and ITPM's SOAP interface. With this interface the possibilities are endless. As you move forward there will be more integrated functions. ITITO and ITPM will coordinate the activities of the many management products and functions that are needed within an enterprise data center.
Summary
As the enterprises move toward On Demand, there is an essential need for higher degrees of automation to give you the simplicity you require to quickly respond to business changes. ITITO and ITPM are key components of such a vision because they:
- Can coordinate and integrate with the activities you require
- Provide you with an abstract interface into what is generally an extremely complex environment
- Have integration capabilities that let you extend what you already have and build on it
Much of what has previously just been a vision for autonomic computing is now a reality with ITITO and ITPM.
Resources
About the author | | | Indran Naick is an e-business Architect for IBM Developer Relations Technical Consulting in Austin, Texas, which provides education, enablement, and consulting to IBM business partners. Indran has over 14 years of industry experience. He joined IBM in South Africa in 1990. Prior to being transferred to Austin, he served as a Software Solutions Architect, offering consulting to a number of financial and government institutions. He has authored a number of publications and is a graduate of the University of the Witwatersrand in South Africa. He can be reached at indrann@us.ibm.com. |
Rate this page
| |
