Database Virtualization Part 1 – It’s Happening Right Now

Forget Big Data. Stop talking about Analytics. There is a trend taking place in the marketplace right now, one that is really happening rather than just being spoken about.

That trend is Database Virtualisation. Or, as my U.S. cousins would spell it, Database Virtualization. (And whilst I am loath to drop the Queen’s English in favour of American spelling, years of typing “ANALYZE TABLE …” have worn me down to the point that I can forgive the odd Z here and there…)

So why am I making this sweeping statement? What evidence is there that this is happening? For years, virtualisation and tier one databases were like oil and water. Is this now changing, and if so then why?

The answer comes from a number of factors:

• Maturity and adoption of virtualisation products
• Oracle’s support policy on virtualised databases
• The drive for consolidation and consumerisation of databases

One of the main constraints around the virtualisation of databases is I/O – in particular the latency (required for application performance) and IOPS (required for application scalability). Flash memory has arrived in the data centre at the perfect time to offer an advantage to this new trend. In fact, since the two primary markets for flash memory right now are database applications and VDI (virtualised desktop infrastructure), it seems like the logical conclusion to bring them together.

Maturity and Adoption of Virtualisation Products

Let’s face it, if you work for a medium to large organisation you probably already have virtualisation in place somewhere in the enterprise. In my role at Violin Memory I get to speak to a lot of different companies and they almost always have virtualisation technology in place for VDI, with quite a lot of them virtualising their SQL Server estates too. Oracle development and test databases are being virtualised more and more. But the production Oracle databases… the big ones with the tier one application on them… they are holding out until the bitter end. They are, as Don Bergal calls it, the last bastion of virtualization.

This is all changing now. Hypervisor products are mature, with VMware leading the pack. Oracle has its own virtualisation product, Oracle VM, which I happen to really like… not least because you can perform an online migration of a database, including RAC. It’s actually supported to move a RAC database that’s within a VM from one physical server to another whilst it is online. I never thought I would see the day. Microsoft has Hyper-V, Citrix has XenServer… the list goes on.

But it’s not just the hypervisors themselves that are maturing. There is a growing portfolio of software aimed at managing and monitoring virtualised databases. A great example is Delphix who make agile data management software which allows you to virtualise all of your “long tail” of development, test, integration and UAT environments. Delphix allows you to automatically clone your production database and create multiple virtualised copies of it, all using excellent compression algorithms to reduce the footprint required. If you look at the engineering team that Delphix have built up you can’t help but be impressed: Adam Leventhal, Kyle Hailey, Frank Sanchez (who pretty much wrote RMAN)…

Another example is Confio, who make software which allows you to accurately monitor database performance in virtualised environments. This is critical because one of the issues with virtualisation is that the new layer of abstraction added by the hypervisor can shield any resource monitoring tools running within the guest from a “true” view of resource utilisation on the host. [Kyle put a great write up of Confio on his blog here]

It’s not just newcomers that are playing the tune either. EMC (80% shareholder of VMware) recently announced the release of vFabric Data Director 2.0, their product for producing, managing and consuming virtualised Oracle databases. The trend is there for everyone to see.

Oracle’s Support Policy On Virtualised Databases

It’s a given that Oracle supports its own products on Oracle VM. That includes Oracle Linux, the database and even RAC. But what about the other hypervisors? What about the VMware, the most prominent hypervisor product and the one that many companies are already using for their non-production environments? At the time of writing, Oracle’s support policy (as stated in My Oracle Support note 249212.1) says (the red highlighting has been added by me):

Oracle has not certified any of its products on VMware virtualized environments. Oracle Support will assist customers running Oracle products on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware.

If a problem is a known Oracle issue, Oracle support will recommend the appropriate solution on the native OS. If that solution does not work in the VMware virtualized environment, the customer will be referred to VMware for support. When the customer can demonstrate that the Oracle solution does not work when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.

At first glance that seems a bit harsh – effectively Oracle is saying that they may decide to withdraw support unless you can prove any issue is not caused by VMware. However, the statement that Oracle does not certify its products on VMware is probably not that unfair, after all the process of certifying each Oracle product is very complex and time-consuming. And if Oracle spent all of those cycles certifying their massive software portfolio on VMware then they would probably have to do the same for Hyper-V (also not certified by Oracle) and every other hypervisor. You decide, but personally I think it’s reasonable. Don’t forget that there is a world of difference between something not being certified and not being supported though.

Actually, Oracle has softened its position on support regarding VMware. Until 11.2.0.2 came out in November 2010, it was unsupported to run RAC on VMware. This change is therefore quite significant – and in my view points to Oracle acknowledging that the shift to virtualisation is inevitable.

The bit about withdrawing support until “the customer can demonstrate” that the problem is still present without VMware is the thorny issue. Anyone considering using virtualisation on their production environment has to be a bit concerned by that. My experience is that Oracle Support will always work to resolve any issue and not use the “Sorry, it’s on a VM” excuse to leave you stranded… but the risk has to be registered all the same. VMware have their own support service which will wrap around that provided by Oracle and offer “total ownership”. And the truth is, as with all things related to Oracle Support (and any enterprise support organisation), the bigger you are as a customer, the more power you have to bend, bypass or just downright break the rules and still get what you want.

Drive for Consolidation and Consumerisation

Consolidation and consumerisation are two related trends which I have already discussed in some depth before. Consolidation is all about reducing complexity and cost through the use of standardised environments. There are some significant resource challenges around consolidation, but flash memory allows for many of them to be removed, or at least controlled. In fact, once you look at the arguments, flash memory is the only sensible storage option on which to build a consolidation platform.

Consumerisation is about the agility angle, about turning database into a service which is consumed by its users. That means automatic or self-service provisioning, defined service levels, maybe even cross-charging. If I could bring myself to say it, it means creating a private cloud.

Virtualisation is the ideal solution for consolidating and consumerising databases. It already has the provisioning and cloning technologies required to create a Database-as-a-Service platform. The independent nature of each operating system in a VM allows for a certain amount of protection, particularly during Oracle upgrades. And there are HA benefits to being able to migrate the entire VM off of the physical host when maintenance is required (ever seen what happens when a bit of planned hardware maintenance goes horribly wrong?).

No matter which way you look at it, virtualised databases are coming. You need to be ready for them.

In part 2 of this blog series I will discuss the challenges of database virtualisation. In case you can’t wait, they are: 1) Oracle licensing, 2) Latency (the bit where I say that you need flash), 3) I/O (the other bit where I say that you need flash), and 4) whether to spell it with an S or a Z.