Share via

Visão geral da rede do Banco de Dados do Azure para PostgreSQL - Servidor flexível com acesso privado (integração VNET)

  • Artigo

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

Este artigo descreve os conceitos de conectividade e rede para o Banco de Dados do Azure para servidor flexível 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 de VNet)

Você pode implantar uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL em sua rede virtual do Azure (VNet) usando a 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 foram atribuídos nessa 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 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.

Diagrama que mostra como o emparelhamento funciona entre redes virtuais, uma das quais inclui uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL.

No diagrama anterior:

  • Os Bancos de Dados do Azure para instâncias de servidor flexíveis PostgreSQL são injetados 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 o servidor flexível.

Conceitos de rede virtual

Uma rede virtual do Azure contém um espaço de endereço IP privado configurado para 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.

Aqui estão alguns conceitos com os quais você deve estar familiarizado quando você estiver usando redes virtuais onde os recursos são integrados à rede virtual com o Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL:

  • 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. 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 integrado à VNET para PostgreSQL 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, 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 para 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 Microsoft Entra, certifique-se de que as tabelas de rotas não afetem o tráfego. Um padrão comum é roteado 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 um dispositivo virtual:

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

    Importante

    Os nomes AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnete GatewaySubnet são reservados no Azure. Não use nenhum deles como nome de sub-rede.

  • Grupo de Segurança de Rede (NSG). As regras de segurança nos 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 dinamicamente regras a essas máquinas virtuais ou remova regras dessas máquinas virtuais.

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

    No momento, não damos suporte a NSGs em que um ASG faz parte da regra com o Banco de Dados do Azure para servidor flexível PostgreSQL. Atualmente, aconselhamos o uso de filtragem de origem ou destino baseada em IP em um NSG.

    Importante

    A alta disponibilidade e outros recursos do Banco de Dados do Azure para servidor flexível PostgreSQL exigem a capacidade de enviar/receber tráfego para a porta de destino 5432 na sub-rede de rede virtual do Azure onde o servidor flexível do Banco de Dados do Azure para PostgreSQL é implantado, bem como para o armazenamento do Azure para arquivamento de log. Se você criar NSG (Grupos de Segurança de Rede) 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 do Azure usando a 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 em seu Banco de Dados do Azure para instância flexível do servidor PostgreSQL, permita o tráfego de saída para o ID do Microsoft Entra usando a marca de serviço 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 requer a capacidade de enviar/receber tráfego para a porta de destino 5432 para primário e réplica, 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 da zona DNS privada do Azure permite resolver o DNS privado na rede virtual atual ou em qualquer rede virtual emparelhada na região onde a zona DNS privada está vinculada.

Usando 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.

Ao usar o acesso à rede privada com a rede virtual do Azure, fornecer as informações da zona DNS privada é obrigatório para poder fazer a resolução de DNS. Para a criação de novas instâncias de servidor flexíveis do Banco de Dados do Azure para PostgreSQL usando acesso à rede privada, as zonas DNS privadas precisam ser usadas durante a configuração do Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL com acesso privado. Para a nova criação de instância de servidor flexível do Banco de Dados do Azure para PostgreSQL usando acesso à rede privada com API, ARM ou Terraform, crie zonas DNS privadas e use-as ao configurar o Banco de Dados do Azure para instâncias de servidor flexíveis do 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 o Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL, poderá fornecer um nome de zona DNS privada que você criou 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 Azure Resource Manager (modelo ARM) ou Terraform, crie zonas DNS privadas que terminem com .postgres.database.azure.com. Use essas zonas ao configurar 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 você optar por usar o formulário [name].postgres.database.azure.com, o nome não poderá ser o nome usado para um dos seus Bancos de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL ou uma mensagem de erro será mostrada durante o provisionamento. Para obter mais informações, consulte a visão geral das zonas DNS privadas.

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

Importante

A capacidade de alterar a Zona DNS privada daquela que você forneceu ao criar 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. Uma vez vinculados, os recursos hospedados nessa rede virtual podem acessar a zona DNS privada.

Importante

Não validamos mais a presença de link de rede virtual na criação de servidor para o Banco de Dados do Azure para servidor flexível PostgreSQL com rede privada. Ao criar um servidor através do portal, oferecemos ao cliente a opção de criar um link na criação do servidor através da caixa de verificação "Vincular 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 registros de recursos em uma zona privada são replicados automaticamente entre regiões. O DNS Privado do Azure é um serviço básico de zona de disponibilidade, redutor 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 do Banco de Dados do Azure para servidor flexível 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 saber mais, consulte Resolução de nomes que usa seu próprio servidor DNS.

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 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 obter mais informações, consulte Vincular a rede virtual.

Nota

Apenas os nomes de zonas DNS privadas que terminam com 'postgres.database.azure.com' podem ser ligados. O nome da zona DNS não pode ser igual à(s) instância(s) flexível(is) do servidor 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 usando o Azure PowerShell ou Bash, substituindo o nome do seu servidor por <server_name> parâmetro no exemplo abaixo:

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

Usando o design de rede privada 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 hospeda serviços usados 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 ligam ao hub central através do peering de rede virtual. 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.

Os spokes também são redes virtuais no Azure utilizadas para isolar cargas de trabalho individuais. O fluxo de tráfego entre a sede local e o Azure é conectado por meio da Rota Expressa ou da VPN Site to Site, conectado à rede virtual do hub. As redes virtuais dos spokes ao hub são colocadas em modo de peering e permitem a comunicação com os 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:

  • Raios diretamente conectados 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 do hub.
  • Os raios comunicam através de um dispositivo de rede. Cada rede virtual spoke tem um emparelhamento para a WAN Virtual ou para uma rede virtual de hub. Um aparelho direciona o tráfego de falado para falado. O dispositivo pode ser gerenciado pela Microsoft (como acontece com a WAN Virtual) ou por você.
  • Gateway de Rede Virtual conectado à rede de hub e fazer uso de Rotas Definidas pelo Usuário (UDR), para permitir a comunicação entre os raios.

Diagrama que mostra a arquitetura básica de hub e spoke com conectividade híbrida via Express Hub.

Use o Azure Virtual Network Manager (AVNM) para criar topologias de rede virtual novas (e integradas existentes) hub e spoke para o gerenciamento central de controles de conectividade e segurança.

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

Frequentemente, os clientes precisam se conectar a clientes de diferentes regiões do Azure. Mais especificamente, essa pergunta normalmente se resume a como conectar duas VNETs (uma das quais tem o Banco de Dados do Azure para PostgreSQL - Servidor Flexível e outro cliente de aplicativo) que estão em regiões diferentes. Existem várias maneiras de alcançar essa conectividade, algumas das quais são:

  • Emparelhamento VNET global. Metodologia mais comum, pois é a maneira mais fácil de conectar redes em diferentes regiões juntas. O emparelhamento VNET global cria uma conexão no backbone do Azure diretamente entre as duas VNETs emparelhadas. Isso fornece a melhor taxa de transferência de rede e as menores latências para conectividade usando esse método. Quando as VNETs são emparelhadas, o Azure também manipula o roteamento automaticamente para você, essas VNETs podem se comunicar com todos os recursos na VNET emparelhada, estabelecida em um gateway VPN.
  • Conexão VNET-to-VNET. Uma conexão VNET-to-VNET é essencialmente uma VPN entre os dois locais diferentes do Azure. A conexão VNET-to-VNET é estabelecida em um gateway VPN. Isso significa que seu tráfego incorre em dois saltos de tráfego adicionais em comparação com o emparelhamento VNET global. Há também latência adicional e menor largura de banda em comparação com esse método.
  • Comunicação via dispositivo de rede na arquitetura Hub e Spoke. Em vez de conectar redes virtuais faladas diretamente umas às outras, você pode usar dispositivos de rede para encaminhar o tráfego entre raios. 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, enquanto as réplicas servem 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 dos dados, especialmente em aplicativos de alto tráfego e de missão crítica.

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. Ambos são ideais para diferentes casos de uso, e um usuário pode escolher um em vez do outro, dependendo do objetivo final.

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

Por padrão , a resolução de nomes DNS tem como escopo uma rede virtual. Isso significa que qualquer cliente em uma rede virtual (VNET1) não 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ê deve certificar-se de que os clientes em VNET1 podem acessar o Banco de Dados do Azure para PostgreSQL servidor flexível Zona DNS Privada. Isso pode ser conseguido adicionando um link de rede virtual à Zona DNS Privada da sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL.

Cenários de rede virtual não suportados

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

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

Importante

O Azure Resource Manager suporta a capacidade de bloquear recursos, como um controlo 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. Esses tipos de bloqueio podem ser aplicados a uma zona DNS privada ou a um conjunto de registros individual. A aplicação de um bloqueio de qualquer tipo na Zona DNS Privada ou no conjunto de registros individuais pode interferir na capacidade do Servidor flexível do Banco de Dados do Azure para PostgreSQL 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, certifique-se de que não está utilizando a zona privada DNS ou bloqueios de registro ao utilizar recursos de Alta Disponibilidade com o Banco de Dados do Azure para servidor flexível PostgreSQL.

Nome do anfitrião

Independentemente da opção de rede escolhida, recomendamos que você sempre use um FQDN como nome de host ao se conectar à sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. Não é garantido que o endereço IP do servidor permaneça estático. Usar o FQDN ajuda a evitar fazer alterações na cadeia de conexã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).

Próximos passos

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