HAProxy Session Persistence v.s. Drain State

Hello HAProxy community!

I am seeking clarification on documentation concerning session persistence and the drain state.

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_a and backend_b) load balanced by an HAProxy instance. Now let my client perform the following three requests:

1. Initial sign in/authentication (in the background, we were load-balanced onto backend_a)
2. 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.
3. Stream the contents of table_t from 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
• Without 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 option redispatch?

1 post - 1 participant

Read full topic