David,
Here's what might be happening to you:
- whenever a new TCP connect comes through the director, the LVS
code checks whether this (protocol, source ip, source port) tuple
has been scheduled, already.
- if the program doing the TCP connect binds to the same local
port and connects to the same Virtual IP and port (as rsh is wont
to do), you'll get a hit on (protocol, ip address, port), and find
the same old scheduling entry you did last time, and hence
go to the same tired, old realserver.
- if the program binds to different local ports each time, the
director won't find the (protocol, ip address, port) in its
list, and will schedule anew, moving on to the next server.
That's why consecutive rlogins to my director within the expiration
timeout go to the same realserver, and consecutive telnets to the
director go to different realservers.
It may be possible to force rescheduling when TCP connects come
through so consecutive rlogins to to different realservers.
John
On Jul 11, 12:35pm, David D.W. Downey wrote:
>
> [ Attachment (multipart/alternative): 34577 bytes ]
>-- End of excerpt from David D.W. Downey
|