Cisco Finesse failover behavior

[J_Vansen_S]

hi all,

Id like to verify if Finesse CCX failover behavior is correct, and working as it should be as designed.

UCCX version 11

I have my 2box of uccx clustered for HA failover.

uccx01.test.com (Primary node)

uccx02.test.com (Secondary node)

All our agents have bookmarked Cisco Finesse on their browser as https://uccx01.test.com:8445

Scenario 1: Did a fail over test by shutting down uccx01.

1. Logged in agents automatically failover to uccx02 (no issue on this)
2. However when other agents came into duty shift, they clicked their Cisco Finesse bookmark https://uccx01.test.com:8445, it timed out. Obviously as uccx01 is being shutdown

Isn't there some sort of redirection that detects uccx01 is down and redirects to uccx02?

So what does this leaves the agent? Do they need to maintain 2 different bookmark url? uccx01.test.com:8445, and uccx02.test.com:8445

And that they need to manually access to uccx02 url when they experience that uccx01 url is in accessible?

Scenario 2: uccx01 powered back on & recovers.

1. uccx01 does not regain as a master.( is that correct?)
2. When agents click on their Finesse bookmark https://uccx01.test.com:8445, it NOW redirects to https://uccx02.test.com:8445

Ultimately my concern is pretty much on scenario 1 failover behavior. Scenario 2 should be fine as it redirects

Appreciate any advise

[Chris Deren]

You can read this doc on expected failover behavior of finesse:

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_10_0/design/guide/UCCX_BK_DF6A995E_00_design-guide/UCCX_BK_DF6A995E_00_design-guide_appendix_0110.html

[Anthony Holloway · Accepted solution]

UPDATE on 2020-06-02

I see someone just gave me helpful votes on this, but this information is 4 years old and Finesse has changed a bit now.  Today, Finesse can run active/active on each server, whereas the Engine is still active/standby.  The load balancer still applies though, however, you cannot use Finesse API call to determine which server Finesse is active on, since it's active/active.  You could however, if you even cared, use the wallboard /uccx/isDBMaster URL to determine which server the Engine is master on.  Otherwise, just 50/50 balance it, or geo route it, etc.

The documentation Chris linked leaves a lot to be desired in terms of setting expectations, and therefore we all end up finding out the hard way that HA really isn't all that great.  It should be marketed as the license is named: WARM STANDBY.

Scenario 1: You found out the hard way, that his is how it works.  If the server is down (or even just Tomcat), your link will be broken, and you will not be redirected.  You will either need to publish both URLs to the Agents (like most people do to solve this), or come up with a fancy front end load balancer, and just use https://finesse.test.com as your single URL.  By the way, if you figure this out, please post about it, as there's not much info out there on this setup.

Scenario 2: Correct, a server failback will not happen automatically.  You must initiate the failback on your own by restarting the CCX engine on the Master.  Do be aware that this is impactful and you will drop all calls on your CTI Ports and log out all Agents.

[J_Vansen_S]

Thanks to all for the verification.

We'll just stick to maintaining 2 url for Finesse then, load balancing is too much hassle.

[Jonathan Schulenberg]

You can use a load balancer but only if it steps out of the traffic path after making the LB decision. For example, on F5 LTM you need to use an iRule to do this. Here's the logical flow that doesn't break TAC support:

1. User types http://finesse.cisco.com into their browser or uses a bookmark that points to this URL.
2. DNS resolves finesse.cisco.com to the load balancer which should listen on TCP 80 and 443 for HTTP and HTTPS, possibly after an F5 GTM query if using multiple data centers with separate LTM clusters. Using anycast IP addresses is a another way to get this to work from multiple data centers if layer two is not extended between them but ensure that LTM is part of the IGP and doesn't use static routes.
3. The load balancer monitors CCX1 and CCX2 for availability as well as querying the http:///FQDN/isDBMaster API (see the DocWiki for more details). The source IP address of the load balancer must be whitelisted under /appadmin > Tools > Real Time Reporting Configuration to have access to this API.
4. The load balancer issues an HTTP 307 response redirecting the client to https://ccx1.cisco.com:8445/desktop or https://ccx2.cisco.com:8445/desktop based on which server is reachable and has mastership. If using F5, this is where you need to use an iRule so that LTM issues the user's browser an HTTP redirect instead of proxying the traffic.
5. The user's browser makes a new GET request to the actual CCX server and out-of-the-box Finesse failover logic takes over from here.
• Critically, the load balancer cannot be in the traffic path once the browser gets to ccx1.cisco.com or ccx2.cisco.com. If it is then I would expect to see CCX installation or upgrades fail because the DNS A and PTR records wouldn’t resolve correctly to the actual nodes. Additionally, Finesse wouldn’t be able to do the Javascript-based failover to the standby node nor would the OpenSocial widgets work correctly since the certificates would be all messed up (e.g. hostname wouldn’t match the CN/SAN).

[Roman Rodichev]

Hi Jonathan,

do you believe that http://FQDN/isDBMaster API monitoring in #3 is necessary? If primary server becomes standby but still servicing finesse page, then I guess it's ok if LTM still brings users to the primary server's page, and lets Finesse do its built-in redirect to the 2nd active server. I think we are only interested in the situation when primary server is completely down and/or port 8445 is not available. For this, we'd only need to monitor the state of TCP 8445 on the primary server. 

I'm trying to avoid setting up http://FQDN/isDBMaster API check on a Netscaler.

What are your thoughts on this?

Regards,

[Anthony Holloway]

You could use this URL on either or both servers to determine which one is Finesse active on:
https://<uccx server>:8445/finesse/api/SystemInfo
You'll be looking for the following line in the XML:
<status>IN_SERVICE</status>
Versus, this, which is what the other one would respond with:
<status>OUT_OF_SERVICE</status>

[Deepak Rawat]

Anthony is absolutely correct in what he informed. Refer Load Balancing for Finesse section of below document in order to know more about the load balancer thing that Anthony suggested

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_11_0/design/guide/UCCX_BK_U3AF2742_00_unified-ccx-design-guide-11/UCCX_BK_U3AF2742_00_unified-ccx-design-guide-11_chapter_0110.html#CFIN_RF_L7808776_00

Regards

Deepak