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 <[email protected]
<mailto:[email protected]>> 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
