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.
There are 3 options for database deployment for guest applications: internal, forward deployed, and external.
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.
Provision and Patch via Platform
Supports High Availability (e.g. AAG or Oracle RAC)
Credential Rotation possible
Ideal Use Case
Internal (or Internally-deployed)
Development (ACP DBaaS)
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.
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.
The following table shows the types of applications whose database can be forward deployed:
|Partition of Single Tenant or Multi-Tenant Isolated Applications||
|Partition of Multi-Tenant Commingled Applications||No||No|
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.
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,
Note: Applications using token-switched connection strings will need to be redeployed after a forward deployment to access a relocated partition.
View and manage connection information for forward-deployed storage partitions from the Storage tab on the application version’s 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.
In general, credentials will need to be updated in the following circumstances:
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.
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.
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.
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.