HAProxy in High Availability Guide
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openstack-manuals |
Invalid
|
Undecided
|
Unassigned |
Bug Description
As in the guide to configure, haproxy can't startup with errors:
Dec 13 08:47:11 controller2 haproxy[12647]: Proxy galera_cluster started.
140 Dec 13 08:47:11 controller2 haproxy[12647]: Proxy galera_cluster started.
141 Dec 13 08:47:11 controller2 haproxy-
142 Dec 13 08:47:11 controller2 haproxy-
143 Dec 13 08:47:11 controller2 haproxy-
144 Dec 13 08:47:11 controller2 haproxy-
The controller's IP is 10.0.0.12 and vip is 10.0.0.10. I saw that the reason should be the related backend services has occupied
the ports: 8774, 9292 etc because they are listening on 0.0.0.0!
Then I added "net.ipv4.
Dec 14 22:04:17 controller2 nova-api[17684]: 2016-12-14 22:04:17.633 17684 ERROR nova File "/usr/lib/
Dec 14 22:04:17 controller2 nova-api[17684]: 2016-12-14 22:04:17.633 17684 ERROR nova sock.listen(
Dec 14 22:04:17 controller2 nova-api[17684]: 2016-12-14 22:04:17.633 17684 ERROR nova File "/usr/lib/
Dec 14 22:04:17 controller2 nova-api[17684]: 2016-12-14 22:04:17.633 17684 ERROR nova return getattr(
Dec 14 22:04:17 controller2 nova-api[17684]: 2016-12-14 22:04:17.633 17684 ERROR nova error: [Errno 98] Address already in use
Dec 14 22:04:17 controller2 nova-api[17684]: 2016-12-14 22:04:17.633 17684 ERROR nova
Dec 14 22:04:17 controller2 nova-api[17684]: haoqf: import GLib now
Dec 14 22:04:17 controller2 systemd[1]: nova-api.service: Main process exited, code=exited, status=1/FAILURE
Dec 14 22:04:17 controller2 systemd[1]: nova-api.service: Unit entered failed state.
Dec 14 22:04:17 controller2 systemd[1]: nova-api.service: Failed with result 'exit-code'.
The cause is because of the ports(8774,9292 etc) were occupied by haproxy now!
So I think the guide is wrong!
The solution might be either change haproxy's frontend to use different ports, or change openstack services to listen on internal
IP like 10.0.0.12 rather than 0.0.0.0.
I think the latter is better but some services have no such option to do so.
-------
Release: 0.0.1 on 2016-12-13 00:09
SHA: 2ef60ea916ae117
Source: http://
URL: http://
Fuel runs haproxy via pacemaker (not vis systemd/upstart) and pacemaker runs haproxy in a separate network namespace. So haproxy does not cause any problems by listedning on 0.0.0.0 since it's listening in a separate network namespace. You can see it via "ip netns ls" command and then "ip netns exec haproxy ip a".
Did you try to restart haproxy via systemd/upstart? If so then you could face this problem. You should use pacemaker to control haproxy service.