[Gluster-devel] Glusterd: A New Hope

[Ian Latter]

> It would be nice to have two or more proposals
> that have been been thought through to approximately the same level of
> detail (which isn't all that high really).  Otherwise we can't really
> make rational comparisons and choices.

Well then add the following as a thought through proposal :-

See section 6.3.1 for Directory (of services) and Meta-data replication details;
  http://www.xtreemfs.org/xtfs-guide-1.4/index.html

It uses FaTLease for consensus via Paxos amongst primary and secondary replicas;
  http://personals.ac.upc.edu/toni/papers/HPDC-08.pdf

>From a user perspective the "cluster" establishment is done via text file configuration to direct nodes to network services;
  http://www.xtreemfs.org/quickstart_distr.php



----- Original Message -----
>From: "Jeff Darcy" <jdarcy at redhat.com>
>To: "Anand Babu Periasamy" <abperiasamy at gmail.com>
>Subject:  Re: [Gluster-devel] Glusterd: A New Hope
>Date: Tue, 26 Mar 2013 08:59:32 -0400
>
> On 03/25/2013 11:59 PM, Anand Babu Periasamy wrote:
> > gluster meta-volume + zeromq for notification (pub/sub) will solve our
> > problems largely and still be light weight.  In a large scale
> > deployment, it is not a good idea to declare all the servers as
> > coordination servers. Since meta-volume is a regular distributed
> > replicated gluster volume, it can always be expanded later depending
> > on the load and availability requirements.
> 
> How do you propose to solve the bootstrap problem?  How do we choose
> which subset of all servers would have pieces of this meta-volume?  How
> do we coordinate its expansion, or detect and respond to failures of
> itscomponents?  What issues does 0MQ introduce with respect to daemons
> or network capabilities?  It would be nice to have two or more proposals
> that have been been thought through to approximately the same level of
> detail (which isn't all that high really).  Otherwise we can't really
> make rational comparisons and choices.  Every approach to any
> non-trivial problem has its pitfalls.  If we don't look for them we risk
> choosing an approach with problems which are merely less obvious but no
> less severe.
> 
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> 


--
Ian Latter
Late night coder ..
http://midnightcode.org/