|
> *Should* be ran, yes, I agree. However I did run in to a situation
> where this did happen, which is far from the fault of lvs its self,
> but it is reasoning for why I want to find a new solution.
I don't know your situation, but I expect fixing the
original problem will be simpler. You shouldn't be trying to
run LVS on a machine in an invalid state.
I do agree with you, and this problem has been fixed. However, this
is a point of failure, which I am trying to address.
>> rr helps here. Still the thundering herd problem has to be
>> handled in user space (until someone writes a fix).
>
> Implementing LVS in this environment was to get around using DNS based
> Round Robin, so this would be counter productive.
the problem with DNS based load balancing is the long time
scale of DNS, not the round robin part.
The round robin part is the problem in my situation.
For example. Say you have 1000 people connected via telnet (those
connections could be from terminals, wireless scanners etc..) across
10 servers. Thats 100 users per server when it is weighted. If you
were using rr, if one server dies then the rest of the servers will
pick up 10 extra users each. When the dead server is restored, you
will have 9 servers with over a hundred users and 1 server with hardly
any connections. That is a poor utilization of resources and could
take a day to recover.
> Traffic does go to the realservers, but the DST is that of the VIP.
> There has to be modifications to the realserver in order for it to
> accept that traffic.
you have one realserver, or many? If one, just let it have
the VIP. If many, do you want all of them to have the VIP?
Just curious ... why would one use LVS if they only had one real
server? But I am dealing with many several directors and several
reals, large scale.
| 