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

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

Este artigo descreve 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, 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 um 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 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 ao seu Banco de Dados do Azure para servidor flexível PostgreSQL usando endereços IP privados.
• Use uma VPN ou Azure ExpressRoute para se conectar de recursos que não são do Azure ao seu banco de dados do Azure para servidor flexível PostgreSQL.
• Certifique-se de que o 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:

• 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 dentro da mesma rede virtual podem acessar o Banco de Dados do Azure para servidores flexíveis PostgreSQL diretamente.
• Os aplicativos implantados em uma rede virtual diferente (VNet-2) não têm acesso direto ao Banco de Dados do Azure para servidores flexíveis 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 seu banco de dados do Azure para servidor flexível 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 em uma rede virtual com o Banco de Dados do Azure para servidores flexíveis 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.

  Seu 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, apenas o Banco de Dados do Azure para servidores flexíveis 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. 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 um dispositivo virtual:

  • Adicione uma regra com a etiqueta AzureActiveDirectory de serviço de destino e o próximo salto Internet.
  • Adicione uma regra com o intervalo de IP de destino igual ao Banco de Dados do Azure para PostgreSQL - Intervalo de sub-rede do Servidor Flexível 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.

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

  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 para a porta de destino 5432 dentro da sub-rede de rede virtual do Azure onde o Banco de Dados do Azure para PostgreSQL - Servidor Flexível é implantado e para o Armazenamento do Azure para arquivamento de log. Se você criar NSGs para negar o fluxo de tráfego de ou para o seu servidor flexível do Banco de Dados do Azure para PostgreSQL na sub-rede onde ele está 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.

  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 seu banco de dados do Azure para servidor flexível 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, 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 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 você usa o acesso à rede privada com uma 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 um novo 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 o Banco de Dados do Azure para servidores flexíveis PostgreSQL com acesso privado.

Importante

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

Para a nova criação de servidor flexível do Banco de Dados do Azure para PostgreSQL usando o acesso à rede privada com uma API, modelo do Azure Resource Manager (modelo ARM) ou Terraform, crie zonas DNS privadas. Em seguida, use-os enquanto configura o Banco de Dados do Azure para servidores flexíveis 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 servidores flexíveis 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 ARM ou Terraform, crie zonas DNS privadas que terminem com .postgres.database.azure.com. Use essas zonas enquanto configura o Banco de Dados do Azure para servidores flexíveis 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 servidores flexíveis do Banco de Dados do Azure para PostgreSQL ou você receberá uma mensagem de erro durante o provisionamento. Para obter mais informações, consulte Visão geral de zonas DNS privadas.

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

Importante

A capacidade de alterar uma zona DNS privada daquela que você forneceu quando criou seu 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

Não validamos mais a presença de link de rede virtual na criação do servidor para o Banco de Dados do Azure para PostgreSQL - Servidor flexível 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 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, redundante 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 PostgreSQL - Servidor Flexível. 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 ao banco de dados do Azure para servidor flexível PostgreSQL de um cliente que é provisionado em outra rede virtual da mesma região ou de uma região diferente, você precisa vincular a zona DNS privada com a rede virtual. Para obter mais informações, consulte Vincular a rede virtual.

Nota

Apenas os nomes de zona DNS privada que terminam com postgres.database.azure.com podem ser ligados. O nome da zona DNS não pode ser o mesmo que o Banco de Dados do Azure para servidores flexíveis 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 no Azure Cloud Shell usando o nslookup Azure PowerShell ou 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'

Use o design de rede privada hub-and-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 raios 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 sede local e o Azure é conectado por meio da Rota Expressa do Azure ou VPN site a site, conectado à rede virtual do hub. As redes virtuais dos raios para o hub são emparelhadas e permitem a comunicação com recursos locais. 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 raios são 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 do hub.
• Os raios se comunicam por meio de um dispositivo de rede: cada rede virtual falada tem um emparelhamento para uma 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 em uma WAN virtual) ou por você.
• Um gateway de rede virtual é conectado à rede do hub e faz uso de rotas definidas pelo usuário: Permite a comunicação entre os raios.

Use o Gerenciador de Rede Virtual do Azure para criar topologias de rede virtual hub-and-spoke novas (e integradas existentes) 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 têm a necessidade de se conectar às diferentes regiões do Azure dos clientes. Mais especificamente, essa pergunta normalmente se resume a como conectar duas redes virtuais (uma das quais tem o Banco de Dados do Azure para PostgreSQL - Servidor Flexível 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 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 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 que são estabelecidos em um gateway VPN.
• Ligação rede-a-rede. Uma conexão entre redes virtuais (conexão rede-a-rede) é essencialmente uma VPN entre os dois locais do Azure. A conexão rede a rede é estabelecida em um 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 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, mas 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 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. 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 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-and-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 Banco de Dados do Azure para PostgreSQL - FQDN de Servidor Flexível 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 - Flexible Server Private DNS zone. Adicione um link de rede virtual à zona DNS Privada do seu Banco de Dados do Azure para servidor flexível 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 que um servidor flexível do Banco de Dados do Azure para PostgreSQL é implantado em uma rede virtual e sub-rede, você não pode movê-lo 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 na rede virtual 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 PostgreSQL - Rede de 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 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 em uma zona DNS privada ou em um conjunto de registros individuais pode interferir na capacidade do Banco de Dados do Azure para PostgreSQL - Servidor Flexível de atualizar registros DNS. 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, certifique-se de que 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 anfitrião

Independentemente da opção de rede escolhida, recomendamos que você sempre use um FQDN como o nome do host quando se conectar ao seu banco de dados do Azure para servidor flexível 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).

Conteúdos relacionados

• Portal do Azure
• CLI do Azure