Forum Discussion
mcris2812
Altostratus
AltostratusSession persistence based on http header for machine to machine calls
Hi, Can you please help me understand what would be required(or if it is even possible) to support the following scenario: BackendApplication(not a browser) ->API Gateway -> LB -> App Node 1, App N...
Awesome!
Thank-you very much for your help!
Kai_Wilke
MVP
MVPHi Mcris,
tweaking your session persistence accordingly depends of a couple factors.
1.) Are HTTP keep-alive sessions in use where a singe client-side TCP session needs to be forwarded to App1, App2 or App3 on a per request-basis?
2.) Does every single request contains the HTTP header? What should happen if the HTTP header is missing?
3.) How should a request become load balanced if the HTTP header routing was never used before?
4.) What should happen if the HTTP header was not seen for X minutes/hours/years? Should it still persist?
5.) Do you have any special requirement in the case of Failovers and Failbacks?
6.) Could you provide a sample of those message identifier headers?
Cheers, Kai
mcris2812Altostratus
AltostratusHi Kai_Wilke,
Answers below in green:
1.) Are HTTP keep-alive sessions in use where a singe client-side TCP session needs to be forwarded to App1, App2 or App3 on a per request-basis?
No, we don't use keep alive sessions.
2.) Does every single request contains the HTTP header? What should happen if the HTTP header is missing?
Yes, It will actually be set by the API GW before forwarding the request to the LB
3.) How should a request become load balanced if the HTTP header routing was never used before?
I guess the LB should just send the request to any one of the nodes in the pool(use the default round robin strategy).
4.) What should happen if the HTTP header was not seen for X minutes/hours/years? Should it still persist?
Same as for 3.
5.) Do you have any special requirement in the case of Failovers and Failbacks?
I guess in this case the session will be lost and a new one should the created with another available node from the pool.
6.) Could you provide a sample of those message identifier headers?
We can be quite flexible here. The API GW can even create a cookie header like Cookie: MsgId={id}.
Thank-you!
- Kai_Wilke
Hi Mcris,
based on your answers i would like to recommend CARP.
CARP based distribution is a load balancing method which distributes load based on a given "INPUT" value that a transaction carries with. If all you requests are getting tagged by the API GW, then you could use the tag as input for load-balaing decission.
when HTTP_REQUEST { if { [HTTP::header value "API-GW-Tag"] ne "" } then { persist carp [HTTP::header value "API-GW-Tag"] } elseif { [HTTP::cookie value "API-GW-Tag"] ne "" } then { persist carp [HTTP::cookie value "API-GW-Tag"] } else { persist none } }Benefits of this method is simplificy, a good balacing of independent Tags (the more unique tags the better the balacing will be) and a guaranteed binding of a given Tag value to one Pool member. Using CARP your F5 dont need to track anything in Memory which may time out...
You may additionally enable OneConnect in combination with CARP. It will slightly boost the performance of your non Keep-Alive sessions (backend connection to the API will be pooled) and also allowes CARP to work in combination with Keep-Alive sessions (true per request balancing).
Cheers, Kai
- mcris2812
Awesome!
Thank-you very much for your help!