Mailing-List: contact user-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@mesos.apache.org
MIME-Version: 1.0
Sender: rasputnik@gmail.com
In-Reply-To: 
 <BN1PR03MB1550F889F93F15DC31537659AAE0@BN1PR03MB155.namprd03.prod.outlook.com>
References: 
 <BN1PR03MB155222A3649C76ECA5F951A9AA40@BN1PR03MB155.namprd03.prod.outlook.com>
	<CABTw1kUd9U3+c7jXfHuoC6-JjffGDrmYwysksyVS0YGeHdVQOw@mail.gmail.com>
	<55845DE5.70704@pobox.com>
	<BN1PR03MB1558482CC8B8375F67F7AF09AA40@BN1PR03MB155.namprd03.prod.outlook.com>
	<55847441.4000800@tampabay.rr.com>
	<BN1PR03MB1550F889F93F15DC31537659AAE0@BN1PR03MB155.namprd03.prod.outlook.com>
Date: Thu, 25 Jun 2015 17:46:15 +0100
Message-ID: 
 <CAK5eLPS8nFGospc4Q9qvfK8X3nDQC4LOnTKXSVv60HBxV2C43Q@mail.gmail.com>
Subject: Re: Thoughts and opinions in physically building a cluster
From: Dick Davies <dick@hellooperator.net>
To: "user@mesos.apache.org" <user@mesos.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

That doesn't sound too bad (it's a fairly typical setup e.g. on an Amazon V=
PC).
You probably want to avoid NAT or similar things between master and
slaves to avoid
a lot of LIBPROCESS_IP tricks so same switch sounds good.

Personally I quite like the master/slave distinction.

I wouldn't want a runaway set of  tasks to bog down the masters and
operationally we'd alert
if we're starting to lose masters whereas the slaves are 'cattle' and
we can just spin up more as
they die if need be (it's a little more tricky to scale out masters
and zookeepers so they get treated
as though they were a bit less expendable).

I co-locate the zookeeper ensemble on the masters on smaller clusters
to save VM count,
but that's more personal taste than anything.

On 25 June 2015 at 17:12, Daniel Gaston <Daniel.Gaston@dal.ca> wrote:
> So this may be another relatively noob question, but when designing a mes=
os cluster, is it basically as simple as the nodes connected by a switch? S=
ince any of the nodes can be "master nodes" or acting as both master and sl=
ave, I am guessing there is no need for another head node as you would have=
 with a traditional cluster design. But would each of the nodes then have t=
o be connected to the external/institutional network?
>
> My rough idea was for this small cluster to not be connected to the main =
institutional network but for my workstation to be connected to both the cl=
uster's network as well as to the institutional network
>
>
> ________________________________________
> From: CCAAT <ccaat@tampabay.rr.com>
> Sent: June-19-15 4:57 PM
> To: user@mesos.apache.org
> Cc: ccaat@tampabay.rr.com
> Subject: Re: Thoughts and opinions in physically building a cluster
>
> On 06/19/2015 01:28 PM, Daniel Gaston wrote:
>>
>> On 19/06/2015 18:38, Oliver Nicholas wrote:
>>> Unless you have some true HA requirements, it seems intuitively
>>> wasteful to have 3 masters and 2 slaves (unless the cost of 5 nodes is
>>> inconsequential to you and you hate the environment).
>> Any particular reason not to have three nodes which are acting both as
>> master and slaves?
>>
>> None at all. I'm not a cluster or networking guru, and have only played =
with mesos in
>> cloud-based settings so I wasn't sure how this would work. But it makes =
sense, that way
>> the 'standby' masters are still participating in the zookeeper quorum wh=
ile still being
>> available to do real work as slave nodes.
>
> Daniel. There is no such thing as a 'cluster guru'. It's all 'seat of
> the pants' flying right now; so you are fine what you are doing and
> propose. If codes do not exist to meet your specific needs and goals,
> they can  (should?) be created.
>
>
> I'm working on an architectural expansion Where nodes (virtual, actual
> or bare metal) migrate from master --> entrepreneur --> worker --> slave
> --> embedded (bare metal or specially attached hardware. I'm proposing
> to do all of this with the "Autonomy_Function" and decisions being made
> bottom_up as opposed to the current top_down dichotomy. I'm prolly going
> to have to 'fork codes' for a while to get things stable and then
> hope they are included; when other minds see the validity of the ideas.
>
>
> Surely one "box" can be set up as both master and slave. Moving slaves
> to masters, should be an automatic function and will prolly will be
> address in the future codes of mesos.
>
>
> PS: Keep pushing your ideas and do not take no for an answer!
> Mesos belongs to everybody.....
>
> hth,
> James
>