Azure prerequisites for Flexible Server
The following Azure prerequisites must be in place in order to use the Flexible Server with Cloudera:
-
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 Flexible Server with Delegated Subnets is selected from the Azure database type options, Flexible Server instances need to be deployed in a delegated subnet within the VNet. This is not required either when public endpoints are used or when Azure Private Link is used to achieve the “private service” mode.
-
When deployed in “private service” mode, either using Azure Private Link or delegated subnets, 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
| 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. |
Microsoft.DBforPostgreSQL/flexibleServers/configurations/write |
This permission is required to change Flexible Server configuration. |
Delegated subnet
You have two options to deploy Flexible Server instances in private service mode (without public endpoints): using Private Link or without Private Link. Flexible Server with Private Link is the recommended option. If Private Link is not used , Flexible Server instances need to be deployed in a “delegated subnet” within the VNet. The Flexible Server with Delegated Subnet option, although still available on the UI, is deprecated and Cloudera recommends that you use the Azure Private Link option instead.
As mentioned in Azure documentation, to be able to utilize private
access with VNet integration, when private endpoints are not used, 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 Cloudera 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 Cloudera.
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.
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, in case of Flexible Server with Private Link, the private DNS zone
must be named privatelink.postgres.database.azure.com. In case of Flexible
Server with a delegated subnet, a private DNS zone that ends with
.postgres.database.azure.com should be created.
If you do not provide the private DNS zone, Cloudera
creates a new private DNS zone in your resource group with the naming convention
<resource-group-name>.flexible.postgres.database.azure.com. In case of
Flexible Server with Private Link, the naming convention for the CDP-created private DNS
zone is
<resource-group-name>.privatelink.postgres.database.azure.com.
Creating a Private DNS Zone
When selecting a name for the Private DNS zone, in case of Flexible Server with
Private Link, use privatelink.postgres.database.azure.com. Use one of the
following forms for Flexible Server with Delegated Subnet:
[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 Cloudera environment to the Private DNS Zone. Once linked, resources hosted in that VNet can access the Private DNS Zone.
If you let Cloudera create the Private DNS Zone, then Cloudera 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.
