I would like to choose a backend based on custom hash function that hashes the client ip (I know this is not ideal but I am trying this approach out).
A pseudo config would look like,
frontend myserver
bind *:80
acl MyHash(clientIP) %2
use_backend backend0 if {MyHash(clientIP)%2 -m int 0}
default_backend backend1
backend backend0
balance leastconn
server server-1 <ip>:port check
server server-2 <ip>:port check
backend backend1
balance leastconn
server server-3 <ip>:port check
server server-4 <ip>:port check
The reason I am doing this instead of the following alternate, is that, I don't want connect a client to a server all the time, instead distribute the load among the servers that belong to same cluster.
server-[1-2] form a cluster and so do server-[3-4].
frontend myserver
bind *:80
default_backend mybackend
backend mybackend
balance source
hash-type consistent
server server-1 <ip>:port check
server server-2 <ip>:port check
server server-3 <ip>:port check
server server-4 <ip>:port check
Able to figure this out.
frontend myserver
bind *:80
acl select_backend_0 src,field(-1,.),mod(2) -m int 0
acl select_backend_1 src,field(-1,.),mod(2) -m int 1
# Use section can be further optimized, like using a map or something.
use_backend backend0 if select_backend_0
use_backend backend1 if select_backend_1
backend backend0
balance leastconn
server server-1 <ip>:port check
server server-2 <ip>:port check
backend backend1
balance leastconn
server server-3 <ip>:port check
server server-4 <ip>:port check
Related
I have two HAProxy in different regions. Each haproxy have some instances for balancing.
Is it possible to use each of these proxies as a backup for another?
I found this article with examples:
https://www.haproxy.com/blog/failover-and-worst-case-management-with-haproxy/
I tried to use something like this:
...
backend bk_app_backup
server second_haproxy.com x.x.x.x:443 check backup
But I got 502 Bad Gateway when I try to open https://x.x.x.x
Or, I can not use haproxy as a backup and should add all instances from backend of first haproxy config to second in backup section?
Something like this:
#first haproxy
...
backend http_back
balance roundrobin
server instance_a_01 x.x.x.x:443 check
server instance_a_01 x.x.x.x:443 check
#second haproxy
...
backend http_back
balance roundrobin
server instance_b_01 x.x.x.x:443 check
server instance_b_02 x.x.x.x:443 check
...
backend bk_app_backup
server instance_a_01 x.x.x.x:443 check backup
server instance_a_02 x.x.x.x:443 check backup
I need to setup a load balancer for all our applications.
At the moment all our applications are clustered (2-node appservers, and 1 apache on each node as well) and we do not have a LB so we just point our DNS alias to the first webserver of each node, making the second node useless (have to manually do a DNS switch in case of a failure of node1, and we don't have load balanced https queries).
Each application uses SSL with a specific domain & SSL certificate. we cannot accept to decrypt SSL and send unencrypted traffic to the backends as the LB might be located in another country etc. so we need to use passthrough.
Before anything, i just wanted to know if this is actually possible in HAProxy or not ?
I am talking about ~50 different applications. Our LB configuration would have to be HA so i guess we'll use something like keepalived with a shared VIP for HAProxy itself.
The setup would look like this i suppose :
domain-a.com-' '-> backend_dom_a -> 1.1.1.1 (app node1 dom a)
| | 1.1.1.2 (app node2 dom a)
domain-b.com-' '-> backend_dom_b -> 2.1.1.1 (app node1 dom b)
| | 2.1.1.2 (app node2 dom b)
domain-c.com-' '-> backend_dom_c -> 3.1.1.1 (app node1 dom c)
| | 3.1.1.2 (app node2 dom c)
domain-N.com-' '-> backend_dom_N -> 4.1.1.1 (app node1 dom N)
| | 4.1.1.2 (app node2 dom N)
+-> haproxy -+
Thanks for your support, best regards
FYI i'm using this configuration that works like a charm.
i have replaced the values in the files to hide our domains & hostnames, and limited the numbers of urls/backends but we have about 50 running now with the load balancer forwarding requests to many apache servers (and each apache forwards requests to tomcat servers behind)
feel free if you have any question
we use balance source to ensure session stickyness
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
daemon
user haproxy
group haproxy
log /dev/log local6 notice
log /dev/log local5 info
maxconn 50000
#chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode tcp
option tcplog
log global
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
#---------------------------------------------------------------------
# dedicated stats page
#---------------------------------------------------------------------
listen stats
mode http
bind :22222
stats enable
stats uri /haproxy?stats
stats realm Haproxy\ Statistics
stats auth <mylogin>:<mypass>
stats refresh 30s
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend main_https_listen
bind <ip address>:443
mode tcp
option tcplog
log global
tcp-request inspect-delay 5s
tcp-request content accept if { req.ssl_hello_type 1 }
#---------------------------------------------------------------------
# Common HAProxy nodes configuration
#---------------------------------------------------------------------
# -------------------------------
# ACLs
# -------------------------------
acl acl_SIT_AT35073 req.ssl_sni -i <app_url1>.my.domain.net # SIT_AT35073 is just an internal code we use, but you can use any alias
acl acl_SIT_AT34305 req.ssl_sni -i <app_url2>.my.domain.net
acl acl_SIT_AT28548 req.ssl_sni -i <app_urlN>.my.domain.net
# -------------------------------
# Conditions
# -------------------------------
use_backend backend_SIT_AT35073 if acl_SIT_AT35073 # same here
use_backend backend_SIT_AT34305 if acl_SIT_AT34305
use_backend backend_SIT_AT28548 if acl_SIT_AT28548
#---------------------------------------------------------------------
# Backends
#---------------------------------------------------------------------
# APP 1
backend backend_SIT_AT35073
description APPNAME1
mode tcp
balance source
option ssl-hello-chk
server server_SIT_AT35073_1 <apache_server1>.my.domain.net:443 check
server server_SIT_AT35073_2 <apache_server2>.my.domain.net:443 check
# APP 2
backend backend_SIT_AT34305
description APPNAME2
mode tcp
balance source
option ssl-hello-chk
server server_SIT_AT34305_1 <apache_server3>.my.domain.net:443 check
server server_SIT_AT34305_2 <apache_server4>.my.domain.net:443 check
# APP N
backend backend_SIT_AT28548
description APPNAMEN
mode tcp
balance source
option ssl-hello-chk
server server_SIT_AT28548_1 <apache_server5>.my.domain.net:443 check
server server_SIT_AT28548_2 <apache_server6>.my.domain.net:443 check
I think you have two options:
pass the traffic through to the backend by using the TCP mode in haproxy frontend and backend. This has the benefit that your backend SSL certificate is passed through. Though you lose the possibility to have one SSL termination in your site. So I present you
Have one (usual) SSL certificate, acting as termination for your site and enable SSL between your backend and haproxy instance. This gives you the advantage that you still have only one entry point but different backends with unique certificates.
The second option might look like this:
frontend f_foo
bind :443 ssl crt /path/to/bundle
mode http
log global
use_backend b2_foo
backend be_foo
mode http
timeout connect 5s
server FOO address:port ssl check crt /path/to/client/bundle force-tlsv10 verify none
The drawback is that you need a client certificate for each backend server but that should be easily automatable.
AS more of an update answer for multi domain configs I use the below for routing different domains.
in the frontend is where you bind the port and add the certs which multiple have to be on the same line afaik.
frontend https_in
bind *:443 ssl crt /link/to/cert+key-file.pem crt /link/to/cert+key-file.pem
The acl host is where you specify the domain name and which backend to use based on that domain name.
acl host_example.com hdr(host) -i example.com
use_backend BACKEND_NAME if host_example.com
The backend where you specify the server that domain is running on.
backend BACKEND_NAME
mode http
option httpclose
option forwardfor
cookie JSESSIONID prefix
server server-name server-ip:443 check ssl verify none
I have read allot of posts and tried several things, but can't seem to get what I want working and stable.
I have HAproxy setup as a pure proxy. The IP/domain of the HAproxy passes ALL to the backend server.
My issues is that the backend server domain has 2 IPs in DNS:
1.1.1.1
2.2.2.2
When the provider switches or removes an IP, HAproxy does not update to the "new" IP and gives a backend not reachable error in the logs:
Message from syslogd#localhost at Jul 18 16:15:02 ...
haproxy[3233]: backend b-http has no server available!
But there is a valid and working server on one of the ips. A restart which forces HAproxy to do a lookup normally fixes this, but I'd prefer for it to be automatic.
On HAproxy version haproxy-1.5.18 I have:
frontend f-http
bind :80
default_backend b-http
backend b-http
option forwardfor
server web-1 domain.com:80 check
I have tried on HAproxy version haproxy-1.7.8-1 I have:
resolvers public-dns
nameserver dns2 8.8.8.8:53
nameserver dns1 8.8.4.4:53
hold valid 10s
frontend f-http
bind :80
default_backend b-http
backend b-http
option forwardfor
server web-1 domain.com:80 resolvers public-dns check
As above dig on domain.com would return 2 A records. I'm thinking that there must be some config which will continue to check the IPs for a valid/working IP and start to use that one on the fly.
Any help is very much appreciated.
I have the following scenario:
Haproxy is running in front of my two groups of servers:
two http servers (active / backup)
two tcp servers (active / backup)
I now want to fail over from the active sides to the backup ones of ANY of the active services goes down (fail over HTTP and TCP at the same time).
Is there any way to do so in HAproxy? I so far was only able to fail over to one of them depending on the protocol but not both. Can these be grouped?
i was wondering if the can be done via ACLs and things like the fe_conn directive
I think haproxy's nbsrv works here. If your nbsrv count, number of healthy instances, falls below desired amount on EITHER pool switch both pools to the backup backend. Otherwise just use the default pool. Here is an example verified on 1.5.18 but should work fine on newer versions:
defaults all
timeout connect 30s
timeout client 30s
timeout server 30s
mode http
# http frontend
frontend http *:80
# use the backup service if EITHER service is down
acl use_backup nbsrv(http_service) lt 1
acl use_backup nbsrv(tcp_service) lt 1
use_backend http_service_backup if use_backup
default_backend http_service
# tcp frontend
frontend tcp_10000 *:10000
mode tcp
# use the backup service if EITHER service is down
acl use_backup nbsrv(http_service) lt 1
acl use_backup nbsrv(tcp_service) lt 1
use_backend tcp_service_backup if use_backup
default_backend tcp_service
backend tcp_service
mode tcp
# main tcp instance here
# can also include backup server here with backup directive if desired
server tcp-service1 tcp-service1.local:10000 check
backend tcp_service_backup
mode tcp
# backup tcp instance here
server tcp-service2 tcp-service2.local:10000 check
backend http_service
# main http instance here
# can also include backup server here with backup directive if desired
server http-service1 http-service1.local:80 check
backend http_service_backup
# backup http instance here
server http-service2 http-service2.local:80 check
See https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#nbsrv for more nbsrv details.
I need to setup Load balancer as an alternative for ELB for Amazon as they have issue in connection timeout.
Currently, Im using HAProxy and it works normally. However, I need to use SSL for users who wants to connect in https (port 443) to the backend apache servers plus sticky session.
What will be the configuration would looks like? I heard that HAProxy doesn't support SSL in native and can use stunnel or nginx / apache to handle the SSL termination.
I would appreciate anyone to share their knowledge and experiences.
Thanks.
James
To http use something like that.
Change the XXX.XXX.XXX.XXX to your IP address.
listen example-cluster XXX.XXX.XXX.XXX:80
mode http
stats enable
stats auth user:password
stick store-request src
stick-table type ip size 200k expire 2m
balance source
cookie JSESSIONID prefix
option httplog
option httpclose
option forwardfor
option persist
option redispatch
option httpchk HEAD /check.txt HTTP/1.0
server example-webl XXX.XXX.XXX.XXX:80 cookie A check
server example-web2 XXX.XXX.XXX.XXX:80 cookie B check
server example-web3 XXX.XXX.XXX.XXX:80 cookie C check
server example-web4 XXX.XXX.XXX.XXX:80 cookie D check
server example-web5 XXX.XXX.XXX.XXX:80 cookie E check
To your SSL use the mode tcp with balance source:
listen example-cluster-ssl XXX.XXX.XXX.XXX:443
mode tcp
reqadd X-Forwarded-Proto:\ https
stick store-request src
stick-table type ip size 200k expire 2m
option persist
option redispatch
option ssl-hello-chk
balance source
server example-webl XXX.XXX.XXX.XXX:443 check
server example-web2 XXX.XXX.XXX.XXX:443 check
server example-web3 XXX.XXX.XXX.XXX:443 check
server example-web4 XXX.XXX.XXX.XXX:443 check
server example-web5 XXX.XXX.XXX.XXX:443 check
Another way is your upgrade your haproxy to version 1.5, in that version have support to ssl but isn't stable yet.
Take a look at the Stud project on github, which combines extremely well with haproxy, is very performant, scalable, and uses very little resource. Many users are switching to it right now because it's simple and efficient.