sijie commented on a change in pull request #847: BP-23: Ledger Balancer (WIP) URL: https://github.com/apache/bookkeeper/pull/847#discussion_r159577803
########## File path: site/bps/BP-23-ledger-rebalancer.md ########## @@ -0,0 +1,50 @@ +--- +title: "BP-23: ledger balancer" +issue: https://github.com/apache/bookkeeper/846 +state: "WIP" +release: "x.y.z" +--- + +### Motivation + +There are typical two use cases of _Apache BookKeeper_, one is *Messaging/Streaming/Logging* style use cases, the other one is *Storage* style use cases. + +In Messaging/Streaming/Logging oriented use case (where old ledgers/segments are most likely will be deleted at some point), we don't actually need to rebalance the ledgers stored on bookies. + +However, +In Storage oriented use cases (where data most likely will never be deleted), BookKeeper data might not always be placed uniformly across bookies. One common reason is addition of new bookies to an existing cluster. This proposal is proposing to provide a balancer mechanism (as an utility, also as part of AutoRecovery daemon), that analyzes ledger distributions and balances ledgers across bookies. + +It replicated ledgers to new bookies (based on resource-aware placement policies) until the cluster is deemed to be balanced, which means that disk utilization of every bookie (ratio of used space on the node to the capacity of the node) differs from the utilization of the cluster (ratio of used space on the cluster to total capacity of the cluster) by no more than a given threshold percentage. Review comment: > Only recovery would have to deal with changing ensembles. I am not sure I understand your comment here. But in current implementation, only write failures on normal writes and ledger recovery deal with ensemble changes. rereplication doesn't change ensemble. The ensemble is only updated when a fragment is fully replicated. > Perhaps for rereplication and for this balancing, instead of copying by fragment, we should just copy the whole ledger, 0->lac. I am not sure it worths changing the copying mechanism here. because rereplication and balancing would only deal with sealed fragments. I don't think there are issues with current copying mechanism, unless I missed anything. This BP here should be more focusing on the strategy on balancing data using whatever copying mechanism available in the system. Changing the copying mechanism should be a different task. Otherwise we are mixing two big changes here, which would make things a bit complicated to discuss, review and implement. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
