according to the tutorial at https://www.golinuxcloud.com/configure-haproxy-in-openstack-high-availability/ trying to implement HA. I'm stuck at the step where I need to add a VIP alias to the /etc/httpd/conf.d/15-horizon_vhost.conf file that I don't have. Does anyone know where I have to put this? I work on the Stein edition.
The process of HA implementation for OpenStack is quite simple. you need to setup a VIP on your loadbalancer machines and manage the VIP with a clustering tool like keepalived or pacemaker, so you have VIP where you have your haproxy up and running. actually you can skip that part and use something like below for haproxy config.
global
chroot /var/lib/haproxy
daemon
group haproxy
maxconn 4000
pidfile /var/run/haproxy.pid
user haproxy
defaults
log global
maxconn 4000
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout check 10s
listen dashboard_cluster
bind 172.16.64.151:443
balance source
option tcpka
option httpchk
option tcplog
server controller1 172.16.64.138:443 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:443 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:443 check inter 2000 rise 2 fall 5
listen galera_cluster
bind 172.16.64.151:3306
balance source
option mysql-check
server galera1 172.16.64.136:3306 check port 9200 inter 2000 rise 2 fall 5
server galer2a 172.16.64.137:3306 backup check port 9200 inter 2000 rise 2 fall 5
listen glance_api_cluster
bind 172.16.64.151:9292
balance source
option tcpka
option httpchk
option tcplog
server controller1 172.16.64.138:9292 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:9292 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:9292 check inter 2000 rise 2 fall 5
listen glance_registry_cluster
bind 172.16.64.151:9191
balance source
option tcpka
option tcplog
server controller1 172.16.64.138:9191 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:9191 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:9191 check inter 2000 rise 2 fall 5
listen keystone_admin_cluster
bind 172.16.64.151:35357
balance source
option tcpka
option httpchk
option tcplog
server controller1 172.16.64.138:35357 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:35357 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:35357 check inter 2000 rise 2 fall 5
listen keystone_public_internal_cluster
bind 172.16.64.151:5000
balance source
option tcpka
option httpchk
option tcplog
server controller1 172.16.64.138:5000 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:5000 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:5000 check inter 2000 rise 2 fall 5
listen nova_ec2_api_cluster
bind 172.16.64.151:8773
balance source
option tcpka
option tcplog
server controller1 172.16.64.138:8773 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:8773 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:8773 check inter 2000 rise 2 fall 5
listen nova_compute_api_cluster
bind 172.16.64.151:8774
balance source
option tcpka
option tcplog
server controller1 172.16.64.138:8774 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:8774 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:8774 check inter 2000 rise 2 fall 5
listen nova_metadata_api_cluster
bind 172.16.64.151:8775
balance source
option tcpka
option tcplog
server controller1 172.16.64.138:8775 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:8775 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:8775 check inter 2000 rise 2 fall 5
listen nova_placement_cluster
bind 172.16.64.151:8778
balance source
option tcpka
option tcplog
server controller1 172.16.64.138:8778 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:8778 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:8778 check inter 2000 rise 2 fall 5
listen cinder_api_cluster
bind 172.16.64.151:8776
balance source
option tcpka
option httpchk
option tcplog
server controller1 172.16.64.138:8776 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:8776 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:8776 check inter 2000 rise 2 fall 5
listen ceilometer_api_cluster
bind 172.16.64.151:8777
balance source
option tcpka
option tcplog
server controller1 172.16.64.138:8777 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:8777 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:8777 check inter 2000 rise 2 fall 5
listen nova_vncproxy_cluster
bind 172.16.64.151:6080
balance source
option tcpka
option tcplog
server controller1 172.16.64.138:6080 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:6080 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:6080 check inter 2000 rise 2 fall 5
listen neutron_api_cluster
bind 172.16.64.151:9696
balance source
option tcpka
option httpchk
option tcplog
server controller1 172.16.64.138:9696 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:9696 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:9696 check inter 2000 rise 2 fall 5
listen swift_proxy_cluster
bind 172.16.64.151:8080
balance source
option tcplog
option tcpka
server controller1 172.16.64.138:8080 check inter 2000 rise 2 fall 5
server controller2 172.16.64.139:8080 check inter 2000 rise 2 fall 5
server controller3 172.16.64.129:8080 check inter 2000 rise 2 fall 5
Related
I have openstack wallaby running in two vm in VBox with Ubuntu 20.04, Controller and compute1. Everything runs without issues in provider network flat type except the dhcp.
For example, I have a network created in the range of 192.168.8.20-192.168.8.30. I selected to have a DHCP.
The instance gets an ip and runs, but when running it I can't get a response from the DHCP, like it did not exist. I mean, the port is attached to the DCHP with the ip 192.168.8.20.
I can even connect to it running ip netns.
root#controller:/home/stack# ip netns list
qdhcp-36c8f4db-ccfc-483b-a5ff-868185dcce0f (id: 0)
When i try to ping the instance ip from the DHCP to the instance using netns the dhcp server did not get any response from the instance or any device in the network. The network works, because if I setup the ip manually in the instance I can get access to the gateway. But it didn't see the DHCP server, sending DHCP_DISCOVER without any response.
Address -> 192.168.8.0/24 36c8f4db-ccfc-483b-a5ff-868185dcce0f
Subnet -> 192.168.8.120,192.168.8.130 09c143c9-0225-4951-bd9c-61846b8078a1
DHCP -> 192.168.8.120 f4b2f7ba-c9e8-493d-a010-852e72f46ef7
Instance -> 192.168.8.22 53316673-b6eb-4880-866f-91b1613aa17c
The process:
root#controller:/home/stack# ps aux | grep dnsmasq
nobody 3616 0.0 0.0 12144 364 ? S 18:11 0:00 dnsmasq --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/host --addn-hosts=/var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/opts --dhcp-leasefile=/var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/leases --dhcp-match=set:ipxe,175 --dhcp-userclass=set:ipxe6,iPXE --local-service --bind-dynamic --dhcp-range=set:subnet-09c143c9-0225-4951-bd9c-61846b8078a1,192.168.8.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1500 --dhcp-lease-max=256 --conf-file=/dev/null --domain=openstacklocal
root 6278 0.0 0.0 6380 2380 pts/1 S+ 18:59 0:00 grep --color=auto dnsmasq
And the log from /var/log/syslog
Nov 6 19:05:10 controller dnsmasq-dhcp[3616]: DHCPRELEASE(ns-f4b2f7ba-c9) 192.168.8.128 fa:16:3e:24:74:93
Nov 6 19:05:10 controller dnsmasq[3616]: read /var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/addn_hosts - 1 addresses
Nov 6 19:05:10 controller dnsmasq-dhcp[3616]: read /var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/host
Nov 6 19:05:10 controller dnsmasq-dhcp[3616]: read /var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/opts
Nov 6 19:05:30 controller dnsmasq[3616]: read /var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/addn_hosts - 2 addresses
Nov 6 19:05:30 controller dnsmasq-dhcp[3616]: read /var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/host
Nov 6 19:05:30 controller dnsmasq-dhcp[3616]: read /var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/opts
Nov 6 19:05:30 controller dnsmasq[3616]: read /var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/addn_hosts - 2 addresses
Nov 6 19:05:30 controller dnsmasq-dhcp[3616]: read /var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/host
Nov 6 19:05:30 controller dnsmasq-dhcp[3616]: read /var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/opts
Nov 6 19:05:30 controller dnsmasq[3616]: read /var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/addn_hosts - 2 addresses
Nov 6 19:05:30 controller dnsmasq-dhcp[3616]: read /var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/host
Nov 6 19:05:30 controller dnsmasq-dhcp[3616]: read /var/lib/neutron/dhcp/36c8f4db-ccfc-483b-a5ff-868185dcce0f/opts
I need to load balance requests based on the requested URI. E.g.:
requests to http://website.com/* should go to web-server1, 2 and 3.
requests to http://website.com/api should go to api-server1, 2 and 3.
Currently no matter the path/URI all requests go to web-server1-3. This is how it is setup in all my 3 haproxy hosts:
frontend fe
default_backend web-servers
backend web-servers
balance leastconn
server web-server-1 1.1.1.1:80 check weight 1
server web-server-2 1.1.1.2:80 check weight 1
server web-server-3 1.1.1.3:80 check weight 1
Both web and api services are running in the same host (i.e., web-server-1 to 3), with JBoss. Recently, I decided to split the web and api services so I could load balance according to the URI, as I mentioned in the begining.
So, now I have a total of 6 servers:
web-server-1 to 3 (1.1.1.1-3:80)
api-server-1 to 3 (1.1.1.4-6:8088)
To do this I came up with 2 different options:
1) add 3 nginx hosts. The haproxy configuration would look like this:
backend nginx-servers
balance leastconn
server nginx-1 1.1.1.7:80 check weight 1
server nginx-2 1.1.1.8:80 check weight 1
server nginx-3 1.1.1.9:80 check weight 1
And now each nginx host routes based on the URI, such as:
upstream web-servers {
server 1.1.1.1:80;
server 1.1.1.2:80;
server 1.1.1.3:80;
}
upstream api-servers {
server 1.1.1.4:8088;
server 1.1.1.5:8088;
server 1.1.1.6:8088;
}
server {
location ~ "/" {
proxy_pass http://web-servers;
proxy_set_header Host $host;
}
location ~ "/api" {
proxy_pass http://api-servers;
}
}
2) the alternative using only haproxy would be:
frontend fe
acl website_domain req.hdr(host) -i website.com
acl route_api path -i -m beg /api
use_backend api-servers if route_api
use_backend web-servers if website_domain !route_api
backend web-servers
balance leastconn
server web-server-1 1.1.1.1:80 check weight 1
server web-server-2 1.1.1.2:80 check weight 1
server web-server-3 1.1.1.3:80 check weight 1
backend api-servers
balance leastconn
server api-server-1 1.1.1.4:8088 check weight 1
server api-server-2 1.1.1.5:8088 check weight 1
server api-server-3 1.1.1.6:8088 check weight 1
However, with this second option when I access http://website.com/ all my api requests return http/404. How is this second approach different from the first one (that actually works)?
I use haproxy as tcp balancer for my servers. There are a few hundred non-zero Send-Q connections between haproxy and clients. And there are many 'cD' flag in haproxy log. Now many server responses reach clients very slowly(more than 10 seconds). Is it caused by clients not receiving data? Or haproxy server does not work properly? Or haproxy server reaches bandwidth limit? What can I do to find the reason?
#455 non-zero Send-Q connection
ubuntu#ip-172-31-19-218:~$ netstat -atn|awk '{if($3>0) print $0}'|wc -l
455
#Top five Send-Q connections
ubuntu#ip-172-31-19-218:~$ netstat -atn|awk '{if($3>0) print $0}'|sort -k3nr|head -n 5
tcp 0 27292 172.31.19.218:12135 :47685 ESTABLISHED
tcp 0 22080 172.31.19.218:12135 :11817 ESTABLISHED
tcp 0 21886 172.31.19.218:12135 :12755 ESTABLISHED
tcp 0 21584 172.31.19.218:12135 :8753 ESTABLISHED
#many 'cD' flags in haproxy log
ubuntu#ip-172-31-19-218:/var/log$ awk '{print $12}' haproxy.log | sort | uniq -c
3
7525 --
**4687 cD**
526 CD
1 /run/haproxy.pid
3 SD
#some 'cD' flag logs
[27/Sep/2017:10:04:11.791] game nodes/s23 1/1/424425 34577 cD 4130/4130/4130/154/0 0/0
[27/Sep/2017:10:09:59.272] game nodes/s34 1/0/77777 3387 cD 4129/4129/4129/165/0 0/0
[27/Sep/2017:09:55:18.557] game nodes/s13 1/0/958654 84303 cD 4128/4128/4128/173/0 0/0
[27/Sep/2017:10:09:34.121] game nodes/s15 1/0/103309 3573 cD 4127/4127/4127/168/0 0/0
#haproxy config
ubuntu#ip-172-31-19-218:/var/log$ cat /etc/haproxy/haproxy.cfg
global
daemon
maxconn 200000
log 127.0.0.1 local0
defaults
maxconn 200000
timeout connect 5000
timeout client 60000
timeout server 60000
listen game
bind *:12135
mode tcp
option tcplog
log global
balance roundrobin
default_backend nodes
backend nodes
server s11 172.31.20.23:12137
....
i want to reject the connection if the user spams the server with requests. My current config looks like this:
frontend http_front
bind *:80
log global
stick-table type ip size 1m expire 1m store gpc0,http_req_rate(10s)
# Increase gpc0 if requests in last 10s where greater than 10
acl conn_rate_abuse src_http_req_rate gt 10
acl mark_as_abuser src_inc_gpc0 gt 0
tcp-request connection track-sc1 src
# Reject if gpc0 greater than 1
tcp-request connection reject if conn_rate_abuse mark_as_abuser
default_backend http_back
The Socket- Output looks like this
0x1e455c0: key=10.23.27.55 use=0 exp=51149 gpc0=0 http_req_rate(10000)=422
What am i doing wrong?!
Edit://
With this code it works, but shouldnt it work with only the code above?
backend http_back
balance roundrobin
acl abuse src_http_req_rate(http_front) ge 10
tcp-request content reject if abuse
server test1 ip1:80 check
server test2 ip2:80 check
HA-Proxy version 1.6.4 2016/03/13
We are trying to configure two back end with https in haproxy load balancing scenario.
We tried ssl termination, hrd_beg , … but could not come to expected result
As in every configuration we tried requests are being transferred to default back end only and not to other back end.
Below is my configuration file.
global
log 127.0.0.1 local0 notice
log 127.0.0.1 local1 debug
maxconn 5000 # Total Max Connections. This is dependent on ulimit
daemon
quiet
nbproc 1 # Number of processing cores. Dual Dual-core Opteron is 4 cores for example.
chroot /usr/share/haproxy
user haproxy
group haproxy
#stats socket /var/run/haproxy.stat mode 600
defaults
log global
# Setting options
option dontlognull #Disable logging of null connections as these can pollute the logs
option redispatch # Enable session redistribution in case of connection failure, which is important in a HA environment
option tcp-smart-accept # Performance tweak, saving one ACK packet during the accept sequence
option tcp-smart-connect # Performance tweak, saving of one ACK packet during the connect sequence
# Setting timeouts
timeout connect 5s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 5s
retries 3
# Slowloris protection
timeout http-request 10s # Slowloris protection
timeout tarpit 1m # tarpit hold time
timeout queue 1m
backlog 10000
frontend ap_ft_https
bind *:443 ssl crt /home/mykey.pem
mode tcp
acl dcall url_sub dc
use_backend dc_bk_https if dcall
use_backend ap_bk_https if { hdr_beg(host) -i ap }
use_backend dc_bk_https if { hdr_beg(host) -i dc }
default_backend ap_bk_https
# Configuration for AP Portals
backend ap_bk_https
mode tcp
balance roundrobin # Load Balancing algorithm
reqadd X-Forwarded-Proto:\ https
#option tcplog
default-server inter 5s rise 2 fall 5
server server1 x.x.x.x:443 weight 1 maxconn 512 check
# server server2 x.x.x.x:443 weight 1 maxconn 512 check
#Configuration for DC Portals
backend dc_bk_https
mode tcp
balance roundrobin # Load Balancing algorithm
reqadd X-Forwarded-Proto:\ https
#option tcplog
default-server inter 5s rise 2 fall 5
server server1 x.x.x.x:443 weight 1 maxconn 512 check
server server2 x.x.x.x:443 weight 1 maxconn 512 check
#HAProxy Stats configuration
listen stats
mode http
bind 0.0.0.0:8880
clitimeout 100s
srvtimeout 100s
contimeout 100s
timeout queue 100s
stats enable
stats hide-version
stats refresh 30s
stats show-node
stats uri /haproxy?stats
stats realm Admin\ Portal\ HAProxy\ Statistics
stats auth admin:xxxx
My Web addresses starts like apxxx.domain.com and dcxxx.domain.com.
I want to configure haproxy such a way that if request is for apxxx.domain.com then it should go to haproxy backend ap_bk_https and the same way if it is for dcxxx.domain.com it should go to haproxy backend dc_bk_https.
Your help will be appreciated!
/****************************************************/
ROUTING BY SUB-Domain
frontend http-in
bind *:80
acl app_ap hdr_end(host) -i apxxx.domain.com
acl app_dc hdr_end(host) -i dcxxx.domain.com
use_backend ap_bk_https if app_ap
use_backend dc_bk_https if app_dc
Now all request from apxxx.domain.com and dcxxx.domain.com will be redirected to your respected backends.
/**********************************/
/*************** OLD ANSWER ************************///
Basically what you want is to route by domain name.
Here's an example which does exactly what you want. Have a look at it. Its simple .
http://seanmcgary.com/posts/haproxy---route-by-domain-name
/** OLD ANSWER ENDS ************/
I hope this will solve your problem.