Forum Discussion
daboochmeister
Cirrus
CirrusIs "Action on Service Down - Reselect" ever safe for HTTP virtual servers? E.g., stateless transactions
I've been living the dream, learning about "Reselect Tries" and "Action on Service Down" ...
We have web service interfaces that are stateless, from an HTTP perspective - no session is created on the web server side, etc. The goal is to have such calls never fail, as long as one web server (pool member) is up. Setting "Reselect Tries" > 0 accomplishes that for new connections - just looking to do the same for existing connections.
Have been looking at "Action on Service Down" - but one thing I can't find clarified is, is a setting of "Reselect" ever safe for a Layer 7 HTTP virtual server? For example, if you know for a fact that your web servers are stateless (no user session involved on the server side, or all user state is written back to the client as cookies), then can reselect be safely used?
I'm concerned about a race condition related to HTTP transactions that span multiple packets ... perhaps it's only safe if you know that all transactions will fit in a single packet?
If it is safe under those constrained circumstances, is there any configuration guidance to be aware of? E.g., is it necessary to avoid use of a OneConnect or something?
If it's not safe, can you explain why, where it breaks things? And, is there any approach that will accomplish what I've described? (maybe, some way to config so that every single transaction is treated like a completely new connection?)
thx! We're on 11.5.2, if it's relevant.
Sorry about that.
Read https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-5-1/5.html?sr=45769495 to understand the circumstances where Action on Service Down should be used.
I think you're not using it appropriately if you're using a HTTP virtual working at layer 7.
Well, The concept of "packet" ceases to exist at Layer-7. When you have a HTTP profile, then you're dealing with Requests and Responses, and all the details of packets are dealt with for you with the HTTP Profile. It gives you a persistent Request/Response interface as you would expect when working at Layer 7.
Therefore, I'm not quite sure where you got the idea of a race-condition. The concept doesn't apply in this context.
So, With HTTP Profile on a VIP, a Transaction is a HTTP Request.
When the system receives the first Request, it will call "LB_SELECT", whose job is to select a pool member to forward this request to. When you set Reselect Retries > 0, you are influencing how many times the system will attempt to choose a new pool member if the initial connection fails. The job of LB_SELECT is to choose a pool member, whether this pool member is chosen by extraction from Persistence information, or by applying the LB-Algorithm to the pool members is just an implementation detail (I'm abstracting here).
From an abstract point of view then, when you apply a one-connect profile, what you are essentially doing is: * Causing LB_SELECT to be called for every transaction (which for HTTP means every request) * Reuse existing connections to the selected pool member rather than create new ones.
The key thing is the fact that LB_SELECT is now called on every transaction.
I think that using this knowledge and the Reselect Retries > 0 should achieve the effect you are aiming for.
You will of course, have to test this out in a lab and confirm that it actually gives you what you desire.
daboochmeisterThank you, aFanen01 - but you focused on "Reselect Retries", when I was asking about "Action on Service Down - Reselect". We already use "Reselect Retries" for HTTP, and no issues, because it only deals with new connections. But for *existing* connections, can "Action on Service Down - Reselect" be safely used, under certain constraints? And what are those constraints? The description of the feature makes it sound only safe for UDP, or TCP where no SNAT/PATing is occurring ... but I'm wondering if, when calling stateless HTTP services, enough of those constraints apply.