Learn about the features of Oracle Traffic Director and also understand the basic terminology and the administration tasks.
This chapter includes the following sections:
Oracle Traffic Director distributes the requests that it receives from clients to servers in the back end based on the specified load-balancing method, routes the requests based on specified rules, caches frequently accessed data, prioritizes traffic, and controls the quality of service.
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, FTP and TCP traffic to application servers and web servers in the back end. 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.
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 using protocols such as Socket Direct Protocol (SDP) for better throughput. 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 12c (12.2.1) includes new features in high availability, websocket connections support, integration with Oracle Fusion Middleware , enhanced security and performance, and more. This document describes the new features made in the initial release of 12c (12.2.1), and also describes the changes made in the subsequent patch set releases: 22.214.171.124.0, 126.96.36.199.0, and 188.8.131.52.0.
On engineered system platforms, you can set up pairs of Oracle Traffic Director instances and leverage its built-in High Availability capability to setup either Active-Passive or Active-Active failover with additional back-end servers to which it can route the requets. These back-end servers can also be added dynamically by the origin-serve. for example, in the WebLogic cluster, the Oracle Traffic Director auto detects such changes using Dynamic Node Discovery method . 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.
Oracle Traffic Director provides the following features:
Advanced methods for load distribution
Configure Oracle Traffic Director to distribute client requests to servers in the back-end using one of these methods:
Least connection count
Least response time
Weighted round robin
Weighted least connection count
Flexible routing and load control on back-end servers
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.
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.
Oracle Traffic Director can be configured to limit the number of concurrent connections to a back end origin-server. 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 RFC 6455 are allowed. See Configuring Routes for a Virtual Server and the Oracle Traffic Director Command-Line Reference.
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.
Administrators can also use Fusion Middleware Control, a browser-based graphical user interface, to monitor statistics and perform lifecycle tasks for Oracle Traffic Director instances.
Oracle Traffic Director enables and enhances security for your IT infrastructure in the following ways:
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 TLS 1.1, and 1.2
To secure data during transmission and to ensure that only authorized users access the servers in the back end, you can configure 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 the administration console or the WLST.
Web Application Firewall
A Web application firewall enables 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.0.
HTTP Forward Proxy Support in Origin Server Pools
In an environment where access to intended origin servers is restricted through corporate proxy servers, you can optionally associate an HTTP forward proxy server with an origin server pool so that all of its member origin servers (of said pool) are communicated with via the configured HTTP forward proxy server.
On engineered systems platforms, you can set up pairs of Oracle Traffic Director instances and leverage its built-in High Availability capability to setup 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.
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 are available. This feature ensures continued availability even when some servers in the back end fail.
Failover for load balancing
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.
Most configuration changes to Oracle Traffic Director instances can be deployed dynamically, without restarting the instances and without affecting requests that are being processed.
Administrators can monitor a wide range of statistics pertaining to the performance of Oracle Traffic Director instances through several methods: the administration console, the command-line interface, and a report in XML format.
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.
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.
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.
Oracle Traffic Director includes a robust command-line interface-WebLogic Scripting Tool as well as a simple, wizard-driven graphical interface-Fusion Middleware Control to help you administer Oracle Traffic Director instances. You can create, modify, and manage Oracle Traffic Director instances.
The command line interface in Oracle Traffic Director is the WebLogic Scripting Tool (WLST).
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. Oracle Traffic Director ships custom WLST commands that you can run using WLST.
Oracle Traffic Director ships a
<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
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:
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:
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:
You can now create Oracle Traffic Director configurations and deploy them as instances on Node Managers.
Learn about the terms used in this document when describing administrative tasks for Oracle Traffic Director.
The following table describes the Oracle Traffic Director terms used throughout this document.
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.
Two Oracle Traffic Director instances grouped by a virtual IP address (VIP), to provide high availability in active-active or 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.
A directory of your choice in which you install the Oracle Traffic Director binaries.
A path to the directory which contains Oracle Traffic Director domain,
Fusion Middleware Control
A web-based graphical interface on the server that you can use to create, deploy, and manage Oracle Traffic Director instances.
Any agent—a browser or an application, for example—that sends HTTP, HTTPS and TCP requests to Oracle Traffic Director instances.
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.
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.
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.
An Oracle Traffic Director administrator can install the product, configure domain, manage instances, and so on. The tools to manage are WebLogic Scripting Tool(WLST) and Fusion Middleware Control.
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 Administration Server, but uses the Administration Server in Oracle WebLogic Server.
Create a WebLogic domain for Oracle Traffic Director. See Creating Domains Using the Pack and Unpack Commands or Creating WebLogic Domains Using the Configuration Wizard.
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 Administration Interfaces.
The standard tasks include:
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.
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.
See 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.
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.
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.
See Managing Security.
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.
See Managing Logs.
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.
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.
See Setting up Failover.
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.
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.