Database as a Service using Enterprise Manager – Part XVI

In this article series, we are exploring the capabilities of Oracle Enterprise Manager Cloud Control 13c for the private Database-as-a-Service (DBaaS) cloud – including the setup of such a cloud.  In the previous parts, we started the setup of the private DBaaS cloud, including the configuration of the self-service portal. The full procedure includes setting up the Enterprise Manager software library, creating the PaaS infrastructure zones, database pools, and quotas for the users, service templates, and optionally, chargeback plans to apply to the users for cloud allocation and cloud usage.

We configured the software library, set up the Enterprise Manager self-update system, and downloaded the latest plug-ins from the external Enterprise Manager store. We created a custom cloud role in Enterprise Manager, and a Cloud SSA user named as "SAI_DAS". Next, we created a PaaS Infrastructure Zone named as “Sainath_PaaS_Zone”, a group of hosts that will be used for Database as a Service. Members (hosts) were added to the PaaS Infrastructure Zone.

A new database pool was then created – a group of database servers where the database software had been pre-installed, with all servers in the pool belonging to the same platform as well as the same database version. Next, we added our Oracle Home targets to the Pool, with each Oracle Home target belonging only to a single database pool. The Placement Policy Constraint “Maximum number of Database Instances per host” was set at 10 instances.

After that, we entered the quotas for the role selected. The Quotas page allows the SSA Administrator to configure the total amount of resources which are allocated to the self-service user via the role. Then we selected Data Sources from the left panel, and on the page that appears, clicked on the Data Profiles tab and created a new profile. In the creation wizard that started, we selected the Reference target as the “saiprod” database. This is the production database that will be used as the master source. We chose to include “Data Content” and “Structure and Data” by creating an RMAN backup from the source database. The profile will be used for the Database-as-a-Service functionality.

We then started to create a new database profile to be used for the Snap Clone functionality. We clicked on “Create” in the Data Profiles tab and specified the reference target again as the “saiprod” database, and included the “Structure and Data” by including an “RMAN Database Image” for this new profile, instead of an RMAN backup. This profile will be used for the Database-as-a-Service using the Snap Clone functionality.

The next step was to create Service Templates for the database cloud, which can then be used by the SSA User to provision databases in the pool. The profiles created in the previous section are like gold copies of an Oracle database, and they are used by service templates. The service template is what is offered to the SSA user and forms the basis of the functionality of the cloud. We created the service templates by selecting Setup | Cloud | Database and then Service Templates in the left pane, followed by clicking on the Create button. We named the service template as “Sainath 11204 Single Instance Database”. Under the Source Identification section, we selected the Create Database as “Using Profile” and then from the list of profiles we selected the appropriate profile that was created with an RMAN Full backup.

The other options for Create Database, besides “Using Profile”, are “Using existing Database” and “Using Test Master Snapshot”. Test master snapshots are a snapshot of an RMAN Image backup from a Production database. Test master snapshots are new in Enterprise Manager 13.1, and can be used to create snap clones. However, these require special storage hardware such as NetApp Storage Appliance, Sun ZFS Storage Appliance, EMC Storage Array, or even the Solaris File System (ZFS). Note that the dNFS file system and CloneDB cannot be used for test master snapshots.

Then, we selected Single instance under the Database Definition. In our case, we specified the SID prefix as “sai” (up to six letters are allowed) and the domain name as “sainath.com”. This can be defined as per company standards, or you may allow the SSA user to specify the prefix at request time. The domain name can be kept unlocked (the default), or by clicking on the lock icon, you can prevent the SSA user from changing the domain name at request time.

You can also select “Enable Standby Database” for this service template, provided you have already set up the infrastructure for this, and have a standby database pool of servers that you can select at this stage.

Under the section “Pools and Zones”, we clicked on Add and selected the previously created “Sainath_PaaS_Zone”. Then, we clicked on “Assign Pool” and selected the Sainath_Database11204_Pool to be assigned to this zone. The self-service databases will be created in this pool.

In the Placement section, there are two possibilities. The provisioning of the database on the host can be selected by the “Placement Algorithm”, or selected by the user during request. The placement algorithm is controlled by the placement constraints that have been configured in the PaaS Infrastructure Zone we have selected. The two constraints – Maximum CPU Utilization (%), and Maximum Memory Allocation (%), have been set to 95% in our case. 

The placement algorithm is also influenced by the placement policy constraint specified in the database pool, i.e. the Maximum number of Database Instances per host, which has been specified as 10 in our case. The algorithm looks at all these factors, and decides which member of the zone should be used for the creation of new services. In our case, there is just one host, but if the algorithm returns false for that host, no new service will be created.

If “selected by the user during request” is used, then the algorithm doesn’t decide on the member; the human user makes that decision. However, the constraints will still apply. If there are multiple hosts in the pool and the human user selects a host that is already over-utilized, the creation of the new service will not work.

So, it is best to leave the selection to the placement algorithm, except in special service catalog offerings where a manual selection of a host is required, for example –  there may be a few hosts in your pool with higher performance (more processors and memory available, or a faster storage subsystem), and you want an especially important database to be created on that specific host rather than other hosts with lower grade performance. Or, you want certain databases to be created only on a particular host in the pool, and other databases to be created on any of the hosts.

Note that database cloud requests can fail for certain reasons, such as placement logic failures. Placement logic uses a 7 day average for Memory and CPU constraints when locating a suitable database server within the selected PaaS infrastructure zone where the new database can be created.

Click on Next. The Database details step appears (Figure 24).

Figure 24: Database Details for Service Template

We will continue in the next part of this article series.