|
Okay,
After lots of time spent trying to narrow this down to a root cause I've hit
a wall. I've included these previous posts for reference. Here's the
phenomenon I'm seeing:
I have two LD's in HA configuration using heartbeatd. On either one of them
my ipvs configuration is working fine to load balance two webservers behind
them using LVS-NAT. My problem is that when I try to cause a failover by
either killing heartbeatd on one or shutting one down (simulating failure) I
get very strange results. After the failover happens and heartbeatd brings
up the shared resources I see some http connections going through fine while
some show up in ipvsadm as:
IPVS connection entries
pro expire state source virtual destination
TCP 00:25.52 SYN_RECV 10.10.9.63:2897 10.10.21.68:80 10.200.200.1:80
TCP 00:45.92 SYN_RECV 10.10.9.63:2898 10.10.21.68:80 10.200.200.1:80
TCP 00:42.92 SYN_RECV 10.10.9.63:2900 10.10.21.68:80 10.200.200.1:80
TCP 00:51.92 SYN_RECV 10.10.9.63:2902 10.10.21.68:80 10.200.200.1:80
TCP 00:08.92 SYN_RECV 10.10.9.63:2891 10.10.21.68:80 10.200.200.1:80
TCP 00:52.72 SYN_RECV 10.10.9.63:2895 10.10.21.68:80 10.200.200.1:80
TCP 00:30.72 SYN_RECV 10.10.9.63:2894 10.10.21.68:80 10.200.200.1:80
Now, I've verified that after failover the client is getting the correct arp
and IP address for the new VIP. After the failover I'd say 1 in 50 http
attempts works...the rest end up in this SYN_RECV state.
So my questions are:
What does a SYN_RECV mean?
What might it indicated is the problem?
Does this sound like anything anyone else out there has run into?
I've pretty much ruled out arp caching on the client and RS side as the
problem by manually checking them all...could it be arp problems at some
other level?
Needless to say, I'm beginning to lose faith in ipvs as a solution at this
point. I've read all the docs, I've followed advice from this list and
searched the archives for similar issues and still am experiencing things
that I have seen no reference to anywhere. I'd REALLY like to make this
configuration work.
Mark
> -----Original Message-----
> From: lvs-users-admin@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:lvs-users-admin@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of
> Joseph Mack
> Sent: Wednesday, May 16, 2001 2:42 PM
> To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx; markm@xxxxxxxxxxxxxxxxxxx
> Subject: Re: Hot Spare config with LVS? - More Questions
>
>
> Mark Miller wrote:
> >
> > Joeseph,
> >
> > Actually I did see it in the FAQ but maybe I missunderstood
> the mechanism by
> > which it handles getting the masq done. I haven't setup
> any MASQ rules
> > myself for either the primary or secondary director. My
> understanding is
> > that the director handles this...
>
> yes
>
> > but it does it using netfilter correct?
>
> don't know how it's done internally, but the masquerading and
> demasquerading
> are setup and you get a VS-NAT director,
>
> > shouldn't I be able to see any iptables rules?
>
> my iptables -L -t nat is empty
>
> > Or, are you saying that
> > ipvsadm handles all the MASQ stuff itself and does the
> forwarding, source
> > and dest address changing, etc?
>
> I guess so
>
> If so, it certainly seems like it's not
> > working correctly for my backup. I know forwarding is
> working because
> > packets make it in through the LD to the RS and back to the
> LD but not
> > beyond. That's the issue I guess, why would the packets
> not leave the LD?
> > When I do an ipvsadm -Lcn these connections show up as:
> >
> > IPVS connection entries
> > pro expire state source virtual
> destination
> > TCP 00:25.52 SYN_RECV 10.10.9.63:2897 10.10.21.68:80
> 10.200.200.1:80
> > TCP 00:45.92 SYN_RECV 10.10.9.63:2898 10.10.21.68:80
> 10.200.200.1:80
> > TCP 00:42.92 SYN_RECV 10.10.9.63:2900 10.10.21.68:80
> 10.200.200.1:80
> > TCP 00:51.92 SYN_RECV 10.10.9.63:2902 10.10.21.68:80
> 10.200.200.1:80
> > TCP 00:08.92 SYN_RECV 10.10.9.63:2891 10.10.21.68:80
> 10.200.200.1:80
> > TCP 00:52.72 SYN_RECV 10.10.9.63:2895 10.10.21.68:80
> 10.200.200.1:80
> > TCP 00:30.72 SYN_RECV 10.10.9.63:2894 10.10.21.68:80
> 10.200.200.1:80
>
> I don't really know and have to dive off for the day. As a wild guess,
> are the packets from the realservers being sent to the new director
> as default gw? Are you starting new connections with the new director
> (your old sessions won't carry through to the new director).
>
> 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
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
|
