Deploying Oracle Workloads on vSAN HCI Mesh Compute Cluster – Disaggregating Compute and Storage

The previous blog No downtime Storage vMotion of Oracle RAC Cluster using shared vmdk’s with multi-writer attribute from one vSAN to another vSAN Cluster using VMware HCI Mesh demonstrated how we can achieve Storage vMotion of Oracle RAC Cluster using shared vmdk’s with multi-writer attribute ONLINE , with NO downtime, from one vSAN to another vSAN Cluster using VMware HCI Mesh.

The previous blog also touched on briefly a very important use case for Oracle workloads on any architecture, Oracle Licensing.

With vSAN HCI Mesh introduced in vSAN 7 Update 1 capability, one could seamlessly and transparently

• move Oracle compute into smaller density (Physical sockets / cores) servers in a different vSAN cluster, thereby significantly reducing their Oracle Licensing costs
• move the Storage for Oracle workloads into a different vSAN cluster, if needed, where excess storage capacity is available

With vSAN 7 Update 2, VMware introduces a significant new capability to vSAN HCI Mesh where traditional vSphere clusters can now mount a remote vSAN datastore.

Yes, we have a winner

This blog demonstrates how we can provision separate Compute and Storage resources for Oracle workloads on vSAN 7 Update 2 Cluster, disaggregating Compute and Storage, with Compute on traditional vSphere Clusters / vSAN Clusters and Storage on vSAN Storage , with a focus on reducing Oracle licensing using HCI Mesh Compute Clusters.

VMware vSAN HCI Mesh Compute Clusters

VMware introduces a significant new capability to vSAN HCI Mesh. In vSAN 7 Update 2, traditional vSphere clusters can mount a remote vSAN datastore. HCI Mesh compute clusters can consume storage resources provided by a remote vSAN cluster, in the same way that multiple vSphere clusters can connect to a traditional storage array.

HCI Mesh compute clusters use native vSAN protocols for maximum efficiency and affords the customer the ability to easily meet a broad variety of use cases. Most importantly, HCI Mesh compute clusters do not need any vSAN licensing

More information on HCI Mesh Compute Clusters can be found in the VMware vSAN HCI Mesh Tech Note.

More information on vSAN HCI Mesh Considerations can be found in the blog vSAN HCI Mesh Considerations.

HCI Mesh Compute Cluster Setup

We have 2 vSphere Clusters attached to the same Virtual Center.

• Source vSAN Cluster – A vSAN Cluster ‘BCA-SiteC’ VMware ESXi, 7.0.2, 17867351, with vSAN datastore ‘BCA-SiteC-vSAN’
• Target traditional vSphere Cluster – vSphere Cluster ‘GPU1’ VMware ESXi, 7.0.2, 17867351

Source vSAN Cluster – ‘BCA-SiteC’ – the vSAN Cluster has 4 hosts , each host has 2 sockets, 24 cores per socket with 384GB RAM.

Source vSAN datastore ‘BCA-SiteC-vSAN’

Target Traditional vSphere Cluster – ‘GPU1’ – the vSphere Cluster has 4 hosts , each host has 2 sockets, 10 cores per socket with 1TB RAM.

The vSAN HCI Mesh Considerations found in the blog vSAN HCI Mesh Considerations. lists out the various requirements that’s is needed to mount a vSAN datastore on a HCI Mesh Compute Cluster

The steps to setup a vSAN HCI Mesh Compute Cluster is shown in the blog post What’s New with vSAN 7 Update 2.

The screenshot below summarizes the setup of vSAN HCI Mesh Compute Cluster as well.

The next step is to mount the remote vSAN datastore ‘BCA-SiteC-vSAN’ on the vSphere Cluster ‘GPU1’ which is now setup as a vSAN HCI Mesh Compute Cluster.

The screenshot below summarizes the steps needed to mount the remote vSAN datastore ‘BCA-SiteC-vSAN’ on the vSphere Cluster ‘GPU1’ which is now setup as a vSAN HCI Mesh Compute Cluster.

The remote vSAN datastore ‘BCA-SiteC-vSAN’ is mounted on the target vSphere cluster ‘GPU1’ which is setup as a vSAN HCI Mesh Compute Cluster.

Test Case

The purpose of the blog is to demonstrate how we can provision separate Compute and Storage resources for Oracle workloads on vSAN 7 Update 2 Cluster, disaggregating Compute and Storage, with Compute on traditional vSphere Clusters / vSAN Clusters and Storage on vSAN Storage, with a focus on reducing Oracle licensing using HCI Mesh Compute Clusters.

The HCI Mesh Compute Cluster Setup demonstrated how we can disaggregating Compute and Storage, with Compute on traditional vSphere Clusters in this case (also vSAN Clusters)  and Storage on vSAN Storage.

We can now vMotion the Oracle workloads compute from source vSAN Cluster ‘BCA-SiteC’ to target traditional vSphere Cluster ‘GPU1’ , leaving the Oracle workloads storage still on source vSAN datastore ‘BCA-SiteC-vSAN’.

We will consider 2 use cases here on HCI Mesh Compute Cluster

• Deploying / Migrating Single Instance Oracle VM
• Deploying / Migrating Oracle RAC VM’s

Deploying / Migrating Single Instance Oracle VM using HCI Mesh Compute Cluster

A VM ‘Oracle19c-BM’ currently in source vSAN Cluster ‘BCA-SiteC’ with storage on vSAN datastore ‘BCA-SiteC-vSAN’ is chosen.

Currently both Compute and Storage is on the vSAN Cluster ‘BCA-SiteC’.

Compute vMotion the VM ‘Oracle19c-BM’ from source vSAN Cluster ‘BCA-SiteC’ to target traditional vSphere Cluster ‘GPU1’  – the VM ‘Oracle19c-BM’ Compute will now relocate to target traditional vSphere Cluster ‘GPU1’ with storage still on source vSAN datastore ‘BCA-SiteC-vSAN’.

After Compute vMotion, the VM ‘Oracle19c-BM’ , VM Compute is now on target traditional vSphere Cluster ‘GPU1’ with Storage still on source vSAN datastore ‘BCA-SiteC-vSAN’

We can perform similar vMotion operations to move the remaining Single Instance Oracle workloads off from the vSAN cluster to the traditional vSphere Cluster ‘GPU1’. This results in Oracle workloads using far less compute.

Deploying / Migrating Oracle RAC VM’s using HCI Mesh Compute Cluster

Oracle RAC VM’s ‘rac19c1’ and ‘rac19c1’ are currently in source vSAN Cluster ‘BCA-SiteC’ with storage on vSAN datastore ‘BCA-SiteC-vSAN’.

Compute vMotion both RAC VM’s ‘rac19c1’ and ‘rac19c2’ from source vSAN Cluster ‘BCA-SiteC’ to target traditional vSphere Cluster ‘GPU1’.

RAC VM’s ‘rac19c1’ and ‘rac19c2’ Compute are now relocated to target traditional vSphere Cluster ‘GPU1’ with storage still on source vSAN datastore ‘BCA-SiteC-vSAN’.

Oracle Licensing Perspective

Assuming that an entire host is used for Oracle workloads –

• Source vSAN Cluster ‘BCA-SiteC’ has 4 hosts, each host has 2 sockets, 24 cores per socket with 384GB RAM
• Each vSAN host has 48 absolute cores which is equivalent to 24 Effective Oracle Enterprise Edition licenses
• Target traditional vSphere Cluster ‘GPU1’ has 4 hosts, each host 2 sockets, 10 cores per socket with 1TB RAM
• Each target vSphere host has 20 absolute cores which is equivalent to 10 Effective Oracle Enterprise Edition licenses
• Moving the Oracle VM Compute off the vSAN Cluster to the traditional vSphere Cluster results in a drastic reduction of 28 absolute cores per host which is equivalent to a drastic reduction of 14 Effective Oracle Enterprise Edition licenses (reduction in $$$$$)

Remember Oracle licensing is for Current usage of Compute (Physical Sockets (SE2)  / Physical Cores (EE) ) or NUP , not proposed futuristic usage !!! Oracle licensing DOES NOT change , whether you run Oracle workloads on a classic vSphere environment or Hyper-Converged Infrastructure or any of the VMware Hybrid Clouds.

Refer to the blog post for more information Oracle on VMware vSphere , vSAN, VxRAIL and VMware Cloud on AWS – Dispelling the Licensing myths

Summary

With vSAN HCI Mesh introduced in vSAN 7 Update 1 capability, one could seamlessly and transparently

• move Oracle compute into smaller density (Physical sockets / cores) servers in a different vSAN cluster, thereby significantly reducing their Oracle Licensing costs
• move the Storage for Oracle workloads into a different vSAN cluster, if needed, where excess storage capacity is available

With vSAN 7 Update 2, VMware introduces a significant new capability to vSAN HCI Mesh where traditional vSphere clusters can now mount a remote vSAN datastore.

All Oracle on vSphere white papers including Oracle on VMware vSphere / VMware vSAN / VMware Cloud on AWS , Best practices, Deployment guides, Workload characterization guide can be found in the url below

Oracle on VMware Collateral – One Stop Shop

http://www.vmw.re/oracle-one-stop-shop

On Demand hot extend clustered vmdk’s online without downtime – Hot Extend RAC clustered disks

 

 

 

This blog focuses on the complete list of steps to be taken to increase the size of the clustered vmdk(s) using Multi-writer flag of an Oracle RAC Cluster. This blog describes the various options using both Native Oracle tools and vSphere tools to attempt to increase the size of the Oracle RAC clustered vmdk(s).

Current restriction of shared vmdk’s using the multi-writer attribute is that Hot extend virtual disk is disallowed as per KB 1034165 & KB 2121181

 

 

 

Reclaiming dead space from Oracle databases on VMware Hybrid Platform

 

 

Dead space reclamation has always been a challenge especially with thin-provisioned volumes. Thin provisioning dynamically allocated storage on-demand to the workloads in a flexible and efficient manner.

Any database day to day 2 operations would include dropping tablespaces, dropping or resizing datafiles, truncating tables, deleting archive logs from ASM FRA diskgroup etc. .

One would expect the free space to go back to the storage free pool to be used for further allocation purposes, but that ability depends on

• How the Application reports the discarded space to the GOS (Guest Operating System)
• How the GOS reports the discarded space to underlying VMware layer
• And eventually how VMware vSphere reports the discarded space to the Storage array

 

This blog focuses on the Oracle ASM Filter Driver (ASMFD) capability to report discarded or free space of thin-provisioned vmdk’s to the GOS which eventually gets reported to the VMware datastores and the underlying Storage array.

 

 

Oracle Java on VMware Hybrid Cloud Platform – Dispelling the Oracle Java Licensing myths

This is just another blog (JAB) about Dispelling the “Galaxy Licensing” Oracle Java on VMware FUD  perpetuated by overzealous licensing and sales teams, which is in complete contrast to the reality of the actual Contractually Impactful documents.

  This blog intends to clear up the reality of how to effectively license Oracle Java workloads on VMware Hybrid Cloud ( vSphere, vSAN , VxRAIL , VMware Cloud on AWS and other VMware Cloud Platforms) and to make it a cost effective one as well.

 

 

Java Licensing Models

 

Prior to 2019, there were three Java SE products known as

• Java SE Advanced
• Java SE Advanced Desktop
• Java SE Suite

  These models required commercial users to purchase upfront licenses and pay annual support.

  Starting 2019, the above three models was replaced by two new subscription-based models

• Java SE Subscription
• Java SE Desktop Subscription

  As per this model, one no longer needs to purchase licenses upfront and pay annual support for Java SE.  Instead, one would have to pay a monthly subscription fee under one to three-year terms for server or desktop licensing and support.

 

 

No downtime Storage vMotion of Oracle RAC Cluster using shared vmdk’s with multi-writer attribute from one vSAN to another vSAN Cluster using VMware HCI Mesh

The previous blog post “Around the “Storage World” in no time – Storage vMotion for Oracle Workloads (RAC & Non-RAC) within same vSphere Cluster” addressed the following use cases of Storage vMotion of an Oracle RAC Cluster with shared vmdk(s) using multi-writer attribute .

 

The following uses cases were addressed by the previous blog post for Oracle RAC clusters within the same vSphere Cluster –

• Migrate Oracle database storage from one Tier to another Tier within a storage array
• Migrate Oracle database storage from one array to another array (within and between data centers) for the same datastore type [ VMFS . NFS, iSCSI, vVOL, vSAN]
• Migrate Oracle database storage from one array to another array (within and between data centers) across different datastore types [ VMFS , NFS, iSCSI, vVOL, vSAN]

 

 

Backing up Oracle Workloads (RAC & Non-RAC) with VMware Snapshot Technology

In computer systems, a snapshot is the state of a system at a particular point in time. To avoid downtime, high-availability systems may instead perform the backup on a snapshot—a read-only copy of the data set frozen at a point in time—and allow applications to continue writing to their data. [ Wikipedia ]

This blog addresses how one can take VM level snapshot of Oracle Single Instance / RAC workloads using VMware snapshot technology, keep certain caveats in mind.

 

Oracle Real Application Cluster (RAC) Support on VMware Clouds

 

As of December 9th, 2020, VMware recommends that anyone currently running OR planning to run, an Oracle Real Application Cluster (RAC) in a VMware Cloud environment, reach out to Oracle Corporation for any Oracle support related matters with RAC on our cloud platform.

 

Please reach out to your VMware representative for any clarifications on the below guidance’s.

 

PVSCSI Controllers and Queue Depth – ASM SAME and Oracle Workloads

The previous blog post ’ PVSCSI Controllers and Queue Depth – Accelerating performance for Oracle Workloads’ purpose was to raise awareness of the importance of using PVSCSI adapters with adequate Queue Depth settings for an Oracle workload.

 

This blog focuses on the implementation of Oracle SAME (Stripe and Mirror everything) technology using Oracle ASM along with using multiple VMware PVSCSI controllers with queue depth for PVSCSI controllers and VMDK’s set to maximum to achieve maximum performance for Oracle workloads.

 

 

 

 

This blog

• Is not meant to be any kind of performance study or bake off any sort
• contains results that I got in my lab running a load generator SLOB against my workload, which will be way different than any real-world customer workload, your mileage may vary
• remember, any performance data is a result of the combination of hardware configuration, software configuration, test methodology, test tool, and workload profile used in the testing. 

 

 

PVSCSI Controllers and Queue Depth – Accelerating performance for Oracle Workloads

For readers who are familiar with the Asterix and Obelix series, the magic potion refers to the potion brewed by Getafix, that gives the Gaulish warriors superhuman strength.

 

 

 

 

 

One of VMware’s magic portion for Oracle workloads is the ‘Paravirtualized SCSI Controllers a.k.a PVSCSI Controllers’ which is accelerates workloads performance on a VMware vSphere Platform.

This blog is meant to raise awareness of the importance of using PVSCSI adapters with adequate Queue Depth settings for an Oracle workload.

This blog

• Is not meant to be a deep dive on PVSCSI and Queue Depth constructs
• contains results that I got in my lab running a load generator SLOB against my workload, which will be way different than any real-world customer workload , your mileage may vary

Remember, any performance data is a result of the combination of hardware configuration, software configuration, test methodology, test tool, and workload profile used in the testing.

 

 

VMworld 2020 – Breakout Sessions , Expert Round Tables and Demos focused on Business Critical Applications (BCA)

Join us at VMworld 2020 to learn how Business Critical Apps benefit from our latest platforms  

 

 

 

 

VMworld 2020 will be a global online event starting September 29 – October 1, 2020. While the program will be adapted to fit the new digital format, VMworld will still be the place to learn about innovative new technology solutions, hear perspectives from VMware executives, dive into educational and technical content, and engage with experts across the industry ecosystem.