> 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@xxxxxxxxxx> >To: "Anand Babu Periasamy" <abperiasamy@xxxxxxxxx> >Subject: Re: 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@xxxxxxxxxx > https://lists.nongnu.org/mailman/listinfo/gluster-devel > -- Ian Latter Late night coder .. http://midnightcode.org/
