<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 23, 2017 at 12:41 PM, Poornima Gurusiddaiah <span dir="ltr">&lt;<a href="mailto:pgurusid@redhat.com" target="_blank">pgurusid@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:times new roman,new york,times,serif;font-size:12pt;color:#000000"><div>Hi,</div><div><br></div><div>This mail is regarding the gfproxy feature, please go through the same and let us know your thoughts.<br></div><div><br></div><div>About the gfproxy feature:<br></div><div>------------------------------<wbr>-----<br></div><div>As per the current architecture of Gluster, the client is more intelligent and has all the clustering logic. This approach has its own pros and cons. In several use cases, it is desirable to have all this clustering logic on the server side and have, as thin client as possible. Eg: Samba, Qemu, Block device export etc. This makes the upgrades easier, and is more scalable as the resources consumed by thin clients are much less than normal client.<br></div><div><br></div><div>Approach:<br></div><div>Client volfile is split into two volfiles:<br></div><div>1. Thin client volfile: master(gfapi/Fuse) followed by Protocol/client<br></div><div>2. gfproxyd volfile: protocol/server, performance xlators, cluster xlators, protocol/servers.<br>With this model, the thin client connects to gfproxyd and glusterd(like always). gfproxyd connects to all the bricks. The major problem with this is performance, when the client and gfproxyd are not co-located.<br></div><div><br></div><div><br></div><div>What is already done by Facebook:<br></div><div>------------------------------<wbr>---------------<br></div><div>1. Volgen code for generating thin client volfile and the gfproxyd daemon volfile.<br></div><div>2. AHA translator on the thin client, so that on a restart/network disruptions between thin client and gfproxyd, we retry fops and the client doesn&#39;t become inaccessible.<br></div><div><br></div><div><br></div><div>What remains to be done:<br></div><div>------------------------------<wbr>---<br></div><div>1. Glusterd managing the gfproxyd<br></div><div>    Currently the gfproxy daemon listens on 40000 port, if we want to run multiple gfproxyd (one per volume)<br></div></div></div></blockquote><div><br></div><div>One per volume seems reasonable. However as we start scaling the number of volumes, the number of gfproxy processes might become overwhelming and necessitate us to multiplex (as has been the case with bricks). We can also consider the possibility of a subset of volumes being exported through a node and have different subset of volumes be exported through other nodes. Further thought is necessary to evolve the set of policies needed for managing gfproxyd daemons on trusted storage pool nodes and possibly outside trusted storage pool too.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:times new roman,new york,times,serif;font-size:12pt;color:#000000"><div></div><div>2. Redo the volgen and daemon management in glusterd2<br></div><div>    -  Ability to be able to run daemons on subset of cluster nodes<br></div><div>    -  ssl<br></div><div>    - Validate with other features like snap, tier, <br></div><div>3. Graph switch for the gfproxyd<br></div></div></div></blockquote><div><br></div><div><br></div><div>I wonder if we can implement a delay interval before failing over to a different server in AHA. If we can do that, then we may not have to worry about graph switch and instead resort to restart of gfproxyd daemons upon configuration changes that affect graph topology. Delay before failing over will also help in situations where there is a transient network interruption.</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:times new roman,new york,times,serif;font-size:12pt;color:#000000"><div></div><div>4. Failover from one gfproxyd to another<br></div></div></div></blockquote><div><br></div><div>What are the problems we need to consider here? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:times new roman,new york,times,serif;font-size:12pt;color:#000000"><div></div><div>5. Less resource consumption on thin client - Memory and threads<br></div><div>6. Performance analysis<br></div><div><br></div><div>Issue: <a href="https://github.com/gluster/glusterfs/issues/242Issue:" target="_blank">https://github.com/gluster/<wbr>glusterfs/issues/242</a></div></div></div></blockquote><div><br></div><div><br></div><div>Might be a good idea to capture this discussion on the issue and continue there!</div><div><br></div><div>Thanks,</div><div>Vijay</div><div><br></div></div></div></div>