Table Of Contents
About Cisco Unity Failover
How Failover Works in Cisco Unity
Requirements for Cisco Unity Failover
How Standby Redundancy Works in Cisco Unity
Requirements for Cisco Unity Standby Redundancy
Effects of Using or Not Using the Force Failover Setting
Effects of Failover and Failback on Calls in Progress
Effects on Cisco Unity Web Applications When Failover or Failback Occurs
Status Monitoring and File Replication
Data That Is Not Replicated
Events When Failover Occurs
Events When Failback Occurs
Automatic and Manual Failback
Causes of Failover and Failback
Failover Causes
Failback Causes
Intervals for Failover and Failback
Failover Interval
Failback Interval
Causes of Both Servers Becoming Active at the Same Time
Effects of Shutting Down and Restarting the Primary and Secondary Servers
Licensing Restrictions on Using a Secondary Server Without a Primary Server
About Cisco Unity Failover
This chapter contains the following sections:
•
How Failover Works in Cisco Unity
•Requirements for Cisco Unity Failover
•How Standby Redundancy Works in Cisco Unity
•Requirements for Cisco Unity Standby Redundancy
•Effects of Using or Not Using the Force Failover Setting
•Effects of Failover and Failback on Calls in Progress
•Effects on Cisco Unity Web Applications When Failover or Failback Occurs
•Status Monitoring and File Replication
•Events When Failover Occurs
•Events When Failback Occurs
•Automatic and Manual Failback
•Causes of Failover and Failback
•Intervals for Failover and Failback
•Causes of Both Servers Becoming Active at the Same Time
•Effects of Shutting Down and Restarting the Primary and Secondary Servers
•Licensing Restrictions on Using a Secondary Server Without a Primary Server
How Failover Works in Cisco Unity
Revised May 5, 2008
Failover is a feature that provides a simple redundancy, allowing voice messaging functions to continue if the Cisco Unity server fails or when you need to perform maintenance. To set up failover, you install and configure Cisco Unity on two servers, a primary server and a secondary server.
Both Cisco Unity servers are connected to the same message store.
The Exchange message store can be installed on the secondary Cisco Unity server (in the voice messaging configuration only) for sites that do not want a separate computer for the Exchange message store. In this configuration, messages are available in the Exchange message store as long as the computer that it shares with the secondary server is functioning. When Exchange is installed on the secondary server, the primary and secondary servers cannot be separated by a firewall.
Alternatively, the Exchange message store can be installed on a computer other than the Cisco Unity servers (in either the unified messaging configuration or voice messaging configuration). In this configuration, messages are available in the Exchange message store when either the primary or secondary server is not functioning.
When Exchange is installed on a separate server, the primary and secondary servers can be separated by a firewall. However, the primary Cisco Unity server cannot be separated from any of the following servers by a firewall:
•The partner Exchange server.
•The domain controller that Cisco Unity monitors for directory updates.
•The global catalog server that Cisco Unity monitors for directory updates.
•The global catalog server with which the Cisco Unity MAPI client communicates.
Cisco Unity failover was designed with the expectation that the primary server would generally be the active server. If the secondary server is separated from any of the listed servers by a firewall, the secondary server must be used as the active server only for brief periods. The problem with the primary server must be resolved promptly, and the primary server must be made the active server again at the earliest opportunity.
If the system includes a Cisco Unity voice recognition server, the primary and secondary Cisco Unity servers must be on the same side of the firewall as the Cisco Unity voice recognition server.
For details on the TCP/UDP ports used by Cisco Unity and other servers, see the "IP Communications Required by Cisco Unity" chapter in the Security Guide for Cisco Unity at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_maintenance_guides_list.html.
The following figures show possible failover configurations for certain integrations with Cisco Unity. For information on making the line connections, see Appendix B, "Line Connections for Voice Card Integrations."
Figure 4-1 Failover Configuration for a Cisco Unified Communications Manager Phone System
Figure 4-2 Failover Configuration for a Phone System in a DTMF Integration Through Voice Cards
Figure 4-3 Failover Configuration for a Phone System in a Serial Integration Through Voice Cards
Figure 4-4 Failover Configuration for a Phone System Integrated Through Digital PIMG Units
Figure 4-5 Failover Configuration for a Phone System in a Serial Integration Through Analog PIMG Units
For figures of failover configurations that do not appear above, see the "Integrating a Secondary Server for Cisco Unity Failover" section in the applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.
Under normal circumstances, the primary server is active—Cisco Unity answers phone calls and takes messages, sends message notifications, and turns message waiting indicators (MWIs) on and off. The secondary server is inactive—Cisco Unity is running, but it does not perform any voice messaging functions.
Table 4-1 shows the behavior of the two servers when the primary server is active.
Table 4-1 Cisco Unity Behavior When the Primary Server Is Active
Cisco Unity Behavior
|
Primary Server
|
Secondary Server
|
Running
|
Yes
|
Yes1
|
Active (handles voice messaging processes)
|
Yes
|
No
|
Answers phone calls
|
Yes
|
No
|
Sends message notifications
|
Yes
|
No
|
Turns on and off MWIs
|
Yes
|
No
|
If the primary server fails or if the Cisco Unity service on the primary server stops, the secondary Cisco Unity server can automatically become active and starts performing standard Cisco Unity operations. This shift from primary to secondary Cisco Unity servers is called failover. If you want to stop the primary Cisco Unity server for maintenance, you can also initiate failover manually.
Note PIMG/TIMG units, when used by integrations, control when failover is initiated by sensing that the primary server is not responding. If the primary server is unresponsive, the PIMG/TIMG units will direct calls to the secondary server, which will become active.
If standby redundancy is configured, failover must be initiated manually.
Table 4-2 shows the behavior of the two servers when the secondary server is active.
Table 4-2 Cisco Unity Behavior When the Secondary Server Is Active
Cisco Unity Behavior
|
Primary Server
|
Secondary Server
|
Running
|
Depends1
|
Yes
|
Active (handles voice messaging processes)
|
No
|
Yes
|
Answers phone calls
|
No
|
Yes
|
Sends message notifications
|
No
|
Yes
|
Turns on and off MWIs
|
No
|
Yes
|
When the secondary server is active, Cisco Unity functions normally, with the following exceptions:
•For a few seconds after a failure occurs and before the secondary server becomes active, subscribers will experience one of the following behaviors when they dial the internal phone number to log on to Cisco Unity by phone:
–For all integrations except PIMG/TIMG, subscribers will hear a fast-busy tone.
–For integrations through PIMG/TIMG units, subscribers will hear a ringback tone or will be transferred to an attendant.
•Reports can be generated only while the primary server is active.
You can configure the secondary server to initiate failback daily. When failback succeeds, the primary server becomes the active server again. Alternatively, you can configure failover so that the secondary server fails back only when you manually initiate failback by using the Failover Monitor.
Note Integrations that use PIMG/TIMG units require temporarily unchecking the Force Failover If Call Arrives on Inactive Secondary check box when failback occurs.
For the behavior of failover during outages of network components, see Appendix C, "Behavior of Cisco Unity Failover During Outages of Network Components."
Requirements for Cisco Unity Failover
For Cisco Unity failover requirements, refer to System Requirements for Cisco Unity at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_installation_guides_list.html.
How Standby Redundancy Works in Cisco Unity
Cisco Unity standby redundancy uses failover functionality to provide duplicate Cisco Unity servers for disaster recovery. The primary server is located at the primary facility, and the secondary server is located at the disaster-recover facility.
Standby redundancy functions in the following manner:
•Data is replicated to the secondary server, with the exceptions noted in the "Data That Is Not Replicated" section.
•Automatic failover is disabled.
•In the event of a loss of the primary server, the secondary server is manually activated.
Requirements for Cisco Unity Standby Redundancy
For Cisco Unity standby redundancy requirements, refer to System Requirements for Cisco Unity at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_installation_guides_list.html.
Effects of Using or Not Using the Force Failover Setting
For integrations through PIMG/TIMG units, the Force Failover If Call Arrives on Inactive Secondary check box must be checked so that failover can function correctly. Otherwise, failover will not function correctly. The information in this section does not apply to integrations through PIMG/TIMG units.
For all other integrations, you can choose whether to use the Force Failover If Call Arrives on Inactive Secondary setting in the Failover Monitor, which is enabled by default. For these integrations, this setting determines how Cisco Unity failover responds to calls that are not answered on the primary server.
If standby redundancy is configured, the Force Failover If Call Arrives on Inactive Secondary check box must be unchecked on the secondary server. Otherwise, standby redundancy will not function correctly.
Calls to the primary server may not be answered for the following reasons:
•One or more voice messaging ports on the primary server lock up and fail to respond to calls.
•An insufficient number of voice messaging ports are available to handle phone traffic.
•The primary server experiences high CPU utilization.
•Cisco Unified Communications Manager integration only: The voice messaging ports on the primary server unregister with the Cisco Unified CM server.
By checking or not checking the Force Failover check box, you can control whether an unanswered call on the primary server causes failover to occur.
Events When the Force Failover If Call Arrives on Inactive Secondary Check Box Is Checked
When a call is not answered on the primary server and the check box is checked in the Failover Monitor, the following events occur:
1. The call is presented to the secondary server.
2. The call causes an Event log entry on the secondary server, which can alert the system administrator to the potential problem on the primary server. (For details on setting up event notification, see the "Setting Up Notification of When Failover Occurs" section on page 1-7.)
3. The secondary server answers the call, causing failover to occur.
Customers may want the secondary server to become active when a voice messaging port on the primary server is locked up. However, other customers who install Cisco Unity servers with a large number of ports may be annoyed that failover occurs when just one port is locked.
Events When the Force Failover If Call Arrives on Inactive Secondary Check Box Is Not Checked
When a call is not answered on the primary server and the check box is not checked in the Failover Monitor, the following events occur:
1. Except for integrations through PIMG/TIMG units, the call is forwarded to the next available voice messaging port on the primary server. (Failover does not occur, and the primary server remains active.)
2. Except for integrations through PIMG/TIMG units, the call causes an Event log entry on the secondary server, which can alert the system administrator to the potential problem on the primary server. (For details on setting up event notification, see the "Setting Up Notification of When Failover Occurs" section on page 1-7.)
Failover occurs only when the primary server fails or when the system administrator manually initiates failover.
Customers who install Cisco Unity servers with a large number of voice messaging ports do not experience failover when just one port is locked. However, if all ports are locked or the CPU utilization is high, Cisco Unity stops answering calls until the system administrator manually initiates failover.
Effects of Failover and Failback on Calls in Progress
When failover or failback is initiated, calls in progress are maintained or dropped, depending on the status of the Cisco Unity service (AvCsMgr.exe) and of the network.
Table 4-3 Failover and Failback Effects on Calls in Progress
Cisco Unity Service
or Network Status
|
Action
|
The Cisco Unity
service is stopped
or crashes
|
For all integrations, calls in progress are dropped. When the Cisco Unity service (AvCsMgr.exe) on the primary server becomes inactive, the secondary server becomes active, but the dropped calls cannot be recovered.
|
The Cisco Unity
service is active when
failover or failback occurs
|
For all integrations, calls in progress are maintained until the callers hang up.
|
Network connections
are lost
|
For integrations with IP phone systems (for example, Cisco Unified Communications Manager), calls in progress may be dropped, depending on the nature of the network problem.
For integrations through voice cards, calls in progress are maintained until the callers hang up.
For integrations through PIMG/TIMG units, calls in progress may be dropped, depending on the nature of the network problem.
(For the behavior of failover during outages of network components, see Appendix C, "Behavior of Cisco Unity Failover During Outages of Network Components.")
|
Effects on Cisco Unity Web Applications When Failover or Failback Occurs
Subscribers must use the correct URLs to access the Cisco Unity Administrator, Status Monitor, and the Cisco Personal Communications Assistant (PCA) on the active server. When failover or failback occurs and subscribers use the URL for the inactive server to browse to a Cisco Unity web application, Cisco Unity does not automatically redirect them to the active server.
Subscribers can continue to access Cisco Unity web applications on the inactive server, but the applications do not work as expected:
•When subscribers access the Cisco Unity Administrator on the inactive server, they are not allowed to save changes.
•When subscribers access the Cisco PCA on the inactive server, any changes they make in the Cisco Unity Assistant can be saved, but the changes are not replicated on the active server and are then overwritten when failover or failback occurs.
In contrast, subscribers who use the phone as a recording or playback device for the Media Master control bar can continue to do so without having to manually update it with the applicable server name. This is because when failover or failback occurs, the Media Master automatically directs the request to place the call to the active server, regardless of the URL that the subscriber used to access the Cisco Unity web application.
Note that depending on the application and how the Cisco Unity server is set up, the server name that is displayed in the Media Master may not be updated, but that does not prevent the correct server from placing the call. For example, the server name displayed in the Media Master in the Cisco Unity Administrator and with Cisco Unity ViewMail for Microsoft Outlook does not change. When failover or failback occurs, the name displayed is the one that was entered when the subscriber set up the Media Master to use the phone as a recording or playback device. The same is true for the Cisco PCA when you prevent the Media Master from being set up automatically. (You can use the Advanced Settings Tool to change the default value for the Unity Inbox and Assistant—Automatically Set Up TRAP in Media Master setting.) Otherwise, the server name displayed in the Media Master in the Cisco PCA reflects the server that subscribers browsed to when they entered the URL for the Cisco PCA.
Status Monitoring and File Replication
When failover is configured and Cisco Unity is functioning normally in a configuration where the message store is installed on a separate server, monitoring and replication take place as shown in Figure 4-6.
When failover is configured and Cisco Unity is functioning normally in a configuration where the message store is installed on the secondary server, monitoring and replication take place as shown in Figure 4-7. Note that the message store is not replicated.
Figure 4-6 Monitoring and Replication Actions (the Message Store Is on a Separate Server)
Figure 4-7 Monitoring and Replication Actions (the Message Store Is on the Secondary Server)
For the behavior of failover during outages of network components, see Appendix C, "Behavior of Cisco Unity Failover During Outages of Network Components."
Details of the monitoring and replication actions are described below.
Node Manager Service
•The Node Manager service (AvCsNodeMgr in the Services window) on the active server sends its status to the inactive server (it sends keep-alive events to the inactive server) at a frequency the installer configures. The default is 1 second. The TCP packet is 785 bytes in size and uses port 3653, which the installer can change as a hidden registry setting.
•The Node Manager service in the inactive server sends its status to the active server (it sends keep-alive events to the active server) at a frequency the installer configures. The default is 1 second. The TCP packet is 785 bytes in size and uses port 3653, which the installer can change as a hidden registry setting.
•The Node Manager service monitors the Cisco Unity service (AvCsMgr) on the server.
Cisco Unity Files
•The frequency of replication between the active and inactive servers depends on the value of the File Replication Interval field in the Failover Monitor and how often the Cisco Unity files change.
•The Node Manager service monitors and replicates the files in the directories Localize\DefaultConfiguration, Localize\Prompts, Snapshot, Stream Files, Support, and UnityMTA (which contains the Unity Messaging Repository, or UMR) on the Cisco Unity server.
•The Node Manager service creates a snapshot in the Snapshot directory of the files in the replicated directories during each replication cycle. In subsequent replication cycles, the Node Manager service compares the current snapshot with the previous snapshot to determine the files that should be replicated.
•If changed files have not been replicated to the secondary server when the AvCsMgr service is stopped or the Cisco Unity server crashes, the changes may be lost. Under such circumstances, the new information is not on the secondary server and may be lost or corrupted on the primary server.
•Replication of changed files is disabled when the Node Manager service is set to manual mode.
SQL Server Database (UnityDb)
•Replication occurs every minute if there are SQL data changes.
•The database on the primary server is configured as the publisher and distributor.
•The database publication is UnityDbPublication.
•The database on the secondary server is configured as the subscriber.
•Two-way replication between the two servers is enabled to let the primary server receive all changes made during periods it is online and inactive.
•If changed data has not been replicated to the secondary server when the AvCsMgr service is stopped or the Cisco Unity server crashes, the new data may be lost. Under such circumstances, the new data is not on the secondary server and may be lost or corrupted on the primary server.
Voice Messages
•Voice messages in the message store are not replicated. Voice messages are available to subscribers no matter which Cisco Unity server is active. In a configuration where the message store is on the secondary Cisco Unity server, however, the message store will be off line when the secondary server is off line, causing the Unity Messaging Repository (UMR) on the primary server to become active.
•Voice messages saved in the Unity Messaging Repository (UMR) when the message store is off line are replicated to the inactive server with other Cisco Unity files. (The UMR is located in the UnityMTA directory.)
Data That Is Not Replicated
Changes to the following Cisco Unity settings are not replicated between the primary and secondary servers. You must manually change values on both servers.
•Registry settings
•Recording settings
•Phone language settings
•GUI language settings
•Port settings
•Integration settings
•Conversation scripts
•Key mapping scripts (can be modified through the Custom Key Map tool)
•Media Master server name settings
•Exchange message store, when installed on the secondary server
Events When Failover Occurs
1. Status monitoring and file replication occur when the primary server is active:
a. The Node Manager service monitors the Cisco Unity service and other services on the server to determine whether failover should be initiated.
b. The Node Manager services on both the primary and secondary servers send status to each other on a regular basis.
c. Certain Cisco Unity files when changed are replicated from the primary server to the secondary server.
d. Data from the SQL Database (UnityDb) when changed is replicated from the primary server to the secondary server.
e. The primary server answers calls, sends message notification, and turns MWIs on and off. The secondary server is inactive and performs none of these functions.
f. Voice messages are stored in the message store (Exchange server), which is either on a separate computer from the primary and servers, or is on the secondary server.
2. Failover occurs when any of the following events take place:
•The Node Manager service on the secondary server does not receive a status update from the primary server within the period specified (for example, when the primary server crashes, the Node Manager service is stopped, or there are network connectivity problems).
•The Cisco Unity service on the primary server is stopped. The Node Manager service on the primary server reports the stoppage to the Node Manager service on the secondary server.
•A port on the secondary server receives a call when the Force Failover If Call Arrives on Inactive Secondary check box is checked in the Failover Monitor.
3. The Node Manager service on the secondary server assumes that the Cisco Unity service is stopped on the primary server and activates the Cisco Unity service on its server. (In the case of the secondary server receiving a call, the Node Manager service on the secondary server instructs the Node Manger service on the primary server to initiate failover.) The secondary server starts answering calls, sending message notification, and turning MWIs on and off.
4. The Node Manager service on the secondary server writes a warning to the Event log.
For the behavior of failover during outages of network components, see Appendix C, "Behavior of Cisco Unity Failover During Outages of Network Components."
Events When Failback Occurs
1. Status monitoring and file replication occur when the secondary server is active and the primary server is running (but inactive):
a. The Node Manager service monitors the Cisco Unity service and other services on the server to determine whether failback should be initiated.
b. The Node Manager services on both the secondary and primary servers send status to each other on a regular basis.
c. Certain Cisco Unity files when changed are replicated from the secondary server to the primary server.
d. Data from the SQL Database (UnityDb) when changed is replicated from the secondary server to the primary server.
e. The secondary server answers calls, sends message notification, and turns MWIs on and off. The primary server is inactive and performs none of these functions.
f. Voice messages are stored in the message store (Exchange server), which is either on a separate computer from the primary and servers, or is on the secondary server.
2. Failback occurs when either of the following events takes place:
•When automatic failback is enabled, the time specified for failback arrives, and the Node Manager service on the secondary server notifies the Node Manger service on the primary server that the Cisco Unity service on the secondary server is inactive.
•Manual failback is initiated by using the Failover Monitor.
3. The Node Manager service on the primary server assumes that the Cisco Unity service is stopped on the secondary server and activates the Cisco Unity service on its server. (In the case of the primary server receiving a call, the Node Manager service on the primary server instructs the Node Manger service on the secondary server to initiate failback.) The primary server then starts answering calls, sending message notification, and turning MWIs on and off.
4. The Node Manager service on the primary server writes a warning to the Event log.
For the behavior of failover during outages of network components, see Appendix C, "Behavior of Cisco Unity Failover During Outages of Network Components."
Automatic and Manual Failback
Failback can occur automatically at a time you specify, or you can manually initiate failback. The Failback Type setting is in the Failover Monitor and has the following options:
Scheduled
|
Use this option if you want the secondary server to fail back automatically. In the Failover Monitor, enter values for the Scheduled Failback Start and Scheduled Failback End fields to set the time for automatic failback. This option is useful when you want failback to occur, for example, at night. You can initiate failback manually before the scheduled time by using the Failover Monitor.
|
Manual
|
Use this option if you do not want the secondary server to automatically fail back to the primary server when the primary server becomes available. The secondary server fails back to the primary server only when you manually fail back by using the Failover Monitor.
|
For details on customizing the failback type in the Failover Monitor, see the "Customizing Failover and Failback Settings for the Cisco Unity System (Optional)" section on page 1-13.
Causes of Failover and Failback
Failover Causes
Failover from the primary server to the secondary server can occur for the following reasons:
•Manual failover is initiated from the Failover Monitor.
•The network connection to the primary server is lost. However, both primary and secondary servers remain active.
•The network connection between the primary and secondary servers experiences latency, which causes the Node Manager service on the secondary to miss 30 keep-alive events from the primary server (the default setting in the Failover Monitor).
•If the Force Failover If Call Arrives on Inactive Secondary check box is checked in the Failover Monitor and a call is answered by the secondary server.
•The primary server loses power while the secondary server is still powered.
•The primary server is turned off while the secondary server remains on.
•On the primary server, the Cisco Unity service is stopped or crashes.
•On the primary server, the Node Manager service stops.
•On the primary server, the Node Manager service fails to send keep-alive events to the Node Manager service on the secondary server as configured in the Failover Configuration dialog box of the Failover Monitor.
•There is excessive CPU usage on either the primary or secondary server. When this problem occurs on the primary server before failover and the secondary server after failover, the primary and secondary servers will fail over and fail back repeatedly until the CPU usage problem is resolved.
•The Event Monitoring Service (EMS) initiates manual failover when a user-specified event occurs.
Failback Causes
Failback from the secondary server to the primary server can occur for the following reasons:
•The problem on the primary server is resolved, and manual failback is initiated from the Failover Monitor.
•The problem on the primary server is resolved, and the scheduled time for failback has arrived as configured in the Failover Configuration dialog box of the Failover Monitor.
•The secondary server loses power while the primary server is still powered but inactive.
•The secondary server is turned off while the primary server remains on but is inactive.
•On the secondary server, the Cisco Unity service is stopped or crashes, while the primary server is on but inactive.
•On the secondary server, the Node Manager service stops, while the primary server is on but inactive.
•On the secondary server, the Node Manager service fails to send keep-alive events to the Node Manager service on the primary server as configured in the Failover Configuration dialog box of the Failover Monitor, while the primary server is on but inactive.
Intervals for Failover and Failback
Failover Interval
When failover occurs, the time it takes for the secondary server to begin answering calls typically depends on what causes failover as described in Table 4-4.
Table 4-4 Interval for Failover
Failover Cause
|
Time
|
Manual failover
|
•Except for integrations through PIMG/TIMG units, the secondary server begins answering calls immediately.
For integrations through PIMG/TIMG units, calls are redirected to the extension of an attendant to be answered manually for approximately ten seconds, then the secondary server begins answering calls.
•Calls in progress on the primary server are not dropped but are maintained until the callers hang up.
|
Network outage
|
•The secondary server begins answering calls after waiting for the number of keep-alive events set in the Missed Events Before Failover field in the Failover Monitor. The time required depends on the value of the field and on the value of the Interval (ms) field. The default settings for the fields result in a 30-second delay for the secondary server to become active.
•A network outage may result in both primary and secondary servers being active at the same time. When the network outage is resolved, the primary server remains active and the secondary server becomes inactive.
•For integrations with an IP phone system (for example, Cisco Unified Communications Manager), calls in progress may be dropped, depending on the nature of the network outage. For integrations through voice cards, calls in progress are not dropped but are maintained until the callers hang up. For integrations through PIMG/TIMG units, calls in progress may be dropped, depending on the nature of the network outage.
|
Failure of the AvCsMgr service on the primary server
|
•The secondary server begins answering calls immediately.
•Calls in progress on the primary server are dropped.
|
Failure of the
operating system
on the primary server
|
•The secondary server begins answering calls after waiting for the number of keep-alive events set in the Missed Events Before Failover field in the Failover Monitor. The time required depends on the value of the field and on the value of the Interval (ms) field. The default settings for the fields result in a 30-second delay for the secondary server to become active.
•Calls in progress on the primary server are dropped.
|
Inactive secondary server
answers a call
|
•The secondary server begins answering calls immediately.
•Calls in progress on the primary server are not dropped but are maintained until the callers hang up.
|
Failback Interval
Revised November 16, 2007
When failback occurs, the time it takes for the primary server to begin answering calls typically depends on what causes failback as described in Table 4-5. File replication occurs in the background and does not affect the failback interval.
Table 4-5 Interval for Failback
Failback Cause
|
Time
|
Automatic failback,
and the primary server
is on but inactive
|
•Failback is initiated only when the time scheduled in the Failover Monitor arrives.
•For SCCP integrations with Cisco Unified Communications Manager, the primary server begins answering calls as soon as the first voice messaging port on the primary server connected to Cisco Unified CM is registered after failback is initiated. All voice messaging ports connected to Cisco Unified CM are registered in about 15 seconds.
•For integrations with a SIP phone system (except SIP integrations with Cisco Unified CM), the voice messaging ports on the primary server that are registered to that phone system begin answering calls immediately after failback is initiated.
•For integrations through PIMG/TIMG units, the primary server begins answering calls as soon as the PIMG/TIMG units re-establish their connection to the primary server (in approximately ten seconds).
•For integrations through voice cards, the voice messaging ports on the primary server that are connected to that phone system begin answering calls immediately after failback is initiated.
•Calls in progress on the secondary server are not dropped but are maintained until the callers hang up.
|
Manual failback,
and the primary server
is on but inactive
|
•Failback is initiated immediately.
•For SCCP integrations with Cisco Unified Communications Manager, the primary server begins answering calls as soon as the first voice messaging port on the primary server connected to Cisco Unified CM is registered after failback is initiated. All voice messaging ports connected to Cisco Unified CM are registered in about 15 seconds.
•For integrations with a SIP phone system (except SIP integrations with Cisco Unified CM), the voice messaging ports on the primary server that are registered to that phone system begin answering calls immediately after failback is initiated.
•For integrations through PIMG/TIMG units, the primary server begins answering calls as soon as the PIMG/TIMG units re-establish their connection to the primary server (in approximately ten seconds).
•For integrations through voice cards, the voice messaging ports on the primary server that are connected to that phone system begin answering calls immediately after failback is initiated.
•Calls in progress on the secondary server are not dropped but are maintained until the callers hang up.
|
Failure of the AvCsMgr service on the secondary server, and the primary server is on but inactive
|
•Failback is initiated immediately.
•For SCCP integrations with Cisco Unified Communications Manager, the primary server begins answering calls as soon as the first voice messaging port on the primary server connected to Cisco Unified CM is registered after failback is initiated. All voice messaging ports connected to Cisco Unified CM are registered in about 15 seconds.
•For integrations with a SIP phone system (except SIP integrations with Cisco Unified CM), the voice messaging ports on the primary server that are registered to that phone system begin answering calls immediately after failback is initiated.
•For integrations through PIMG/TIMG units, the primary server begins answering calls as soon as the PIMG/TIMG units re-establish their connection to the primary server (in approximately ten seconds).
•For integrations through voice cards, the voice messaging ports on the primary server that are connected to that phone system begin answering calls immediately after failback is initiated.
•Calls in progress on the secondary server are dropped.
|
Failure of the
operating system
on the secondary server,
and the primary server is on but inactive
|
•The primary server initiates failback after waiting for the number of keep-alive events set in the Missed Events Before Failover field in the Failover Monitor. The time required depends on the value of the field and on the value of the Interval (ms) field. The default settings for the fields result in a 30-second delay for the primary server to become active.
•For SCCP integrations with Cisco Unified Communications Manager, the primary server begins answering calls as soon as the first voice messaging port on the primary server connected to Cisco Unified CM is registered after failback is initiated. All voice messaging ports connected to Cisco Unified CM are registered in about 15 seconds.
•For integrations with a SIP phone system (except SIP integrations with Cisco Unified CM), the voice messaging ports on the primary server that are registered to that phone system begin answering calls immediately after failback is initiated.
•For integrations through PIMG/TIMG units, the primary server begins answering calls as soon as the PIMG/TIMG units re-establish their connection to the primary server (in approximately ten seconds).
•For integrations through voice cards, the voice messaging ports on the primary server that are connected to that phone system begin answering calls immediately after failback is initiated.
•Calls in progress on the secondary server are dropped.
|
Causes of Both Servers Becoming Active at the Same Time
Revised November 16, 2007
Under some circumstances, both the primary server and secondary server can become active at the same time, as indicated in the Failover Monitor. The condition can occur for the following reasons:
•The network connection to the primary server is lost, so both servers become active.
With Cisco Unified Communications Manager (SCCP only), SIP phone systems, and phone systems that integrate through PIMG/TIMG units, Cisco Unity will receive no calls. However, if the primary server loses its connection to the Cisco Unified CM server, the SIP proxy server, or the PIMG/TIMG units while the secondary server retains its connection, calls can reach the secondary server and initiate failover.
With phone systems that integrate through voice cards, calls will be answered by both the primary server and the secondary server simultaneously.
•The Node Manager service on the primary server is stopped. The secondary server becomes active, but the components on the primary server remain active and continue to answer calls.
Effects of Shutting Down and Restarting the Primary and Secondary Servers
When you shut down or restart the primary or secondary servers, the servers behave in the following ways:
•When both servers are running and the active server is shut down, the inactive server becomes active.
•When neither server is running, the first server started becomes the active server.
•When the secondary server is active and configured for automatic failback, and the primary server is also running, the secondary server attempts failback on the failback schedule.
•When the Exchange message store is installed on the secondary server and the secondary server is shut down, Exchange stops. The Unity Messaging Repository (UMR) on the primary server (if active) begins storing messages.
•When the secondary server is restarted, Exchange begins storing messages and the messages stored in the UMR are transferred to Exchange.
•When the domain controller and global catalog are installed on the secondary server and the secondary server is shut down, the following events occur:
–Directory synchronization stops.
–Administrators cannot log on to the Cisco Unity Administrator.
–Subscribers cannot log on to Cisco Personal Communications Assistant (Cisco PCA).
–Subscribers hear silence when trying to leave messages.
–Subscribers cannot listen to new messages that are left by external callers.
Licensing Restrictions on Using a Secondary Server Without a Primary Server
To prevent the secondary server from being used as the primary server in another location, the secondary server stops answering calls:
•Four hours after you restart the secondary Cisco Unity server, if you have never run the Configure Cisco Unity Failover wizard.
•Four hours after you restart the secondary Cisco Unity server, if you have run the Configure Cisco Unity Failover wizard but the secondary server has never been able to contact the primary server.
•60 days after the last time that the secondary server was able to contact the primary server, if the secondary has contacted the primary server at least once. In this case, the only way to make the secondary server start answering calls again is to reconnect the primary server to the network.
There are no licensing restrictions on a primary server, so a primary server will operate without a secondary server. However, without a secondary server, the failover feature cannot work, and an error appears in the Event log whenever you restart the Cisco Unity server. To stop the errors from appearing, disable the Node Manager service (AvCsNodeMgr) in the Services window.
