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.
- Reduce Application Time to Market: DBaaS gives you the ability to rapidly develop, test, and deploy new applications at a fraction of the time it used to take with legacy systems, so faster time to market new apps
- Reduce costs by optimizing infrastructure use: DBaaS increases the efficiency of both DB/application and infrastructure teams. The storage administrator will no longer need to spend time and effort on provisioning storage resources for databases. DBAs will no longer have to wait for DB resources to be allocated and provisioned. This frees up time for both the teams
- Automate Database Lifecycle Management: Database sprawl is a major problem in many companies. IT departments have difficulty keeping track of all the DB instances that are deployed. This has serious implications from licensing, data governance, and security standpoints. With DBaaS you can ensure that you have complete visibility into your database environment and enforce governance through policy-based management. Save thousands of hours through automation of database monitoring, management and maintenance operations so you can focus on product.
- Availability: Improve reliability of applications by making them highly available with failover protection and minimal downtime.
- Scalability: Scale to any size on demand by dynamically scaling databases as and when needed without underutilization or overpaying for a larger scale.
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
- Defining templates of database VMs to be available in self-service catalog
- Commissioning / Decommissioning Single Instance / Clustered databases from self-service catalog
- Cloning of Single Instance / Clustered Databases with data masking for Test / Dev / QA
- Database Refresh
- Database Backup & Restore
- Metering / Reporting
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
- High-performing storage infrastructure to ensure rapid provisioning of DBs
- Efficient data reduction to ensure storage capacity is not exhausted
- A high degree of resiliency to ensure minimal-to-no downtime
- Ease of use and management
- Different Databases have different levels of criticality and each DB needs different storage performance characteristics and capabilities
- There is a challenge trying to meet stringent SLAs for performance with slow traditional storage
- With the rapid growth of databases, the need to reduce the backup windows to meet performance & business SLAs grows as well
- With the growth databases, day 2 operations like Clone, Database Refresh from production to QA becomes a big challenge
- Using Storage-based replication, unnecessary data gets copied over even if the speed of storage-based replication is superior compared to Application based replication
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
- explains how one can achieve Scalability , Reliability and Performance with DBasS using VMware Virtual Volumes on Pure Storage for Oracle Workloads.
- highlights primary use cases for VMware Virtual Volumes (VVols) and Storage Policy Based Management (SPBM) by leveraging Pure Storage VVols technology including database backup and restore, refreshing, cloning, patching etc
- shows how DBAs can be empowered with the tools they need to secure, manage, and scale your deployment on-premises
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
A journey in Virtualizing Oracle on VMware 
You must be logged in to post a comment.