| The Open Grid System Architecture (OGSA) Common Management Model [1] (CMM) is an abstract representation of real IT resources such as disks, file systems, operating systems, network ports, and IP addresses. The CMM can also be an abstract representation of logical IT resources, which can be a composition of the physical IT resources to build services and complete business applications. Some of the most important and commonly utilized terms in the management of resources are "manageable resource," "manageability," and resource "management." Key Terms to Understand Manageable resource is any IT entity that has some state to which the management operations can be applied. A manageable resource can be any entity, hardware (hard drives ), software components (a database), complete applications (help desk system), and even transient things such as print jobs. Manageability is a concept whereby a resource defines information that can be utilized to manage the resource. Manageability details all the aspects of a resource that support management, including interaction with a resource from the management applications. Management is the process of monitoring, modifying, and making decisions about a resource, including the capabilities that use manageability information, to perform activities or tasks associated with managing IT resources. |
The CMM is a "single" model for management that can be utilized with, and extended for, multiple grid resource models; however, it does not define a resource information model (e.g., CIM, SNMP, JMX), which is the job of the other standards organizations (e.g., DMTF, JCP). The CMM defines a set of common management interfaces by which these manageable resources are exposed to the external management applications for the sole purposes of managing these resources. In CMM, every management resource is represented as a grid service instance that possesses a state, a unique instance identifier, and operational interfaces. Figure 10.1 depicts the grid services facade. Figure 10.1. The manageable resource grid services facade.  Figure 10.1 shows a manageable resource and its facade grid service that provides CMM-specific manageability interfaces and domain-specific interfaces. One must be certain on the difference between manageability interfaces and domain-specific interfaces. Manageability Interfaces Every resource represented by CMM has a grid service facade that represents the underlying resource, and exposes a set of canonical interfaces and behaviors common to all the CMM services. This grid service has a state that corresponds to the resource state and a managed lifecycle model. Domain-Specific Interfaces Every CMM resource exposes a number of domain-specific interfaces, in addition to the canonical manageability interfaces for its management applications. These domain-specific interfaces are tightly coupled to the domain in which these resources are defined. As an example, we can consider the case of a resource instrumented in CIM. This resource exposes a standard CMM manageability interface and, in addition, exposes some CIM-specific interfaces (e.g., a CIM Operating System interface) to deal with the resources. These interfaces provide access to the resources but do not represent the CMM-managed resource behavior. The OGSA CMM specification defines three aspects of manageability: -
An XML schema (XSD) for modeling the resource manageability information -
A collection of manageability portTypes -
Guidelines for modeling resource New Constructs for Resource Modeling A resource's manageability information is modeled using the XML schema. CMM-defined extensions and additional data types (i.e., XML attributes) allow those manageable resources to provide additional information to the management applications. In order to better capture the data, CMM defined the following new data types: counter and gauge. In addition to these data types, CMM defined XML attributes that are classified as: Let us now examine the core port types exposed by the common management model. CMM-Defined Manageability Interfaces The CMM-defined manageability interfaces are the WSDL portTypes that are defined as part of the management interfaces of a manageable resource. We can see that CMM is trying to factor out the common set of interfaces that can function against all the resources. These interfaces are called "canonical port types" that provide a consistent behavior and functionality to the management applications (Figure 10.2). Figure 10.2. CMM manageability port types.  There are two most important canonical port types defined for CMM. As we have previously seen in the OGSI specification, the GridService port type is the core interface and is present in all grid services, and it provides a set of common behaviors and operations. The other interface defined by CMM is the BaseManageablePortType. This contains common behaviors (e.g., service data) that must be implemented by all manageable resources. The behaviors represented by this port type include resource lifecycle data, relationships to other resource types and data, searchable resource properties, and resource groups to which this resource instance belongs within the respective environment. In addition to these standard canonical port types, a CMM resource can utilize other grid service port types as defined by the OGSI specification. One commonly utilized port type is service group; it is utilized to represent a grouping and collection behavior for a certain group of resources, or for enumeration of resources of the same types. Resource Modeling Concepts The primary components of the Common Management Model are data types (i.e., existing and new), additional XML attributes, service data, and their associated service data descriptions and port types. In general, a resource type is represented as a port type, the managed properties of the resource are represented as service data of the port type, and methods on the resource are port type operations. Let us now explore an important modeling concept of the CMM service composition, and how it models the granular resource models. The resources defined using CMM are generally coarse-grained services rather than granular or normalized resource model definitions. In other words, the service is self-contained with normalized resource models, and contains a few relationships to other services. We further explore this concept by using the case of a disk resource that has a model for manageability containing characteristics of the disk, a model for a set of error statistics, a model for its disk metrics, and a relationship model to a computing system resource. When we set forth to model this as a CMM service, all these behaviors are aggregated into the service; a CMM service is composed of manageability characteristics, error statistics, and metric models. In addition to this notion, all of this expresses a containment relationship to a computer system. Let us now explore further to better understand some of the core concepts defined in the CMM specification. These concepts are as follows : -
Service data and resource properties. Properties of a manageable resource are expressed as service data and grid service port type operations. "findServiceData" and "setServiceData" can be utilized to access and modify these properties. -
Base management port type and its behavior. This (BaseManageableResource) canonical port type contains service data elements that must be implemented by all manageable resources. This port type extends the OGSI GridService port type and adds service data that has valuable information about a manageable resource. Table 10.1 lists the common service data elements of this port type. Table 10.1. Service Data Elements in Base Management portType | Service Data Name | Description | | lifeCycleModel | Describes the states of the resource and/or substates through which the resource will transition. These are static service data values, which we will further explore later in "CMM Resource Lifecycle model." | | currentLifeCycleState | The current state of the resource and substate information, which we will further explore later in "CMM Resource Lifecycle model." | | serviceGroupType | The portType of the manageable resource that provides the service group function for manageable resource of this type. This static value is set in WSDL and must present only with the primary apex-derived port type in the hierarchy. This helps to "locate" a service group that holds these resource instances. | | searchProperty | Zero (or more) service data elements (i.e., properties) that are utilized for searching for a manageable resource. A service can use these values for caching and for searching. These are static service data values. | | relatedInstance | Expresses the relationship between management resources "instance," which we will further explore in the "Relationship and Dependency" section. | | relatedType | Expresses the relationship between management resources "type," which we will further explore in the "Relationship and Dependency" section. | As previously discussed, these service data values are accessed by the grid service port type's "findServiceData" and "setServiceData" operations. The "relatedInstance" service data is the only service data value in the BaseManageableResource port type that is mutable, and hence, the setServiceData operation is applicable to that service data for adding new related instances to the current resource instance. Resource Lifecycle Modeling For purposes of this discussion, a lifecycle is a set of states that a resource can sustain, including the valid transitions between those states. In CMM, this lifecycle is represented by the lifecycle model service data of the base management port type. This is the most complex modeling process in the CMM; the resource exists from the time they are created until they are destroyed , and they transition through a variety of states in between these two states. This complexity forces CMM to come up with a recommendable and generic lifecycle model for all the resources. Let us now explore this lifecycle model recommended by the CMM. It is important to understand that this is not the only possible model based on the resource complexity, lifecycle states, and transition logic; there may be other lifecycle models. This lifecycle model is different from a grid service lifecycle model, and there is no effort (as of today) to merge these models together. Let us now explore the proposed lifecycle model. Based on the proposed CMM common lifecycle model, there are five possible lifecycle states for a resource and the proposed operational state of that resource. These are noted as follows: -
Down In this state, a resource is created but cannot do useful work until it is up. Operational states are: -
Starting This is a transient state indicating that the resource is starting and the next state may be either up or failed. Operational states are: -
Up In this state, the resource is available and ready to perform the work. Operational states are: -
Idle : The resource is ready but is now not processing any job. -
Busy : The resource is ready but is busy with another job. -
Degraded : The resource is ready but is in a degraded condition where we cannot meet the expected quality of service requirements. -
Stopping This is a transient state where the resource is in the process of stopping. The next state may likely be either Failed or Down. Operational states are: -
Failed In this state, the resource is not available except for problem determination. Operational states are: -
dependencyFailure : This resource cannot be restarted because of the loss of a supporting/hosting resource. -
nonRecoverableError : This resource is not capable of being restarted because of critical errors. Based upon the above observations and conditions of the resource state, the following artifacts are defined by the CMM: -
An XSD that describes the structure of the lifecycle state element -
A service data element that defines the lifecycle model utilized by a resource -
A service data element that holds the current lifecycle value of a resource -
The XML attributes that describe the lifecycle characteristics of a service, including changeability, validity, volatility, and latency. These values are critical for management applications. The following XSD (Listing 10.1) describes the lifecycle model type as defined by the CMM: Listing 10.1. The schema definition for a lifecycle model. <xsd:complexType name="lifecycleModelType"> <xsd:sequence> <xsd:element ref="crm:lifecycleState" minOccurs="1" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:element name="lifecycleState" type="crm:lifecycleStateType"/> <xsd:complexType name="lifecycleStateType"> <xsd:sequence> <xsd:element name="subState" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:attribute name="name" type="xsd:NCName"/> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:attribute name="name" type="xsd:NCName"/> </xsd:complexType> The GWSDL port type defines the service data description for a lifecycle model, as shown in Listing 10.2. Listing 10.2. The service data definition for a lifecycle model. <sd:serviceData name="lifecycleModel" type="crm:lifecycleModelType" minOccurs="1" maxOccurs="1" nillable="true" mutability="static"/> As one will notice by observing the above constructs, this lifecycle model for service data is static, and hence, the GWSDL constructs contain the possible values of this service data description in the <staticServiceDataValues> section of GWSDL portType. A commonly utilized lifecycle value and its substates for the lifecycle model service data are described in Listing 10.3. Listing 10.3. The static service data values. <sd:staticServiceDataValues> <crm:lifecycleModel> <lifecycleState name="down"> <subState name="restartable"/> <subState name="recovered"/> </lifecycleState> <lifecycleState name="starting"> <subState name="OK"/> <subState name="error"/> </lifecycleState> <lifecycleState name="up"> <subState name="idle"/> <subState name="busy"/> <subState name="degraded"/> </lifecycleState> <lifecycleState name="stopping"> <subState name="OK"/> <subState name="error"/> </lifecycleState> <lifecycleState name="failed"> <subState name="dependencyFailure"/> <subState name="nonrecoverableError"/> </lifecycleState> </crm:lifecycleModel> </sd:staticServiceDataValues> This concludes our introduction to the resource lifecycle modeling. It should be noted that based on what has been previously discussed, the lifecycle model is a general-purpose lifecycle model, and we may need to also deal with new lifecycle state models for CMM. Resource Grouping Concepts in CMM The management applications need to locate manageable resources in the system. This manageable resource collection size may vary depending on the system and the environment. There is a problem of locating fine-grained resources in the system, as normal "registries" are not sophisticated enough to retain that much information. The service domain concept, which we will cover later in this book, will address this problem of service location with a federation of information across registries. However, it is still not sufficient to address the fine-grained resource problem. The CMM works to resolve this fine-grained resource problem by utilizing the natural grouping of resource concepts that exist in the system. To appropriately explain this natural grouping, based on resource types, we can consider the sample of a database server hosting some databases, and these databases in turn contain the tables. We can also infer that these containers are responsible for the management of the resources that it contains. The CMM container resource and the contained resource form a resource group. The CMM then uses the Service Group concept in the OGSI for managing these resources. Every manageable resource defined by CMM must implement the BaseManageableResource port type. As we have previously discussed, it is possible that a resource can be a container, which holds the same type of resources instance, in addition to the regular management port type. This use case is explained in Figure 10.3. Figure 10.3. Example of a manageable port type.  In this example, the database, the table, and the database server are manageable resources; however, the database server has more functionality and acts as a container (i.e., implementing OGSI ServiceGroup) for the resources belonging to that server. Relationship and Dependency among Resources There may oftentimes be relationships existing among many instances of manageable resources. This relationship model is not specific to the CMM; the service relationships exist in the grid and Web service environments. Let us take a look at these ideas in order to better familiarize ourselves with the two core concepts here: -
Relationships describe which resources are connected to each other and what type of connection exists; however, they do not describe the details of how one resource depends on the other. -
Dependencies add additional information to the relationship on exactly how one resource depends on another. For example, a database resource indicates that it uses a storage device and provides more details on the needs such as storage space. We will begin our discussion on the CMM relationship model with a simple example on relationships. Processes are created by operating system and the operating system is hosted by the computer system, which is a part of a cluster. CMM provides mechanisms to model these types of resource relationships (see Table 10.2). In CMM, the BaseManageableResource port type provides two service data definitions (relatedInstance and relatedType) to deal with a relationship. Table 10.2. CMM-defined relationship types. | Relationship Type | Description | | Hosts | Any resource "A" hosts another resource "B" if resource "A" provides an environment in which resource "B" is created and runs. The lifecycle of resource "B" is a subset of the lifecycle of resource "A" and resource "B" cannot exist without resource "A." For example, a database hosts the table within it. | | Contains | Any resource may consist of a number of other resources. Any contained resource has the same lifetime as the containing resource. If resource "A" contains resource "B," then if "A" installs "A," "B" gets installed and if "A" stopped "B" gets stopped. For example, a deployed J2EE application containing various modules. | | Federates | Any numbers of resources are in different hosting environments and are utilized together to form another resource. For example, an application includes a database and queue and they do not know each other but work together in the application. | | Aggregates | A number of resources are grouped together. For example, a resource that represents all computers in a department. | | Uses | A resource uses another resource. It is different from federates. For example, a security system uses a LDAP registry to hold user information. | | Implements | One resource is utilized to implement the function of another. For example, a database server is implemented as a Linux or Windows service. | These types of relationships exist in current programming environments and are explained quite well by the UML relationship model and dependency graphs. We believe that this CMM-specific relationship model should be elevated to the grid service and Web service worlds , with the appropriate modifications. We have now discussed the new concepts and canonical information provided by CMM. The resource's manageability information can be implemented using any of the existing management instrumentation methods, such as Common Information Model (CIM), Simple Network Management Protocol (SNMP), and Lightweight Directory Access Protocol (LDAP). The CMM resource model and management grid service are independent of the underlying service implementation and resource instrumentation. One important question that may come across is: What is the value CMM provides over a normal service interface to any existing resource instrumentation models? The answer lies in the fact that CMM is not just an algorithmic mapping from a grid service to resource instrumentation. Instead, CMM contains a more behavior-specific and self-contained resource management model. Also, the same resource model may map to multiple instrumentation choices, and this is a binding choice. Summary We can summarize the CMM discussion with the characteristics it exposes to the resource management world. These characteristics are as follows: -
CMM provides an abstract representation of the real-world physical resource or logical resources. -
CMM provides common manageability operations. -
CMM can overlay multiple resource instrumentations. -
Resources are now grid services containing four capabilities. -
Common lifecycle management -
Common resource discovery -
Common event notification -
Common resource attribute query -
CMM provides well-defined resource states. Two areas where the architecture needs to mature are as follows: | 