Just need some ideas:
We have Conductor Cluster, some MCU's behind and TMS. Booking is running over TMS / Conductor. All have latest SW-Versions.
TMS can only handle one Conductor from the Cluster. Ok, fine.
But what will happend if this conductor is going down with the scheduled conferences ? Is there a way to send the booking asap to the Conductor Cluster an store them there ? Any solutions or workarounds ?
Many thanks !
Sent from Cisco Technical Support iPad App
Welcome to Cisco Support Community!
As you stated correctly, when you have a cluster of conductor, TMS is not able to recognize all the members of the cluster, so only one Conductor (normally the main one) will be managed and scheduled by TMS. If that main Conductor goes down, when a scheduled conference reaches the time to start, TMS won't be able to push the conference to Conductor, so that the conference will fail.
Unfortunately, at this moment, you don't have any automatic method to push the conference to another Conductor peer in the cluster, however, as workaround, you can manually push the conference to another Conductor peer by following this method:
- Raise your Conductor cluster normally according to Cisco documentation
- Add only the main Conductor peer to TMS
- Configure TMS to track the system by using IP address instead of MAC address. You can find that configuration into "System > Navigator", in the "connection" tab.
- Configure your TMS or any monitoring server to advise you (either via email or by using any method else) when the Conductor goes down
- When you are told that Conductor is down, go to TMS in "System > Navigator", select Conductor, go to "Connection" tab and change the IP address of your the Conductor, put the IP address of another Conductor peer in the cluster. So TMS will push the next schedule conferences to this Conductor peer
- When the main Conductor comes up back, go to TMS and set the IP address of the main Conductor back. So the next scheduled conferences will be pushed to the main Conductor.
It is important to point that, obviously, if a scheduled conference starts right in the time when the Conductor is down, before you change the IP address in TMS, then that conference will fail. You will probably have to manually reschedule the conference.
Although this good method is working fine for our customer, it is important to advise you that it is not an official Cisco workaround (as far as I know). So I personally suggest you to test and homologate it by yourself before appling it to your environment. I personally don't like to suggest not official Cisco recomendations, but I think that is something worth to investigate.
Sorry for delay in answering your question. =)
I hope this help.
Please rate useful replies and remember to mark any solved questions as "answered".