Estou usando o LVS (ipvsadm) no modo NAT para balancear a carga do tráfego UDP para vários "servidores reais". Estou usando o agendamento de um pacote para que o tráfego originado de uma única porta de origem no cliente seja distribuído para diferentes servidores reais.
O que vejo, porém, é que os datagramas UDP, que se originam nos servidores reais e são enviados de volta ao cliente, têm seu ip/porta de origem configurado para o do servidor real, o que confunde o cliente, pois ele espera receber respostas com fonte ip/porta correspondente àquelas para as quais ele enviou o datagrama original.
Isso é realmente muito estranho, porque o LVS supostamente "esconde" os servidores reais atrás do ip/porta virtual.
Parece que se eu desligar o agendamento de um pacote, o ip/porta de origem dos datagramas de saídasãoreescrito corretamente pelo LVS.
Alguém já encontrou isso? Se sim, qual é a maneira de contornar isso?
Responder1
Se você ainda estiver interessado:
Acredito que o agendamento de um pacote não espera uma resposta do pacote que acabou de agendar e, portanto, não armazena informações de conexão. Então, quando a resposta volta, o LVS não consegue encontrar a conexão para ela e, portanto, não sabe qual IP/porta de origem usar.
Isso parece ser intencional. Pesquise aqui por "OPS é implementado para configurações onde não há resposta para o pacote original" e você verá algumas explicações.
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.UDP.html
A solução é definir um tempo limite de persistência para conexões UDP (você pode configurá-lo para um valor baixo se esperar respostas rápidas), definindo explicitamente um tempo de conexão. Como você pode fazer isso, não faz sentido que o OPS se lembre das conexões.