Oracle Traffic Director serves 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 method, routes the requests based on specified rules, caches frequently accessed data, prioritizes traffic, and controls the quality of service.
The following diagram illustrates a high-level workflow in Oracle Traffic Director:
|Product Component||OS Type||Versioning||Pattern Depth|
|Oracle Traffic Director Server||UNIX||Active, File||Instance-based|
|Oracle Traffic Administration Node||UNIX||Active, File||Instance-based|
|Oracle Traffic Director Administration Server||UNIX||Related SI||Instance-based|
regex " trafficd-wdog"
regex " trafficdirector_Home"
|AdminServer||SoftwareInstance created||type||=||Oracle Traffic Director Administration Node|
regex " admin-server"
Version information for the product is currently collected using the Active and File Versioning methods.
Install root is obtained from the triggering process arguments using the following regular expression:
Configuration file directory can be obtained from triggering process arguments using the following regular expression:
To obtain the version, the pattern runs <install_root>/bin/tadm -V command and extracts the version from the output using the following regular expression:
Oracle Traffic Director (\d+(?:\.\d+)*)
The pattern retrieves the product version by evaluating the instantiate.xml file located in the /inventory subfolder of the install root using the following xpath:
The AdminServer pattern uses the version of Oracle Traffic Director Server or Oracle Traffic Director Administration Node Software Instance to extract the product version for Oracle Traffic Director Administration Server Software Instance.
The main components of Oracle Traffic Director are:
All virtual servers are modeled as SoftwareComponents inside Oracle Traffic Director Server software instance.
The TrafficDirector pattern triggers on the discovered process whose command line contains trafficd-wdog as a substring, and whose arguments (for example,
-d /home/oracle/otd/instances/net-test3/config -r /home/oracle/oracle/product/22.214.171.124.0/trafficdirector_Home_1 -t /tmp/net-test3-dee33fc9 -u oracle) contain trafficdirector_Home as a substring.
The AdminServer pattern triggers on the new Oracle Traffic Director Administration Node SoftwareInstance whose instance matches regex "admin-server" and whose config_file matches "^/".
The TrafficDirector pattern creates either Oracle Traffic Director Administration Node or Oracle Traffic Director Server Software Instance, its key being based on instance, si type, host key and hashed config file.
The AdminServer pattern creates an instance-based Software Instance, its key being based on Oracle Traffic Director Administration Node SoftwareInstance key and si type.
The pattern creates containment relationships between the Oracle Traffic Director Administration Node software instance and all Oracle Traffic Director Server instances.
As the Oracle Traffic Director Administration Node and Oracle Traffic Director Server are equal processes with different configuration, the TrafficDirector pattern triggers on both of them. To decide on which one should be modeled, the TrafficDirector pattern retrieves the instance information from the triggering process arguments using the following regular expression:
and matches the retrieved information against the following regular expression:
In case of successful match, the Oracle Traffic Director Administration Node SI is created. Otherwise, it is Oracle Traffic Director Server Software Instance.
To retrieve information about the listening port used by the Oracle Traffic Director Administration Node or Server, the pattern evaluates the contents of server.xml configuration file located in the configuration file directory using the following xpaths:
To detect the clustered deployment, the TrafficDirector pattern evaluates the contents of server.xml configuration file located in the configuration file directory using the following xpaths:
The TrafficDirector pattern models virtual servers whose traffic is managed by Oracle Traffic Director. To detect the virtual servers, the TrafficDirector pattern evaluates the contents of server.xml configuration file located in the configuration file directory using the following xpaths:
Next, the pattern searches for http-listener-name and port for every detected virtual server. If the port is identified, the virtual server is modeled as a Software Component of the Oracle Traffic Director.
Software Instance details of Oracle Traffic Director Server SI generated with this pattern (click on the image to open full size):
Subject Matter Expert input will be welcome on any other potential approaches not discussed to improving product versioning coverage and depth of Oracle Oracle Traffic Director.
The pattern was tested on live installations in the test lab on Red Hat Enterprise Linux.
There are no known open issues with this pattern.
24 Aug 2014