On Mon, Nov 30, 2015, at 12:29, Giuseppe Ragusa wrote: > Hi all, > I'm writing as a followup to a related wishlist item that I recently posted on the oVirt users mailing list (see the last point in http://lists.ovirt.org/pipermail/users/2015-November/036048.html ). > > As far as I know, GlusterFS currently supports specifying a bandwidth limit only for geo-replication traffic. > > On the other side, it is my understanding that a cluster where peers have been probed on a separate, dedicated network (accessed by all peers with dedicated NICs) will automatically relegate heal/rebalance/etc traffic (I mean: anything besides client-related traffic) to that network, so that if you have a different client-facing network the aforementioned goal should be already attainable (to be honest: even in that scenario, a CPU limiting feature for those heal/rebalance/etc tasks could be needed but currently I think it is possible only to limit glusterd/glusterfsd as a whole). After some reading of GlusterFS proposed specs [1] I must partially correct my statement above by specifying that the above holds true only (barrying some specific DNS/routing/firewalling tricks) if clients use NFS/Samba (generally anything besides FUSE/libgfapi) to access GlusterFS cluster servers. > The main scope for the present RFE is to allow bandwidth limiting for those cases where peers are clients too (and maybe the only clients), just like in an hyperconverged oVirt setup. Further reading through linked discussions [2] brought up a possible way to achieve the goal in the servers-are-clients case by offloading (separately: heal/rebalance vs clients) traffic to many separate networks once the Split-Network spec will be implemented; I still think that the QoS-facilitating changes proposed below could be useful by themselves and maybe of easier implementation (is 3.8 stuff still open for small proposals?). [1] https://github.com/gluster/glusterfs-specs/blob/master/in_progress/Split%20Network.md [2] http://www.gluster.org/pipermail/gluster-users/2014-November/019471.html > As a final note, it would be fine if the goal could be reached by OS-level means, as with QoS policy, but this too seems not possible at the moment: maybe by allowing to specify dedicated fixed ports for heal/rebalance/etc outgoing traffic then we could apply some traffic control to those ports only. > > Many thanks in advance for your attention and excuse me for any errors/misunderstandings on my part. > > Regards, > Giuseppe > > PS: sorry if this gets double-posted, but I initially forgot to use the subscribed email address when sending > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
