Jump to: navigation, search

Resource Manager HA (Linux)

Two options exists to achieve high availability when the Resource Manager is installed on Linux operating systems: Simple Virtual IP failover and Bonding Driver failover.

When you configure either of these two options, each host in the HA-pair has a static private IP address, however, all hosts share one public virtual IP address. The public IP address is used by external Session Initiation Protocol (SIP) endpoints to interact with the Resource Manager on each host in the cluster. If an instance of the Resource Manager fails on any host, the failover is transparent to the caller.

Furthermore, when you use the Bonding Driver failover option, and two or more network cards are installed on the same server, the bonding driver provides active standby functionality for the individual network interfaces.

Important
If a VMWare installation is used for Resource Manager in active backup HA mode, you must use Procedure: Configuring Bonding Driver Failover. Typically two NICs are recommended for bonding (to achieve maximum robustness), however, bonding can also be achieved by using one NIC only.

Precaution for Failover Scenarios

In certain failover scenarios, it is expected that both Resource Manager instances will have an active (and identical) Virtual IP address. In most environments this is not an issue, because the network layer ARP table is updated automatically to prioritize traffic to the primary Resource Manager. However, Genesys recommends that you confirm with your Network Operations team that no actions are taken at the network layer when duplicate IP addresses (specifically the Virtual IP address) have been identified.

Use the procedures in this section to configure Resource Manager HA in active standby mode on the Linux host(s).

Limitation

A limitation exists when the Resource Manager is configured in HA mode on Linux, where the NICs, that are associated with the aliases and used for the virtual IPs, are active on both Resource Manager hosts. Depending on the network topology, a situation might arise where a SIP User Agent sends a query to find the active Resource Manager, and instead of sending it to the active instance, sends it to the backup Resource Manager.

To workaround for this issue, configure the primary and secondary Resource Manager instances as described in the section, Creating Alarm Reaction Scripts, Conditions, and Reaction Applications on page 435.

Task Summaries

Task Summary: Configuring the RM in High Availability Active-Standby Mode (Linux)
Objective Related Procedures and Actions
  1. Configure the Resource Manager hosts for HA.
Procedure: Configuring Simple Virtual IP Failover

or
Procedure: Configuring Bonding Driver Failover.

  1. Configure the member IDs for the Resource Manager Applications.
Procedure: Configuring the INIT and NLB Script Files (Linux).
  1. Specify the NICs that require monitoring.
Procedure: Specifying the NICs for Monitoring (Linux).
  1. Complete finals steps before executing the Resource Manager HA-pair in NLB mode.
Start Resource Manager HA-pair in NLB mode.
Task Summary: Configuring the RM in High Availability Active-Active Mode (Linux)
Objective Related Procedures and Actions
  1. Configure the member IDs in the Resource Manager Applications.
Procedure: Configuring the Resource Manager HA-Pair.
  1. Configure the virtual IP in the Media Control Platform, Call Control Platform, and CTI Connector Applications.
Procedure: Integrating Application Objects with Resource Manager

and
Procedure: Configuring the Call Control Platform.
Note: When you use these procedures to configure active active HA mode, the virtual IP is used as the Resource Manager IP.

  1. Configure the external load balancer.
the vendor documentation for the type of load balancer you are using (for example, F5 or Radware).

Procedure: Configuring Simple Virtual IP Failover

Configure Resource Manager HA in active standby mode by using Simple Virtual IP failover.

Use this failover method if you do not have multiple NICs in the Resource Manager host.

  1. Verify that:
  2. At the Linux host, log in as root.
  3. Copy the contents of the /etc/sysconfig/network-scripts/ifcfg-eth0 file to the ifcfg-eth0:1 file.
  4. On the active host, modify the lines in the ifcfg-eth0:1 file as follows, replacing <virtual_IP_addr> with the actual virtual IP address: 
    IPADDR=<virtual_IP_addr>
ONBOOT=no
ONPARENT=no
DEVICE=eth0:1
BOOTPROTO=none

    For RHEL 5 Releases only:

  5. Prepare the ifup-eth script:
      Copy /etc/sysconfig/network-scripts/ifup-eth file to <RM_Install_Dir>/bin directory.
    1. In the <RM_Install_Dir>/bin/ifup-eth file, comment out lines 266 to 269, as follows: 
      # if !arping -q -c 2 -w 3 -D -I ${REALDEVICE} ${IPADDR}; then
# echo $"Error, some other host already uses address ${IPADDR}."
# exit 1
# fi
    2. Enable executable permission, by typing chmod +x <RM_Install_Dir>/bin/ifup-eth, and then press Enter.
  6. Prepare the ifup script:
    1. Copy the /etc/sysconfig/network-scripts/ifup script to the <RM_Install_Dir>/bin directory.
    2. In the <RM_Install_Dir>/bin/ifup file, modify lines 145 to 149, as follows: 
      OTHERSCRIPT="<RM_Install_Dir>/bin/ifup-eth"
# if [!-x ${OTHERSCRIPT}]; then
# OTHERSCRIPT="/etc/sysconfig/network-scripts/ifup-eth"
# fi
    3. Enable executable permission by typing chmod +x <RM_Install_Dir>/bin/ifup, and then pressing Enter.
    4. Repeat these steps on the standby host.

    For RHEL 4 Releases only:

  7. Enable executable permission by typing chmod +x <RM_Install_Dir>/bin/ifup, and then pressing Enter.
  8. Repeat Steps 1, 2, 3, and 7 on the standby host.
  9. Modify the INIT and NLB script files. See Procedure: Configuring the INIT and NLB Script Files (Linux).

Procedure: Configuring Bonding Driver Failover for RHEL 4.x and RHEL 5.x

Configure Bonding Driver failover on the Resource Manager to achieve High Availability.

  1. Verify that:
  2. At the Linux host, log in as root.
    Tip
    Genesys recommends that root user perform the steps in this procedure. However, if a non-root user must use this procedure, see Procedure: Enabling a Non-root User to Configure and Run Resource Manager to make that possible.
  3. In the /etc/modprobe.conf file, on separate lines add:
    alias bond0 bonding
    and
    options bond0 miimon=1000 mode=1
  4. In the /etc/sysconfig/network-scripts directory, copy the contents of the ifcfg-eth0 file to the ifcfg-bond0 file.
  5. In the ifcfg-bond0 file:
    1. Change DEVICE=eth0 to DEVICE=bond0.
    2. Remove any line that refers to the hardware address for example, HWADDR=.
    3. Set this option: BONDING_OPTS= "miimon=1000 mode=1"
  6. In the ifcfg-eth0 file:
    1. Remove any line that refers to the hardware address for example, HWADDR=.
    2. Remove any line that refers to the IP address for example, IPADDR=.
    3. On a separate line, add MASTER=bond0.
    4. On a separate line, add SLAVE=yes.
  7. Repeat the previous step for the ifcfg-eth1 file.
  8. Restart the host computer.
  9. Make a copy of the ifcfg-bond0 file, and name it ifcfg-bond0:1.
  10. After the host has restarted, modify the ifcfg-bond0:1 file, as follows, substituting <virtual_IP_addr> for the actual virtual IP address: 
    IPADDR=<virtual_IP_addr>
ONBOOT=no
ONPARENT=no
DEVICE=bond0:1
BOOTPROTO=none

    For RHEL 5 Releases only:

  11. Prepare the ifup-eth script:
    • Copy the /etc/sysconfig/network-scripts/ifup-eth file to <RM_Install_Dir>/binINSERT_TEXT directory.
    • In the <RM_Install_Dir>/bin/ifup-eth file, comment out lines 266 to 269, as follows: 
    # if !arping -q -c 2 -w 3 -D -I ${REALDEVICE} ${IPADDR}; then
# echo $"Error, some other host already uses address ${IPADDR}."
# exit 1
# fi
  12. Enable executable permission, by typing chmod +x <RM_Install_Dir>/bin/ifup-eth, and then press Enter.
  13. Prepare the ifup script:
  14. Copy the /etc/sysconfig/network-scripts/ifup script to the <RM_Install_Dir>/bin directory.
  15. In the <RM_Install_Dir>/bin/ifup file, modify lines 145 to 149, as follows: 
    OTHERSCRIPT="<RM_Install_Dir>/bin/ifup-eth"
# if [!-x ${OTHERSCRIPT}]; then
# OTHERSCRIPT="/etc/sysconfig/network-scripts/ifup-eth"
# fi
  16. Enable executable permission by typing chmod +x <RM_Install_Dir>/bin/ifup, and then pressing Enter.
  17. Repeat Steps 2 to 11 on the standby host in the HA-pair.

    For RHEL 4 Releases only:

  18. Enable executable permission by typing chmod +x <RM_Install_Dir>/bin/ifup, and then pressing Enter.
  19. Repeat Steps 2–9 and 13 on the standby host in the HA-pair.
  20. Configure the member IDs and NLB script path in the Resource Manager HA Application. See Procedure: Configuring the Resource Manager HA-Pair.
  21. Modify the INIT and NLB script files. See Procedure: Configuring the INIT and NLB Script Files (Linux).

Procedure: Configuring Bonding Driver Failover for RHEL 6.x

Configure Bonding Driver failover on the Resource Manager to achieve High Availability.

  1. Verify that:
  2. At the Linux host, log in as root.
  3. For a channel bonding interface to be valid, the kernel module must be loaded. To ensure that the module is loaded when the channel bonding interface is brought up,
    1. Create a new file as root named <bonding>.conf in the /etc/modprobe.d/ directory.
      You can name this file anything you like as long as it ends with a .conf extension.
    2. Insert the following line into this new file:
      alias bond<n> bonding
    3. Replace <n> with the interface number, such as 0.
    4. For each configured channel bonding interface, there must be a corresponding entry in your new /etc/modprobe.d/<bonding>.conf file.
    5. Do not specify options for the bonding device in /etc/modprobe.d/<bonding>.conf, or in the deprecated /etc/modprobe.conf file.
    Tip
    Genesys recommends that root user perform the steps in this procedure. However, if a non-root user must use this procedure, see Procedure: Enabling a Non-root User to Configure and Run Resource Manager to make that possible.
  4. In the /etc/sysconfig/network-scripts directory, copy the contents of the ifcfg-eth0 file to the ifcfg-bond0 file.
  5. In the ifcfg-bond0 file:
    1. Change DEVICE=eth0 to DEVICE=bond0.
    2. Remove any line that refers to the hardware address (for example, HWADDR=).
    3. Set these options as follows:
      • BONDING_OPTS="<bonding parameters separated by spaces>"
      • BONDING_OPTS= "miimon=1000 mode=1"
      • ONBOOT=yes
      • NM_CONTROLLED=no
  6. In the ifcfg-eth0 file:
    1. Remove any line that refers to the hardware address (for example, HWADDR=).
    2. Remove any line that refers to the IP address (for example, IPADDR=).
    3. On a separate line, add MASTER=bond0.
    4. On a separate line, add SLAVE=yes.
    5. Set these options as follows:
      • ONBOOT=yes
      • NM_CONTROLLED=no
  7. Repeat the previous step for the ifcfg-eth1 file.
  8. Restart the host computer.
  9. Make a copy of the file ifcfg-bond0:0, and name it ifcfg-bond0:1.
  10. After the host has restarted, modify the ifcfg-bond0:1 file, as follows, substituting <virtual_IP_addr> for the actual virtual IP address: 
    IPADDR=<virtual_IP_addr>
ONBOOT=no
ONPARENT=no
DEVICE=bond0:1
BOOTPROTO=none
NM_CONTROLLED=no

    Note: You can deleted BONDING_OPTS= "miimon=1000 mode=1" because it is not required and is already present in bond0.

  11. Prepare the ifup-eth script:
    1. Copy /etc/sysconfig/network-scripts/ifup-eth file to <RM_Install_Dir>/bin directory.
    2. In the <RM_Install_Dir>/bin/ifup-eth file, comment out lines 243 to 246, as follows: 
      # if ! /sbin/arping -q -c 2 -w 3 -D -I ${REALDEVICE} ${ipaddr[$idx]} ; then
# net_log $"Error, some other host already uses address ${ipaddr[$idx]}."
# exit 1
# fi
    3. Enable executable permission by entering chmod +x <RM_Install_Dir>/bin/ifup-eth.
  12. Prepare the ifup script:
    1. Copy the /etc/sysconfig/network-scripts/ifup script to the <RM_Install_Dir>/bin directory.
    2. In the <RM_Install_Dir>/bin/ifup file, modify lines 157 to 161, as follows: 
      OTHERSCRIPT="''<RM_Install_Dir>''/bin/ifup-eth"
# if [ ! -x ${OTHERSCRIPT} ]; then
# OTHERSCRIPT="/etc/sysconfig/network-scripts/ifup-eth"
# fi
    3. Enable executable permission by entering chmod +x <RM_Install_Dir>/bin/ifup.
  13. Repeat All previous steps on the standby host in the HA-pair.

Procedure: Configuring Bonding Driver Failover for RHEL 7.x

Configure Bonding Driver failover on the Resource Manager to achieve High Availability. To proceed with the following steps, log on to the Linux machine as a root user.

  1. Configure a bonding interface called BOND0. This interface is a virtual Ethernet interface that contains the physical Ethernet interface of ETH0. Go to the /etc/sysconfig/network-scripts/ directory and create the following file:

    2. # vi ifcfg-bond0

    DEVICE=bond0
     TYPE=Ethernet
     MASTER=yes
     ONBOOT=yes
     IPADDR=<ip_addr>
     NETMASK=
     GATEWAY=
     BONDING_OPTS="mode=1 miimon=100"
     BOOTPROTO=none
     NM_CONTROLLED=no

    Inside the BOND0 interface, an IP address is included. This IP address is the only IP address connected to the server.

  2. Modify the physical ethernet interface related to the BOND0 interface:

    3. # vi ifcfg-eth0

    DEVICE=ens32
    TYPE=Ethernet
    ONBOOT=yes
    NM_CONTROLLED=no
    MASTER=bond0
    SLAVE=yes
    BOOTPROTO=none

    In the above example, the interface ETH0 is modified. Also, the IP address inside the eth0 interface is removed and MASTER = bond0 is appended.

  3. Repeat step (2) for ifcfg-eth1.
  4. Restart the network service to load the new configuration:

    5. # service network restart

    If network restart fails, then disable NetworkManager using:

    # service NetworkManager stop (To stop)
    # chkconfig NetworkManager off (To disable)

    Restart the network service again.

    #service network restart

    Now start and enable NetworkManager:

    #service NetworkManager start
    #chkconfig NetworkManager on

  5. Now, the new interface called bond0 is part of the network list:

    6. # ifconfig

    bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500

    ...
    ...
    eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500

    ...
    ...
    lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536

    ...
    ...

  6. Check the bonding status using the following command:

    7. # cat /proc/net/bonding/bond0

    Bonding Mode: fault-tolerance (active-backup)
    Primary Slave: None
    Currently Active Slave: eth0
    MII Status: up
    MII Polling Interval (ms): 100
    Up Delay (ms): 0
    Down Delay (ms): 0

    Slave Interface: eth0
    MII Status: up
    Speed: 1000 Mbps
    Duplex: full
    Link Failure Count: 0
    Permanent HW addr: 08:00:27:61:e4:88
    Slave queue ID: 0


  7. Create another virtual interface bond0:1 and enter the details as:

    8. # vi ifcfg-bond0:1
    DEVICE=bond0:1
    TYPE=Ethernet
    NM_CONTROLLED=no
    IPADDR=<your virtual IP address> (Same as virtual-ip in cluster section of RM Application)
    NETMASK=
    GATEWAY=
    PREFIX=24
    NAME=bond0:1
    ONBOOT=no
    ONPARENT=no
    BOOTPROTO=none

    After completing the above steps, make sure that the following files are available in the /etc/sysconfig/network-scripts/ directory:
    ifcfg-bond0
    ifcfg-bond0:1
    ifcfg-eth0

  8. Copy and paste /etc/sysconfig/network-scripts/ifup-eth file to the <RM_installation>/bin directory and comment out the following lines:

    9. # if ! LC_ALL=C ip addr ls ${REALDEVICE} | LC_ALL=C grep -q "${ipaddr[$idx]}/${prefix[$idx]}" ; then
     # if [ "${REALDEVICE}" != "lo" ] && [ "${arpcheck[$idx]}" != "no" ] ; then
     # /sbin/arping -q -c 2 -w 3 -D -I ${REALDEVICE} ${ipaddr[$idx]}
     # if [ $? = 1 ]; then
     # net_log $"Error, some other host already uses address ${ipaddr[$idx]}."
     # exit 1
     # fi
     # fi

  9. Copy and paste the ifup file from network-scripts directory to <RM_installation>/bin directory. Then modify the following lines:

    10. OTHERSCRIPT="<RM_installation_directory>/bin/ifup-eth"

    #if [ ! -x ${OTHERSCRIPT} ]; then
    # OTHERSCRIPT="/etc/sysconfig/network-scripts/ifup-eth"
    #fi

  10. Bring the bond0:1 interface up using the following command:

    11. # ifup bond0:1

    Restart the network service again. New interface bond0:1 is shown on the network list.

    bond0:1: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500

    …………
    ………….

  11. Give read, write, and execute permissions to all the files in the bin directory of <RM_installation_path>.
  12. Repeat all the steps on the other host of the RM HA pair.

Procedure: Enabling a Non-root User to Configure and Run Resource Manager

Create a user with permission to operate Resource Manager without root access. This user will access the Resource Manager install directory, and the directories /bin/ifup and /sbin/ifdown.

Run the following commands through the root account to give sudo permission for selected commands (<RM Install directory>/bin/ifup, /sbin/ifdown) to this user.

  1. Run the following commands in the console of the RHEL machine:
    1. visudo
      This command opens the file.
    2. Beneath the line root ALL= (ALL) ALL, add this line:
      gvp-user ALL= NOPASSWD: <RM Install directory>/bin/ifup, /sbin/ifdown
    3. Comment the new line Defaults requiretty.
  2. Execute the following commands:
    ...to grant permission to gvp-user to edit/use the necessary files and folders.
    • chown gvp-user /etc/modprobe.conf ...for RHEL 5
    • chown -R gvp-user /etc/modprobe.d ...for RHEL 6
    • chown -R gvp-user /etc/sysconfig/network-scripts
    • chown -R gvp-user /opt/genesys ...Grants permission to gvp-user for installing the GVP software.
  3. Log on (using ssh) as gvp-user.
  4. Configure Resource Manager for High Availability with the Procedure: Configuring the Resource Manager HA-Pair. Once you have completed the Resource Manager High Availability configuration...
  5. Modify the following files:
    1. NLB.bat: add sudo to the beginning of lines 10 and 13...
      • line number 10 should read:
        sudo <RM Install directory>/bin/ifup $activeIntf
      • line number 13 should read:
        sudo /sbin/ifdown $activeIntf
    2. INIT.sh: add sudo at the beginning of line 6...
      • line number 6 should read:
        sudo /sbin/ifdown $activeIntf
  6. The non-root user gvp-user should begin the Procedure: Configuring Bonding Driver Failover at step 2.

Procedure: Configuring the INIT and NLB Script Files (Linux)

Verify that the mymemberid parameter that is configured in the cluster section of the Resource Manager Application for mymemberid=1 (and mymemberid=2) is the same as the configuration in the NLB.bat file for mymemberid=1 (and mymemberid=2).

Configure the INIT and NLB script files so that each Resource Manager host is assigned a unique member ID in the HA-pair.

  1. Verify that HA is set up on the Resource Manager hosts. See Procedure: Configuring Simple Virtual IP Failover, or Procedure: Configuring Bonding Driver Failover.
  2. At the Linux host, log in as root.

    NLB.bat File

  3. Follow the instructions in the NLB.bat file to update the mymemberids:
    • On the Resource Manager host that is assigned memberID=1 in the <RM_Install_Dir>/bin directory, update mymemberid=1.
    • On the Resource Manager host that is assigned memberID=2 in the <RM_Install_Dir>/bin directory, update mymemberid=2.
  4. Save the changes.

    INIT.sh File

  5. Follow the direction in the INIT.sh file to update the following lines:
    • If you are using Simple Virtual IP Failover activeIntf="eth0:1".
    • If you are using Bonding Driver Failover activeIntf="bond0:1".
  6. Save the changes.
    Note: In the NLB.bat and INIT.sh files, the activeIntf= parameter must match the bonding-driver configuration; for example, use activeIntf="bond0:1 if you are configuring Bonding Driver failover. Use activeIntf="eth0:1 if the bonding driver is not configured.
  7. Repeat this procedure on the Resource Manager host that is assigned memberID=2.
  8. Specify the NICs that you want to monitor. See Procedure: Specifying the NICs for Monitoring (Linux).

Procedure: Specifying the NICs for Monitoring (Linux)

Specify the NICs that are to be monitored by the Resource Manager.

  1. Verify that:
  2. Log in to Genesys Administrator.
  3. On the Provisioning tab, select Environment > Applications.
  4. Select the Resource Manager Application you want to configure.
  5. On the Options tab, scroll to the GVP section. (Create the gvp section if it does not exist.)
  6. Add the nic parameter that corresponds nic.ethX parameter.
  7. If not configured by default, edit the nic.upvalue parameter as follows:
    nic.upvalue = up
  8. If not configured by default, edit the nic.linkattribute parameter as follows:
    nic.linkattribute = MII Status:
  9. Edit the nic.eth0 parameter as follows:
    nic.eth0 = "/proc/net/bonding/bond0" Configure the nic.eth0 parameter value as shown above, even when Simple Virtual IP failover is used. If the file cannot be read, the NIC status is queried directly by default during NIC detection.
  10. Add the nic.eth1 parameter as follows:
    nic.eth1 = "/proc/net/bonding/bond0" If Simple Virtual IP failover is used, configure the nic.eth1 parameter as follows (where represents an empty string): nic.eth1 =
  11. If more than two NICs exist, configure the nics option value to 0 1.
    Tip
    The instructions in Step 8, 9, and 10 are based on the assumption that the chosen network interfaces are numbered 0 and 1. If this configuration does not match the actual interface numbers in your system, change the values accordingly.
  12. Save the changes.
  13. Execute the INIT file on each Resource Manager host. See Start Resource Manager HA-pair in NLB mode.

Creating Alarm Reaction Scripts, Conditions, and Reaction Applications

When an active Resource Manager goes down, but does not stop it's virtual IP, and then the backup Resource Manager becomes active and starts it's virtual IP, the two systems will claim the virtual IP. Therefore, when a system sends an ARP query to determine where the virtual IP can be reached, it might obtain or use the response from the system with the inactive Resource Manager.

To ensure this does not occur, complete each task in the Task Summary: Configuring the Resource Manager to Use Alarm Scripts on both the primary and backup Resource Manager instances.

Tip
Alternatively, you can use a wizard in Genesys Administrator to complete the first two tasks in the Task Summary table. See Procedure: Using the Create New Application Wizard. As you proceed through the wizard, enter the information in the required fields as outlined in the procedures in this section.
Task Summary: Configuring the Resource Manager to Use Alarm Scripts
Objective Related Procedures and Actions
  1. Create a new Third Party Server template.
Procedure: Creating the Third Party Server Template.
  1. Create two Reaction Applications.
Procedure: Creating the Reaction Applications.
  1. Create and configure two Alarm Reaction scripts.
Procedure: Creating and Configuring the Alarm Reaction Scripts.
  1. Create two Alarm Conditions to send an alarm when either instance of the Resource Manager is stopped.
Procedure: Creating an Alarm Condition for an RM Stopped Intentionally.
  1. Create two Alarm Conditions to send an alarm when either instance of the Resource Manager stops unexpectedly.
Procedure: Creating an Alarm Condition for an RM Stopped Unexpectedly.

Procedure: Creating the Third Party Server Template

Create a Third Party Server template to use for the Reaction Applications (which the next procedure will create).

  1. Log in to Genesys Administrator.
  2. On the Provisioning tab, select Provisioning > Environment > Application Templates.
  3. Click New.
  4. On the Configuration tab, populate the following fields:
    • Name: Third Party Server
    • Type: Third Party Server
    • Version: 1.0
  5. Click Save & Close.
  6. Create the Reaction Applications. See Procedure: Creating the Reaction Applications (immediately below).

Procedure: Creating the Reaction Applications

Create the Reaction Applications that stop the NIC (the virtual IP interface) on the Resource Manager that is down (intentionally or unintentionally).

  1. In Genesys Administrator, go to Provisioning > Environment > Applications.
  2. Click New.
  3. On the Configuration tab, in the General section, populate the following fields:
    • Name: stop_pri_VIP or stop_bac_VIP
    • Application template: Third Party Server
  4. In the Server Info section, populate the following fields:
    • Host: <Primary RM host object> or <Backup RM host object>
      (Add the name of the primary or backup Resource Manager host object.)
    • Listening Ports: <Port Number>
      (Add a default unused port, typically in the 70xx range.)
    • Working Directory: <RM bin directory>
      (Add the actual Resource Manager bin directory.)
    • Command Line: ./NLB.bat
      For IPTakeover, you must use IPTakeOver.bat
      Command Line=IPTakeOver.bat}}
    • Command Line Arguments: disable 2
      (for stop_pri_VIP) or disable 1 (for stop_bac_VIP)
  5. Click Save & Close.
  6. Create the Alarm Scripts. See Procedure: Creating and Configuring the Alarm Reaction Scripts.

Procedure: Creating and Configuring the Alarm Reaction Scripts

Configure the Alarm Reaction scripts that cause the Reaction Applications to be run when the Alarm Reaction script is called.

  1. In Genesys Administrator, go to Provisioning > Environment > Scripts.
  2. Click New.
  3. On the Configuration tab, in the General section, populate the following fields:
    • Name: pri_rm_not_running or bac_rm_not_running
    • Script Type: Alarm Reaction
  4. Click Save & Close.

    Configuring Alarm Scripts

  5. In the list of Scripts, click (to highlight) the Alarm script you created in Procedure: Creating and Configuring the Alarm Reaction Scripts.
  6. In the Tasks pane, click Script Wizard and enter the following in each step of the wizard:
  7. When the wizard is complete, Click Finish.
  8. Create the Alarm Conditions. See Procedure: Creating an Alarm Condition for an RM Stopped Intentionally.

Procedure: Creating an Alarm Condition for an RM Stopped Intentionally

Create an Alarm condition under which an Alarm script is activated when the Resource Manager is stopped intentionally.

  1. In Genesys Administrator, go to Provisioning > Environment > Alarm Conditions.
  2. Click New.
  3. On the Configuration tab, in the General section, populate the following fields as shown here:
    • Name: rm_pri_stopped or rm_bac_stoppedINSERT_TEXT
    • Description: primary RM was manually stopped or backup RM was manually stopped
    • Detect Clearance Timeout: 1 (change the default value from 86400)
    • Detect Log Event ID: 5091
    • Detect Selection Mode: Select by Application (from drop-down menu)
    • Detect Application: Enter primary or backup Resource Manager Application object (the actual Resource Managers, not the reaction objects).
  4. In the Scripts section, populate the following fields with equivalent data: colspan="2"|Scripts
    Field Sample Data
    General
    Name rm_pri_stopped
    Description Primary RM was manually stopped
    Category Major (selected from a drop-down list)
    Detect Script (select from a search field)
    Clearance Timeout 1
    Detect Log Event ID 5091
    Detect Selection mode Select by Application (from a drop-down list of applications)
    Detect Application Type GVP Resource Manager (selected from a drop-down list)
    Detect Application HA_RM_2 (selected from a search field)
    Cancel Log Event ID: 0
    State: Enabled
    Name pri_rm_not_running
    Script Type Alarm Reaction
    State Enabled
  5. Click Add in the Reaction Scripts: field to add pri_rm_not_running or bac_rm_not_running. (See Procedure: Creating and Configuring the Alarm Reaction Scripts.)
  6. Click Save & Close.
  7. Provision the Alarm Conditions. See Procedure: Creating an Alarm Condition for an RM Stopped Intentionally

Procedure: Creating an Alarm Condition for an RM Stopped Unexpectedly

Create an Alarm condition that activates an Alarm script when the Resource Manager is stopped unexpectedly.

  1. In Genesys Administrator, go to Provisioning > Environment > Alarm Conditions.
  2. Click New.
  3. On the Configuration tab, in the General section, populate the following fields:
    • Name: rm_pri_down or rm_bac_down
    • Description: primary RM stopped unexpectedly or "backup RM stopped unexpectedly"
    • Detect Clearance Timeout: 1 (change the default value from 86400)
    • Detect Log Event ID: 5064
    • Detect Selection Mode: Select by Application (from drop-down menu)
    • Detect Application: Enter primary or backup Resource Manage Application object (the actual Resource Manager instances, not the reaction objects).
  4. In the Scripts section, populate the following fields:
  5. Click Add in the Reaction Scripts: field to add pri_rm_not_running or bac_rm_not_running. (See Procedure: Creating and Configuring the Alarm Reaction Scripts.)
  6. Click Save and Close.
This page was last edited on April 23, 2018, at 05:52.
Comments or questions about this documentation? Contact us for support!