Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O Balanceador de Carga do Azure dá suporte aos seguintes modos de distribuição para rotear conexões para instâncias no pool de back-end:
| Modo de distribuição | Baseado em hash | Persistência da sessão: IP do cliente | Persistência da sessão: IP do cliente e protocolo |
|---|---|---|---|
| Descrição geral | Tráfego do mesmo IP de cliente encaminhado para qualquer instância saudável no conjunto de back-end | O tráfego do mesmo IP do cliente é roteado para a mesma instância de back-end | O tráfego do mesmo IP e protocolo do cliente é roteado para a mesma instância de back-end |
| Tuplas | cinco-tupla | duas tuplas | tuplo de três elementos |
| Configuração do portal do Azure | Persistência de sessão: Nenhuma | Persistência da sessão: IP do cliente | Persistência da sessão: IP do cliente e protocolo |
| API REST | "loadDistribution":"Default" |
"loadDistribution":SourceIP |
"loadDistribution":SourceIPProtocol |
Não há tempo de inatividade ao alternar de um modo de distribuição para outro em um balanceador de carga.
Baseado em hash
O Balanceador de Carga do Azure utiliza, por predefinição, um modo de distribuição baseado num hash quíntuplo.
O quíntuplo é composto por:
- IP de origem
- Porta de origem
- IP de destino
- Porto de destino
- Tipo de protocolo
O hash é usado para rotear o tráfego para instâncias de back-end íntegras dentro do pool de back-end. O algoritmo garante persistência apenas no âmbito de uma sessão de transporte. Quando o cliente inicia uma nova sessão a partir do mesmo IP de origem, a porta de origem muda e faz com que o tráfego vá para uma instância de back-end diferente.
Para configurar a distribuição baseada em hash, você deve selecionar persistência de sessão como Nenhum no portal do Azure. Isso especifica que solicitações sucessivas do mesmo cliente podem ser tratadas por qualquer máquina virtual.
Nota
Quando há variação limitada nos endereços IP de origem e nas portas, o balanceador de carga pode não ter informação de fluxo distinta suficiente para distribuir o tráfego de forma uniforme entre os backends. Em cenários onde dispositivos intermédios (como firewalls que executam SNAT) reduzem o número de endereços IP de origem visíveis e atribuem portas de origem em padrões previsíveis, a variação disponível nos fluxos de tráfego pode ser significativamente limitada, especialmente quando o tráfego se origina de um pequeno número de clientes. Isto pode resultar numa distribuição muito desigual ou sem qualquer distribuição entre instâncias de back-end. Se verificar uma distribuição desigual, aumente o número de clientes que enviam tráfego através do dispositivo intermédio ou tente ajustar o número de instâncias do dispositivo intermédio ou de servidores de back-end do balanceador de carga para quebrar a simetria do hash.
Persistência da sessão
A persistência da sessão também é conhecida como afinidade de sessão, afinidade de IP de origem ou afinidade de IP de cliente. Este modo de distribuição utiliza um hash de 2 tuplos (IP de origem e IP de destino) ou de 3 tuplos (IP de origem, IP de destino e tipo de protocolo) para encaminhar para as instâncias de back-end. Ao usar a persistência de sessão, as ligações do mesmo cliente são encaminhadas para a mesma instância de back-end no pool de back-end.
O modo de persistência da sessão tem dois tipos de configuração:
IP do cliente (2 tuplas) - Especifica que solicitações sucessivas do mesmo endereço IP do cliente são tratadas pela mesma instância de back-end.
Endereço IP do cliente e protocolo (triplo) - Especifica que pedidos sucessivos da mesma combinação de endereço IP do cliente e protocolo são encaminhados para a mesma instância de backend.
A figura a seguir ilustra uma configuração de duas tuplas. Repare como a tupla de dois elementos passa pelo balanceador de carga até à máquina virtual 1 (VM1). O backup do VM1 é feito pelo VM2 e pelo VM3.
Casos de utilização
A afinidade do IP de origem com o IP do cliente e o protocolo (afinidade do IP de origem de três elementos) resolve uma incompatibilidade entre o Balanceador de Carga do Azure e o Gateway de Ambiente de Trabalho Remoto (RD Gateway).
Outro cenário de caso de uso é o upload de mídia. O carregamento de dados acontece através de UDP, mas o plano de controlo é conseguido através de TCP:
- Um cliente inicia uma sessão TCP para o endereço público com balanceamento de carga e é direcionado para um DIP específico. O canal é deixado ativo para monitorar a integridade da conexão.
- Uma nova sessão UDP do mesmo computador cliente é iniciada para o mesmo ponto final público com balanceamento de carga. A conexão é direcionada para o mesmo ponto de extremidade DIP que a conexão TCP anterior. O upload de mídia pode ser executado em alta taxa de transferência, mantendo um canal de controle através de TCP.
Nota
Quando os membros do pool de back-end do Balanceador de Carga são alterados removendo ou adicionando uma máquina virtual, a distribuição das solicitações do cliente é recalculada. Não pode contar com o facto de novas ligações de clientes existentes serem encaminhadas para o mesmo servidor. Além disso, usar o modo de distribuição de afinidade IP de origem pode causar uma distribuição desigual do tráfego. Os clientes que funcionam por trás de proxies podem ser vistos como uma única aplicação cliente.
Próximos passos
Para obter mais informações sobre como configurar o modo de distribuição do Balanceador de Carga do Azure, consulte Configurar o modo de distribuição para o Balanceador de Carga do Azure.