CIMOM Implementation. What is Pegasus? Pegasus is an open-source reference implementation of the...
-
Upload
audrey-knight -
Category
Documents
-
view
229 -
download
0
Transcript of CIMOM Implementation. What is Pegasus? Pegasus is an open-source reference implementation of the...
CIMOM Implementation
What is Pegasus?
• Pegasus is an open-source reference implementation of the DMTF WBEM specifications
• Pegasus is a work project of the TOG Enterprise Management Forum
• Pegasus is a platform for building application management• Pegasus is a function-rich, production-quality open-source
implementation designed to be used in high volume server implementations.
Why Produce Pegasus?
• Demonstrate manageability concepts.
• Provide additional standards for WBEM
• Provide a working implementation of WBEM technologies
• Provide an effective modular implementation
• Support other Open Group manageability standards
• Base Platform for Open Group Application management Projects
• Help make WBEM real
Pegasus was Initiated in 2000 by the Open Group in collaboration with:
BMC SoftwareIBMTivoli Systems
Key Pegasus Objectives
Pegasus
Open Source
Portable
EfficientAnd
Lightweight
StandardsBased
Continuity
ModularAnd
ExtensibleProduction
Quality
Pegasus Working Group Philosophy
• Manageability not management– The Pegasus working group’s objective is not to manage systems but to make
them manageable by promoting a standard instrumentation environment
– The actual management of systems is left to systems management vendors
• No standards without implementation– The process of implementation provides a rigorous process for testing the
validity of standards
– Therefore all standards must be validated by implementation
Open Source
• Code and documentation freely available– Open Group and Source Forge
• MIT source license
• Open to contributions
• No commitment to Open Group to use code
Portable
• Designed for multi-platform, multi-OS, multi-compiler implementation
• Platforms ported today– UNIX (AIX, HPUX, Solaris, Tru-Unix)
– Linux
– Windows Platforms (NT, 2000, 9x)
– Compaq Himalaya (Tandem)
Efficient and Lightweight
• Core written in C++
• Designed for execution efficiency
• Designed to be production-quality solution
Standards Based
• Based on DMTF CIM and CIM-XML specifications
• Open Group is active partner in DMTF
• Growth through participation in specification growth
• Commitment to continue DMTF compliance
Modular and Extensible
• Minimize core object broker.
• Maximize extensibility through plug-in components
• Component types– Providers
– Provider interfaces
– Clients
– Repositories (additional repository handlers)
– Manageability service extensions
– Protocol Adapters
– Modules (extend and modify core functions)
Modularity is key to doing parallel development and allowto extensibility
Project for Continued Development
• WBEM will continue to develop functionality and standards
• Open Group will develop application management partly around Pegasus
• Pegasus Development will continue beyond current versions– Integrate contributions
– Add basic new functionality
– Etc.
The Open Group
• Enterprise Management Forum– Projects include:
• Pegasus
• Ex-SNIA Java Based open-source Implementation
• Application Management APIs
– ARM
– AIC• Software Licensing Standards
• QoS Task Force– User/Supplier interaction forum to advance QoS and Service Level
Standards
– Working with DMTF, IETF, TMN
2. The Pegasus Environment
Pegasus Architecture
ConsumersConsumersConsumersConsumers
ClientsClients
CIM ServerCIM Server
ConsumersConsumersConsumersConsumers
ProvidersProviders
CIM/HTTPInteroperable*
Interoperable* CIM/HTTP In-Process
ServicesServices
StandardInterfaces
MOF
Compiler
MOF
Compiler
CIMOM Capabilities
• Respond to Operations defined in “CIM Operations” spec.– Create, Modify, Delete operations on
• Class, Instance, Property, Qualifier
• Handle Provider Registration• Forward Requests to Providers, repositories, etc.• Read/Write access to Management Information
– Maintain Class/Instance Information
• Traversal of Associations• Use of WBEM Query Language• Syntax/Semantic checking (with Qualifiers)• Available Implementations
– Microsoft (in Windows2000), Sun WBEM SDK, SNIA, Open Group Pegasus, …
Key Interoperability Interfaces
CIM Object Manager
CIM Object Manager
CIM ProvidersCIM Providers
ApplicationApplication
Manageability to Manager•Multiple management systems•Common open manageability
Object Manager / Providers• Multiple Providers•Encourage common providers
Management System
Management System
EnterpriseManagement
Console
EnterpriseManagement
Console
ApplicationApplicationApplicationApplication
ApplicationApplication
Provider / Resource Interface•Protect Applications•Make application management easy
The CIM Operations
ConsumersConsumersConsumersConsumers
ClientsClients
CIM Object MgrCIM Object Mgr
ConsumersConsumersConsumersConsumers
ProvidersProviders
CIM/HTTPInteroperable*
Interoperable* CIM/HTTP In-Process
ServicesServices
StandardInterfaces
Repository
CIMOperations
CIMOperations
Repository
Operations Routing
• Class Operations– Routed to the Class Repository
• Instance Operations– To Provider if Provider Qualifier exists
– To Instance repository if no Provider
• Instance routing at Class Level Today– Issues – Routing at instance level
The CIM Indications
ConsumersConsumersConsumersConsumers
ClientsClients
CIM Object MgrCIM Object Mgr
ConsumersConsumersConsumersConsumers
ProvidersProviders
CIM/HTTPInteroperable*
Interoperable* CIM/HTTP In-Process
ServicesServices
StandardInterfaces
RepositoryRepository
IndicatorsIndicators
Indication
HandlersSNMP, cim-
xml, etc.
SNMP, cim-xml, etc.
Modularity and Extensibility
• Providers– Grow with DMTF provider concepts
• Provider Interfaces• Protocol Adapters (connectors)
– Client - Xml-cim today (Soap, etc. in future)– Provider, service, repository, etc.
• Modules– Modularize core so it can be extended and modified through attachable modules
• Manageability Service Extensions– Think super providers
Building A Modular Manageability Environment
CoreObjectBroker
CoreObjectBroker
XML-CIM
ModuleModule
ModuleModule
ModuleModule
ModuleModule
ConnectorConnector
ProviderProvider
ConnectorConnector
ProviderProvider
ConnectorConnector
CIM ClientCIM ClientConnectorConnector
. . .
Resources Resources Resources
ServiceExtension
ServiceExtensionService
Extension
ServiceExtensionService
Extension
ServiceExtensionService
Extension
ServiceExtension
RepositoryRepository
Undefined
CIM ClientCIM ClientCIM ClientCIM Client
RepositoryRepository
RepositoryRepository
ServiceExtension
ServiceExtensionService
Extension
ServiceExtensionService
Extension
ServiceExtensionService
Extension
ServiceExtension
ManagementSystem Connector
ManagementSystem Connector
Pegasus Manageability Environment
CIM Object Broker•Provider Registration •Service Registration•Request Routing •Securiy
CIM Object Broker•Provider Registration •Service Registration•Request Routing •Securiy
Consumers
Providers
AICProvider
AICProvider
Apps OS Etc.
ARMProvider
ARMProvider
Resource
Providers
Broker
Consumers Gateways Apps
XML/CIMConnector
XML/CIMConnector
ManagementSystem Connector
ManagementSystem Connector
ApplicationConsumer
ApplicationConsumer
ClassRepository
ClassRepository
Services core*** additional
InterfaceFor Spec
CIMOMManagement
System
. . .SNMPProvider
SNMPProvider
ManagementSystem
ApplicationConsumer
ApplicationConsumer
ApplicationConsumer
ApplicationConsumer
InstanceRepository
InstanceRepository
Provider Interoperability
• In the classical architecture, interoperability is only supported between the client and server.
• In addition, the Pegasus architecture aims to support provider/server interoperability.
• Goal– Write a provider once and run it under any CIM server implementation.
• Provider/Server Interoperability:– Participating in efforts to standardize the Provider/Server protocol.– Proposing provider API standards.– Writing adapters enabling Pegasus providers to run under other CIM servers.– Adapters enabling other providers to run under Pegasus
Important Provider Interfaces
• SUN WBEM Provider Interface– Java based
– Classes, etc. “similar” to Pegasus
• C Provider Interface– Sun has a specification here.
• We will support multiple provider interfaces and language bindings.
In-Process and Out-of-process Providers
• Today Pegasus based on shared Library Providers• Extend to
– Internal Providers– IPC based Providers– Providers in Remotes systems
• Objectives:– Write Provider once and compile/link for different environments
• Technique– Use connectors as basis for provider/CIMOM communication
• Issues– Security, discovery
Manageability Service Extensions
• Super Providers
• Access to the Core Broker
• Examples– Indication Subscription service.
– Class repository service.
– Instance repository service.
Connectors (Protocol Adapters)
• Functions– Adapt to different protocols
• Characteristics– Protocol– Encoding– Security– Discovery
• Examples– Xml-CIM– Local Protocols– Soap– WMI– Corba environment interface
Pegasus CorePegasus Core
Xml-cimConnector
Xml-cimConnector
PegasusProvider
PegasusProvider
ConnectorConnector
RemoteProvider
Xml-cimClient
Xml-cimClient
SoapConnector
SoapConnector
SoapClient
SoapClient
CorbaConnector
CorbaConnector
ExternalCorba
Environment
ServiceExtension
ServiceExtensionService
Extension
ServiceExtensionService
Extension
ServiceExtensionService
Extension
ServiceExtension
RepositoryRepository
Pegasus Interfaces
• Common Interface base for– Clients, providers, services,
connectors
• Based on CIM Operations over HTTP
• Additional functions for each interface
• Interfaces separated from implementation
CoreObjectBroker
CoreObjectBroker
ProviderProvider
ConnectorConnector
CIM ClientCIM ClientConnectorConnector
3. The Pegasus Software Architecture
Major Components
Client
CIM Server Repository
ClientCIMClients
ClientClientCIMProviders
Topics
• Communication.
• Representation of CIM Elements.
• The Client Interface.
• The CIM Object Manager.
• The Provider Interface.
• The Repository Interface.
Pathways of Communication
Client
CIM Server CIMRepository
ClientCIM Clients
ClientClientCIM Providers
Component Location
• A component may be located in one of three places with respect to the CIM Server.– In-process.
– Local out-of-process (on the same machine).
– Remote out-of-process (on another machine).
• For example, a provider may be in-process, local, or remote.
Component Location in Pegasus Today
In-Process Local Remote
Client X
Provider X
Repository X
Possible Communication Mechanisms
• Components could potentially communicate with the CIM Server using the following mechanisms:– CIM/HTTP (remote).
– Proprietary TCP-based protocol (remote).
– Direct call (in process).
– Shared memory (local).
– Named pipes (local).
Communication Mechanisms in Pegasus
In-Process Local Remote
Client CIM/HTTP
Provider Direct Call
Repository Direct Call
Client Communication
• Uses CIM/HTTP as sole protocol.
• Asynchronous socket I/O.
• An efficient XML parser.
• Fast enough to eliminate the need for a proprietary protocol.
An Efficient XML Parser
• No memory heap usage during parsing.
• Modifies message in place to avoid copying.
• Non-validating parser (“loose validation”).
HTTP Implementation
• Uses asynchronous socket I/O in conjunction with message queues to achieve optimal throughput.
• Provides entry points to adding web server capabilities such as putting and getting of documents (to support remote upgrade and deployment later on).
Proposals
• Support out-of-process providers (local and remote).
• Support out-of-process repositories (local and remote).
• Location independent provider development.
Representation of CIM Elements
Representing CIM Elements in Pegasus with C++
CIM Data Types in C++
• Uint8• Sint8• Uint16• Sint16• Uint32• Sint32• Uint64• Sint64• Real32• Real64
• Boolean• Char16• String• CIMDateTime• CIMReference
CIM Values in C++
• CIM values (property, parameter, and qualifier values) are represented using the CIMValue class. This class:– Encapsulates a union of all CIM data types.
– Has a type member indicating the type currently being represented.
– Provides access/modifier methods overloaded for each CIM data type.
CIM Elements in C++
• CIMClass• CIMInstance• CIMProperty• CIMMethod• CIMParameter• CIMQualifierDecl• CIMQualifier
Class Declaration Example (Part 1)• Consider the following MOF class declaration:
class Alarm{ [key] uint64 id; string message = “none”;};
• This class is defined in C++ as follows:CIMClass alarmClass(“Alarm”);CIMProperty id(“id”, Uint32(0));id.addQualifier(CIMQualifier(“key”, true)); CIMProperty message(“message”, “none”);alarmClass.addProperty(id);alarmClass.addProperty(message);
• Or more succinctly like this:CIMClass alarmClass(“Alarm”);alarmClass .addProperty(CIMProperty(“id”, Uint32(0)) .addQualifier(CIMQualifier(“key”, true))) .addProperty(CIMProperty(“message”, “none”));
Property Iteration Example:
• The properties of a class may be iterated like this:CIMClass c;
…
for (Uint32 i = 0, n = c.getPropertyCount();
i < n; i++)
{
CIMProperty p = c.getProperty(i);
}
The Client Interface
Client
CIM Server Repository
ClientCIMClients
ClientClientCIMProviders
The Client Interface
• A C++ interface for interacting with the Pegasus Server (or any CIM Server).
• Uses CIM/HTTP to communicate.
• Provides a method for each CIM operation defined in the “CIM Operations over HTTP, V1.0” specification.
The CIM Operations
• GetClass
• GetInstance
• DeleteClass
• DeleteInstance
• CreateClass
• CreateInstance
• ModifyClass
• ModifyInstance
• EnumerateClasses
• EnumerateClassNames
• EnumerateInstances
• EnumerateInstanceNames
• ExecQuery
• Associators
• AssociatorNames
• References
• ReferenceNames
• GetProperty
• SetProperty
• GetQualifier
• SetQualifier
• InvokeMethod
CIM Operation Example
virtual CIMInstance getInstance( const String& nameSpace, const CIMReference& instanceName, Boolean localOnly = true, Boolean includeQualifiers = false, Boolean includeClassOrigin = false, const Array<String>& propertyList =
NULL_PROPERTY_LIST);
<instance> GetInstance ( [IN] <instanceName> InstanceName, [IN,OPTIONAL] boolean LocalOnly = true, [IN,OPTIONAL] boolean IncludeQualifiers = false, [IN,OPTIONAL] boolean IncludeClassOrigin = false, [IN,OPTIONAL,NULL] string PropertyList [] = NULL )
CIM Operations
Specification
PegasusClass
Method
Client Connection Example
• A client connects to the CIM Server on the host called “saturn” at port 5988 like this:Selector selector;
CIMClient client(&selector);
client.connect(“saturn:5988”);
GetClass Example
• A client gets a class like this:CIMClass alarmClass =
client.getClass(“root/cimv2”, “Alarm”);
Client Proposals
• Asynchronous Interface APIs
• Interface independent of local/remote client
The Pegasus CIMOM
Client
CIM Server Repository
ClientCIMClients
ClientClientCIMProviders
Request Lifecycle
Channel
Protocol
Encodings
Dispatcher
ProvidersProvidersProviders
Repository
1. Receive TCP Message
2. Process HTTP Request
3. Decode from XML
4. Dispatch Request
Incoming Request
Channel
Protocol
Encodings
Aggregator
8. Transmit TCP Message
7. Form HTTP Response
6. Encode to XML
5. Aggregate Results
Outgoing Response
CIMOM Modules
• Channel - Implements transport mechanism (e.g., TCP).• Protocol - Implement application protocol (e.g., HTTP).• Encodings - Implements encoding and decoding of messages
(e.g., CIM-XML).• Dispatcher - Dispatches messages to provider(s)/repository.• Repository - Implements CIM Repository.• Aggregator - Aggregates results.
Module Concept
• The internal CIMOM architecture is being refined into a set of modules.
• Each module handles part of the request lifecycle.
• Alternative implementations may be provided for each module type.
• New module implementations can be used to modify or refine the behavior of the CIMOM and to facilitate porting.
Module Implementations
• Channel - provide a named-pipe implementation.• Protocol - provide a proprietary binary protocol.• Encodings - provide a binary encoding scheme.• Repository - provide a relational-based implementation.• Traffic Encryption - SSL implementation.• Authentication – Challenge and response
Queued Operation Model
• Internal representation of operations/Indications is messages
• Major components are queue driven
• Mapped to direct interfaces (ex. getClass) at provider manager.
• Message manager controls flows, priorities, etc.
• Advantages– Efficiency
– Threading
– Extensible interfaces
– Flow Control
Module Definition and Loading
• Modules implement one of the module interfaces (e.g., Repository).
• Modules are configured as dynamic libraries.
• Modules listed in modules file.
• Modules loaded by CIMOM on startup.
Provider Mgr Subsystem
CIM XML Comm Module
CIM Operations Processing subsystem
Services Subsystem
PegasusMsgDispatcher
IndicationHandlerManager
CIM-XMLIndication
handler
Repository
ProviderManager
provider
CIM Control Services•Start/Stop Function•Provider registration Function•User/Auth. Function•jj•Jj•__Namespace
SubscriptionService and
Indication Processor
IndicationImport
providerprovider
Client Interface (cim-xml today)
Acceptor
HttpDelegator
Authentication
XMLDecoder
XMLEncoder
Authorization
OperationsRequest
Processor
OperationsResponseProcessor
Responsegenerator
Formal ProviderInterface
IndicationConsumerManager
IndicationConsumerManager
CIM ExportRequest Processor
CIM ExportRequest Decoder
ExportIndication
Pegasus Module Organization
LocalDestination
SNMPIndication
handler
Httpxxx
xxx
The Provider Interface
Client
CIM Server Repository
ClientCIMClients
ClientClientCIMProviders
Provider Proposals
• Interoperability with SUN Wbem providers proposal
• We are extending other interoperability ideas
PegasusCIMOM
PegasusCIMOM
SUN WBEMCIMOM
SUN WBEMCIMOM
MicrosoftCIMOM
MicrosoftCIMOM
PegasusProviders
PegasusProviders
SUN WBEMProviders
SUN WBEMProviders
Microsoft WMIProviders
Microsoft WMIProviders
The Repository Interface
Client
CIM Server Repository
ClientCIMClients
ClientClientCIMProviders
The Repository Interface
• Defines the interface to manipulating the CIM repository.
• Alternative implementations of this interface may be provided.
• Pegasus provides a simple default implementation.
Default Repository Implementation
• Each CIM Class object is stored in its own file.• Instance objects stored in single file for each class• CIM objects are encoded as XML in files.• Namespaces are represented using file system directories.• Single reader/writer at a time.• Example: the class X (subclass of Y) which resides in the
root/cimv2 namespace would be stored in this file:
<repository_root>/root#cimv20/classes/X.Y
Default Repository Limitations
• Adequate for classes and qualifiers (which tend to be few).
• Okay for a few hundred instances.
• Not intended to scale to thousands of instances (uses a lot of disk space due to internal fragmentation).
• Good for scenario in which a few instances come from the repository and many instances come from providers.
Proposed Repository Implementation
• A new repository implementation is under consideration to improve scalability:– Encode objects in binary on disk (rather than XML). This will reduce size
by three to one.
– Combine like objects into a single file rather than separate files (this will reduce internal fragmentation).
– Provide a fast indexing scheme for keys (disk hashing or B+-Trees). This will improve lookup time.
Alternative Repository Modules
• Repository modules may be developed to achieve a highly scalable repository. Possibilities include:– Basing repository on a relational database.
– Basing repository on Unix DB.
– Making the repository remote.
– Improving space utilization of existing implementation by storing objects in binary format (rather than as XML).