RFC: Hash-based routing #1222
RFC: Hash-based routing #1222
Conversation
beyhan
requested review from
a team,
rkoster,
beyhan,
stephanme,
ameowlia and
ChrisMcGowan
and removed request for
a team
|
Hi @beyhan, thanks for picking this up. We are still doing a team-internal review first and keeping this PR in "Draft" state. We will ping again once it's ready for the big stage. |
| tenant-specific databases. With the current load balancing algorithms, each tenant eventually creates a connection to each | ||
| application instance, which then creates connection pools to every customer database. As a result, all tenants might span | ||
| up a full mesh, leading to too many open connections to the customer databases, impacting performance. This limitation | ||
| represents a gap in achieving optimal load distribution and can be solved with routing based on a tenant. |
There was a problem hiding this comment.
"enhance load distribution" and "achieving optimal load distribution" depend very much on what you consider the optimal distribution. Ordinarily I would say the most (load) balanced situation is when each instance is experiencing exactly the same load but with hash-based we deliberately sacrifice this goal because we know that there is a more efficient way which might not be as fair as rr or lc but optimizes the overall resource consumption of the system (which you do mention later on in line 42f.
See also:
- line 14
- line 34
|
|
||
| [Maglev hashing](https://storage.googleapis.com/gweb-research2023-media/pubtools/2904.pdf) can be considered as a possible solution. | ||
|
|
||
| N hashes can be associated with one application instance. The number of hashes is a multiple of the number of application instances. |
There was a problem hiding this comment.
This sentence seems a bit disconnected. Either you spend a paragraph summarizing Maglev hashing or you don't and people have to read the paper. But just having this once sentence is probably confusing if you are not already into the details.
| The options are raw JSON and will be passed directly to the Gorouter without any modifications. | ||
|
|
||
| #### Route-Registrar | ||
| No use cases are known to implement hash-based routing for the platform-related routes. |
There was a problem hiding this comment.
This seems unfair, couldn't we just include it for completeness?
There was a problem hiding this comment.
You are right that it is unfair, but I would rather avoid implementing a feature that won't be used.
However, we are open to hearing about any use cases where it might be beneficial.
There was a problem hiding this comment.
Maybe a rewording helps? I agree on not including it in the "MVP" that is implemented via this RFC. Would be open to re-discuss if the panel/reviwers come up with use-cases
| No use cases are known to implement hash-based routing for the platform-related routes. | |
| In the scope of this RFC, it is not planned to implement hash-based routing in route-registrar for platform-routes. |
Co-authored-by: Maximilian Moehl <[email protected]>
Cloud Foundry uses round-robin and least-connection algorithms for load balancing between Gorouters and backends. Still, they are unsuitable for specific use cases, prompting a proposal to introduce hash-based routing on a per-route basis.