17 Configuring Oracle Traffic Director for an Enterprise Deployment

When configuring the Web tier, you have an option of using Oracle Traffic Director to route requests to the application tier, rather than Oracle HTTP Server.

The procedure for configuring Oracle Traffic Director is different than the procedure for configuring Oracle HTTP Server.

Topics

About Oracle Traffic Director

Oracle Traffic Director (OTD) is a software load balancer for load balancing HTTP/S and TCP traffic to application tier. 

The application-tier servers that receive the requests from Oracle Traffic Director are referred to as Oracle Traffic Director origin servers. Origin servers can be application servers, Web servers, Oracle Managed File Transfer, LDAP directory servers, MLLP servers, or any type of TCP server.

Starting with Oracle Fusion Middleware 12.2.1.3.0, in addition to being available for use with the engineered systems (Oracle Exalogic running either Oracle Linux or Oracle Solaris or Oracle SuperCluster running Oracle Solaris), Oracle Traffic Director is available for customers with the Oracle WebLogic Server Multi-tenancy or Oracle WebLogic Server Continuous Availability add-on options.

For more information about OTD, see Overview of Oracle Traffic Director in Administering Oracle Traffic Director.

An Oracle Traffic director deployment consists of an admin service and Oracle Traffic Director Instances.

The admin service sits within an Oracle Weblogic Domain. You can choose to place the Admin Server into one of your application domains or create a dedicated domain purely for Oracle Traffic Director. If you are planning to route requests to more than one domain, it is recommended that a dedicated OTD domain be created. This ensures that:

  • OTD can be upgraded independently of any other product.

  • Shutting down an application domain does not impact the management of OTD.

It is recommended that the Oracle Traffic Director Administration service is kept inside your application tier. If you are deploying on Exalogic where there is no demarcation between the web tier and application tier then this is less important.

Oracle Traffic Director can be installed in one of following different ways:

  • Colocated: In this scenario, OTD is managed by the WebLogic Administration Srver.

  • Standalone: In this scenario, OTD is not managed by the WebLogic Administration Server. However, certain key functionality is unavailable.

The standalone installation is also used when an OTD instance is being managed by Oracle WebLogic Server, but does not reside on the host where Admin Server is running.

Variables Used When Configuring Oracle Traffic Director

The procedures for installing and configuring Oracle Traffic Director reference use a series of variables that you can replace with the actual values used in your environment.

The following directory location variables are used in these procedures:

  • WEB_ORACLE_HOME

  • ASERVER_HOME

  • MSERVER_HOME

  • WEB_DOMAIN_HOME

  • JAVA_HOME

  • NM_HOME

  • WEB_APPLICATION_HOME

  • OTD_ORACLE_HOME

  • OTD_ASERVER_HOME

  • APPLICATION_HOME

  • WL_HOME

  • ORACLE_COMMON_HOME

  • nodemanager_username

  • nodemanager_password

  • DOMAIN_NAME

  • WEB_HTTP_PORT

  • IAD_WLS_PORT

  • OAM_PORT

  • IAMADM_PORT

  • IGD_WLS_PORT

  • OIM_PORT

  • SOA_PORT

  • LDAP_PORT

For more information about file system directories and the directory variables, see File System and Directory Variables Used in This Guide.

In addition, you reference the virtual IP (VIP) address — ADMINVHN that is defined in Reserving the Required IP Addresses for an Enterprise Deployment.

  • ADMINVHN

Actions in this chapter are performed on the following host computers:

  • APPHOST1 - Host where OTD Administration Server is running.

  • APPHOST2 - Host where OTD Administration Server can run in the event of a failure of APPHOST1.

  • WEBHOST1 - Host where OTD instance 1 is running.

  • WEBHOST2 - Host where OTD instance 2 is running.

Installing Oracle Traffic Director in Collocated Mode on the Application Tier Hosts

You must install Oracle Traffic Director in Collocated mode on the host that will be managing your Oracle Traffic Director installation.

Subsequent installs on hosts just running the OTD instances do not require a collocated install. Before you install Oracle Traffic Director in collocated mode, you must install:

  • A supported JDK

  • Oracle Fusion Middleware Infrastructure

For information about installing Oracle Fusion Middleware Infrastructure, see Installing the Oracle Fusion Middleware Infrastructure.

To configure Oracle Traffic Director for high availability, perform the steps on two mount points.

Installing the Oracle Fusion Middleware Infrastructure

To start the installation program:

Starting the Oracle Traffic Director Installer

To start the installation program:

  1. Log in to the application host and go to the directory in which you downloaded the installer.
  2. Run the following command to launch the installation wizard:

    On Linux

    fmw_12.2.1.3.1_otd_linux64.bin

When the installation program appears, you are ready to begin the installation.

Verifying the Installation on the Application Tier Hosts

After you complete the installation and the post-installation steps, verify that the Oracle home directory (ORACLE_HOME/otd) contains the following directories:

common
lib
plugins

Navigating the Oracle Traffic Director Installation Screens (Collocated)

The following table describes how to use the installer screens to install Oracle Traffic Director in colocated mode on the first application tier host.

Note:

Installing Oracle Traffic Director in the rest of the application tier is also required in these cases:

  • If future domain extensions are planned. If you have not planned any domain extensions, you might encounter errors when you unpack the domain in the rest of application hosts, due to missing required components.

  • In the application hosts where AdminServer can fail over because OTD components are required by the AdminServer.

If you need additional help with any of the installation screens, click the screen name.

Screen Description

Installation Inventory Setup

On UNIX operating systems, this screen will appear if this is the first time you are installing any Oracle product on this host. Specify the location where you want to create your central inventory. Make sure that the operating system group name selected on this screen has write permissions to the central inventory location.

For more information about the central inventory, see Oracle Fusion Middleware Installing Software with the Oracle Universal Installer in Installing Software with the Oracle Universal Installer.

Note:

Oracle recommends that you configure the central inventory directory on the products shared volume. Example: /u01/oracle/products/oraInventory

You may also need to execute the createCentralinventory.sh script as root from the oraInventory folder after the installer completes.

Welcome

This screen introduces you to the product installer.

Click Next.

Auto Updates

Select whether or not you want to receive automatic updates for this product.

Installation Location

Enter the path to the Oracle Fusion Middleware Infrastructure that you installed in the previous tasks. If you are deploying into an existing application domain, select the location of the infrastructure of that domain.

Note that run-time processes cannot write to this directory.

For the purposes of this enterprise deployment, enter the value of the OTD_ORACLE_HOME variable listed in Table 9-2.

Installation Type

Use this screen to select the type of installation and consequently, the products and feature sets you want to install.

  • Select Collocated OTD (Managed through WebLogic server).

JDK Selection

Select from the dropdown list, the location of the JDK you used when installing the infrastructure.

Prerequisite Checks

The installer analyzes the host computer to ensure that the prerequisites are fulfilled. The results of the prerequisite checks are displayed on this screen.

If a prerequisite check fails, an error or warning message is displayed.
  • Fix the error and click Rerun. For example, if any of the required packages listed in Prerequisites for Installing Oracle Traffic Director are not available in the system, install them.

  • To ignore the error or warning and continue with the installation, click Skip.

  • To stop the prerequisite checking process, click Stop.

Click Next to continue.

Installation Summary

This screen displays the Oracle home directory that you specified earlier. It also indicates the amount of disk space that will be used for the installation and the free space available.

Review information on this screen.

To save the settings specified so far in the installation wizard in a text file (called a response file), click Save. If necessary, you can use the response file to perform the same installation from the command line.

Click Install to begin the installation.

For more information about silent or command line installation, see "Using the Oracle Universal Installer in Silent Mode" in Installing Software with the Oracle Universal Installer.

Installation Progress

This screen shows the progress and status of the installation process.

If you want to cancel the installation, click Cancel. The files that were copied to your system before you canceled the installation will remain on the system; you should remove them manually.

Click Next to continue.

Installation Complete

Click Finish.

Installing Oracle Traffic Director in Standalone Mode on the Web Tier Hosts

You can install Oracle Traffic Director by using an interactive graphical wizard provided by the Oracle Universal Installer. This standalone installation is performed on the two WEBHOST systems that is used in enterprise deployment.

Starting the Oracle Traffic Director Installer

To start the installation program:

  1. Log in to the application host and go to the directory in which you downloaded the installer.
  2. Run the following command to launch the installation wizard:

    On Linux

    fmw_12.2.1.3.1_otd_linux64.bin

When the installation program appears, you are ready to begin the installation.

Installing a Supported JDK

Oracle Fusion Middleware requires that a certified Java Development Kit (JDK) is installed on your system.

Locating and Downloading the JDK Software

To find a certified JDK, see the certification document for your release on the Oracle Fusion Middleware Supported System Configurations page.

After you identify the Oracle JDK for the current Oracle Fusion Middleware release, you can download an Oracle JDK from the following location on Oracle Technology Network:

http://www.oracle.com/technetwork/java/index.html

Be sure to navigate to the download for the Java SE JDK.

Installing the JDK Software

Oracle Fusion Middleware requires you to install a certified Java Development Kit (JDK) on your system.

You must install the JDK in the following locations:

  • On the shared storage device, install the JDK in the /u01/oracle/products/jdk directory. The JDK will be accessible from each of the application tier host computers.

  • On the local storage device for each of the Web tier host computers. The Web tier host computers, which reside in the DMZ, do not necessarily have access to the shared storage on the application tier.

  • On the local storage device for each of the directory tier host computers, in case of the directory hosts not utilizing the shared storage.

For more information about the recommended location for the JDK software, see Understanding the Recommended Directory Structure for an Enterprise Deployment.

To install JDK 1.8.0_131:
  1. Change directory to the location where you downloaded the JDK archive file.
    cd download_dir
  2. Unpack the archive into the JDK home directory, and then run the following commands:
    tar -xzvf jdk-8u131-linux-x64.tar.gz
    Note that the JDK version listed here was accurate at the time this document was published. For the latest supported JDK, see the Oracle Fusion Middleware System Requirements and Specifications for the current Oracle Fusion Middleware release.
  3. Move the JDK directory to the recommended location in the directory structure.
    For example:
    mv ./jdk1.8.0_131 /u01/oracle/products/jdk
  4. Define the JAVA_HOME and PATH environment variables for running Java on the host computer.
    For example:
    export JAVA_HOME=/u01/oracle/products/jdk
    export PATH=$JAVA_HOME/bin:$PATH
  5. Run the following command to verify that the appropriate java executable is in the path and your environment variables are set correctly:
    java -verison
    The Java version in the output should be displayed as “1.8.0_131”.

Navigating the Oracle Traffic Director Installation Screens (Standalone)

The installation program displays a series of screens, in the order listed in the following table.

If you need additional help with any of the installation screens, click the screen name.

Screen Description

Installation Inventory Setup

On UNIX operating systems, this screen will appear if this is the first time you are installing any Oracle product on this host. Specify the location where you want to create your central inventory. Make sure that the operating system group name selected on this screen has write permissions to the central inventory location.

For more information about the central inventory, see Using the Oracle Universal Installer in Installing Software with the Oracle Universal Installer

Note:

Oracle recommends that you configure the central inventory directory within the products directory. Example: /u02/oracle/products/oraInventory

You may also need to execute the createCentralinventory.sh script as root from the oraInventory folder after the installer completes.

Welcome

Click Next.

Auto Updates

Select whether or not you want to receive automatic updates for this product.

Installation Location

Use this screen to specify the location of your Oracle home directory.

Oracle home is the directory in which software binaries for Oracle products are stored. Note that run-time processes cannot write to this directory. For the purposes of an enterprise deployment, enter the value of the WEB_ORACLE_HOME variable listed in Table 9-3.

Installation Type

Use this screen to select the type of installation and consequently, the products and feature sets you want to install.

  • Select Standalone OTD (Managed independently of WebLogic server).

JDK Selection

For the value of JDK Home, enter the value of JAVA_HOME that you set when you install the JDK software.

Prerequisite Checks

The installer analyzes the host computer to ensure that the prerequisites are fulfilled. The results of the prerequisite checks are displayed on this screen.

If a prerequisite check fails, an error or warning message is displayed.

  • Fix the error and click Rerun. For example, if any of the required packages listed in Prerequisites for Installing Oracle Traffic Director are not available in the system, install them.

  • To ignore the error or warning and continue with the installation, click Skip.

  • To stop the prerequisite checking process, click Stop.

Click Next.

Specify Security Updates

If you already have an Oracle Support account, use this screen to indicate how you would like to receive security updates.

If you do not have one and are sure you want to skip this step, clear the check box and verify your selection in the follow-up dialog box.

Installation Summary

This screen displays the Oracle home directory that you specified earlier. It also indicates the amount of disk space that will be used for the installation and the free space available.

Review information on this screen.

To save the settings specified so far in the installation wizard in a text file (called a response file), click Save. If necessary, you can use the response file to perform the same installation from the command line.

Click Install to begin the installation.

For more information about silent or command line installation, see "Using the Oracle Universal Installer in Silent Mode" in Installing Software with the Oracle Universal Installer.

Installation Progress

This screen shows the progress and status of the installation process.

If you want to cancel the installation, click Cancel. The files that were copied to your system before you canceled the installation will remain on the system; you should remove them manually.

Click Next.

Installation Complete

Click Finish.

Verifying the installation on the Web Tier Hosts

After you complete the installation and the post-installation steps, use the ls --format=single-column command to verify that the Oracle home directory contains the following directories:

bin
cfgtoollogs
crs
css
has
install
inventory
jlib
ldap
lib
network
nls
OPatch
oracle_common
oracore
oraInst.loc
otd
oui
plsql
plugins
precomp
rdbms
slax
sqlplus
srvm
webgate
wlserver
xdk

Creating the Oracle Traffic Director Administration Domain

The following topics provide instructions for creating the Oracle Traffic Director Administration domain using the Fusion Middleware Configuration wizard.

For more information on other methods available for domain creation, see Additional Tools for Creating, Extending, and Managing WebLogic Domains in Creating WebLogic Domains Using the Configuration Wizard.

Starting the Configuration Wizard

To begin domain configuration, run the following command in the Oracle Fusion Middleware Oracle home. The domain should be created in one of the application tier hosts (OAMHOST1 or OIMHOST2).

OTD_ORACLE_HOME/oracle_common/common/bin/config.sh

Navigating the Configuration Wizard Screens

Follow the instructions in this section to create the Oracle Traffic Director Administration domain using the Configuration Wizard.

Domain creation and configuration includes the following tasks.
Task 1   Selecting the Domain Type and Domain Home Location

On the Configuration Type screen, select Update an existing domain if you are adding the administration service to an existing application domain. Otherwise, select Create a New domain.

In the Domain Location field, specify the value of the ASERVER_HOME variable, as defined in File System and Directory Variables Used in This Guide. For example, OTD_ASERVER_HOME.

Tip:

More information about the other options on this screen of the Configuration Wizard, see Configuration Type in Creating WebLogic Domains Using the Configuration Wizard.

Task 2   Selecting the Configuration Templates

On the Templates screen, select Oracle Traffic Director – Restricted - JRF 12.2.1.3.0[otd].

Tip:

More information about the options on this screen can be found in Templates in Creating WebLogic Domains Using the Configuration Wizard.

Task 3   Selecting the Application Home Location

On the Application Location screen, specify the value of the APPLICATION_HOME variable, as defined in File System and Directory Variables Used in This Guide.

Tip:

More information about the options on this screen can be found in Application Location in Creating WebLogic Domains Using the Configuration Wizard.

Task 4   Configuring the Administrator Account

On the Administrator Account screen, specify the user name and password for the default WebLogic Administrator account for the domain.

Make a note of the user name and password specified on this screen; you will need these credentials later to boot and connect to the domain's Administration Server.

Task 5   Specifying the Domain Mode and JDK

On the Domain Mode and JDK screen:

  • Select Production in the Domain Mode field.

  • Select the Oracle Hotspot JDK in the JDK field.

Selecting Production Mode on this screen gives your environment a higher degree of security, requiring a user name and password to deploy applications and to start the Administration Server.

Tip:

More information about the options on this screen, including the differences between development mode and production mode, can be found in Domain Mode and JDK in Creating WebLogic Domains Using the Configuration Wizard.

In production mode, a boot identity file can be created to bypass the need to provide a user name and password when starting the Administration Server. See Creating the boot.properties File.

Task 6   Selecting Advanced Configuration

To complete domain configuration for the topology, select the following options on the Advanced Configuration screen:

  • Administration Server

    This is required to properly configure the listen address of the Administration Server.

  • Node Manager

    This is required to configure Node Manager.

  • Topology

    This is required to add, delete, or modify the Settings for Server Templates, Managed Servers, Clusters, Virtual Targets, and Coherence.

Note:

When using the Advanced Configuration screen in the Configuration Wizard:

  • If any of the above options are not available on the screen, then return to the Templates screen, and be sure you selected the required templates for this topology.

  • Do not select the Domain Frontend Host Capture advanced configuration option. You will later configure the frontend host property for specific clusters, rather than for the domain.

Task 7   Configuring the Administration Server Listen Address

On the Administration Server screen:

  1. In the Server Name field, retain the default value - AdminServer.

  2. In the Listen Address field, enter the virtual host name that corresponds to the VIP of the ADMINVHN that you procured in Procuring Resources for an Enterprise Deployment and enabled in Preparing the Host Computers for an Enterprise Deployment.

    For more information on the reasons for using the ADMINVHN virtual host, see Reserving the Required IP Addresses for an Enterprise Deployment.

  3. In the Listen Port field, enter the port number to access the administration server. This guide recommends you to use the default port 7102 for Access.

    Leave the other fields at their default values. In particular, be sure that no server groups are assigned to the Administration Server.

Task 8   Configuring Node Manager

Select Per Domain Default Location as the Node Manager type, then specify the Node Manager credentials you will use to connect to the Node Manager.

Tip:

For more information about the options on this screen, see Node Manager in Creating WebLogic Domains Using the Configuration Wizard.

For more information about per domain and per host Node Manager implementations, see About the Node Manager Configuration in a Typical Enterprise Deployment.

For information about Node Manager configurations, see Configuring Node Manager on Multiple Machines in Administering Node Manager for Oracle WebLogic Server.

Task 9   Configuring Managed Servers

Do not create any Managed Servers.

Click Next.

Task 10   Configuring a Cluster

Do not create any cluster.

Click Next.

Task 11   Assigning Server Templates

Click Next to proceed to the next screen.

Task 12   Configuring Coherence Clusters

Use the Coherence Clusters screen to configure the Coherence cluster that is automatically added to the domain.

In the Cluster Listen Port, enter a unique value for this domain..

Note:

For Coherence licensing information, Oracle Coherence Products in Oracle Fusion Middleware Licensing Information User Manual.

Task 13   Creating Machines

Use the Machines screen to create new machines in the domain. A machine is required in order for the Node Manager to be able to start and stop the servers.

You must create a machine even if your topology contains just the Administration Server. To do this:

  1. On the Unix Machines tab, click the Add button.

  2. Enter the name and the Node Manager listen address for each of the machines.

  3. Verify the port in the Node Manager Listen Port field.

The port number 5556, shown in this example, may be referenced by other examples in the documentation. Replace this port number with your own port number as needed.

Name Node Manager Listen Address Node Manager Listen Port

ADMINHOST

Enter the value of the OTDADMINVHN variable.

5556

WEBHOST1

The value of the WEBHOST1 host name variable. For example, WEBHOST1.example.com.

5556

WEBHOST2

The value of the WEBHOST2 host name variable. For example, WEBHOST2.example.com.

5556

Tip:

More information about the options on this screen can be found in Machines in Creating WebLogic Domains Using the Configuration Wizard.

If you are configuring a node manager per domain then the node manager listen port must be unique to that domain.

Click Next to proceed.

Task 14   Assigning Servers to Machines

Use the Assign Servers to Machines screen to assign any statically defined managed servers to the appropriate machines. Servers that are part of a dynamic cluster will be assigned to the calculated machine names automatically.

The Assign Servers to Machines screen is similar to the Assign Managed Servers to Clusters screen. Select the target machine in the Machines column, select the server name in the left column, and click the right arrow to assign the server to the appropriate machine.

Use this screen to assign AdminServer to the ADMINHOST machine.

Tip:

More information about the options on this screen can be found in Assign Servers to Machines in Creating WebLogic Domains Using the Configuration Wizard.

Task 15   Creating Virtual Targets

Click Next.

Task 16   Creating Partitions

Click Next.

Task 17   Reviewing Your Configuration Specifications and Configuring the Domain

The Configuration Summary screen contains the detailed configuration information for the domain you are about to create. Review the details of each item on the screen and verify that the information is correct.

You can go back to any previous screen if you need to make any changes, either by using the Back button or by selecting the screen in the navigation pane.

Domain creation will not begin until you click Create.

Tip:

More information about the options on this screen can be found in Configuration Summary in Creating WebLogic Domains Using the Configuration Wizard.

Task 18   Writing Down Your Domain Home and Administration Server URL

The Configuration Success screen will show the following items about the domain you just configured:

  • Domain Location

  • Administration Server URL

You must make a note of both items as you will need them later; the domain location is needed to access the scripts used to start the Administration Server.

Click Finish to dismiss the Configuration Wizard.

Configuring the Node Manager and Starting the Servers

After the domain is created and the node manager is configured, you can then configure the additional domain directories and start the Administration Server and the Managed Servers.

Starting the Node Manager in the Administration Server Domain Home

Use these steps to start the per-domain Node Manager for the IAD_ASERVER_HOME domain directory.

  1. Verify that the listen address in the nodemanager.properties file is set correctly.
    1. Open the nodemanager.properties file for editing:
      vi IAD_ASERVER_HOME/nodemanager/nodemanager.properties
    2. Make sure the ListenAddress property is set to the value of the ADMINVHN virtual IP address.
    3. Make sure that QuitEnabled is set to ‘true’. If this line is not present in the nodemanager.properties file, add the following line:
      QuitEnabled=true
  2. Change to the following directory:
    cd IAD_ASERVER_HOME/bin
  3. Start the Node Manager by entering the following command:
    nohup ./startNodeManager.sh > IAD_ASERVER_HOME/nodemanager/nodemanager.out 2>&1 &

    For more information about additional Node Manager configuration options, see Administering Node Manager for Oracle WebLogic Server.

Creating the boot.properties File

You must create a boot.properties if you want to start the Administrator Server without being prompted for the Administrator Server credentials. This step is required in an enterprise deployment. When you start the Administration Server, the credentials that you enter in this file are encrypted.

To create a boot.properties file for the Administration Server:

  1. Create the following directory structure:
    mkdir -p IAD_ASERVER_HOME/servers/AdminServer/security
  2. In a text editor, create a file called boot.properties in the security directory that you created in the previous step, and enter the Administration Server credentials that you defined when you ran the Configuration Wizard to create the domain:
    username=adminuser
    password=password

    Note:

    When you start the Administration Server, the username and password entries in the file are encrypted.

    For security reasons, minimize the amount of time the entries in the file are left unencrypted; after you edit the file, you should start the server as soon as possible so that the entries are encrypted.

  3. Save the file and close the editor.

Disabling the Derby Database

Disable the embedded Derby database, which is a file-based database, packaged with Oracle WebLogic Server. The Derby database is used primarily for development environments. As a result, you must disable it when you are configuring a production-ready enterprise deployment environment; otherwise, the Derby database process starts automatically when you start the Managed Servers.
To disable the Derby database:
  1. Navigate to the following directory in the Oracle home:
    cd WL_HOME/common/derby/lib
  2. Rename the Derby library jar file:
    mv derby.jar disable_derby.jar
  3. If each host uses a separate file system, repeat steps 1 and 2 on each host.

Starting the Administration Server Using the Node Manager

After you have configured the domain and configured the Node Manager, you can start the Administration Server by using the Node Manager. In an enterprise deployment, the Node Manager is used to start and stop the Administration Server and all the Managed Servers in the domain.

To start the Administration Server by using the Node Manager:

  1. Start the WebLogic Scripting Tool (WLST):
    cd ORACLE_COMMON_HOME/common/bin
    ./wlst.sh
  2. Connect to Node Manager by using the Node Manager credentials:
    wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
                'ADMINVHN','5556','domain_name',
                'IAD_ASERVER_HOME')

    Note:

    This user name and password are used only to authenticate connections between Node Manager and clients. They are independent of the server administrator ID and password and are stored in the nm_password.properties file located in the following directory:

    IAD_ASERVER_HOME/config/nodemanager
  3. Start the Administration Server:
    nmStart('AdminServer')
    

    Note:

    When you start the Administration Server, it attempts to connect to Oracle Web Services Manager for WebServices policies. It is expected that the WSM-PM Managed Servers are not yet started, and so, the following message appears in the Administration Server log:

    <Warning><oracle.wsm.resources.policymanager>
    <WSM-02141><Unable to connect to the policy access service due to Oracle WSM policy manager host server being down.>
  4. Exit WLST:
    exit()

Validating the Administration Server

Before you proceed with the configuration steps, validate that the Administration Server has started successfully by making sure that you have access to the Oracle WebLogic Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control; both of these are installed and configured on the Administration Servers.

To navigate to Fusion Middleware Control, enter the following URL, and log in with the Oracle WebLogic Server administrator credentials:

http://IGDADMINVHN.example.com:7101/console

To navigate to the Oracle WebLogic Server Administration Console, enter the following URL, and log in with the same administration credentials:

http://IGDADMINVHN.example.com:7101/em

Propagating the Domain and Starting the Node Manager on the Web Tier Hosts

After you have installed Oracle Traffic Director on the application tier hosts and you have extended the domain with Oracle Traffic Director system components, you can then copy the domain configuration to the hosts on the web tier and configure the Node Manager.

Packing Up the Domain on the Application Tier

Use the following steps to create a template JAR file that contains the domain configuration information:

  1. Log in to APPHOST1, and run the pack command to create a template JAR file as follows:
    cd ORACLE_COMMON_HOME/common/bin
     
    ./pack.sh -managed=true \ 
              -domain=ASERVER_HOME \
              -template=full_path/extend_otd_template.jar\
              -template_name=extend_otd_template
    

    In this example:

    • Replace ASERVER_HOME with the actual path to the domain directory you created on the shared storage device.

    • Replace full_path with the complete path to the directory where you want the template jar file saved.

    • extend_otd_template.jar is a sample name for the JAR file that you are creating, which contains the domain configuration files, including the configuration files for the Oracle HTTP Server instances.

    • extend_otd_template is the name assigned to the domain template file.

  2. Make a note of the location of the template JAR file that you just created with the pack command.

    Tip:

    For more information about the pack and unpack commands, see Overview of the Pack and Unpack Commands in Creating Templates and Domains Using the Pack and Unpack Commands.

  3. Copy the template JAR file to a location available to the web tier hosts.

Unpacking the Domain Configuration on the Web Tier Hosts

Use the following procedure to copy the Oracle Traffic Directory domain configuration information to the Web Tier hosts.
  1. Log in to WEBHOST1.
  2. If you haven't already, create the recommended directory structure for the Managed Server domain on the WEBHOST1 storage device.
  3. Make sure the template JAR file you created with the pack command is accessible to WEBHOST1.
  4. Run the unpack command to unpack the template in the domain directory onto the local storage, as follows:
    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=MSERVER_HOME
                -overwrite_domain=true
                -template=complete_path/extend_otd_template.jar 
                -log_priority=DEBUG
                -log=/tmp/unpack.log
                -app_dir=WT_APPLICATION_HOME
    

    In this example:

    • Replace MSERVER_HOME with the complete path to the domain home to be created on the local storage disk. This is the location where the copy of the domain will be unpacked.

    • Replace complete_path with the complete path to the domain template jar file that you created when you ran the pack command to pack up the domain on the shared storage device.

    • Replace WT_APPLICATION_HOME with the complete path to the Application directory for the domain on local storage. See File System and Directory Variables Used in This Guide.

    Tip:

    For more information about the pack and unpack commands, see Overview of the Pack and Unpack Commands in Creating Templates and Domains Using the Pack and Unpack Commands.

  5. Change directory to the newly created MSERVER_HOME directory and verify that the domain configuration files were copied to the correct location on the WEBHOST1 local storage device.
  6. Repeat the unpack steps on WEBHOST2.

Configuring and Starting Node Manager on the Web Tier Hosts

Oracle Traffic Director runs alone in the Web tier hosts, and therefore, it is not necessary to create a per node Node Manager for each Web tier host. Instead, Oracle Traffic Director nodes use the default per domain Node Manager.

Oracle also recommends that you use the SSL Node Manager in the DMZ for security reasons.

To create the required Node Manager configuration and start Node Manager on each Web tier host, follow these steps. Repeat for each Web tier host.

  1. Navigate to WEB_DOMAIN_HOME/nodemanager.
  2. Edit the nodemanager.properties file and check the following properties:
    • ListenAddress = WEBHOSTn

  3. Change the directory to WEB_DOMAIN_HOME/bin .
  4. Run the following command to start Node Manager:
    nohup ./startNodeManager.sh > $WEB_DOMAIN_HOME/nodemanager/nodemanager.out 2>&1 &

Creating an Oracle Traffic Director Configuration

An Oracle Traffic Director configuration is a collection of metadata that you can use to instantiate Oracle Traffic Director. Oracle Traffic Director reads the configuration when a server instance starts on the web tier hosts and while processing client requests.

To create a configuration:

  1. Log in to Fusion Middleware Control for the application tier domain.
  2. From the WebLogic Domain menu, select Administration > OTD Configurations.
  3. From the Change Center menu (the lock icon), select Lock & Edit.
  4. Click Create.
    The New Configuration Wizard screen is displayed.
  5. Specify a name for the configuration, and an origin server type.
    For example, specify edgconfig as the configuration name, select HTTP as the Origin Server Type, and then click Next.
  6. In the Create Configuration: Listener screen, specify the port you wish the listener to use (WEB_HTTP_PORT), adjust any remaining values as appropriate, and click Next.
  7. In the Create Configuration: Origin Server Pool screen, click Next.
    You can later add additional origin servers and origin-server pools for the products that you are configuring in the enterprise deployment.
  8. In the Create Configuration: Deployment screen, select WEBHOST1 and WEBHOST2 as WebLogic Server machines for deployment. Click Next.
  9. Review the screen with the configuration definitions and click Create Configuration to create the configuration.
  10. From the Change Center menu (the lock icon), select Activate Changes to make the changes effective.

Note:

The following are automatically created after you create the configuration:

  • One virtual servers named edgconfig.

  • One instance on each of the hosts that are defined for the configuration.

Starting the Oracle Traffic Director Default Instance

You can use the Oracle Traffic Director configuration to create instances of Oracle Traffic Director servers on one or more administration nodes.

To start the Oracle Traffic Director default instance:

  1. Log in to Fusion Middleware Control for Traffic Director.
  2. From the WebLogic Domain, select Administration > OTD Configurations.
    A list of the available configurations is displayed.
  3. Select the configuration that you created earlier. For more information, see Creating an Oracle Traffic Director Configuration.
  4. From the Traffic Director Configuration menu, select Administration > Instances.
    The Instances page is displayed.
  5. Select the instance from the list of instances, click Start, and then verify that the operation completes successfully.

Defining Oracle Traffic Director Virtual Servers for an Enterprise Deployment

By default, when you created the configuration, a default virtual server for HTTP access was created, named edg_config. However, each enterprise deployment uses additional Oracle Traffic Director virtual servers and origin-server pools for specific purposes. For example, each time you extend the domain with a new Fusion Middleware product, there are additional virtual servers that must to be defined.

For a complete list of the virtual servers required for the enterprise deployment, see Summary of the Virtual Servers Required for an Enterprise Deployment

For general information about creating Oracle Traffic Director virtual servers, see Creating a Virtual Server in the Fusion Middleware Administering Oracle Traffic Director.

To create and configure virtual servers, you must create the origin server pools and then define the virtual servers.

Creating the Required Origin Server Pools

Table 17-1 lists the origin server pools required for an enterprise deployment. To create the required origin server pools by using Fusion Middleware Control:
  1. Log in to Fusion Middleware Control.
  2. From the WebLogic Domain menu, select Administration > OTD Configurations.
    A list of the available configurations is displayed.
  3. Select the configuration for which you want to add the Origin-Server Pool.
  4. From the Traffic Director Configuration menu, select Administration > Origin Server Pools.
    The Server Pools page is displayed. It displays a list of the server pools (HTTP/Sand TCP server pools) defined for the configuration.
  5. From the Change Center menu (the lock icon), select Lock and Edit.
  6. Under HTTP/S Origin Server Pools, click Create to create any required HTTP origin-server pools.
  7. Under Origin Server Information, specify the address of the servers that are associated with the origin server pool.
  8. Click OK on the right-top of the screen.

    You are returned to the Origin Pools page.

  9. Under TCP Origin Server Pools, click Create to create any TCP origin-server pools.
  10. Under Origin Server Information, specify the address of the servers that are associated with origin server pool.
  11. Click OK on the right-top of the screen.

    You are returned to the Origin Pools page.

  12. Select Activate Changes in the submenu that shows up when you click the lock icon on the upper-right corner of the screen.
    The details of the origin-server pool that you just created are displayed on the Origin-Server Pools page.
  13. Repeat the steps for any additional origin server pools required for the enterprise deployment.

    After the origin-server pool is created, the Results screen of the New Origin-Server Pool wizard displays a message confirming successful creation of the origin-server pool.

  14. Select Activate Changes in the submenu that shows up when you click the lock icon on the upper-right corner of the screen.

Table 17-1 Origin-Server Pools

Product Origin-Server Pool Origin Server Type Origin Servers Port

Access Manager

iadadmin-pool

HTTP

IADADMINVHN.example.com

7001 (IAD_WLS_PORT)

oam-pool

HTTP

OAMHOST1.example.com, OAMHOST2.example.com

14100 (OAM_PORT)

ama-pool

HTTP

OAMHOST1.example.com, OAMHOST2.example.com

14150 (IAMADM_PORT)

Identity Governance

igdadmin-pool

HTTP

IGDADMINVHN.example.com

7101 (IGD_WLS_PORT)

oim-pool

HTTP

OIMHOST1.example.com, OIMHOST2.example.com

14000 (OIM_PORT)

soa-pool

HTTP

OIMHOST1.example.com, OIMHOST2.example.com

8001 (SOA_PORT)

Directory

ldap-pool

TCP

LDAPHOST1.example.com, LDAPHOST2.example.com

1389 (LDAP_PORT)

Note:

  • *7022 is the default port that is used for the SFTP listeners on the Managed File Transfer servers.

  • Configure the port numbers appropriately, as assigned for your static or dynamic cluster. Dynamic clusters with the Calculate Listen Port option selected will have incremental port numbers for each dynamic managed server that you create.

Creating the Required Virtual Servers

Table 17-2 lists the virtual servers that are required for an enterprise deployment. To create a virtual server do the following:
  1. Log in to Fusion Middleware Control.
  2. From the WebLogic Domain menu, select Administration > OTD Configurations.
    A list of the available configurations is displayed.
  3. Select the configuration for which you want to create a virtual server.
  4. From the Traffic Director Configuration menu, select Administration > virtual server.
  5. From the Change Center menu (the lock icon), select Lock and Edit.
  6. Under Virtual Servers, click Create.
    The New Virtual Server wizard starts.
  7. Enter the name of the virtual server.
  8. Select Select listeners for this virtual server and click Next.
  9. Select the listener that was created with the configuration and accept other defaults. Click Next.
  10. In the Create Virtual Server: Origin Server Pool screen, select Select a pool of origin servers.
  11. For each of the Virtual Servers, select the pool as indicated in Table 17-2.

    When you have finished providing the required information, click Next.

  12. Review the data in the Create Virtual Server: Review screen, and click Create Virtual Server.
    After the virtual server is created, the Results screen of the New Virtual Server wizard displays a message confirming a successful creation of the virtual server.
  13. Select Activate Changes in the submenu that shows up when you click the lock icon on the upper-right corner of the screen.

Table 17-2 Virtual Server Information

Product Virtual Server Name Host Served Pool

Access Manager

login.example.com

login.example.com

oam-pool

iadadmin.example.com

iadadmin.example.com

iadadmin-pool

Identity Governance

prov.example.com

prov.example.com

soa-pool

igdadmin.example.com

igdadmin.example.com

igdadmin-pool

igdinternal.example.com

igdinternal.example.com

oim-pool

Note:

*WEBHOST1-V1 and WEBHOST2-V1 are the VIPS that are used for the corresponding Oracle Traffic Director failover groups.

Creating the Required Virtual Server Routes

Some of the Oracle Fusion Middleware products require specific URIs defined, so specific requests can be routed to the correct Managed Servers and with the correct protocol. In Oracle Traffic Director, you can define these URIs by creating specific routes for the selected virtual servers that you have created.
  1. Review the information available in Table 17-3.

    This topic lists all the routes required for each of the specific Oracle Fusion Middleware products. For the products that you are deploying, note the virtual server, then name of the route, the list of URIs, and the origin server pool. You can use that information to create each required route.

  2. Log in to Fusion Middleware Control.
  3. From the WebLogic Domain menu, select Administration > OTD Configurations.
    A list of the available configurations is displayed.
  4. Click the configuration for which you want to create a virtual server.
    The Traffic Director Configuration page appears.
  5. From the Traffic Director Configuration menu, select Administration > virtual server.
  6. Click the name of the virtual server that you want to edit.
  7. Select the Routes tab.
  8. From the Change Center menu (the lock icon), select Lock and Edit.
  9. Click Create.
    The Create Route page appears.
  10. In the Name field, enter a name for the Route.

    Refer to for the list of routes you need to create for each Fusion Middleware product.

  11. In the Condition field, click Edit Expression. The Edit Expression dialogue box is displayed.
  12. Click Edit Manually.
  13. Enter the following syntax to identify a specific URL to which the routing information will be assigned:
    $uri =~ '/context_string'

    For example:

    $uri =~ '/soa-infra'

    If you have to enter multiple URLs, then separate them with or. For example:

    $uri =~ '/soa-infra' or $uri=~'/inspection.wsil'

    Alternatively, you can click Create, and build the expression up via the wizard. For example:

    1. Select $uri in the Variables/Functions list.

    2. Select =~ in the Operator.

    3. Enter /context_string in the Value field.

    4. Click OK. Repeat for each of the conditions to be added. For subsequent conditions, you should also change the expression type to or.

  14. Click Validate to check the syntax of the expression. If it is correct, click OK to save the route conditions.
  15. From the Origin Server Pool drop-down menu, select the pool that is associated with this route.

    Requests that meet the conditions of this route are directed to the selected pool.

  16. If a route requires a named session cookie to be used, do the following
    1. Click on the newly created route.

    2. Expand the Advanced Settings.

    3. Set Sticky Cookie to the cookie name from Table 17-3.

    4. Set the Sticky URI parameter to the cookie name from Table 17-3.

Table 17-3 lists the virtual server routes (or URIs) that are required by the Fusion Middleware products. You can use this information as you create the required routes by using the Oracle Traffic Director management pages in Fusion Middleware Control.

Table 17-3 Routes and Conditions

Product Virtual Host Route Origin-Server Pool Conditions Cookie Name

Access Manager

iadadmin.example.com

default

iadadmin-pool

N/A

-

-

-

amaadmin-route

ama-pool

$uri=~'/access'

-

Identity Governance

igdadmin.example.com

default

igdadmin-pool

NA

-

-

-

oim-admin-route

oim-pool

$uri =~ '/oim' or

-

-

-

-

-

$uri =~ '/identity' or

-

-

-

-

-

$uri =~ '/sysadmin' or

-

-

-

-

-

$uri =~ '/xlWebApp' or

-

-

-

-

-

$uri =~ '/iam' or

-

-

-

-

-

$uri =~ '/wsm-pm' or

-

-

-

-

-

$uri =~ '/admin' or

-

-

-

-

-

$uri =~ '/OIGUI' or

-

-

-

-

-

$uri =~ '/FacadeWebApp' or

-

-

-

-

-

$uri =~ 'SchedulerService-web' or

-

-

-

-

-

$uri =~ '/Nexaweb'

-

Access Manager

login.example.com

default

origin-server-pool-1

N/A

OAM_JSESSIONID

Identity Governance

prov.example.com

default

soa_pool

N/A

oimjsessionid

-

-

oim-prov-route

oim-pool

$uri =~ '/identity' or

oimjsessionid

-

-

-

-

$uri =~ '/iam' or

-

-

-

-

-

$uri =~ '/FacadeWebApp' or

-

-

-

-

-

$uri =~ '/OIGUI' or

-

-

-

-

-

$uri =~ '/xlWebApp' or

-

-

-

-

-

$uri =~ '/HTTPClnt' or

-

-

-

-

-

$uri =~ '/reqsvc'

-

Identity Governance

igdinternal.example.com

default

oim-pool

N/A

oimjsessionid

-

-

soa-igdinternal-route

soa-pool

$uri =~ '/soa-infra' or

oimjsessionid

-

-

-

-

$uri =~ '/sodcheck' or

-

-

-

-

-

$uri =~ '/integration' or

-

-

-

-

-

$uri =~ '/soa' or

-

-

-

-

-

$uri =~ '/ucs'

-

-

-

-

usm-pool to

$uri =~'/sdpmessaging'

-

Enabling SSL Passthrough

In the enterprise deployment, Topology SSL is terminated at the hardware load balancer and passed through to Oracle Traffic Director by using the HTTP protocol.

Oracle Traffic Director requires extra configuration steps to ensure that any application redirects occur correctly.

To ensure that application redirects occur correctly, perform the following steps for each route that is associated with a virtual server where SSL is used and terminated at LBR, which are the following virtual servers:

  • login.example.com

  • prov.example.com

  1. Log in to Fusion Middleware Control.
  2. From the WebLogic Domain menu, select Administration > OTD Configurations.
    A list of the available configurations is displayed.
  3. Click the configuration you want to change.
    The Traffic Director Configuration page appears.
  4. From the Traffic Director Configuration menu, select Administration > virtual server.
  5. Click the name of the virtual server that you want to edit.
  6. Select the Routes tab. From the list of the defined routes, click a route, for example, default-route.
  7. In the Route Properties screen, expand Advanced Settings.
  8. Remove any content in the box labeled Rewrite Headers.
  9. In the Parameters Forwarded to Origin Servers section, deselect the following:
    • Cipher

    • Key Size

    • SSL/TLS Session ID

    • Issuer DN

    • User DN

    • Certificate

    • Secret Key Size

    • SSL

  10. Click Apply.
  11. Repeat steps 8 and 9 for each route in the virtual server.
  12. After modifying all the routes in the virtual server, click Activate Changes.

Creating a TCP Proxy for an Enterprise Deployment

If you are going to use Oracle Traffic Director to distribute requests across your LDAP instances, you need to create a TCP Proxy. If you are using a regular load balancer, this is not required.

To create a TCP Proxy, do the following:
  1. Log in to Fusion Middleware Control. Click the WebLogic Domain button at the upper-left corner of the page.
  2. Select Administration > OTD Configurations.
    A list of the available configurations is displayed.
  3. Select the configuration for which you want to create a TCP Proxy.
  4. In the Common Tasks pane, click Traffic Director Configuration.
  5. Select Administration > TCP proxies.
  6. In the TCP Proxies table, click Lock & Edit, and then Create.
    The New TCP Proxy wizard starts. Table 17-4 lists the TCP proxies that are required for an enterprise deployment.
  7. Enter a name for the proxy without selecting FTP, and click Next.
  8. In the Create TCP Proxy: Listener screen, specify the name of the listener, the corresponding port, and * as address. Click Next.
  9. In the Create TCP Proxy: Origin Server Pool screen, select the corresponding pool that you created in the previous steps. Click Next.
  10. Review the next screen and click Create TCP Proxy.
  11. Select Activate Changes in the submenu that shows up when you click the lock icon on the upper-right corner of the screen.

Table 17-4 Summary of the TCP Proxies

Product TCP Proxy Name Origin Server Pool TCP Listener Name TCP Listener Port

LDAP

idstore.example.com

server oud-pool

idstore-listener

*:1389

Note:

1389 is your LDAP port. This is typically 1389 for OUD.

Creating a Failover Group for Virtual Hosts

A failover group ensures high availability of Oracle Traffic Director instances by combining two Oracle Traffic Director instances.

When a request is sent to one of the virtual hosts in the EDG, the front end load balancer redirects the request to the IP address that has been configured to load balance requests. This IP address is enabled on one of the OTD instances but it can be migrated to another OTD instance should a failure occur. You can combine two Oracle Traffic Director instances in a failover group represented by one or two virtual IP (VIP) addresses. You can do this by creating an active-passive failover group for the IP address. This failover group lists a primary and a number of secondary instances.

The following instructions explain how to create failover groups for the IP addresses associated with the different virtual servers in the configuration. The failover groups for the MFT OTD IP addresses are optional since the load balancer fails over requests between the two Oracle Traffic Director instances, but they provide faster failure detection and failover than the typical load balancer monitors.

For more information about creating failover groups or other high availability configurations for Oracle traffic Director, see Configuring Oracle Traffic Director for High Availability in the Administrator's Guide.

Creating Failover Groups

You can implement a highly available pair of Oracle Traffic Director instances by creating failover groups.

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.

  • Identify the Oracle Traffic Director 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 nodes that you select 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 are not 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.

If you are going to use OTD as a load balancer or gateway for the internal IPoIB interface in an Exalogic deployment, then you need to create all of the failover groups in the listed in the following table. If you are creating failover groups for failover detection, you need to create the ones on bond1 only.

Table 17-5 Failover Group Details

Virtual Host Router ID Network Prefix Primary Node Primary Network Interface Secondary Node Secondary Network Interface

idstore.example.com

50

19

Admin Node

bond0

WEBHOST2

bond0

iadinternal.example.com

52

19

WEBHOST2

bond0

Admin Node

bond0

igdinternal.example.com

53

19

Admin Node

bond0

WEBHOST2

bond0

webhost1vhn1.example.com

54

19

Admin Node

bond1

WEBHOST2

bond1

webhost2vhn1.example.com

55

19

WEBHOST2

bond1

Admin Node

bond1

Note:

  • The failover groups for the external virtual IP addresses are optional since the load balancer fails over requests between the two Oracle Traffic Director instances. However, they will provide faster failure detection and failover than the typical load balancer monitors.

  • The router ID is a unique number you assign to the routing. The number must be between 1 and 244.

    The Network Prefix is the subnet mask in the CIDR format.

    The primary node is the node where the Failover group is initially active.

    The Primary Network Interface is the interface on the host where the failover group is bound.

    The Secondary Node is the Node on which the failover group can be started if the Primary node is unavailable.

    The Secondary Network interface is the Network Interface used on the Secondary node.

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

  1. Log in to 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 Lock & Edit, and then click Create in the Active Passive Failover Groups tab.
  8. In the Failover Group Creation screen, enter the following
    • Virtual IP: Enter the floating hostname that is moved across nodes. This needs to map top a valid Virtual IP that can be enabled both in WEBHOST1 and WEBHOST2. Make sure this VIP is not yet enabled in the nodes.

    • Router ID: Enter a number from 1 to 255. The value must be unique across failover groups because this value is the identifier for the VRRP process that performs the IP failover.

    • Select the Primary and Backup Instance to host the VIP and enter the required network interfaces where the VIPs will be enabled.

    Note:

    Generally it is sufficient to leave Network Interface (NIC) at the default value of Auto Detect. If you leave the default, Oracle Traffic Director (OTD) determines which network interface card to use based on the IP address of the failover group. If, however, this is not easily derivable, for example, if you have not used a standard CIDR associated with the IP address, you may have to manually tell OTD the network interface to which the failover group should be attached.

    For example, if your internal IP address is 192.168.1.1, and it is associated with bond0, and uses a valid net mask (CIDR), and your IP address of the failover group is 192.168.50.1, OTD knows to use network interface bond0. If, however, OTD cannot determine the appropriate interface, you are required to specify it in this field.

    Oracle Traffic Director validates the information before creating the failover group.

    If you receive a validation error similar to the following, the IP Address you are trying to assign is incompatible with the current configuration of the network card. If you see this error you will have to choose a different IP Address/netmask:

    OTD-67322 The specified virtual IP 'x.x.x.x' cannot be bound to any of the network interfaces on the node 'hostname'. 
    The IP addresses bound to the node are [......] check if the specified virtual IP is in the proper subnet. 
    This error could also be caused if either the network interfaces on the node are not configured correctly or if the network prefix
    length is incorrect.
    
  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.

    • When you create a failover group you must run otd_startFailover on those machines as a root user. This is to manually start the failover. If this command is not executed, failover does not start and there is no high availability. For more information about otd_startFailover, see WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

      To run the otd_startFailover command, follow these steps:

      Start WLST as root or as a user with sudo rights.

      			[root@webhost1]# ./wlst.sh 
      			Initializing WebLogic Scripting Tool (WLST) ... 
      			Jython scans all the jar files it can find at first startup. Depending on the 
      			system, this process may take a few minutes to complete, and WLST may not 
      			return a prompt right away. 
      
      			wls:/offline> wls:/offline> props = {} 
      
      			wls:/offline> props['domain-home'] = 
      			'/u02/oracle/config/domains/mftedg_domain/' 
      
      			wls:/offline> props['instance'] ='otd_edgconfig_WEBHOST1' 
      
      			wls:/offline> otd_startFailover(props)

      Run the failover command in WEBHOST2 also. Use the WEBHOST2 instance name in this case. For example: props['instance'] ='otd_edgconfig_WEBHOST2’.

    • The operating system keepalived package is needed for otd_startFailover. This package is not bundled with all Linux distribution and it needs to manually installed on the operating system. Refer to your operating system for details and installation.