Alta disponibilidade e balanceamento de carga dos seus conectores e aplicativos de rede privada
Este artigo explica como a distribuição de tráfego funciona com a implantação do proxy de aplicativo. Saiba como o tráfego é distribuído entre usuários e conectores, juntamente com dicas para otimizar o desempenho do conector. Saiba como o tráfego flui entre conectores e servidores de aplicativos de back-end, com recomendações para balanceamento de carga entre vários servidores back-end.
Distribuição do tráfego entre os principais conectores
Os conectores estabelecem suas conexões com base nos princípios de alta disponibilidade. Não há nenhuma garantia de que o tráfego sempre seja distribuído uniformemente entre os conectores e não haja nenhuma afinidade de sessão. No entanto, o uso varia, e as solicitações são enviadas aleatoriamente para instâncias de serviço de proxy de aplicativo. Como resultado, o tráfego normalmente é distribuído quase igualmente entre os conectores. O diagrama e as etapas ilustram como as conexões são estabelecidas entre usuários e conectores.
- Um usuário em um dispositivo cliente tenta acessar um aplicativo local publicado por meio do proxy de aplicativo.
- A solicitação passa por um Azure Load Balancer para determinar qual instância de serviço de proxy de aplicativo deve executar a solicitação. Há dezenas de instâncias disponíveis para aceitar as solicitações de todo o tráfego na região. Esse método ajuda a distribuir uniformemente o tráfego entre as instâncias de serviço.
- A solicitação é enviada ao Barramento de Serviço.
- O Barramento de Serviço envia sinais a um conector disponível. Em seguida, o conector pega a solicitação do Barramento de Serviço.
- Na etapa 2, as solicitações vão para diferentes instâncias de serviço de proxy de aplicativo, portanto, é mais provável que as conexões sejam feitas com conectores diferentes. Como resultado, os conectores são quase usados de maneira uniforme dentro do grupo.
- O conector passa a solicitação para o servidor de back-end do aplicativo. Em seguida, o aplicativo envia a resposta de volta para o conector.
- O conector conclui a resposta abrindo uma conexão de saída para a instância de serviço de onde a solicitação veio. Em seguida, essa conexão é fechada imediatamente. Por padrão, cada conector é limitado a 200 conexões de saída simultâneas.
- Em seguida, a resposta é passada de volta para o cliente da instância de serviço.
- As solicitações subsequentes da mesma conexão repetem as etapas.
Um aplicativo geralmente tem muitos recursos e abre várias conexões quando ele está sob carga. Cada conexão passa pelas etapas para ser alocada a uma instância de serviço. Se a conexão não estiver emparelhada com um conector, selecione um novo conector disponível.
Práticas recomendadas para alta disponibilidade de conectores
Devido à maneira como o tráfego é distribuído entre conectores para alta disponibilidade, é essencial sempre ter pelo menos dois conectores em um grupo de conectores. Três conectores é a quantidade recomendada para fornecer um buffer adicional entre conectores. Para determinar o número correto de conectores necessários, siga a documentação de planejamento de capacidade.
Coloque os conectores em conexões de saída diferentes para evitar um único ponto de falha. Se os conectores usarem a mesma conexão de saída, um problema de rede com a conexão afetará todos os conectores que a usarem.
Evite forçar a reinicialização dos conectores quando estiverem conectados a aplicativos de produção. Isso pode afetar negativamente a distribuição do tráfego entre conectores. A reinicialização de conectores faz com que mais conectores não estejam disponíveis e força conexões com o conector restante disponível. O resultado é um uso desigual dos conectores inicialmente.
Evite todas as formas de inspeção embutida em comunicações TLS de saída entre conectores e o Azure. Esse tipo de inspeção embutida causa degradação no fluxo de comunicação.
Mantenha as atualizações automáticas em execução para seus conectores. Desde que o serviço Atualizador do conector de rede privada esteja em execução, os conectores serão atualizados automaticamente. Caso você não veja o serviço Atualizador do Conector no servidor, precisará reinstalar o conector para obter todas as atualizações.
Fluxo de tráfego entre conectores e servidores de aplicativos de back-end
Outra área principal em que a alta disponibilidade é um fator é a conexão entre os conectores e os servidores back-end. Quando um aplicativo é publicado por meio do Proxy de Aplicativo do Microsoft Entra, o tráfego dos usuários para os aplicativos flui por meio de três conexões:
- O usuário se conecta ao ponto de extremidade público do serviço de proxy de aplicativo do Microsoft Entra no Azure. A conexão é estabelecida entre o endereço IP do cliente de origem (público) do cliente e o endereço IP do ponto de extremidade do proxy de aplicativo.
- O conector de rede privada efetua pull da solicitação HTTP do cliente do serviço de proxy de aplicativo.
- O conector de rede privada se conecta ao aplicativo de destino. O conector usa seu próprio endereço IP para estabelecer a conexão.
Considerações de campo de cabeçalho X-Forwarded-For
Em algumas situações (como auditoria, balanceamento de carga e assim por diante), compartilhar o endereço IP de origem do cliente externo com o ambiente local é um requisito. Para atender ao requisito, o conector de rede privada do Microsoft Entra adiciona o campo de cabeçalho X-Forwarded-For com o endereço IP do cliente de origem (público) à solicitação HTTP. O dispositivo de rede apropriado (balanceador de carga, firewall) ou o servidor Web, ou o aplicativo de back-end pode ler e usar as informações.
Práticas recomendadas para balanceamento de carga entre vários servidores de aplicativo
O balanceamento de carga é importante quando o grupo de conectores atribuído ao aplicativo do proxy de aplicativo tem dois ou mais conectores. O balanceamento de carga também é importante quando você executa o aplicativo Web de back-end em vários servidores.
Cenário 1: o aplicativo de back-end não requer persistência de sessão
O cenário mais simples é o que aplicativo Web de back-end não exige a adesão da sessão (persistência da sessão). Uma instância de aplicativo de back-end lida com solicitações de usuário no farm de servidores. Você pode usar um balanceador de carga de camada 4 e configurá-lo sem afinidade. Algumas opções incluem o balanceamento de carga de rede da Microsoft e o Azure Load Balancer ou um balanceador de carga de outro fornecedor. Como alternativa, configure uma estratégia de DNS (Sistema de Nomes de Domínio) round-robin.
Cenário 2: o aplicativo de back-end não requer persistência de sessão
Nesse cenário, o aplicativo Web de back-end requer a adesão da sessão (persistência da sessão) durante a sessão autenticada. A instância de aplicativo de back-end lida com solicitações de usuário. As solicitações são executadas no mesmo servidor no farm de servidores. Esse cenário pode ser mais complicado porque o cliente geralmente estabelece várias conexões com o serviço de proxy de aplicativo. Solicitações em diferentes conexões podem chegar em diferentes conectores e servidores no farm. Como cada conector usa seu próprio endereço IP para essa comunicação, o balanceador de carga não pode garantir a adesão da sessão com base no endereço IP dos conectores. A afinidade de IP de origem não pode ser usada. Aqui estão algumas opções para o cenário 2:
Opção 1: basear a persistência da sessão em um cookie de sessão definido pelo balanceador de carga. Essa opção é recomendada porque permite que a carga seja distribuída mais uniformemente entre os servidores back-end. Ele requer um balanceador de carga de camada 7 com esse recurso e que pode manipular o tráfego HTTP e encerrar a conexão TLS. Você pode usar o Gateway de Aplicativo Azure (afinidade de sessão) ou um balanceador de carga de outro fornecedor.
Opção 2: basear a persistência da sessão no campo de cabeçalho X-Forwarded-For. Essa opção requer um balanceador de carga de camada 7 com esse recurso e que pode manipular o tráfego HTTP e encerrar a conexão TLS.
Opção 3: Configure o aplicativo de back-end para não exigir persistência de sessão.
Para entender os requisitos de balanceamento de carga do aplicativo de back-end, consulte a documentação do fornecedor de software.