Hello HAProxy community!
In a few words,
can I leverage cookie/ip “session persistence” (linked above) to route “new” requests to a server in drain state?
In more words,
Consider I have two backend servers (
backend_b) load balanced by an HAProxy instance. Now let my client perform the following three requests:
- Initial sign in/authentication (in the background, we were load-balanced onto
- Load resource (
table_t) onto the current server servicing us (in this case
backend_a). This resource comes from another downstream component irrelevant to this question.
- Stream the contents of
table_tfrom the same server we loaded the table onto (
backend_a) to somewhere on our client.
For obvious reasons, these three requests need to occur in order on the same backend server (
backend_a). For simplicity’s sake, let me say that we load balance based on a hash of the username. Our backend config then looks like
backend server balance hdr(username-hash) hash-type consistent ... option redispatch
If I decide to drain
backend_a using the runtime API after request 2 is sent AND BEFORE REQUEST 3 IS SENT, is there any way to get request 3 onto
backend_a? From what I have found (Management | Enable/Disable Servers | HAProxy Enterprise 2.5r1), the drain state will
set server state to DRAIN (remove from load-balancing, but remain available for health checks and persistent connections)
But, I’m not sure if cookie/IP persistence constitutes a “persistent connection”.
- This forum post supports my hope that the “persistent connections” include the stick-table and not just the literal TCP connections - sticky-sessions-and-drain-not-working-together
- I may need to remove
option redispatch- Sticky Session/ Session Persistence
redispatch, we will stay bound to a server even if the server breaks - option redispatch
TL;DR will cookie or ip based “persistence” allow new requests (without an existing TCP connection) to connect to a server in the drain state while using