Summary
Oracle Traffic Director (OTD) is a powerful software load balancing solution. As with most good products there is a degree of flexibilty in how it can be deployed with different approaches allowing the solution to be formed. This article discusses two options that could be used to determine different routing possiblilties.
The scenario that is being considered is a need to perform two separate load balancing activities in the same OTD environment. For example, load balancing to an older SOA 11g deployment and to SOA 12c for recent integration deployments. Another possible example would be two routes to the same back end service but one is designed for high priority traffic while the other route will throttle the service at a preset load. The two options that are discussed are:
- Using two separate configurations, one for SOA 11g and one for SOA12c.
- Using one configuration that has two virtual servers. The virtual servers handling the routing for each environment.
Needless to say either option can be appropriate and it will depend on the details of the overall solution and to some extent personal preference to determine the right answer for a particular customer environment. Of course other options such as more complex routing rules within a single configuration or multiple OTD domains are also options to think about.
OTD Configuration Overview
Simple configuration
An OTD deployment, in its simplest form, consists of an administrative instance which manages the configuration and a deployed instance. The deployed configuration specifies the HTTP(S)/TCP listening port, routing rules to one or more origin servers, logging setup etc. In many situations there is a business need to use OTD to manage requests to different business applications or even just to different environments/versions of an application. It is obviously possible to split these out by using independent deployments of OTD however to minimise the resources required and keep the number of deployed components to a minimum there are options to use one administration server.
 |
| The base configuration options |
The minimum configuration that will appear for a configuration is a setup which defines things like the listening ports, SSL certificates, logging setup and critically at least one origin server pool and a virtual server. The origin server pool is a simple enough concept in that it defines the back end services to actually fulfil the client requests.
Using Virtual Servers
The virtual servers provide a mechanism to isolate traffic sent to the software load balancer. Each virtual server contains its own set of routing rules which can determine the origin servers to send requests to, caching rules, traffic shaping and overrides for logging and the layer 7 firewall rules. The virtual server to be used for subsequent processing is identified by either the listening port or the hostname used to send the request.
 |
| Virtual Server example - Routing based on otrade-host |
 |
| Virtual Server example - Routing based on websession-host |
So in the above example both hostnames otrade-host and websession-host resolve to the same IP address in DNS (or in the clients local /etc/hosts file). In this case two virtual servers also use the same listener. If the client makes a request to access otrade-host then the first virtual server is used and if they request websession-host then the second's rules are used.
There is always at least one virtual server. By default this is created and the hosts field left blank such that it is used if any traffic hits the listening port.
Solution Variations
Multiple Configurations
Overview
In this setup two configurations can be defined and deployed. It is quite possible to have both configurations deployed to the same OS instances.
(Admin node in OTD talk.) The result of deploying the configuration to the admin nodes is the creation of another running instance of OTD.
 |
| Running multiple configurations |
Thus in the example shown above we have three OS instances, one to host the admin server which could be co-located with the actual instances. There are two OS instances which host two OTD servers, one for each configuration. I have shown two OS instances to run the configuration to indicate that they can be setup in a failover group to provide HA, each config can utilise a different VIP.
Advantages
- Each configuration is managed independently of each other. (within the one administration server)
- The settings are independent of each other.
- The running instances for each configuration are independent of each other. i.e. Can be stopped and started without impacting the other configuration instances running.
- Simple to understand
Disadvantages
- Care must be taken to ensure that the configurations do not have clashes with each other. (eg. Same listenting ports)
- Results in more processes running on each OS instance.
Multiple Virtual Servers
Overview
In this situation there is one configuration with multiple virtual servers which result in different routing rules being applied to send requests on. In the diagram below we have deployed a single configuration to two OS instances with the configuration containing two virtual servers. As per the multi-config option I have shown two OS instances to indicate that the failover group can be used for HA.
 |
| OTD Using Two Virtual Servers |
Advantages
- One configuration that provides visibility of all configuration in the environment.
- Minimal running processes
- Simplifying the monitoring
- Reducing resources required to run the system
Disadvantages
- Introduces dependencies between the environments
- eg. Can share listeners, origin server pools, logging config etc. Thus one change can impact all instances
- eg. Some changes mandate a restart of an instance. A change for one config may have an impact on load balancing for the other environment.
- Complexity of a single configuration
- Dependencies on external factors. (DNS resolution of hostnames/firewalls for port access.)
Conclusions
There are no hard and fast rules to figure out which approach is the best one for you. It will ultimately depend on the requirements for the load balancing. If a configuration is changing frequently and is functionally independent then I would tend to go for the multiple configuration route. If on the other hand simplicity of monitoring and minimal resource footprint alongside a fairly static configuration was the situation I would tend to use the multiple virtual server approach.
Essentially the classic IT answer of "it depends" will apply. Only a good understanding of the requirements will clarify which way to go. (Although if you are using OTD 11.1.1.6 then you might be better with the virtual server approach as there are a few limitations to the VIPs using keepalive for the failover groups)
