forked from Deuxfleurs/garage
zero-downtime migration procedure
This commit is contained in:
parent
44f8b1d71a
commit
7f715ba94f
3 changed files with 79 additions and 25 deletions
|
|
@ -6,45 +6,76 @@ weight = 60
|
|||
Garage is a stateful clustered application, where all nodes are communicating together and share data structures.
|
||||
It makes upgrade more difficult than stateless applications so you must be more careful when upgrading.
|
||||
On a new version release, there is 2 possibilities:
|
||||
- protocols and data structures remained the same ➡️ this is a **straightforward upgrade**
|
||||
- protocols or data structures changed ➡️ this is an **advanced upgrade**
|
||||
- protocols and data structures remained the same ➡️ this is a **minor upgrade**
|
||||
- protocols or data structures changed ➡️ this is a **major upgrade**
|
||||
|
||||
You can quickly now what type of update you will have to operate by looking at the version identifier.
|
||||
Following the [SemVer ](https://semver.org/) terminology, if only the *patch* number changed, it will only need a straightforward upgrade.
|
||||
Example: an upgrade from v0.6.0 from v0.6.1 is a straightforward upgrade.
|
||||
If the *minor* or *major* number changed however, you will have to do an advanced upgrade. Example: from v0.6.1 to v0.7.0.
|
||||
You can quickly now what type of update you will have to operate by looking at the version identifier:
|
||||
when we require our users to do a major upgrade, we will always bump the first nonzero component of the version identifier
|
||||
(e.g. from v0.7.2 to v0.8.0).
|
||||
Conversely, for versions that only require a minor upgrade, the first nonzero component will always stay the same (e.g. from v0.8.0 to v0.8.1).
|
||||
|
||||
Migrations are designed to be run only between contiguous versions (from a *major*.*minor* perspective, *patches* can be skipped).
|
||||
Example: migrations from v0.6.1 to v0.7.0 and from v0.6.0 to v0.7.0 are supported but migrations from v0.5.0 to v0.7.0 are not supported.
|
||||
Major upgrades are designed to be run only between contiguous versions.
|
||||
Example: migrations from v0.7.1 to v0.8.0 and from v0.7.0 to v0.8.2 are supported but migrations from v0.6.0 to v0.8.0 are not supported.
|
||||
|
||||
## Straightforward upgrades
|
||||
## Minor upgrades
|
||||
|
||||
Straightforward upgrades do not imply cluster downtime.
|
||||
Minor upgrades do not imply cluster downtime.
|
||||
Before upgrading, you should still read [the changelog](https://git.deuxfleurs.fr/Deuxfleurs/garage/releases) and ideally test your deployment on a staging cluster before.
|
||||
|
||||
When you are ready, start by checking the health of your cluster.
|
||||
You can force some checks with `garage repair`, we recommend at least running `garage repair --all-nodes --yes` that is very quick to run (less than a minute).
|
||||
You will see that the command correctly terminated in the logs of your daemon.
|
||||
You can force some checks with `garage repair`, we recommend at least running `garage repair --all-nodes --yes tables` which is very quick to run (less than a minute).
|
||||
You will see that the command correctly terminated in the logs of your daemon, or using `garage worker list` (the repair workers should be in the `Done` state).
|
||||
|
||||
Finally, you can simply upgrades nodes one by one.
|
||||
Finally, you can simply upgrade nodes one by one.
|
||||
For each node: stop it, install the new binary, edit the configuration if needed, restart it.
|
||||
|
||||
## Advanced upgrades
|
||||
## Major upgrades
|
||||
|
||||
Advanced upgrades will imply cluster downtime.
|
||||
Major upgrades can be done with minimal downtime with a bit of preparation, but the simplest way is usually to put the cluster offline for the duration of the migration.
|
||||
Before upgrading, you must read [the changelog](https://git.deuxfleurs.fr/Deuxfleurs/garage/releases) and you must test your deployment on a staging cluster before.
|
||||
|
||||
From a high level perspective, an advanced upgrade looks like this:
|
||||
1. Make sure the health of your cluster is good (see `garage repair`)
|
||||
2. Disable API access (comment the configuration in your reverse proxy)
|
||||
3. Check that your cluster is idle
|
||||
We write guides for each major upgrade, they are stored under the "Working Documents" section of this documentation.
|
||||
|
||||
### Major upgrades with full downtime
|
||||
|
||||
From a high level perspective, a major upgrade looks like this:
|
||||
|
||||
1. Disable API access (for instance in your reverse proxy, or by commenting the corresponding section in your Garage configuration file and restarting Garage)
|
||||
2. Check that your cluster is idle
|
||||
3. Make sure the health of your cluster is good (see `garage repair`)
|
||||
4. Stop the whole cluster
|
||||
5. Backup the metadata folder of all your nodes, so that you will be able to restore it quickly if the upgrade fails (blocks being immutable, they should not be impacted)
|
||||
5. Back up the metadata folder of all your nodes, so that you will be able to restore it if the upgrade fails (data blocks being immutable, they should not be impacted)
|
||||
6. Install the new binary, update the configuration
|
||||
7. Start the whole cluster
|
||||
8. If needed, run the corresponding migration from `garage migrate`
|
||||
9. Make sure the health of your cluster is good
|
||||
10. Enable API access (uncomment the configuration in your reverse proxy)
|
||||
10. Enable API access (reverse step 1)
|
||||
11. Monitor your cluster while load comes back, check that all your applications are happy with this new version
|
||||
|
||||
We write guides for each advanced upgrade, they are stored under the "Working Documents" section of this documentation.
|
||||
### Major upgarades with minimal downtime
|
||||
|
||||
There is only one operation that has to be coordinated cluster-wide: the passage of one version of the internal RPC protocol to the next.
|
||||
This means that an upgrade with very limited downtime can simply be performed from one major version to the next by restarting all nodes
|
||||
simultaneously in the new version.
|
||||
The downtime will simply be the time required for all nodes to stop and start again, which should be less than a minute.
|
||||
If all nodes fail to stop and restart simultaneously, some nodes might be temporarily shut out from the cluster as nodes using different RPC protocol
|
||||
versions are prevented to talk to one another.
|
||||
|
||||
The entire procedure would look something like this:
|
||||
|
||||
1. Make sure the health of your cluster is good (see `garage repair`)
|
||||
|
||||
2. Take each node offline individually to back up its metadata folder, bring them back online once the backup is done.
|
||||
You can do all of the nodes in a single zone at once as that won't impact global cluster availability.
|
||||
Do not try to make a backup of the metadata folder of a running node.
|
||||
|
||||
3. Prepare your binaries and configuration files for the new Garage version
|
||||
|
||||
4. Restart all nodes simultaneously in the new version
|
||||
|
||||
5. If any specific migration procedure is required, it is usually in one of the two cases:
|
||||
|
||||
- It can be run on online nodes after the new version has started, during regular cluster operation.
|
||||
- it has to be run offline
|
||||
|
||||
For this last step, please refer to the specific documentation pertaining to the version upgrade you are doing.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ We define them as our release process.
|
|||
While we run some tests on every commits, we do not make a release for all of them.
|
||||
|
||||
A release can be triggered manually by "promoting" a successful build.
|
||||
Otherwise, every weeks, a release build is triggered on the `main` branch.
|
||||
Otherwise, every night, a release build is triggered on the `main` branch.
|
||||
|
||||
If the build is from a tag following the regex: `v[0-9]+\.[0-9]+\.[0-9]+`, it will be listed as stable.
|
||||
If it is a tag but with a different format, it will be listed as Extra.
|
||||
|
|
|
|||
|
|
@ -12,13 +12,15 @@ back up all your data before attempting it!**
|
|||
Garage v0.8 introduces new data tables that allow the counting of objects in buckets in order to implement bucket quotas.
|
||||
A manual migration step is required to first count objects in Garage buckets and populate these tables with accurate data.
|
||||
|
||||
## Simple migration procedure (takes cluster offline for a while)
|
||||
|
||||
The migration steps are as follows:
|
||||
|
||||
1. Disable API and web access. Garage v0.7 does not support disabling
|
||||
these endpoints but you can change the port number or stop your reverse proxy for instance.
|
||||
2. Do `garage repair --all-nodes --yes tables` and `garage repair --all-nodes --yes blocks`,
|
||||
check the logs and check that all data seems to be synced correctly between
|
||||
nodes. If you have time, do additional checks (`scrub`, `block_refs`, etc.)
|
||||
nodes. If you have time, do additional checks (`versions`, `block_refs`, etc.)
|
||||
3. Check that queues are empty: run `garage stats` to query them or inspect metrics in the Grafana dashboard.
|
||||
4. Turn off Garage v0.7
|
||||
5. **Backup the metadata folder of all your nodes!** For instance, use the following command
|
||||
|
|
@ -32,3 +34,24 @@ The migration steps are as follows:
|
|||
10. Your upgraded cluster should be in a working state. Re-enable API and Web
|
||||
access and check that everything went well.
|
||||
11. Monitor your cluster in the next hours to see if it works well under your production load, report any issue.
|
||||
|
||||
## Minimal downtime migration procedure
|
||||
|
||||
The migration to Garage v0.8 can be done with almost no downtime,
|
||||
by restarting all nodes at once in the new version. The only limitation with this
|
||||
method is that bucket sizes and item counts will not be estimated correctly
|
||||
until all nodes have had a chance to run their offline migration procedure.
|
||||
|
||||
The migration steps are as follows:
|
||||
|
||||
1. Do `garage repair --all-nodes --yes tables` and `garage repair --all-nodes --yes blocks`,
|
||||
check the logs and check that all data seems to be synced correctly between
|
||||
nodes. If you have time, do additional checks (`versions`, `block_refs`, etc.)
|
||||
|
||||
2. Turn off each node individually; back up its metadata folder (see above); turn it back on again. This will allow you to take a backup of all nodes without impacting global cluster availability. You can do all nodes of a single zone at once as this does not impact the availability of Garage.
|
||||
|
||||
3. Prepare your binaries and configuration files for Garage v0.8
|
||||
|
||||
4. Shut down all v0.7 nodes simultaneously, and restart them all simultaneously in v0.8. Use your favorite deployment tool (Ansible, Kubernetes, Nomad) to achieve this as fast as possible.
|
||||
|
||||
5. At this point, Garage will indicate invalid values for the size and number of objects in each bucket (most likely, it will indicate zero). To fix this, take each node offline individually to do the offline migration step: `garage offline-repair --yes object_counters`. Again you can do all nodes of a single zone at once.
|
||||
|
|
|
|||
Loading…
Reference in a new issue