You're misunderstanding outgoing interface and bound IP address.
when using source x.x.x.x, haproxy will use the NIC which hosts the
IP address x.x.x.x to try to reach the server.
then your kernel will pick up the main IP address configured on the
corresponding nic, that's why it works when you
Hi All,
Well, you can also use a couple of LVS clusters in DSR mode:
between clients and HAProxy, DSR mode, source hash load-balancing.
Between HAProxy and servers, DSR mode, destination hash load-balancing.
and you're done :)
Your architecture becomes scallable and you avoid this dirty RRDNS
Hi,
You're misunderstanding outgoing interface and bound IP address.
when using source x.x.x.x, haproxy will use the NIC which hosts the
IP address x.x.x.x to try to reach the server.
then your kernel will pick up the main IP address configured on the
corresponding nic, that's why it works
Hi Baptiste,
when using source x.x.x.x, haproxy will use the NIC which hosts the
IP address x.x.x.x to try to reach the server.
then your kernel will pick up the main IP address configured on the
corresponding nic, that's why it works when you have one IP per NIC
but it doesn't work when
You're right...
documentation says about source x.x.x.x : the IPv4 address HAProxy
will bind to before connecting to a server.
Actually, I use very often source 0.0.0.0 combined with usesrc
clientip. In such configuration, HAProxy will let the system choose
the right outgoing interface address
On my laptop, kernel 3.10.6, haproxy 1.5-dev19-50, compiled with
TARGET=linux2628 USE_ZLIB=yes USE_OPENSSL=yes USE_PCRE=yes (TPROXY
implicitly setup by the TARGET).
I confirm that source x.x.x.x, using x.x.x.x as an alias works perfectly.
So I wonder if Nerilaunt issue is in his kernel...
Could
Hi,
I confirm that source x.x.x.x, using x.x.x.x as an alias works perfectly.
FYI: this works even if the build target is linux26.
In the strace, I see that haproxy succesfully binds to 10.0.0.84 (which is a
secondary IP on eth0 here):
bind(9, {sa_family=AF_INET, sin_port=htons(0),
Working here on a redhat 64bit using :
2.6.18-274.12.1.el5 #1 SMP x86_64 x86_64 x86_64 GNU/Linux
The source x.x.x.x is binded on alias.
Using haproxy 1.5-dev19 too.
On Mon, Aug 19, 2013 at 12:37 PM, Lukas Tribus luky...@hotmail.com wrote:
Hi,
I confirm that source x.x.x.x, using
Hello,
I've been running 1.5-dev releases for about 6 months now, and have been
running dev19 since it was released in June. It seems to be crashing on me
more than the previous builds.
I ran it in debug mode and logged to a file, so hopefully this can help to
track down the issue.
Here's the
Hi Nick,
Can you confirm whether you installed dev19 from the raw .tar.gz
archive or the latest one from git?
Usually, the second option is prefered, so if you chose the first one,
could you please update it using git then let us know if this version
still crashes.
Baptiste
On Mon, Aug 19,
Hi again,
Could you let us know which version of HAProxy are you running and how you
did compiled it?
Version 1.5-dev19, one a 2.6.25-2-686 (yep, very old one) kernel,
compiled with :
make TARGET=linux26 USE_OPENSSL=yes
It would be intersting to see if the bind call returns non-zero in
Yeah, I was using the tar.gz, will update from git and rebuild and report
any further crashes.
Thanks
Nick
On Mon, Aug 19, 2013 at 3:05 PM, Baptiste bed...@gmail.com wrote:
Hi Nick,
Can you confirm whether you installed dev19 from the raw .tar.gz
archive or the latest one from git?
Please report if you have no crashes as well.
Baptiste
On Mon, Aug 19, 2013 at 4:11 PM, Nick Jennings n...@silverbucket.net wrote:
Yeah, I was using the tar.gz, will update from git and rebuild and report
any further crashes.
Thanks
Nick
On Mon, Aug 19, 2013 at 3:05 PM, Baptiste
Hi!
I've been running 1.5-dev releases for about 6 months now, and have
been running dev19 since it was released in June. It seems to be
crashing on me more than the previous builds.
Are you implying older releases crashed as well, but no so often?
When updating your build, as per Baptiste
First of all, thanks so much to everyone for the responses so far! It's
been really helpful, and I'd love to hear what anyone else thinks.
Have you considered using Haproxy with Direct Server Return to work
around the routing issue?
You cannot use HAProxy with Direct Server Return, because
Hi,
You've got me thinking that maybe I'm going about this wrong and should
focus on using a single instance, with a corosync/pacemaker standby. I
hadn't done the calculations before, assuming I'd need more than one
instance, but now I see that about 7.5GB of RAM should handle 300,000
17 matches
Mail list logo