[Openais] CSI, SI and SU, Component ??? Totally confused.
harish kulkarni
wasinapple at gmail.com
Sun Jun 14 02:57:40 PDT 2009
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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/openais/attachments/20090614/6226515e/attachment.htm
More information about the Openais
mailing list