From 105aa1d1524971f1c40bdc1b68781b63453778f5 Mon Sep 17 00:00:00 2001 From: N Balachandran Date: Tue, 13 Dec 2016 20:52:37 +0530 Subject: Feature page for Rebalance Estimates Change-Id: I086a9bfb15a47668fe28684e480d6230fd3e7811 Signed-off-by: N Balachandran Reviewed-on: http://review.gluster.org/16119 Reviewed-by: Shyamsundar Ranganathan Tested-by: Shyamsundar Ranganathan --- under_review/rebalance-estimates.md | 128 ++++++++++++++++++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 under_review/rebalance-estimates.md diff --git a/under_review/rebalance-estimates.md b/under_review/rebalance-estimates.md new file mode 100644 index 0000000..2a2c299 --- /dev/null +++ b/under_review/rebalance-estimates.md @@ -0,0 +1,128 @@ +Feature +------- + +Summary +------- + +Provide a user interface to determine when the rebalance process will complete + +Owners +------ +Nithya Balachandran + + +Current status +-------------- +Patch being worked on. + + +Related Feature Requests and Bugs +--------------------------------- +https://bugzilla.redhat.com/show_bug.cgi?id=1396004 +Desc: RFE: An administrator friendly way to determine rebalance completion time + + +Detailed Description +-------------------- +The rebalance operation starts a rebalance process on each node of the volume. +Each process scans the files and directories on the local subvols, fixes the layout +for each directory and migrates files to their new hashed subvolumes based on the +new layouts. + +Currently we do not have any way to determine how long the rebalance process will +take to complete. + +The proposed approach is as follows: + + 1. Determine the total number of files and directories on the local subvol + 2. Calculate the rate at which files have been processed since the rebalance started + 3. Calculate the time required to process all the files based on the rate calculated + 4. Send these values in the rebalance status response + 5. Calculate the maximum time required among all the rebalance processes + 6. Display the time required along with the rebalance status output + + +The time taken is a factor or the number and size of the files and the number of directories. +Determining the number of files and directories is difficult as Glusterfs currently +does not keep track of the number of files on each brick. + +The current approach uses the statfs call to determine the number of used inodes +and uses that number as a rough estimate of how many files/directories ae present +on the brick. However, this number is not very accurate because the .glusterfs +directory contributes heavily to this number. + +Benefit to GlusterFS +-------------------- +Improves the usability of rebalance operations. +Administrators can now determine how long a rebalance operation will take to complete +allowing better planning. + + +Scope +----- + +#### Nature of proposed change + +Modifications required to the rebalance and the cli code. + +#### Implications on manageability + +gluster volume rebalance status output will be modified + +#### Implications on presentation layer + +None + +#### Implications on persistence layer + +None + +#### Implications on 'GlusterFS' backend + +None + +#### Modification to GlusterFS metadata + +None + +#### Implications on 'glusterd' + +None + +How To Test +----------- + +Run a rebalance and compare the estimates with the time actually taken to complete +the rebalance. + +The feature needs to be tested against large workloads to determine the accuracy +of the calculated times. + +User Experience +--------------- + +Gluster volume rebalance status +will display the expected time left for the rebalance process to complete + + +Dependencies +------------ + +None + +Documentation +------------- + +Documents to be updated with the changes in the rebalance status output. + + +Status +------ +In development. + + + +Comments and Discussion +----------------------- + +*Follow here* -- cgit