Because Fuel Master HA is viewed as a waste of a user’s resources, we need to provide value by allowing for backup/recovery for disaster recovery scenarios. Now that Fuel Master is running on Docker containers, backup and recovery are quite painless and simple.
A detailed description of the problem:
Fuel Master backup and recovery can be simplified by use of scripts and a simple mechanism to compress and save the archive wherever the user requests.
Backup will take place with powered down containers to ensure consistent state.
Recovery in its first stage of implementation will be simplified. It will not include astute.yaml settings (IP addresses, DHCP settings, DNS, NTP, etc). It will simply restart the Docker containers to the backed up state, plus restore all configurations, Puppet manifests, and package repositories.
Backup and restore can be done with docker-0.10 without freezing running containers, but it may result in inconsistent data.
Using docker-0.12 will allow freezing containers to save running state without any destructive risks.
Changes which require modifications to the data model often have a wider impact on the system. The community often has strong opinions on how the data model should be evolved, from both a functional and performance perspective. It is therefore important to capture and gain agreement as early as possible on any proposed changes to the data model.
Questions which need to be addressed by this section include:
Each API method which is either added or changed should have the following
This will impact upgrades. The scope of this feature is not so extensive to cover restoring an old version of Fuel onto a newer installed Fuel Master. In most cases, this would downgrade every component on the system except Fuel Master base host packages. A workaround could be devised in a future blueprint, but certainly not in the time frame of 5.1.
The user will interact with backup and restore via the dockerctl command line utility. All containers will be shut down during the backup process. The backup will fail to start if there are any incomplete tasks present when running fuel task –list.
Minimal. There will be performance hits during backup process, resulting in downtime.
Discuss things that will affect how you deploy and configure Fuel that have not already been mentioned, such as:
Default backup path /var/backup/fuel The backup ID will be generated from a timestamp of YYYY-MM-DD-hh_ss. The backup will be ‘tar’ed then compressed with lrzip due to its efficiency in handling deduplication across large archives.
Yes. Immediate effect, but no backups are automatic.
Discuss things that will affect other developers working on Fuel, such as:
Feature Lead: raytrac3r Mandatory Design Reviewers: vkuklin Developers: raytrac3r QA: ykotko
Work items or tasks – break the feature up into the things that need to be done to implement it. Those parts might end up being done by different people, but we’re mostly trying to understand the timeline for implementation.
Automated tests for backup/save need to be added to current Fuel system tests.
Acceptance criteria: * User can deploy multinode OpenStack and run a backup.
User-facing docs are required to show users the different ways to perform the back up and restore.