The main finding of a recent Wikibon study on virtualizing databases is that there is an excellent technical case for the virtualization of the majority of databases in general and Oracle in particular. The case extends to the in-house and ISV packages that use databases. The business case for migration is very strong, the major financial drivers being:
- Business continuity at a much lower price point
- Equipment consolidation for smaller database instances
- Greater flexibility and resilience
Wikibon expects that the migration will be steady and deliberate over an extended period of many years.
There are caveats to this recommendation:
- There is no such thing as a free lunch. Oracle continues to resist fully supporting Oracle under VMware. There are some valid technical reasons cited by Oracle that users should consider, such as increased complexity from an additional virtualization layer between Oracle and the hardware, and there are some performance and latency impacts. However, Wikibon believes that most of the resistance is related to Oracle’s fears of lost revenue from alternative non-Oracle business continuity solutions, lost opportunities to bundle Oracle software and hardware and loss of account control.
- While Oracle is correct that any hypervisor creates additional overhead for both servers and storage and VMware licenses specifically are not free. However, for most database workloads the business and technical cases for migration are very strong and getting stronger.
The net of this debate in our view is that the potential drawbacks cited by Oracle, which sometimes include strong arm tactics aimed at maintaining account control, are outweighed by the benefits in most cases and users should aggressively pursue virtualization strategies with Oracle. Given our premise that there is no reason not to start the journey, this Wikibon research note is designed to help you pick the best route and avoid the torpedoes.
Choice of Virtualization Platform
While VMware is implemented in the majority of installations, there is some momentum from Microsoft’s Hyper-V and Citrix Xen. For very high performance databases running on non-X86 servers, other virtualization platforms such as IBM’s LPAR may be appropriate. However, VMware is currently the most functionally rich and stable virtualization environment for X86 servers, and is expected to remain in advance of other platforms for some time. The VMware ecosystem of supporting management products is also very rich; in particular, we are impressed with the IBM Tivoli management products. At the moment (Mid-2011) Wikibon recommends the use of VMware for virtualization of production Oracle databases on Intel X86 servers.
Understanding Oracle’s VMware Support Policy
Officially the only product that supports VMware is Oracle RAC 11.2.0 and above, a high availability high-performance clustered database system. Not surprisingly it is the Oracle product that will gain least from VMware virtualization. Lack of support means that Oracle does not certify support for Oracle under VMware, which means that many ISVs using Oracle as a database that require a certified configuration also do not certify support. For some industries certification is mandated (e.g., by the FDA for pharmaceutical companies involved in trials).
However users should be aware that Oracle will support VMware explicitly within certain industry segments. One example is pharmaceutical, where Oracle will provide support and certification of Oracle applications under VMware to meet FDA requirements. This support is not advertised by Oracle, and the certification is behind the Oracle firewall. Access to this certification is expensive.
As well, our research indicates that a large portion of practitioners is pursuing a virtualization strategy even without Oracle’s blessing and realizing significant business benefit.
Negotiating VMware support from all ISV Software
It is important to set a clear policy and explain to all internal departments and ISVs that the IT objective is to move operational systems to VMware, because it provides a more cost effective and higher availability environment. The best time to get that support from ISVs is during the selling motion. Where possible, set a policy that VMware support is a prerequisite. The next best position is a commitment to future support. Some software providers such as IBM already provide full support for all software running under hypervisors such as VMware, and can be used as an example in negotiations. For more detail on negotiating with Oracle, read Wikibon’s paper entitled “Oracle Negotiation Myths and Understanding Virtualization Adoption in Oracle Shops”.
Building a V2P Capability for Support
Sometimes to provide support, Oracle and some other ISVs will require users to recreate a problem in a non-virtualized (physical) environment. In practice this is not an issue if the problem is previously known, but issues can arise where Oracle or other software vendors insist on recreating the problem on a physical machine. Three of six sites (50%) that Wikibon spoke to in depth reported that Oracle had asked for reproduction of the problem on a physical configuration. Although there is a temptation to rail against vendors asking for this, Wikibon recommends that organizations be prepared in advance to perform this task. From the ISV’s perspective this is not unreasonable as it needs to ensure the problem can be isolated to its software and not, for example VMware.
There are a number of excellent tools from EMC, IBM (e.g., Tivoli Provisioning Manager for Images) and others for moving application environments from Virtual to Physical that can accelerate the migration from V2P and back again. The capabilities and process should be put in place and tested, and can be used when necessary to reduce the time for support from Oracle and ISVs. It can also reassure lines of business that support can be obtained if necessary.
Setting Standards for Production Oracle Database Systems
For development environments being able to change the system setup on a dime is extremely useful. For operations staff responsible for large-scale production systems, change is an anathema.
Production systems under VMware should use the same best practices as physical systems to ensure that change control standards are in place and followed. The use of a best practices management system (e.g., IBM’s Tivoli provisioning manager using the Open Virtualization Format (OVF), or tools with similar functionality) for building the virtual infrastructure and ensuring that no unauthorized change has been made to the production systems is boring but extremely important and fundamental to best practice.
VMware Performance Overheads
Table 1 shows the same order-entry benchmark using Oracle run under VMware and Natively. It shows that an additional 18% of throughput could be obtained if workloads under VMware were run natively.
Source:Wikibon 2Q 2011 re-presented from data derived from Tables 1-5 in "Virtualizing Performance-Critical Database Applications in VMware® vSphere™" downloaded 1/27/2011
Configuring the Servers for VMware
Use the best equipment for production Oracle databases under VMware. VMware works best on large new processors with plenty of RAM. Table 1 shows there is a loss of a potential additional 18% of processor performance when oracle workloads are run under VMware on new Intel servers. This is insignificant against the savings from driving these servers harder in consolidation environments, and for reducing the cost of providing a high availability solutions. However these overheads could be significant for very high performance systems that require multiple large servers.
Carefully Configuring Storage
In a recent study, Wikibon found that the greatest cause for database performance problems under VMware originated from incorrect storage configurations. As with processors, Table 1 shows there is a small but real VMware overhead for IOPS, throughput and latency. Database administrators are particularly sensitive to latency, especially for high performance transaction systems with high locking rates. Oracle RAC systems and the database system in Microsoft exchange can be very sensitive to increases in IO latency.
The choice of storage array is important, and additional performance and functionality is needed to compensate for the overhead; it is important that storage provisioning not be skimped. Storage arrays should include VAAI support for advanced management and performance capabilities. Users should be aware that all VAAI integration is not created equal and users should understand the timing of code releases, maturity of integration and specific nuances of array exploitation. Even more important in the context of this discussion however is support from the array vendor or partner for configuration of the VMware storage for Oracle databases.
The reality is that if anything goes wrong, the storage system will be guilty until proven otherwise. Installations should ensure that the storage management tools on both VMware and the array can work together to show latency and throughput by application/database on virtual machines, as well as the ability to drill down accurately to the physical disks themselves.
Virtual Networks for Databases
Virtualization also has an impact on networking and databases have some special requirements. Databases in general and virtual networks specifically have bandwidth requirements that require architects to look at fabric architectures that allow for high performance traffic between servers. Mobility such as VMware vMotion can be used, but some environments (especially Oracle RAC) have limitations on the latency that is acceptable. Performance and latency are important metrics for database environments, so users should look for networking solutions that provide simple management of these metrics and QoS.
Migrating Test and Development First
Most installations have already migrated test and development to a virtualized environment. Of particular value are the speed of setting up virtual environments, the very high efficiency of consolidation, and the ability to test systems quickly and efficiently. The use of virtualization can significantly shorten the elapsed time for development, and for this reason alone the business case for earlier realization of value is overwhelming. The only area on debate is the testing of database systems that will be deployed on physical servers. Some professionals advocate that most of the testing should be done in the environment that will be used for production.
Ensuring that Virtualized Production Database Systems Work Well
Many installations were too enthusiastic too early, and tried to migrate large database systems to VMware without adequate testing. The “lets try it and see if it works” approach did not work. The memories of line of business and operations staff (particularly database administrators) are long, and these early setbacks have been an inhibitor to expansion of the virtualization of systems. Moving too quickly and any failures will aggravate these trust issues.
Wikibon recommends that confidence in virtualized Oracle systems be established by taking a standard project approach and properly testing each system before going into production. Sign-off by all the interested parties (line of business, database administrators, development etc.) and all the issues such as support, certification, ability to fall-back to physical, testing of new ways for business continuance should be fully documented. The feedback part of the process to stakeholders is very important:
- Feedback that the systems are getting the resources the lines of business are “paying” for, and that there is sufficient buffer of infrastructure resources to meet peaks without wholesale rebalancing of production systems;
- Feedback that the savings in resource, support levels and additional availability are being achieved.
Although this approach will be slower to begin with, it will allow for much faster adoption of production virtualization as confidence, competence and trust are built up over time.
It is likely that there will be some systems that cannot be migrated over to a virtualized environment for the foreseeable future. However, the de facto standard should be that all future systems should be virtualized, and a strong business case is required for exceptions.
Avoiding Expectations that VMware will reduce Oracle License Costs
Oracle pricing is value driven, as are most ISV software companies. ISVs adapt their licensing schemes to reflect their value. Oracle’s database products are excellent and have high value. Oracle’s policy towards soft partitioning (i.e., VMware) is clear in its policy statement “Soft partitioning is not permitted as a means to determine or limit the number of software licenses required for any given server.” In theory, the use of VMware could reduce the number of servers running Oracle. In practice, expect Oracle to negotiate aggressively and change its licensing terms to preserve revenue.
Tactical use of VMware can reduce Oracle license costs. Sometimes high cost elements such as Oracle RAC can be avoided by the use of lower cost availability features from VMware (e.g., Site Recovery Manager), which may be a better fit for the business continuity requirements of the application. However, don’t expect those saving to be carried forward into the next year’s budget, especially if an Oracle Enterprise License Agreement (ELA) is in place.
Creating an Alternative to Oracle
The functionality and performance of Oracle Databases (particularly transaction databases) are excellent, and are the de facto standard in many IT organizations. Wholesale migration from Oracle to other database platforms is an expensive undertaking, and is likely to reduce significantly the IT value delivered to the organization during a migration period.
However, Oracle is currently the most unhelpful ISV in supporting virtualization of database and application products. This is in stark contrast to the stance of many of Oracle’s software competitors. Microsoft has a similar set of policies, but in practice Wikibon members report that good support is given for SQL Server when virtualized, even when using products other than Hyper-V. IBM provides full support for almost all IBM software products under VMware , including all IBM databases (e.g., DB2). Wikibon members from larger installations that demonstrate a willingness to invest in pilot projects to examine the feasibility of migration to (say) DB2 have indicated a marked increase in willingness from Oracle to negotiate support and better pricing.
Where feasible, Wikibon recommends that installations openly set up a project to evaluate and migrate Oracle to other databases that are fully supported under VMware. Examples might include the use of EMC’s Greenplum or IBM’s Netezza for big data analytic systems, and SAP with DB2 for a transactional system.
Wikibon believes it is likely that Oracle will grudgingly extend its support for databases and applications under VMware over time. However, Wikibon also notes that some large organizations (particularly in the consumer products sector with large SAP systems) are migrating all databases from Oracle to DB2.
Creating a Support Environment Conducive to Virtualization
One of the consistent themes and recommendations to their peers that Wikibon heard from senior managers during our investigation was the need to rethink support in a virtualized environment. The traditional approach of deep silos of expertise for servers, storage, networking, virtualization and database administration was an inhibitor to working effectively together to resolve issues.
Organizations that have significant production VMware workloads are moving to a flatter organization with fewer highly skilled cross-functional staff. There is also a drive to move towards implementing complete hardware/software stacks as a single SKU for both purchasing and maintenance, which helps to reduce the support staff load.
Action Item: Wikibon recommends that organizations do not wait for Oracle to announce support for virtualization but to take an aggressive yet pragmatic approach, moving towards virtualization as the standard for all production systems.
Footnotes: WMware best Practice Guide for Oracle Databases on VMware
