Meu entendimento da documentação do NGINX Plus é que seu balanceamento de carga irá rotear servidores que estão inativos ou sobrecarregados e que a Persistência de Sessão tenta manter o mesmo servidor para uma determinada sessão. Parece que os dois podem se tornar mutuamente exclusivos quando um servidor fica inativo no meio das sessões. Há uma indicação de falha do servidor, para que possamos saber que pode haver alguma perda de dados devido à mudança para outro servidor (que pode não ter ocorrido nas alterações na sessão) ou ele muda silenciosamente?
Isso é especificamente para comunicação TCP/UDP, não HTTP.
Responder1
Parece que os dois podem se tornar mutuamente exclusivos
Sim. Esse não é um problema específico do nginx. De longe, a melhor solução é ter os dados da sua sessão replicados/altamente disponíveis - mas isso não é fácil de implementar em um serviço existente que não tenha sido bem planejado.
O que você deseja que o nginx faça quando o servidor que implementa uma sessão falha? Failover para qualquer outro servidor? Failover para um servidor específico? Seus servidores estão em pares? algo mais? Interrompa a sessão - pois ela está em estado indeterminado....Existem tantas opções.
Quanto ao relato de falhas. Existem 2 partes para isso. Um deles é o monitoramento - alguém precisa ser informado de que algo está quebrado/precisa ser consertado. Este não é o trabalho do Nginx. Isso é para sua pilha de monitoramento lidar. A segunda parte é informar ao cliente que algo não funcionou. O Nginx não sabe que deveria colocar o estoque de volta nas prateleiras/reaplicar a alteração de DNS. Esse é o trabalho do protocolo que você está executando e do aplicativo. Embora existam problemas de tempo, a maioria dos protocolos de rede usa uma troca de mensagens curtas de solicitação/resposta para fornecer visibilidade do estado do servidor no cliente. No caso da (maioria) dos bancos de dados, isso é muito bem definido com uma mensagem "COMMIT" explícita do cliente. Mas considere o que acontece se o cliente disser “COMMIT” e não receber resposta?
Isso é especificamente para comunicação TCP/UDP, não HTTP.
Como @PersionGulf, recomendo usar HAProxy para balanceamento de carga não HTTP/HA de TCP sobre nginx. A última vez que verifiquei, não é possível fazer UDP.
Não indica como funciona em caso de falha
Não é difícil testar.