13 Configuring Oracle Traffic Director for High Availability

13.2.1 How Failover Works

Oracle Traffic Director provides support for failover between the instances in a failover group by using an implementation of the Virtual Routing Redundancy Protocol (VRRP), such as keepalived for Linux and vrrpd (native) for Solaris.

Keepalived v1.2.12(minimum version required) is included in Oracle Linux; so you need not install or configure it. Keepalived is licensed under the GNU General Public License. Keepalived provides other features such as load balancing and health check for origin servers, but Oracle Traffic Director uses only the VRRP subsystem. For more information about Keepalived, go to http://www.keepalived.org.

VRRP specifies how routers can failover a VIP address from one node to another if the first node becomes unavailable for any reason. The IP failover is implemented by a router process running on each of the nodes. In a two-node failover group, the router process on the node to which the VIP is currently addressed is called the master. The master continuously advertises its presence to the router process on the second node.

If the node on which the master router process is running fails, the router process on the second node waits for about three seconds before deciding that the master is down, and then assumes the role of the master by assigning the VIP to its node. When the first node is online again, the router process on that node takes over the master role. For more information about VRRP, see RFC 5798 at http://datatracker.ietf.org/doc/rfc5798.

13.2.2 Failover Modes

You can configure the Oracle Traffic Director instances in a failover group to work in the following modes:

• Active-passive: A single VIP address is used. One instance in the failover group is designated as the primary node. If the primary node fails, the requests are routed through the same VIP to the other instance.

• Active-active: This mode requires two VIP addresses. Each instance in the failover group is designated as the primary instance for one VIP address and the backup for the other VIP address. Both instances receive requests concurrently.

The following figure illustrates the active-active and active-passive failover modes.

Figure 13-2 Failover Modes

Description of ''Figure 13-2 Failover Modes''

13.2.3 Creating Failover Groups

This section describes how to implement a highly available pair of Oracle Traffic Director instances by creating failover groups. For information about how failover works, see Section 13.2.1, "How Failover Works."

You can create a failover group by using either Fusion Middleware Control or the WLST.

Before You Begin

• Decide the unique VIP address that you want to assign to the failover group.

  • The VIP addresses should belong to the same subnet as that of the nodes in the failover group.

  • The VIP addresses must be accessible to clients.

  Note:

  To configure an active-active pair of Oracle Traffic Director instances, you would need to create two failover groups with the same instances, but with a distinct VIP address for each failover group, and with the primary and backup node roles reversed.

• Identify the network prefix of the interface on which the VIP should be managed. The network prefix is the subnet mask represented in the Classless Inter-Domain Routing (CIDR) format, as described in the following examples.

  • For an IPv4 VIP address in a subnet that contains 256 addresses (8 bits), the CIDR notation of the subnet mask 255.255.255.0 would be 24, which is derived by deducting the number of addresses in the given subnet (8 bits) from the maximum number of IPv4 addresses possible (32 bits).

  • Similarly, for an IPv4 VIP address in a subnet that has 4096 addresses (12 bits), the CIDR notation of the subnet mask 255.255.240.0 would be 20 (=32 minus 12).

  • To calculate the CIDR notation of the subnet mask for an IPv6 subnet, you should deduct the bit-size of the subnet's address space from 128 bits, which is the maximum number of IPv6 addresses possible.

  The default network-prefix-length is 24 or 64 for an IPv4 VIP or IPv6 VIP, respectively. The default network-prefix-length is used, if not specified, for automatically choosing the NIC and for validating if the VIP is in the same subnet as the specified NIC.

  While actually plumbing the VIP it is preferred to use the hostmask, 32 for IPv4 and 128 for IPv6, so that any outgoing traffic originating from that node does not use the VIP as the source address.

• Identify the Oracle Traffic Director administration nodes that you want to configure as primary and backup nodes in the failover group. The nodes should be in the same subnet.

  Note that the administration nodes that you select should have Oracle Traffic Director instances present on them for the specified configuration.

• Identify the network interface for each node.

  For each network interface that is currently up on the host, the administration server compares the network part of the interface's IP address with the network part of the specified VIP. The first network interface that results in a match is used as the network interface for the VIP.

  For this comparison, depending on whether the VIP specified for the failover group is an IPv4 or IPv6 address, the administration server considers only those network interfaces on the host that are configured with an IPv4 or IPv6 address, respectively.

• You can bind to a VIP IP address within the HTTP listener by performing a system configuration that allows you to bind to a non-existing address, as a sort of forward binding. Perform one of the following system configurations:

  echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

  or,

  sysctl net.ipv4.ip_nonlocal_bind=1 (change in /etc/sysctl.conf to keep after a reboot)

  Make sure that the IP addresses of the listeners in the configuration for which you want to create a failover group are either an asterisk (*) or the same address as the VIP. Otherwise, requests sent to the VIP will not be routed to the virtual servers.

• Make sure that the router ID for each failover group is unique. For every subsequent failover group that you create, the default router ID is decremented by one: 254, 253, and so on.

Creating Failover Groups Using Fusion Middleware Control

To create a failover group by using the Fusion Middleware Control, do the following:

1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

2. Click the WebLogic Domain button at the upper left corner of the page.

3. Select Administration > OTD Configurations.

   A list of the available configurations is displayed.

4. Select the configuration for which you want to create a failover group.

5. Click the Traffic Director Configuration In the Common Tasks pane.

6. Select Administration > Failover Groups.

   The Failover Groups page is displayed. It shows a list of the Failover Groups defined for the configuration.

7. Click Create.

   The New Failover Group wizard is displayed.

   Figure 13-3 New Failover Group Wizard

   
   Description of ''Figure 13-3 New Failover Group Wizard''
   
   

8. Follow the on-screen prompts to complete creation of the failover group by using the details—virtual IP address, network interface, host names of administration nodes, and so on—that you decided earlier.

   After the failover group is created, the Results screen of the New Failover Group wizard displays a message confirming successful creation of the failover group.

9. Click Close on the Results screen.

   The details of the failover group that you just created are displayed on the Failover Groups page.

   Note:

   At this point, the two nodes form an active-passive pair. To convert them into an active-active pair, create another failover group with the same two nodes, but with a different VIP and with the primary and backup roles reversed.

Creating Failover Groups Using WLST

To create a failover group, run the otd_createFailoverGroup command.

For example, the following command creates a failover group with the following details:

• Configuration: ha

• Primary instance: 1.example.com

• Backup instance: 2.example.com

• Virtual IP address: 192.0.2.1

props = {}
props['configuration'] = 'ha'
props['virtual-ip'] = '192.0.2.1'
props['primary-instance'] = '1.example.com'
props['backup-instance'] = '2.example.com'
props['primary-nic'] = 'eth0'
props['backup-nic'] = 'eth0'
otd_createFailoverGroup(props)

To enable active-active failover, create another failover group with the same two nodes, but with the primary and backup roles reversed.

For more information about otd_createFailoverGroup, see WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

13.2.4 Managing Failover Groups

To manage the failover groups, the failover daemon needs to run as a privileged user (typically root), otd_startFailover command should be executed as a privileged user on the machines on which the primary and backup instances of the failover group run. Similarly to stop the daemon, you should run the otd_stopFailover. The configuration parameters for the keepalived daemon are stored in a file named keepalived.conf in the config directory of each instance that is part of the failover group. For more information about otd_startFailover or otd_stopFailover, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

After creating failover groups, you can list them, view their settings, change the primary instance for a failover group, switch the primary and backup instances, and delete them. Note that to change the VIP or any property of a failover group, you should delete the failover group and create it afresh.

You can view, modify, and delete failover groups by using either Fusion Middleware Control or the WLST.

Managing Failover Groups Using Fusion Middleware Control

To view, modify, and delete failover groups by using the Fusion Middleware Control, do the following:

1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

2. Click the WebLogic Domain button at the upper left corner of the page.

3. Select Administration > OTD Configurations.

   A list of the available configurations is displayed.

4. Select the configuration for which you want to manage failover groups.

5. Click the Traffic Director Configuration In the Common Tasks pane.

6. Select Administration > Failover Groups.

7. The Failover Groups page is displayed. It shows a list of the Failover Groups defined for the configuration.

   • To view the properties of a failover group, click its virtual IP.

   • To switch the hosts for the primary and backup nodes, click the Toggle Primary button. In the resulting dialog box, click OK.

   • To delete a failover group, click the Delete button. In the resulting dialog box, click OK.

Managing Failover Groups Using WLST

To view, modify, and delete failover groups, see the following examples with the below details.

• Configuration: ha

• Primary instance: 1.example.com

• Backup instance: 2.example.com

• Virtual IP address: 10.128.67.44

For example, run the otd_listFailoverGroups command, for list a failover group:

props = {}
props['configuration'] = 'ha'
otd_listFailoverGroups(props)

For example, run the otd_toggleFailovergroupPrimary command, for toggle a failover group:

props = {}
props['configuration'] = 'ha'
props['virtual-ip'] = '10.128.67.44'
otd_toggleFailovergroupPrimary(props)

For example, run the otd_getFailoverGroupProperties command, for change properties of a failover group:

props = {}
props['configuration'] = 'ha'
props['primary-instance'] = '1.example.com'
otd_getFailoverGroupProperties(props)

For example, run the otd_deleteFailoverGroup command, for deleting a failover group:

props = {}
props['configuration'] = 'ha'
props['virtual-ip'] = '10.128.67.44'
otd_deleteFailoverGroup(props)

For more information, see WebLogic Scripting Tool Command Reference for Oracle Traffic Director.