Oracle SQL Server

Database as a Service (DBaaS) on VMware Cloud infrastructure with vVOLs (Part 1 of 2)

With the unstoppable rise of open-source databases, businesses are adopting multiple database management system types to power their applications. This creates the complex challenge of ensuring all infrastructure components are organized, compatible, and accessible to avoid mission-critical application failures, and while adopting these new databases and technologies, DBA’s are expected to do more with less resources at the ready. There is a need for public cloud like DBaaS in hybrid cloud environments. We will look at how VMware vVols can greatly enhance DBaaS showcased by a partner solution from ScaleGrid. ScaleGrid is a VMware partner providing a DBaaS platform for both on-premises and the cloud supporting the commonly used legacy and modern databases.


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.

  1. 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
  2. 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
  3. 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.
  4. Availability: Improve reliability of applications by making them highly available with failover protection and minimal downtime.
  5. 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.


Legacy storage is a black box

Figure 1: 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 dedicated VVols in the storage

Figure 2: 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 Storage vs vVols for snapshots

Figure 3: 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

In part two of the blog series, we will look at the ScaleGrid DBaaS platform for a typical database platform like PostgreSQL on vSphere with vVols and show how DBAs can be empowered with the tools they need to secure, manage and scale your deployment on-premises.