[prev in list] [next in list] [prev in thread] [next in thread]
List: jacorb-developer
Subject: Re: [jacorb-developer] Name servce load balancing
From: "Heide, Marc (NSN - DE/Berlin)" <marc.heide () nsn ! com>
Date: 2010-02-09 13:03:06
Message-ID: FD63517120335F488E0DBD96D9DDD9EAD4FEA0 () DEMUEXC014 ! nsn-intra ! net
[Download RAW message or body]
Hi Chirantan,
No, actually we didnt thought about another solution.
This is because we have started with Visibroker which had
this "Clustering" feature also implemented. I think
back in these days VB hoped that this feature would make it
into CORBA standard one day, but it never did.
So once we had used this feature from VB we had to reimplement
it as we switched over to jacorb, to maintain our applications
and client software stable.
As i said, the non-standard behavior is the smallest problem
since for a servant this NS will just never report an
AlreadyBoundException so it always looks like being the first
servant ever bound. Could just be a problem for a servant
who is "expecting" this exception.
For many other projects it could be far more easy to register
only one "fake" object in NS, which has an IIOP profile (IP+port)
pointing to a hardware load-balancer sitting before all real CORBA
servers.
These load balancers keep track of your real servant processes
and will distribute incoming requests accordingly. These
hardware load balancers are more stable then any self knitted
NS logic ;o) and available in most projects dealing with many clients.
Regards
Marc
> -----Original Message-----
> From: jacorb-developer-bounces@lists.spline.inf.fu-berlin.de
> [mailto:jacorb-developer-bounces@lists.spline.inf.fu-berlin.de
> ] On Behalf Of ext Chirantan Kundu
> Sent: Dienstag, 9. Februar 2010 12:20
> To: Discussions concerning CORBA development with JacORB
> Subject: Re: [jacorb-developer] Name servce load balancing
>
> Hi Marc,
>
> Thanks for pointing out the potential pitfalls. Just curious,
> as you said
> you developed the same (and supposedly non-standard) thing,
> did you explore
> any alternate approach for achieving this?
>
> Regards,
> Chirantan
>
> On Tue, Feb 9, 2010 at 2:07 PM, Heide, Marc (NSN - DE/Berlin) <
> marc.heide@nsn.com> wrote:
>
> > Hi Chirantan,
> >
> > Since we have developed a NamingService which is exactly providing
> > what you have described i can tell you some of the pitfalls.
> >
> > The multiple-bind feature you request is much more as it
> looks at the
> > first glance:
> >
> > 1) its against the standard, since multiple bind() requests
> for the same
> >
> > name shall be rejected by a NamingService with an
> > AlreadyBoundException
> > (ok, standards are never really up to the real world so we simply
> > forget about that :o) )
> >
> > 2) Your NamingService needs a database binding as backend.
> A transient
> > NS has the extreme drawback that it would forget about registered
> > servers on restart, so either you need a database for persistent
> > storage of registered servers, or your servers would have to
> > reregister
> > every minute to enshure that NS knows all servers.
> >
> > 3) Your NS must implement a lifecheck towards your servers,
> yeah, thats
> > really
> > nasty since you risk to give out invalid object references if you
> > dont
> > do this. This just causes nasty errors on client side and therefor
> > nasty
> > questions from your customer ;o) So on every request you have to
> > check
> > if the servant you are going to return to client is still alive.
> >
> > 4) your NS must properly handle situations where your servers
> > reregister.
> > Sounds easy, but its not, since it forces a deep understanding of
> > IORs
> > and whats inside IORs (which is clearly not in scope of CORBA
> > standard).
> > Also moving of servers or permanently shutdowns must be handled
> > properly,
> > so you need a good "cleanup" handling inside your NS or
> you risk that
> >
> > it "explodes" internally because of old, dead or double
> references of
> > registered
> > servers.
> >
> > So after all its not just the bind() implementation you
> have to change
> > ;o)
> > You can make things easier depending of which level of
> reliability is
> > needed
> > for your project, but its not that easy.
> >
> > Regards
> > Marc
> >
> > > -----Original Message-----
> > > From: jacorb-developer-bounces@lists.spline.inf.fu-berlin.de
> > > [mailto:jacorb-developer-bounces@lists.spline.inf.fu-berlin.de
> > ] On Behalf Of ext flib
> > > Sent: Dienstag, 9. Februar 2010 03:02
> > > To: Discussions concerning CORBA development with JacORB
> > > Subject: Re: [jacorb-developer] Name servce load balancing
> > >
> > >
> > > Hi Chirantan,
> > >
> > > the drawback of the multi-bind feature might be for you:
> > > * restarting a service, the new instance will rebind with new
> > > objref, the
> > > old invalid objref may stay in nameservice forever or at
> > > least some time
> > > causing troubles being resolved by client, such as connection
> > > errors. You
> > > must implement a liveliness check within the nameservice,
> but this may
> > > cause new problems in case of short time network outage
> etc. and name
> > > service might assume the objectref-binding might have become
> > > invalid, etc
> > > etc.
> > >
> > > * Moreover the multi-bind solution does not allow grouping
> > > of services.
> > > For maintenance or performance it may be useful to associate
> > > each client
> > > with a specific server-farm (location) and service-instances. The
> > > roundrobin approach per bind-entry does not allow to control
> > > this or to
> > > form sets/groups.
> > >
> > > Well, the location-forward service provides:
> > > * client's initial request to name-service is forwarded, eg
> > > location NS-A
> > > or NS-B.
> > > * client will stick to that name-service once forwarded
> > > (protocol feature)
> > > * client will communicate with name-service directly, no gateway
> > > * successive resolv-requests will return objrefs from same
> > > name-service
> > > * no changes in client code required
> > > * no changes in server code neither
> > > * allows grouping of services and the access to them,
> each group is
> > > associated with a single name-service
> > > * easy maintenance, restart of one location
> > > (services+nameservice) affects
> > > a subset of clients, others are unaffected
> > >
> > > The location-forwarding is a CORBA/IIOP built-in-feature,
> every ORB
> > > supports.
> > >
> > > Just tell me if you need to know more details.
> > >
> > > Hope that helps, flib
> > >
> > > <chirantan@2pirad.com>:
> > > > Hi Flib,
> > > >
> > > > Thanks for your suggestion.
> > > > However my requirement is to load balance multiple servers
> > > registered in
> > > > one
> > > > single name service. Suppose two servers Server A and
> Server B are
> > > running
> > > > on different machines but both of them bind to one common
> > > name service
> > > with
> > > > some kind of grouping mechanism so that the client
> looks up for them
> > > using
> > > > a
> > > > common name and name service returns either A or B
> using round-robin
> > > load
> > > > balancing within the two.
> > > > Also I cannot touch the client side code, whatever to be
> > > done is to be
> > > done
> > > > at server side only.
> > > > I can think of developing a name server (including a separate
> > > > NamingContextImpl class to customize bind, rebind and
> > > resolve methods)
> > > and
> > > > use it instead of org.jacorb.naming.NameServer. But I'm
> not sure if
> > > there
> > > > are any pitfalls.
> > > >
> > > > Thanks again,
> > > > Chirantan
> > > >
> > > > On Mon, Feb 8, 2010 at 4:55 PM, flib
> > > <flib@icoup-consulting.com> wrote:
> > > >
> > > >>
> > > >> Hi Chirantan
> > > >>
> > > >> If you have got two separate sets of services, each set
> > > binding to its
> > > >> local name service, the problem is to redirect client's
> > > name service
> > > >> requests to one or the other service-set.
> > > >>
> > > >> You have got to configure your client with name
> service reference
> > > >> pointing
> > > >> to an redirector/forwarder, eg
> > > corbaloc:loadbalancerhost:/NameService
> > > >>
> > > >> The redirector/forwarder can be implemented using the
> interceptor
> > > feature
> > > >> of CORBA/POA, replacing the intial object-ref on client
> > > side by a new
> > > >> forward-location.
> > > >>
> > > >> Does this help you?
> > > >>
> > > >> Cheers, Flib
> > > >>
> > > >> <chirantan@2pirad.com>:
> > > >> > Hi Flib,
> > > >> >
> > > >> > Thanks a lot for your response. Among the options you
> > > mentioned, I'd
> > > >> like
> > > >> > to
> > > >> > go for the last one, ie, loadbalancing full name service.
> > > >> > Could you please mention the steps to be implemented
> for that?
> > > >> >
> > > >> > Regards,
> > > >> > Chirantan
> > > >> >
> > > >> > On Sun, Feb 7, 2010 at 3:45 PM, flib
> <flib@icoup-consulting.com>
> > > wrote:
> > > >> >
> > > >> >>
> > > >> >> Hi Chirantan,
> > > >> >>
> > > >> >> > I need to register multiple servers against the same
> > > name in name
> > > >> >> service
> > > >> >> > and then distribute client requests to those servers using
> > > >> round-robin
> > > >> >> load
> > > >> >> > balancing from name service. Any suggestions on how
> > > to implement
> > > >> >> > this
> > > >> >> > inJacorb?
> > > >> >>
> > > >> >> The JacORB name-service does not provide the
> > > load-balancing service
> > > >> >> out
> > > >> >> of
> > > >> >> the box you ask for.
> > > >> >>
> > > >> >> But, I can think of different options for your problem.
> > > It depends
> > > on
> > > >> >> your
> > > >> >> requirements.
> > > >> >> Options might be:
> > > >> >> * using an intermediate service providing that feature
> > > >> >> * using federated name-services, implementing and
> registering a
> > > >> >> sub-directory with the required behaviour
> > > >> >> * loadbalancing full Name-Service
> > > >> >>
> > > >> >> Hope this helps? Which option would you favor?
> > > >> >>
> > > >> >> Cheers, flib
> > >
> > > > ____________________________________
> > > > Visit us at http://www.2pirad.com
> > > > _______________________________________________
> > > > jacorb-developer maillist -
> > > > jacorb-developer@lists.spline.inf.fu-berlin.de
> > > >
> > > https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-
> > > developer
> > >
> > > --
> > > flib@icoup-consulting.com
> > > technology consulting
> > > icoup - technology and management consulting
> > > http://www.icoup-consulting.com
> > >
> > > _______________________________________________
> > > jacorb-developer maillist -
> > > jacorb-developer@lists.spline.inf.fu-berlin.de
> > > https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-
> > > developer
> > >
> >
> > _______________________________________________
> > jacorb-developer maillist -
> > jacorb-developer@lists.spline.inf.fu-berlin.de
> >
> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-
> developer
> >
>
> ____________________________________
> Visit us at http://www.2pirad.com
> _______________________________________________
> jacorb-developer maillist -
> jacorb-developer@lists.spline.inf.fu-berlin.de
> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-
> developer
>
_______________________________________________
jacorb-developer maillist - jacorb-developer@lists.spline.inf.fu-berlin.de
https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic