Alta disponibilidade e balanceamento de carga de seus conectores e aplicativos de rede privada

Artigo
02/27/2024

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 back-end, com recomendações para balanceamento de carga entre vários servidores back-end.

Distribuição de tráfego entre conectores

Os conectores estabelecem suas conexões com base em princípios de alta disponibilidade. Não há garantia de que o tráfego seja distribuído uniformemente entre os conectores e não há 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 uniformemente entre os conectores. O diagrama e as etapas ilustram como as conexões são estabelecidas entre usuários e conectores.

Diagrama mostrando conexões entre usuários e conectores

Um usuário em um dispositivo cliente tenta acessar um aplicativo local publicado por meio do proxy do aplicativo.
A solicitação passa por um Balanceador de Carga do Azure para determinar qual instância de serviço de proxy de aplicativo deve receber a solicitação. Há dezenas de instâncias disponíveis para aceitar as solicitações para todo o tráfego na região. Esse método ajuda a distribuir uniformemente o tráfego entre as instâncias de serviço.
O pedido é enviado para o Service Bus.
Sinais do Barramento de Serviço para um conector disponível. Em seguida, o conector pega a solicitação do Service Bus.
- Na etapa 2, as solicitações vão para instâncias de serviço de proxy de aplicativo diferentes, portanto, é mais provável que as conexões sejam feitas com conectores diferentes. Como resultado, os conectores são usados quase uniformemente dentro do grupo.
O conector passa a solicitação para o servidor 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 com a instância de serviço de onde a solicitação veio. Em seguida, esta conexão é imediatamente fechada. Por padrão, cada conector é limitado a 200 conexões de saída simultâneas.
A resposta é então passada de volta para o cliente a partir da instância de serviço.
Solicitações subsequentes da mesma conexão repetem as etapas.

Um aplicativo geralmente tem muitos recursos e abre várias conexões quando 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 à forma como o tráfego é distribuído entre conectores para alta disponibilidade, é essencial ter sempre pelo menos dois conectores em um grupo de conectores. Três conectores são preferidos para fornecer buffer extra entre os conectores. Para determinar o número correto de conectores necessários, siga a documentação de planejamento de capacidade.
Coloque conectores em diferentes conexões de saída 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 usam.
Evite forçar a reinicialização dos conectores quando conectados a aplicativos de produção. Isso poderia afetar negativamente a distribuição do tráfego entre os conectores. A reinicialização dos conectores faz com que mais conectores fiquem indisponíveis e força as conexões com o conector disponível restante. O resultado é um uso desigual dos conectores inicialmente.
Evite todas as formas de inspeção em linha nas comunicações TLS (Transport Layer Security) de saída entre conectores e o Azure. Este tipo de inspeção em linha causa degradação do fluxo de comunicação.
Certifique-se de manter as atualizações automáticas em execução para seus conectores. Se o serviço Atualizador do conector de rede privada estiver em execução, os conectores serão atualizados automaticamente e receberão a atualização mais recente. Se não vir o serviço Connector Updater no servidor, terá de reinstalar o conector para obter quaisquer atualizações.

Fluxo de tráfego entre conectores e servidores de aplicativos back-end

Outra área importante onde a alta disponibilidade é um fator é a conexão entre conectores e os servidores back-end. Quando um aplicativo é publicado por meio do proxy de aplicativo Microsoft Entra, o tráfego dos usuários para os aplicativos flui através de três saltos:

O usuário se conecta ao ponto de extremidade público do serviço de proxy de aplicativo 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 do aplicativo.
O conector de rede privada extrai a 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.

Diagrama de usuário conectando-se a um aplicativo via proxy de aplicativo

Considerações sobre o 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 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 aplicativo back-end pode ler e usar as informações.

Práticas recomendadas para balanceamento de carga entre vários servidores de aplicativos

O balanceamento de carga é importante quando o grupo de conectores atribuído ao aplicativo proxy de aplicativo tem dois ou mais conectores. O balanceamento de carga também é importante quando você está executando o aplicativo Web back-end em vários servidores.

Cenário 1: O aplicativo back-end não requer persistência de sessão

O cenário mais simples é quando o aplicativo Web back-end não requer aderência de sessão (persistência de sessão). Uma instância de aplicativo 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 Balanceador de Carga do Azure 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 back-end requer persistência de sessão

Nesse cenário, o aplicativo Web back-end requer aderência de sessão (persistência de sessão) durante a sessão autenticada. A instância do aplicativo back-end lida com as solicitações do 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 conexões diferentes podem chegar a conectores e servidores diferentes 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 aderência da sessão com base no endereço IP dos conectores. O Source IP Affinity também não pode ser usado. Aqui estão algumas opções para o cenário 2:

Opção 1: Baseie 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 de forma mais uniforme entre os servidores back-end. Ele requer um balanceador de carga de camada 7 com esse recurso e que pode lidar com o tráfego HTTP e encerrar a conexão TLS. Você pode usar o Gateway de Aplicativo do Azure (Afinidade de Sessão) ou um balanceador de carga de outro fornecedor.
Opção 2: Baseie a persistência da sessão no campo de cabeçalho X-Forwarded-For. Esta opção requer um balanceador de carga de camada 7 com esse recurso e que possa lidar com o tráfego HTTP e encerrar a conexão TLS.
Opção 3: Configure o aplicativo back-end para não exigir persistência de sessão.

Para entender os requisitos de balanceamento de carga do aplicativo back-end, consulte a documentação do fornecedor do software.

Partilhar via