Services collocation

[Andrey Kornev]

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.

Any ideas/suggestion are very much appreciated!

Thanks
Andrey
     

[dsetrakyan]

On Mon, Sep 7, 2015 at 6:05 PM, Andrey Kornev <[hidden email]>
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
>

[Andrey Kornev]

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.

Thanks
Andrey

> From: [hidden email]
> Date: Mon, 7 Sep 2015 21:02:46 -0700
> Subject: Re: Services collocation
> To: [hidden email]
>
> On Mon, Sep 7, 2015 at 6:05 PM, Andrey Kornev <[hidden email]>
> 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
> >

     

[dsetrakyan]

On Tue, Sep 8, 2015 at 8:07 AM, Andrey Kornev <[hidden email]>
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: [hidden email]
> > Date: Mon, 7 Sep 2015 21:02:46 -0700
> > Subject: Re: Services collocation
> > To: [hidden email]
> >
> > On Mon, Sep 7, 2015 at 6:05 PM, Andrey Kornev <[hidden email]>
> > 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
> > >
>
>