This is documentation for Apprenda 7 and 8.
Documentation for older versions are also available.

Enterprise DBaaS Adminstration

The Apprenda Cloud Platform provides support for guest applications that leverage SQL Server and Oracle databases, otherwise referred to generically as "structured storage partitions" or simply "partitions" on the Platform. Depending on how a guest application's partition is deployed, the Platform has different levels of involvement in managing the instance.

This page describes the different types of deployments for data partitions, and how you can support enterprise use cases like High Availability or credential rotation by using the forward deploy Platform functionality to connect guest application databases (SQL or Oracle) to externally managed servers. (Note that before Platform version 8.0.0, the forward deploy functionality was referred to as a database "move" and was only available for Oracle databases.)

Guest application database deployment types

There are 3 options for database deployment for guest applications: internal, forward deployed, and external.

  • Internal (or internally-deployed): Partition deployed to an on-Platform database server and managed by the Platform
  • Forward-deployed: Initially an internally-deployed storage partition that a Platform Operator has configured to be on an off-Platform database server. The database can still be patched and provisioned by Developers like an internally-deployed database, but Platform Operators can manage the database
  • External (or externally-deployed): Database deployed to an off-Platform database and not managed by the Platform

A node is considered off-Platform if it has not been added to the Platform through the Apprenda Installer (at installation or through the Modify workflow), or added using the Linux installation process. A node that is off-Platform will not appear on the Infrastructure>Servers page in the SOC.

The following table shows the supported database capabilities for a given database type.

Database Type

Provision and Patch via Platform

Supports High Availability (e.g. AAG or Oracle RAC)

Credential Rotation possible

Ideal Use Case

Internal (or Internally-deployed)

Yes No No

Development (ACP DBaaS)

Forward-deployed Yes Yes Yes

Test/Production (ACP DBaaS)

Supported capabilities for externally-deployed databases are up to your database administrators. If an application database already exists, or Platform Operators and Developers do not want to manage their data tier through the Platform, Developers can deploy and patch their application on the Platform and connect it to an external database. An external database my be ideal to use if your enterprise is already utilizing another DBaaS offering or your application is making use of a database technology not supported directly by the Platform.

Forward-deploying for DBaaS on Platform

When the Platform deploys an application with a database component, it will deploy a storage partition internally on an on-Platform server. A partition deployed like this is completely managed by the Platform, meaning that Developers can patch and provision their application data as needed. This type of deployment can also limit how Platform Operators manage certain elements of the database, like credential rotation, since the database is all controlled by the Platform.

If you need more control over your guest application databases, you can forward deploy an internal database onto an off-Platform database server. After creating and promoting an application with a database component, a Platform Operator can reconfigure connection information of the internally-deployed database to connect to an off-Platform instance of the same database (pre-deployed by the Platform Operator). Developers are still able to patch and deploy forward-deployed databases, but control over database management is left to the Platform Operators and database administrators (DBAs).

Using this feature, Platform Operators and database administrators (DBAs) are able to offer an enterprise-level Database-as-a-Service (DBaaS) solution that supports secure operational workflows while still allowing Developers to provision and patch their application databases in an automated fashion directly in the Developer Portal.

Note: In Platform versions before 8.0.0, forward deployed capabilities were referred to as "moving a database" and were only available for Oracle databases. As of Platform version 8.0.0, this capabilities is available for both Oracle and SQL Server database partitions.

The following table shows the types of applications whose database can be forward deployed:

Forward-Deploy SQL Oracle
Partition of Single Tenant or Multi-Tenant Isolated Applications

In Platform version 8.0.0 and later: Yes

In Platform versions before 8.0.0: No

Yes
Partition of Multi-Tenant Commingled Applications No No

High Availability and Failover Use Cases

By utilizing the forward deploy feature, Platform Operators can set up some High Availability features for use with application databases. The National Institute of Standards and Technology (NIST) defines High Availability (HA) as “a process where redundancy and failover processes are built into a system to maximize its uptime and availability.”

The Platform supports the following HA features for storage partitions provisioned by the Developer. To support these features for guest application databases, the storage partitions must be forward deployed to an off-Platform storage server.

NOTE: For production environments that include Oracle 12c, an Oracle MT (PDB) license may be required due to the Platform's PDB functionality.

Forward-deploying Partitions 

Prerequisites

  • At least one on-Platform Storage Server (SQL Server or Oracle) included in your Platform
  • A guest application that
    • is in the published stage
    • leverages SQL Server or Oracle 12c
    • includes a application provisioning script which determines how tables, views, and other structural artifacts will be created

When a Tenant is onboarded to the application, the Platform will create a corresponding storage partition on an on-Platform server in accordance with the application provisioning script.

To configure a guest application forward deployment or connect to an off-Platform Storage Server,

  1. start maintenance for any Tenants whose storage partitions being forward deployed (preventing them from changing/adding data)
  2. replicate the application data on the off-Platform server by doing one of the following:
    1. Move/copy the internally-deployed storage partition to a prepared off-Platform server and make sure all the necessary users have been created
    2. Create and prepare a new partition on the off-Platform server against which the application provisioning script can be re-run (recommended only if tenants have not yet created or changed data in the storage partition) and make sure all the necessary users have been created
  3. update the connection information for the internally-deployed storage partition on the application's Version Details page to point to the corresponding partition on the off-Platform server. If you are forward deploying to a SQL Server that supports Always On Availability Groups, you will provide the AG Listener and port in the SQL Server Instance name field. 
  4. Oracle only: If the PDB is being recreated (rather than forward deployed/copied), the Platform Operator can opt to run the application provisioning script on the forward-deployed PDB at this time. More details for this step are outlined below
  5. stop maintenance for all Tenants for which partitions have been successfully forward deployed

Note: Applications using token-switched connection strings will need to be redeployed after a forward deployment to access a relocated partition.

Credential management with forward-deployed partitions

View and manage connection information for forward-deployed storage partitions from the Storage tab on the application version's Version Details page in the Applications section of the SOC:

Information displayed includes the storage Partition Name, the Partition Server (the name of the server on which the partition is currently hosted), the Storage Used by the partition (this will apply to internally-deployed partitions only), and the Tenants for which data is stored on the partition.

To update connection information for a storage partition, click on the appropriate Update Connection button for the partition you wan to update. This will open a window that will allow you to view and change connection information. For an internally-deployed partition, you will see only the names of the user provisioned by the Platform as the tenant/runtime user (Tenant Account) and the owner/patching user under which all scripting is executed (Patching Account), as well as the amount of storage used by the partition:

For a forward-deployed Oracle 12c partition (PDB), you will also see the Connection String currently used by the Platform to connect to the storage partition (see Figure below).

For a forward-deployed SQL Server partition (DB), you will see the SQL Server Instance Name (or Availability Group Listener and port) as the mechanism by which the Platform connects to the storage partition (see Figure below).

As needed, this page can be used to update the credentials or connection string that the Platform uses to connect to a storage partition.

Updating Username and Password

In general, credentials will need to be updated in the following circumstances:

  • A password has changed for either user
  • A username has changed for either user for a storage partition that has previously been Forward Deployed/copied to or recreated (Oracle only) off-Platform
  • A username for either user must be updated to match the username that will be used when the PDB is Forward Deployed/copied to an off-Platform Oracle server
  • Oracle only: A username for either user must be updated to match the username that will be used when the PDB is recreated on an off-Platform Oracle server. Please note that in this situation you can, if you have performed the steps outlined in the attached document, select the Re-run Provisioning Scripts option described below, which will recreate any objects outlined in the application provisioning script and grant the appropriate permissions to the new user.

While updating password information for Oracle has no impact on user grants, username changes should be coordinated with your DBA, as (in most cases) your DBA is responsible for ensuring that the new users have the appropriate permissions and user grants for objects in the storage partition. To streamline grant creation, Platform Operators/DBAs may choose to follow the Platform installation and configuration procedures outlined in the Apprenda Off-Platform Oracle 12c Guide for Username Changes. This method allows Platform Operators to use the Re-run Provisioning Scripts option described below to recreate data objects on the Forward-Deployed PDB and create grants for the new users.

Windows Authentication (SQL Server only)

If guest applications are using Windows Authentication to connect to SQL Server partitions, then only the domain service account name (and not the password) will be displayed rather than the SQL Server account. Additionally, Platform Operators will not be able to modify this account name in the SOC.

Updating the Connection String (Oracle only)

The Connection String field can be updated to point to an forward-deployed Storage Partition. It should exclude username and password information, and must include host name, port number, and the service name of the PDB:

In the example above, the connection string has been set to 
Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=HQT-westsixth09)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=DBAUTO_targetpdb)));Pooling=False;

However, the connection string should adhere to whatever format is required for the Platform to communicate with the forward-deployed PDB.

After the Connection String field has been altered, a Re-run Provisioning Scripts checkbox will appear. Checking this box will run the application provisioning script on the forward-deployed PDB

Note: this option should be selected ONLY if you are recreating the storage partition on the forward-deployed PDB. Leave the box unchecked if you have forward-deployed or copied the storage partition from the on-Platform server to the off-Platform Oracle server, as re-running the provisioning script will result in an error and possible data loss/corruption.

Once all changes are made, click on the Save button. As needed, the Update Connection button can be used to view or make any additional changes to the connection information.

It should be noted that Connection String information can be updated and saved for Oracle 12c storage partitions only. Although the Update Connection button is active and the Partitions Properties window will appear for all storage partitions, attempting to save changes will result in an error message for other partitions.

Grants for Oracle Structured Storage Partitions

For Oracle 12c, Platform Operators have the option to enable or disable automatic grant creation for the DEFAULT_SCHEMA and TENANT users for storage partitions internally hosted on the Platform. Grants are never automatically created by the Platform for forward-deployed storage partitions.

You can enable Automatic grant creation for internally-deployed storage partitions by setting the DB.GrantSchemaAccessIn12C setting to a value of True in the Platform Registry Settings section of the SOC (this is the default behavior when the Platform is installed). 

When automatic grant creation is disabled for internally-deployed storage partitions, or if storage partitions will be forward-deployed, Platform Operators should advise Development teams that grants should be created for guest applications through the application provisioning script as described in the Working with Data section of our documentation.