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
Load balancer: Pluggable subsetting for load balancers #17013
Comments
I agree that having some type of pluggable subsetting capability would be nice. Design proposals appreciated. |
@mattklein123 i will try to write up a basic design by next week so that we can iterate over the details. |
High Level Design For Generic SubsettingStructuralInheritance
Other Data StructuresRingInfo (Details TBD)Contains information about metadata to calculate the position of the Envoy instance in the hash ring:
FlowInitialization
Refresh/UpdatesMetadataBasedSubsetLoadBalancer: No changes from existing update logic for "SubsetLoadBalancer" DeterministicApertureSubsetLoadBalancer:
|
@mattklein123 @alyssawilk Added a basic design and flow design. Need to iterate on the details. |
Having both pluggable sub-setting and upstream aperture based SGTM. The only thing I'm not sold on is MetaDataBased for the legacy subset naming. cc @zuercher who I think implemented the subset LB and may have thoughts both on structure and naming. |
The name seems a bit cumbersome, but it's accurate. I think you could drop "Based" and it'd be fine. It's not immediately obvious to me that those two load balancing implementations have a lot in common, but it's worth exploring. |
@zuercher @alyssawilk @mattklein123 . I have finally got some time block to focus on this. After some thought into this, I feel that we could be better off by keeping the existing subsetting mechanism and add a new Initially I was thinking we could keep subsetting separate from load balancer so that algorithms like If you agree, I can proceed with adding the new |
@zuercher thoughts on this? I'm fairly out of date with subsetting code |
I'm fine with that. The subsets in the existing Envoy load balancer don't have the same semantic meaning as the subsets in the deterministic aperture load balancer described in the blog post. The former is a way to divide the members of a service into sets of addressable upstream servers based on the properties of the upstream servers. The d-aperture load balancer is a way to reduce the total number of connections used by N clients (envoy servers in our case) communicating with M upstream servers, while distributing requests evenly across the upstreams and without requiring coordination across clients (envoys). |
Thanks @zuercher . @alyssawilk @mattklein123 @zuercher Regarding the specifics of the implementation itself, here is my hight level thought ideas:
Will fill in more details as I start the initial draft of the implementation. Does the above plan sound ok? |
That sounds right. |
Thanks @zuercher |
Based on the discussions in issue:envoyproxy#17013, this change introduces implementation of deterministic aperture load balancing algorithm. The implementation matches the original finagle implementation (`https://github.com/twitter/finagle/tree/develop/finagle-core/src/main/scala/com/twitter/finagle/loadbalancer`). Signed-off-by: Jojy George Varghese <jojy_varghese@apple.com>
Title: Load balancer: Pluggable subsetting for load balancers
Description:
We would like to have a pluggable component for feeding the subset of endpoints that feeds into the load balancer system such that it allows different subsetting schemes like deterministic subsetting. This will keep the load balancing scheme decoupled from the subsetting scheme. Without a pluggable subsetting scheme, looks like we currently only have a cluster priority based subset.
[Relevant Links:]
https://blog.twitter.com/engineering/en_us/topics/infrastructure/2019/daperture-load-balancer
The text was updated successfully, but these errors were encountered: