Sfcb Intro Ext

8/2/2019 Sfcb Intro Ext

http://slidepdf.com/reader/full/sfcb-intro-ext 1/29

Linux Technology Center

May 2005 | LTC Systems Management © 2005 IBM Corporation

sfcb

Small Footprint Cim BrokerIntroduction

Adrian Schuur

[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 – 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 out-of-process

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 up-calls

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 httpDaemonCimXml

Request

Processor

(aka Codec)

Provider

Request Provider Resolution

Returns list of Provider sockets

Execute Request

Returns Result

fork()

fork()

fork()

Handling a Client request

sfcBroker forks Daemon (only once)

Daemon listens on portDaemon forks Codec

Codec parses request

Codec requests “provider resolution”

sfcbBroker resolves requests

sfcbBroker forks provider(s) if needed

sfcbBroker returns list of sockets

Codec “calls” provider(s)

Provider(s) returns result

Codec generates response

Codec 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 CIMONProxy

Provider

Remote

Daemon

Remote system

CMPIProvider

CMPI

Provider

Remote

Daemon

Remote system

CMPI

Provider

CMPI

ProviderCentral 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

Up-call: 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 Up-call

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 requestsIsolate 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 clean-up 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) Up-calls 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 up-call 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 off-line 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

up-call 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 up-call call.

Default implementation will return not supported, meaning message

will not be translated.





sfcb – Details: Indication Components

sfcbClient Listener

InterOp

Provider

Indication

Handler

Indication

Provider





sfcb – Details: Indication scenario

1. Client creates CIM_IndicationFilter instance

2. InterOp Provider checks query expression

3. Client creates CIM_ListenerDestinationCIMXML instance

4. Handler provider invokes _addHandler method of Interop Provider

5. Client creates CIM_IndicationSubscription association instance

6. Client starts listening for indications

7. InterOp Provider checks whether related Filter and Handler exist

8. InterOp Provider requests provider resolution for this request

9. InterOp Provider drives ActivateFilter of eligible provider(s)

10. Indication provider start monitoring

11. Indication provider makes DeliverIndication up-call12. DeliverIndication evaluates indication against Query expression(s)

13. DeliverIndication invokes _deliver method of InterOp Provider

14. InterOp Provider finds related Subscription(s)

15. InterOp Provider invokes _deliver method of all related handlers instances

16. Handler formats and sends indication

17. Client receives indication

sfcbClient

Listener

InterOp

Provider

Indication

Handler

Indication

Provider





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*

heap

thread stacks

stack





Where and How to Measure

Linux /proc filesystem

– /proc/ pid /statm

– gives virtual, resident and library-related 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 1

Number of extra Threads 3 5 3 6

Text 8kB 8kB 88kB 88kB

Stacks (sum) 1050kB 1400kB 1180kB 1190kB

585kB 780kB 900kB 1430kBLib Text 430kB 430kB 7500kB 7500kB

Thread Stacks (sum) 512kB 1536kB 1024kB 2560kB

Total 2585kB 4154kB 10692kB 12768kB

Total (w/o thread stacks) 2073kB 2618kB 9668kB 10208kB

RSS 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 copy-on-write memory (estimated 1.4MB)

– don't account for shared RSS

Li T h l C




Performance sfcb vs. OpenPegasus

What's measured

– response time for enumInstanceNames and enumInstances

– sample file provider (2785 instances)

– resource access time ~0,3s

enumInstanceNames enumInstances

SFCB CMPI C 0.6s 2.3s

SFCB CMPI C++ 0.6s 2.3s

SFCB ecute 0.6s 4.0s

Pegasus CMPI C 5.3s 15.7s

Documents

Sfcb Intro Ext