Balanceamento de carga do Balanceador Público de Carga Padrão do Azure para uma VM não íntegra ou removida

Question

Temos um site altamente disponível que estamos tentando migrar para o Azure. Basicamente, temos um Balanceador de carga padrão do Azure com um IP público e duas VMs no pool de back-end.

Percebemos que, se uma das VMs falhar (o host falha ou algo como o Pool de Aplicativos falha), o balanceador de carga padrão detecta que o host não está íntegro, mas continua a enviar conexões existentes para o host.

Isso significa que os usuários finais que já possuem uma sessão na VM de back-end não íntegra continuam a ser enviados para ela e geralmente recebem um erro HTTP genérico. Os usuários que entram como novas conexões são enviados com sucesso para o host íntegro no pool de back-end.

Nosso balanceador de carga está configurado para não manter o estado, portanto, em teoria, novas conexões serão distribuídas aleatoriamente entre os hosts abaixo e com um tempo limite de sessão de 4 minutos (O Azure mais baixo nos permite ir).

Há algo que perdemos aqui ou esse é apenas o comportamento esperado dos balanceadores de carga do Azure?

    

Answer 1

É o comportamento esperado. O comportamento das sondas para baixo é como o fole:

New TCP connections will succeed to backend instance which is healthy and has a guest OS and application able to accept a new flow.

If a backend instance's health probe fails, established TCP connections to this backend instance continue.

If all probes for all instances in a backend pool fail, no new flows will be sent to the backend pool. Standard Load Balancer will permit established TCP flows to continue. Basic Load Balancer will terminate all existing TCP flows to the backend pool.

Because the flow is always between the client and the VM's guest OS, a pool with all probes down will cause a frontend to not respond to TCP connection open attempts as there is no healthy backend instance to receive the flow.

Referências: sondas de integridade do Load Balancer