Rede com acesso privado (integração de rede virtual) para o Banco de Dados do Azure para PostgreSQL

Este artigo descreve os conceitos de conectividade e rede para instâncias de servidor flexíveis do Banco de Dados do Azure para PostgreSQL.

Ao criar uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, você deve escolher uma das seguintes opções de rede:

• Acesso privado (integração de rede virtual)
• Acesso público (endereços IP permitidos) e ponto de extremidade privado

Este documento descreve a opção de sistema de rede de acesso privado (integração da rede virtual).

Acesso privado (integração de rede virtual)

Você pode implantar uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL em sua rede virtual do Azure usando a injeção de rede virtual. As redes virtuais do Azure fornecem comunicação de rede privada e segura. Os recursos em uma rede virtual podem se comunicar por meio de endereços IP privados que tiverem sido atribuídos nessa rede.

Escolha esta opção de rede se você deseja ter as seguintes funcionalidades:

• Conecte-se dos recursos do Azure na mesma rede virtual à instância do servidor flexível do Banco de Dados do Azure para PostgreSQL usando endereços IP privados.
• Use uma VPN ou o Azure ExpressRoute para se conectar de recursos que não são do Azure à instância de servidor flexível do Banco de Dados do Azure para PostgreSQL.
• Verifique se a instância do servidor flexível do Azure Database for PostgreSQL não possui endpoint público acessível pela Internet.

No diagrama anterior:

• As instâncias de servidor flexível do Azure Database para PostgreSQL são implantadas na sub-rede 10.0.1.0/24 da rede virtual VNet-1.
• Os aplicativos implantados em sub-redes diferentes na mesma rede virtual podem acessar diretamente as instâncias de servidor flexíveis do Banco de Dados do Azure para PostgreSQL.
• Os aplicativos implantados em uma VNet-2 (rede virtual) diferente não têm acesso direto às instâncias de servidor flexíveis do Banco de Dados do Azure para PostgreSQL. É necessário executar o emparelhamento de rede virtual para uma zona DNS privada para que eles possam acessar a instância do servidor flexível.

Conceitos de rede virtual

Uma rede virtual do Azure contém um espaço de endereços IP privado configurado para o uso. Sua rede virtual deve estar na mesma região do Azure que sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. Para saber mais sobre redes virtuais do Azure, consulte Visão geral da Rede Virtual do Azure.

Aqui estão alguns conceitos para se familiarizar quando você estiver usando redes virtuais em que os recursos são integrados a uma rede virtual com instâncias de servidor flexíveis do Banco de Dados do Azure para PostgreSQL:

• Sub-rede delegada: uma rede virtual contém sub-redes. As sub-redes permitem segmentar a rede virtual em espaços de endereço menores. Os recursos do Azure são implantados em sub-redes específicas dentro de uma rede virtual.

  Sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL integrada em uma rede virtual deve estar em uma sub-rede delegada. Ou seja, somente instâncias de servidor flexíveis do Banco de Dados do Azure para PostgreSQL podem usar essa sub-rede. Nenhum outro tipo de recurso do Azure pode estar na sub-rede delegada. Para delegar uma sub-rede, você precisa atribuir a propriedade de delegação dessa rede como Microsoft.DBforPostgreSQL/flexibleServers.

  O menor intervalo CIDR que você pode especificar para a sub-rede é de /28, que fornece 16 endereços IP. O primeiro e o último endereço em qualquer rede ou sub-rede não pode ser atribuído a nenhum host individual. O Azure reserva cinco IPs a serem usados internamente pela rede do Azure, que incluem dois IPs que não podem ser atribuídos ao host, conforme mencionado. Isso deixa 11 endereços IP disponíveis para um intervalo CIDR /28. Uma única instância de servidor flexível do Banco de Dados do Azure para PostgreSQL com recursos de alta disponibilidade usa quatro endereços.

  Para replicação e conexões do Microsoft Entra, verifique se as tabelas de rotas não afetam o tráfego. Um padrão comum é rotear todo o tráfego de saída por meio de um Firewall do Azure ou de um dispositivo de filtragem de rede local personalizado.

  Se a sub-rede tiver uma tabela de rotas associada à regra para rotear todo o tráfego para uma solução de virtualização:

  • Adicione uma regra com a marca de serviço de destino AzureActiveDirectory e o próximo salto Internet.
  • Adicione uma regra com o intervalo de IP de destino igual ao intervalo de sub-rede da instância de servidor flexível do Banco de Dados do Azure para PostgreSQL e o próximo salto Virtual Network.

  Importante

  Os nomes AzureFirewallSubnet,AzureFirewallManagementSubnet,AzureBastionSubnet e GatewaySubnet estão reservados no âmbito do Azure. Não use nenhum desses nomes como o nome da sub-rede. Além disso, as redes virtuais não devem ter espaço de endereço sobreposto para criar réplicas entre regiões.

• NSG (grupo de segurança de rede) as regras de segurança em NSGs permitem filtrar o tipo de tráfego de rede que pode fluir para dentro e fora das sub-redes da rede virtual e dos adaptadores de rede. Para obter mais informações, confira a Visão geral dos grupos de segurança de rede.

  Os ASGs (grupos de segurança de aplicativo) facilitam o controle da segurança da camada 4 usando os grupos de segurança de rede em redes simples. É possível rapidamente:

  • Unir máquinas virtuais a um ASG ou remover máquinas virtuais de um ASG.
  • Aplicar regras a essas máquinas virtuais ou remover regras dessas máquinas virtuais de maneira dinâmica.

  Para obter mais informações, confira a Visão geral dos ASGs.

  No momento, não há suporte a NSGs em que um ASG faça parte da regra com as instâncias de servidor flexível do Banco de Dados do Azure para PostgreSQL. Atualmente, recomendados o uso de filtros de origem ou destino baseados em IP em um grupo de segurança de rede.

  A alta disponibilidade e outros recursos do servidor do Banco de Dados do Azure para PostgreSQL exigem a capacidade de enviar/receber tráfego para a porta de destino 5432 dentro da sub-rede de rede virtual do Azure em que uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL é implantada e para o Armazenamento do Azure para arquivamento de log. Se você criar NSGs para negar o fluxo de tráfego de ou para sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL na sub-rede em que ele é implantado, certifique-se de permitir o tráfego para a porta de destino 5432 dentro da sub-rede e também para o Armazenamento, usando a marca de serviço Armazenamento como destino. Para alta disponibilidade, a melhor prática é adicionar um ponto de extremidade de serviço Microsoft.Storage, pois ele garante o roteamento de tráfego correto para a conta de armazenamento do Azure que é usada para carregar arquivos WAL (log write-ahead).

  Você pode filtrar ainda mais essa regra de exceção adicionando sua região do Azure ao rótulo como us-east.storage. Além disso, se você optar por usar a autenticação do Microsoft Entra para autenticar entradas em sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, permita o tráfego de saída para a ID do Microsoft Entra usando uma marca de serviço do Microsoft Entra.

  Ao configurar as Réplicas de leitura em regiões do Azure, sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL requer a capacidade de enviar ou receber tráfego para a porta de destino 5432 para réplicas e primárias e para o Armazenamento do Azure em regiões de réplica e primárias de servidores de réplica e primários. A porta TCP de destino necessária para o Armazenamento é 443.

• Integração da zona DNS privada: a integração da zona DNS privada do Azure permite que você resolva o DNS privado dentro da rede virtual atual ou de uma rede virtual emparelhada na região onde a zona DNS privada esteja vinculada.

Usar uma zona DNS privada

O DNS privado do Azure fornece um serviço DNS confiável e seguro para sua rede virtual. O DNS Privado do Azure gerencia e resolve nomes de domínio em uma rede virtual sem a necessidade de configurar uma solução DNS personalizada.

Ao usar o acesso à rede privada com uma rede virtual do Azure, é obrigatório fornecer as informações da zona DNS privada para poder fazer a resolução de DNS. Para uma nova criação de instância de servidor flexível do Banco de Dados do Azure para PostgreSQL usando o acesso à rede privada, as zonas DNS privadas precisam ser usadas enquanto você configura instâncias de servidor flexível do Banco de Dados do Azure para PostgreSQL com acesso privado.

Para a criação de uma nova instância de servidor flexível para o Banco de Dados do Azure para PostgreSQL usando o acesso à rede privada com uma API, modelo do ARM (Azure Resource Manager), Bicep ou Terraform, crie zonas DNS privadas. Em seguida, use essas zonas enquanto configura as instâncias de servidor flexível do Banco de Dados do Azure para PostgreSQL com acesso privado. Para obter mais informações, veja as especificações da API REST para o Azure.

Se você usar o portal do Azure ou a CLI do Azure para criar instâncias de servidor flexíveis do Banco de Dados do Azure para PostgreSQL, poderá fornecer um nome de zona DNS privado criado anteriormente na mesma assinatura ou em uma assinatura diferente ou uma zona DNS privada padrão será criada automaticamente em sua assinatura.

Se você usar uma API do Azure, um modelo do ARM ou o Terraform, crie zonas DNS privadas que terminem em .postgres.database.azure.com. Utilize essas zonas ao configurar instâncias de servidor flexível do Azure Database for PostgreSQL com acesso privado. Por exemplo, use a forma [name1].[name2].postgres.database.azure.com ou [name].postgres.database.azure.com. Se você optar por usar o formulário [name].postgres.database.azure.com, o nome não poderá ser o nome que você usa para uma das instâncias de servidor flexível do Banco de Dados do Azure para PostgreSQL ou receberá uma mensagem de erro durante o provisionamento. Para obter mais informações, veja Visão geral de zonas DNS privadas.

Ao usar o portal do Azure, as APIs, a CLI do Azure ou um modelo do ARM, você também pode alterar a zona DNS privada da que você forneceu quando criou sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL para outra zona DNS privada que existe para a mesma assinatura ou assinatura diferente.

Depois de criar uma zona DNS privada no Azure, você precisará vincular uma rede virtual a ela. Os recursos hospedados nessa rede virtual podem então acessar a zona DNS privada.

As zonas privadas DNS são resilientes a interrupções regionais porque os dados de zona estão disponíveis globalmente. Os registros de recursos em uma zona privada são replicados automaticamente entre regiões. O DNS privado do Azure é um serviço fundamental de zona de disponibilidade e com redundância de zona. Para obter mais informações, consulte Serviços do Azure com suporte à zona de disponibilidade.

Integração com um servidor DNS personalizado

Se você estiver usando um servidor DNS personalizado, deverá usar um encaminhador DNS para resolver o FQDN da instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. O endereço IP do encaminhador deve ser 168.63.129.16.

O servidor de DNS personalizado deve estar dentro da rede virtual, ou ser acessível por meio da configuração do servidor DNS da rede virtual. Para obter mais informações, consulte Resolução de nome usando seu próprio servidor DNS.

Zonas DNS privadas e emparelhamento de rede virtual

As configurações de zona DNS privada e o emparelhamento de redes virtuais são independentes um do outro. Se você quiser se conectar à instância de servidor flexível do Banco de Dados do Azure para PostgreSQL de um cliente provisionado em outra rede virtual da mesma região ou de uma região diferente, será necessário vincular a zona DNS privada à rede virtual. Para saber mais, confira Vincular rede virtual.

Para mapear um nome de servidor para o registro DNS, você pode executar o comando nslookup no Azure Cloud Shell usando o Azure PowerShell ou o Bash. Substitua o nome do servidor pelo parâmetro <server_name> no exemplo a seguir:

nslookup -debug <server_name>.postgres.database.azure.com | grep 'canonical name'

Usar do design de sistema de rede privada Hub e Spoke

Hub e spoke é um modelo de rede popular para o gerenciamento mais eficiente de requisitos comuns de comunicação ou de segurança.

O hub é uma rede virtual que atua como um local central para gerenciar a conectividade externa. Ele também hospeda serviços usados por várias cargas de trabalho. O hub coordena toda a comunicação entre os spokes. As regras ou os processos de TI como segurança podem inspecionar, rotear e gerenciar centralmente o tráfego. Os spokes são as redes virtuais que hospedam as cargas de trabalho e conectam-se ao hub central por meio do emparelhamento de rede virtual. Os serviços compartilhados são hospedados nas próprias sub-redes para compartilhamento com os spokes. Então, uma sub-rede de perímetro atua como um dispositivo de segurança.

Os spokes também são redes virtuais no Azure que são usadas para isolar cargas de trabalho individuais. O fluxo de tráfego entre a matriz local e o Azure é conectado por meio do Azure ExpressRoute ou de uma VPN site a site conectada à rede virtual de hub. As redes virtuais dos spokes para o hub são emparelhadas e permitem a comunicação com os recursos locais. Implemente o hub e cada spoke em assinaturas ou grupos de recursos separados.

Há três padrões principais para conectar redes virtuais spoke entre si:

• Os spokers são conectados diretamente entre si: os emparelhamentos de rede virtual ou túneis VPN são criados entre as redes virtuais spoke para fornecer conectividade direta sem atravessar a rede virtual de hub.
• Os spokes se comunicam por meio de um dispositivo de rede: cada rede virtual spoke tem um emparelhamento com uma WAN virtual ou com uma rede virtual de hub. Um dispositivo encaminha o tráfego de spoke para spoke. O dispositivo pode ser gerenciado pela Microsoft (como com uma WAN virtual) ou por você.
• Um gateway de rede virtual é anexado à rede de hub e usa rotas definidas pelo usuário: habilita a comunicação entre os spokes.

Use o Gerenciador de Rede Virtual do Azure para criar novas (e integrar as existentes) topologias de rede virtual de hub e spoke visando o gerenciamento central de controles de segurança e conectividade.

Comunicação com clientes de rede privada em regiões diferentes

Frequentemente, os clientes precisam se conectar às regiões do Azure dos clientes. Mais especificamente, essa questão normalmente se resume a como conectar duas redes virtuais (uma das quais tem uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL e outra tem um cliente de aplicativo) que estão em regiões diferentes.

Há várias maneiras de alcançar essa conectividade, incluindo:

• Emparelhamento de rede virtual global. Esta é a metodologia mais comum porque é a maneira mais fácil de conectar redes em diferentes regiões. O emparelhamento de rede virtual global cria uma conexão pelo backbone do Azure diretamente entre as duas redes virtuais emparelhadas. Esse método fornece a melhor produtividade rede e latências mais baixas para conectividade. Quando as redes virtuais são emparelhadas, o Azure também lida com o roteamento automaticamente para você. Essas redes virtuais podem se comunicar com todos os recursos na rede virtual emparelhada estabelecidos em um gateway de VPN.
• Conexão rede para rede. Uma conexão entre redes virtuais (conexão rede para rede) é essencialmente uma VPN entre os dois locais diferentes do Azure. A conexão rede para rede é estabelecida em um gateway de VPN. O tráfego incorre em dois saltos de tráfego adicionais em comparação com o emparelhamento global de rede virtual. Também há latência extra e menor bandwidth em comparação com esse método.
• Comunicação por meio do dispositivo de rede na arquitetura hub e spoke. Em vez de conectar redes virtuais spoke diretamente entre si, você pode usar dispositivos de rede para encaminhar o tráfego entre spokes. Os dispositivos de rede fornecem mais serviços de rede, como inspeção profunda de pacotes e segmentação de tráfego ou monitoramento, mas podem introduzir gargalos de latência e desempenho se não forem dimensionados corretamente.

Replicação entre regiões do Azure e redes virtuais com rede privada

A replicação de banco de dados é o processo de copiar dados de um servidor central ou primário para vários servidores conhecidos como réplicas. O servidor primário aceita operações de leitura e gravação, e as réplicas atendem transações somente leitura. O servidor primário e as réplicas formam coletivamente um cluster de banco de dados. O objetivo da replicação de banco de dados é garantir redundância, consistência, alta disponibilidade e acessibilidade de dados, especialmente em aplicativos críticos e de alto tráfego.

O Banco de Dados do Azure para PostgreSQL oferece dois métodos de replicação: replicação física (ou seja, streaming) por meio do recurso interno de Réplica de Leitura e replicação lógica. As duas opções são ideais para casos de uso diferentes e o usuário pode escolher uma das duas, dependendo do objetivo final.

A replicação entre regiões do Azure, com redes virtuais separadas em cada região, exige conectividade entre limites de rede virtual regionais que pode ser fornecida por meio do emparelhamento de rede virtual ou em arquiteturas hub e spoke por meio de um dispositivo de rede.

Por padrão, a resolução de nomes DNS tem como escopo uma rede virtual. Qualquer cliente em uma rede virtual (VNET1) não consegue resolver o FQDN da instância de servidor flexível do Banco de Dados do Azure para PostgreSQL em outra rede virtual (VNET2).

Para resolver esse problema, você deve garantir que os clientes na VNET1 possam acessar a zona DNS privada da instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. Adicione um link de rede virtual à zona DNS privada da instância de servidor flexível do Banco de Dados do Azure para PostgreSQL.

Cenários de rede virtual sem suporte

Aqui estão algumas limitações para trabalhar com redes virtuais criadas por meio da integração VNET:

• Depois que uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL for implantada em uma rede virtual e sub-rede, você não poderá movê-la para outra rede virtual ou sub-rede. Não é possível mover a rede virtual para outro grupo de recursos ou assinatura.
• Não é possível aumentar o tamanho da sub-rede (espaços de endereços) depois que já houver recursos na sub-rede.
• Os recursos injetados pela VNET não podem interagir com o Link Privado por padrão. Se você quiser usar o Link Privado para rede privada, confira Rede do servidor flexível do Banco de Dados do Azure para PostgreSQL com o Link Privado.

Nome do host

Independentemente da opção de rede escolhida, recomendamos que você sempre use um FQDN como o nome do host ao se conectar à instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. Não há garantia de que o endereço IP do servidor permanecerá estático. Usar o FQDN ajuda você a evitar fazer alterações na cadeia de conexão.

Um exemplo que usa um FQDN como nome de host é hostname = servername.postgres.database.azure.com. Sempre que possível, evite usar hostname = 10.0.0.4 (um endereço privado) ou hostname = 40.2.45.67 (um endereço público).

Conteúdo relacionado

• Azure portal
• CLI do Azure