Today, information technology (IT) resources are managed using a variety of incompatible and often proprietary interfaces and protocols. Requirements for management information regarding the resources need to be specifically programmed to address new resources and in many cases the specific programming is not updated as new versions of the managed elements become available.
The problem of managing disparate managed elements is becoming more acute as systems are increasingly developed using managed elements that are deployed in remote locations and accessed via information networks, such as the Internet. Generally, the resources to be managed are not readily identifiable when the resources are highly distributed and independent of one another. Further, it is difficult to obtain information regarding properties and attributes of the resources, and protocols for exchanging management information with the resources. A further difficulty lies in determining the relationships among the resources used in a system to pinpoint operational problems when one or more of the resources do not respond as expected.
In today's high density data centers (HDDC) that support computing on demand and dynamic adaptive infrastructures, the complexity imposed on the data center supervisor to create and maintain a plethora of proprietary scripts and commands is not sustainable. The complexity and speed of dynamic change experienced in today's HDDC require that hardware vendors standardize the command set used to configure, boot and re-provision the hardware, software, and other managed elements.
In some embodiments, a computer product stores information regarding Common Information Model (CIM) managed elements that reside in remote computer systems. The media also stores association information for the managed elements to allow a topological graph of instances of the managed elements to be created without requiring extra operations to determine how the managed elements are associated to one another.
In other embodiments, a computer system includes logic instructions operable to provide grammar production rules for converting a user-friendly target name to a CIM class name. The target name for a managed element of a CIM_ComputerSystem can include at least one of the group consisting of: ComputerSystemPackage, HostedService, HostedAccessPoint, HostedCollection, HostedDependency, and AssociatedME (ManagedElement).
In some embodiments, a system for locating physical components in a data center determines the physical location of at least one managed element using a property of the at least one managed element, wherein the managed element is assigned a unique name within a container and the property specifies a value that indicates the physical location of the managed element within the container, further wherein the value is provided in a format that is standardized for the type of container.
In some embodiments, systems and methods disclosed herein are operable to receive a command line; parse the command line; and map tokens in the command line to a target entity that corresponds to a Common Information Model (CIM) name. The target entity is an instance of a managed element, which may or may not have services directly provided for by a Common Information Model provider.
Various other features and advantages of embodiments of the invention will be more fully understood upon consideration of the detailed description below, taken together with the accompanying figures.
Systems and methods disclosed herein specify embodiments of a common command line syntax and/or message protocol for managing computer resources in various distributed and local environments, such as Internet, enterprise, and service provider environments. In some embodiments, unique indices to instances of an object class are generated that enable consistent addressing across different types of computer resources. The addressing protocol is interoperable among various implementations, CPU architectures, chipsets, and vendor/operating environments.
Referring to
Although various embodiments discussed herein use the Common Information Model (CIM) for managing managed elements 102, it is anticipated that systems and methods disclosed herein can be implemented using other models and standards in addition to, or instead of, CIM to manage elements 102.
As described in the “CIM Tutorial” by the Distributed Management Task Force, (http://www.wbemsolutions.com/tutorials/CIM/ [June 2003]), the CIM is a model for describing overall management information in a network/enterprise environment. CIM is comprised of a Specification and a Schema. The Specification defines the details for integration with other management models, while the Schema provides model descriptions for systems, application programs, networks, and Devices. The CIM Schema enables application programs from different developers on different platforms to describe management data in a standard format so that information can be shared among a variety of application programs.
In some embodiments, an Extensible Markup Language (XML)-CIM Encoding Specification defines XML elements, written in Document Type Definition (DTD) format, which can be used to represent CIM classes and instances. Information can be transferred between management platform 106 and one or more servers 108 using the XML elements. XML-CIM Operations 114 defines a mapping of CIM operations onto Hypertext Transfer Protocol (HTTP) that allows implementations of CIM to interoperate in an open, standardized manner. Note that other protocols can be used for communication between server 108 and management platform 106.
In the embodiment shown in
Instrumentation 122 can be used to get information about a managed element 102. In some embodiments, instrumentation 122 can be implemented as Windows Management Instrumentation (WMI), which is a component of the Windows Operating System by Microsoft Corporation of Redmond, Wash.
Management platform 106 is configured to execute logic associated with Command Line Protocol (CLP) engine 110, one or more management access points (MAP) 126, XML to CIM operations 114, client interface(s) 116, listener interface(s) 128, object manager 130, and providers 132.
Object manager 130 can be implemented as part of management platform 106 and is assumed to be available regardless of the operational state of server 108 (e.g., stopped, running, faulted, etc.) Object manager 120 can be implemented as part of server 108 and may be unavailable if server 108 is not operating. Upon request, object managers 120 and 130 can perform operations to determine the position of managed elements 102 in their respective containers 104, and support management of managed elements 102 through the agency of MAP(s) 112 and/or 126.
Containers 104 are often configured to hold one or more rows and/or columns of managed elements 102, analogous to a one, two, or three-dimensional table or x, y, z Cartesian coordinate system. Various types of devices can be used as containers 104, such as equipment racks, slots in a chassis, positions on a printed circuit board, racks in a bay, computer-readable media for storing software, and other suitable devices configured to hold one or more managed elements 102.
Management console 134 can issue commands to MAP 126 in management platform 106 or MAP 112 in server 108 to perform management actions on server instrumentation 122 in several different ways. As a first alternative, console 134 can issue a command to MAP 126 to use Client IF 116 on management platform 106 to access instrumentation 122 via object manager 130 and object providers 132. A second alternative can include console 134 issuing a command to access instrumentation 122 via MAP 126, Client IF 116, object manager 120, and object providers 124. A third alternative to access instrumentation 122 includes using console 134 to command MAP 126 to use Client IF 116 on management platform 106 to access object manager 130 on management platform 106, object providers 132, object manager 120 on server 108, and object providers 124. As another alternative, console 134 can command MAP 112 to use Client IF 116 on server 108 to access object manager 120, object providers 124, and then instrumentation 122. A fifth alternative uses console 134 to command MAP 112 to directly access instrumentation 122. A sixth alternative includes console 134 commanding MAP 112 to use Client IF 116 on server 108 to access object manager 120, object manager 130 on management platform 106, and object providers 132 to access instrumentation 122. A still further alternative uses console 134 to command MAP 112 to use Client IF 116 on server 108 to access object manager 120, object providers 124, and object manager 130 and object providers 132 on management platform 106 and then instrumentation 122 on server 108.
Note that in some implementations, object manager 120 on server 108 may access providers 132, and object manager 130 on management platform 106 may access providers 124.
One kind of management command that management console 134 can send to MAP 112 or 126 is a command to create an event subscription in object manager 120. If such an event subscription has been created, and instrumentation 122 detects an event, such as a failure or other event, instrumentation 122 can notify object providers 124 of the event. Object providers 124 can in turn cause object manager 120 to send an indication to listener IF 118 on server 108 and/or listener IF 128 on management platform 106. As an alternative, object manager 120 can send the event indication to object manager 130 and then to Listener IF 128.
Traditionally, one drawback to using the CIM Schema alone for resource management is that users are required to enter long, complex class names to access information about managed elements 102. Embodiments of system 100 allow user-friendly tags (UFTs) that help overcome the burden of entering long, complex class names associated with the CIM Schema. Various features of addressing schemes associated with system 100 can also adapt the CIM Schema's containment hierarchy to provide a non-ambiguous method of addressing managed elements 102 including physical elements, logical devices, services, service access points, system specific collections, and virtual systems within a single computer system, as further described herein.
XML-CIM operations 110 define how MAPs 112, 126 access object providers 124, 132 through object managers 120, 112 and create, delete, retrieve, and modify object instances. Sufficient information is stored within the containment profiles 136 and MAPs 112, 126 to construct names for managed elements 102 and allow MAPs 112, 126 to exchange instance information with instrumentation 122.
When server 108 is operating, information for managed elements 102 can be retrieved and modified using both MAPs 112, 126. When server 108 goes down, MAP 112 will not be available. A user can, however, retrieve and modify information regarding managed elements 102 from MAP 126 using CLP commands that are input to management platform 106 and passed to instrumentation 122 that remains operational even when server 108 is down. Instrumentation 122 that remains operational when server 108 goes down might include devices such as a Baseboard Management Controller (BMC) as specified by the Intelligent Platform Management Interface (IPMI) standard, version 1.5 or 2.0, or other devices. Note that server 108 may itself be a managed element 102, therefore information regarding any error conditions or faults may be available to help determine system status and whether server 108 can recover and resume operation
Client interfaces 116 are used to communicate information between MAP 112 or 126, which perform XML-CIM operations 110, and object managers 120 and 130. Object managers 120, 130 pass commands to one of a plurality of object providers, which operate on instrumentation 122 that instruments managed elements 102. For example, when a management application requests data from object manager 120, object manager 120 uses a provider 124 to pass the request to the respective instrumentation 122. Providers 124, 132 are classes that perform functions in response to a request from object managers 120, 130, such as mapping instance data from instrumented managed elements 102 to CIM classes. Instrumentation 122 can, for example, get information from managed elements 102, pass the information to provider 132 and object manager 130 in the form of CIM classes, map the information from CIM classes to formats required by managed elements 102, get the required information from the CIM class, and pass the information to managed elements 102 in native device formats.
A client request is typically input to CLP engine 110 directly from a user by entering CLP commands or other suitable commands/protocol at management console 134. A series of commands can also be input via a script that is launched via management console 134. Requests in the form of CLP commands can also be input automatically to CLP engine 110 via a client application program (not shown) or other suitable method.
Object manager 120 or 130 calls the correct provider(s) 132, 124, which access the correct instrumentation 122 in response to the client's requests, such as creating/updating a CIM namespace, class, or instance. The provider(s) 132, 124 and instrumentation 122 process the incoming request and return a response to the object manager 120 or 130. The object manager 120 or 130 passes the response to the client.
An event subscription can be included in object manager 120 and/or 130 that allows providers 132, 124 to generate indications, by which subscribers can be notified of the occurrence of events. An event is an occurrence in a computer system detected by instrumentation 122 to which an event monitoring application might need to respond, for example, failure of a fan or power supply in server 108.
Object managers 120, 130 and/or providers 132, 124 may poll enumerated instances of managed elements 102 at a specified polling interval to find any new, changed, or deleted instances between the two sets of enumerated instances. Object Managers 120 and/or 130 may generate an indication when a static instance is created, modified, or deleted. Providers 124, 132 can generate indications for the intrinsic events that occur in the dynamic instances of the classes they support. A subscriber can create one or more event filters with one or more event handlers. Indications of events are typically not delivered until a client creates a subscription for the events. A client application can add Listener interface 128 to register for indications of events. Object manager 120 and/or 130 can generate indications of events that are specified by an event filter when a client subscription is created.
CIM uses Object References to address objects in the CIM model. One problem is that the syntax of Object References is not concise or user friendly, and is not easily used in scripts. For example, an Object Reference can typically include over 80 characters, which is cumbersome for a user to enter manually. The abbreviation “CIMREF” for CIM Object Reference is used herein. Another problem relates to mapping command verbs to specific object types, parameters, and methods. CIM-XML Operations 110 over Hypertext Transfer Protocol (HTTP) provide a command interface to object manager 120 and 130, but it is not suitable for a user-interactive, browser session-based command line protocol. Embodiments disclosed herein solve these and other problems. Further, commands and object references are disclosed herein using Augmented BNF (ABNF) grammar notation, as specified in the Internet Engineering Task Force's (IETF's) standard RFC2234, by way of example and are not intended to limit embodiments of the invention to a particular grammar notation.
One or more profiles 136 can be defined for the addressing scheme to simplify addressing managing elements 102 and support rendering a graph of physical and logical topology of elements 102. For example, a Containment Profile can be defined to describe the legal associations to use to address a target instance. The addressing scheme further provides a unique target to accurately address managed elements 102. In some embodiments of the addressing scheme, MAPs 112, 126 implement hierarchical, logical containment, and physical containment profiles 136 for specific hardware platform types and profile components for specific manageability domains, as further described herein.
A target name is a unique user-friendly tag (UFT) or CIM Object Reference. Target names can be translated to CIM Object References and vice versa. In some embodiments, the following CLP command syntax can be used to set a target name for a session.
Set Target=[[“/”] targetUFT [/targetUFT]*] [CIMREF]
User Friendly Tags (UFTs) can be nested to drill down to an element 102 enclosed within a system, for example, a slot in a chassis or a disk drive. Note that a slash character “/” is used in the definition above as a separator between components of the target name. Other suitable characters, such as a period “.”, can also be used as separators.
There is a 1 to 1 mapping between a UFT and a CIM class name. The required class names are defined by physical and logical containment profiles 136. Tables 138 in MAPs 112, 126 store a unique UFT within the scope of each managed element 102. CIM divides its object schema into logical and physical realms. Logical entities derive from CIM_LogicalElement. Physical entities derive from CIM_PhysicalElement. Aspects of managed element 102 that are not related to a three-dimensional concrete real world existence are modeled as logical objects. A PhysicalElement is an object that occupies space and can be touched. A LogicalElement, on the other hand cannot.
For example, a ComputerSystem is a LogicalElement that comprises all the components of a computer including hardware, software, firmware, processes, file systems, internet addresses, logs, etc. A disk drive is the physical form factor (a PhysicalPackage) that encloses the logical aspects of the disk, such as storage volumes, disk partitions, and memory blocks. In CIM, only the form factor is a PhysicalPackage and all the rest including the logical entity that describes the kind of disk drive (floppy, CD, DVD, etc.) are LogicalDevices. An embodiment of a CLP command set is described in the following paragraphs. Note that other suitable commands, required elements, optional elements, return values, and error conditions, can be used in addition to, or instead of, the CLP commands listed below.
CLP Set Command: The Set command applies a SettingData instance referenced by a UFT or a CIMREF to the target instance (e.g. a Server or Device). Specifics about when to shut down, restart, power off/on, etc can be defined in a SettingData instance to accomplish complex tasks in a single set command (e.g. provision multiple servers with the same configuration). Alternatively, a PropertyName=value list can be used to set one or more configurable parameters on the target. The Set command does not require creating a SettingData instance. Set action updates the Current SettingData associated with the target.
CLP Boot Command: The Boot command brings up a Server system 108. The optional BootLocator is an index into the user configurable ordered array ComputerSystem.BootOrder[ ] property. For instance, array location 1 may be a floppy drive, location 2 a CD drive, location 3 and higher may be hard drives or a boot service. If the BootLocator option is missing, the boot location search process starts with array location 1 and terminates when the first boot image is found.
Syntax: Boot [targetUFT|CIMREF] [BootLocator]
CLP Reset Command
Syntax: Reset [targetUFT|CIMREF] [Warm|Cold]
Examples:
CLP Power Command
Syntax: Power [targetUFT|CIMREF] [On|Off]
Examples:
CLP Halt Command: Shuts down the target instance according to the semantics of the specified Halt option.
Syntax: Halt [targetUFT|CIMREF] [Shut Down|Dump]
CLP Show: Instance Properties Command: returns all the supported properties of the target instance.
Syntax: Show [targetUFT|CIMREF]*(PropertyName)
Examples:
CLP Show: instance names Command: returns all the names of that target type in the management platform metadata tables 136.
Syntax: Show [targetUFT|CIMREF] targetCN
Examples:
CLP Create Command: Creates an instance of the target type in MAPs 112, 126 with the values in the property list. The value of the default target is used to scope the new instance. Note, the types of instances a user may create include IndicationFilter, ListenerDestination, Subscription, Security Certificate, etc. Other targets like System, Subsystem and Devices typically return error codes.
Syntax: Create UFT targetCN*(name=value)
CLP Remove Command: Removes the target instance from MAPs 112, 126.
Syntax: Remove [targetUFT|CIMREF]
Examples:
CLP Indications Command: The Create, Set, and Show commands can be used to manipulate IndicationFilter and ListenerDestination for events.
CLP Subscribe Command: Register to receive indications defined by IndicationFilter at ListenerDestination (default) or De-register to cancel subscription.
Syntax: Subscribe (IndicationFilterUFT|CIMREF)
Note that other suitable commands, required elements, optional elements, return values, and error conditions, can be used in addition to, or instead of, the CLP commands listed.
Table 1 shows some examples of CIM_Class Names and corresponding UFTs for items commonly found in computer systems:
Embodiments of addressing schemes described herein define legal targets for CLP commands and provide a human-friendly way to accurately address CIM objects (classes and instances) in metadata tables 136. In some embodiments, addresses for managed elements 102 are based on profiles 136 that specify architectural associations between managed elements 102 and management platform 106. Profiles 136 define rules and guidelines to model specific hardware platforms such as a generic base system, modular systems such as blade servers, and other architectural features such as clustering, redundancy (resource sharing) and virtual machines. Further, profiles 136 can define rules and guidelines to model specific management domains such as Boot Control, Power Control, Firmware Update, and the like.
In some embodiments, associations in profiles 136 define hierarchies in the CIM model that can be used to define specific paths to leaf or end node instances, in the same manner as a directory structure provides a hierarchical directory path to a leaf file or directory in a file system. Delimiters, such as forward slashes (/) in the address denote associations and the terms between delimiters are User Friendly Tags (UFTs). In some embodiments, there are two types of UFTs; User Friendly class Tags (UFcT) and User Friendly instance Tags (UFiT). A UFcT is typically defined for each class used in profiles 136. UFcTs provides a simple short user friendly synonym for specific a CIM class. UFiTs are built based on the instance's UFcT and addressing rules further described herein.
A new CIM Property, ManagedSystemElement.UserFriendlyTag, of type String, can be used to hold an instance's User Friendly instance Tag (UFiT). Profiles 136 simplify the complexity of the CIM model for the user and insure interoperable implementations between managed elements 102. Profiles 136 are also used by CLP engine 110 to map CLP commands to managed elements 102. CLP engine 110 uses the UFTs on the command line to target managed elements 102. A fully qualified path of UFTs allows a simple mapping of CLP targets to CIM Object References, thus providing support for communication between MAPs 112, 126 and Servers 108, Clients, and instrumentation 122. These features combine to effectively create an embedded lightweight CIM Server in MAPs 112, 126.
For each CIM class used in profiles 136 there is a 1 to 1 alias mapping to a UFT. Standard instance UFTs are derived by adding an index, such as an integer suffix, to the class UFT root. Some samples of instance UFTs include:
system, card, cpu, disk, etc.
system0 . . . 1, card0 . . . n, cpu0 . . . n, disk0 . . . n
Similarly, UFT instance names for vendor aliased classes are created by adding an index to the aliased class UFT. For example if cell is an alias for card, then instances of cell would be cell0, cell1, and so on. Table 2 shows some target name examples:
Note that more than one UFT alias can be defined for the same managed element 102. MAPs 112, 126 typically follow a set of rules to support unique user friendly target naming. In one embodiment, the rules include the following:
Note that MAPs 112, 126 can operate according to other rules in addition to, or instead of, the rules disclosed herein.
The CIM standard namespace is flat. Delimiters, such as the forward slash “/” character, merely separate terms in standard CIM Object References and do not denote a directory-like structure. Therefore, CIM namespaces cannot be aggregated to allow a command to be performed on multiple managed elements 102 with one command. Further, CIM requires instance keys to be used to address instances, which are unwieldy for a human operator to enter. Accordingly, embodiments of address schemes disclosed herein are designed to be easy to use, and to provide a hierarchical namespace similar to a directory/file system. The addressing scheme provides the capability to move up and down an address path from the root to the target, and supports aggregation of namespaces by aggregating root nodes at discrete points. For example in a large data center, a single MAP 112, 126 may be responsible for a single rack. There may be several racks in the data center each being managed by a separate MAP 112, 126. An intelligent management application, such as the OpenView system by Hewlett-Packard of Palo Alto, Calif., can aggregate the namespaces of each MAP 112, 126 about a single node. As long as each aggregated MAP node has a unique tag, such as MAP1, MAP2, . . . MAPn shown in
A Physical containment profile 210 (
The HostedDependency relationship in
show/system1/rack1/chassis2/raid1/swid
where raid1 is the raid controller and swid is the property CIM_SoftwareIdentity. This command returns the associated SoftwareIdentity for the disk array controller “raid1”.
The address hierarchy shown in
Referring to
A single Rack may contain 0 . . . n Chassis; a single Chassis may contain 0 . . . n Packages; a single Package may contain 0 . . . n Components or Connectors or PhysicalElements. A PhysicalElement Realizes a LogicalDevice so any PhysicalElement by association may “contain” a LogicalDevice.
Properties are defined for elements of containment profile 210. For example, properties of PhysicalComponents can include:
Removable,
Replaceable, and
Hot Swappable.
Properties of PhycicalConnections can include:
ConnectionPinout,
ConnectorType,
ConnectorGender,
ConnectorElectricalCharacteristics,
OtherElectricCharacteristics,
NumPhysicalPins,
ConnectorLayout, and
ConnectorDescription.
Properties of PhysicalFrames can include:
CableManagementStrategy,
ServicePhilosophy,
ServiceDescriptions,
LockPresent,
AudioAlarm,
VisibleAlarm,
SecurityBreach,
BreachDescription, and
IsLocked.
Properties of Chassis can include:
NumberofPowerCords,
CurrentRequiredorProtocol
HeatGeneration,
ChassisTypes,
TypeDescriptions,
ChassisPackageType,
ChassisTypeDescription,
MultipleSystemSupport, and
RackMountable.
Properties of Rack can include:
TypeofRack, and
CountryDesignation.
Note that other suitable properties can be used in addition to, or instead of, the properties disclosed herein.
A PhysicalElement is one of CIM_Package (Frame, Rack, and Chassis), CIM_Component, CIM_connector, or CIM_link. A package may contain any PhysicalElement thus the containment is recursive. A Chassis is a package and so it may be “in a” chassis thus the hardware hierarchy is n deep. The physical containment profile 210 is suitable to model any arbitrary computer hardware topology.
A PhysicalElement is contained in at most one container. The CIM associations prescribe how containers are ordered. The specific association is never ambiguous because it is inherent in the instance. That is, a PhysicalElement instance can have only one containment association. If a chassis is in a rack, it will be the Chassis CIMREF in ChassisInRack. If a chassis is in a package it will be the Package CIMREF in PackageInChassis, but not both PackageInChassis and ChassisInRack. MAPs 112, 126 (
where xxxUFT is the User Friendly Name (UFT) of the instance, as further described herein. If the UFT instance name is unique within its container, the target path addresses at most a single unique instance. The associated instance information is obtained using the target instance's associations. That is, the specific instance, rackUFT, has a ChassisInRack association with the specific chassisUFT wherein the rackUFT is the GroupComponent and the chassisUFT is the Part Component.
When the containment rules shown in Table 3 are followed, contained elements are finite and unique.
Referring to
By definition, a single computer system may contain 0 . . . n services; 0 . . . n service access points; 0 . . . n system specific collections; and 0 . . . n virtual systems that contain 0 . . . n logical devices that may have HostedDependency associations to real logical devices. The containment rules guarantee that a virtual device will not have a Realizes association to a physical element and that it will be in the dependent role of the HostedDependency. Properties are defined for elements of logical containment profile 220. For example, properties of LogicalDevice can include:
CreatorClassName,
DeviceID,
OtherIdentifyingInfo,
IdentifyingDescriptions,
Reset,
SaveProperties, and
RestoreProperties.
Properties of PhysicalElement can include:
Tag,
CreationClassName,
Manufacturer,
Model,
SKU,
SerialNumber,
Version,
Part Number,
OtherIdentifyingInfo,
PoweredOn,
ManufactureData,
VendorEquipmentType,
UserTracking, and
CanBeFRUed.
Properties of ComputerSystems can include:
NameFormat,
OtherIdentifyingInfo,
Identifying Descriptions,
Dedicated, and
ResetCapability.
Properties of Services can include:
CreationClassName,
Name,
PrimaryOwnerName,
PrimaryOwnerContact,
StartMode,
Stared,
StartService, and
StopService.
Properties of ServiceAccessPoint can include:
CreationClassName, and
Name.
Properties of SystemSpecificCollection can include:
InstanceID.
Physical containment profile 210 (
Target names are generally based on the following containment rules:
A virtual system follows all the logical containment rules of a physical system except it does not “realize” any physical components and it is dependently associated (HostedDependency) to its hosted system.
Logical containment rules for a system can include:
Note that other rules for physical and logical containment profiles can be used in addition to, or instead of, the rules disclosed herein.
/system1/blade1/cpu3
in which the delimiters are forward slash marks “/”, and the components between the delimiters are referred to as tokens. Process 302 determines whether the first token is a delimiter, such as the “/” character. If so, then the address is a fully qualified name and process 303 removes the UFT instance index and hashes the target root instance name (e.g., “cpu”) to a Class type, then transitions to process 304. If not, then the address is a relative path and the process 302 transitions to process 306, which moves the last InstanceID into the first token and transitions to process 308.
Process 304 determines whether the Class type is “ComputerSystem” and the instance has no HostedDependency dependent role. If not, then process 310 indicates an error, since no such managed element 102 exists. Otherwise, process 308 determines whether the next token is a delimiter. If not, then the token contains the name of the target instance. If so, process 312 moves the next token into token2 and determines whether there is a valid association between token1 and token2 based on information from metadata tables 138 (
The parser process 300 can reset a delimiter counter to zero and increment the counter each time a delimiter is encountered. In some embodiments, if a delimiter count is greater than a specified number, for example, greater than 4, the parsing process 300 can stop and return an error. The delimiter count can also be used to determine the scope of a target instance.
As an example of how parsing process 300 operates, consider again the input target name stream:
In process 302, the first token is a delimiter (i.e., “/”), denoting a root. In some embodiments, a UFT is detected after a delimiter when the token ends with an index, such as an integer value. In this example, “system1” ends with an index, therefore a UFT has been detected and the values of the UFT and the index are stored. If a CIMREF is found, the value of the CIMREF is stored along with a CIM keyword.
Process 303 then separates the instance index “1” from “system”.
If the token parser finds a CIMREF it stores the value and a keyword in the current target string.
Process 304 determines whether the class type of the first token is “ComputerSystem” using metadata tables 138. Assuming “system1” is found in metadata tables 138 as a UFT for a CIM ComputerSystem class with no HostedDependency dependent role, process 308 determines that the next token in the remaining input stream is a delimiter. Process 312 moves the next token “blade1” into token 2 and determines whether there is a valid association between token1 and token 2, i.e., “system1” and “blade1”, in metadata tables 138.
If so, process 316 determines whether token1 (system1) has a valid target association with token2 (blade1), again using data from metadata tables 138. If so, then process 320 determines whether the next token in the input stream is a delimiter, which it is since the remaining input stream is “/cpu3”. Accordingly, process 324 moves token2 (blade1) into token1, and returns to process 308 to determine whether there are valid associations between token1 (blade1) and token2 (cpu3) in processes 312 through 324.
Parser process 300 stops when no further delimiters are found, or in some embodiments, if the allowable number of delimiters in an input string has been exceeded. Once parser process 308 finds no more delimiters, process 326 returns a target that is a specific instance UFT or a <for all> this target component.
In some embodiments, a method includes automatically recognizing standardized object references and alias names for the standardized object references in command lines for monitoring or controlling managed elements. An instance of a managed element is located based on either a standardized object reference or an alias name recognized in a command line. More than one unique alias name can be used for an instance of a managed element.
A hierarchical profile of a CIM Schema can be used in locating instances of the managed elements. The hierarchical profile defines specific paths to end node instances of the managed elements based on a CIM containment model, and the standardized object references and alias names of the managed elements are unique within a container.
A logical profile can be used in locating instances of the managed elements. The logical profile defines a LogicalDevice, ComputerSystem, Service, PhysicalElement, SystemSpecificCollection, and/or ServiceAccessPoint. Associations between the managed elements can include Hosted Dependency, Hosted Service, System Device, Hosted Access Point, Hosted Collection, Computer System Package, and/or Realizes.
A physical profile can be used in locating instances of the managed elements. The physical profile specifies that a Rack may contain 0 . . . n Chassis; a Chassis may contain 0 . . . n Packages; a Package may contain 0 . . . n Components, Connectors, or PhysicalElements, and a PhysicalElement Realizes a LogicalDevice, so any PhysicalElement by association may ‘contain’ a LogicalDevice.
Information regarding instances of the managed elements can be stored in a metadata repository that includes information typically stored in a CIM instance repository.
Associations between managed elements can be based on a set of grammar rules.
An index can be included in the alias names. The index is unique for each instance of the managed elements of the same type within a container.
A command in command lines can be automatically recognized including a command to apply a Setting Data instance to the instance; a command to bring up a Server system; a Reset Command; a Power Command; a Halt Command to shut down a target managed element instance; a Show: Instance Properties Command, which returns all the supported properties of an instance; a Show: instance names Command, which returns all the names of a specified managed element in a CIM instance; a Create Command, which creates an instance of a specified managed element; a Remove Command, which removes an instance of a specified managed element; and/or a Subscribe Command to register to receive indications of specified events.
A user-friendly class tag (UFcT) can be defined for each class used in a profile to provide a user friendly alias name for a specific CIM class. A user-friendly instance tag (UFiT) can be defined based on the UFcT and a unique index for the type of managed element in a container.
One or more data tables can be used that include information regarding instances of managed elements, associations between the managed elements, user-friendly tags and corresponding CIM class names for the managed elements, properties of the managed elements including user-friendly tags and corresponding CIM names for the properties, and/or pointers to executable instructions provide the properties of a managed object upon request.
Table 4 shows examples of User-Friendly Class Tags and User-Friendly Instance Tags that can be used in system 100:
Some embodiments of MAPs 112, 126 utilize grammar rules to form fully qualified target names.
The grammar production rules and notation outlined below are defined in Augmented Backus-Naur Form (ABNF), which defines a set of rules for a formal unambiguous machine parsable grammar developed by the Internet Engineering Task Force (IETF), as set forth in IETF Specification RFC2234. The grammar rules can be implemented as follows:
MAPs 112, 126 often have limited processing resources, while being required to perform functions similar to a CIM Server. MAPs 112, 126 are not required to support CIM Operations over HTTP, but in other respects MAPs 112, 126 perform many of the functions of a CIM Server including interacting with clients via management console 134 or scripts, and instrumentation 122. Also, MAPs 112, 126 store information regarding managed elements 102 in metadata tables 138.
In addition, in CIM environments using CIM Operations over HTTP, a client must make repeated remote operation calls to determine how instances of managed elements 102 are related to one another. This is often very time-consuming, especially if the object space is large. To help solve this problem, metadata tables 138 can be used to cache association information along with the information typically stored in metadata tables 138 so that a complete instance graph is always available. Thus, no calls are necessary to determine how or if a managed element 102 is associated to another. A remote operation is only necessary to retrieve or set property information or to invoke a method.
Further, information cached in MAP 126 may be uploaded to another client to provide an aggregated view of a data center. For instance, consider several MAPs 112, 126 each managing a single rack, such as a blade system with multiple virtual systems, and several MAPs 112, 126 each managing one or more systems, and perhaps several more MAPs 112, 126 in each of the multiple stand alone systems in the data center.
MAPs 112, 126 have separate and distinct namespaces. The aggregating client, such as an OpenView system available from Hewlett-Packard of Palo Alto, Calif., can upload cached information from each of the MAPs 126 in the data center to provide a comprehensive view of the data center. Since the namespace is hierarchical, there would be no namespace collisions even though the instance names are not unique, as long as the individual MAP namespace is stored under a unique node name.
The ability to provide a single view of an entire data center provides the functionality necessary to support an infrastructure management system, such as an OpenView system. Further, data may be viewed in a number of different ways. A fully connected instance association graph can be used to render data center topology or answer questions such as: “If a power supply fails, which central processing unit (cpu) is going down?” “If a power sensor is over threshold, which cpus are affected, which applications are running and where can these applications be moved?”
In some embodiments, metadata tables 138 are optimized by storing each CIM string once and leveraging User Friendly class and instance Tags (UFcT, UFiT). The instance tag naming rules require that an index, such as an integer value, be added to the UFcT to form an UFiT and that the index must be unique within its immediate container.
Referring to
The information in the embodiment of MAP table 500 shown includes MAP name, protocols/protocol versions supported, CIM versions supported, and object manager namespace handle. MAP table 500 can be included in a CIM class(es) representing MAP 112, 126 and treated as another CIM instance. The object manager namespace handle can be used with the instance's key in Instance table 520 to construct CIM Object References.
System table 510 can include information regarding all the systems MAP 112, 126 is managing. In the embodiment shown, System table 510 includes a unique index key, a System UFT, a System Type key, a pointer to the managed system's instance table, and an optional Boolean value to signify if the system is real or virtual. If a system is Partitioned, the system is by definition virtual. If MAP 112, 126 never manages partitionable systems, this field is not necessary. For many operations, storing information noting whether a system is real or virtual will prove more efficient than examining links in an instance's association table to find the existence of a HostedDependency.
The System Type Key can be used to index into a System Type table (not shown) that contains information about the physical architecture of the system such as simple stand alone system, single rack blade, multi-rack blade, Cluster, etc.
The System Type Key can also include information about MAP coverage, for example, to denote a racked blade implementation with a separate MAP 112, 126 in every blade. Such information can be used to know how to parse a target name. In the case where a single blade (or cell) is managed by a dedicated MAP 112, 126, e.g. the MAP's namespace only contains instances for its chassis. Parsing process 300 (
Instance table 520 includes information about all the instances that are known for a particular system, including a unique key for each instance, a key to the instance's class name, the instance's user friendly name, a list of the instance's CIM key values, a pointer to the instance's property provider, and a pointer to the instance's Association table. There is a single instance table 520 for each managed element 102. Provider Key indexes into Provider table 570 to get to the provider 124 or 132 executable and other pertinent information about the associated instrumentation 122. In a distributed MAP implementation across multiple servers 108, the Property Provider can be a MAP 112, 126.
Class Name table 540 is indexed with Class Name Key, which stores the UFT and CIM Object Reference for each class.
The CIM Key string in Instance table 520 can be used to construct a CIM Object Reference pathname. Caching the CIM Object Reference provides the translation from UFTs to CIM Object References to support interaction with both CLP and Web Based Enterprise Management (WBEM) facilities.
Association table 530 can include information about a particular instance's associations such as a unique key for each association, the class name key index of the association, the user friendly name for this association instance, a pointer into the instance table to locate the associated instance, the target instance's role in the association, and a pointer to the association's property provider if the association has additional properties. If associations span server systems 108, then it is necessary to add foreign system information. The HostedDependency association can be used to connect real resources with virtual resources. The association table 530 can be used to construct physical topology views, relate virtual resources to real resources, aggregate logical device information; combine LogicalDevice and their PhysicalElements, find related firmware, product information, capabilities, settings, services, managed access points, and other suitable functions.
Parser process 304 (
Finally, parser process 304 checks to see if system1 and chassis1 are in the appropriate roles. That is, system1 must be in column 1 and chassis1 must be in column 2. It is not legal according to the address containment rules for there to be more than 1 “real” system1 in the MAPAdminDomain namespace. There may be a virtual system1, but this is not a problem because it is one hop away from a “real” ComputerSystem using a HostedDependency association, and system1 will now be in column 2 because it is in the Dependent role. So /system1/system1 is legal and Association table 530 sorts the associations out appropriately. Parser processes 308-326 can continue to verify that each term in the path corresponds to an instance with the proper relationship.
Instance retrieval can be made by index or class type. Association retrieval can be based on instance id (index in instance table) or class type. Most association queries begin with one instance and ask a question such as [what ? is associated with this instance], or [where ? may be AssociatedPowerSupply, ElementSettingData, ElementSoftwareIdentity, RunningOS, InstalledOS, or any number of supported CIM associations]. A table look up routine can be used to search the Index Key column in association table 530 to locate the desired association and records all the matches where the instance ID is in the first or second column. The position of the instance ID in either column will tell what the role of each instance is in that particular association instance.
To get all the instances that an object is associated with, the matches in column 1 and column 2 of the association table 530 can be determined. Again, Index Key column in association table 530 provides information regarding the kind of association, and the positions of the related instances in columns 1 and 2 reveal their respective roles.
To follow an association path, for instance, to answer the question of what is contained in rack1, one begins the search in column1 of Association table 530 because rack1 is the container and therefore in the Group or Antecedent role. All the hardware contained in the rack will have ChassisInRack or Container association with rack1. Next for each chassis type returned in the first retrieval one does a nested retrieval of all the instances associated with the chassis; PackageInChassis, Container; for each Package retrieve all the ConnectorOnPackage, PackagedComponent, Container. Such a graph traversal is guaranteed to terminate at a leaf instance.
At which point, the search recurses to the next chassis in the rack until all the branches have been walked. This traversal pattern along with the location information can provide the necessary information to render a physical topology in most cases. For more complex topologies, a Location property on the association can be used. Traditionally in CIM, the properties for specifying a location include a free-form text string that describes the placement of a managed element 102, such as slot information on a hosting board, mounting site in an equipment rack, a position relative to stationary elements in a container 104, or latitude and longitude information, among others.
Referring again to
Referring to FIGS. 1A and 6A-6C, in some embodiments, the zero coordinate is located in the rear lower left hand corner of container 104 and the positions of managed elements 102 are confined to the positive x, y, z axis, as indicated by the numbers along x, y, z axes. The values provided in the text strings of the location properties can correspond to “x, y, z” coordinates or other suitable arrangement. Note that one or more coordinates may be omitted for single dimensional locations. For instance, the location description for a chassis with a single row of slots will require one dimension. Dimensional coordinates may be omitted if all managed elements 102 within a particular container 104 have the same coordinate for the dimension. A delimiter such as a comma “,”
In some embodiments, coordinate(s) of the location description are used as divisors in unit ratios of corresponding axes. For example, the description “3, 2, 0” describes a managed element 102 located one third (⅓) of the way along the positive x axis, and mid-way (½) up the y axis, with no depth along the z axis, as indicated in
In other embodiments, the coordinates provided in the property descriptions can be used as an index to the position/location in container 104. For example, the description “3, 2, 0” could indicate the position of a managed element 102 located in the third position along the x axis and the second position along the y axis, as indicated in
Referring again to
Property Name table 550 includes information about the properties of supported CIM classes, including a unique key for each property within the scope of a class, a CIM Name for the property, and a UFT for the property. If property information is to be cached in a Property instance table, then data type information is stored as well and a Data Type table can be used to map the data type enumerator with data type information.
Property Name table 550 allows programming logic to convert a user friendly name into a CIM parameter name to pass to a Provider 124 or 132 and instrumentation 122 and provides similar translation for transmitting Provider results to the user.
Association Roles table 560 provides information about the roles that an instance may be assigned in a particular CIM association, including a unique key (integer) for each supported CIM association and a string value of the role. Information in Association Roles table 560 can be used to develop programmatic logic to traverse associations by indicating, for example, the dependent or contained member. The role provides directional and containment information that can be used to construct a topological view of the entire system or any subsystem, such as storage or power systems.
Property Provider table 570 includes information about a particular property provider including a unique key for each provider 124 or 132 and a pointer to the provider's executable. Other useful information about the nature of the provider 124 or 132 can also be included. Providing a separate table for Provider executable location pointers avoids redundancy in Instance tables 520.
In some embodiments, a computer product including storage media can be configured to implement a hierarchical profile of a CIM Schema that can be used to locate instances of managed elements, wherein the hierarchical profile defines specific paths to end node instances of the managed elements based on a containment profile.
A logical containment profile can be implemented that defines at least one managed element of the group consisting of: LogicalDevice, ComputerSystem, Service, PhysicalElement, SystemSpecificCollection, and ServiceAccessPoint. Associations between the managed elements can be defined that include at least one of the group consisting of: Hosted Dependency, Hosted Service, System Device, Hosted Access Point, Hosted Collection, Computer System Package, and Realizes.
A physical containment profile can be implemented in locating instances of the managed elements wherein the physical profile specifies that a Rack may contain 0 . . . n Chassis; a Chassis may contain 0 . . . n Packages; a Package may contain 0 . . . n Components, Connectors, or PhysicalElements, and a PhysicalElement Realizes a LogicalDevice so any PhysicalElement by association may ‘contain’ a LogicalDevice.
Information regarding instances of the managed elements can be stored in a metadata repository that includes information typically stored in a CIM instance repository.
A set of grammar rules can be implemented that define how instances of the managed elements can be associated to one another.
A table of instances of managed elements can be implemented, wherein names of the managed elements include a unique index to distinguish the managed elements of the same type from one another within a container.
A user-friendly class tag (UFcT) can be defined for each class used in a profile to provide a user friendly alias name for a specific CIM class. A user-friendly instance tag (UFiT) based on the UFcT and a unique index for the type of managed element in a container.
More than one unique alias name can be used for an instance of the managed elements.
One or more data tables can be implemented that include information regarding at least one of the group consisting of: instances of the managed elements, properties of the managed elements, and pointers to executable instructions provide the properties of a managed object upon request.
Server 108 and management platform 106 can be embodied in any suitable computer-processing device that includes memory for storing and executing logic instructions, and is capable of interfacing with other processing systems via a network. Various input/output devices, such as keyboard and mouse (not shown), can be included to allow a user to interact with components internal and external to server 108 and management platform 106.
Additionally, server 108 and management platform 106 can be embodied in any suitable computing device and corresponding logic instructions can be implemented using any suitable combination of hardware, software, and/or firmware, such as microprocessors, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuit (ASICs), or other suitable devices.
Logic instructions executed by server 108 and management platform 106 can be stored on a computer readable medium, or accessed by server 108 and management platform 106 in the form of electronic signals. Server 108 and management platform 106 can be configured to interface with each other, and to connect to an external network, via suitable communication links such as any one or combination of T1, ISDN, or cable line, a wireless connection through a cellular or satellite network, or a local data transport system such as Ethernet or token ring over a local area network. The logic modules can be independently implemented or included in one of the other system components. Similarly, other components have been discussed as separate and discrete components. These components may, however, be combined to form larger, smaller, or different software modules or structures, integrated circuits, or electrical assemblies, if desired. Further, examples of various features in hierarchical profile 200 and logical and physical containment profiles 210, 220, metadata tables 138 are referred to by specific names herein, however, it is recognized that other names can be used to denote similar features. Further other suitable features can be included hierarchical profile 200 and logical and physical containment profiles 210, 220, metadata tables 138 in addition to, or instead of, the features disclosed herein.
While the present disclosure describes various embodiments, these embodiments are to be understood as illustrative and do not limit the claim scope. Many variations, modifications, additions, and improvements of the described embodiments are possible. For example, those having ordinary skill in the art will readily implement the steps necessary to provide the structures and methods disclosed herein, and will understand that the process parameters, materials, and dimensions are given by way of example only. The parameters, materials, and dimensions can be varied to achieve the desired structure as well as modifications, which are within the scope of the claims. Variations and modifications of the embodiments disclosed herein may also be made while remaining within the scope of the following claims.
In the claims, unless otherwise indicated the article “a” is to refer to “one or more than one”.