10.176.56.113 and 10.176.56.114 are 2 x DNS servers in Site 1.
We are planning to put in 10.188.56.49 and 10.188.56.50 which are Site 2 DNS servers as standby realserver because there was a time when 2 of the Site 1 DNS servers went dead and there was no DNS server running in Site 1.
We do not want the DNS vip to route to Site 2 DNS unless both of the .113 and .114 are dead. Can you advice if 'inservice standby' can be used?
"If a client making a request is stuck to an out-of-service server (using a cookie, SSL ID, source IP, etc), this connection is balanced to an in-service server in the farm. If you want to be stuck to an out-of-service server, enter the inservice standby command. When you enter the inservice standby command, no connections are sent to the standby real server with the exception of those connections that are stuck to that server and those servers with existing connections. After the specified standby time, you can use the no inservice command to allow only existing sessions to be sent to that real server. Sticky connections are then sent to an in-service real server in the server farm. "
The explanation above is rather vague and confusing. Hence I would like to seek your advice whether the usage of 'inservice standby' can serve the purpose that we required, which is to failover to .49 and .50 when .113 and .114 became "out of service" in the CSM.
"no inservice" and "inservice standby" are used to gracefully shutdown the real servers. "Inservice standby" is used for shutting down (taking out of LB logic) a real server when stickiness is configured.
You can use Backup server farm for your requirement. A sample config
virtual z.z.z.z tcp
serverfarm SITE1 backup SITE2
If all the servers in SITE1 goes down then the real of SITE2 will be used. If a single server of SITE1 comes back then all connections will go to that server in SITE1.
This document covers the important troubleshooting data to be collected and data collection procedures when you experience an issue with ACI fabric. The collection of the relevant troubleshooting data is very critical to root cause the issue and...
There are certain situations in where an On-Demand Techsupport is not able to be performed. In such cases, a local techsupport can be collected instead for either the APIC or an ACI switch. This document outlines this...
Webcast: Evolution of Data Center: From Classic Ethernet to VXLAN
(Live Webcast Tuesday May 15, 2018 at 10 am Pacific/ 1 pm Eastern / 7 pm Paris)
Register today for this live Cisco Support Community webcast.