|
On Feb 8, 2005, at 5:17 PM, Peter Mueller wrote:
The thread you referenced for issue #1 looks to be specific for DR. Am
I mistaken?
2) The big one. Our traffic spikes on the CSS hit 90mbit/s.
Not huge
by a lot of standards,
1) None of the real servers can load pages from virtualized
IPs. That
is, if a server is a real server (and thus has as its gateway the LVS
director), it can't get any services that the director
provides. This
is a pretty minor problem, one we can work around, but would rather
not. Any ide but still sizable. The CSS was pushing out
about 50mbit/s when we cut over to the LVS-NAT box, and traffic
immediately dropped to about 20mbit/s, never breaking 30.
How did you measure this? Did you notice anything unusual about the
traffic?
Was the service available during this period?
No, the traffic was normal as far as I could see. The service was
available but much slower during this period. Throughput was measured
with mrtg every 5 minutes and with "nload" constantly.
A test download from a box on another network, with a 100mbit
connection to the Internet, was able to download a single
file at well
over 40mbit/s through the CSS. Through the LVS, it peaked at 1Mbit/s
at the beginning and then quickly fell to about 300kbit/s after a few
seconds, and stayed there.
How did you download? Assuming http? What does testlvs show?
Yes, http (wget on a 15MB file). I haven't yet run testlvs, when I do
I'll post results. Later tonight.
I tested again using wget etc with just one real server, and was able
to get about 20mbit/s for the single connection. As I threw more
parallel connections at it they all slowed until the aggregate traffic
was in the 20-30mbit/s range. When going through the css to a single
server I'm able to more than double that for single or parallel
connections.
|
