42df864217
W/o this fix, when the management interface on the controller node running a Swift proxy is down, HAProxy would fail to update its backend status at the storage network. This is a problem as we want swift backends not able to connect the swift endpoint via the management VIP to be marked down. Othewise, responces time for any requested swift commands would be drastically longer. Simple httpcheck option cannot resolve this because the swift healthcheck reports OK, if conntacted via the storage network. In order to fix this, simple healthcheck script is implemented. This script is running as HTTP xinetid service at TCP port 49001 and is accessible only from the localhost, 240.0.0.2, and storage plus management networks. The service verifies the node under check for the: a) management VIP is pingable via ICMP (by 3 packets) b) Swift endpoint is reachable by TCP-connect via the local storage address within 5 seconds connection timeout c) Swift healthcheck report via the local storage address endpoint is OK Reports an HTTP 200 OK, if all of the results are OK. Otherwise, it would report an HTTP 503 Error. Expected Swift node control plane failover time will be around 30 seconds. Swift data plane is not affected. DocImpact: Reference architecture, swift failover. Closes-bug: #1459772 Related-bug: #1460623 Change-Id: I55a35b45257763a20f33bd47cb5c57de53558ccf Signed-off-by: Bogdan Dobrelya <bdobrelia@mirantis.com> |
||
|---|---|---|
| debian | ||
| deployment/puppet | ||
| files | ||
| specs | ||
| tests/noop | ||
| utils | ||
| .gitignore | ||
| .gitreview | ||
| CHANGELOG | ||
| LICENSE | ||
| README.md | ||
Fuel is the Ultimate Do-it-Yourself Kit for OpenStack
Purpose built to assimilate the hard-won experience of our services team, it contains the tooling, information, and support you need to accelerate time to production with OpenStack cloud.
OpenStack is a very versatile and flexible cloud management platform. By exposing its portfolio of cloud infrastructure services – compute, storage, networking and other core resources — through ReST APIs, it enables a wide range of control over these services, both from the perspective of an integrated Infrastructure as a Service (IaaS) controlled by applications, as well as automated manipulation of the infrastructure itself.
This architectural flexibility doesn’t set itself up magically; it asks you, the user and cloud administrator, to organize and manage a large array of configuration options. Consequently, getting the most out of your OpenStack cloud over time – in terms of flexibility, scalability, and manageability – requires a thoughtful combination of automation and configuration choices.
Mirantis Fuel for OpenStack was created to solve exactly this problem.