<div dir="ltr">Hello,<div><br></div><div>As we are gearing up for Release-8, and its planning, I wanted to bring up one of my favorite topics, &#39;Thin-Arbiter&#39; (or Tie-Breaker/Metro-Cluster etc etc).</div><div><br></div><div>We have made thin-arbiter release in v7.0 itself, which works great, when we have just 1 cluster of gluster. I am talking about a situation which involves multiple gluster clusters, and easier management of thin-arbiter nodes. (Ref: <a href="https://github.com/gluster/glusterfs/issues/763">https://github.com/gluster/glusterfs/issues/763</a>)</div><div><br></div><div>I am working with a goal of hosting a thin-arbiter node service (free of cost), for which any gluster deployment can connect, and save their cost of an additional replica, which is required today to not get into split-brain situation. Tie-breaker storage and process needs are so less that we can easily handle all gluster deployments till date in just one machine. When I looked at the code with this goal, I found that current implementation doesn&#39;t support it, mainly because it uses &#39;volumename&#39; in the file it creates. This is good for 1 cluster, as we don&#39;t allow duplicate volume names in a single cluster, or OK for multiple clusters, as long as volume names are not colliding.</div><div><br></div><div>To resolve this properly we have 2 options (as per my thinking now) to make it truly global service.</div><div><br></div><div>1. Add &#39;volume-id&#39; option in afr volume itself, so, each instance picks the volume-id and uses it in thin-arbiter name. A variant of this is submitted for review - <a href="https://review.gluster.org/23723">https://review.gluster.org/23723</a> but as it uses volume-id from io-stats, this particular patch fails in case of brick-mux and shd-mux scenarios.  A proper enhancement of this patch is, providing &#39;volume-id&#39; option in AFR itself, so glusterd (while generating volfiles) sends the proper vol-id to instance. </div><div><br></div><div>Pros: Minimal code changes to the above patch.</div><div>Cons: One more option to AFR (not exposed to users).</div><div><br></div><div>2. Add<b> cluster-id </b>to glusterd, and pass it to all processes. Let replicate use this in thin-arbiter file. This too will solve the issue.</div><div><br></div><div>Pros: A cluster-id is good to have in any distributed system, specially when there are deployments which will be 3 node each in different clusters. Identifying bricks, services as part of a cluster is better.</div><div><br></div><div>Cons: Code changes are more, and in glusterd component.</div><div><br></div><div>On another note, 1 above is purely for Thin-Arbiter feature only, where as 2nd option would be useful in debugging, and other solutions which involves multiple clusters.</div><div><br></div><div>Let me know what you all think about this. This is good to be discussed in next week&#39;s meeting, and taken to completion.</div><div><br></div><div>Regards,</div><div>Amar</div><div>---</div><div><font color="#666666"><a href="https://kadalu.io">https://kadalu.io</a></font></div><div><font color="#666666">Storage made easy for k8s</font></div><div><br></div></div>