VCE-101: Oracle On VMware Without Limits

After a brief hiatus I am very eager to return to the ‘Virtualization Changes Everything’ series, and today’s post is an impromptu addition to our syllabus. Recently fellow VMware vExpert Steve Kaplan of INX published a rather thought provoking post rallying for the acceleration of the transformation to a 100% virtualized datacenter. Steve waxes poetic advocating acquisition decisions spanning compute, storage and network should be driven by their contribution to data center virtualization success and I would encourage everyone to read it.

In today’s post I’d like to highlight and expand upon the following comment in Steve’s post:

‘Creativity overcomes most obstacles to a fully virtualized data center such as the minority of software manufacturers still refusing to support their applications on VMs. An easy resolution for organizations running vSphere over NFS on NetApp is to FlexClone a Virtual Machine's virtual disk into a LUN and simply present to a physical server. Voila, instantaneous V2P.’

Daunting Restrictions

Customers have shared with me that their understanding of Oracle’s support is restricted to issues known to occur with deployments on physical servers and should the issue remain unresolved the customer may be directed to their virtualization vendor and/or be asked to migrate their databases to physical servers.

These comments appear validated with Oracle’s official support statement:

‘Oracle has not certified any of its products on VMware virtualized environments.’

For most of us (minus the bold), the thought of adding complexity to the support process has stalled the migration of Oracle databases into the virtual data center.

Overcoming Limits

NetApp can help mitigate the support concerns around deploying Oracle on VMware by leveraging FlexClone as a part of the support process. For those of you unfamiliar with FlexClone, it is provides immediate zero-cost clones of files, volumes, and LUNs.

It is the cloning engine that enables the NetApp Rapid Cloning Utility, Quest vWorkspace, and the Citrix StorageLink Adapter for XenServer.

In order to for us to consider how FlexClone can simplify and expedite the resolution of a support case we need to define how one may deploy Oracle in a virtual machine.

Scenario 1: Oracle deployed on VMDKs on VMFS

In this architecture customers can leverage FlexClone to provide instant clones iof the datastores containing the VM in question in order to validate the support process prior to applying these steps to the production system. Should the issue persist within the VM, a customer would need to consider copying the Oracle data to a physical server in order to continue the support process.

Obviously the creation of VM and datastore clones is useful in the support process but this design is not the most compelling when aligned with oracle's support position.

Scenario 2: Oracle deployed on VMDKs on NFS

With this design customers have two support options. First, they can leverage FlexClone to provide immediate VM clones in order to validate the support process prior to applying these same steps to the production system.

In addition, and as Steve pointed out, this architecture allows customers to instantly clone the virtual disks as LUNs which allows for their access with a physical server.  This instant V2P process provides a simple and fast means to continue to test and verify a prescribed course of action in the event the corrective actions have not returned favorable results within a VM.

This functionality is truly unique to NetApp and I will cover this process in the technical details section.

Scenario 3: Oracle deployed on RDMs

This design almost mirrors scenario 2 in terms of the options available to customers.  FlexClone can provide instant zero-cost VM clones and and RDMs are LUNs,they can be coned for direct access by a physical server as in scenario 2.

RDMs should be strongly considered for those deploying Oracle on VMware in a Fibre Chanel environment.

Scenario 4: Oracle deployed over dNFS

Before I dive into this one, if you are unfamiliar with Oracle over dNFS check out this post by Nick Howell which was published in the VMware Communities.

This architecture also provides customers with two options. Like the previous scenarios customers can instant clones of both the VM and of the Oracle network file systems in order to validate the support process in a non-production VM.

As the Oracle database is stored on a network file system clones can be created and which provide immediate access for physical servers in the event such support steps are required.

Let’s Get into the Technical Details

As described in scenario 2, a NetApp FlexClone can clone a VMDK into a LUN without requiring the data to be copied, and I’d like to show you how. This process must be completed by a storage admin, as the required commands are only available via the command line interface.  (I would add admins with basic shell scripting skills could leverage ONTAP's RBAC to provide automation for DBAs requiring automation in the event of a support case.)

Step 1: Identify the Virtual Disk(s) you want to clone

This can be accomplished easily in vCenter. Select the VM, right click and select edit settings. Highlight the virtual disk and VMDK and its path will be identified.

Remember: vCenter will share the ‘dot’ vmdk file, which is a descriptor file. We want the data file, or the ‘dash flat’ vmdk file.

Step 2: Clone the Virtual Disk

Connect to the CLI of the FAS, vSeries, or N-Series array. In our example we will assume that FC, FCOE, or iSCSI is already running and you have an igroup created for your physical server.

In addition you will need a snapshot to base the clone off of. If you have SnapManager for Oracle take a snapshot, if not then place Oracle into hot backup mode and create the snapshot.

On the array run complete the following commands:

• Set the mode to advanced

• Identify the path to the -flat.vmdk on the array

• Create FlexClone of the Original VMDK

• Convert the Cloned VMDK into a LUN

• Map the LUN to a physical server

Note: this last step can be completed in FilerView or Systems Manager if one prefers

Step 3: Scan the storage adapter/bus on your physical server and run your tests!

In Closing

I’m confident that Oracle will continue to enhance its support for running on VMware (and Hyper-V), but customers don’t need to skip virtualizing their databases until that day to arrives just because support may require validation on a physical server.  Virtualization technology and deployment architectures exist that make this V2P testing a snap.

The essence of the VCE series is to share how storage virtualization technologies are as critical as virtualizing one’s servers and network, and I hope that this evening’s post demonstrates what is available with NetApp, and our Star Partners like INX; Customers can implement 100% virtualized datacenters without limits or concerns around support restrictions.

Comments

[Steve Jones]

I read the post and I am truly amazed. I know I heard it said that such could be done — but I couldn't wrap my head around the mechanics of making this happen.

The implications are staggering. This means that our customers, when hosted on NetApp storage, can at a moment revert to a physical realm in order to address just about any issue in just about any scenario — with ZERO impact to the production environment.

Question: Is anyone aware of any other storage vendor that has this same capability to convert a VMDK?

Comment: I assume that this process cannot be easily applied to the boot "disk" due to driver issues.

[twitter.com/that1guynick]

@Steve, you could do a tricky boot-from-SAN, but the easiest way would be to have a physical box on standby, with a comparable version of Oracle (same patch level) installed and powered down, waiting to mount your luns/disks to it.

One thing I would add, especially for NFS/dNFS, is that to clone your vmdk's, requires a VOLUME-LEVEL snap, i.e. you have to mount the entire datastore in which your VMDK's reside. One of the beauties of NFS is how well it dedupes and scales, so it behooves you to cram everything into one large datastore (check volume size limits for dedupe compatability!)

I found that the more I crammed into one datastore, I took a negligible performance hit, and increased my dedupe %'age.

Point is, these methods work, but sometimes you can't remount ANOTHER 1-2TB volume. I would almost go through the effort of spinning up another smaller volume, mount to vmware, svmotion the vmdk's to it, THEN snap. Seems...."safer."

It is fine to store your OS vmdk for linux/solaris in this big massive datastore, but your oracle bin/data/log/tmp volumes are still just going to be typical flexvol's on your storage that you mount via fstab/vfstab, with no regard to vmware.

This scenario also makes for easy support scenarios. Have another physical box laying around, install same patch level oracle, copy over your $ORACLE_HOME, umount NFS from VM, and remount your NFS mount points.

I honestly don't know that I would ever use these methods for a V2P support scenario, but with SMO+Flexclone, I could easily restore a copy of the database somewhere else (i.e. physical), which seems worlds easier to me. Correct me if I'm wrong, please!

-Nick

[Vaughn Stewart]

Nick - thanks for chiming in on this topic. Obviously you are in the vanguard when it comes to virtualizing Oracle.