Out of the documentation:
ServerIron(config)# server real r1 1.1.1.1
ServerIron(config-real-server-r1) port 80
ServerIron(config-real-server-r1) port ftp
ServerIron(config-real-server-r1) port dns
ServerIron(config-rsr1) hc-track-group 80 21 53
The ServerIron now tracks health status for ports 80, 21, and 53. If any of these ports is down then the combined
health would be marked as failed and the ServerIron will not use these ports for load balancing traffic.
You would have to combine port 80 and port 443 in a health check track group.
Is not that what you are looking for?
R, Oliver
At 10:15 15.07.2009, Manu Chao wrote:
i am sure a vendor like f5 will help you to overcome your applications limitations
On Tue, Jul 14, 2009 at 4:26 PM, David Miller <[email protected]> wrote:
- Hi All;
- I've got a situation that I'm not sure of the best way to handle.
- I have a pair of servers that are able to run the same application. Caching issues make it weird though. The application writes to the database when updates come in, and (of course) updates its own internal cache. The servers don't update each other, however, nor do they get updates from the database any time other than at startup. "startup" in this case is defined as the first query that hits tomcat.
- What this means is that I want to run off S1 as long as its running. And if S1 becomes unavailable I want to run off S2 until I come back and fix things. lb-pri-servers takes care of that part.
- Here's the complicated part. The servers accept SSL as well for user authentication. I need http and ssl to fail to S2 as a pair - both or neither. We recently had application response issues where S1 was very slow to respond, and http failed over but ssl did not. This broke the customers ability to authenticate. We're terminating ssl on the ServerIron 4G's and talking plaintext on port 443 to the server. Apache is listening on 80 and 443 expecting plaintext.
- We've played with boolean health checks, but I haven't implemented them. I'm concerned about separate health checks because nothing different is being tested. It seems like a race condition would still exist where http would fail over, but a second later the ssl check would pass. What we need is for a single failed health check to down the server and fail all services over to the backup.
- If it makes things easier, we can just skip the ssl test. A single test for http is adequate for making sure apache is responding on the server.
- Suggestions very welcome.
- --- David
- _______________________________________________
- foundry-nsp mailing list
- [email protected]
- http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
