[Openais] CSI, SI and SU, Component ??? Totally confused.

Steven Dake sdake at redhat.com
Fri Jun 12 01:56:55 PDT 2009


On Fri, 2009-06-12 at 12:39 +0530, harish kulkarni wrote:
> Hello All,

First, AMF in openais is experimental and you likely wont be happy with
the results.
> 
> I need your help in getting an understanding about these terms with an
> example, i saw few examples on this mailing list which were helpful. 
> But not close to realistic situations.
> 
> I understand the service unit and component concept well but i didn't
> get component service instance(CSI), service instance (SI) and 
> service group (SG) logic well, i read specs and other presentations
> on 

A component can provide multiple instantiations of a service unit's
workload.  For example consider a webserver which hosts 5 domains.  Each
domain would be a separate CSI but serviced by 1
component(component=webserver process of a SU).

The CSI abstraction essentially allows a component to have separate
contexts (also known as instances).  A service instance is a collection
of the CSIs that define a SU's running instances.  In a typical
application, there is only one component providing all processing for a
service unit.  If the case is in my hypothetical example above, there is
1 web server component and 1 database component, they could be combined
into 1 SU.  Then each of the 5 domain names would get a separate SI (5
SIs (load1-load5), 2 components (webserver, db), and each component in
the SI would get a seperate CSI (5 CSIs per component in the SU)
CSIs(comp1-load1->comp1-load5->comp1 and
comp1-load2->comp2-load2->comp2)

> web but failed to grab the said.
> 
> Please help me with your thoughts.
> 
> Use Case:
> 
> Assume i have 3 processes/components, which constitute my service
> Process-1 Provides DB interface for persistent data storage
> Process-2 Call Control Logic (CCL)
> Process-4 Billing
> 
> Let's say i have two physical box's (blades) on which i am building
> the service.
> 
> I want to have CCL and Billing on same blade always, so i define both
> of them under single SU (SU-1) as two components, 
> one CCL component (COMP-1) and other Billing component (COMP-2).
> 
> From my understanding, within a service unit, if a component goes down
> the whole SU gets switch-overed, in normal active-standby setup.
> 
> And i define DB component (COMP-3) within another SU (SU-2)
> 
> When my system runs, i see on active blade (blade-1) all components
> COMP-1, COMP-2,COMP-3 getting active status and on standby blade
> (blade-2)
> 
> i see all the components getting standby status.
> 
> Where does this CSI (component service instance), SI (service
> instance) and SG (service group) come into picture and why do we need
> them?.

see above for example.  If it isn't clear from that, ask again and I'll
rephrase.

You might have a look at pacemaker (which is an availability manager
developed in open source and an offshoot of the linux-ha effort) if you
want something compatible with openais and corosync that you can use
today.

> 
> Might be that my requirements don't really need  CSI,SI,SG, but
> according to my knowledge most telco box's have what i have explained
> might be few more components and SU additional accordingly.
> 

Finally a SG is just a grouping of SUs into one logical entity.

> -Thanks for your time.
> Harish
> 
> _______________________________________________
> Openais mailing list
> Openais at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/openais



More information about the Openais mailing list