Cisco Unified MeetingPlace Release 8.5 -- About Failover Options for the Hardware Media Server

From DocWiki

Revision as of 18:01, 24 March 2011 by MeetingPlace Moderator (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Main page: Cisco Unified MeetingPlace Release 8.5

Up one level: Planning Your Deployment


This module describes how failover works for the Hardware Media Server.


Note: The Express Media Server is part of the Application Server. See About Failover Options for the Application Server for information about failover for the Express Media Server.


How Hardware Media Server Failover Works

The Hardware Media Server performs load balancing based on resource usage and not by the number of meetings. When the system receives a request for a new meeting, the Hardware Media Server checks all the Audio Blades and chooses the Audio Blade that is currently carrying the lightest load to create the meeting.


If a Hardware Media Server fails, the system automatically performs failover; no manual configuration is necessary.


For Hardware Media Server failover, you can choose from the following options:

  • Configure an extra Audio Blade on the Application Server. If this is a video deployment, the Audio Blade should have its own Video Blade.
  • Use a standby Hardware Media Server that is connected to the standby Application Server. The standby Hardware Media Server may be smaller than the primary.


These two options are not mutually exclusive and we recommend both. If a single blade (Audio Blade or Video Blade) fails, the Application Server generates an alarm and then automatically assigns new calls to the extra blade. If the whole Hardware Media Server fails, use the standby system.


Audio and video port licenses are not required for redundant Audio and Video Blades.


Audio Blade Failover Mechanism

The failover mechanism for an Audio Blade is as follows:

  1. The Application Server maintains a list of active Audio Blades.
  2. When an Audio Blade fails, it times out after a few seconds and the Application Server removes it from the list of active Audio Blades.
    Note: The Application Server is unable to distinguish between a failing Audio Blade and an Audio Blade that is out of communication due to network problems.
  3. The Application Server generates the following alarm: "Audio Blade is down: IP_address", where IP_address is the IP address of the failing Audio Blade.
  4. The Application Server drops all existing calls on the failed Audio Blade.
  5. When a new caller comes in for a meeting that was being hosted on the failed Audio Blade, the Application Server restarts the meeting on a different Audio Blade and allows the caller to join.


Video Blade Failover Mechanism

The failover mechanism for a Video Blade is as follows:

  1. The Application Server immediately drops video from any meetings hosted on that Video Blade and the meeting switches to audio only (or audio and web only, if the meeting has a web component).
  2. New calls into that meeting are not offered video.
  3. The Application Server generates the following alarm: "Video Blade is down: IP_address", where IP_address is the IP address of the failing Video Blade.
  4. The Application Server assigns any new meetings that require video to a different Video Blade, if one is available. If no video resources are available, the Application Server starts the meeting as audio only (or as audio and web, if the meeting has a web component).

Rating: 0.0/5 (0 votes cast)

Personal tools