Re: Multi-mastersD

[Marco Massenzio <ma...@mesosphere.io>]

(I'm sure I'm missing something here, so please forgive if I'm stating the
obvious)

This is actually very well supported right now: you can use "slave
attributes" (if, eg, you want to name the various clusters differently and
launch tasks according to those criteria) that would be passed on to the
Frameworks along with the resource offers: the frameworks could then decide
whether to accept the offer and launch tasks based on whatever logic you
want to implement.

You could use something like "--attributes="cluster:01z99; os:ubuntu-14-04;
jdk:8" or whatever makes sense.

*Marco Massenzio*
*Distributed Systems Engineer*

On Tue, Jul 7, 2015 at 8:55 AM, CCAAT <cc...@tampabay.rr.com> wrote:

> Hello team_mesos,
>
> Is there any reason one set of (3) masters cannot talk to and manage
> several (many) different slave clusters of (3)? These slave clusters
> would be different arch, different mixes of resources and be running
> different frameworks, but all share/use the same (3) masters.
>
>
> Ideas on how to architect this experiment, would be keenly appreciated.
>
>
> James
>
>

Re: Multi-mastersD

[CCAAT <cc...@tampabay.rr.com>]

I'm glad to know it is easy, that's what I was hoping for.


I want to keep the (3+) masters on line 7/24/365 but have different 
"teams" of slave that do different (industrial) tasks. Each team would 
be geographically close, if not on the same power buss. I would think
this is routine, but I have not tried it yet. Sure, the number of 
masters will expand as needed, but one pool of masters. Many many pools 
of mesos slaves with various abilities, in diverse if not extremely 
remote locations.


So it's been done? Experiences?  Many of these 'slave processor teams' 
will sleep for significant periods, if that matters. Think of it as a 
very distributed cluster with very diversified hardware and task 
requests que. Rarely working on a single BIG problem....
but still with that Big problem, one team capability.


Any suggestions for long term sleep issues of slaves? Upgrade scheduling 
? Data consistency once a team is awakened?


James



On 07/07/2015 10:08 AM, Marco Massenzio wrote:
> (I'm sure I'm missing something here, so please forgive if I'm stating
> the obvious)
>
> This is actually very well supported right now: you can use "slave
> attributes" (if, eg, you want to name the various clusters differently
> and launch tasks according to those criteria) that would be passed on to
> the Frameworks along with the resource offers: the frameworks could then
> decide whether to accept the offer and launch tasks based on whatever
> logic you want to implement.
>
> You could use something like "--attributes="cluster:01z99;
> os:ubuntu-14-04; jdk:8" or whatever makes sense.
>
> /Marco Massenzio/
> /Distributed Systems Engineer/
>
> On Tue, Jul 7, 2015 at 8:55 AM, CCAAT <ccaat@tampabay.rr.com
> <ma...@tampabay.rr.com>> wrote:
>
>     Hello team_mesos,
>
>     Is there any reason one set of (3) masters cannot talk to and manage
>     several (many) different slave clusters of (3)? These slave clusters
>     would be different arch, different mixes of resources and be running
>     different frameworks, but all share/use the same (3) masters.
>
>
>     Ideas on how to architect this experiment, would be keenly appreciated.
>
>
>     James
>
>