|
Phillip,
I'm not sure why the SH scheduler is not working for you,
but I'm pretty certain that if you just remove it and use WLC with
persistence then you should get the desired result.
i.e.
-A -t x.y.z.220:0 -s wlc -p 600
-a -t x.y.z.220:0 -r a.b.c.4:0 -i -w 1
-a -t x.y.z.220:0 -r a.b.c.5:0 -i -w 1
-a -t x.y.z.220:0 -r a.b.c.6:0 -i -w 1
-a -t x.y.z.220:0 -r a.b.c.7:0 -i -w 1
Otherwise, the SH scheduler overrides the default persistence table
(which you don't really need to do).
Obviously I may be missing something important - but I don't think so.
Regards,
Malcolm Turnbull
Loadbalancer.org Ltd.
www.loadbalancer.org
+44 (0)330 380 1064
Malcolm Turnbull
Loadbalancer.org Ltd.
www.loadbalancer.org
+44 (0)330 380 1064
malcolm@xxxxxxxxxxxxxxxx
FREE TRIAL | ONLINE DEMO | REVIEWS | BLOG
On Fri, 1 Nov 2019 at 18:41, Phillip Moore <pdm@xxxxxxxxx> wrote:
>
> On Fri, Nov 1, 2019 at 12:39 PM Malcolm Turnbull <malcolm@xxxxxxxxxxxxxxxx>
> wrote:
>
> > Are you getting any health check failures?
> > It's not a consistent hash - so any config changes would throw it
>
>
> There do not seem to be any health check failures that correspond with the
> incident. That was my thought to especially because of the sh-fallback
> option in use.
>
> >
> >
> Why not just use the standard persistence table?
> > The stick table for that is completely reliable, as long as you have
> > enough memory.
> >
>
> Can you elaborate on what you mean by this? I was using source hash (sh)
> on :0 to ensure that when a client connects back on the data port, it would
> be hashed to the same place it was sent for the ftp control port. This
> seems to work most of the time as most ftp sessions work. More than chance
> anyway since we have 4 ftp servers behind the VIP and if the hashing was
> not working I would expect it to only succeed randomly 25% of the time.
>
> So I'm not sure how this would work or what you mean by the standard
> persistence table.
>
> Thank you for the suggestions.
>
> Phillip
>
>
> >
> >
> > On Fri, 1 Nov 2019 at 15:49, Phillip Moore <pdm@xxxxxxxxx> wrote:
> > >
> > > Hello!
> > > We have FTP setup with on its own VIP and just map all ports (:0) and use
> > > source hashing. Sometimes when the FTP client opens the data channel it
> > > will land on the wrong real server causing a reset. I stress sometimes
> > > because mostly FTP seems to work but we do see this behavior of requests
> > > landing on the wrong server.
> > >
> > > FTP client makes connection to VIP:0 on ftp port, is asked to open data
> > > channel on VIP:0 on alternate port. FTP client sends SYN packet but that
> > > packet doesn't land on the correct real FTP server, so connection is
> > > reset. That SYN packet likely came through a different IPVS server but
> > > should have sync connection state by this time.
> > >
> > > Example of our config:
> > >
> > > -A -t x.y.z.220:0 -s sh -p 600 -b sh-fallback
> > > -a -t x.y.z.220:0 -r a.b.c.4:0 -i -w 1
> > > -a -t x.y.z.220:0 -r a.b.c.5:0 -i -w 1
> > > -a -t x.y.z.220:0 -r a.b.c.6:0 -i -w 1
> > > -a -t x.y.z.220:0 -r a.b.c.7:0 -i -w 1
> > >
> > > 3.10.0-1062.1.1.el7.x86_64
> > >
> > > We have this config running on multiple active IPVS servers all running
> > > active/backup sync processes .
> > >
> > > We've also tried a non 1 weight (1000) to see if it was the overload
> > logic
> > > kicking in and sending requests to alt server, but that did not seem to
> > be
> > > it.
> > >
> > > Is there any reason why subsequent connections from the same source IP
> > > would land on a different server?
> > >
> > > Thanks,
> > > Phillip Moore
> > > _______________________________________________
> > > Please read the documentation before posting - it's available at:
> > > http://www.linuxvirtualserver.org/
> > >
> > > LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> > > Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> > > or go to http://lists.graemef.net/mailman/listinfo/lvs-users
> >
> > _______________________________________________
> > Please read the documentation before posting - it's available at:
> > http://www.linuxvirtualserver.org/
> >
> > LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> > Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> > or go to http://lists.graemef.net/mailman/listinfo/lvs-users
> >
> _______________________________________________
> Please read the documentation before posting - it's available at:
> http://www.linuxvirtualserver.org/
>
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
