An Enhanced Redundancy Configuration for the Avaya S8700 Media Server – Issue 1.2
Abstract
The Avaya S8700 Media Server architecture supports an additional pair of remote redundant servers with a minimum of additional administration. A network with geographically dispersed backup servers that are actively capturing backup translations sets a new standard for redundancy support, offering significantly enhanced protection from catastrophic loss of mission critical applications. Many customers with large networks have expressed an interest in greater protection from long term network outages resulting from floods, earthquakes, and building catastrophes. These Application Notes are a result of such customer requests. They describe the administrative steps required to configure an additional backup S8700 server pair, and to switch it into service when required1. They are applicable to IP Connect and MultiConnect configurations with or without Avaya S8300 Media Servers.
1 This issue of these Application Notes applies only to Communication Manager releases 1.1 – 1.3, and supercedes the following issues:
• An Enhanced Redundancy Configuration for the Avaya S8700 Media Server with Avaya G600 Media Gateways – Issue 1.0
• An Enhanced Redundancy Configuration for the Avaya S8700 Media Server with Avaya S8300 Local
Survivable Processors and Avaya Media Gateways – Issue 1.1 See your Avaya Sales representative about the Manual Backup Server (MBS) capabilities now being offered for CM releases 2.0 and later.
1.1. Background The Avaya S8700 Media Server architecture has been designed such that the network administration for the server platform itself is independent of the telephony administration that manages Media Gateways. This provides a means by which additional backup S8700 Media Servers can be deployed throughout the customer network by simply copying the telephony administration files. Web-based server platform administration supports automatic backup and manual restore of these files to the backup servers. When activation of a backup server is required, it can be accomplished with a few standard administration commands. S8300 Local Survivable Processors (LSP) can also be supported with a small amount of additional administration. These Application Notes outline the procedures for configuration and service activation of a backup S8700 Media Server within IP Connect and MultiConnect configurations. Avaya G600, G700, and SCC1/MCC1 Media Gateways are supported. Control of G700 Media Gateways by an S8700 Media Server IP Connect configuration is supported in Communication Manager Release 1.2 or greater. See the appropriate product documentation for standard installation and administration procedures for the S8300 and S8700 Media Servers, and Media Gateways.
1.2. Terminology The following terminology will be used in this document.
• References to the S8700 Media Server or server pair will mean the combined dual processor unit. All other references to a server in the text or administration screens will mean a specific processor in a server pair.
• The primary server pair normally provides telephony service. The backup server pair is powered up, but not providing service during normal operation, and is then manually put into service when the primary pair becomes unavailable.
• The active server is the processor within a server pair that is currently available to provide service. The standby server is not providing service, but will be automatically put into service should the active server fail.
• The primary active server refers to the active server in the primary server pair. The primary standby server refers to the standby server in the primary server pair.
• The backup active server refers to the active server in the backup server pair. The backup standby server refers to the standby server in the backup server pair.
• G600, SCC1 and MCC1 Media Gateways are sometimes also referred to as “port networks”
1.3.1. S8700 IP Connect The sample network configuration shown in Figure 1 was used to verify the procedures that follow for an IP Connect configuration. The primary S8700 Media Server pair is co-located with a G600 Media Gateway at a headquarters location. The backup server pair is co-located with an S8300 LSP and G700 Media Gateway at a branch location. The two locations are connected via a frame-relay WAN. The actual locations of the gateways and server pairs do not matter as long as the network is administered so that the backup server pair has the same network access to all of the gateways, S8300 LSP, and Avaya IP telephones as the primary server pair. For maximum reliability, administer the Media Gateway Controller Lists of G700 Media Gateways to contain the IP addresses of as many geographically dispersed C-LAN boards as possible.
To verify support for standalone G700 Media gateways, the S8300 LSP was temporarily removed from the configuration. The results were identical to that for G600 Media Gateways, as documented in Issue 1.0 of these Application Notes.
1.3.2. S8700 MultiConnect A MultiConnect configuration is shown in Figure 2. The primary and backup server pairs each have their own pair of redundant Ethernet switches for their control network. Inter-location links among the switches and remote MCC1 Gateways use Ethernet/fiber media converters and single or multi-mode fiber links. The MCC1 Media Gateways operate in a duplicated IPSI (IP Server Interface) configuration. Locations 1 and 2 contain the primary and backup server pairs, respectively. Locations 3 and 4 show alternate configurations for other locations with MCC1 Media Gateways. For optimal survivability of MCC1 Gateways at locations without S8700 servers, the configuration shown for Location 4 is recommended, since loss of either Location 1 or 2 will allow the remaining location to control these gateways.
2. Equipment and Software Validated The following Avaya components were used to verify these Application Notes for the IP Connect configuration in Figure 1. No other special versions of Avaya hardware or software were required. The models for switches and routers are not pertinent to the features validated in these Application Notes.
Component Version Avaya S8300 Media Server R011x.01.0.060.4 Avaya S8700 Media Servers R011x.01.0.060.4 Avaya G700 Media Gateway
Processor (MGP) 2
3. Process Overview Figure 3 shows a high level view of the configuration and switchover administration sequences. Each of the steps shown will be described in more detail in the following sections. Note that no administrative steps are required for the G600 and G700 gateways themselves. This is due to the architectural flexibility of MultiVantage described in Section 1.1.
4. Configuring the Backup Server Pair The backup server pair should be configured as follows:
• The data network should be configured so that the backup server pair can access the same gateways, servers and IP telephones that are controlled by the primary server pair.
• The installed license file must use the same Reference IPSI serial number as that for the primary server pair. If not, contact Avaya or the BusinessPartner installation team.
• Anonymous FTP access should be enabled on the backup active server. This can be done using the Security Start/Stop FTP Server function in the web interface. Select Start Server. The result is shown in Figure 4. Since FTP is disabled during the server software upgrade process, this step must be repeated following an upgrade.
Figure 4: Backup Active Server Web Interface - Enabling Anonymous FTP
• The backup standby server should be busied out, using the Server Busy Out Server function on its web interface, as shown in Figure 5. Select Busy Out. This prevents the standby from becoming active during the switchover procedures described in Section 7.
Figure 5: Backup Standby Server Web Interface - Busying Out the server
• Each backup server must be configured to require manual startup of Avaya Communication Manager. Specifically, the file /etc/rc.d/rc4.d/s99wdinit must be removed. This ensures that the backup servers will not become active after a power failure2.
• Telnet into each backup server, log in with the appropriate credentials, and stop Communication Manager via the stop –af command. Use the statapp command to verify that all processes have been stopped. See Figure 6 for sample output as applied at the standby backup server.
Figure 6: Backup Standby Server CLI Interface – Verifying Communication Manager has been stopped
2 This is a privileged operation and must be performed by the Avaya Support Team. Contact them for details.
5. Scheduling Translation Backups The translation file in the primary active server must be backed up to the standby active server. The Data Backup/Restore Schedule Backup function on the web interface will only perform automatic backups if the server is active at the time the backup is attempted. Since either server in the primary server pair can be active due to server interchanges, both servers in the primary server pair must be configured to automatically store the current translation file on the backup active server. The following procedure must be repeated for both primary servers. The Schedule Backup function is shown in Figure 7. Select Add.
Figure 7: Primary Active Server Web Interface - Scheduling the backup Repeat for standby server
AVAYA Call Processing and Save ACP translations prior to backup will be selected by default. Select FTP as the backup method, and populate the displayed fields as shown in Figure 8 and Figure 9. The User Name must be “anonymous”. The password can be any string. The Host Name should contain the IP address of the backup active server. The Directory must be “.”. Check the desired day under Day of Week, or check all days for daily backups. Modify the Start Time as necessary. Select Add New Schedule (see Figure 9). The resulting schedule screen is shown in Figure 10. Translation files will be transferred to the /var/home/ftp directory of the designated backup active server.3
Figure 8: Primary Active Server Web Interface – Backup Scheduling Detail Screen (top portion) Repeat for standby server
3 If additional file redundancy is desired, a second backup schedule can be added to the primary active and primary standby servers to transfer a copy of the translation file to the backup standby server. It is important that for a given server, the start times specified for multiple backup schedules be different by at least 5 minutes.
Figure 10: Primary Active Server Web Interface - Backup Scheduling Results Screen Repeat for standby server
6. Configuring the S8300 Media Server The S8300 Media Server must be configured to accept translation file updates from the backup server pair. This configuration must be done for each S8300 Media Server in the network. Use the Server Configuration and Upgrades Configure Server function in the S8300 Media Server web interface shown in Figure 11 to specify the IP addresses of the backup server pair. Continue the Configure Server process to the end (Update System). Then reboot the S8300 Media Server.
Figure 11: Adding the backup server pair IP addresses to the S8300 Media Server – Web interface
7. Restoring Service Using the Backup Server Pair If the primary server pair becomes unavailable, and a switchover to the backup server pair is desired, the following procedure should be followed:
1. If the primary server pair is still running and connected to the network, shut them down 2. Use the Data Backup/Restore View/Restore Data function in the web interface for
the backup active server to restore translations from the most recent copy transferred. Select Local Directory, as shown in Figure 12. The system displays “/var/home/ftp” as the default directory. Select View.
Figure 12: Backup Active Server Web Interface - Restoring Translations
3. From the resulting list of translations files, select the most recent, based on the time and date stamp contained in the names (Figure 13). Check Force restore if server name mismatch. If the software versions of the primary and backup server pairs are different (not recommended), but the translation files are known to be compatible, check Force restore if backup version mismatch. Then select Restore. The first warning message that results in Figure 14 is due to the server name mismatch, and can be ignored.
Figure 14: Backup Active Server Web Interface – Result of Restoring Translations
4. Telnet into each of the backup servers and use the CLI start -a command to start Communication Manager, which will use the newly restored translations. Since the backup standby server was busied out (see Section 4), a server interchange will not take place. Use statapp to verify that Communication Manager is running. The backup active server will take control of the gateways the network and restore telephone service.
5. Release the backup standby server via the server –r CLI command or Server Release
Server in the web interface (see Figure 15). Select Release. This will cause the translations in the backup active server to be copied to the backup standby server.
8. Restoring the S8300 Servers to Non-LSP Mode The S8300 LSP Media Servers in the network will transition to LSP mode if the backup server pair is not put into service within the administered transition time interval. In this case, the S8300 LSP must be put under control of the S8700 backup server pair. To do this, open a SAT session on each S8300 LSP, and execute reset system 4 as shown in Figure 16. This will cause Communication Manager to restart, registering the S8300 LSP with the backup server pair.
Figure 16: S8300 LSP SAT Interface - Resetting the Server
9. Re-activating the Primary Server Pair To return the primary server pair to service:
1. Busy out the backup standby server (see Section 4). 2. Telnet into each backup server, log in with the appropriate credentials, and stop
Communication Manager via the stop –af command. Use the statapp command to verify that all processes have been stopped.
3. Put the primary server pair back into service. If translation changes have been made while the backup server pair has been providing service, then the translations must be transferred back to the primary server pair. A way to do this is to repeat the steps described in Sections 4, 5, and 7, reversing the roles of the primary and backup server pair. In this case an immediate rather than scheduled backup could be performed via the Data Backup/Restore Backup Now function on the web interface.
10. Verification Proper installation and configuration of the backup server pair in your network can be verified using the following steps:
1. Follow the steps outlined in Sections 4-6. 2. Disconnect the RJ-45 cable from the control network ports on the primary server pair. 3. Verify that no successful calls can be made between media gateways. Note that calls will
be possible within and between G700 Media Gateways that are controlled by the same S8300 LSP when it transitions to LSP mode.
4. Follow the steps outlined in Sections 7-8. 5. Verify the following:
• Calls can be completed successfully as when the primary server pair was providing service.
• Use the Server View Summary Status function in the web interface on the active or standby backup server to verify the mode (active or standby) of each server.
• Start a SAT session on the active backup server and use the list configuration all command to verify that all gateways and their populated board slots are listed. If they are not, use the list ipserver-interface and list media-gateway commands to verify the proper connection status of the G600 and G700 Media Gateways, respectively.
11. Additional Considerations
1. Long-term operation of the primary/backup server pair configuration will result in accumulation of translation files on the backup active server4. To conserve storage space, it is recommended that the older translation files be periodically deleted from the /var/home/ftp directory on this server. Failure to do so will cause that particular disk partition to become full, and will prevent additional backup translation files and error
4 The new MBS redundancy supported in release 2.0 and later eliminates this.
logs from being accumulated by the system. However, telephone service will not be affected. This is by design, and prevents denial of service attacks via unauthorized usage of anonymous FTP.
2. Since more than one schedule of automatic translation file backup can be created using
the Data Backup/Restore Schedule Backup function on the primary active server, more than one backup server pair can be configured in multiple locations to support highly redundant and distributed disaster recovery applications. The procedures described in Sections 4-6 would be repeated for each backup server pair and S8300 LSP. The backup start times on the primary server pair must be staggered, as noted earlier.
3. Should the G600 Media Gateway containing the Reference IPSI be unreachable from the
backup S8700 Media Server, the server will go into license-error mode. Service will still be provided for an additional 6 days (144 hours). At that time, the server will enter no-license mode, and service will be blocked. For that reason, it is important to make network connectivity to the Reference IPSI as reliable as possible. In a disaster recovery situation, if the Reference IPSI is no longer functional, Avaya support should be contacted immediately to perform a “License File Serial Number Swap-out” procedure using the Remote Feature Activation (RFA) web application. This procedure will modify the license file to match a new Reference IPSI that is specified. Avaya will generate and install a new license on your backup server pair, as well as on the primary server pair when it becomes available. The procedure takes approximately 10 minutes to execute.5 Refer the Avaya support team to the License File Serial Number Swap-out procedures located at https://rfa.avaya.com.
4. If the backup servers are affected by a power failure or the servers must be restarted,
Communication Manager will not be started automatically. It must be started manually using the procedure described in Section 7, Step 4.
12. Conclusion These Application notes describe the means by which system availability can be improved by deploying backup S8700 Media servers throughout the customer network. This approach takes advantage of the distributed, single IP network architecture of an Avaya S8700 Media Server controlling S8300 LSP Media Servers, G600 Media Gateways, G700 Media Gateways, and SCC1/MCC1 Media Gateways. It applies to IP Connect and MultiConnect configurations. Distributing the gateways and servers geographically or in different buildings reduces single points of failure and allows partial or full service to be restored within a short time period.
5 This service may result in a bill being generated to the customer, depending on the warranty or post-warranty arrangements in effect at the time.
