[Openais] CSI, SI and SU, Component ??? Totally confused.
Andras Kovi
kovi at mit.bme.hu
Mon Jun 15 00:47:22 PDT 2009
Hi Harish,
In my opinion the list below should be:
Component: process /process group with one registered (there can be only
one registered process per component but a component may be composed of
multiple processes, and any number of threads inside these)
SU: logical stuff that aggregates components
CSI: logical stuff that is assigned to the component when the SI is
assigned to the SU (this is a component workload)
SI: logical stuff that aggregates CSIs and is assigned to the SUs either
as active or standby
SG: group of SUs. All SUs are of the same type. This means if you have
identical SUs in an SG, they have only different names and
deployment/placement. The SG protects the SIs by maintaining active and
standby (in n-way active red. model only active) SU assignments to the SUs
in the given SG. An SI is protected by at most one SG.
Let's see an example:
box1{ su1{comp1, comp2}, su2{comp1, comp2}}
box2{ su3{comp1, comp2}, su3{comp1, comp2}}
si1{ csi1, csi2}
sg1 {redMod=3+1; protects=si1; serviceUnits=su1,su2,su3,su4}
If you start the cluster, all the components in the SUs will be
instantiated as processess using the instantiate scripts. When an SU
becomes available (In Service, after all comps in that SU registered
(saAmfComponentRegister())) it is considered as a possible service
provider for si1. Accordingly, si1 will be assigned (by AMF) to one of the
suX-es as active and to an other as standby, this means, the CSIs in the
SI are assigned to the Components through the SaAmfCSISetCallbackT()
callback function.
Of course there are tons of parameters that influence the order of
instantiation, the preferences, the timeouts... and I don't exactly know
how is AMF implemented in OpenAIS, but as far as I remember, a
configuration similar to the above one worked for me.
Hope this helps,
Andras
From:
harish kulkarni <wasinapple at gmail.com>
To:
sdake at redhat.com
Cc:
openais at lists.linux-foundation.org
Date:
2009.06.14 11:59
Subject:
Re: [Openais] CSI, SI and SU, Component ??? Totally confused.
On Sat, Jun 13, 2009 at 1:49 PM, Steven Dake <sdake at redhat.com> wrote:
On Sun, 2009-06-14 at 10:48 +0530, harish kulkarni wrote:
> Thanks for your clarification.
>
> Let me just re-iterate just to correct myself,
>
> Component: is logical stuff
> Component Service Instance: Is a process
> Service Unit: Logical stuff
> Service Instance: set of CSI's.
>
> Now say, i have two executable's (x1 and x2) which provide two
> different functionalities say y1 and y2, and are interdependable so i
> define them as components under one service unit.
>
> Till now it's all logical binding.
>
> Now when i define CSI, i can have multiple CSI's of each component.
> say for example i may have x1-csi-1 and x1-csi-2 and y1-csi-1,
> y1-csi-2.
>
> And i can have two SI's
>
> si-A and si-B, si-A will have two csi's x1-csi-1 and y1-csi-1,
> similarly under si-B will have x1-csi-2 and y1-csi-2.
>
> And under sg i define one su, but two si's.
>
> When i bring up this kind of a setup on two blades (box;s) , we end-up
> of seeing two si's which means four processes on one box and 4 on
> other box.
I believe you should only have two processes on one box given your
example. Your example, an executable (In Linux-speak, a process)
contains two components each, and each component is not separately
spawned.
[Harish] Sorry, didn't get this one. Because since i have two si, which
means i have two instances of SU running and each instance of SU has two
process ( components), so it should be four processes on each box.
>
> two instances of x1 process with x1-csi-1 and x1-csi-2 specific
> arguments
>
> two instances of y1 process with y1-csi-1 and y1-csi-2 specific
> arguments.
>
> and each si will have have it's own HA state.
>
yes all of this is correct
> And both are independent, which means si-A could be active on blade-1
> and si-B could be active on blade blade-2.
>
components are assigned SI/CSI workloads based upon the redundancy model
and the configuration options related to those redundancy models.
> Please correct if i have missed something.
>
Your understanding appears to be mostly correct. I have only read the
AMF spec about 60-70 times, so I could be mistaken because it is quite
complex and each redundancy model has a different requirement on
si/csis. :)
Regards
-steve
> -Thanks
> Harish
>
>
> On Fri, Jun 12, 2009 at 2:26 PM, Steven Dake <sdake at redhat.com> wrote:
> 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
>
>
_______________________________________________
Openais mailing list
Openais at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/openais/attachments/20090615/d888ea16/attachment-0001.htm
More information about the Openais
mailing list