[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