-
Notifications
You must be signed in to change notification settings - Fork 9.2k
HDFS-16646. RBF: Support an elastic RouterRpcFairnessPolicyController #4519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
💔 -1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
|
@ayushtkn @Hexiaoqiao @goiri Are you interested in checking out this PR? I feel that RBF should need a dynamically or elastic RouterRpcFairnessPolicyController. And this elastic solution used in our prod environment has a very obvious effect. |
|
@ZanderXu Thanks for your proposal. There was another solution for the improvement as #4307. Would you mind to review and give a compare? IIRC, this policy have been discussed for a while and does not reach agreement yet, it will be more useful for end user if we could push forward it here. |
|
@Hexiaoqiao Thanks for your comment. #4307 is also our solution. It has an obvious effect compared with StaticRouterRpcFairnessPolicyController, but it is slightly flawed in dealing with burst traffic. I can review it and push it forward if need. According to my previous practical experience, my RP can also play a very obvious effect in dealing with burst traffic. @goiri @ayushtkn @Hexiaoqiao Can you share your practical experience? Because it's very helpful for end user, so I very much hope that we can reach a conclusion about it, so that we can push it forward. Looking forward your ideas. Thanks~ |
|
We're closing this stale PR because it has been open for 100 days with no activity. This isn't a judgement on the merit of the PR in any way. It's just a way of keeping the PR queue manageable. |
Description of PR
As we all known,
StaticRouterRpcFairnessPolicyControlleris very helpfully for RBF to minimize impact of clients connecting to healthy vs unhealthy nameNodes.But in prod environment, the traffic of clients accessing each NS and the pressure of downstream namenodes are dynamically changed. So if we only have one static permit conf, RBF cannot able to adapt to the changes in traffic to achieve optimal results.
So here I propose an elastic RouterRpcFairnessPolicyController to help RBF adapt to traffic changes to achieve an optimal result.
The overall idea is:
StaticRouterRpcFairnessPolicyControllerSuppose we have 200 handlers and 5 name services, and each name services configured different exclusive Permits, like:
The
sum(NsExclusivePermit)is 100, and theSharedPermits = TotalPermits(200) - Sum(NsExclusivePermit)(100) = 100Suppose we configure that each nameservice can preempt up to 20% of TotalPermits, marked as
elasticPercent.Then from the point view of a single NS, the permits it may be can use are as follow:
If we configure the
elasticPercent=100, it means one nameservices can use up all SharedPermits.If we configure the
elasticPercent=0, it means nameservice can only use it's exclusive Permits.If we configure the
elasticPercent=20, it means that the RBF can tolerate 5 unhealthy name services at the same time.In our prod environment, we configured as follow, and it works well:
elasticPercentis 30%Of course, we need to configure reasonable parameters according to the prod traffic.