openstack
/
freezer-dr
Code Issues Proposed changes
Tools and automation to achieve Disaster Recovery of OpenStack Cloud Platforms
128 Commits 6 Branches 62 Tags 1.6 MiB
Python 94.6%
Jinja 5.4%
Go to file
OpenStack Release Bot 27aff441dd Update TOX_CONSTRAINTS_FILE for stable/yoga 
Update the URL to the upper-constraints file to point to the redirect
rule on releases.openstack.org so that anyone working on this branch
will switch to the correct upper-constraints list automatically when
the requirements repository branches.

Until the requirements repository has as stable/yoga branch, tests will
continue to use the upper-constraints list on master.

Change-Id: I2afb126fe6a70d18a02e9d683b9c7b18ac411b8c
 		2022-03-10 12:39:10 +00:00
config-generator freezer-dr big bang 2016-05-09 09:55:31 +00:00
doc [ussuri][goal] Update contributor documentation 2021-05-31 20:30:23 +00:00
etc Set default notifier endpoint 2018-10-15 20:28:09 +08:00
freezer_dr Remove the __future__ modulue 2020-06-19 22:52:55 -07:00
releasenotes/notes [ussuri][goal] Drop python 2.7 support and testing 2019-11-22 01:53:02 +00:00
tests Adding pep8, pylint, coverage, sphinx testing 2016-05-09 15:00:10 +00:00
.coveragerc Adding pep8, pylint, coverage, sphinx testing 2016-05-09 15:00:10 +00:00
.gitignore Update .gitignore 2018-11-12 06:20:22 -05:00
.gitreview Update .gitreview for stable/yoga 2022-03-10 12:39:08 +00:00
.pylintrc Fix pylint error 2021-11-03 06:31:43 +08:00
.stestr.conf Switch to stestr 2018-07-11 10:59:33 +07:00
.zuul.yaml Update gate ci 2021-11-03 23:28:18 +00:00
CONTRIBUTING.rst [ussuri][goal] Update contributor documentation 2021-05-31 20:30:23 +00:00
CREDITS.rst Adding CREDITS.rst 2016-02-12 16:28:58 +00:00
HACKING.rst Sync Sphinx requirement 2019-08-03 11:53:24 +02:00
LICENSE Add LICENSE file 2017-01-17 13:18:06 +07:00
README.rst Sync Sphinx requirement 2019-08-03 11:53:24 +02:00
bindep.txt Add bindep to fix py37 tests 2019-08-03 11:38:14 +02:00
lower-constraints.txt Update CI jobs for wallaby 2020-11-09 19:59:24 -08:00
requirements.txt Update CI jobs for wallaby 2020-11-09 19:59:24 -08:00
setup.cfg update python37 to python38 2021-11-03 09:36:33 +00:00
setup.py Cleanup py27 support 2020-04-12 20:58:22 +02:00
test-requirements.txt Fix hacking min version to 3.0.1 2020-09-08 17:31:58 +00:00
tox.ini Update TOX_CONSTRAINTS_FILE for stable/yoga 2022-03-10 12:39:10 +00:00

README.rst

Team and repository tags

image

Freezer Disaster Recovery

freezer-dr, OpenStack Compute node High Available provides compute node high availability for OpenStack. Simply freezer-dr monitors all compute nodes running in a cloud deployment and if there is any failure in one of the compute nodes freezer-dr will fence this compute node then freezer-dr will try to evacuate all running instances on this compute node, finally freezer-dr will notify all users who have workload/instances running on this compute node as well as will notify the cloud administrators.

freezer-dr has a pluggable architecture so it can be used with:

  1. Any monitoring system to monitor the compute nodes (currently we support only native OpenStack services status)
  2. Any fencing driver (currently supports IPMI, libvirt, ...)
  3. Any evacuation driver (currently supports evacuate api call, may be migrate ??)
  4. Any notification system (currently supports email based notifications, ...)

just by adding a simple plugin and adjust the configuration file to use this plugin or in future a combination of plugins if required

freezer-dr should run in the control plane, however the architecture supports different scenarios. For running freezer-dr under high availability mode, it should run with active passive mode.

How it works

Starting freezer-dr:

  1. freezer-dr Monitoring manager is going to load the required monitoring driver according to the configuration
  2. freezer-dr will query the monitoring system to check if it considers any compute nodes to be down ?
  3. if no, freezer-dr will exit displaying No failed nodes
  4. if yes, freezer-dr will call the fencing manager to fence the failed compute node
  5. Fencing manager will load the correct fencer according to the configuration
  6. once the compute node is fenced and is powered off now we will start the evacuation process
  7. freezer-dr will load the correct evacuation driver
  8. freezer-dr will evacuate all instances to another computes
  9. Once the evacuation process completed, freezer-dr will call the notification manager
  10. The notification manager will load the correct driver based on the configurations
  11. freezer-dr will start the notification process ...