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 [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
