Alta disponibilidade e balanceamento de carga de 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 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.
- 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.
- O Barramento de Serviço sinaliza para um conector disponível. Em seguida, o conector recolhe 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 origem da solicitação. 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 para o(s) conector(es) disponível(eis) restante(s). 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 aplicações 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.
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 aplicação backend lida com solicitações de usuário na fazenda 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 circular de DNS (Sistema de Nomes de Domínio).
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 na 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. Pedidos em diferentes conexões podem chegar a diferentes conectores e servidores na 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.