On Tue, Mar 26, 2013 at 8:19 AM, Joe Julian <joe@xxxxxxxxxxxxxxxx> wrote: > > > Anand Babu Periasamy <abperiasamy@xxxxxxxxx> wrote: > >>On Tue, Mar 26, 2013 at 5:59 AM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote: >>> 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? >> >>Admin declares the config servers manually. Automatic option is a >>disaster waiting to happen. >> >>We should set the minimum number of config servers required by default >>to 3, so that we can enforce quorum. Any failure would require the >>admin to declare replacement config servers manually. > > On that note, the additional quorum functionality should be implemented with regard to watchers before using a glusterfs store for configuration coordination. > > From what I've been reading, the biggest thing zookeeper has over any other solution is its robustness with regard to split-brain. If that was managed it seems like that would open up a number of possibilities to satisfy the other requirements. > Exactly. Even ZooKeeper requires min 3 servers and odd number of servers there after. For example of you have 4 servers, it will still handle only one node failure. With 2 node failures, it cannot elect majority. Where ever we go, we will have similar issues. We need to solve these issues for our sync-replication in any case. -- -ab Imagination is more important than knowledge --Albert Einstein
