Compartilhar via

Rede com acesso privado (integração de rede virtual) para o Banco de Dados do Azure para PostgreSQL – Servidor Flexível

  • 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 PostgreSQL - Servidor flexível.

Ao criar um servidor flexível do Banco de Dados do Azure para PostgreSQL, escolha uma das seguintes opções de sistema 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 um servidor flexível do Banco de Dados do Azure para PostgreSQL em sua rede virtual do Azure usando uma 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 as seguintes funcionalidades:

  • Conectar-se de recursos do Azure na mesma rede virtual ao servidor flexível do Banco de Dados do Azure para PostgreSQL usando endereços IP privados.
  • Usar uma VPN ou o Azure ExpressRoute para se conectar de recursos que não são do Azure ao servidor flexível do Banco de Dados do Azure para PostgreSQL.
  • Verificar se o servidor flexível do Banco de Dados do Azure para PostgreSQL não tem nenhum ponto de extremidade público acessível pela Internet.

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

No diagrama anterior:

  • Os servidores flexíveis do Banco de Dados do Azure para PostgreSQL são injetados 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 os servidores 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 aos servidores flexíveis do Banco de Dados do Azure para PostgreSQL. É necessário 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ços IP privado configurado para o uso. A rede virtual deve estar na mesma região do Azure que o 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 servidores 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.

    O servidor flexível do Banco de Dados do Azure para PostgreSQL integrado em uma rede virtual deve estar em uma sub-rede delegada. Ou seja, somente servidores 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. Um único 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 do Banco de Dados do Azure para PostgreSQL – Servidor Flexível 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.

    Neste momento, não oferecemos suporte ao uso de grupos de segurança de rede com o Banco de Dados do Azure para PostgreSQL – Servidor flexível 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.

    A alta disponibilidade e outros recursos do Banco de Dados do Azure para PostgreSQL – Servidor Flexível exigem a capacidade de enviar/receber tráfego nas porta de destino 5432 da sub-rede de rede virtual do Azure em que o Banco de Dados do Azure para PostgreSQL – Servidor Flexível está implantado, bem como no Armazenamento do Azure para arquivamento de log. Se você criar NSGs 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 usando a marca de serviço Armazenamento 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 as credenciais no servidor flexível do Banco de Dados do Azure para PostgreSQL, permita o tráfego de saída para o Microsoft Entra ID usando uma marca de serviço do Microsoft Entra.

    Ao configurar Réplicas de Leitura em regiões do Azure, o Banco de Dados do Azure para PostgreSQL – Servidor Flexível 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 qualquer 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 a criação de um 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 os servidores flexíveis do Banco de Dados do Azure para PostgreSQL com acesso privado.

Importante

Ao usar uma zona DNS privada em uma assinatura diferente, essa assinatura deve ter o provedor de recursos Microsoft.DBforPostgreSQL registrado. Caso contrário, a implantação do servidor flexível do Banco de Dados do Azure para PostgreSQL não será concluída.

Para a criação de um servidor flexível do Banco de Dados do Azure para PostgreSQL usando o acesso à rede privada com uma API, crie zonas DNS privadas usando o modelo do ARM (modelo do Resource Manager do Azure) ou o Terraform. Use essas zonas ao configurar os servidores flexíveis do Banco de Dados do Azure para PostgreSQL com acesso privado. Para obter mais informações, confira as especificações da API REST para o Azure.

Se você usar o portal do Azure ou a CLI do Azure para criar servidores flexíveis do Banco de Dados do Azure para PostgreSQL, poderá fornecer um nome de zona DNS privada que você criou anteriormente na mesma 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. Use essas zonas ao configurar os servidores flexíveis 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 dos servidores flexíveis do Banco de Dados do Azure para PostgreSQL ou uma mensagem de erro será exibida durante o provisionamento. Para obter mais informações, confira 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 a partir da fornecida ao criar o servidor flexível do Banco de Dados do Azure para PostgreSQL para outra zona DNS privada que existe na mesma assinatura ou em uma diferente.

Importante

A capacidade de alterar a zona DNS privada da que você forneceu ao criar seu 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. Os recursos hospedados nessa rede virtual podem então 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 Banco de Dados do Azure para PostgreSQL – Servidor Flexível com rede privada. Ao criar um servidor por meio do portal, fornecemos 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 à 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 Banco de Dados do Azure para PostgreSQL – Servidor flexível. 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 o 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 os dos servidores flexíveis 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 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.

Diagrama que mostra a arquitetura básica de hub e spoke com conectividade híbrida por meio de um hub expresso.

Use o Gerenciador de Rede Virtual do Azure para criar (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 geralmente se resume a como conectar duas redes virtuais (tendo uma delas o Banco de Dados do Azure para PostgreSQL – Servidor Flexível e outra 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 – Servidor Flexível 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 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 podem ser fornecidos 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. Nenhum cliente em uma rede virtual (VNET1) consegue resolver o FQDN do Banco de Dados do Azure para PostgreSQL – Servidor Flexível em outra rede virtual (VNET2).

Para resolver esse problema, você precisa verificar se os clientes na VNET1 podem acessar a zona DNS privada do Banco de Dados do Azure para PostgreSQL – Servidor Flexível. Adicione um link de rede virtual à zona DNS privada do 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 o servidor flexível do Banco de Dados do Azure para PostgreSQL for implantado em uma rede virtual e sub-rede, não será possível 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 Banco de Dados do Azure para PostgreSQL – Servidor Flexível com 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 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 em uma zona DNS privada ou conjunto de registros individuais pode interferir na capacidade do Banco de Dados do Azure para PostgreSQL – Servidor Flexível de atualizar registros DNS. Isso também pode 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á usando uma zona privada DNS ou bloqueios de registro ao usar recursos de alta disponibilidade com o Banco de Dados do Azure para PostgreSQL – Servidor Flexível.

Nome do host

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

Conteúdo relacionado