[go: up one dir, main page]

Skip to content
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

[Feature Request] Balancing with custom hash #134

Open
lippertmarkus opened this issue Apr 9, 2018 · 2 comments
Open

[Feature Request] Balancing with custom hash #134

lippertmarkus opened this issue Apr 9, 2018 · 2 comments

Comments

@lippertmarkus
Copy link
lippertmarkus commented Apr 9, 2018

I need to load-balance an application which uses a proprietary TCP protocol. As our customers often use application virtualization (like e.g. Citrix XenApp) to connect to our application, the source IP of all clients in such environments is the same, only the source port differs.

Therefore I would need a load balancing strategy based on a hash of the source IP and the source port (or an even more generic soluation like nginx has: http://nginx.org/en/docs/http/ngx_http_upstream_module.html#hash)

Would this be possible to implement?

@yyyar yyyar added the feature label Apr 12, 2018
@yyyar
Copy link
Owner
yyyar commented Apr 12, 2018

Hi @lippertmarkus
Thanks for a feature request. It's makes sense and can be implemented for sure.

I just want to think about it properly to find a most flexible solution.
Implementing another strategy with just ip+port seems like hardcode.
Seems adding "variables" like in nginx to build own hash key would be best option.
The problem is that we have only one string field for a value of balance strategy parameter and I want to keep it backward-compatible.

Maybe something like:

balance = "hash [$client_ip $client_port]"

Or we can transform balance field to a object:

[servers.default.balance]
kind = "hash"
hash_key = "$client_ip $client_port]"

But it breaks backward compatibility unless we do some haks.

@illarion @nickdoikov what do you think?

@nickdoikov
Copy link
Collaborator

@yyyar
request looks reasonable, we can hash only a source ip + source port on L4 level, hope this will enough for appropriate routing to appropriate backend.

@lippertmarkus
In case you are using your protocol secured with TLS(based on client's certs) you can use sni based hostname matching strategies
SNI

example :

[servers.somebackend]
bind = "10.0.0.1:7777"
client_idle_timeout = "0"
backend_idle_timeout = "0"
balance="leastconn"

 [servers.somebackend.sni]
 read_timeout = "2s"
 hostname_matching_strategy = "regexp"
 unexpected_hostname_strategy = "default"

  [servers.somebackend.discovery]
  kind = "static"
  static_list = [
      "10.0.3.83:7000 weight=1",
      "10.0.3.12:7000 weight=1 sni=^first\\.domain\\.com$",
      "10.0.3.13:7000 weight=1 sni=^first\\.domain\\.com$",
      "10.0.3.22:7000 weight=1 sni=^(second|second-subuser1|second-subuser2)\\.domain\\.com$",
      "10.0.3.42:7000 weight=1 sni=^third\\.domain\\.com$",
      "10.0.3.43:7000 weight=1 sni=^third\\.domain\\.com$"

  ]

 [servers.somebackend.healthcheck]  
  interval = "10s"                 
  timeout = "2s"                  
  fails = 5                      
  passes = 2                     
  kind = "ping"

@nickdoikov nickdoikov modified the milestones: 0.7.0, 0.6.0 Jun 25, 2018
@illarion illarion modified the milestones: 0.6.0, 0.7.0 Jul 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants