Converting the existing survivable core server to main server

Last Updated : Jan 28, 2025 |

About this task

Use this procedure to convert an existing survivable core server to a main server. For example, when two or more systems are being combined into one system, an existing Avaya server could be converted to a main server while other servers could be converted to survivable core servers.

Caution:

This procedure is service affecting. As the new main server is coming online, the Media Gateway that are being controlled by other servers will eventually switch to the new main server. This requires that the Media Gateway perform a reset. If a survivable core server exists, it may be advantageous to switch all Media Gateway to the survivable core server prior to the conversion.

Procedure

  1. Back up the translations on the server to be converted. If the existing main server is still in operation, perform a complete backup. If the existing main server is not in operation, determine the location of the last known good backup.
  2. Verify that the server to be converted is disconnected from the LAN/WAN.
    Caution:

    Two main servers cannot be connected to the LAN/WAN at the same time.

  3. Connect the laptop to the services port on the server that you are converting.
  4. Confirm that the server to be converted is running the latest version of Communication Manager.
    1. On the System Management Interface, click Administration > Server (Maintenance).

      The Server Administration Interface is displayed.

    2. Click Software Version under Server.

      If the server is not running on the latest version of Communication Manager, upgrade the server.

  5. If the server is a duplex pair, busy out the standby server.
  6. Execute this step for S8300E active servers. In the System Management Interface, under Server Configuration, click the Network Configuration option.
    1. Enter a unique Server ID (SVID) in the Server ID field. A single SVID is required for a single server and two unique SVIDs are required for a duplicated server pair. This ID must be between 1 and 256. Usually the main servers are set to SVID 1 and 2.Gaps in the numbering are allowed (10, 20, 30, . . .) but servers may also be consecutively numbered.

      • Click Continue, and verify the IP Addresses.

    2. Under the Server Configuration, click the Server Role option from the left margin.

      • Select the main server.

  7. For duplicated servers, perform the same configuration activities as step 6 for the standby server.
  8. Install a new license file with the appropriate settings for the main server.

    The new license file should have the following attributes:

    • Enterprise Survivable Server set to n

    • ESS Administration set to y

    • A Module ID (MID) of 1: The MID is referred to as the Cluster ID (CLID) by the survivable core server feature. This value is set by the license file and cannot be administered in Communication Manager. Each server in a duplex pair (OEMR XL R640) has the same CLID. A main server always has the MID of 1.

      The MID appears in the license file name after the letter m. In an example where the main server license file name is s66579v5m1-060214-20295.lic, the MID would be 1.

    • A System ID (SID): The SID is unique to the system configuration. The main server and all survivable core servers will have the same SID.

  9. Configuring the server causes a reset to be executed. It is not sufficient to notify all of the non Communication Manager processes of the new server configuration including the Cluster ID.
  10. From the active server command line interface, run the following commands to notify all processes of the new parameters:

    • stop -caf

    • start -ca

  11. For duplicated servers, release the busy out of the standby server using the Release Server command on the System Management Interface.
  12. Wait for the license file to be file synced from the active server to the standby. This can be verified by using the Linux command statuslicense-v repeatedly until the Module ID is updated.
  13. Once the Module ID is updated, run the following commands from the command line to inform all processes of the new server configuration and Module ID.interface:

    • stop -caf

    • start -ca

  14. Be sure that the translations from the main server match the translations for the newly converted main server. Use the display survivable-processor command to check the main translations. If the translations do not match, adjust as necessary using the Network Configuration command from the System Management Interface (see step 6).
  15. Remove the old ESS translations from the newly converted main server using the remove survivable-processor nodename command, where nodename is the old ESS node name.

    If this is not done the new main server will alarm when the former survivable core server fails to register. For more information on administering ESS, see Survivable core server administration.

  16. After the former ESS translations have been removed, it is necessary to notify all Communication Manager processes that the old Cluster ID no longer exists. Use the following commands to notify the Communication Manager processes:

    • save trans all

    • reset sys 4

  17. Use the list survivable-processor, display survivable-processor nodename,command to verify that the correct translations are present for all the survivable core servers.
  18. Disconnect, if connected, the old main server from the LAN/WAN.
  19. Connect the new main server to the LAN/WAN.
  20. At any existing survivable core server, verify that the new main server or server pair are connected to the LAN/WAN.
  21. Using the System Management Interface, on each ESS and LSP specify:
    1. The IP address(es) of the new main server.

      Changing the address of the main server on the survivable core server does not require a reset system 4, nor does it do one automatically.

      For more information on how to configure the server, see Server configuration worksheets.

  22. Verify that each of the survivable core servers and survivable remote servers register with the main server and that the translations are updated.

    Using the status ess clusters command, verify that the main server (this server) is shown and that all survivable core servers register and their translations are updated. Periodically repeat the status ess clusters or list survivable-processor command until all survivable core servers register and are updated.

    Note:

    An active main server knows its own state and that of any survivable core servers that have registered with it. For some period of time (minutes), after all servers are installed and configured, there may be a discrepancy between the state displayed by the main server and the survivable core servers.

  23. If a save trans all command was not performed in step 16 then do so now. At the main server, execute the save translation all command to synchronize translations between the new main server, the survivable remote servers, and the survivable core servers.
  24. If a reset system 4 command was not performed in 16, then do so now. From the main server, execute the reset system 4 command.
Related information
License files
Survivable core server administration
Pre-requisites for administering a survivable core server on the main server
Survivable Processor screen
Administering page one of the Survivable Processor screen
Administering page two of Survivable Processor screen
Administering Page three of the Survivable Processor screen
Administering Page four of the Survivable Processor screen
Checking the administration on the main server
Server configuration worksheets
Network settings
Network configuration settings
Duplication parameters
Add Login