i have a customer that wishes to use a CSS11501 with 2 web servers, 1 active and 1 standby.
the primary sorryserver content option seems to achieve this, however the customer wants content requests to go to the sorryserver even after the primary service on the content rule has come back.
Thye wish to control when traffic goes back to the original active server.
When tested traffic goes back automatically to the primary server when it comes up which is not what they want.
Is there any way of achieving this ?
I am not sure there is any way to do what you want, even with the use of custom keepalive scripts. But if the end goal is to ensure the front-end client connection is not re-established once the primary service becomes ALIVE, you can try adding 'no persistent' to the content rule and adding 'persistence reset remap' to the global config. This will cause only the backend connections to be remapped from the sorry server to the restored primary server once it comes back online.
From the manual:
"If you configure the persistence reset remap command in the global configuration and no persistent command on the content rule, when a local service becomes available again, the CSS remaps any new or in-progress persistent connections to the local server from the sorry server. Otherwise, new connections go to the available local services, but in-progress persistent connections stay on the sorry server."
Hope that's what you're looking for.
thanks for the reply.
i saw reference to those persistence commands in another post and i think they would help but not completely solve the issue.
Ie in flight connections would stay on the sorryserver but new ones go the available primary server.
The customer wants everything to stay on the sorryserver whether in flight or new traffic once the primary server goes down so that they can control bringing traffic back to it when it returns.
i am thinking this may not be achievable.
Interestingly there was another post from some time ago that kind of suggested this was how it actually did work anyway.
Yeah, I understand what it is you're trying to do, but unfortunately I don't think there's any way to do it fully on the CSS. The idea is that the sorryserver would store some sort of static content, like a 'server down' or 'ongoing maintenance' page, that clients would be directed to incase the primary service failed. Once the primary service comes alive all *new* connections would be directed to the primary service, while existing connections to the sorry server could A) continue to be mapped to the sorry server until the entry in the persistence table expired or B) be remapped to the now-up primary service.
The only way I can think to implement what you want would require something like this:
- Turn on logging
- Configure an email address on the CSS that logs can be sent to
- Ensure the keepalive method is 'get' for the primary service
When the state transition states place for the primary service (ALIVE to DEAD/DOWN), it is recorded in the traplog. Once this is emailed to the customer, there can be logic on their end that will change the contents of the healthcheck file on the primary server if it sees the primary service on the CSS failed. The primary service will then continue to fail its keepalives due to a hash mismatch and would require the customer to manually change the healthcheck file to bring the server back into rotation.
I know it sounds a little far fetched, but perhaps it can be done. I've seen variants of this method implemented so it might be worth looking at.
cheers - that last idea is certainly worth exploring though i reckon the manual intervention bit
may a bit of a challenge for them.