Editar

Compartilhar via


Revisão do Azure Well-Architected Framework de um gateway da NAT do Azure

Gateway de Aplicativo do Azure
Rede Virtual do Azure
Link Privado do Azure

Este artigo descreve práticas recomendadas para um gateway da NAT do Azure. Estas diretrizes se baseiam nos cinco pilares de excelência para arquiteturas: Otimização de custos, Excelência operacional, Eficiência de desempenho, Confiabilidade e Segurança.

Como pré-requisito para esta orientação, você deve ter conhecimento prático do Gateway da NAT do Azure e entender seus respectivos recursos. Para obter mais informações, consulte a Documentação do Gateway da NAT do Azure.

Otimização de custo

Configure o acesso a soluções de plataforma como serviço (PaaS) por meio do Link Privado do Azure ou pontos de extremidade de serviço, incluindo armazenamento, para que você não precise usar um gateway da NAT. O Link Privado e os pontos de extremidade de serviço não exigem a travessia do gateway da NAT para acessar os serviços de PaaS. Essa abordagem reduz o custo por gigabyte (GB) de dados processados, em comparação com o custo de usar um gateway da NAT. O Link Privado e os pontos de extremidade de serviço também oferecem benefícios de segurança.

Eficiência de desempenho

Cada recurso de gateway da NAT fornece até 50 gigabits por segundo (Gbps) de taxa de transferência. Você pode dividir suas implantações em várias sub-redes e depois atribuir um gateway da NAT a cada sub-rede ou grupo de sub-redes para expansão.

Cada endereço IP público do gateway da NAT fornece 64.512 portas SNAT (Conversão de endereços de rede) de origem. Você pode atribuir até 16 endereços IP a um gateway da NAT, incluindo endereços IP públicos padrão individuais, o prefixo de IP público ou ambos. Para cada endereço IP de saída atribuído que vai para o mesmo ponto de extremidade de destino, o gateway da NAT pode oferecer suporte a até 50.000 fluxos simultâneos para TCP e UDP, respectivamente.

Esgotamento de SNAT

Considere as seguintes orientações para ajudar a prevenir o esgotamento de SNAT:

  • Os recursos de gateway da NAT têm um tempo limite ocioso de TCP padrão de quatro minutos. Você pode configurar o tempo limite para até 120 minutos. Se você alterar essa configuração para um valor maior que o padrão, o gateway da NAT manterá os fluxos por mais tempo, o que poderá causar uma pressão desnecessária no inventário de portas SNAT.

  • As solicitações atômicas (uma solicitação por conexão) limitam a escala, além de reduzir o desempenho e a confiabilidade. Em vez de solicitações atômicas, é possível reutilizar conexões HTTP ou HTTPS para reduzir o número de conexões e portas SNAT associadas. Ao reutilizar as conexões, você pode dimensionar melhor o aplicativo. O desempenho do aplicativo melhora devido a custos reduzidos de handshakes, sobrecarga e operação de criptografia quando você usa o TLS.

  • Se você não armazenar em cache os resultados do resolvedor de DNS, as pesquisas de DNS (Sistema de Nomes de Domínio) poderão introduzir muitos fluxos individuais no volume. Use o cache DNS para reduzir o volume de fluxos e reduzir o número de portas SNAT. DNS é o sistema de nomenclatura que mapeia nomes de domínio para endereços IP para recursos que estão conectados à Internet ou a uma rede privada.

  • Os fluxos UDP, como pesquisas de DNS, usam portas SNAT durante o tempo limite ocioso. O temporizador de tempo limite ocioso de UDP é fixado em quatro minutos.

  • Use pools de conexão para formatar o volume de conexão.

  • Para limpar os fluxos, não abandone silenciosamente os fluxos de TCP nem dependa de temporizadores de TCP. Se você não permitir que o TCP feche explicitamente uma conexão, a conexão TCP permanecerá aberta. Sistemas intermediários e pontos de extremidade manterão essa conexão em uso, o que torna a porta SNAT indisponível para outras conexões. Esse antipadrão pode disparar falhas de aplicativo e esgotamento de SNAT.

  • Não altere os valores de temporizador relacionados ao fechamento de TCP no nível do sistema operacional, a menos que você conheça as implicações. Se os pontos de extremidade de uma conexão tiverem incompatibilidade de expectativas, a pilha de TCP poderá ser recuperada, mas poderá afetar negativamente o desempenho do aplicativo. Normalmente, existe um problema de design subjacente caso você precise alterar os valores do temporizador. E se o aplicativo subjacente tiver outros antipadrões e você alterar os valores do temporizador, também poderá acelerar o esgotamento de SNAT.

Analise as seguintes diretrizes para melhorar a escala e a confiabilidade do seu serviço:

  • Considere os efeitos da redução do tempo limite ocioso de TCP para um valor mais baixo. Um tempo limite ocioso padrão de quatro minutos pode liberar, de forma preventiva, o inventário de portas de SNAT.

  • Considere os padrões de sondagem assíncrona nas operações de execução longa, a fim de liberar seus recursos de conexão para outras operações.

  • Considere usar keep alives TCP ou keep alives de camada de aplicativos para fluxos de TCP de vida longa, como conexões TCP reutilizadas, para evitar o tempo limite de sistemas intermediários. Você só deverá aumentar o tempo limite ocioso como um último recurso e isso pode não resolver a causa raiz. Um tempo limite longo pode causar falhas de baixa taxa quando o tempo limite expira. Também pode introduzir um atraso e falhas desnecessárias. É possível habilitar keep alives TCP de um lado de uma conexão para manter uma conexão ativa dos dois lados.

  • Considere o uso de keep alives UDP para fluxos UDP de longa duração a fim de evitar que sistemas intermediários atinjam o tempo limite. Quando você habilita keep alives UDP em um lado da conexão, apenas um lado da conexão permanece ativo. É necessário habilitar keep alives UDP nos dois lados de uma conexão para manter uma conexão ativa.

  • Considere padrões normais de repetição para evitar tentativas agressivas e intermitências durante uma falha transitória ou uma recuperação de falha. Quanto ao antipadrão conexões atômicas, você cria uma conexão TCP para cada operação HTTP. As conexões atômicas desperdiçam recursos e impedem que o aplicativo seja bem dimensionado.

    Para aumentar a velocidade de transação e diminuir os custos de recursos para o aplicativo, sempre inclua várias operações em um pipeline na mesma conexão. Quando o aplicativo usa criptografia de camada de transporte, por exemplo, TLS, o processamento de novas conexões aumenta o custo. Para conhecer mais padrões de práticas recomendadas, consulte Padrões de design de nuvem do Azure.

Excelência operacional

É possível usar um gateway da NAT com o Serviço de Kubernetes do Azure (AKS), mas o gerenciamento de gateway da NAT não está incluído no AKS. Se você atribuir um gateway da NAT à sub-rede CNI (Interface de Rede do Contêiner), habilitará os pods do AKS para sair pelo gateway da NAT.

Ao usar vários gateways da NAT entre zonas ou entre regiões, mantenha o estado IP de saída gerenciável usando prefixos IP públicos do Azure ou prefixos BYOIP. Não é possível atribuir um tamanho de prefixo de IP com mais do que 16 endereços IP (tamanho de prefixo /28) a um gateway da NAT.

Use alertas do Azure Monitor para monitorar e alertar sobre o uso de portas SNAT, pacotes processados ou descartados o volume de dados transmitidos. Use logs de fluxo NSG (grupo de segurança de rede) para monitorar o fluxo de tráfego de saída de instâncias de VM (máquina virtual) em uma sub-rede configurada de gateway da NAT.

Quando você configura uma sub-rede com um gateway da NAT, este substitui todas as outras conexões de saída para a Internet pública para todas as VMs nessa sub-rede. O gateway da NAT tem precedência sobre um balanceador de carga, independentemente das regras de saída. O gateway também tem precedência sobre endereços IP públicos atribuídos diretamente a VMs. O Azure controla a direção de um fluxo e impede o roteamento assimétrico. O tráfego originado de entrada, como um IP de front-end do balanceador de carga, é convertido corretamente e é convertido separadamente do tráfego originado de saída por meio de um gateway da NAT. Essa separação permite que os serviços de entrada e saída coexistam perfeitamente.

Recomendamos um gateway da NAT como padrão para habilitar a conectividade de saída para redes virtuais. Um gateway da NAT oferece eficiência e simplicidade operacional em comparação com outras técnicas de conectividade de saída no Azure. Os gateways da NAT alocam portas SNAT sob demanda e usam um algoritmo mais eficiente para evitar conflitos de reutilização de portas SNAT. Não confie no antipadrão conectividade de saída padrão para sua propriedade. Em vez disso, defina a configuração explicitamente com recursos de gateway da NAT.

Confiabilidade

Os recursos de gateway da NAT estão altamente disponíveis em uma zona de disponibilidade e abrangem vários domínios de falha. É possível implantar um gateway da NAT em uma sem zona na qual o Azure seleciona automaticamente uma zona para colocar o gateway da NAT ou o isola em uma zona de disponibilidade específica.

Para oferecer isolamento da zona de disponibilidade, cada sub-rede deve ter recursos apenas dentro de uma zona específica. Para implementar essa abordagem, é possível:

  • Implantar uma sub-rede para cada uma das zonas de disponibilidade em que as VMs estão implantadas.
  • Alinhar as VMs zonais com gateways da NAT zonais correspondentes.
  • Criar pilhas zonais separadas.

No diagrama a seguir, uma VP na zona de disponibilidade 1 está em uma sub-rede com outros recursos que também estão apenas na zona de disponibilidade 1. Um gateway da NAT é configurado na zona de disponibilidade 1 para atender a essa sub-rede.

Diagrama que demonstra o fluxo direcional de uma pilha zonal.

As redes virtuais e sub-redes abrangem todas as zonas de disponibilidade de uma região. Você não precisa dividi-las por zonas de disponibilidade para acomodar recursos zonais.

Segurança

Com o gateway da NAT, as VMs individuais ou outros recursos de computação não precisam de endereços IP públicos e podem permanecer totalmente privadas. Recursos sem um endereço IP público ainda podem alcançar fontes externas fora da rede virtual. É possível associar um prefixo de IP público para garantir que você use um conjunto contíguo de IPs para conectividade de saída. É possível configurar as regras de firewall de destino com base nessa lista de IP previsível.

Uma abordagem comum é projetar um cenário de NVA (dispositivo virtual de rede) somente de saída com firewalls que não sejam da Microsoft ou com servidores proxy. Quando você implanta um gateway da NAT em uma sub-rede com um conjunto de NVAs de escala de máquina virtual, esses NVAs usam um ou mais endereços de gateway da NAT para conectividade de saída em vez de um IP de um balanceador de carga ou os IPs individuais. Para empregar esse cenário com o Firewall do Azure, consulte Integrar o Firewall do Azure ao Azure Standard Load Balancer.

Diagrama que mostra firewalls com um sanduíche de balanceador de carga e gateway da NAT.

É possível usar o recurso de alerta do Microsoft Defender para Nuvem para monitorar qualquer conectividade de saída suspeita em um gateway da NAT.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas