Visão geral de rede do Banco de Dados do Azure para PostgreSQL – Servidor Flexível com acesso privado (Integração VNET)

APLICA-SE A: Banco de Dados do Azure para PostgreSQL – Servidor Flexível

Este artigo descreve os conceitos de conectividade e rede para o servidor flexível 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 VNet) ou acesso público (endereços IP permitidos) e ponto de extremidade privado. Este documento descreverá a opção de rede de Acesso privado (integração VNet).

Acesso privado (integração da VNet)

Você pode implantar uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL em sua VNet (rede virtual) do Azure usando injeção de VNET. 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 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 VPN ou 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 Banco de Dados do Azure para PostgreSQL não tem nenhum ponto de extremidade público acessível pela Internet.

No diagrama anterior:

• As instâncias de servidor flexível dos Banco de Dados do Azure para PostgreSQL são injetadas 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ível do Banco de Dados do Azure para PostgreSQL.
• Os aplicativos implantados em uma rede virtual diferente (VNet-2) não têm acesso direto às instâncias de servidor flexível 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 o 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 com os quais se familiarizar quando você estiver usando redes virtuais onde os recursos são integrados à rede virtual com instâncias de servidor flexível 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 da VNET deve estar em uma sub-rede delegada. Ou seja, somente instâncias de servidor flexível do Banco de Dados PostgreSQL do Azure 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 de CIDR que você pode especificar para uma sub-rede é /28, que fornece 16 endereços IP. No entanto, 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 a serem utilizados internamente pela rede do Azure, que incluem dois IPs que não podem ser atribuídos ao host, mencionados acima. Isso deixa 11 endereços IP disponíveis para o intervalo CIDR /28, enquanto uma única instância de servidor flexível do Banco de Dados do Azure para PostgreSQL com recursos de Alta Disponibilidade utiliza quatro endereços. Para conexões de Replicação e do Microsoft Entra, certifique-se de que as Tabelas de Rotas não afetem o tráfego. Um padrão comum é rotear todo o tráfego de saída através 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 um dispositivo virtual:

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

  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 sua sub-rede.

• NSG (grupo de segurança de rede) . As regras de segurança em grupos de segurança de rede permitem filtrar o tipo de tráfego de rede que pode fluir para dentro e para 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.

  Neste momento, não oferecemos suporte ao uso de grupos de segurança de rede com o servidor flexível do Banco de Dados do Azure para PostgreSQL nos casos em que um ASG faça parte da regra. Atualmente, recomendados o uso de filtros de origem ou destino baseados em IP em um grupo de segurança de rede.

  Importante

  A alta disponibilidade e outros Recursos do servidor flexível do Banco de Dados do Azure para PostgreSQL exigem a capacidade de enviar e receber tráfego para a porta de destino 5432 da sub-rede da Rede Virtual do Azure em que o servidor flexível do Banco de Dados do Azure para PostgreSQL está implantado, bem como para o Armazenamento do Azure para arquivamento de log. Se você criar Grupos de Segurança de Rede (NSG) para negar o fluxo de tráfego de ou para o servidor flexível do Banco de Dados do Azure para PostgreSQL na sub-rede em que ele foi implantado, precisará permitir o tráfego na porta de destino 5432 da sub-rede e também no armazenamento do Azure por meio da marca de serviço Armazenamento do Azure como destino. 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 logons na instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, permita o tráfego de saída para o Microsoft Entra ID usando a marca de serviço do Microsoft Entra. Ao configurar Réplicas de Leitura em regiões do Azure, o servidor flexível do Banco de Dados do Azure para PostgreSQL, isso requer a capacidade de enviar/receber tráfego para a porta de destino 5432 para réplica e primárias, bem como para o armazenamento do Azure em regiões primárias e de réplica de servidores primários e de réplica.

• Integração de zona DNS privada. A integração de zona DNS privada do Azure permite que você resolva o DNS privado na rede virtual atual ou em qualquer rede virtual emparelhada na região à qual a zona de DNS privado 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 a rede virtual do Azure, é obrigatório fornecer as informações da zona DNS privada para poder fazer a resolução de DNS. Para a criação da instância de servidor flexível do Banco de Dados do Azure para PostgreSQL usando o acesso à rede privada, as zonas DNS privadas precisarão ser usadas ao configurar instâncias de servidor flexíveis do Banco de Dados do Azure para PostgreSQL com acesso privado. Para a criação da instância de servidor flexível do Banco de Dados do Azure para PostgreSQL usando o acesso à rede privada com API, ARM ou Terraform, crie zonas DNS privadas e use-as ao configurar instâncias de servidor flexível do Banco de Dados do Azure para PostgreSQL com acesso privado. Veja mais informações sobre as especificações da API REST para o Microsoft Azure. Se você usar o portal do Azure ou a CLI do Azure para criar instâncias de servidor flexível do Banco de Dados do Azure para PostgreSQL, poderá fornecer um nome de zona DNS privada que você criou anteriormente no mesmo ou em uma assinatura diferente ou uma zona DNS privada padrão será criada automaticamente em sua assinatura.

Se for usar uma API do Azure, um modelo do Azure Resource Manager (modelo do ARM) ou o Terraform, crie zonas DNS privadas que terminem com .postgres.database.azure.com. Use essas zonas ao configurar instâncias de servidor flexível do Banco de Dados do Azure para 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 usado para uma das instâncias de servidor flexível dos Bancos de Dados do Azure para PostgreSQL ou uma mensagem de erro será mostrada durante o provisionamento. Para saber mais, confira a Visão geral de zonas DNS privadas.

Usando o Portal do Azure, a API, a CLI ou o ARM, você também pode alterar a Zona DNS privada daquela fornecida ao criar sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL para outra zona DNS privada que existe a mesma assinatura ou diferente.

Importante

A capacidade de alterar a Zona DNS privada da que você forneceu ao criar seu Banco de Dados do Azure para a instância de servidor flexível do Banco de Dados do Azure para PostgreSQL para outra zona DNS privada está desabilitada no momento para servidores com o recurso de Alta Disponibilidade habilitado.

Depois de criar uma zona DNS privada no Azure, você precisará vincular uma rede virtual a ela. Uma vez vinculada, os recursos hospedados nessa rede virtual podem acessar a zona DNS privada.

Importante

Nós não validamos mais a presença de link de rede virtual na criação do servidor para o servidor flexível do Banco de Dados do Azure para PostgreSQL com rede privada. Ao criar o servidor por meio do portal, damos ao cliente a opção de criar um link na criação do servidor por meio da caixa de seleção “Vincular DNS privado Zona da sua rede virtual” no portal do Azure.

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 fundacional de zona de disponibilidade, redundante em zona. Para obter mais informações, consulte Serviços do Azure com suporte à zona de disponibilidade.

Integração com um servidor DNS personalizado

Se estiver usando um servidor DNS personalizado, você deverá usar um encaminhador de DNS para resolver o FQDN do 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ê deseja se conectar a 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.

Observação

Apenas nomes de zonas DNS privadas que terminam com "postgres.database.azure.com" podem ser vinculados. O nome da zona DNS não pode ser o mesmo que a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL, caso contrário, a resolução de nomes falhará.

Para mapear um nome de servidor para o registro DNS, você pode executar o comando nslookup no Azure Cloud Shell por meio do Azure PowerShell ou Bash, substituindo o nome do servidor pelo parâmetro <server_name> no exemplo abaixo:

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

Uso do design 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 redes virtuais que hospedam 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 usadas para isolar cargas de trabalho individuais. O fluxo de tráfego entre a matriz local e o Azure é conectado por meio de um circuito do ExpressRoute ou de uma VPN site a site conectado à rede virtual 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:

• Spokes conectados diretamente uns aos outros. 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 hub.
• Spokes que se comunicam por meio de um dispositivo de rede. Cada rede virtual spoke tem um emparelhamento com a WAN virtual ou com uma rede virtual 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ê.
• Gateway de Rede Virtual anexado à rede do hub e uso de UDR (Rotas Definidas pelo Usuário) para habilitar a comunicação entre os spokes.

Use o AVNM (Gerenciador de Rede Virtual do Azure) para criar topologias de rede virtual de hub e spoke (e integrar as existentes) 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 a clientes de diferentes regiões do Azure. Mais especificamente, essa questão geralmente se resume a como conectar duas VNETs (sendo uma delas com o servidor flexível do Banco de Dados do Azure para PostgreSQL e outro cliente de aplicativo) que estão em regiões diferentes. Há várias maneiras de alcançar essa conectividade, algumas das quais são:

• Emparelhamento global de VNET. Metodologia mais comum, pois é a maneira mais fácil de conectar redes em diferentes regiões. O emparelhamento global de VNETs cria uma conexão pelo backbone do Azure diretamente entre os duas VNETs emparelhadas. Isso fornece a melhor taxa de transferência de rede e latências mais baixas para conectividade usando esse método. Quando as VNETs são emparelhadas, o Azure também lida com o roteamento automaticamente para você. Essas VNETs podem se comunicar com todos os recursos na VNET emparelhada, estabelecida em um gateway de VPN.
• Conexão de VNET para VNET. Uma conexão de VNET para VNET é essencialmente uma VPN entre os dois locais diferentes do Azure. A conexão VNET para VNET é estabelecida em um gateway de VPN. Isso significa que o tráfego incorre em dois saltos de tráfego adicionais em comparação com o emparelhamento global de VNETs. Também há latência adicional e menor largura de banda 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, enquanto 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 servidor flexível do Banco de Dados do Azure para PostgreSQL oferece dois métodos para replicações: físico (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 da meta final.

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

Por padrão, a resolução de nomes DNS tem como escopo uma rede virtual. Isso significa que nenhum cliente em uma rede virtual (VNET1) consegue resolver o FQDN do servidor flexível do Banco de Dados do Azure para PostgreSQL em outra rede virtual (VNET2).

Para resolver esse problema, você precisa verificar se os clientes na VNET1 podem acessar a zona DNS privada do servidor flexível do Banco de Dados do Azure para PostgreSQL. Isso pode ser feito adicionando 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 a 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

Importante

O Azure Resource Manager dá suporte à capacidade de bloquear recursos, como um controle de segurança. Os bloqueios de recurso são aplicados ao recurso e são efetivos entre todos os usuários e funções. Há dois tipos de bloqueio de recurso: CanNotDelete e ReadOnly. Esses tipos de bloqueio podem ser aplicados a uma zona de DNS privado ou a um conjunto de registros individual. A aplicação de um bloqueio de qualquer tipo em uma Zona DNS privada ou conjunto de registros individuais pode interferir na capacidade do servidor flexível do Banco de Dados do Azure para PostgreSQL de atualizar registros DNS e causar problemas durante operações importantes no DNS, como failover de alta disponibilidade do primário para o secundário. Por esses motivos, verifique se você não está utilizando bloqueios de registro ou zona privada DNS ao utilizar recursos de alta disponibilidade com o servidor flexível do Banco de Dados do Azure para PostgreSQL.

Nome do host

Qualquer que seja a opção de rede escolhida, é recomendável usar sempre um FQDN (nome de domínio totalmente qualificado) como 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 ajudará 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).

Próximas etapas

• Saiba como criar uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL por meio da opção Acesso privado (integração de VNet) no portal do Azure ou na CLI do Azure.