Welcome! Log In Create A New Profile

Advanced

Feature suggestion: Check for same binding on multiple frontends

Posted by Moomjian, Chad 
Haproxy Developers,

I recently modified a configuration file for haproxy, and after setting it up, I noticed that about half of my requests came back with a 503 error, and the other half came back with the correct elements being returned.

After doing troubleshooting involving a test haproxy instance and changing the IP address, I realized that I had mistakenly added the same IP binding, 10.x.x.11:443, in two different frontends. As a result, half of my requests had no matching path (we don't use a default backend), and the other half were using responding correctly.

Since I cannot think of a time when this would be desired behavior, would it be possible to add a check on haproxy startup for the exact same IP binding in multiple frontends of the same config file? This could save me and others from possibly making this mistake in the future.

Thanks for the consideration and for the great product. We switched our entire production and pre-production environments from F5's to haproxy load balancers, and everyone has been really happy with the move. The haproxy load balancers actually outperform the expensive, commercial, physical devices.

Regards,

Chad Moomjian
Cloud Systems Administrator

OutMatch
Hello Chad,


On 7 March 2018 at 03:34, Moomjian, Chad <[email protected]> wrote:
> Haproxy Developers,
>
>
>
> I recently modified a configuration file for haproxy, and after setting it
> up, I noticed that about half of my requests came back with a 503 error, and
> the other half came back with the correct elements being returned.
>
>
>
> After doing troubleshooting involving a test haproxy instance and changing
> the IP address, I realized that I had mistakenly added the same IP binding,
> 10.x.x.11:443, in two different frontends. As a result, half of my requests
> had no matching path (we don’t use a default backend), and the other half
> were using responding correctly.
>
>
>
> Since I cannot think of a time when this would be desired behavior, would it
> be possible to add a check on haproxy startup for the exact same IP binding
> in multiple frontends of the same config file? This could save me and others
> from possibly making this mistake in the future.

You can set noreuseport in the global section to guarantee that there
is only a single socket bound to a port:

http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-noreuseport



Lukas
Thanks for the information, Lukas. I'm confused why this is not a default option though. Can you think of a time when you would ever want the exact same binding in multiple places in the config?

-----Original Message-----
From: lukas@ltri.eu [mailto:[email protected]]
Sent: Wednesday, March 7, 2018 3:21 AM
To: Moomjian, Chad <[email protected]>
Cc: haproxy@formilux.org
Subject: Re: Feature suggestion: Check for same binding on multiple frontends

Hello Chad,


On 7 March 2018 at 03:34, Moomjian, Chad <[email protected]> wrote:
> Haproxy Developers,
>
>
>
> I recently modified a configuration file for haproxy, and after
> setting it up, I noticed that about half of my requests came back with
> a 503 error, and the other half came back with the correct elements being returned.
>
>
>
> After doing troubleshooting involving a test haproxy instance and
> changing the IP address, I realized that I had mistakenly added the
> same IP binding, 10.x.x.11:443, in two different frontends. As a
> result, half of my requests had no matching path (we don’t use a
> default backend), and the other half were using responding correctly.
>
>
>
> Since I cannot think of a time when this would be desired behavior,
> would it be possible to add a check on haproxy startup for the exact
> same IP binding in multiple frontends of the same config file? This
> could save me and others from possibly making this mistake in the future.

You can set noreuseport in the global section to guarantee that there is only a single socket bound to a port:

http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-noreuseport



Lukas
Hello,


On 8 March 2018 at 06:36, Moomjian, Chad <[email protected]> wrote:
> Thanks for the information, Lukas. I'm confused why this is not a default option though. Can you think of a time when you would ever want the exact same binding in multiple places in the config?

noreuseport is not something that reads the configuration and applies
some kind of heuristics for such errors, what it does is that it makes
haproxy NOT set the SO_REUSEPORT [1] socket option.

SO_REUSEPORT is useful because it permits faster and (depending on
more factors) hitless reloads. Other than that an important use-case
is to have the kernel load-balance between different sockets on
different CPU cores for scalability reasons.



Lukas


[1] https://lwn.net/Articles/542629/
Sorry, only registered users may post in this forum.

Click here to login