Displaying cluster status for a master blade

The number of the slot in the MSE chassis to which this row in the table refers.

To configure a blade as a master or a slave in a cluster, go to the web interface of the MSE 8050 Supervisor in the chassis which houses the MSE media blade.

The IP address of the blade in this slot, or Master blade (if this is the master).

Possible statuses for a slave blade are:

• OK: The master and slave are communicating correctly.
• OK (last seen <number> seconds ago): The master has lost contact with the slave. The slave will restart itself and in this way it will rejoin the cluster. Wait a few minutes and then refresh the Status > Cluster page.
• Still starting up: The slave blade is in the process of starting up. Wait a few minutes and then refresh the Status > Cluster page.
• Lost contact <number> secs ago: The master has lost contact with the slave. The slave will restart itself and in this way it will rejoin the cluster. Wait a few minutes and then refresh the Status > Cluster page.
• Cluster support not enabled: There is no Cluster support feature key on this blade.
• Failed, version mismatch: All blades in the cluster must be running the same version of software. This status message indicates that this blade is running different software to the master blade. This blade is not part of the cluster. Update all blades in the cluster to the same version of software.
• Blade not configured as slave: The Supervisor has told the master that the blade is a slave, but the blade is not a slave. This indicates that someone has removed the slave blade and replaced it with a different blade.
  
• Blade incorrect type: Someone has removed the blade in this slot and replaced it with a different blade type after the cluster was configured.

If the status of the slave is OK, it is currently functioning in the cluster. For any of the other statuses, the slave blade is not currently functioning as part of the cluster.

If a slave blade has a problem that causes it to no longer be part of the cluster, the cluster can continue to operate without that slave. For example, in a cluster of three blades if one slave fails, the master and the other slave can continue to operate and accept calls. There will just be fewer video ports available. Similarly, in a cluster of two blades, if the slave fails, the master continues to operate.

If a slave blade fails, participants in conferences will not be disconnected: if there are sufficient resources on another blade in the cluster, they will continue to receive audio and video. In the worst case, the video will disappear, but the audio will continue because all audio is processed by the master blade.

If the master loses contact with a slave, the slave will automatically restart itself. In this way, it can rejoin the cluster.

An overview of the current media loading of each blade in the cluster. The load may increase during periods of peak conference use.

Conferences are distributed between the blades in the cluster. The loads on the blades depend on the number of conferences running on each blade and the sizes of those conferences.

On a slave blade, the audio load will always be zero: the master is responsible for all the audio.

The number of port licenses on each slot in this cluster.

All port licenses on slave blades are controlled by the master blade. Depending on how you use the blades in the MSE chassis, you might want to allocate all port licenses to the slot that houses the master blade or you might distribute them between the slots in the cluster. It does not matter to the cluster how you have allocated the port licenses; in any case, the master controls all port licenses and even if a blade has failed in the cluster, the master will continue to have access to any port licenses allocated to the failed blade's slot.