Cloudera Docs

Azure prerequisites for Flexible Server

The following Azure prerequisites must be in place in order to use the Flexible Server with CDP:

  • If you would like to use zone redundant-HA, select a region that supports it.

  • The policy provided for the Azure credential must have the required permissions mentioned below.

  • When deployed in “private service” mode (without public endpoints), Flexible Server instances need to be deployed in a delegated subnet within the VNet. This is not required when public endpoints are used.

  • When deployed in “private service” mode, providing the private DNS zone information is mandatory in order to be able to perform DNS resolution. This is not required when public endpoints are used.

Read on to learn how to meet these prerequisites.

Supported regions

Ensure that your selected region has compute availability for Flexible Server. See Flexible Server Azure Regions.

Credential permissions

The Prerequisites for the provisioning credential documentation lists role definitions that includes sufficient permissions for Flexible Server. The role definitions include the following additional permissions that are required for Flexible Server:
Permission Description
Microsoft.DBforPostgreSQL/flexibleServers/write Creates a server with the specified parameters or updates the properties or tags for the server.
Microsoft.DBforPostgreSQL/flexibleServers/delete Deletes an existing server.
Microsoft.DBforPostgreSQL/flexibleServers/start/action Starts an existing server.
Microsoft.DBforPostgreSQL/flexibleServers/stop/action Stops an existing server.
Microsoft.DBforPostgreSQL/flexibleServers/firewallRules/write Restrict which networks can access the database instance.

Delegated subnet

When deployed in private service mode (without public endpoints), Flexible Server instances need to be deployed in a delegated subnet within the VNet.

As mentioned in Azure documentation, to be able to utilize private access with VNet integration, it is a prerequisite to delegate a subnet to Microsoft.DBforPostgreSQL/flexibleServers. This delegation means that only Azure Database for PostgreSQL Flexible Servers can use that subnet. No other Azure resource types can be in the delegated subnet.

You need to create such a delegated subnet and provide it to CDP during environment registration. This delegated subnet will be used by Azure Database for PostgreSQL instances. The delegated subnet provided during environment registration will be used by default for all Azure Database for PostgreSQL instances used in CDP.

Creating a delegated subnet

For a step-by-step official guide on how to perform the delegation, see Delegate a subnet to an Azure service. For considerations on the delegated subnet’s sizing, see Virtual network concepts.

Here is a screenshot from Azure Portal showing the desired setting:

The Microsoft.Storage service endpoint is set automatically during deployment by Azure.

After the subnet has successfully been delegated, don’t forget to record the full subnet ID or the name of the subnet for later use as an input (referred to as <delegated-subnet-id>). For example: /subscriptions/3ddda1c7-d1f5-4e7b-ac81-abcdefgh/resourceGroups/rg/providers/Microsoft.Network/virtualNetworks/vnet/subnets/subnet

Private DNS Zone

When using "private service" mode with Azure virtual network, a Private DNS Zone is mandatory in order to be able to perform DNS resolution.

As mentioned in Using a Private DNS Zone, a Private DNS Zone is used for creating a new Azure Database for PostgreSQL Flexible Server using private network access. Specifically, a Private DNS Zone that ends with .postgres.database.azure.com should be created.

If you do not provide the Private DNS Zone, CDP creates a new Private DNS Zone in your resource group with the naming convention <resource-group-name>.flexible.postgres.database.azure.com

Creating a Private DNS Zone

When selecting a name for the Private DNS zone, use one of the following forms:

[name1].[name2].postgres.database.azure.com

or

[name].postgres.database.azure.com

After the Private DNS zone has been created, don’t forget to record the full Private DNS Zone ID, referred as <dns-zone-id>, for later use as an input. For example: /subscriptions/3ddda1c7-d1f5-4e7b-ac81-abcdefgh/resourceGroups/drg/providers/Microsoft.Network/privateDnsZones/flexible.private.postgres.database.azure.com

For instructions on how to create a Private DNS zone, see Quickstart: Create an Azure private DNS zone using the Azure portal.

Virtual Network Link

After the Private DNS Zone has been created in Azure, you need to link the VNet that you would like to use for your CDP environment to the Private DNS Zone. Once linked, resources hosted in that VNet can access the Private DNS Zone.

If you let CDP create the Private DNS Zone, then CDP creates the required Virtual Network Link connecting the VNet of your deployment with the created Private DNS Zone.

To learn more about virtual network links, see What is a virtual network link?.

Linking the virtual network

For instructions on how to link the VNet to the previously created Private DNS Zone, see Link the virtual network.