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
