Oracle DNS-Based Load-Balancing e-Business Suite

Recently Elke Phelps and Sriram Veeraraghavan presented a talk named advanced E-business Suite Architectures" which handled quite some interesting topics. You van check a re-run of the presentation via the weblog of Steven Chan and you can download the presentation also from the oracle.com website in a PDF format.

One of the interesting subjects covered during the talk was the subject of load-balanced configuration for Oracle e-Business suite. This is a very interesting topic because it can help you in several parts of your architecture and your Enterprise IT planning. It can help you load-balance load within one datacenter, it can help you balance the load over multiple datacenters and it can help you with creating a more resilient solution. Within the presentation examples on load balance solutions where given in the form of DNS-based HTTP-layer based load-balancing. We will focus on DNS-based load-balancing, the slide from the presentation given by Sriram and Elke is shown below.

The example used in the presentation from Oracle is talking about Oracle e-Business Suite, however you can use DNS-based load-balancing technology for all kinds of applications and primarily for web-based applications.  In the below example you can see a none load-balanced web-application. A user will request the IP address of the URL (somedomain.com = 101.102.103.101) where the .101 IP is the IP of web-node-0 within the DMZ in DC-0 (datacenter-0). This is quiet straight forward and how all web applications work in essence.

If you are planning for a more resilient solution then the one above, which has a number of single point of failure parts, the first thing we will have to take a look at is the number of web nodes. You can make one web node up and running and have a second standby for when the first fails. This is a fail-over solution in which you can choice for hot standby or cold standby.

A better solution might be to have both web-nodes up and running and have both of them handling load. This way the load can be spread evenly and when one of the web-nodes fails the other can handle the full load. This is shown in the below image where we have "web node 0" and "web node 1". In this situation you have to configure your DNS server to provide the IP address of "Web Node 0" or "Web node 1" when the user requests the IP address of the URL. To provide a good load-balance mechanism you will have to have a round-robin (like) algorithm to make sure the load is distributed among "Web Node 0" and "Web node 1"

"Round robin DNS is often used for balancing the load of geographically distributed Web servers. For example, a company has one domain name and three identical web sites residing on three servers with three different IP addresses. When one user accesses the home page it will be sent to the first IP address. The second user who accesses the home page will be sent to the next IP address, and the third user will be sent to the third IP address. In each case, once the IP address is given out, it goes to the end of the list. The fourth user, therefore, will be sent to the first IP address, and so forth."

In the above example we still have some possible issues. For example; what happens when "web node 0" is down? In the above example the DNS server will still think the node is up and will provide the IP address of the malfunctioning node to users whenever the round robin algorithm decides it is it's turn. Having a smart mechanism which checks the availability of the node and which removes the IP address from the DNS server so it will not be used when the node is down can be considered as a best practice. Having such a heart beat mechanism for DNS should be in your overall design.

A second single point of failure is the DNS server itself. If the DNS server is down it will not be able to provide the needed IP addresses when requested for by a user and it will not be able to balance the load over "web node 0" and "web node 1". It is common practice for most publicly used DNS servers to have a domain registered in a primary and a secondary name server. To prevent your solution from malfunctioning in the case a DNS server issue you should have at least a primary and a secondary DNS server and possibly even a tertiary DNS server. Having multiple DNS servers for a single domain name is within the design of how DNS name resolving works and is not something you should (really) worry about.

The above example is protecting you against the failure of a DNS server and the failure of one of your web nodes. It is however not protecting you against the failure of your entire datacenter. If datacenter DC-0 would be lost due to, for example a fire, your DNS servers would have nothing to point at. You do however have the solution already at hand with the round robin solution in your DNS servers. You can use a dual datacenter solution where you deploy your web nodes in both. Now the round robin DNS server will route users to both datacenters and to both web nodes. Meaning, the DNS server will provide routing to all 4 IP addresses of all 4 web nodes by making use of the round robin mechanism.

As you can see in the above diagram we have also introduced a data synchronization between DC-0 and DC-1 to make sure that the data is replicated to both datacenters. For replication of data between multiple datacenters you can deploy several mechanisms. Some are based upon a solution in the database, some in how the application is developed and some make use of block storage replication. Which one is the best for your solution is something that will depend on a large number of variables like for example; distance between your locations, type of storage, type of application, level of data integrity needed,... etc. making a decision on how this needs to be done however is something that you have to think about very carefully as it can impact the stability, availability, extendability and speed of your application.