Load balancing Oracle Application / HTTP Server
Benefits of load balancing Oracle Application / HTTP Server
Load balancing Oracle Application Server offers a number of benefits, including:
- High Availability (HA): Load balancing ensures that if one application server fails, all client traffic is automatically and immediately redirected to the remaining healthy servers in the pool. This eliminates a single point of failure, maximizing application uptime and providing a highly resilient service, which is crucial for critical enterprise applications.
- Improved performance: A load balancer distributes incoming user requests evenly across multiple application server instances. This prevents any single server from becoming overwhelmed or creating a bottleneck, leading to lower latency, faster response times, and a better overall user experience. It also makes efficient use of all available computing resources.
- Scalability: Load balancing makes it easy to scale the application environment horizontally by simply adding more application servers to the backend pool. The load balancer instantly recognizes the new server and begins routing traffic to it, allowing the application to handle sudden increases in load without manual intervention or downtime. This supports seamless growth with minimal disruption.
About Oracle Application / HTTP Server
Oracle Application Server product line is the industry’s most comprehensive Java platform for developing, deploying, and integrating enterprise applications. It provides the foundation for application grid, which is an architecture that enables enterprises to outperform their competitors while minimizing operational costs.
Why Loadbalancer.org for Oracle Application / HTTP Server?
Loadbalancer’s intuitive Enterprise Application Delivery Controller (ADC) is designed to save time and money with a clever, not complex, WebUI.
Easily configure, deploy, manage, and maintain our Enterprise load balancer, reducing complexity and the risk of human error. For a difference you can see in just minutes.
And with WAF and GSLB included straight out-of-the-box, there’s no hidden costs, so the prices you see on our website are fully transparent.
More on what’s possible with Loadbalancer.org.
How to load balance Oracle Application / HTTP Server
The load balancer can be deployed in four fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, and Layer 7 Reverse Proxy (Layer 7 SNAT mode).
For Oracle HTTP Server, Layer 7 Reverse Proxy is recommended.
Virtual service (VIP) requirements
To provide load balancing and HA for Oracle Application / HTTP Server, the following VIP is required:
Ref. | VIP Name | Use | Mode | Port(s) | Persistence Mode | Health Check |
---|---|---|---|---|---|---|
VIP 1 | OHS-HTTP | HTTP Server Traffic | Layer 7 Reverse Proxy | 7777 | HTTP Cookie | HTTP (GET) |
Load balancing deployment concept
Once the load balancer is deployed, clients connect to the Virtual Service (VIP) on the load balancer rather than directly to one of the Oracle HTTP Servers:

Load balancing topology
Layer 7 Reverse Proxy can be deployed using either a one-arm or two-arm configuration. For two-arm deployments, eth1 is typically used for client side connections and eth0 is used for Real Server connections, although this is not mandatory since any interface can be used for any purpose.
For more on one and two-arm topology see Topologies & Load Balancing Methods.
About Layer 7 Reverse Proxy load balancing
Layer 7 Reverse Proxy uses a proxy (HAProxy) at the application layer. Inbound requests are terminated on the load balancer and HAProxy generates a new corresponding request to the chosen Real Server. As a result, Layer 7 is typically not as fast as the Layer 4 methods. Layer 7 is typically chosen when either enhanced options such as SSL termination, cookie based persistence, URL rewriting, header insertion/deletion etc. are required, or when the network topology prohibits the use of the Layer 4 methods.
The image below shows an example Layer 7 Reverse Proxy network diagram:

Because Layer 7 Reverse Proxy is a full proxy, Real Servers in the cluster can be on any accessible network including across the Internet or WAN.
Layer 7 Reverse Proxy is not transparent by default, i.e. the Real Servers will not see the source IP address of the client, they will see the load balancer’s own IP address by default, or any other local appliance IP address if preferred (e.g. the VIP address).
This can be configured per Layer 7 VIP. If required, the load balancer can be configured to provide the actual client IP address to the Real Servers in 2 ways. Either by inserting a header that contains the client’s source IP address, or by modifying the Source Address field of the IP packets and replacing the IP address of the load balancer with the IP address of the client. For more information on these methods, please refer to Transparency at Layer 7 in the Enterprise Admin Manual.