An oft debated topic – whether to use RDM’s or vmdk’s for Oracle workloads – The Battle ranges on ( theme captured in one of classic rock band Deep Purple 90’s releases ).
This topic of discussion comes up in customer & partner conversations who are have increasing large Oracle workload footprint and who are struggling with the various limitations of RDM’s.
Business Critical Oracle Workloads have stringent IO requirements and enabling, sustaining, and ensuring the highest possible performance along with continued application availability is a major goal for all mission critical Oracle applications to meet the demanding business SLA’s, all the way from on-premises to VMware Hybrid Clouds
Business-critical databases is also among the last workloads to be virtualized primarily because of the challenges posed as workloads grow and scale especially with Day 2 operations.
Meeting strict business SLAs for performance, managing rapidly growing production databases, and simultaneously reducing backup windows and their impact on system performance often force DBAs to delay virtualization of business-critical databases and workloads. Frequent demands for database cloning and refreshing further complicate matters.
Making the appropriate choice of storage for the Oracle workloads, based on existing infrastructure, operational efficiencies, skill sets etc, will ensure that these operations are streamlined, efficient and repeatable thus freeing up much needed DBA & Infrastructure team cycles to be able to focus on other important tasks.
Key points to take away from this blog
This blog is a high-level discussion of pros and cons of using RDM over VMDK’s and how VMware Virtual Volumes (vVols) helps solves all those issues.
Making the appropriate choice of storage for the Oracle workloads, based on existing infrastructure, operational efficiencies, skill sets etc, will ensure that these operations are streamlined, efficient and repeatable thus freeing up much needed DBA & Infrastructure team cycles to be able to focus on other important tasks.
VMware Raw Device Mapping (RDM)
Raw device mapping (RDM) provides a mechanism for a virtual machine to have direct access to a LUN on the physical storage subsystem.
An RDM is a mapping file in a separate VMFS volume that acts as a proxy for a raw physical storage device. With the RDM, a virtual machine can access and use the storage device directly. The RDM contains metadata for managing and redirecting disk access to the physical device.
You can use RDMs in virtual compatibility or physical compatibility modes. Virtual mode specifies full virtualization of the mapped device. Physical mode specifies minimal SCSI virtualization of the mapped device, allowing the greatest flexibility for SAN management software.
More on VMware RDM’s can be found here.
VMware VMFS and vmdk’s
To store virtual disks, ESXi uses datastores. The datastores are logical containers that hide specifics of physical storage from virtual machines and provide a uniform model for storing the virtual machine files.
The datastores that you deploy on block storage devices use the native vSphere Virtual Machine File System (VMFS) format. It is a special high-performance file system format that is optimized for storing virtual machines.
More on VMware VMFS datastores can be found here.
VMware Virtual Volumes (vVols)
VMware vSphere Virtual Volumes, also known as vVols, virtualizes storage devices by abstracting physical hardware resources into logical pools of capacity. The Virtual Volumes functionality changes the storage management paradigm from managing space inside datastores to managing abstract storage objects handled by storage arrays. With Virtual Volumes, an individual virtual machine, not the datastore, becomes a unit of storage management, while storage hardware gains complete control over virtual disk content, layout, and management.
Virtual Volumes maps virtual disks and their derivatives, clones, snapshots, and replicas, directly to objects, called virtual volumes, on a storage system. This mapping allows vSphere to offload intensive storage operations such as snapshot, cloning, and replication to the storage system.
VMware Virtual Volumes are a well-orchestrated system of RDM’s without the management overhead of RDM’s (Physical SCSI LUN limit per ESXi server) but with all the capabilities and features provided by vmdk’s
More on VMware Virtual Volumes (Vols) can be found here.
RDM v/s VMDK – Performance Concerns
This has been an oft debated topic – whether to use RDM’s or vmdk’s for Oracle workloads.
Let’s start with addressing the biggest elephant in the room – Performance.
Oracle DBA’s often state that using RDM’s is more beneficial than using vmdk’s because
- a VM is directly accessing a LUN
- there is a natural tendency to think that a RDM would provide better performance as a VM is reading/writing directly to a LUN and not having to deal with the overhead of the VMFS file system
While you might think that it’s not the case, RDM’s provide the same performance levels as a VM on VMFS does, the difference is minor.
VMware Engineering performed testing and published whitepaper of RDM v/s VMDK performance difference.
- vSphere 5.1 – VMDK versus RDM – Blog by Mark Achtemichuk , VMware Performance Engineering
- Performance Characteristics of VMFS and RDM VMware ESX Server 3.0.1 – Published Dec 7, 2007
- Performance Characterization of VMFS and RDM Using a SAN ESX Server 3.5 – Published Feb 13, 2008
This discussion can be summarized in the table below –
Hang on !!!! OLD INFORMATION – Show me something new !!!
Explanation – Yes, we realize the link above are old and for ESX 3.x / 5.x but we have a reason for doing so – we have ALREADY proved in ESX 3.x / 5.x that “really no performance difference between VMDK and RDM and this holds true for all versions of our platform. +/- 1% is insignificant” – that means we don’t have to prove that in every release of VMware vSphere platform.
Despite the above , the discussion of RDM v/s VMDK comes up and hence this blog – QED.
The key takeaway from all the above publications is:
- There is really no performance difference between VMDK and RDM and this holds true for all versions of our platform. +/- 1% is insignificant in today’s infrastructure and can often be attributed to noise.
- The decision between VMDK and RDM is now one of architecture or functional requirement and without a special need, VMDK should be used by default.
- VMDK’s provides all the performance and flexibility you require to virtualize your most critical business applications.
RDM use cases
When we talk about RDM’s, there still are some use cases where long before, we thought it made sense to use RDM’s over vmdk’s but that may not hold true now with the latest advancements of VMware vSphere platform and release of new features:
This discussion can be summarized in the table below –
The RDM v/s VMDK use case is further discussed in VMware vSphere VMFS Technical Overview and Best Practices.
So if the use case is not NPIV, we have established so far, we don’t need RDM’s!!!
RDM v/s VMDK – Operational concerns
Lets now focus on some of the RDM v/s vmdk operational concerns we have seen so far and see how VMware Virtual Volumes (vVols) can help with mitigating some of those challenges.
To reiterate, VMware Virtual Volumes are a well-orchestrated system of RDM’s without the management overhead of RDM’s (Physical SCSI LUN limit per ESXi server) but with all the capabilities and features provided by vmdk’s
This discussion can be summarized in the table below –
Summary
In evaluating RDM’s v/s VMDK’s and with VMware Virtual Volumes (vVols) as an option to consider –
- RDM v/s VMDK Performance Concerns – we established that there is really no performance difference between VMDK and RDM and this holds true for all versions of our platform. +/- 1% is insignificant in today’s infrastructure and can often be attributed to noise
- RDM Use cases – NPIV seems to be the only remaining use case for RDM , apart from that, there is no real need for RDM’s
- RDM Operational concerns – VMware Virtual Volumes (vVols) eliminates noisy neighbor effect, provides Granularity of DB operations just as RDM’s did and in addition provides increased limit on the number of vVols , surpassing the current SCSI limit of 1024 for RDM’s.
VMware vSphere Virtual Volumes (vVols) addresses the business challenges discussed in the previous section regarding business-critical databases’ day-to-day operations like
- Backup & Restore
- Cloning
- Database Refreshes
- Database Provisioning
The “Virtualizing Oracle Workloads with VMware vSphere Virtual Volumes on VMware Hybrid Cloud – REFERENCE ARCHITECTURE” can be found here.
Acknowledgements
This blog was authored by Sudhir Balasubramanian, Senior Staff Solution Architect & Global Oracle Lead – VMware.
Conclusion
This blog is a high-level discussion of pros and cons of using RDM over VMDK’s and how VMware Virtual Volumes (vVols) helps solves all of those issues.
Making the appropriate choice of storage for the Oracle workloads, based on existing infrastructure, operational efficiencies, skill sets etc, will ensure that these operations are streamlined, efficient and repeatable thus freeing up much needed DBA & Infrastructure team cycles to be able to focus on other important tasks.
VMware vSphere Virtual Volumes (vVols) addresses the business challenges discussed in the previous section regarding business-critical databases’ day-to-day operations like
- Backup & Restore
- Cloning
- Database Refreshes
- Database Provisioning
All Oracle on VMware vSphere collaterals can be found in the url below.
Oracle on VMware Collateral – One Stop Shop
https://blogs.vmware.com/apps/2017/01/oracle-vmware-collateral-one-stop-shop.html
