WIP - use case for load balancer member respawn
Change-Id: I3362292106d104df1a379182502c8ab8a603641e
This commit is contained in:
Eric K
parent
f887448771
commit
79de12720a
|
|
@ -0,0 +1,150 @@
|
|||
..
|
||||
This template is intended to encourage a certain level of
|
||||
consistency between different use cases. Adherence to the structure
|
||||
of this template is recommended but not strictly required.
|
||||
|
||||
This template should be in ReSTructured text. For help with syntax,
|
||||
see <http://sphinx-doc.org/rest.html>. To test out your formatting,
|
||||
see <http://www.tele3.cz/jbar/rest/rest.html>.
|
||||
|
||||
===============================
|
||||
Load Balancer Member Respawning
|
||||
===============================
|
||||
|
||||
..
|
||||
Please fill in the blanks in this use case statement, or rephrase
|
||||
as appropriate.
|
||||
|
||||
As a cloud operator, whenever a load balancer member node fails, I want the
|
||||
load balancer to stop directing traffic to the failed member and for a new
|
||||
member to be spawned.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
..
|
||||
A more detailed description of the fault management scenario;
|
||||
however it is not advised to duplicate details covered in the
|
||||
sections below. If the problem is not too complex, it may be more
|
||||
appropriate to simply delete this section and provide the details in
|
||||
the sections below.
|
||||
|
||||
|
||||
Fault class
|
||||
===========
|
||||
|
||||
..
|
||||
Please choose which of these classes are relevant and delete the
|
||||
others. If you can think of a new class which should be listed
|
||||
here, please update the template.
|
||||
|
||||
* Hardware failure
|
||||
* Software error
|
||||
* Network failure
|
||||
|
||||
|
||||
OpenStack projects used
|
||||
=======================
|
||||
|
||||
..
|
||||
Please provide a list of projects (OpenStack and otherwise) which
|
||||
may be used in order to implement this use case. If no
|
||||
implementation exists yet, suggestions are sufficient here.
|
||||
|
||||
* Openstack Aodh (telemetry alarm service)
|
||||
* Openstack Heat (orchestration)
|
||||
* Openstack Octavia (load balancer as a service)
|
||||
|
||||
|
||||
Remediation class
|
||||
=================
|
||||
|
||||
..
|
||||
Please choose which of these classes are relevant and delete the
|
||||
others. If you can think of a new class which should be listed
|
||||
here, please update the template.
|
||||
|
||||
* Reactive
|
||||
|
||||
|
||||
Fault detection
|
||||
===============
|
||||
|
||||
..
|
||||
Describe the exact nature of the fault, which components
|
||||
will be needed to automatically detect it, and how they
|
||||
should be configured or used for the detection.
|
||||
|
||||
Octavia detects when a load balancer member node becomes unresponsive
|
||||
and raises a corresponding alarm on Aodh.
|
||||
|
||||
|
||||
Inputs and decision-making
|
||||
==========================
|
||||
|
||||
..
|
||||
Describe how decisions about the remediation action are taken. In
|
||||
particular list any other components or inputs which may provide
|
||||
additional context to help determine appropriate remediation of the
|
||||
fault.
|
||||
|
||||
* Octavia automatically stops directing traffic to the unresponsive
|
||||
member node.
|
||||
* Heat receives the Aodh alarm regarding the unresponsive member node,
|
||||
and according to the behavior defined in the stack template, spawns
|
||||
a new instance to replace the unresponsive member node.
|
||||
* Octavia detects when the new member node is operational and begins
|
||||
directing some traffic to the new node.
|
||||
|
||||
|
||||
Remediation
|
||||
===========
|
||||
|
||||
..
|
||||
Describe how the fault may be remediated. If there may be different
|
||||
approaches available, please list them all.
|
||||
|
||||
When a fault is detected, the load balancer stops directing traffic
|
||||
to the failed node.
|
||||
|
||||
At the same time, Heat spawns a new load balancer node to replace
|
||||
the failed node. When the new node is ready, the load balancer begins
|
||||
to direct some traffic to the new node.
|
||||
|
||||
|
||||
Existing implementation(s)
|
||||
==========================
|
||||
|
||||
..
|
||||
If there are one or more existing implementations of this use case,
|
||||
please give as many details as possible, in order that operators can
|
||||
re-implement the use case in their own clouds. However any
|
||||
information is better than no information! Linking to external
|
||||
documents is perfectly acceptable.
|
||||
|
||||
A demo video is available
|
||||
`here <https://www.youtube.com/watch?v=dXsGnbr7DfM>`_.
|
||||
|
||||
|
||||
Future work
|
||||
===========
|
||||
|
||||
..
|
||||
Please link from here to any relevant specs. If a cross-project
|
||||
spec is required, it can be placed under ../specs/ in this
|
||||
repository.
|
||||
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
..
|
||||
- Include specific references to specs and/or blueprints in
|
||||
self-healing-sig, or in other projects, that this one either depends
|
||||
on or is related to.
|
||||
|
||||
- Does this feature require any new library dependencies or code
|
||||
otherwise not included in OpenStack? Or does it depend on a specific
|
||||
version of library?
|
||||
Loading…
Reference in New Issue