We are running UCCX8.5 in our dev lab (NFR kit) in HA (LAN) setup, when I reboot both servers node 1 is master
(check by http://node1server/uccx/isDBMaster)
but after a while (hour or so) suddenly node 2 is master.
When I run CAD, I can login, go ready/not ready, IPPA says service is not active, I guess the ip-address should be changed of the url?
Anyway, why would node 2 be master, I expect node 1 to always be master unless it becomes unavailable
Can I force node 1 to be master?
I am not sure which log to check for issues, if there are any
CAD automatically gets connect with the Active engine master ( Node1 or Node2)
But for IPPA you need to manually select the active IPPA service URL and login again to handle calls.
And why your Node1 is failing to reatin the mastership you need to check the MCVD and MIVR logs and check the exact reason for failure .
Please refer the below links for the same.
Hope it helps.
Please rate helpful posts by clicking on the stars below the right answers !!
I have not been able to find any reason for failure yet, even with node2 as Master, it does not update it's RealTime tables for the Wallboard (which is what we are developing..).
I think the HA was fine until I loaded the license..
I hope to crawl through the logs soon
I hope you are well...
UCCX failover isn't like CUCM - the 'longest running correctly' server is the Master for call processing services (i.e. CAD, CCX Engine) and will only fail to the other node when it breaks or is restarted.
It never fails back on it's own, as this would involve dropping queued calls, failing agents over etc. As you've noted, using IPPA isn't very seamless as you have to have two IP Phone services defined one for each server, and you have to choose the right one (it won't refer you automatically).
Now... the exception to this rule is the database - all DB writes are done to the publisher if it is 'UP', as the Publisher always becomes 'Master' for the UCCX DB.
The exception to that rule is realtime tables - they only update on whichever server is currerntly the Master for the UCCX Engine.
Now... the final exception is that the 8.x releases have a few really nice bugs. If you look at the UCCX services in the web interface (serviceability) you often see that the DB is not in running state on the Publisher. It can't be started or fixed without restarting the Node Manager from CLI (or the whole server which is easier). If you look at the 'utils service list' command it is usually running (A Cisco DB) but UCCX has lost sight of it. It's fixed in the lastest SRs I believe.
Yes, hope you are well too, thanks for asking
I even rebuild both servers bot node 2 keeps becoming the master, but my uccxwallboard user ip-address is not allowed after a while, as if the DB sync breaks after a while (a day or so)
As development partners we don't have access to SR's, which is very unfortunate, we can only buy NFR :-(
Good to hear... running any 8.x UCCX release without a recent SU would be a worrying scenario for anyone..
I wonder if we run into bug;
CSCto90417 3 GC pauses cause CVD heartbeats failure and thereby failover
(I see all missed heartbeats on node2,
28979: May 29 19:17:04.201 NZST %MCVD-CVD-5-HEARTBEAT_MISSING_HEARTBEAT:CVD does not receive heartbeat from node for a long period: nodeId=1,dt=2617
28980: May 29 19:17:04.201 NZST %MCVD-CVD-4-HEARTBEAT_SUSPECT_NODE_CRASH:CVD suspects node crash: state=Heartbeat State,nodeInfo=Node id=1 ip=a.b.c.d convId=11 cmd=34 viewLen=1,dt=524)
we are development partner and don't have access to downloads, so can't apply any SR's
I rebuild node 2, once it was up and running I lost realtime stats updating..
node2 just rebooted
29750: May 29 19:18:05.412 NZST %MCVD-CVD-7-UNK:Heartbeat State activated, retransmitInterval=500, silenceInterval=2550
29751: May 29 19:18:05.569 NZST %MCVD-PROMPT_MGR-6-NO_SYSTEM_TTS_PROVIDER:No system TTS provider registered
29752: May 29 19:18:06.571 NZST %MCVD-CVD-5-HEARTBEAT_MISSING_HEARTBEAT:CVD does not receive heartbeat from node for a long period: nodeId=1,dt=1045
29753: May 29 19:18:06.587 NZST %MCVD-CVD-3-CVD_REGISTER_SUBSCRIBER_ERROR:CVD can not register subscriber on the remote node: nodeId=1,Exception=null
29754: May 29 19:18:06.588 NZST %MCVD-CVD-7-UNK:Dispatcher:: readMcvdProperty() property file = application.MCVD.properties Property value=2
29755: May 29 19:18:06.588 NZST %MCVD-CVD-7-UNK:Dispatcher:: processHeartbeatNodeJoinCmd() Restarting system
29756: May 29 19:18:06.588 NZST %MCVD-CVD-7-UNK:Dispatcher:: updateMcvdProperty() property file= application.MCVD.properties Property value=3
29757: May 29 19:18:06.588 NZST %MCVD-CVD-3-REBOOT_ON_CVD_REGISTER_SUBSCRIBER_ERROR:CVD can not register subscriber on the remote node due to connection issue. System is being rebooted once to recover from the issue.: Exception=java.rmi.ConnectException: Connection refused to host: a.b.c.d; nested exception is:
java.net.ConnectException: Connection refused
I hit CSCto90417 on early versions of 8.0.2 - according to the bug toolkit it is fixed in the following versions:
Do you have the hostnames / ip's setup correctly on your UCCX publisher and subscriber. Can you ping the hostname and ip address of the opposite server from the command line?
utils network ping 10.10.10.10
utils network ping hostname
Both comands are fine from both servers, I am wondering if the installation scripts open the iptables correctly.
We are running the NFR version:
but without access to SR's I can't know for sure..