Important This service is deprecated and will be deleted in the next minor release. We strongly recommend not creating any new instances with this service. We also recommend deleting or moving existing instances to user-provided instances, as these instances will be out of the control of CSB once the offering is no longer available in the CSB catalog.
This topic gives you reference information about the Azure SQL (MSSQL) service (csb-azure-mssql). It details the plans, configuration parameters, and binding credentials.
For more information about Azure SQL, see the Microsoft documentation.
Plans
The table below lists the default plans for the csb-azure-mssql service:
| Plan | CPUs | Storage Size |
|---|---|---|
| mini | 1 | 5 GB |
| small-v2 | 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 the plan parameters that you must configure 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 next 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 PLAN-NAME SERVICE-INSTANCE-NAME -c '{"PARAMETER-NAME": "PARAMETER-VALUE"}'
For example:
$ cf create-service csb-azure-mssql small mssql-dev -c '{"instance_name": "mssql-dev"}'
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 service:
| Parameter Name | Type | Description | Default | Operation |
|---|---|---|---|---|
instance_name |
string | The name of the service instance. | csb-azsql-INSTANCE-ID |
provision |
resource_group |
string | The Azure resource group in which to create the instance. | rg-INSTANCE-NAME |
provision |
db_name |
string | The name of the database. | csb-db |
provision and update |
location |
string | The Azure region in which to deploy the service instance. Important Currently, Azure SQL is not available in all regions. If you configure a region that is unavailable, Cloud Service Broker for Azure fails. |
westus |
provision |
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 of 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 SKUs section. | "" |
provision and update |
authorized_network |
string | The Azure subnet ID, in long form, that the instance is connected to through a service endpoint. The subnet must have the Microsoft.sql service enabled. |
default |
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 |
SKUs
Stock-keeping units (SKU) 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 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, VMware recommends that the SKU for the updated service instance remain in the same tier (GP_S, GP, or HS). If you wish to change to a different tier, check the Azure documentation to ensure that updating to the new tier is supported.
Binding Credentials
You can bind a service to an app by running:
cf bind-service APP_NAME SERVICE_INSTANCE --binding-name BINDING_NAME
The format for binding credentials made available to the app is as follows:
{
"name" : "DATABASE NAME",
"hostname" : "DATABASE-SERVER-HOST",
"port" : "DATABASE-SERVER-PORT",
"username" : "AUTHENTICATION-USERNAME",
"password" : "AUTHENTICATION-PASSWORD",
"uri" : "DATABASE-CONNECTION-URI",
"jdbcUrl" : "JDBC-FORMAT-CONNECTION-URI",
"jdbcUrlForAuditingEnabled": "JDBC-FORMAT-CONNECTION-URI",
"sqldbName" : "DATABASE-NAME",
"sqldbResourceGroup" : "RESOURCE-GROUP",
"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.
