09/23/2021 | News release | Distributed by Public on 09/23/2021 12:29
Deploying and managing an Oracle DB environment is not a trivial undertaking. Oracle infrastructure tends to have stringent performance, business continuity, and backup and recovery requirements. To support these requirements, IT departments often are tasked with maintaining sprawling infrastructure for production, disaster recovery, backup, quality assurance, test, training, development, and sandbox.
Enterprise customers have identified Database-as-a-Service (DBaaS) as a key initiative that will enable higher levels of agility via rapid application development. The idea is to allow database consumers such as application developers, testers, and architects to provision databases easily using an on-demand, self-service platform.
DBaaS will greatly simplify the deployment and management of a robust Oracle environment, while delivering higher levels of efficiency and flexibility for IT departments throughout the application lifecycle-implementation, migrations, consolidations, upgrades, and ongoing maintenance , thus allowing DBA's to focus on more important pressing issues - Moving away from DBA-as-a-Service to Database as a Service (DBaaS) model.
This blog focuses on VMware Virtual Volumes (vVols) using Pure Storage and how vVols can greatly enhance DBaaS to provide higher levels of agility via rapid application development for both on-premises and the cloud for Oracle workloads on VMware Hybrid Platform.
What is Database-as-a-Service (DBaaS)
DBaaS can be defined as the ability to manage, monitor, and provision database resources on demand through self-service catalogs with minimal requirements for installation and configuration of hardware or software up front.
Core Benefits of DBaaS solution
A good DBaaS platform needs to provide developers, DevOps engineers, and database administrators (DBAs) an ability to automate daily tasks, optimize their infrastructure, and refocus their efforts on new innovations for their applications with speed and agility. In addition, the platform should support different types of databases and their capabilities.
Compelling Use cases for DBaaS
One can define DBaaS as the ability to manage, monitor, and provision database resources on demand through self-service catalogs with minimal requirements for installation and configuration of hardware or software up front. The idea is to allow database consumers such as application developers, testers, and architects and owners to provision databases easily and quickly using an on-demand, self-service platform.
Some of the use cases of Database as a Service
Critical factors for DBaaS
Time is critical for an as a service solution and it is also critical for DBaaS. Quite often the storage performance can be a limiting factor for DBaaS solutions. Traditional disk-based storage cannot meet the performance needs for DBaaS and is inherently too complicated to manage.
Some of the key DBaaS considerations include
VMware vVols ideal technology to meet DBaaS requirements
VMware Virtual Volumes or vVols enables your existing storage array capabilities to be managed via storage policy-based management (SPBM) and applied at a VM or VM disk level, all while existing in a single vVols datastore that correlates to a storage container on the array. The Guest OS file system is the native FS on the vVol itself. It is not a VMDK sitting on top of another FS such as VMFS or NFS. Each vVol is its own first-class citizen, meaning it is independent of other vVols, LUNs, or volumes. As a result, vVols match very well with First Class Disks (FCD), which are disks not requiring an associated VM. vVols also allows for a much larger scale than traditional LUNs, up to 64k per host! Plus, you don't have to manage LUNs or volumes, which would be a nightmare at scale.
Array is unaware of use of blocks. The array and vSphere unaware of each other leading to rigidity to associate unique capability at a LUN or volume level. LUNs or volumes are rigid and fixed in their capabilities. They also require a file system such as VMFS or NFS.
Traditional Storage arrays are a black box in a vSphere environment
With VVols, there is no file system, it's inside each VVol that a file system is created and that file depends on the OS or the VVol function. IE config, swap, etc. With regards to the capabilities, generally a LUN or volume is provisioned with a specific set of capabilities and that isn't easily changed without create a new LUN or volume and migrating the data.
Each VM has its associated vVols at the array level
With VVols, changing the capability is simple, with the simple change of an SPBM policy, the capability is changed, no storage vMotion or data migration needed. Depending on the array, you can even change from spinning media to all-flash with a policy change. The array then handles the performance and data migration, no admin action required. Another key aspect of VVols over traditional storage is the array and vSphere has complete insight into the data and I/O requirements. Subsequently, the array can then manage the I/O and data accordingly.
Snapshots and cloning are critical for DBaaS
With traditional storage, snapshots are managed by vSphere. Although vSphere is efficient at snapshots, typically, arrays manage snapshots in a different and more efficient manner. With typical vSphere snapshots, a secondary SESparse disk is created, and all new I/O goes to that disks. If this disk is not removed it can continue to grow even larger than the original disk. Additionally, if more snapshots are created, then the chain of VM can slow I/O as any read may end up growing though each disk looking for the data. Consequently, performance of the VM can be impacted. When the vSphere snapshot is deleted, depending on how large the snapshot is and how busy the VM is, it can take quite a bit of time to delete. This is the norm, but if a snapshot is left for a long time and grows to 10s or even 100s of GB, it could take hours to delete and impact the VM's performance while being deleted.
Traditional snapshots with VMFS versus storage level snapshots with vVols
With vVols, snapshots happen on the array and array based snapshots are point in time "pictures" of the data and take very little space. When a vVols snapshot exists, the I/O is NOT redirected and instead continues to go to the original disk or vVol. Leaving a vVols snapshot alone will not continue to grow and can be copied to another array and even used as a copy or clone of the original VM. When a vVol snapshot is deleted, the snapshot is quickly removed with no impact to the VM. Regardless of how many snapshots, up to a maximum of 32, there is no performance impact on the VM. Creation and deletion of snapshots is faster and more efficient on vVol storage due to array offloading of operations
All Oracle on vSphere white papers including Oracle licensing on vSphere/vSAN, Oracle best practices, RAC deployment guides, workload characterization guide can be found in the url below