Azure Load Balancer: distribuição na camada 4, investigações de integridade, NAT e escolha da solução
Entenda balanceadores públicos e internos, distribuição por cinco tuplas, persistência de sessão, investigações de integridade, portas HA, NAT de entrada, regras explícitas de saída e quando outro serviço de tráfego do Azure é mais adequado.
Tempo de estudo sugerido: 60 minutos • Nível intermediário • Reescrita autoral baseada no módulo fornecido do Microsoft Learn e corrigida pela documentação vigente do Azure Load Balancer
Por João Ricardo Dutra••Conteúdo autoral completo
1. Substitua dispositivos físicos de camada 4 por um serviço nativo do
A Adatum está migrando aplicações comerciais de três camadas dos datacenters locais para máquinas virtuais do distribuídas entre redes virtuais. Algumas aplicações devem atender a internet pública; outras precisam ficar disponíveis apenas para o escritório da empresa em Sydney. Os antigos dispositivos físicos balanceavam as camadas Web e de processamento, deixavam de enviar trabalho novo a servidores com falha, mantinham cada sessão em um servidor e encaminhavam conexões administrativas para VMs específicas.
O reproduz essas funções na camada de transporte para VMs do e . Este capítulo aborda arquitetura, algoritmo de decisão, investigações, recursos , saída e a fronteira entre o e outros serviços de tráfego do .
Explicar o que o faz e como contribui para a disponibilidade.
Acompanhar uma conexão pelo front-end, regra, investigação e pool de back-end.
Escolher implantação pública ou interna e o modo de distribuição adequado.
Diferenciar regras de balanceamento, de entrada, portas HA e saída.
Decidir se o ou outro serviço do atende à carga de trabalho.
O pré-requisito formal é compreender fundamentos de ,,, portas, redes virtuais e máquinas virtuais.
O projeto reúne uma decisão de tráfego, uma decisão de integridade e um plano explícito de conectividade.
2. O balanceamento escala horizontalmente em vez de apenas ampliar um servidor
Até um servidor potente pode se tornar gargalo quando as requisições aumentam. O balanceamento distribui o trabalho de entrada por vários computadores, evitando que uma instância absorva toda a demanda. Um conjunto de máquinas menores pode oferecer mais vazão, resiliência e flexibilidade de manutenção que uma única máquina superdimensionada.
O distribui fluxos de rede entre VMs ou instâncias de um Conjunto de Dimensionamento de . As regras indicam destinos elegíveis; as investigações impedem que novos fluxos cheguem a pontos não íntegros. Instâncias redundantes ampliam capacidade e disponibilidade.
3. O distribui fluxos regionais na camada 4
O atua na camada de transporte do modelo OSI. Ele decide com base em endereços, portas e protocolo ou , não em , cabeçalhos, ou conteúdo da aplicação. O processamento ocorre por fluxo; o serviço não é um reverso e não armazena dados da aplicação.
O que a camada 4 consegue ou não avaliar.
Consegue avaliar
Não consegue avaliar
Endereços de origem e destino
Caminho de como /imagens ou /
Portas de origem e destino
Host ou cabeçalho
Protocolo ou
, identidade ou conteúdo da aplicação
Estado do fluxo e de persistência
Regras de firewall de aplicativo Web
Use o serviço quando baixa latência, alta vazão e transporte transparente de ou forem mais importantes que inspeção de camada 7.
4. Balanceadores públicos e internos expõem front-ends diferentes
O front-end define o modelo de acesso.
Tipo
Front-end
Uso típico
público
Endereço público
Receber internet para uma camada Web e, com saída explícita, traduzir endereços privados do back-end.
interno
Endereço privado
Distribuir tráfego privado na rede virtual ou vindo do ambiente local por ou .
O front-end interno nunca é exposto diretamente como ponto de extremidade da internet. Ele atende tráfego dentro da rede virtual, acesso híbrido, distribuição da camada Web pública para processamento privado e aplicações LOB. Os dois tipos suportam grande quantidade de fluxos e .
Use front-end público para entrada da internet e privado para tráfego ou híbrido.
5. Sete componentes cooperam no caminho dos dados
Componentes centrais do .
Componente
Responsabilidade
Configuração de front-end
Endereço público ou privado usado pelos clientes.
Regra de balanceamento
Mapeia , porta e protocolo front-end para pool e porta de back-end.
Pool de back-end
VMs ou instâncias do conjunto aptas a receber fluxos.
Investigação de integridade
Define quais pontos podem receber novos fluxos.
Persistência de sessão
Seleciona distribuição por cinco, duas ou três tuplas.
Portas HA ou regra de entrada
Balanceia todas as portas de NVAs internas ou encaminha uma porta a uma instância.
Regra de saída
Define explícita para membros do pool de um Standard público.
Um endereço front-end isolado não basta. A regra referencia pool e investigação; os controles de segurança precisam permitir clientes e investigação; e a saída deve ser desenhada separadamente.
6. O front-end é o ponto de contato dos clientes
O cliente se conecta a uma configuração de front-end. O front-end público mapeia e porta acessíveis pela internet para endereços privados do back-end e devolve a resposta pela tupla pública. O interno usa um endereço privado acessível apenas pela rede conectada.
Um aceita vários IPs front-end, cada qual com suas regras. Assim, um serviço compartilhado pode publicar diversos endereços ou aplicações sem deixar de operar na camada 4.
7. O pool de back-end é o conjunto escalável de instâncias elegíveis
O pool reúne VMs ou instâncias de um Conjunto de Dimensionamento de . A associação pode usar interfaces de rede ou endereços ; VMs atrás de um público não precisam de público individual. O serviço atual admite vários pools, embora cada regra aponte para um deles.
Ao adicionar ou remover instâncias, o se reconfigura automaticamente e reaplica as regras ao novo conjunto. Os recursos de uma regra permanecem em uma única rede virtual; a regra não atravessa duas redes virtuais.
8. A regra conecta front-end, back-end, protocolo e investigação
Uma regra de entrada mapeia uma combinação de e porta front-end para um pool e uma porta de back-end em ou . Por exemplo, 80 público pode chegar ao 80 de cada servidor Web íntegro; outro front-end ou porta pode usar outra regra e outro pool.
Regras de balanceamento distribuem fluxos de entrada e não equivalem a regras de saída. É possível publicar várias portas, vários endereços front-end ou ambos.
A regra é o contrato entre a tupla front-end e o pool íntegro.
9. O algoritmo padrão calcula um de cinco tuplas por fluxo
Por padrão, o usa e porta de origem, e porta de destino e protocolo. O escolhe um back-end íntegro. Pacotes da mesma sessão de transporte conservam a tupla e chegam à mesma instância; uma conexão posterior pode mudar a porta de origem e alcançar outra VM.
de origem: endereço do cliente solicitante.
Porta de origem: porta usada pelo fluxo do cliente.
de destino: endereço front-end contatado.
Porta de destino: porta do serviço no front-end.
Protocolo: ou .
O algoritmo não é necessariamente round-robin. Se muitos clientes aparecem atrás da mesma e oferecem pouca variação nas tuplas, a distribuição pode ficar desigual.
A persistência padrão dura o fluxo de transporte, não todas as futuras requisições do cliente.
10. A persistência de sessão troca uniformidade por afinidade
Modos de distribuição da regra.
Opção no portal
Entradas do
Efeito
Nenhuma (padrão)
Cinco tuplas
Nova conexão do mesmo cliente pode ir a qualquer back-end íntegro.
do cliente
de origem + de destino
Fluxos sucessivos do mesmo permanecem na mesma instância.
do cliente e protocolo
de origem + de destino + protocolo
Afinidade separada para e .
Persistência também é chamada afinidade de sessão, de de origem ou de do cliente. Ela ajuda quando o estado não circula entre servidores, mas pode concentrar tráfego quando muitos usuários compartilham ou . Prefira aplicações sem estado quando possível.
Use apenas a afinidade realmente exigida pela aplicação.
11. Investigações de integridade retiram instâncias da seleção de novos fluxos
A investigação testa periodicamente uma porta do back-end. Seu resultado define as instâncias que podem receber novos fluxos de entrada. Ao atingir o limite não íntegro, o deixa de atribuir conexões novas ao ponto; a conectividade de saída não é afetada.
Investigações no Standard .
Tipo
Resultado íntegro
Exemplos de falha
O ouvinte conclui o .
Tempo limite, ausência de ouvinte ou reset.
O caminho configurado responde 200 no prazo.
Status diferente de 200, tempo limite ou reset.
Como , com e cadeia assinada no mínimo com .
Falha ,, de prazo ou conexão.
Configure protocolo, porta, intervalo, caminho (S) e limite de sucessos/falhas consecutivos. Os padrões atuais do portal e das podem divergir; verifique a implantação em vez de memorizar valores antigos do export. Permita 168.63.129.16 ou a marca de serviço AzureLoadBalancer nos e firewalls convidados.
A investigação testa a disponibilidade da aplicação, não apenas a existência da VM.
12. Conexões existentes e todas as investigações inoperantes exigem atenção
Quando um back-end Standard falha, conexões estabelecidas continuam até a aplicação encerrar, expirar a ociosidade ou a VM parar; conexões novas usam instâncias íntegras. Fluxos existentes podem migrar a outro ponto íntegro.
Se todas as investigações do Standard falharem, o pool não recebe fluxos novos, mas já estabelecido pode continuar quando há mais de uma instância. Essa diferença importa em manutenção e diagnóstico.
13. Portas HA balanceiam todas as portas de NVAs internas
Uma regra de portas HA usa protocolo Todos e porta front-end 0 para abranger todas as portas e em um Standard interno. A decisão por cinco tuplas serve a firewalls, VPNs, SD-WAN e outras NVAs altamente disponíveis que processam muitas portas.
Portas HA não substituem regras Web específicas e não têm suporte em públicos. Elas evitam criar milhares de regras individuais para a camada de dispositivos internos.
14. de entrada encaminha uma porta para uma instância específica
Uma regra de entrada encaminha um e porta front-end para uma VM e porta de back-end determinadas. 50001 público pode, por exemplo, mapear para 3389 em uma VM Windows, enquanto outra porta alcança outra VM. Assim, administra-se cada instância sem público individual.
Isso difere do balanceamento: escolhe deliberadamente uma instância em vez de distribuir pelo pool. Restrinja a origem, prefira ou gerenciamento privado e não trate como política de autorização.
15. Regras de saída definem explícita para o back-end
A regra de saída de um Standard público traduz endereços privados dos membros do pool para um ou mais IPs públicos front-end. Ela controla pool e front-end, e/ou , alocação de portas , tempo de ociosidade e reset opcional.
Saída é um projeto separado do balanceamento de entrada. O acesso de saída padrão foi aposentado para novas VMs, e o Basic foi desativado em 30 de setembro de 2025. Use regras de saída do Standard, do ou público por instância. O costuma ser preferível para saída previsível e escalável da sub-rede e menor risco de esgotamento .
Portas HA, de entrada e saída resolvem direções e escolhas diferentes.
16. O projeto da Adatum usa dois balanceadores para duas camadas
Na aplicação migrada, coloque um Standard público diante das VMs Web. A investigação retira nós falhos e a afinidade só deve ser usada se a aplicação precisar. Entre a camada Web e a de análise ou transformação, use um Standard interno para manter as VMs secundárias privadas.
de entrada pode oferecer administração específica controlada, mas ou acesso privado são mais seguros que RDP aberto. Saída explícita, , zonas de disponibilidade, monitoramento e pelo menos duas instâncias íntegras completam o projeto de produção.
Escolha por camada, alcance, protocolo, aceleração e segurança da aplicação.
17. Use o para fluxos ou de alto desempenho
Substituir um dispositivo físico de camada 4 por distribuição gerenciada.
Expor uma camada redundante de VMs ou conjunto de dimensionamento.
Balancear tráfego privado entre camadas ou vindo de uma rede híbrida.
Interromper novos fluxos para aplicações com falha por meio de investigações.
Preservar afinidade quando um cliente precisa permanecer em um back-end.
Usar portas HA para NVAs internas com muitas portas ou .
Encaminhar uma porta a uma instância com de entrada controlada.
Definir saída explícita quando o Standard público for o método escolhido.
18. Não adicione o quando não há necessidade de distribuição
Uma aplicação de baixo tráfego que funciona bem em uma VM ganha pouco com pool e regras, salvo quando disponibilidade ou crescimento justificam redundância. O também é inadequado quando a decisão exige conteúdo , término ,, caminhos de , aceleração global ou seleção por .
O serviço não é firewall, de aplicação, diretor de nem regra universal entre VNets. Comece pelo requisito arquitetural, não pelo nome do produto.
19. Escolha o serviço de tráfego pela camada e pelo alcance
Comparação dos serviços citados no módulo.
Serviço
Alcance e camada
Quando escolher
Regional, camada 4; e
Distribuição de baixa latência para VMs, camadas privadas ou NVAs.
regional de camada 7
Roteamento (S), término , decisão por host/caminho ou .
Rede global de entrega de aplicações, camada 7
Aceleração Web global, borda, , rápido e opcional.
Traffic Manager
Direcionamento global baseado em
Seleção entre pontos regionais aceitando do resolvedor e .
Os serviços podem ser combinados: escolhe uma região íntegra, enquanto ou distribui dentro dela.
20. Respostas da avaliação e prioridades de diagnóstico
Respostas corretas.
Pergunta
Resposta
Motivo
Em qual camada OSI o atua?
Camada 4
Ele avalia endereços, portas e ou .
O que mantém um cliente no mesmo back-end?
Persistência de sessão
A afinidade de duas ou três tuplas seleciona consistentemente a instância.
O que interrompe novos fluxos 443 para um back-end sem resposta?
Investigação de integridade
Ela marca o ponto como não íntegro e o remove de novos fluxos.
Ordem de diagnóstico
Confirme a ligação entre front-end, protocolo/portas da regra, pool e investigação.
Verifique se ao menos um back-end escuta a porta e devolve 200 quando necessário.
Permita AzureLoadBalancer e 168.63.129.16 nos e firewalls locais.
Confirme que o permite o cliente e que a aplicação escuta a porta de back-end.
Inspecione status, métricas, , ociosidade, reset e modo de distribuição.
Para falha de saída, verifique método explícito e portas , não a regra de entrada.
Para tráfego desigual, revise persistência e variedade das tuplas de origem.
21. Revisão compacta, recordação ativa e recursos oficiais
Versão resumida de todos os temas.
Tema
Memorize
Finalidade
Distribuir fluxos ou entre VMs ou instâncias íntegras.
