Like many other IT organizations, Intel IT is motivated to apply autonomic computing technologies to reduce operational costs and increase IT agility. The vision is that computing capabilities are autonomous and well-integrated, and that they can maintain themselves and control their own resources to deliver IT services in a consistent and continuous way. The autonomic enterprise vision is part of an agile IT vision, allowing an IT department to continuously adapt in a dynamic and automatic way, in response to changing business needs.

Creating a common enterprise "language"

A source of complexity in the enterprise is the diversity of communication protocols, usually proprietary, that leads to vexing integration efforts. A common language is needed so that enterprise components and systems can be discovered and freely communicate with each other. The PoC demonstrates the use of the WS-Management protocol stack. This is employed in front of each one of the stack layers, components, and systems in the enterprise, in a reusable fashion. It enables a standard, common and unified messaging layer that drives Managed Object (MO) discovery and provisioning. This enables a holistic approach to IT infrastructure management. Using a WS-Management protocol stack we were able to create a common communication approach for the entire enterprise manageability framework.

Figure 2: WS-Management stack in front of each component creates a common "language"
click image for larger view
 

The common communication framework simplifies manageability integration with the capability to automatically discover and control resources. This capability advances the notion of the autonomic enterprise, fulfilling the vision of agile IT.

Automated discovery

A key enabler of the evolution of the autonomic enterprise is the ability to dynamically discover all computing resources and immediately control them.

Dynamic, real-time discovery means the following:

1. The ability to detect when an MO comes onto the network or changes its state.
2. The ability to query the MO for its metadata.
3. Registration of the new MO instance in the Configuration Management Database (CMDB).

Immediate MO control is the ability to control the behavior of the object through business rules or policies. These policies are automatically provisioned to the MO when it comes online or changes its state.

Conceptually, the dynamic, real-time MO discovery process has three main steps:

1. As the MO comes online in the network, it announces itself by sending a thin message.
2. The manager gets the announcement and queries the MO end-points (through the manageability interface) for the required object Configuration Item (CI) information.
3. The manager then registers the MO in the Configuration Management Database (CMDB).

When an MO joins the network, or has a metadata change, it will interact with the backend IT management system (the Manager) in the following way:

1. Send an announcement: send a thin "Hello" message to a Discovery Proxy (DP).
2. Register the change: the DP processes the announcements and forwards them to the Manager.
3. The Manager then queries the MO for more information as needed for enterprise management.

The MO Catalog (following the WS-Management Catalog specification) contains the information needed by the Manager to pull all required data. These may include events that are exposed by the MO, available methods and how they can be used, and MO properties and attributes.

The Manager then creates a new CI record in the CMDB for the new instance of the object type (or updates the record if it already exists, for example, for a status change from "offline" to "online" or vice versa).

Figure 3: Managed-Object Discovery concept diagram
click image for larger view
 

The announcement process can be implemented through multicast or unicast. DP could be built-in as part of the Manager implementation.

Dynamic, automatic, and real-time MO discovery is an essential capability in the evolution toward a fully autonomic framework. Discovery is not limited to devices only, but must address all layers of the stack, including hardware, the Virtual Machine Monitor (VMM), operating systems, and applications. Probing for a change (pull model) doesn't answer all enterprise management needs because current and future enterprise objects are highly dynamic. A combination of pull model and push model is the most likely solution to the autonomic computing needs. The autonomic computing facilities will reconfigure themselves based on business need, load, fault management, and other factors in order to optimize service availability and throughput. Some key results of the discovery process are an up-to-date enterprise directory (CMDB, another key enabler of the evolution of an autonomic enterprise) and the functionality it needs.

Standards plays a fundamental role in the discovery process. The WS-Management Catalog is the key enabler for MO discovery. It is the entire set of metadata available from a WS-Management agent for a given Resource. WS-Transfer, which is part of WS-Management specification suite, is then used to pull the information out of the catalog. WS-Management is a standard communications protocol for communication between the different components.

Policy provisioning

Through the evolution of the autonomic enterprise, IT departments look to run their business based on a logical model that fits best with their business processes. This logical model is then mapped to physical business rules and policies. Those physical policies are provisioned to the corresponding physical MOs.

In this PoC, physical policies are stored in the CMDB, associated with the corresponding type of MO. Once a new instance of an MO type is discovered, its attributes (type, location, etc.) are matched with selection criteria in the CMDB to automatically trigger policy provisioning. A compliance tool, once triggered, provisions the policies to the newly discovered MO through the standard WS-Management protocol.

Figure 4: IT business model representation and physical mapping (policies)
click image for larger view
 

Federated event processing

Enterprise event management can cross system, domain, and company boundaries. It requires automated cooperation between multiple enterprise systems, including business layer systems, to make it part of an automated response system. The systems involved in processing an event include MOs, Management tool-sets, ITIL (Information Technology Infrastructure Library) functions, and other systems like the Known Error Database (KEDB). The events that MOs expose are described in the MO Catalog (WS-Management Catalog), which can be queried dynamically when needed.

Figure 5: Federated event processing
click image for larger view
 

When a new instance of an object type is discovered, the event management system is triggered. It subscribes to those events at the MO end-points that are of business interest. The subscription process can be done either directly by the event management system, or as part of policy provisioning when a new object instance is discovered. WS-Eventing (part of the WS-Management suite) provides the mechanism and protocol for Event Subscription.

When a failure or fault event occurs in an MO, the PoC takes a holistic approach, involving the technical and IT business layers. For example, an event is sent to the event management system using WS-Eventing; the event management system queries CMDB for additional information needed on the MO, and then process the event internally. The event management system queries the KEDB, using WS-Transfer, for a potential known resolution for the problem. The KEDB replies with the resolution action to be executed (also using WS-Transfer).

In cases where the MO cannot make a decision on its own, the event management system sends a request to the change management system (the ITIL function at the business layer) for further actions to correct the failure.

The change management system replies with approval (both using WS-Transfer), and a request is sent to the compliance system (also using WS-Transfer) to execute the corrective action.

The change authorization may include information such as the window for maintenance and the expected time to complete. The compliance system then executes the corrective action using WS-Transfer. All communication in this scenario is implemented using WS-Management standard protocol stack to enable the holistic approach required to automate event management.

Role of Intel® AMT

During the PoC we used an Intel AMT simulator as part of the device's manageability stack. It had a fundamental role as the root of the discovery and provisioning processes.

When the device is first plugged into the network, the simulator is automatically and immediately discovered through the process described above. As part of this discovery the simulator sends its identification number as a unique identity key representing the host platform. This key serves as the root of the discovery and provisioning process for the entire stack, and it announces the existence of the new device as a computing resource.

As part of the PoC we were able to automatically discover and provision a new server platform out-of-the-box by having Intel AMT initiate the discovery process for the server OOB.

In response to the discovery of a new server, policies kept in the CMDB directed the bare-metal OS provisioning to be performed OOB via Intel AMT.

Once the OS was brought online it was discovered and provisioned, and the processes of discovery and provisioning were repeated for the entire stack (now IB, or via a WS-Management interface to the OS).

Using this approach we were able to take a new hardware platform out of the box and automatically add it to an existing IT service for added computing power, with minimum delay and manual intervention.