sfcb small footprint cim broker introductionsblim.sourceforge.net/doc2/sfcb-intro-ext.pdfsupport for...

Linux Technology Center

May 2005 | LTC Systems Management© 2005 IBM Corporation

Template release: Oct 02For the latest, go to http://w3.ibm.com/ibm/presentations

sfcb Small Footprint Cim Broker

IntroductionAdrian [email protected]


Management Infrastructure for Embedded Environments © 2005 IBM Corporation2


Contents

Simple questions:

Why ?

What ?

How ?

A Picture and Terminology used

Detailed description of components

Indication scenario

Preliminary Performance numbers




sfcb

Simple questions




sfcb – Why ? WBEM infrastructure is available and becoming well established on

servers.

In order to become pervasive as part of Systems Management solutions it is required to have WBEM infrastructure available in embedded and/or constrained environments as well.

When available, Management Solutions will find a uniform model and instrumentation to work with.

IBM and Intel are collaborating on efforts to achieve this by working together in the Small Footprint CIM Broker project.




sfcb – What is it ? Highly configurable CIM Object Manager

Capable of supporting all or selected DMTF specifications

Standards based: WBEM and CMPI Intended for resource constrained and/or embedded environments

Consists of a core that can be extended using providers and input adapters Design for inherent stability – survives adapter and provider crashes

Main sfcb process very simple – should never die

Input adapters and providers execute outofprocess It is a IBM/Intel collaboration Manageability project

2 not yet announced products will use sfcb.

Goal is to open source this technology – work in progress




sfcb – How ?

Written in C Main process is essentially not more than a Provider Manager

Modeled after Provider Manager of SNIA CIMOM (ServerNamespace)

Maintains provider registration data

Resolves and loads providers on request from adapters and upcalls CIM Data type support based on Remote CMPI experiences

Garbage Collection

Added hash table, list and string buffer support Uses internally a relocatable CIM object format

Objects can be shipped around without marshalling overhead




sfcb – Picture Please !

sfcBroker httpDaemonCimXmlRequest

Processor

(aka Codec)

Provider

Request Provider ResolutionReturns list of Provider sockets

Execute RequestReturns Result

fork()

fork()

fork() Handling a Client request

sfcBroker forks Daemon (only once)Daemon listens on portDaemon forks CodecCodec parses request Codec requests “provider resolution”sfcbBroker resolves requestssfcbBroker forks provider(s) if neededsfcbBroker returns list of socketsCodec “calls” provider(s)Provider(s) returns resultCodec generates responseCodec exits

Client Request Response




Remote CMPI Concept

Remote CMPI is a concept the enables an unaltered, ordinary CMPI style provider to execute at a remote location

Remote in the sense that it is remote in respect to the central CIMOM Clients field requests to the central CIMOM At the CIMOM side the generic Remote CMPI proxy provider kicks in and pass requests

to the Remote CMPI daemon at remote locations The Remote CMPI daemon will load and drive the provider. Proxy and Daemon use a private streaming protocol

Client CIMON ProxyProvider

RemoteDaemon

Remote system

CMPIProvider

CMPIProvider

RemoteDaemon

Remote system

CMPIProvider

CMPIProvider

Central CIMOM




sfcb

Technical details




sfcb Terminology used

Terminology used to describe interactions between broker and providers:Driving ff of provider yy: The broker calling the ff provider function of provider yy

Upcall: Invocation of a broker function by a provider

Invoking mm method of zz: A provider calling the extrinsic method mm of provider zz

broker

Driving GetInstance of yy Upcall

Invoking mm of zz

yy zz

Client GetInstance request




sfcb – Details: sfcBroker sfcBroker uses configuration file during startup

Max number of concurrent Codec processes

Max number of concurrent Provider processes Sum of max process numbers used to generate socket pairs and System V semaphores

SEM_UNDO option used on counters and locks to observe max numbers

automatic throttling of requests

arbitration done when reaching max provider processes Initializes usual signal handler – including SIGHUP for restart Loads the provider registration file Starts class and InterOp provider Starts input adapter Daemon(s) Enters “request for provider resolution” loop

Input for request is namespace, classname and operation




sfcb – Details: Input Adapter Daemon

The httpDaemon supports SSL and basic authentication Authentication exit is offered to customize authentication policies.

Opens designated port number (defined in configuration file) Enters processing loop

Listen for requests

Isolate payload

Fork input adapter (codec)

Wait for next request

(As is obvious, daemon processing is very simple. We might consider folding this into the sfcBroker process as a thread (configuration option)).

Input throttling is accomplished automatically with System V semaphores using counting locks and the SEM_UNDO option.




sfcb – Details: CIMXML codec

CIMXML codec forked once for every client request XML parsed using Bison with custom build XML tag lexer Interfaces with sfcBroker and Providers with

providerMgr.c to request provider resolution getProviderContext()

providerDrv.c to invoke provider(s) – invokeProvider() and invokeProviders()

These interfaces are protocol agnostic and can be used by other protocols (WS, CLI, SQL, binary, etc)

Generates “chunked” responses when requested for enumerating type requests.

Currently blocks class creation and modifying operations – will be changed to send requests to class provider (who will than decide to support this or not)




sfcb – Details: Providers All CMPI provider types will be supported Providers are forked by sfcBroker when needed Idle/Unload monitoring done within each provider process

Possible idle/unload policies:

idle time specified in configuration file once for all providers

“never” specified during registration

after “n” invocations specified during registration (rejuvenation option) Providers can resist unloading at cleanup time by returning either the

CMPI_RC_NEVER_UNLOAD or CMPI_RC_DO_NOT_UNLOAD return code. An indication provider becomes a unload candidate when no subscriptions exist any more

for this provider. Multiple providers can share a provider process Every provider request is executed as a detached (POSIX) thread (concurrent execution

of requests) Upcalls are serialized within a provider process




sfcb – Details: Extension Providers

Extension Providers implement function that other CIMOMs often considered part of a CIMOM itself. Examples:

Class provider $ClassProvider$

Default provider (static repository) $DefaultProvider$

InterOp namespace provider $InterOpProvider$

Indication handlers using real class names

Authorization provider using real class names

Message internationalization support $MessageTranslation$ Most of these providers are not class specific because they offer general function. Special

pseudo class name are used to register these providers. This enables customization of these extension without altering the core.

Extension Providers often have no related cim schema and/or often offer extrinsic method calls that are not defined in a cim schema either (and cannot be used by clients).

Extension providers are a key ingredient for enabling customizable CIMOMs




sfcb – Details: Class Provider The class provider is an instance and method provider The class provider is only used by

sfcBroker for during provider resolution

Some of the upcall routines that need class information

Codecs to hand off class creation/deletion/modification requests to the class provider In general, the class provider knows its class repository and also maintains the

inheritance tree. It must respond to very specific method requests issued during provider resolution.

Class provider can have very different incarnations depending on the subset of functions are needed in an embedded environment.

The current sfcb implementation keeps all classes in memory and has a very intimate relationship with mofc (sfcb’s offline mof compiler),




sfcb – Details: Default Provider

Invocation of this provider is instigated solely by provider resolution support.

The default provider is the provider of last resorts it no provider is registered for a particular class. Its is an instance, association and method provider.

It can respond by accessing a static repository or return an error indication saying that no provider is available for this operation.

The sfcb implementation interfaces with sfcb’s file based repository support.

Other implementation might use a proper database instead, or use a non persistent memory store.




sfcb – Details: InterOp Provider

The InterOp provider is invoked for every operation against the InterOp namespace, unless it is against a registered InterOp class.

Normally is an instance, association and method provider. This provider controls the degree of InterOp compliance. Currently used to implement Process Indications, implementing

support for CIM_IndicationFilter and CIM_IndicationSubscription. The provider can be invoked as a result of normal Client requests, but

also offers a few hidden methods being used by the DeliverIndication upcall and Indication Handlers reporting creation or deletion of Indication handler instances.




sfcb – Details: Indication Handler

Indication handlers interface with InterOp provider to report Handler creation/deletion requests using _addHandler and _removeHandler methods.

In case of a deletion request a check is made to see whether the handler instance is part of an active subscription. If so, the handler is instructed to refuse the deletion request.

Indication Handlers must support the _deliver method. The indication instance is part of the _deliver method.

CIM_ListenerDestinationCIMXML is supported by sfcb. It requires the Curl package to be installed.




sfcb – Details: Authorization Provider

Meant to serve two purposes:Administrative interface to define authorizations

Interface to be used by providers to test for authorized principle Default implementation stores authorizations in side file Other implementations could interface with ldap or other security

environments

The principle of a request is always passed to a provider via the CMPIContext instance.




sfcb – Details: Message internationalization support

Special provider to manage message catalogues for translation services.

Invoked internally by TranslateMessage upcall call. Default implementation will return not supported, meaning message

will not be translated.




sfcb – Details: Indication Components

sfcbClient Listener

InterOpProvider

IndicationHandler

IndicationProvider




sfcb – Details: Indication scenario

1. Client creates CIM_IndicationFilter instance2. InterOp Provider checks query expression3. Client creates CIM_ListenerDestinationCIMXML instance4. Handler provider invokes _addHandler method of Interop Provider5. Client creates CIM_IndicationSubscription association instance6. Client starts listening for indications7. InterOp Provider checks whether related Filter and Handler exist8. InterOp Provider requests provider resolution for this request9. InterOp Provider drives ActivateFilter of eligible provider(s)10. Indication provider start monitoring11. Indication provider makes DeliverIndication upcall12. DeliverIndication evaluates indication against Query expression(s)13. DeliverIndication invokes _deliver method of InterOp Provider14. InterOp Provider finds related Subscription(s)15. InterOp Provider invokes _deliver method of all related handlers instances16. Handler formats and sends indication17. Client receives indication

sfcbClient

Listener

InterOpProvider

IndicationHandler

IndicationProvider




sfcb

Preliminary Performance Numbers




CIM Server Footprint Comparison

Footprint Measurement Problems– shared memory usage determination (mainly shared libraries)

– virtual vs real storage (commit ratio, copy on write)

main()

libclibpeg*

heapthread stacks

stack




Where and How to Measure

Linux /proc filesystem– /proc/pid/statm

– gives virtual, resident and libraryrelated page consumption

– /proc/pid/vmstat

– gives detailed human readable informations also need to consider other virtual storage consumption factors

– shared library text and data sizes

– number of threads (thread stack on process heap)!

– per process stack and data size




Metrics and Measurement Method

Total virtual storage consumption (n processes, m threads)

Conditions– CIM server idle after startup

– CIM server idle after enumeration

– don't count libc (~1.1MB)

– custom thread stack size 512 kB




Footprint sfcb and OpenPegasus

Number of Processes 3 4 1 1Number of extra Threads 3 5 3 6Text 8kB 8kB 88kB 88kBStacks (sum) 1050kB 1400kB 1180kB 1190kB

585kB 780kB 900kB 1430kBLib Text 430kB 430kB 7500kB 7500kBThread Stacks (sum) 512kB 1536kB 1024kB 2560kBTotal 2585kB 4154kB 10692kB 12768kBTotal (w/o thread stacks) 2073kB 2618kB 9668kB 10208kBRSS 2060kB 3200kB 6420kB 7964kB

SFCB after Startup

SFCB after Enum

Pegasus after Startup

Pegasus after Enum

Data + Libdata (sum)

Note: these are conservative figures for sfcb– don't account for copyonwrite memory (estimated 1.4MB)

– don't account for shared RSS




Performance sfcb vs. OpenPegasus

What's measured– response time for enumInstanceNames and enumInstances

– sample file provider (2785 instances)

– resource access time ~0,3s

enumInstanceNames enumInstancesSFCB CMPI C 0.6s 2.3sSFCB CMPI C++ 0.6s 2.3sSFCB ecute 0.6s 4.0s

Pegasus CMPI C 5.3s 15.7s

sfcb small footprint cim broker introductionsblim.sourceforge.net/doc2/sfcb-intro-ext.pdfsupport for...

Documents