Does TP Conductor support MCU redundancy?

[Aliaksandr Tratseuski]

Hi,

It's claimed that TP Conductor can support several MCUs for the primary use of call balancing through creating a pool (as I understood). But if there was just a couple of MCUs (no matter: either 2x4505 separate or 2x5310 clustered) with calls on each, is there a way to move calls from the failed MCU (just in case) to the working one?

And one more point of clearing out. As I undarstood from the documentation a cluster of MCU 5300 does not provide redundancy because the one is Master and the second is Slave. Master/Slave failure leads to the cluster failure.

Please correct if I'm wrong.

Thanks

[Justin Ferello]

Alexander,

Your first question is somewhat correct.  The Conductor does not necessarily load balance calls to the MCUs.  It simply sets up conferences on the MCUs you have defined based on the priority you have previously assigned to those MCUs.

In it's basic form, the Conductor allows conference creation and dialing to be much easier for the enduser as they do not need to remember which MCU they have to dial into, or which MCU they have the ability to create conferences on.

For your second question, you are correct.  Clustering in the Cisco MCU world means nothing more than expansion of resources.  When you cluster two MCUs together the Master MCU is just getting permission to use the DSPs from the slave MCUs for video processing.

Again, clustering makes its simple for your endusers, if you have two 8510 blades the endusers do not need to remember which blade to call into, there would only be one to call into.

IMHO I think they should rename the clustering feature to linking or expansion.  Since clustering usually implies load balancing, HA or redundancy.

Thanks,

Justin

[Aliaksandr Tratseuski]

Justin, thanks for the answer.

But it's still not clear for me if there is an ability to failover with Conductor?

E.g. I have a Conductor and 2 MCUs 5320. There are active calls, balanced among both MCUs. If either fails, does the Conductor move calls from it to the working one without call interruption?

[Justin Ferello]

Alexander,

If one of the MCUs fails then the conferences will just abruptly end and not reconnect automatically.

Thanks,

Justin

[Aliaksandr Tratseuski]

Hmm... but then what does the phrase mean: "Taking an MCU or Conductor unit out of service will not impact service availability" ?? (can be found here: http://www.cisco.com/en/US/products/ps11775/index.html). Justin, according to your comment there will be a service interruption, but cisco claims that the service "will be available". That means "availability" is not equal to "non-interruption" ?

Maybe some of cisco folks could make the question clear?

[Justin Ferello]

Alexander,

That statement would be correct.  Assuming you had multiple Conductors & MCUs, if you removed one of each there would be no significant impact to the availability of service.  Obviously you lost an MCU, so there will be the impact of loosing X amount of ports.

Cisco states nothing about service interruption though, so yes my original statement is correct.  Your call would be disconnected but since service is still available, you could just re-dial the same conference name and it will create a new conference on another MCU.

Thanks,

Justin

[Aliaksandr Tratseuski]

Justin,

I've just found out that TMS has a so called "Automatic MCU Failover" option which could be "If conference start or MCU polling fails", The polling interval could also be configured there.

I suppose that if there are several MCUs, managed by TMS, and if either of them fails that the conference are automatically recreated on another MCU (suppose it is same as the failed one) and all participants automatically call into the recreated conference.

It seems like a basic solution for MCU failover with TMS instead of Conductor. Is it right? Will it be able to function like expected?

Regards,

Alexander

[Kjetil Ree · Accepted solution]

Alexander Tratsevsky wrote:
I've just found out that TMS has a so called "Automatic MCU Failover" option which could be "If conference start or MCU polling fails" [...]

Hi,

"If conference start or MCU polling fails" is a very dangerous option, as it can make TMS tear down ongoing calls that actually are connected correctly. This happens if TMS loses connection to the MCU for a minute, but that's doesn't necessarily mean that endpoints cannot connect to the MCU!

We strongly recommend not using "If conference start or MCU polling fails" .

Regards,

Kjetil

[Aliaksandr Tratseuski]

Hi Kjetil,

Glad to see a cisco representative in this thread!

All the answers for my initial question are not good for me. In my opinion, the main reason is the initial question was created with a lack of knowledge. I'll try to rephrase it:

1) Is there any designed/safe way of making MCU redundancy? (if one fails another takes it's place, transparent for the end user, if possible)

2) What cisco devices should I use for completing this task?

As I figured out from the discussion above (thanks Justin), there is no way of avoiding interruption of service. But there might be solutions for just automatic redial. All should be automated as much as possible.

Regards,

Alexander

[Kjetil Ree]

Alexander Tratsevsky wrote:
Hi Kjetil,
Glad to see a cisco representative in this thread! 
All the answers for my initial question are not good for me. In my opinion, the main reason is the initial question was created with a lack of knowledge. I'll try to rephrase it:
1) Is there any designed/safe way of making MCU redundancy? (if one fails another takes it's place, transparent for the end user, if possible)
2) What cisco devices should I use for completing this task?
As I figured out from the discussion above (thanks Justin), there is no way of avoiding interruption of service. But there might be solutions for just automatic redial. All should be automated as much as possible.
Regards,
Alexander

I personally recommend using a TelePresence Conductor to handle MCU redundancy. The Conductor does this way more transparently than what you get if TMS manages the MCUs directly.

As Justin says, there is no way to avoid that the conference goes down if an MCU suddenly dies. However, if this is a call scheduled in TMS, TMS will then make the endpoints dial back to the Conductor. If the Conductor is set up correctly with multiple MCUs, the conference will connect again after a short while. Users should expect no more than 30 seconds of downtime, and usually a lot less.That is IMHO acceptable in case of hardware failure (which should happen very rarely).

/Kjetil

[daleritc]

Absolutely correct Kjetil

And this is specified in our TMS Online Help with regards to the Automatic MCU Failover setting:

• Off: Cisco TMS will not initiate automatic MCU failover.
• If conference start fails: Cisco TMS will automatically try another MCU  if conference setup fails during conference start.
• If conference start or MCU polling fails: Cisco TMS  will automatically try another MCU if conference setup fails during  conference start, or if the MCU is unresponsive during the conference.  For failover threshold, see the field below. We do not recommend using  this setting, as Cisco TMS could disconnect all participants from a  conference if the network connection to the hosting MCU is lost for a  short time, despite the conference having continued with no problem.

[Aliaksandr Tratseuski]

Please, look at the questions above

Thanks

P.S. I didn't marked this question as answered. Strange...

[Martin Koch · Accepted solution]

Hello Alexander!

Lets see:

is there a way to move calls from the failed MCU (just in case) to the working one?

If it is a booked call you could delete the conference in tms and set it up again.

There is no automatic way either is there some hot failover.

(btw you would have a similar problem if a vcs goes down, even if it is in a cluster

all its active sessions would be taken down by it).

There is no "drag and drop" of active conferences to move it from one to an other MCU.

And one more point of clearing out. As I undarstood from the  documentation a cluster of MCU 5300 does not provide redundancy because  the one is Master and the second is Slave. Master/Slave failure leads to  the cluster failure.

Yes that is correct, if the master on a MCU cluster is down the complete cluster is down.

From what I understood if a slave goes down it will just lack these additional ports. But at least

active conferences where participants were on the slave would suffer and I would not rule out that

you would have to reboot the master anyhow.

A MSE8000 cluster would behave the same.

The Link you quoted also states:

http://www.cisco.com/en/US/products/ps11775/index.html
 Cisco TelePresence Conductor will dynamically select the most appropriate Cisco TelePresence resources for each new conference.

This does not say anything about hot failover (as Justin also pointed out).

It  seems like a basic solution for MCU failover with TMS instead of   Conductor. Is it right? Will it be able to function like expected?

The conductor is a relative new and emerging product. Also the TMS integration with the conductor just came with tms 14.1. It depends on how your expectation is, if its hotfailover, then no.

1) Is there any designed/safe way of making MCU redundancy? (if one fails another takes it's place, transparent for the end user, if possible)
2) What cisco devices should I use for completing this task?
As  I figured out from the discussion above (thanks Justin), there is no  way of avoiding interruption of service. But there might be solutions  for just automatic redial. All should be automated as much as possible.

1) it all depends a bit on your usage, for us with most conferences handled as ad-hoc dial in meetings to given conference numbers its quite easy to manage, but sure for other organizations I could also see the demand

of booked meetings and OBTP and TMS

2) clustered vcs + clustered conductor + multiple mcus (+ redundant TMS)

All that being said. I can live with an interruption of a service if one device dies if new calls and conferences

still work. Some things might need time to recover (like a endpoint registration) or maybe manual action

(like delete a hanging conference and create a new one).

The lack if hotfailover does not mean a lack of redundancy.

Btw, personally I never had a MCU which had a failure so I had to take it out of production.

(sure which does not mean that it can not happen later today, ... :-)

How do you plan to use your conferences? Booked meetings, more adhoc with

given meeting room names/numbers, direct or via the conductor?

I really like the conductor, I think its a great tool to help you with enabling scalability and redundancy

of your MCU service. You can also combine the VCS with the redundancy given by virtualization if needed.

I would recommend that you talk to your local cisco partner / representative and file a feature request

if you see that things for your deployment could be improved.