This topic gives you reference information about the Azure SQL (MSSQL) Database service (csb-azure-mssql-db). It details the plans, configuration parameters, and binding credentials.
The csb-azure-mssql-db service manages Azure SQL databases on pre-configured database servers on Azure SQL. For more information about Azure SQL, see the Microsoft documentation.
Note Tanzu Cloud Service Broker for Azure v1.5.0 removes the brokerpak preconfigured subsume plan for Azure SQL MSSQL Database Instance. If you have instances of Azure SQL (MSSQL) that were created in previous versions subsuming them, you must change the plan before upgrading. For more information about upgrade steps, see Upgrading Tanzu Cloud Service Broker for Azure.
Configuring the service
To configure the service, provide the pre-configured database servers in the following format when configuring Cloud Service Broker for Azure:
{
"SERVER1":{
"server_name": "SERVER1-FQDN",
"server_resource_group": "SERVER1-RESOURCE-GROUP",
"admin_username": "SERVER1-ADMIN-USERNAME",
"admin_password": "SERVER1-ADMIN-PASSWORD"
},
"SERVER2":{
"server_name": "SERVER2-FQDN",
"server_resource_group": "SERVER2-RESOURCE-GROUP",
"admin_username": "SERVER2-ADMIN-USERNAME",
"admin_password": "SERVER2-ADMIN-PASSWORD"
}
}
For more information about configuring services, see Configure Services with Cloud Service Broker for Azure.
Plans
The table below lists the plans available for the csb-azure-mssql-db service:
| Plan | CPUs | Maximum Storage Size |
|---|---|---|
| mini | 2 | 5 GB |
| small | 2 | 5 GB |
| medium | 8 | 200 GB |
| large | 32 | 500 GB |
| extra-large | 80 | 1 TB |
Plan configuration parameters
When configuring Cloud Service Broker for Azure you can add additional plans. For how to configure plans, see Configure Services with Cloud Service Broker for Azure.
Note To effectively leverage the capabilities of the Tanzu Cloud Service Broker for Azure, VMware advises creating and managing custom plans. These plans are configurable through the tile, providing a user-friendly method to define and adjust service characteristics. For more information about custom plans, see Custom Plans.
The following table lists parameters which can only be configured for additional plans:
| Parameter Name | Values | Default | Required |
|---|---|---|---|
name |
The plan name | n/a | Yes |
id |
A unique GUID | n/a | Yes |
description |
Description of the new plan | n/a | Yes |
metadata.displayName |
Name to use when displaying the plan in the Marketplace. | n/a | No |
metadata.bullets |
List of bullet points to display in Apps Manager. | n/a | No |
You can also add any of the configuration parameters listed in the parameters section to your plan. To create plans with specific size limits we recommend setting sku_name or cores and max_storage_gb properties.
Note If you set a parameter at plan level, developers cannot change the value when creating or updating service instances.
Configuration parameters
You can provision a service by running:
cf create-service csb-azure-mssql-db PLAN-NAME SERVICE-INSTANCE-NAME -c '{"PARAMETER-NAME": "PARAMETER-VALUE"}'
For example:
$ cf create-service csb-azure-mssql-db small mssql-dev -c '{"server":"server1"}'
You can update the plan or configuration parameters for a service instance by running:
cf update-service SERVICE-INSTANCE-NAME [-p NEW-PLAN] -c '{"PARAMETER-NAME": "PARAMETER-VALUE"}'
The table below lists the parameters that you can configure, using the -c flag, when provisioning or updating a csb-azure-mssql-db service:
| Parameter Name | Type | Description | Default | Operation |
|---|---|---|---|---|
db_name |
string | The name of the database. | csb-db-INSTANCE-ID |
provision and update |
server |
string | (Required) The name of the server on which to create the database. This must match one of the SERVER parameters in one of the servers configured when configuring the service. |
None | provision and update |
azure_tenant_id |
string | The ID of the Azure tenant for the service instance. | The value the operator entered for Tenant ID in Ops Manager. | provision and update |
azure_subscription_id |
string | The ID of the Azure subscription for the service instance. | The value the operator entered for Subscription ID in Ops Manager. | provision and update |
azure_client_id |
string | The ID of the Azure service principal to authenticate for service instance creation. | The value the operator entered for Client ID in Ops Manager. | provision and update |
azure_client_secret |
string | The secret (password) for the Azure service principal to authenticate for service instance creation. | The value the operator entered for Client Secret in Ops Manager. | provision and update |
cores |
number | Number vCores for the instance (up to the maximum allowed for the service tier). 1–80, multiples of 2 | 2 |
provision and update |
max_storage_gb |
number | Maximum storage allocated to the database instance in GB. | 5 |
provision and update |
sku_name |
string | The Azure stock-keeping unit (SKU). For more information about configuring this parameter, see the SKUs section. | "" |
provision and update |
skip_provider_registration |
boolean | Set to true to skip automatic Azure provider registration. Set if the service principal being used does not have the rights to register providers. |
false |
provision and update |
short_term_retention_days |
number | Retention period in days for short-term retention (Point in Time Restore) policy. The maximum period is 35 days. | 7 |
provision and update |
ltr_weekly_retention |
string | The weekly retention policy for an LTR backup in an ISO 8601 format. A valid value is 1 to 520 weeks. For example, P3W indicates 3 weeks. To unset this parameter, use PT0S. |
PT0S |
provision and update |
ltr_monthly_retention |
string | The monthly retention policy for an LTR backup in an ISO 8601 format. A valid value is 1 to 120 months. For example, P3M indicates 3 months. To unset this parameter, use PT0S. |
PT0S |
provision and update |
ltr_yearly_retention |
string | The yearly retention policy for an LTR backup in an ISO 8601 format. A valid value is 1 to 10 years. For example, P3Y indicates 3 years. To unset this parameter, use PT0S. |
PT0S |
provision and update |
ltr_week_of_year |
number | The week of the year to make the yearly backup. The value must be 1 to 52. | 1 |
provision and update |
SKUs
SKUs are usually formatted as TIER_FAMILY_NUMBER-OF-CORES. Where:
- Examples of
TIERareGP_S,GP, andHS - Examples of
FAMILYareGen4andGen5
Example SKUs are GP_S_Gen4_1 and GP_Gen5_8.
If you do not define a SKU using the sku_name parameter, the SKU is computed from the number of cores in your plan. See Plans above.
The table below shows the mapping of the number of cores to the corresponding Azure SKU:
| Cores | SKU |
|---|---|
| 1 | GP_Gen5_1 |
| 2 | GP_Gen5_2 |
| 4 | GP_Gen5_4 |
| 8 | GP_Gen5_8 |
| 16 | GP_Gen5_16 |
| 32 | GP_Gen5_32 |
| 80 | GP_Gen5_80 |
For a list of all valid SKUs, run:
az sql db list-editions -l LOCATION -o table
For information about the vCore purchasing model, see this Microsoft documentation.
For information about the DTU purchasing model, see this Microsoft documentation.
Note Azure SQL service instances use the vCore model and the Gen5 hardware generation unless you override this default using the sku_name parameter. For more information about the vCore model, see the Microsoft documentation.
When updating a service instance, the SKU for the updated service instance must remain in the same tier (GP_S, GP, or HS). If you update to a different tier, Azure refuses the update request.
Binding credentials
The format for binding credentials for an Azure SQL database is as follows:
{
"name" : "DATABASE-NAME",
"hostname" : "DATABASE-SERVER-HOST",
"port" : "DATABASE-SERVER-PORT",
"username" : "AUTHENTICATION-USERNAME",
"password" : "AUTHENTICATION-PASSWORD",
"server" : "SERVER-NAME",
"uri" : "DATABASE-CONNECTION-URI",
"jdbcUrl" : "JDBC-FORMAT-CONNECTION-URI",
"jdbcUrlForAuditingEnabled" : "JDBC-FORMAT-CONNECTION-URI",
"sqldbName" : "DATABASE-NAME",
"sqlServerName" : "SERVER-NAME",
"sqlServerFullyQualifiedDomainName" : "SERVER-FQDN",
"databaseLogin" : "AUTHENTICATION-USERNAME",
"databaseLoginPassword" : "AUTHENTICATION-PASSWORD"
}
A binding or service key corresponds to a user in SQL Server. By default, a user cannot be deleted when they own a schema.
When a binding or service key is deleted, user-owned data is re-assigned to a role called binding_user_group before the user is deleted. This ensures that the user can be deleted.
