HAproxy - Revision history

Khgras at 06:04, 28 July 2020

2020-07-28T06:04:28Z

← Older revision		Revision as of 06:04, 28 July 2020
Line 12:		Line 12:
	* As front-level loadbalancer in front of the Apache instances (in enterprise installations, however, usually other software is employed for that purpose), or		* As front-level loadbalancer in front of the Apache instances (in enterprise installations, however, usually other software is employed for that purpose), or
	* As loadbalancer for connecting the OX middleware to the database (Galera) instances, or		* As loadbalancer for connecting the OX middleware to the database (Galera) instances, or
	* As loadbalancer for connecting [[AppSuite:Dovecot_Antiabuse_Shield\|~~Dovecot Anti~~ Abuse Shield]] to Dovecot and App Suite		* As loadbalancer for connecting [[AppSuite:Dovecot_Antiabuse_Shield\|OX Abuse Shield]] to Dovecot and App Suite

	We will cover in this article the latter two use cases.		We will cover in this article the latter two use cases.
Line 27:		Line 27:
	# apt-get install haproxy		# apt-get install haproxy

	== HAproxy for ~~DAAS / wforce Loadbalancing~~ ==		== HAproxy for OX Abuse Shield ==

	In the following we present a configuration which was feedbacked to us from a large customer installation. (Thanks a lot!)		In the following we present a configuration which was feedbacked to us from a large customer installation. (Thanks a lot!)

Dominik.epple at 14:24, 18 July 2018

2018-07-18T14:24:08Z

@@ Line 3: / Line 3: @@
 == Introduction ==
-HAproxy is one of the options to use for [[OXLoadBalancingClustering_Database#Galera_database_setup|Galera]] loadbalancing. Please consider reading through [[OXLoadBalancingClustering_Database#Loadbalancer_options|the available options]] before deciding for one solution.
+HAproxy is a mature and popular option for userspace loadbalancing under Linux (and similar operating systems). Its main (original) purpose is probably HTTP load balancing.
-== System Design ==
+Thus, in Open-Xchange installations HAproxy thus typically acts in other roles:
-We present a solution where each OX node runs a HAproxy instance. This way we can implement a solution without the need for additional loadbalancer (virtual) machines.
+* As front-level loadbalancer in front of the Apache instances (in enterprise installations, however, usually other software is employed for that purpose), or
-We create two HAproxy "listener", one round-robin for the read requests, one active/passive for the write requests.
+We will cover in this article the latter two use cases.
 == Software Installation ==
 HAproxy should be shipped with the distribution.
@@ Line 17: / Line 24: @@
 Historical Wheezy note: haproxy is provided in wheezy-backports, see http://haproxy.debian.net/. More recent (Debian) distributions don't need this extra repo and provide it with their native repos.
   # apt-get install haproxy
-== Configuration ==
+== HAproxy for DAAS / wforce Loadbalancing ==
 The following is a HAproxy configuration file <code>/etc/haproxy/haproxy.cfg</code>, assuming the Galera nodes have the IPs 10.0.0.1..3.
@@ Line 90: / Line 141: @@
 Note 2: If you are configuring a dedicated loadbalancer node which should loadbalancer for other clients on the network (rather than a distributed / colocated HAproxy instance which should only serve for localhost) change the <code>bind</code> parameters accordingly.
-== Health check service ==
+=== Health check service ===
 As you can see we use the <code>httpchk</code> option, so we assume a health check service to be available. Please have a look at the [[Clustercheck]] page how to configure such a service. Please be aware that we assume you use our customized, improved [[Clustercheck|<code>clustercheck</code>]] script, so please don't use the standard one.
@@ Line 96: / Line 147: @@
 Contrary to other setup instructions which recommend to configure one node as ''regular'' node and the other two ones as <code>backup</code> nodes, we recommend to leverage a health check which declares only the node with <code>wsrep_local_index=0</code> as available. This way we ensure that even in corner cases, multiple distributed HAproxy instances can not end up with declaring different nodes as designated write nodes, which [[OXLoadBalancingClustering_Database#Write_requests|would be problematic]].
-== Monitoring ==
+=== Monitoring ===
 Besided using the Galera check service configured before, you can also speak to the stats socket of HAproxy using <code>socat</code>.

Dominik.epple at 13:37, 22 September 2017

2017-09-22T13:37:16Z

Show changes

Dennis Sieben at 09:05, 27 September 2016

2016-09-27T09:05:43Z

← Older revision		Revision as of 09:05, 27 September 2016
Line 125:		Line 125:
	}		}
	#		#

			'''Note''': Please ensure that you haven't set the <tt>max_load</tt> parameter in the xinetd configuration. This parameter will lead to xinetd not answering any request if the load increases above this value. So the system will be detected a dead even though it actually isn't.


	== Monitoring ==		== Monitoring ==

Dominik.epple: /* Configuration */

2016-09-19T14:45:27Z

Configuration

← Older revision		Revision as of 14:45, 19 September 2016
Line 48:		Line 48:
	option dontlognull		option dontlognull
	option redispatch		option redispatch
	~~option allbackups~~
	# the http options are not needed here		# the http options are not needed here
	# but may be reasonable if you use haproxy also for some OX HTTP proxying		# but may be reasonable if you use haproxy also for some OX HTTP proxying

Choeger at 13:56, 8 July 2015

2015-07-08T13:56:25Z

← Older revision		Revision as of 13:56, 8 July 2015
Line 54:		Line 54:
	no option httpclose		no option httpclose

	listen mysql-~~cluster~~		listen mysql-read
	bind 127.0.0.1:3306		bind 127.0.0.1:3306
	mode tcp		mode tcp
Line 63:		Line 63:
	server dav-db3 192.168.1.103:3306 check port 9200 inter 12000 rise 3 fall 3		server dav-db3 192.168.1.103:3306 check port 9200 inter 12000 rise 3 fall 3

	listen mysql-~~failover~~		listen mysql-write
	bind 127.0.0.1:3307		bind 127.0.0.1:3307
	mode tcp		mode tcp

Dominik.epple: /* Configuration */

2014-10-22T13:31:31Z

Configuration

← Older revision		Revision as of 13:31, 22 October 2014
Line 44:		Line 44:
	maxconn 256000		maxconn 256000
	timeout connect 60000		timeout connect 60000
	timeout client 5m		timeout client 20m
	timeout server 5m		timeout server 20m
	option dontlognull		option dontlognull
	option redispatch		option redispatch

Dominik.epple at 13:13, 22 October 2014

2014-10-22T13:13:32Z

← Older revision		Revision as of 13:13, 22 October 2014
Line 44:		Line 44:
	maxconn 256000		maxconn 256000
	timeout connect 60000		timeout connect 60000
	timeout client ~~120000~~		timeout client 5m
	timeout server ~~120000~~		timeout server 5m
	option dontlognull		option dontlognull
	option redispatch		option redispatch

Dominik.epple at 12:17, 22 October 2014

2014-10-22T12:17:21Z

← Older revision		Revision as of 12:17, 22 October 2014
Line 30:		Line 30:
	log 127.0.0.1 local0		log 127.0.0.1 local0
	log 127.0.0.1 local1 notice		log 127.0.0.1 local1 notice
			user haproxy
			group haproxy
	# this is not recommended by the haproxy authors, but seems to improve performance for me		# this is not recommended by the haproxy authors, but seems to improve performance for me
	#nbproc 4		#nbproc 4

Dominik.epple: /* Configuration */

2014-10-17T07:16:02Z

Configuration

← Older revision		Revision as of 07:16, 17 October 2014
Line 124:		Line 124:
	}		}
	#		#

			== Monitoring ==

			Besided using the Galera check service configured before, you can also speak to the stats socket of haproxy using socat.

			echo "show stat" \| socat unix-connect:/var/lib/haproxy/stats stdio

			There are more commands available via this socket to enable / disable servers; see the haproxy documentation for details. (As of writing that documentation could be found here: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#9.2 that URL seems unstable.)