1 / 28

Introduction to Pegasus An Open-Source WBEM implementation

Agenda. What is Pegasus?Introduction to the TechnologiesCIM and WBEMThe CIM Manageability EnvironmentThe Pegasus Architecture and EnvironmentThe Pegasus ProjectA Challenge for the Future. 1. Overview. What is Pegasus?. Pegasus is an open-source reference implementation of the DMTF WBEM specificationsPegasus is a work project of the TOG Enterprise Management ForumPegasus is a platform for building application management.

Download Presentation

Introduction to Pegasus An Open-Source WBEM implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. Introduction to Pegasus An Open-Source WBEM implementation March 19 2001 Karl Schopmeyer Chair Enterprise Management Forum k.schopmeyer@attglobal.net

    4. 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

    5. Why Produce Pegasus? Demonstrate certain manageability concepts. Provide additional standards for WBEM Provide a working implementation of WBEM technologies Provide an effective modular implementation Support other TOG manageability standards Base Platform for Open Group Application management Projects

    6. Major Objectives of The Project Create standards and implemented solutions for an open architecture for manageability Use DMTF WBEM as basis for information and interoperability Modular and componentized implementation Wide variety of platforms Integrate with other TOG standards such as AIC, ARM, etc. Allow extensibility (pluggability) New manageability resources, resource providers New manageability services Connectibility to wide variety of management systems.

    7. The Working Group Philosophy Manageability not management The working groups 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

    8. Major Objectives of Pegasus Standards Based and Compliant DMTF CIM/WBEM Interoperable DMTF cim-xml Interface Efficient and Lightweight Implemented in C++ Portable NT, Linux, and others planned Modular Replacable modules for function change and addition Extensible Manageabilitys Service extensions

    10. The Evolution of Management Standards

    11. What is WBEM? A major initiative of the DMTF A set of management and internet standard technologies developed to unify the management of enterprise computing environments

    12. What is CIM? Implementation neutral schema for describing management information CIM facilitates the common understanding of management data across different management systems CIM facilitates the integration of management information from different sources CIM is a data model, not an implementation model MOF syntax supports sharing of information across management systems CIM provides models for both instrumentation and management

    13. CIM Available today

    14. Scope of the various CIM Schemas (total: 16) Core Defines generic Managed Object Classes and concepts Other schemas define extensions by subclassing from Core Systems & Devices Define the System, ComputerSystem, OperatingSystem, LogicalDevice and PhysicalElement classes Network/QoS Defines parameters for Networks, mechanism for dealing with QoS Applications Defines application states, supports distribution, installation, updating, asset tracking , monitoring, configuration, and control of distributed applications

    15. Scope Of Schemas (cont) Distributed Application Performance (DAP) / Metrics Defines performance metrics of distributed applications Continues Tivoli/HP work on Application Response Measurement Users Service Policy today

    16. Web-based Enterprise Management (WBEM) Information Model CIM Schema (Core, System,) Communication Model CIM Operations over HTTP Transport Encoding Cim-xml CIM/XML mapping Event Model CIM indications (new in 2.5) CIM Object Manager (CIMOM) Today: confined to a single host Distributed CIMOMs planned Object Providers Instrumentation subagents

    17. Managed Object Format (MOF)

    18. 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 (by means of Qualifiers) Available Implementations Microsoft (in Windows2000), Sun WBEM SDK, SNIA, TOG MSB void ModifyClass ([IN] <class> ModifiedClass) > > The ModifiedClass input parameter defines the set of changes (which MUST > be correct amendments to the CIM Class as defined by the CIM > Specification [1]) to be made to the current class definition. > > In processing the modification of the Class, the following rules MUST be > conformed to by the CIM > Server: > If the modified Class has no Superclass, the ModifiedClass > parameter defines modifications to a > base Class. The Server MUST ensure that: > Any Properties, Methods or Qualifiers in the existing Class > definition which do not appear in > the ModifiedClass parameter are removed from the resulting > modified Class. > > The request to modify the Class MUST fail if the Server cannot update > any existing Subclasses or Instances of that Class in a consistent > manner. > ==== > so it seems to me that the instances of the class itself and of its > subclasses will be updated at run-time. > But of course rejecting the operation if there are existing instances is > a way to also support the spec without violating object paradigm, but I > do not think that they were thinking that way (else they would have > mentioned "FAIL if existing instances"). > But those standards are so obscure ;) > I was actually part of the group that wrote the spec. Our intention was to reject on existing instances, but we did not want to limit an implementation that wanted to do all this work. I do not know of an implementation that supports this, they could but are not required to. We set it up to get the best level of interoperability while allowing as much flexibility as possible for the implementation.void ModifyClass ([IN] <class> ModifiedClass) > > The ModifiedClass input parameter defines the set of changes (which MUST > be correct amendments to the CIM Class as defined by the CIM > Specification [1]) to be made to the current class definition. > > In processing the modification of the Class, the following rules MUST be > conformed to by the CIM > Server: > If the modified Class has no Superclass, the ModifiedClass > parameter defines modifications to a > base Class. The Server MUST ensure that: > Any Properties, Methods or Qualifiers in the existing Class > definition which do not appear in > the ModifiedClass parameter are removed from the resulting > modified Class. > > The request to modify the Class MUST fail if the Server cannot update > any existing Subclasses or Instances of that Class in a consistent > manner. > ==== > so it seems to me that the instances of the class itself and of its > subclasses will be updated at run-time. > But of course rejecting the operation if there are existing instances is > a way to also support the spec without violating object paradigm, but I > do not think that they were thinking that way (else they would have > mentioned "FAIL if existing instances"). > But those standards are so obscure ;) > I was actually part of the group that wrote the spec. Our intention was to reject on existing instances, but we did not want to limit an implementation that wanted to do all this work. I do not know of an implementation that supports this, they could but are not required to. We set it up to get the best level of interoperability while allowing as much flexibility as possible for the implementation.

    20. Pegasus Architecture

    21. The CIM Operations

    22. Key Interoperability Interfaces

    23. Key Characteristics Open source Available Today Portable Designed to build and run on wide variety of platforms C++ core C++ CIM Objects C++ Operation/Provider/Service/Respsitory interfaces Modular and extensible Modular components to extend the core Manageability service extensions to extend functionality Light weight

    24. Modularity and Extensibility Providers Grow with DMTF provider concepts 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

    25. Building A Manageability Environmnent

    26. Pegasus Manageability Environment

    27. 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 will be achieved in three ways: Participating in efforts to standardize the Provider/Server protocol. Proposing provider API standards. Writing adapters enabling Pegasus providers to run under other CIM servers.

    28. In-Process and Out-of-process Providers It will be possible to develop a provider and compile it once and then configure it dynamically to run in-process (within the server process) or out of process (communicates with the server using either IPC or CIM/HTTP).

    29. Modules The core server components are organized into loadable modules. Standard APIs are defined for each module. Alternative implementations can be provided later without recompiling the Pegasus server.

    30. Core Modules Authentication module Thread module Traffic Encryption module

    31. Thread Module Example There will be a thread service: Pegasus will provide a thread service based on ACE wrappers. Alternative thread services can be implemented and plugged in.

    32. Manageability Service Extensions Super Providers Access to the Core Broker

    33. Example Services Event service. Query engine service. Class repository service. Instance repository service. Repository

    34. Repository Service Example One example of a core service is the repository. Pegasus provides a simple repository implementation (based on disk files). An alternative repository based on a commercial database may be implemented later.

    35. Connectors Functions Adapt to different protocols Adapt to other languages Some Examples Xml-cim SUN Java C adapter Other Object Models WMI

    36. 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

    38. Overview of the Project Active project of the Enterprise Management Forum of the Open Group Produce Pegasus open-source Implementation Core, clients, providers, repositories SDKs (Provider and Client) Documentation for use and development Specifications for major Interfaces Continue support and growth of Pegasus Portability New functions New Standards requirements New Providers Tools

    39. Pegasus Status Today Phase 1 of 4+ Phases Effectively 0.8 release Source Code available today Licenses with MIT open-source license Preliminary documentation available Multiple users evaluating today Tested on Windows platforms and Linux

    40. Pegasus Project Phases Phase 1 (March 2001) Goals Model Validation Client and Provider development Basic Environment Core model Cim-xml Operations Class and instance repositories Providers Phase 2 (May 2001) Goals Production Code Additions Threaded model Configuration Security Service Extensions Query Language Phase 3 (June 2001) Events Extensions Remote Providers Phase 4 (Unsure) Other extensions including other Language Interfaces (ex. Java connector)

    41. Participants The Open Group BMC IBM Tvioli CA Hermes Softlab SIAC The Open Group Research Institute Focal Point

    42. Additional Activities Providers Clients Growth of functionality with DMTF Discovery Provider standardization (registration, interfaces) Next generation interoperability

    43. Pegasus Manageability Environment

    44. Pegasus and Other Manageability Projects AIC Application and Control AIC as a Pegasus Provider ARM Applications Response Measurement ARM and DMTF DAP Information as Pegasus Provider Other possible Providers JMX (Java)

    46. CIMOMs - Basic Concepts Tool to create Management Interoperability Tool to create manageability interoperability Infrastructure for manageability Manageability interoperability Xml-cim today, ??? Tomorrow Instrumentation Interoperability Many providers, few CIMOMs Lots of applications limited numbers of providers

    47. However We do not make money off of infrastructure If we dont have common interfaces we will not have interoperability. CIM is not Easy. Creating complete and Correct CIM environments is not easy There is a lot of work to do with a common environment and much more with many different envrionments

    48. The Alternatives Creating a common interoperability environment Management Manageability xmp-cim Providers APIs and protocols Provider building Common object implementations The choice Build a common structure with contributions Everybody does their own thing. (Many incompatible and incomplete WBEM Implentations

    49. openWBEM Consortium to create common WBEM manageability In fomative stages today About 10 involved organizations today Sun, Compaq,IBM, Tivoli, Open Group, SNIA, Caldera, Novell, Nokia, Intel Open Group Proposing to host

    50. openWBEM Objectives

    51. The Challenge!!! Can we create a common WBEM infrastructure? OR do we all go our own way?

    52. Where to Get More Information Pegasus is public www.opengroup.org/management/pegasus Pegasus WEB Site Source Code Builds on Linux and Windows Snapshots and CVS Binary Release (end of March) Documentation Pegasus Working Group

More Related