There are multiple ways to optimize Oracle in a VMware virtualized environment. In part 2 of this blog series, a simple solution consisting of consolidating multiple Oracle databases on a single VMware server or cluster was described. This architecture can be used in different configurations to provide additional benefits and cost savings.
Coming back to the simple case scenario where consolidation occurs, a simple fact is that all databases do not have peak CPU loading at the same time. One application can stay idle most of the week and have a peak during weekends or a specific event such as the end of the quarter, some others may be running queries during the day due to end user activity and batch processes at night. The number of processors needed within a VMware virtualized environment is less than the number needed on individual servers for an identical set of databases as CPU resources get shared. When licensed on dedicated servers, the rule of thumb ‘peak usage times two’ is often considered. In a virtualized environment, this rule becomes obsolete as all the CPU resources are shared and not all databases have peak demand at the same time. Oversizing anywhere from 25 to 50% is usually acceptable, but detailed analysis tied to the nature and usage of each application must be performed. Considering these numbers, a customer having 15 dedicated Oracle servers, each supporting 12 cores can be conservatively consolidated into a cluster of 4 VMware ESX physical (host) servers of 32 cores each:
In this example, the benefit would be to lower the Oracle processor license consumption by: (15×12) – (4×32) = 52 cores, assuming the processor factor is the same between the two systems. With a processor factor of 0.5 and a unit price of an Enterprise Edition license of $47,500 the saving or cost avoidance would be:
52 (number of processors) * 0.5 (core factor) * 47,500 (price per processor) = $1,240,200
The saving may be higher if the original servers where not running Intel x86 processors but Sun SPARC, HP PA-RISK or IBM POWER that have, for most of them, a core factor greater than 0.5. Additionally, VMware comes with many advantages in terms of managing full OS environments—enabling archiving, cloning, regeneration or moving a full environment to a new hardware server.
Placing VMware ESX servers hosting Oracle databases in a cluster offers multiple advantages. VMware’s VMotion provides the capability to regulate virtual machine loads across ESX servers without human intervention. When using the Oracle Database Enterprise Edition, VMware High Availability (HA) can be used instead of Oracle Real Application Clusters (RAC). Oracle RAC is the most expensive Oracle option at $23,000 per processor. This needs to be carefully considered as it does not apply to all configurations. Oracle RAC provides load balancing and seamless high availability; VMware HA provides high availability with a downtime, usually a few minutes, required to recover the database.
In the previous blog entry, the use of the Oracle Standard Edition was considered. One of the best strategies for any organization is a mix between Oracle Standard Edition and Enterprise Edition. Not all databases are mission critical and require database options or management packs. Having a set of clusters, each supporting one of the two Oracle editions, provides the required flexibility with maximum savings. Large organizations typically have hundreds of databases that can be distributed across the two product editions.
VMware ESX/ESXi is a leading server virtualization technology that can provide substantial savings when applied to Oracle database environments. However, it adds complexity to software license management considering all the rules attached to Oracle licenses. In a VMware virtualized environment, the virtual processors allocated to a virtual machine are not considered for the Oracle processor license; only the number of sockets or the number of cores and the type of processors contained in the host are considered. This requires the ability to collect inventory of physical and virtual servers, detect Oracle database instances, determine the nature (physical or virtual) of the operating system hosting the databases, and tie the virtual machines to physical hosts. Additionally, rules governing Oracle editions and clusters must be considered to calculate an accurate license position.