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 o Banco de Dados do Azure para instâncias de servidor flexíveis do 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 rede de acesso privado (integração de 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 numa rede virtual comunicam através de endereços IP privados que atribui nesta rede.

Escolha esta opção de rede se desejar os seguintes recursos:

• Conecte-se a partir de recursos do Azure na mesma rede virtual à sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL usando endereços IP privados.
• Use uma VPN ou Azure ExpressRoute para se conectar de recursos que não são do Azure à sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL.
• Certifique-se de que a instância de servidor flexível do Banco de Dados do Azure para PostgreSQL não tenha nenhum ponto de extremidade público acessível pela Internet.

No diagrama anterior:

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

Conceitos de rede virtual

Uma rede virtual Azure contém um espaço de endereços IP privados que configura para o seu 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, consulte a visão geral da Rede Virtual do Azure.

Familiarize-se com estes conceitos ao utilizar redes virtuais, onde os recursos estão integrados numa rede virtual com o Azure Database for PostgreSQL em instâncias de servidor flexíveis.

• Sub-rede delegada: uma rede virtual contém sub-redes (sub-redes). As sub-redes permitem segmentar sua rede virtual em espaços de endereço menores. Implementas recursos Azure 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, apenas o Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL pode usar essa sub-rede. Nenhum outro tipo de recurso do Azure pode estar na sub-rede delegada. Você delega uma sub-rede atribuindo sua propriedade de delegação como Microsoft.DBforPostgreSQL/flexibleServers.

  O menor intervalo CIDR que você pode especificar para a sub-rede é /28, que fornece 16 endereços IP. O primeiro e o último endereço em qualquer rede ou sub-rede não podem ser atribuídos a nenhum host individual. O Azure reserva cinco IPs para serem usados internamente pela rede do Azure, que inclui dois IPs que não podem ser atribuídos ao host, conforme mencionado. Esta reserva deixa-lhe 11 endereços IP disponíveis para um intervalo de /28 CIDR. 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 é encaminhar todo o tráfego de saída através de um Azure Firewall ou de um dispositivo de filtragem de rede personalizado nas instalações.

  Se a sub-rede tiver uma tabela de rotas associada à regra para rotear todo o tráfego para um dispositivo virtual:

  • Adicione uma regra com a tag 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 do servidor flexível do Banco de Dados do Azure para PostgreSQL e o próximo salto Virtual Network.

  Importante

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

• Grupo de segurança de rede (NSG): as regras de segurança em NSGs permitem filtrar o tipo de tráfego de rede que pode entrar e sair de sub-redes de rede virtual e interfaces de rede. Para obter mais informações, consulte a visão geral do NSG.

  Os grupos de segurança de aplicativos (ASGs) facilitam o controle da segurança da Camada 4 usando NSGs para redes planas. Pode rapidamente:

  • Junte máquinas virtuais a um ASG ou remova máquinas virtuais de um ASG.
  • Aplique regras dinamicamente a essas máquinas virtuais ou remova regras dessas máquinas virtuais.

  Para obter mais informações, consulte a visão geral do ASG.

  Neste momento, as instâncias de servidor flexível do Azure Database para PostgreSQL não suportam NSGs em que um ASG faz parte da regra. Utilize filtragem de origem ou destino baseada em IP num NSG.

  A alta disponibilidade e outras funcionalidades do Azure Database for PostgreSQL requerem a capacidade de enviar e receber tráfego para a porta de destino 5432 dentro da sub-rede virtual Azure, onde é implementada uma instância de servidor flexível Azure Database for PostgreSQL, e para o Azure Storage para arquivamento de logs. 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 onde 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 garantir alta disponibilidade, a melhor prática é adicionar um serviço da Microsoft. Endpoint de serviço de armazenamento porque assegura o encaminhamento correto do tráfego para a conta de armazenamento da Azure, utilizada para carregar ficheiros de Write Ahead Log (WAL).

  Você pode filtrar ainda mais esta regra de exceção adicionando a 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 seu Banco de Dados do Azure para instância de servidor flexível do PostgreSQL, permita o tráfego de saída para a ID do Microsoft Entra usando uma marca de serviço do Microsoft Entra.

  Quando você configura 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 primário e réplica e para o Armazenamento do Azure em regiões primárias e de réplica de servidores primários e de réplica. A porta TCP de destino necessária para armazenamento é 443.

• Integração de zona DNS privada: a integração de zona DNS privada do Azure permite resolver o DNS privado dentro da rede virtual atual ou de qualquer rede virtual emparelhada na região onde a zona DNS privada está 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 na rede virtual sem a necessidade de configurar uma solução DNS personalizada.

Quando utiliza acesso à rede privada com uma rede virtual Azure, deve fornecer a informação da zona DNS privada para permitir a resolução DNS. Para novas instâncias de servidor flexível Azure Database for PostgreSQL criadas através do acesso privado à rede, é necessário usar zonas DNS privadas ao configurar o Azure Database para instâncias de servidor flexível PostgreSQL com acesso privado.

Importante

Ao usar uma zona DNS privada numa subscrição diferente, essa subscrição deve ter também o fornecedor de recursos Microsoft.DBforPostgreSQL registado. Caso contrário, a implementação de uma instância de servidor flexível Azure Database para PostgreSQL não será concluída.

Para novas instâncias de servidor flexível do Azure Database for PostgreSQL criadas usando acesso privado à rede com uma API, template Azure Resource Manager (template ARM), Bicep ou Terraform, devem ser criadas zonas DNS privadas. Em seguida, use-os enquanto configura o Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL com acesso privado. Para obter mais informações, consulte Especificações da API REST para o Azure.

Se você usar o portal do Azure ou a CLI do Azure para criar o Banco de Dados do Azure para instâncias de servidor flexíveis do 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 usar uma API Azure, um template ARM, Bicep ou Terraform, crie zonas DNS privadas que terminem em .postgres.database.azure.com. Use essas zonas enquanto configura o Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL com acesso privado. Por exemplo, use o formulário [name1].[name2].postgres.database.azure.com ou [name].postgres.database.azure.com. Se optares por usar o formulário [name].postgres.database.azure.com, o nome não pode ser o nome que usas para uma das tuas instâncias de servidor flexível do Azure Databases para PostgreSQL, caso contrário vais receber uma mensagem de erro durante o provisionamento. Para obter mais informações, consulte Visão geral de zonas DNS privadas.

Quando usa o portal Azure, APIs, a CLI Azure ou um template ARM, também pode alterar a zona DNS Privada daquela que forneceu ao criar a sua instância de servidor flexível Azure Database para PostgreSQL para outra zona DNS Privada que exista na mesma subscrição ou noutra subscrição.

Importante

A capacidade de alterar uma zona DNS Privada daquela 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 está atualmente desabilitada para servidores com o recurso de alta disponibilidade habilitado.

Depois de criar uma zona DNS privada no Azure, você precisa vincular uma rede virtual a ela. Os recursos hospedados na rede virtual vinculada podem acessar a zona DNS privada.

Importante

Deixámos de validar a presença de ligação de rede virtual na criação de instâncias de servidor flexíveis do Azure Database for PostgreSQL com rede privada. Quando você cria um servidor por meio do portal, oferecemos ao cliente a opção de criar um link na criação do servidor por meio da caixa de seleção Vincular uma zona DNS privada à sua rede virtual no portal do Azure.

As zonas privadas de DNS são resilientes a interrupções regionais porque os dados de zona estão disponíveis globalmente. Os registos de recursos numa zona privada são replicados automaticamente entre regiões. O DNS Privado do Azure é um serviço fundamental de zona de disponibilidade, 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 utilizar um servidor DNS personalizado, deve usar um encaminhador DNS para resolver o Nome de Domínio Totalmente Qualificado (FQDN) para a sua instância de servidor flexível do Azure Database for PostgreSQL. O endereço IP do encaminhador deve ser 168.63.129.16.

O servidor DNS personalizado deve estar dentro da rede virtual ou acessível através da configuração do servidor DNS da rede virtual. Para obter mais informações, veja Resolução de nomes que utiliza o seu próprio servidor DNS.

Importante

As atualizações de manutenção agendadas atualizam automaticamente as definições personalizadas do seu servidor DNS. Para reconhecer e aplicar definições DNS personalizadas atualizadas antes da próxima atualização agendada, a Microsoft deve realizar a atualização internamente, pois esta funcionalidade não é exposta através de APIs ou controlos direcionados para o cliente. Se precisar que a alteração entre em vigor mais cedo, contacte o Suporte da Microsoft.

Zona DNS privada e emparelhamento de rede virtual

As configurações de zona DNS privada e o emparelhamento de rede virtual são independentes uns dos outros. Se quiser ligar-se à instância de servidor flexível do Azure Database for PostgreSQL a partir de um cliente que provisiona noutra rede virtual da mesma região ou de uma região diferente, precisa de ligar a zona privada de DNS à rede virtual. Para obter mais informações, consulte Vincular a rede virtual.

Observação

Só pode ligar nomes de zonas DNS privadas que terminem em postgres.database.azure.com. O nome da zona DNS não pode ser o mesmo que o Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL. Caso contrário, a resolução de nomes falhará.

Para mapear um nome de servidor para o registo DNS, execute o nslookup comando no Azure Cloud Shell usando Azure PowerShell ou Bash. Substitua o nome do seu servidor pelo <server_name> parâmetro no seguinte exemplo:

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

Use o design de rede privada em modelo hub e spoke

O Hub and spoke é um modelo de rede popular para gerenciar com eficiência os requisitos comuns de comunicação ou segurança.

O hub é uma rede virtual que atua como um local central para gerenciar a conectividade externa. Ele também aloja serviços utilizados por várias cargas de trabalho. O hub coordena todas as comunicações de e para os spokes. As regras ou processos de TI, como a segurança, podem inspecionar, encaminhar e gerir o tráfego de forma centralizada. Os "spokes" são redes virtuais que alojam cargas de trabalho e se conectam ao "hub" central através de conexão ponto-a-ponto de redes virtuais. Os serviços compartilhados são hospedados em suas próprias sub-redes para compartilhamento com os porta-vozes. Em seguida, uma sub-rede de perímetro atua como um dispositivo de segurança.

As conexões são também redes virtuais no Azure que são utilizadas para isolar cargas de trabalho individuais. O fluxo de tráfego entre a sede local e o Azure é estabelecido por meio do Azure ExpressRoute ou de uma VPN site a site, ambas conectadas à rede virtual do hub. As redes virtuais dos spokes para o hub são emparelhadas e permitem a comunicação com recursos no local. O hub e cada spoke podem ser implementados em subscrições ou grupos de recursos separados.

Existem três padrões principais para conectar redes virtuais faladas entre si:

• Os spokes estão diretamente conectados entre si: Você cria peerings de redes virtuais ou túneis VPN entre as redes virtuais spokes para fornecer conectividade direta sem atravessar a rede virtual do hub.
• Os espetos comunicam-se por meio de um aparelho de rede: cada rede virtual spoke tem um emparelhamento para uma WAN virtual ou para uma rede virtual hub. Um dispositivo direciona o tráfego de extremidade para extremidade. O dispositivo pode ser gerenciado pela Microsoft (como em uma WAN virtual) ou por você.
• Um gateway de rede virtual está ligado à rede do hub e utiliza rotas definidas pelo utilizador: Permite a comunicação entre as ramificações.

Utilize o Azure Virtual Network Manager para criar novas topologias de rede virtual hub-and-spoke (e integrar as já existentes) para a gestão centralizada dos controlos de conectividade e segurança.

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

Frequentemente, os utilizadores precisam de se conectar a clientes em diferentes regiões do Azure. Mais especificamente, essa pergunta 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.

Pode alcançar essa conectividade de várias formas, incluindo:

• Emparelhamento de rede virtual global. Esta metodologia é a mais comum porque é a maneira mais fácil de conectar redes em diferentes regiões juntas. O emparelhamento de rede virtual global cria uma conexão no backbone do Azure diretamente entre as duas redes virtuais emparelhadas. Esse método fornece a melhor taxa de transferência de rede e as menores latências para conectividade. Quando faz peering de redes virtuais, o Azure também trata do roteamento de forma automática. Essas redes virtuais podem se comunicar com todos os recursos na rede virtual emparelhada que são estabelecidos em um gateway VPN.
• Ligação de rede para rede. Uma conexão entre redes virtuais (conexão rede-a-rede) é essencialmente uma VPN entre os dois locais do Azure. Estabeleces a ligação rede a rede num gateway VPN. Seu tráfego incorre em mais dois saltos de tráfego em comparação com o emparelhamento de rede virtual global. Há também latência extra e menor largura de banda em comparação com esse método.
• Comunicação via dispositivo de rede em arquitetura hub-and-spoke. Em vez de conectar redes virtuais satélite diretamente umas às outras, pode-se usar dispositivos de rede para encaminhar o tráfego entre as redes satélite. Os dispositivos de rede fornecem mais serviços de rede, como inspeção profunda de pacotes e segmentação ou monitoramento de tráfego, 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, mas as réplicas servem apenas para transações de leitura única. 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 dos dados, especialmente em aplicativos de alto tráfego e de missão crítica.

A Base de Dados Azure para PostgreSQL oferece dois métodos de replicação: físico (ou seja, streaming) por meio do recurso interno de Read Replica e replicações lógicas. Ambos são ideais para diferentes casos de uso, e podes escolher um em detrimento do outro, dependendo do teu objetivo final.

A replicação entre regiões do Azure, com redes virtuais separadas em cada região, requer conectividade através dos limites regionais de redes virtuais que o peering de rede virtual ou um dispositivo de rede em arquiteturas hub-and-spoke pode fornecer.

Por padrão, a resolução de nomes DNS tem como escopo uma rede virtual. Qualquer cliente numa rede virtual (VNET1) não consegue resolver a instância de servidor flexível do Azure Database for PostgreSQL FQDN noutra rede virtual (VNET2).

Para resolver este problema, certifique-se de que os clientes no VNET1 podem aceder à zona de DNS privada da instância de servidor flexível da Azure Database para PostgreSQL. Adicione um link de rede virtual à zona DNS privada do seu Banco de Dados do Azure para instância de servidor flexível do PostgreSQL.

Cenários de rede virtual não suportados

Aqui estão algumas limitações para trabalhar com redes virtuais criadas através da integração de rede virtual:

• Depois de implementar uma instância de servidor flexível Azure Database for PostgreSQL para uma rede virtual e sub-rede, não pode movê-la para outra rede ou sub-rede virtual. Não é possível mover a rede virtual para outro grupo de recursos ou assinatura.
• Não podes aumentar o tamanho da sub-rede (espaços de endereçamento) depois de existirem recursos na sub-rede.
• Por defeito, os recursos injetados por rede virtual não podem interagir com o Private Link. Se você quiser usar o Link Privado para rede privada, consulte Banco de Dados do Azure para rede PostgreSQL com Link Privado.

Importante

O Azure Resource Manager dá suporte à capacidade de bloquear recursos como um controle de segurança. Os bloqueios de recursos são aplicados ao recurso e são eficazes em todos os usuários e funções. Existem dois tipos de bloqueio de recursos: CanNotDelete e ReadOnly. Pode aplicar estes tipos de bloqueio tanto a uma zona DNS privada quer a um conjunto de registos individual.

A aplicação de um bloqueio de qualquer tipo em uma zona DNS privada ou em um conjunto de registros individuais pode interferir na capacidade de uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL atualizar registros DNS. Também pode causar problemas durante operações importantes no DNS, como na comutação por falha de alta disponibilidade do servidor primário para o servidor secundário. Por estas razões, certifique-se de que não está a usar uma zona privada DNS ou bloqueios de registos quando utiliza funcionalidades de alta disponibilidade com uma instância de servidor flexível Azure Database for PostgreSQL.

Nome do anfitrião

Independentemente da opção de rede que escolher, use sempre um nome de domínio totalmente qualificado (FQDN) como nome de host quando se ligar à sua Azure Database para uma instância de servidor flexível PostgreSQL. O endereço IP do servidor pode mudar. Ao usar o FQDN, não precisa de atualizar a sua cadeia de ligação.

Um exemplo que usa um FQDN como um 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

• portal do Azure
• Azure CLI