Recently I have been involved in a number of cases where the topic of virtualising the Oracle eBS R12 applications tier has been on the agenda. In all cases the target deployment has been on x86_64 infrastructure (combination of blades and stand alone servers) so the virtualisation platform considered has been either VMware or Oracle VM.
Beyond the obvious known benefits of deploying the applications tier – and where relevant the database tier – on virtual infrastructure, one additional benefit that does not seem to receive attention is the ability to provision specific applications components to specific servers.
Case in point where we have a multi-node applications tier sitting behind a load balancing router (we have abstracted the web entry point in this case to the load balancing router). Consider this configuration where we have two physical application servers:
- Server 1 – 2 x 6 core CPU
- Server 2 – 2 x 6 core CPU
One option is to provision the Root, Web and Batch Service Groups on each server and let everything compete for the available resources on the server. This is the easiest way to configure the applications tier (introducing PCP into this configuration as well). Before closing the case on looking at alternative configurations lets consider some of the negatives of this approach:
- Web and Batch services are competing for the same pool of CPU, IO and RAM resources.
- Measurement of resource consumption by each service group is somewhat complicated.
- Limited ability to provision additional resources into a service group based on workload demand.
Assuming that we are using a Shared APPL_TOP configuration we can consider deploying virtual servers with the following Oracle eBusiness Suite R12 Service Groups:
If we consider the above we now have a server running a Service Group. This lets us:
- Measure the resource consumption of the Service Group better.
- Provision the required peak resources for the Service Group better.
- Isolate maintenance activities to a particular set of servers.
- Limit the resources consumed by a Server Group from the physical server.
Matching configuration to workload
Deploying the applications tier on virtual infrastructure provides more flexibility to provision, start and stop servers and the hosted Service Group. On the assumption that we have sufficient physical resources available we can consider bringing online additional servers for a Service Group depending on workload requirements.
In the following example we can consider the monthly workload profile for an eBS environment that has a combination of Self Service apps (iProcurement, Oracle Time, SSHR) and is running a combination of Oracle Financials and HRMS & Payroll modules as follows:
Week 1 – Medium online activity through Web Service Group (OACORE and OAFORMS). Minimal batch activity.
Week 2 – Heavy online activity through Web Service Group (OACORE and OAFORMS). Medium batch activity running Payroll.
Week 3 – Low online activity and heavy batch activity running Payroll.
Week 4 – Low online activity and very heavy batch activity running end of month posting and reporting.
With our virtual infrastructure in place we now have the ability to bring online additional web servers (running either the OACORE or OAFORMS engines) or additional concurrent manager servers into the environment. The only pre-requisite being that we configure the additional servers using the standard documented steps for Rapid Clone. Given our two physical machines we can adopt the following config for Week1 – Week 4 (actual hardware capacity may allow for more/less virtual machines running at the same time but this provides an example of what can be done):
Week 1 & 2- 4 Web Servers available, 2 Concurrent Manager servers
Week 3 & 4 – 2 Web Servers available, 4 Concurrent Manager servers
The benefit
End result from this approach is that we can have added additional resources available to the relevant service groups where needed which are measurable and require very little or no ongoing operational effort to achieve (the management of the vm startup and shutdown which can be done via scheduled jobs in a VMA appliance or the Oracle VM equivalent).