ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Services collocation
Date Tue, 08 Sep 2015 15:55:36 GMT
On Tue, Sep 8, 2015 at 8:07 AM, Andrey Kornev <andrewkornev@hotmail.com>
wrote:

> Dmitriy,
>
> In case of topology changes, I'd prefer the services to stay on the same
> node they are currently on, as long as possible. In general, my goal is to
> keep the related singleton services together, and minimize their movements
> between the nodes. But if they have to move, they move as a group, all to
> the same new node.
>

Andrey,

I think you may need to create your own custom affinity function with the
specific behavior for your application. Then configure this affinity
function for the cache you use to determine the affinity grouping for your
services.


>
> Thanks
> Andrey
>
> > From: dsetrakyan@apache.org
> > Date: Mon, 7 Sep 2015 21:02:46 -0700
> > Subject: Re: Services collocation
> > To: dev@ignite.apache.org
> >
> > On Mon, Sep 7, 2015 at 6:05 PM, Andrey Kornev <andrewkornev@hotmail.com>
> > wrote:
> >
> > > Hello,
> > >
> > > I'd like to be able to deploy my cluster-wide singleton services all
> > > collocated on the same cluster node. What is the best way to achieve
> that?
> > >
> > > Ideally, I'd like to be able to define the "service groups" where all
> > > services in a group would be deployed on the same node, whereas the
> > > different groups would be load balanced all over the cluster. The
> services
> > > included in the same group would usually the ones that share their data
> > > or/and closely collaborate on the same task. By collocating services in
> > > such a way, I'll be able to optimize some of the execution paths
> (reducing
> > > the number of remote invocations, for example) and have in-process
> > > coordination between the services (if necessary) as a bonus.
> > >
> > > I've considered the affinity-based collocation (where the "group" would
> > > consist of the all services configured with the same affinity key),
> but the
> > > drawback, IMHO, is that topology changes may cause unnecessary mass
> > > migration of the services to the new primary node where the services
> get
> > > then restarted. I'd like to avoid paying the service shutdown/start-up
> > > overhead as much as possible, since in my case it's pretty expensive.
> > >
> >
> > Andrey, what would you like to happen in case of topology change? Say a
> new
> > node is added - do you want your services migrated to that node?
> >
> >
> > >
> > > Any ideas/suggestion are very much appreciated!
> > >
> > > Thanks
> > > Andrey
> > >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message