Load balancing issue with local server things
Hi, so basically, I want to use cfs load balancing to obviously balance the servers out.
But some actions require the user to get redirected to the same server to work properly.
Example:
>> User requests to start socket connection to external api, gets redirected to Server1
>> User wants to send something to the socket, but gets sent to Server2 due to load balancing
>> Socket isnt active on Server2, user cant interact with the initial socket
Is there a clean way to resolve this issue?
6 Replies
CF LB has a whole set of features for that: https://developers.cloudflare.com/load-balancing/understand-basics/session-affinity/
Cloudflare Docs
Session affinity · Cloudflare Load Balancing docs
When you enable session affinity, your load balancer directs all requests from a particular end user to a specific origin server. This continuity …
Thanks, i would use ip_cookie, but what if the user is using a vpn/proxy on their phone, and not on their pc? do i need to use the header method in that case?
ip_cookie is still just a cookie (so as long as they have that cookie, they're going to the same origin) but the selection is also stable based on the same IP
if they were on a vpn/proxy, it'd just be based off the vpn/proxy's IP, same for mobile devices. And if their phone switches IPs or vpns/proxies, they still have that cookie to guide them
In order to hit a different origin, they'd have to lose that cookie and change IP
whereas with just the cookie, their ip doesn't matter and they would just go randomly to one origin in the pool if they didn't have the cookie/it got cleared
yes i understand that, my scenario is, for example user logs in on desktop, gets cookie for server1, later uses their phone to log in (different browser) with a different ip (for example proxy/vpn), then they would not always get connected to server1 i am assuming. thats why i considered the header method
Maybe, for the header method you'd have to have some sort of user identifider though and full control over the headers they send in order to ensure that header is always sent. Even the header method has a max expiration of 7 days if the session is idle.
that's a big difference between "a user has a socket open for their current session and we don't want to lose it" to "always direct the same user to the same server regardless of device/context/etc", how sticky do you need it to be? Origins can still fail and force traffic to be redirected
Well it would be pretty bad if the user is redirected to a different server, when he is connected to the socket