I have a scenario where a group of servers need to connect a pair of application servers, but only one app server can be active and have connections at a time. I've setup a serverfarm with a single server as primary, then with a backup server that should go active if the primary server fails. I've tested failover when the primary server fails, and the ACE successfully directs connections to the backup server. My question is about the failover actions once the primary server comes back online. I believe the default behavior is to maintain existing connections to the backup server, but start directing new connections to the restored primary server. I've found that I can prevent the primary server from coming online by setting a long timer for the return to service, but my app developers are asking if the ACE can sever the connections to the backup server once the primary is restored. Can anyone advise if this is possible? So basically I want to kill any connections to the backup server in the event that the primary server becomes active again.
I tried your suggested config, but I noticed a couple of things:
First, configuring the backup-rserver under the ST-UAT-BACK serverfarm results in another rserver being created underneath that serverfarm. I don't know if that defeats the purpose of what you were trying to accomplish with your config.
Second, the policy-map config is making the standby rserver the primary serverfarm, which seems like it's backwards. Testing this config out, I couldn't establish any connection until I reversed the order of the serverfarms in the policy-map.
Also, I've read through the configuration guides and I can't find anything that indicates connections to a serverfarm will ever be forcefully disconnected -- is that true?
You can load balance a client request for content to a server farm by using the serverfarm command in policy map load-balancing class configuration mode. Server farms are groups of networked real servers that contain the same content and that typically reside in the same physical location.
The syntax of this command is as follows:
The keywords, arguments, and options are as follows:
•name1—Unique identifier of the server farm. Enter an unquoted text string with no spaces and a maximum of 64 alphanumeric characters.
•backupname2—(Optional) Designates an existing host (with valid content) or a redirect (sorry) server farm as a backup server farm in case all the real servers in the primary server farm become unavailable. You can configure one backup server farm for each existing primary server farm. When at least one server in the primary server farm becomes available again, the ACE sends all new connections back to the primary server farm. The ACE allows existing connections to the backup server farm to complete. You can fine-tune the conditions under which the primary server farm fails over and returns to service by configuring a partial server farm failover. For details about partial server farm failover, see the "Configuring a Partial Server Farm Failover" section in Chapter 2, Configuring Real Servers and Server Farms. Enter the name of an existing server farm that you want to specify as a backup server farm as an unquoted text string with no spaces and a maximum of 64 alphanumeric characters.
I also tried a sticky group, but that has the same basic functionality in regards to the backup:
When you associate a server farm with a sticky group using the serverfarm command in sticky configuration mode, the primary server farm inherits the stickiness of the sticky group. The ACE sends requests from the same client to the same server in the primary server farm based on the type of stickiness that you configure in the sticky group. If you also configure a backup server farm using the backup option of the same command, you can make the backup server farm sticky, too, by configuring the optional sticky keyword.
If all the servers in the primary server farm go down, the ACE sends all new requests to the backup server farm. When the primary server farm comes back up (at least one server becomes active):
•If the sticky option is enabled, then:
–All new sticky connections that match existing sticky table entries for the real servers in the backup server farm are stuck to the same real servers in the backup server farm.
–All new non-sticky connections and those sticky connections that do not have an entry in the sticky table are load balanced to the real servers in the primary server farm.
•If the sticky option is not enabled, then the ACE load balances all new connections to the real servers in the primary server farm.
•Existing non-sticky connections to the servers in the backup server farm are allowed to complete in the backup server farm.
I was hoping there was a trick to getting it to work, but perhaps not this time.
Introduction This article will help you understand the steps on how to
download the UCS licenses from the Cisco Systems website and then
installing it on the UCS. The redacted (blue lines) just covers up
certain numbers for privacy please do not take them...
Introduction This article will help you understand and educate the
customer on how to clear their "expired licenses"
(license-graceperiod-expired) from their UCS-M. If a customer just
purchased a license and needs a step by step guide on how to download
==================== VIC FNIC driver does not support Virtual Volumes (
second level LUN ID ) An enhancement request has been created to track
this feature - CSCux64473 UPDATE - 12-14-2016 We made some traction on
the enhancement request - The Fix is in t...