Database as a Service using Enterprise Manager – Part VI

In our 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, quotas for the users, service templates, and optionally the chargeback plans to apply to the users for cloud allocation and cloud usage.

After configuring the software library, we 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 "SAI_DAS". Next, we created a PaaS infrastructure zone, a group of hosts that will be used for Platform as a Service (PaaS). Our particular zone is to be used only for Database as a Service (DBaaS) – including single instance or multi-instance Oracle Real Application Cluster (RAC) databases, or schemas, or pluggable databases created via self service.

We named the zone “Sainath_PaaS_Zone” and added the members (hosts) that will be part of the PaaS Infrastructure Zone. We also added the global host credentials to be used for provisioning in this PaaS infrastructure zone and the placement constraints – the Maximum CPU Utilization (%), and the Maximum Memory Allocation (%).Then, we specified the roles that can access this zone.

After the zone creation, the next step we went through was to set up a new database pool, a group of database servers where the database software has been preinstalled. These database servers can be stand-alone servers or clustered servers with the cluster infrastructure and Oracle Clusterware already configured. All the servers in a database pool must be of the same platform as well as the same database version. We noted that standardization is one of the key goals of creating the service catalog that will be used in the DBaaS project. If there are multiple 11g versions, standardize on one version, such as the terminal release for that platform.

We named the pool “Sainath_Database11204_Pool”, and entered the host credentials that will be used for performing the database creation operations. This was the global host named credential that uses the Oracle UNIX user and password. Root credentials are also needed since we plan to use the pool for snap clone database requests.

The platform was selected as Linux x86-64 from the drop-down list. Next, we added our Oracle home targets to the pool. Only those database homes and hosts that are the same as the platform, database configuration and database version you have chosen, will appear in the selection list.

Note that each Oracle home target can belong only to a single database pool. If the Oracle home you want is already in another pool, you must first remove it from there before you add it here. We can now continue with the setup.

If the Database Configuration was selected as Cluster Database instead of Database Instance, you would need to select the Oracle home from each node in your Cluster.

Remember that the PaaS infrastructure zone was made available to a role. The users that are assigned this role will now be able to utilize the database pool for their self service provisioning.

In the “Standby Pools” section, you can also associate one or more separate database pools for provisioning (a) physical standby database(s). When you click on “Add”, the list of pools that will be displayed will show only the ones that are suitable for use, as per the Data Guard compatibility matrix. You would have pre-created the standby pools before you could select them in this section.

This would then allow “Enable Standby Database” to be selected in the next step when we create the service template, and the self-service user would then be able to have a standby database automatically created along with the main requested database. In our case, we have decided not to use this option.

The placement policy constraint on this page is the maximum number of database instances per host. This, combined with the Maximum CPU Utilization (%) and the Maximum Memory Allocation (%) defined in the PaaS infrastructure zone, are the maximum ceilings for any database server in the pool. These can be modified appropriately, with lower ceilings for production zones, and higher for development or test zones.

In our case, we have used the ceilings of 95% for both CPU and memory in the PaaS infrastructure zone, and specified a maximum number of 10 instances on any of the servers in the pool. Because of these ceilings, when it is time for the database to be provisioned in the pool, the first database server that satisfies the placement constraints will be selected. In this way, over-utilized servers in the pool will not be used for the new database.

Click on Submit to create the database pool. You are placed back in the database cloud setup page, where the newly created pool appears.

Suppose you committed a mistake when naming the database pool. You wrongly named the pool as “Sainath_Database11203_Pool” during creation, while the Oracle home inside the pool had been selected as 11.2.0.4. Since this is just the pool’s text name, it has no effect on the rest of the setup, but it shows the importance of naming pools correctly, in order to prevent confusion later on. Once named and created, the pool cannot be renamed – even if you use the Edit button. You will need to delete it and recreate it.

Enter Quotas

Select “Quotas” from the left panel, and click on create. You can now enter the quotas for the role you select (Figure 15).

Figure 15: Entering Quota details

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.

We will discuss more about quotas, and continue this article series in the next part.