Red Hat Bugzilla – Bug 1468950
[RFE] Have a global option to set per node limit to the number of multiplexed brick processes
Last modified: 2017-07-25 06:09:28 EDT
Description of problem:
The main purpose the brick multiplexing feature tries to serve is to reduce the number of brick processes, hence reusing resources. Currently, we do not have a cap on the number of brick processes that can be run per node with brick multiplexing enabled. The proposal is to have a global option cluster.max-bricks-per-process which can control the number of brick instances to be attached to a single brick process.
upstream patch : https://review.gluster.org/17469
downstream patches :
b is the number of bricks existing per node
n is cluster.max-bricks-per-process
1)default should allow all bricks to point to same brick process ie on glusterfsd per node irrespective of number of bricks hosted --pass
2)setting to a value say n, must be effective from here on ---->PASS, but will be effective for new vol creates only, existing volumes would have to be restarted, for this effect
3)if bricks on fsd >n(ie which were created before setting value to n), still new bricks must get created on new fsd -->PASS
4)if already b>>n, and offline one of the b, still a new brick create must use a new pid(as long b doesn't go less than n)
5)if b>=n and add-brick must spawn new process
6)if b=n ,remove brick and then add new brick/vol must use existing proc, as b<n with remove brick
All the cases mentioned in comment#7 have passed
hence moving this bz to verified
Note: The memory consumption and profiling should be check by perf team and if any descripencies there, that can be tracked seperatekly.
Functionally, the RFE is healthy and any further issues can be tracked with new bugs.
Eg: Some cosmetic bugs were raised as below
1474344 - Allow only the maximum number of bricks supported for cluster.max-bricks-per-process
1474342 - reset cluster.max-bricks-per-process value when brick mux is disabled