We now have a solid foundational understanding of what cloud computing is and how it applies to DBaaS. In this article, we outline the specifics around services as they relate to DBaaS and what they mean to end users as well as to the provider in a cloud computing environment.
The services offered by the DBaaS provider to the end user fall into three main categories: provisioning, administrative, and reporting. Some of these services are optional, and others are mandatory.
Provisioning services provided to end users include some or all of the following:
- The ability to requisition new databases.
- The ability to choose database options as needed (partitioning, advanced security, High Availability with Real Application Cluster, etc.).
- The ability to add resources (storage, CPU, network bandwidth, etc.) to existing databases. This includes the ability to scale up as well as to scale down.
- Database backup capability using provided backup resources.
Administrative services include some or all of the following:
- The ability to perform on-demand database restores and recoveries.
- The ability to perform database clones using existing database backups.
- Database monitoring capabilities, including basic 24/7 incident reporting management capabilities.
Reporting services include some or all of the following:
- Performance management, which is the ability to look at a database from a performance and tuning standpoint, whether in the form of reporting or in the form of application and GUI database restore and recovery capability.
- Resource consumption and usage reports, which let end users compare the resources provisioned and the actual usage so they can fine-tune resource needs to accommodate workload.
- The ability to view resource chargeback based on resource allocation and consumption.
- The ability to track provider compliance to the SLAs.
The ability to track provider compliance to the SLAs is an especially critical point to understand. To ascertain whether or not the requested services are being provided at an appropriate level, end users must first define what “appropriate level” means. For each service, there may be more than one SLA. The higher the SLA, the more technology and resources are needed to satisfy the SLA. Pricing is also affected by the level of service detailed in the SLA.
For example, for I/O performance guarantees, the SLA would specify the input/output operations per second (IOPS) and megabytes per second (MBps) would specify I/O service times. Based on the SLA, the provider determines the actual storage layer provided to the end user. It is the provider’s responsibility to ensure that the service delivered to the end user is within the accepted limits.
If we look at I/O performance as an example, the SLAs could be structured as follows:
- Bronze standard: Small block average I/O service times equal to or under 15 ms.
- Silver standard: Small block average I/O Service time equal to or under 10 ms.
- Gold standard: Small block average I/O service times equal to or under 5 ms.
- Platinum standard: Small block average I/O service times equal to or under 1 ms.
Based on these SLAs, the provider may choose to
- Place bronze customers on a low-end storage array’s using primarily serial advanced technology attachment (SATA) disks.
- Place silver customers on high-performance storage arrays using serial-attached SCSI (SAS) drives.
- Place gold customers on a high-end storage array’s with a combination of SAS and solid-state drive (SSD).
- Place platinum customers on a high-end storage array based entirely on SSD or flash memory.
The key is that, once end users make their choice, the provider has to
- Define the exact key performance indicators (KPIs) required to meet the service level expectation.
- Ensure that the KPIs required for the SLA are measured and monitored.
- Plan for expansion to continue to be able to meet and provide the expected KPI metrics both now and in the long term.
- Provide end users with reports that support or, if necessary, justify the provider’s service performance capabilities.
Architecture of an Oracle-Based DBaaS Implementation
DBaaS started primarily as a consolidation exercise for reducing capital expenditures (CAPEX), but as it evolved, organizations started looking into other key drivers, such as self-service, showback, and chargeback. Before we look at the details of how to implement DBaaS, we need to have some understanding of the underlying consolidation models and deployment issues that are common to all DBaaS flavors and some of the terminology that we use when defining DBaaS.
The various consolidation models that can be used to provide DBaaS are shown in Figure 1. The simplest and most prevalent form of consolidation exists around server virtualization. Server virtualization offers a simple way of running multiple operating system instances on the same hardware. A better model, platform consolidation, consolidates multiple databases on the same operating system, or a cluster. However, in both cases, database sprawl is still an issue that invariably leads to larger administrative overheads and compliance challenges. An even better consolidation model is the capability to host multiple schemas from different tenants within the same database, using Oracle Database 12c’s multitenant architecture.
Before we describe such methodologies, however, it is important to have a common understanding of the components that make up the underlying architecture.
Architecture and Components
In Oracle terminology, hosts containing monitored and managed targets are grouped into logical pools. These pools are collections of one or more Oracle database homes (used for database requests) or databases (used for schema requests). A pool contains database homes or databases of the same version and platform—for example, a pool may contain a group of Oracle Database 18.104.22.168 container databases on Linux x86_64.
Pools can in turn be grouped into zones. In the DBaaS world, a zone typically comprises a host, an operating system, and an Oracle database. In a similar vein, when defining middleware as a service (MWaaS) zones, a zone consists of a host, an operating system, and an Oracle WebLogic application server. Collectively, these MWaaS and DBaaS zones are called platform as a service (PaaS) zones. Users can perform a few administrative tasks at the zone level, including starting and stopping, backup and recovery, and running chargeback reports for the different components making up a PaaS zone.
In the DBaaS view of a PaaS zone, self-service users may request new databases, or else new schemas in an existing database can be created. The databases can be either single instance or a Real Application Cluster (RAC) environment, depending on the zones and service catalog templates that a user can access.
Diagrammatically, these components and their relationships are shown in Figure 2.