1 Getting Started with Oracle Traffic Director

Oracle Traffic Director is a fast, reliable, and scalable layer-7 software load balancer. You can set up Oracle Traffic Director to serve as the reliable entry point for all HTTP, HTTPS and TCP traffic to application servers and web servers in the back end. Oracle Traffic Director distributes the requests that it receives from clients to servers in the back end based on the specified load-balancing algorithm, routes the requests based on specified rules, caches frequently accessed data, prioritizes traffic, and controls the quality of service.The architecture of Oracle Traffic Director enables it to handle large volumes of application traffic with low latency. The product is optimized for use in Oracle Exalogic Elastic Cloud and Oracle SuperCluster. It can communicate with servers in the back end over Exalogic's InfiniBand fabric. For more information about Exalogic, see the Oracle Exalogic Elastic Cloud documentation, http://docs.oracle.com/cd/E18476_01/index.htm. Oracle Traffic Director is also certified with various Fusion Middleware products. Oracle Traffic Director is easy to install, configure, and use. It includes a simple, web browser based graphical user interface (using Oracle Enterprise Manager) as well as robust Command Line Interface using Oracle WebLogic WLST.For high availability, you can set up pairs of Oracle Traffic Director instances for either active-passive or active-active failover. As the volume of traffic to your network grows, you can easily scale the environment by reconfiguring Oracle Traffic Director with additional back-end servers to which it can route requests.Depending on the needs of your IT environment, you can configure Oracle Traffic Director to apply multiple, complex rules when distributing requests to the back-end servers and when forwarding responses to clients.

This chapter provides information to help you understand and get started with Oracle Traffic Director. It contains the following sections:

1.1 New Features in 12c (12.2.1)

This section describes features that have been added to the current release of Oracle Traffic Director:

1.1.1 Weblogic Management Framework

Previous releases (11g) of Oracle Traffic Director did not require databases; this release supports database-based installation, or Restricted JRF-based installation. For more information on installation prerequisites, see Overview of Installing Oracle Traffic Director in Oracle Fusion Middleware Installing Oracle Traffic Director. This release of Oracle Traffic Director introduces the WebLogic Management Framework, a set of tools that leverage Oracle WebLogic 12.2.1 interfaces to provide a simple, consistent and distributed framework for managing Oracle. For more information on the WebLogic Management Framework, see What is the WebLogic Management Framework in Understanding Oracle Fusion Middleware.

OTD functionality is the same for both Database and Restricted-JRF mode based installations. The WebLogic Management Framework introduces these enhancements:

  • Configuration is a post-installation task that begins with creating a domain, primarily by using Configuration Wizard. For more information, see Installing and Configuring Oracle Traffic Director.

  • WLST: You can create, configure, and manage WebLogic domains using WLST, command-line utilities, and Fusion Middleware Control interchangeably. The method that you choose depends on whether you prefer using a graphical or command-line interface, and whether you can automate your tasks by using a script.

  • Oracle Traffic Director configurations and instances are part of the WebLogic domain.

1.1.2 WLST Commands

The command line interface in Oracle Traffic Director 12.2.1 is WLST (Weblogic Scripting Tool). A number of WLST commands are used to configure and administer Oracle Traffic Director.

There are two types of WLST commands:

  • Online Command

  • Offline Command

Most of WLS commands are ”only online commands” which requires connection to the WLS server. Some of them are ”only offline commands” which does not required any connection to the WLS server. Some of them are both online and offline those can be invoked in both the ways.

All the commands configured through WLST, should be activated.

For more information see Oracle Fusion Middleware Infrastructure Security WLST Command Reference.

1.1.3 Multi-tenancy Support

Web Logic Server 12.2.1 introduces a new concept Multi-tenancy, It provides a sharable infrastructure for use by multiple organizations that means, It allows one domain to support multiple tenants at a time, where a dedicated domain is not required.

Multi-tenancy provides resource isolation within a domain partition, an administrative and runtime partition of a WebLogic domain that is dedicated to running application instances and related resources for a tenant.

In a typical deployment scenario Web Logic Server will be front ended by Oracle Traffic Director, so whenever partition related tasks are performed from Web Logic Server side Oracle Traffic Director need to be configured appropriately, so that it can successfully front end the Web Logic Partition.

With the Multi-tenancy support, Oracle Traffic Director will be configured automatically with out any explicit user action. For more information see, Configuring Oracle Traffic Director and End-to-End Life Cycle Management.

For more information, see Oracle Fusion Middleware Using WebLogic Server Multitenant.

1.1.4 Monitoring Enhancements

The monitoring subsystem, it gives the detailed information on the state of runtime components/processes which used to track the performance bottlenecks, to tune the system for optimal performance, to aid capacity planning, to predict failures, to do root cause analysis in case of failures. In some situations it is used to make sure that everything is functioning as per the requirements.

For more information, see Chapter 12, "Monitoring Oracle Traffic Director Instances".

1.1.5 Oracle Fusion Middleware T2P Utility for Oracle Traffic Director

The Oracle Fusion Middleware T2P utility allows you to move a Fusion Middleware environment from test to production with customization specific to the production environment. In 12.2.1, this utility supports Oracle Traffic Director.

For more information, see Appendix D, "Oracle Fusion Middleware T2P Utility for Oracle Traffic Director".

1.1.6 External Health Check Executable

Oracle Traffic Director now supports a generic health check hook-up mechanism, so that customers can write their own health check programs/scripts to monitor the health of specific origin servers. An external executable is especially useful for a protocol-level health check monitor for the origin servers.

For more information, see Section 5.7.1.1, "Configuring Health-Check Settings to Use an External Executable" in Chapter 13, "Configuring Oracle Traffic Director for High Availability.".

1.1.7 Queueing with Request Limiting

Overflow connection queuing is a new feature added in 12.2.1, The requests that overflow are queued and are de-queued as per request priority. The request and response bandwidth can be controlled by this feature.

For more information, see Section 14.3, "Tuning the Thread Pool and Connection Queue".

1.1.8 Origin Server Traffic Control

The user can set limit on reusing same origin server connection for multiple requests by the keep-alive option. Bandwidth can be limited and controlled for each origin server. This feature can be used to control the HTTP origin server pools, but, not the TCP origin server pools.

1.1.9 Origin Server and Origin Server Pool Maintenance

By using this feature in 12.2.1, an origin server or origin server pool can be marked for maintenance, all the new connections and sessions to such an origin server or origin server pool are drained further.

A single pool can have a multiple partitions, but only one of those partitions may be pushed to a new pool. All the old requests must directed to the old pool until a time-out expires or the admin take some action.

All the Scaling up and scaling down process of origin servers need not require any functionality change on the Oracle Traffic Director. So Oracle Traffic Director admin will update the origin server as ”disabled”. All on-going requests will still be processed by the disabled origin server. This is not just the runtime change but also the configuration will be updated to reflect the new state of the origin server.

1.1.10 Prioritized Backend Connection Management

Oracle Traffic Director supports the prioritized requests to the back end server, for critical application requests. With this feature, requests with higher priority are de-queued before the ones with lower priority.

1.1.11 Forward Proxy Support in Origin Server Pools

Oracle Traffic Director always in contact to it's configured origin servers in a direct manner. The HTTP forward proxy server can be optionally associated with an origin server pool so that all member origin servers (of said pool) will be communicated with via the configured HTTP forward proxy server.

For more information, see Chapter 5, "Managing Origin-Server Pools".

1.1.12 NZ Security Library

The security library used in 12.2.1 is NZ and the cert/key store is Oracle Wallet. NSS is no longer supported.

1.1.13 ModSecurity Upgrade

In the Oracle Traffic Director 12c, we are upgrading the ModSecurity code used in WAF from version 2.6.7 to 2.8.0.

1.2 Features of Oracle Traffic Director

Oracle Traffic Director provides the following features:

  • Advanced methods for load distribution

    You can configure Oracle Traffic Director to distribute client requests to servers in the back end by using one of the following algorithms:

    • Round robin

    • Least connection count

    • Least response time

    • IP Hash

    • Weighted round robin

    • Weighted least connection count

  • Flexible routing and load control on back-end servers

    • Request-based routing

      Oracle Traffic Director can be configured to route HTTP(S) requests to specific servers in the back end based on information in the request URI: pattern, query string, domain, source and destination IP addresses, and so on.

    • Content-based routing

      Oracle Traffic Director can be configured to route HTTP(S) requests to specific servers in the back end based on contents within a request. This way, web service requests such as XML or JSON can be easily routed to specific origin servers based on specific elements within the body content. Content-based routing is enabled by default.

    • Request rate acceleration

      Administrators can configure the rate at which Oracle Traffic Director increases the load (number of requests) for specific servers in the back end. By using this feature, administrators can allow a server that has just been added to the pool, or has restarted, to perform startup tasks such as loading data and allocating system resources.

    • Connection limiting

      Oracle Traffic Director can be configured to limit the number of concurrent connections to a server in the back end. When the configured connection limit for a server is reached, further requests that require new connections are not sent to that server.

  • Controlling the request load and quality of service

    • Request rate limiting

      Oracle Traffic Director can be set up to limit the rate of incoming requests from specific clients and for specific types of requests. This feature enables administrators to optimize the utilization of the available bandwidth, guarantee a certain level of quality of service, and prevent denial-of-service (DoS) attacks.

    • Quality of service tuning

      To ensure equitable utilization of the available network resources for incoming requests, you can configure Oracle Traffic Director virtual servers to limit the maximum number of concurrent connections to clients and the maximum speed at which data can be transferred to clients.

  • Support for WebSocket connections

    Oracle Traffic Director handles WebSocket connections by default. WebSocket connections are long-lived and allow support for live content, games in real-time, video chatting, and so on. In addition, Oracle Traffic Director can be configured to ensure that only those clients that strictly adhere to R FC 6455 are allowed. For more information, see the section Section 7.4, "Configuring Routes" and the WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

  • Integration with Oracle Fusion Middleware

    • Oracle Traffic Director is designed to recognize and handle headers that are part of requests to, and responses from, Oracle WebLogic Server managed servers in the back end.

    • When an Oracle Traffic Director instance is configured to distribute client requests to clustered Oracle WebLogic Server managed servers, Oracle Traffic Director automatically detects changes in the cluster—such as the removal or addition of managed servers, and considers such changes while routing requests.

    • Patches that Oracle delivers for the Oracle Traffic Director software can be applied by using OPatch, a Java-based utility, which is the standard method for applying patches to Oracle Fusion Middleware products.

  • Easy-to-use administration interfaces

    Administrators can use either a graphical user interface or a command-line interface to administer Oracle Traffic Director instances.

  • Security

    Oracle Traffic Director enables and enhances security for your IT infrastructure in the following ways:

    • Reverse proxy

      By serving as an intermediary between clients outside the network and servers in the back end, Oracle Traffic Director masks the names of servers in the back end and provides a single point at which you can track access to critical data and applications hosted by multiple servers in the back end.

    • Support for SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2

      To secure data during transmission and to ensure that only authorized users access the servers in the back end, you can configure SSL/TLS-enabled HTTP and TCP listeners for Oracle Traffic Director instances.

      You can either use digital certificates issued by commercial CAs such as VeriSign or generate RSA- and Elliptic Curve Cryptography (ECC)-type self-signed certificates with key sizes of up to 4096 bits by using Fusion Middleware Control or the WLST.

    • Web Application Firewalls

      Web application Firewalls enable you to apply a set of rules to an HTTP request, which are useful for preventing common attacks such as Cross-site Scripting (XSS) and SQL Injection. The Web Application Firewall module for Oracle Traffic Director supports open source ModSecurity 2.8.

    • Single Sign-On with WebGate

      WebGate enables single sign-on (SSO) for Oracle Traffic Director. WebGate examines incoming requests and determines whether the requested resource is protected, and if so, retrieves the session information for the user. Through WebGate, Oracle Traffic Director becomes an SSO partner application enabled to use SSO to authenticate users, obtain their identity by using Oracle Single Sign-On, and to make user identities available to web applications accessed through Oracle Traffic Director.

  • High availability

    Oracle Traffic Director provides high availability for your enterprise applications and services through the following mechanisms:

    • Health checks for the back end

      If a server in the back end is no longer available or is fully loaded, Oracle Traffic Director detects this situation automatically through periodic health checks and stops sending client requests to that server. When the failed server becomes available again, Oracle Traffic Director detects this automatically and resumes sending requests to the server.

    • Backup servers in the back end

      When setting up server pools for an Oracle Traffic Director instance, you can designate a few servers in the back end as backup servers. Oracle Traffic Director sends requests to the backup servers only when none of the primary servers is available. This feature ensures continued availability even when some servers in the back end fail.

    • Failover for load balancing

      Two Oracle Traffic Director instances can be deployed in an active-passive or active-active configuration. If the primary Oracle Traffic Director instance fails, the backup instance takes over.

    • Dynamic reconfiguration

      Most configuration changes to Oracle Traffic Director instances can be deployed dynamically, without restarting the instances and without affecting requests that are being processed.

  • Monitoring statistics

    Administrators can monitor a wide range of statistics pertaining to the performance of Oracle Traffic Director instances through several methods: Fusion Middleware Control, the command-line interface, and a report in XML format.

  • High performance

    • SSL/TLS offloading

      Oracle Traffic Director can be configured as the SSL/TLS termination point for HTTP/S and TCP requests. This reduces the processing of overhead on the servers in the back end.

    • Content caching

      Oracle Traffic Director can be configured to cache (in its process memory) content that it receives from origin servers. By caching content, Oracle Traffic Director helps reduce the load on servers in the back end and helps improve performance for clients.

    • HTTP compression

      Administrators can configure Oracle Traffic Director instances to compress the data received from servers in the back end and forward the compressed content to the requesting clients. This feature improves the response time for clients connected on slow connections.

  • Virtualization-enabled solution

    Oracle Traffic Director can be deployed as a virtual appliance on cloud and virtual platforms.

    After deploying Oracle Traffic Director as a physical application, you can create a virtual appliance from an Oracle Traffic Director instance or create an assembly containing multiple such appliances. You can then deploy the appliance or assembly on the Oracle Virtual Machine hypervisor. To enable such a deployment, Oracle provides an Oracle Traffic Director plug-in as part of Oracle Virtual Assembly Builder, a tool that you can use to build virtual appliances and assemblies from physical applications.

    For more information about creating and deploying virtual assemblies containing Oracle Traffic Director instances, see the Oracle Virtual Assembly Builder User's Guide.

  • TCP load balancing

    With TCP load balancing, Oracle Traffic Director accepts client connections and routes the requests to a pool of servers running TCP-based protocols.

1.3 Typical Network Topology

The network topology that you create for Oracle Traffic Director varies depending on your business requirements such as the number of back-end applications for which you want to use Oracle Traffic Director to balance requests, IT requirements such as security, and the features of Oracle Traffic Director that you want to use.

In the simplest implementation, you can have a single Oracle Traffic Director instance running on a dedicated compute node distributing client requests to a pool of servers in the back end.

To ensure that the node on which an Oracle Traffic Director instance runs does not become the single point of failure in the topology, you can have two homogenous Oracle Traffic Director instances running on different nodes forming an active-passive failover pair.

Figure 1-1 shows a typical Oracle Traffic Director network topology for a high-availability use case in an active-passive mode.

Figure 1-1 Oracle Traffic Director Network Topology: Active-Passive Failover Mode

Description of Figure 1-1 follows
Description of ''Figure 1-1 Oracle Traffic Director Network Topology: Active-Passive Failover Mode''

The topology shown in Figure 1-1 consists of two Oracle Traffic Director instances—otd_1 and otd_2—forming an active-passive failover group and providing a single virtual IP address for client requests. When the active instance (otd_1 in this example) receives a request, it determines the server pool to which the request should be sent and forwards the request to one of the servers in the pool based on the load distribution method defined for that pool.

Note that Figure 1-1 shows only two server pools in the back end, but you can configure Oracle Traffic Director to route requests to servers in multiple pools.

In the active-passive setup described here, one node in the failover group is redundant at any point in time. To improve resource utilization, you can configure the two Oracle Traffic Director instances in active-active mode with two virtual IP addresses. Each instance caters to requests received on one virtual IP address and backs up the other instance.

For more information about configuring Oracle Traffic Director instances in failover groups, see Section 13.2, "Creating and Managing Failover Groups."

1.4 Oracle Traffic Director Terminology

An Oracle Traffic Director configuration is a collection of elements that define the run-time behavior of an Oracle Traffic Director instance. An Oracle Traffic Director configuration contains information about various elements of an Oracle Traffic Director instance such as listeners, origin servers, failover groups, and logs.

The following table describes the terms used in this document when describing administrative tasks for Oracle Traffic Director.

Term Description
Configuration A collection of configurable elements (metadata) that determine the run-time behavior of an Oracle Traffic Director instance.

A typical configuration contains definitions for the listeners (IP address and port combinations) on which Oracle Traffic Director should listen for requests and information about the servers in the back end to which the requests should be sent. Oracle Traffic Director reads the configuration when an Oracle Traffic Director instance starts and while processing client requests.
Instance An Oracle Traffic Director server that is instantiated from a configuration and deployed on an administration node.
Failover group Two Oracle Traffic Director instances grouped by a virtual IP address (VIP), to provide high availability in active-passive mode. Requests are received at the VIP and routed to the Oracle Traffic Director instance that is designated as the primary instance. If the primary instance is not reachable, requests are routed to the backup instance.

For active-active failover, two failover groups are required, each with a unique VIP, but both consisting of the same nodes with the primary and backup roles reversed. Each instance in the failover group is designated as the primary instance for one VIP and the backup for the other VIP.
ORACLE_HOME A directory of your choice in which you install the Oracle Traffic Director binaries.
DOMAIN_HOME A path to the directory which contains Oracle Traffic Director domain
Fusion Middleware Control A web-based graphical interface on the administration server that you can use to create, deploy, and manage Oracle Traffic Director instances.
Client Any agent—a browser or an application, for example—that sends HTTP, HTTPS and TCP requests to Oracle Traffic Director instances.
Origin server A server in the back end, to which Oracle Traffic Director forwards the HTTP, HTTPS and TCP requests that it receives from clients, and from which it receives responses to client requests.

Origin servers can be application servers like Oracle WebLogic Server managed servers, web servers, and so on.
Origin-server pool A collection of origin servers that host the same application or service that you can load-balance by using Oracle Traffic Director.

Oracle Traffic Director distributes client requests to servers in the origin-server pool based on the load-distribution method that is specified for the pool.
Virtual server A virtual entity within an Oracle Traffic Director server instance that provides a unique IP address (or host name) and port combination through which Oracle Traffic Director can serve requests for one or more domains.

An Oracle Traffic Director instance on a node can contain multiple virtual servers. Administrators can configure settings such as the maximum number of incoming connections specifically for each virtual server. They can also customize how each virtual server handles requests.

1.5 Oracle Traffic Director Deployment Scenarios

Oracle Traffic Director can be used either as a physical application or as a virtual appliance.

  • Physical application

    You can install Oracle Traffic Director on an Oracle Linux 6.5 system and run one or more instances of the product to distribute client requests to servers in the back end.

    For information about installing Oracle Traffic Director as a physical application, see the Installing Oracle Traffic Director .

  • Appliance running on a virtual platform

    After deploying Oracle Traffic Director as a physical application, you can create a virtual appliance from an Oracle Traffic Director instance or create an assembly containing multiple such appliances. You can then deploy the appliance or assembly on the Oracle Virtual Machine hypervisor. To enable such a deployment, Oracle provides an Oracle Traffic Director plug-in as part of Oracle Virtual Assembly Builder, a tool that you can use to build virtual appliances and assemblies from physical applications.

    For more information about creating and deploying virtual assemblies containing Oracle Traffic Director instances, see the Oracle Virtual Assembly Builder User's Guide.

1.6 Overview of Administration Tasks

  • Install the product

    You can install Oracle Traffic Director on Oracle Linux 6.5+ on an x86_64 system, by using an interactive graphical wizard or in silent mode. Note that in 12c, Oracle Traffic Director does not have its own separate Admin Server, but uses the Admin Server in Oracle WebLogic Server.

    For more information, see Installing Oracle Traffic Director .

  • Create a WebLogic domain for Oracle Traffic Director. For more information, see Section 2, "Configuring the WebLogic Server Domain for Oracle Traffic Director."

  • Access Fusion Middleware Control and WLST

    You can use Fusion Middleware Control and command-line interface of Oracle Traffic Director to create, modify, and monitor Oracle Traffic Director configurations.

    For information about accessing Fusion Middleware Control and command-line interface, see Section 1.7, "Accessing the Administration Interfaces."

  • Create and manage configurations

    Create configurations that define your Oracle Traffic Director instances. A 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 and while processing client requests.

    For information about managing configurations, see Chapter 3, "Managing Configurations."

  • Create and manage instances

    After creating a configuration, you can create Oracle Traffic Director server instances by deploying the configuration on one or more hosts. You can view the current state of each instance, start or stop it, reconfigure it to reflect configuration changes, and so on.

    For information about managing instances, see Chapter 4, "Managing Instances."

  • Define and manage origin-server pools

    For an Oracle Traffic Director instance to distribute client requests, you should define one or more origin-server pools or in the back end. For each origin-server pool, you can define the load-distribution method that Oracle Traffic Director should use to distribute requests. In addition, for each origin server in a pool, you can define how Oracle Traffic Director should control the request load.

    For more information, see Chapter 5, "Managing Origin-Server Pools" and Chapter 6, "Managing Origin Servers."

  • Create and manage virtual servers and listeners

    An Oracle Traffic Director instance running on a node contains one or more virtual servers. Each virtual server provides one or more listeners for receiving requests from clients. For each virtual server, you can configure parameters such as the origin-server pool to which the virtual server should route requests, the quality of service settings, request limits, caching rules, and log preferences.

    For more information, see Chapter 7, "Managing Virtual Servers" and Chapter 9, "Managing Listeners."

  • Manage security

    Oracle Traffic Director, by virtue of its external-facing position in a typical network, plays a critical role in protecting data and applications in the back end against attacks and unauthorized access from outside the network. In addition, the security and integrity of data traversing through Oracle Traffic Director to the rest of the network needs to be guaranteed.

    For more information, see Chapter 10, "Managing Security."

  • Manage Logs

    Oracle Traffic Director records data about server events such as configuration changes, instances being started and stopped, errors while processing requests, and so on in log files. You can use the logs to troubleshoot errors and to tune the system for improved performance.

    For more information, see Chapter 11, "Managing Logs."

  • Monitor statistics

    The state and performance of Oracle Traffic Director instances are influenced by several factors: configuration settings, volume of incoming requests, health of origin servers, nature of data passing through the instances, and so on. As the administrator, you can view metrics for all of these factors through the command-line interface and Fusion Middleware Control, and extract the statistics in the form of XML files for detailed analysis. You can also adjust the granularity at which Oracle Traffic Director collects statistics.

    For more information, see Chapter 12, "Monitoring Oracle Traffic Director Instances."

  • Set up Oracle Traffic Director instances for high availability

    In the event that an Oracle Traffic Director instance or the node on which it runs fails, you need to ensure that the load-balancing service that the instance provides continues to be available uninterrupted. You can achieve this goal by configuring a backup Oracle Traffic Director instance that can take over processing of requests when the primary instance fails.

    For more information, see Chapter 13, "Configuring Oracle Traffic Director for High Availability."

  • Tune for performance

    Based on your analysis of performance statistics and to respond to changes in the request load profile, you might want to adjust the request processing parameters of Oracle Traffic Director to maintain or improve the performance. Oracle Traffic Director provides a range of performance-tuning controls and knobs that you can use to limit the size and volume of individual requests, control timeout settings, configure thread pool settings, SSL/TLS caching behavior, and so on.

    For more information, see Chapter 14, "Tuning Oracle Traffic Director for Performance."

  • Diagnose and troubleshoot problems

    Despite the best possible precautions, you might occasionally run into problems when installing, configuring, and monitoring Oracle Traffic Director instances. You can diagnose and solve some of these problems based on the information available in error messages and logs. For complex problems, you would need to gather certain data that Oracle support personnel can use to understand, reproduce, and diagnose the problem.

    For more information, see Chapter 15, "Diagnosing and Troubleshooting Problems."

1.7 Accessing the Administration Interfaces

This section contains the following topics:

1.7.1 Accessing WebLogic Scripting Tool

The command line interface in Oracle Traffic Director 12c is WLST (Weblogic Scripting Tool). The WLST scripting environment is based on Jython which is an implementation of the Python language for the Java platform. The tool can be used both online and offline. For more information on WLST and various online and offline commands, see Oracle WebLogic Scripting Tool. Oracle Traffic Director ships with custom WLST commands that you can run using WLST.

Note:

Oracle Traffic Director ships a wlst.sh wrapper <oracle_home>/otd/common/bin/wlst.sh which initializes the required environment and libraries for Oracle Traffic Director commands. All Oracle Traffic Director custom commands can only be executed from this wlst.sh.

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

1.7.1.1 Usage Modes

You can use the following techniques to invoke Oracle Traffic Director custom commands. For more information on using WLST in these modes, see Using the WebLogic Scripting Tool in Oracle WebLogic Scripting Tool.

1.7.2 Displaying Fusion Middleware Control

To display Fusion Middleware Control, you enter the Fusion Middleware Control URL, which includes the name of the host and the administration port number assigned during the installation. The following shows the format of the URL:

http://hostname.domain:port/em

The port number is the port number of the Fusion Middleware Control. By default, the port number is 7001. The port number is listed in the following file:

DOMAIN_HOME/config/config.xml

For some installation types, such as Web Tier, if you saved the installation information by clicking Save on the last installation screen, the URL for Fusion Middleware Control is included in the file that is written to disk (by default to your home directory). For other installation types, the information is displayed on the Create Domain screen of the Configuration Wizard when the configuration completes.

To display Fusion Middleware Control:

  1. Enter the URL in your Web browser. For example:

    http://host1.example.com:7001/em

  2. Enter the Oracle Fusion Middleware administrator user name and password and click Login.

You can now create Oracle Traffic Director configurations and deploy them as instances on administration nodes. For more information, see Chapter 3, "Managing Configurations."

1.8 Setting Up a Simple Load Balancer Using Oracle Traffic Director

This section describes how you can set up a load-balanced service using Oracle Traffic Director with the minimum necessary configuration. The purpose of this section is to reinforce and illustrate the concepts discussed earlier in this chapter and to prepare you for the configuration tasks described in the remaining chapters.

This section contains the following topics:

1.8.1 Example Topology

In this example, we will create a single instance of Oracle Traffic Director that will receive HTTP requests and distribute them to two origin servers in the back end, both serving identical content.

Figure 1-2 shows the example topology.

Figure 1-2 Oracle Traffic Director Deployment Example

Description of Figure 1-2 follows
Description of ''Figure 1-2 Oracle Traffic Director Deployment Example''

The example topology is based on the following configuration:

  • Administration server host and port: bin.example.com:8989

  • Administration node host and port: apps.example.com:8900

  • Virtual server host and port to receive requests from clients: hr-apps.example.com:1905

  • Host and port of origin servers (web servers in this example):

    • hr-1.example.com:80

    • hr-2.example.com:80

    In the real world, both origin servers would serve identical content. But for this example, to be able to see load balancing in action, we will set up the index.html page to which the DocumentRoot directive of the web servers points, to show slightly different content, as follows:

    • For hr-1.example.com:80: "Page served from origin-server 1"

    • For hr-2.example.com:80: "Page served from origin-server 2"

  • Load-balancing method: Round robin

1.8.2 Creating the Load Balancer for the Example Topology

This section describes how to set up the topology described in Section 1.8.1, "Example Topology."

  1. Install Oracle Traffic Director as described in Installing Oracle Traffic Director .

  2. Create a configuration hr-config using the otd_createConfiguration WLST command.

    props = {}
props['name'] = 'hr-config'
props['listener-port'] = '1905'
props['server-name'] = 'hr-apps.example.com'
props['origin-server'] = 'hr-1.example.com:80,hr-2.example.com:80'
otd_createConfiguration(props)

  3. Create an instance of the configuration hr-config by running the otd_createInstance WLST command. Specify the machine as the name you specified when creating the machine in Fusion Middleware Control, corresponding to the host name of the machine on which the OTD instance is running.

    props = {}
props['configuration'] = 'hr-config'
props['machine'] = 'machine1'
otd_createInstance(props)

  4. Start the Oracle Traffic Director instance that you just created by running the start WLST command.

    start('otd_foo_machine1')

Note:

The steps in this procedure use only WLST, but you can use Fusion Middleware Control as well.

We have now successfully created an Oracle Traffic Director configuration, and started the instance.

1.8.3 Verifying the Load-Balancing Behavior of the Oracle Traffic Director Instance

The Oracle Traffic Director instance that we created and started earlier is now listening for HTTP requests at the URL http://hr-apps.example.com:1905.

This section describes how you can verify the load-balancing behavior of the Oracle Traffic Director instance by using your browser.

Note:

  • Make sure that the web servers hr-1.example.com:80 and hr-2.example.com:80 are running.

  • If necessary, update the /etc/hosts file on the host from which you are going to access the Oracle Traffic Director virtual server, to make sure that the browser can resolve hr-apps.example.com to the correct IP address.

  1. Enter the URL http://hr-apps.example.com:1905 in your browser.

    A page with the following text is displayed:

    "Page served from origin-server 1"

    This indicates that the Oracle Traffic Director instance running on the apps.example.com administration node received the HTTP request that you sent from the browser, and forwarded it to the origin server hr-1.example.com:80.

  2. Send another HTTP request to http://hr-apps.example.com:1905 by refreshing the browser window.

    A page with the following text is displayed:

    "Page served from origin-server 2"

    This indicates that Oracle Traffic Director sent the second request to the origin server hr-2.example.com:80

  3. Send a third HTTP request to http://hr-apps.example.com:1905 by refreshing the browser window again.

    A page with the following text is displayed:

    "Page served from origin-server 1"

    This indicates that Oracle Traffic Director used the simple round-robin load-distribution method to send the third HTTP request to the origin server hr-1.example.com:80.