|
"Palmer J.D.F." wrote:
>
> Hi,
>
> I finally managed to get time enough to spend getting my LVS cluster
> working, finally.
>
> Well it works fine with http, but not with squid.
> What I mean by this is I get network unreachable back from the squid boxes
> (on the squid generated errors), the actual load balancing works okay.
I looked at the output of the rc.lvs script and it did what I told it
to do. Because you have iproute2 tools installed, the script
deleted the entries from the route table and reinstalled them with
ip. The route entries you now have are output on the screen when you
run the script (towards the end). You can check them yourself by
doing
#ip rule show
(gives table)
#ip route list table VIP
for you the output says (paraphrased)
"all packets with src_addr=VIP which come through eth0 are sent to default gw"
#ip route list table RIP
for you the output says
"all packets with src_addr=RIP (which aren't anything to do with the LVS) are
sent to the DIP". I do this for security, since the RIP is usually a
non-routeable
address, and anyhow packets coming from the RIP in a VS-DR are just network
housekeeping
packets. I want to make sure that anyone who breaks into the realserver, can't
route packets back to the internet, since they'll be sending packets with
src_addr=RIP.
note: you can't use the route command anymore, because it doesn't read the
tables setup by ip (route will give output, but most of the routes it sees have
been deleted).
There is no longer any default gw and there isn't supposed to be - all packets
are accounted for - any other packets aren't supposed to be there and
I don't have a default gw.
You say the LVS works for http. I assume you have http realservers and clients
can connect with the realservers in rotation etc (true?). If the http LVS is
working it's because the packets with src_addr=VIP dst_addr=CIP coming
from the realserver are being sent to the default gw (x.x.x.254) and
then back to the client.
If this is true, then I have to think why the squids aren't working.
It's been a while since I thought about how squids work - you're
going to have to fill me in here. I assume you're having people
send their http requests to the VIP and this isn't a straight through
LVS/squid (where the clients don't know that the squid is in the packet path).
On receiving the forwarded request from the director, the squid realserver
sends a query to the webserver out on internetland (packet has
src_addr=VIP, dst_addr=0.0.0.0), receives a reply (presumably a packet
with dst_addr=RIP) and then sends a packet on to the client (which I presume
will have a src_addr=RIP). Is this true?
If so, then the reply from the realserver (src_addr=RIP, dst_addr=CIP)
is sent to the DIP, where it can't get to the client.
If this is the case then I've outsmarted myself and I don't have a general
solution (at least right off the bat).
As far as you're concerned, you can use the solution you have now.
In the meantime, can you let me know whether my thinking above is correct
so I can think of a better solution?
Thanks Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
