[openstack-dev] [Fuel] Waiting for Haproxy backends
svasilenko at mirantis.com
Thu Nov 20 10:25:16 UTC 2014
> Nor should it, IMO. Other than the Neutron dhcp-agent, all OpenStack
> services that run on a "controller node" are completely stateless.
> Therefore, I don't see any reason to use corosync/pacemaker for management
> of these resources.
I see following reasons for managing neutron agents by Pacemaker:
- *co-location* between resources. For example, L3 and DHCP agents
should be run only on nodes, that has properly work openvswitch (or another
L2) agent. Then L2-agent works wrong -- L3 and DHCP agents should be
stopped immediately. Because Neutron don't control this situation and can
allocate some resources (router or subnet) to an agent.
- extended *monitoring*. Traditional OS init/upstart subsystem allow
only simple status checking (may be exclude systemd). Now we have
situation, for example with neutron agents, then some of agent pretends to
well-working. But in really, do nothing. (unfortunately, openstack
developed as is) Such agent should be immediately restarted. Our Neutron
team now works on internal health-checking feature for agents, and I hope,
that this will implemented in 6.1. For example we can make simple checking
(pid found, process started) every 10sec, and more deep (RMQ connection,
internal health-checking) -- mo rare.
- No different business-logic for different OS. We can use one OCF
script for Ubuntu, Centos, debian, etc...
- handle cluster partitioning situation.
> haproxy should just spread the HTTP request load evenly across all API
> services and things should be fine, allowing haproxy's http healthcheck
> monitoring to handle the simple service status checks.
Just HTTP checking not enough. In the future will be better make more deep
checking personal for each openstack service.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev