<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 09/05/2014 03:51 PM, Kaushal M
wrote:<br>
</div>
<blockquote
cite="mid:CAOujamV8MDm6R1msy70A8aTuR71w7p1_xB7oS4ucJqw+K3v39A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>GlusterD performs the following functions as the management
daemon for GlusterFS:<br>
</div>
- Peer membership management<br>
- Maintains consistency of configuration data across nodes
(distributed configuration store)
<div>- Distributed command execution (orchestration)<br>
- Service management (manage GlusterFS daemons)<br>
- Portmap service for GlusterFS daemons<br>
<br>
<br>
This proposal aims to delegate the above functions to
technologies that solve these problems well. We aim to do this
in a phased manner.<br>
The technology alternatives we would be looking for should
have the following properties,<br>
- Open source<br>
- Vibrant community<br>
- Good documentation<br>
- Easy to deploy/manage<br>
<br>
This would allow GlusterD's architecture to be more modular.
We also aim to make GlusterD's architecture as transparent and
observable as possible. Separating out these functions would
allow us to do that. <br>
<br>
Bulk of current GlusterD code deals with keeping the
configuration of the cluster and the volumes in it consistent
and available across the nodes. The current algorithm is not
scalable (N^2 in no. of nodes) and doesn't prevent
split-brain of configuration. This is the problem area we are
targeting for the first phase.<br>
<br>
As part of the first phase, we aim to delegate the distributed
configuration store. We are exploring consul [1] as a
replacement for the existing distributed configuration store
(sum total of /var/lib/glusterd/* across all nodes). Consul
provides distributed configuration store which is consistent
and partition tolerant. By moving all Gluster related
configuration information into consul we could avoid
split-brain situations.<br>
</div>
</div>
</blockquote>
Did you get a chance to go over the following questions while making
the decision? If yes could you please share the info.<br>
What are the consistency guarantees for changing the configuration
in case of network partitions?<br>
specifically when there are 2 nodes and 1 of them is not
reachable?<br>
consistency guarantees when there are more than 2 nodes?<br>
What are the consistency guarantees for reading configuration in
case of network partitions?<br>
<br>
Pranith<br>
<blockquote
cite="mid:CAOujamV8MDm6R1msy70A8aTuR71w7p1_xB7oS4ucJqw+K3v39A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
All development efforts towards this proposal would happen in
parallel to the existing GlusterD code base. The existing code
base would be actively maintained until GlusterD-2.0 is
production-ready.<br>
<div><br>
</div>
<div>This is in alignment with the GlusterFS Quattro proposals
on making GlusterFS scalable and easy to deploy. This is the
first phase ground work towards that goal.</div>
<div><br>
</div>
<div>Questions and suggestions are welcome.</div>
<div><br>
</div>
<div>~kaushal</div>
<div><br>
</div>
<div>[1] : <a moz-do-not-send="true"
href="http://www.consul.io/">http://www.consul.io/</a></div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gluster-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://supercolony.gluster.org/mailman/listinfo/gluster-users">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a></pre>
</blockquote>
<br>
</body>
</html>