High Availability: Upgrade to Chef Backend 2
This topic describes the process of upgrading a high availability Chef Infra Server cluster.
The Chef Infra Server 14 upgrade process requires downtime for stopping the server, installing the new package, and then upgrading the server, which will include an automatic Elasticsearch reindexing operation for existing Solr users. We estimate the reindexing operation will take 2 minutes for each 1000 nodes, but the it could take more time, depending on your server hardware and the complexity of your Chef data.
Overview
These instructions cover the process of upgrading a Chef Backend cluster. Please refer to the appropriate directions for the version of Chef Backend that you are using and the version that you intend to upgrade to:
Update Chef Backend
The minor version update is appropriate for all upgrades of a Chef Backend cluster within a version. For example, updating from 1.x to 1.x or 2.x to 2.x.
Note
Step 1: Block Failover
We don’t want the cluster to fail over to a follower that is in the process of being updated. So we start by disabling failover:
- Run
chef-backend-ctl set-cluster-failover off
Step 2: Update the followers
Followers should be updated sequentially. Upgrading them simultaneously is not supported and may result in data loss. Verify the successful rejoin after each upgrade.
Install the new chef-backend package:
RHEL and CentOS:
yum install PATH_TO_FILE.rpm
Debian and Ubuntu:
dpkg -i PATH_TO_FILE.deb
You may also want to look at the chef-ingredient cookbook to automate downloading and installing the latest package.
Run the upgrade command:
chef-backend-ctl upgrade
The update command will make any changes necessary to start the new service and verify that the updated node has rejoined the cluster.
Repeat the previous steps in this section for each remaining follower.
Step 3: Update the leader
Unblock failover, trigger failover, block it again.
% chef-backend-ctl set-cluster-failover on
% chef-backend-ctl upgrade --failover
% chef-backend-ctl set-cluster-failover off
Step 4: Re-enable failover
Allow failover again:
chef-backend-ctl set-cluster-failover on
Step 5: Verify the cluster is stable
Check the status of the cluster:
chef-backend-ctl status
Chef Backend 1.x to 2.x Upgrade
Warning
Identify the node with the leader role using the
chef-backend-ctl cluster-status
command:Name IP GUID Role PG ES backend-1 192.168.33.215 dc0c6ea77a751f94037cd950e8451fa3 leader leader not_master backend-2 192.168.33.216 008782c59d3628b6bb7f43556ac0c66c follower follower not_master backend-3 192.168.33.217 1af654172b1830927a571d9a5ba7965b follower follower master
In this example,
backend-1
is the leader node, as indicated by its role in the Role column.Install the new Chef Backend package on all nodes in the cluster:
RHEL and CentOS:
yum install PATH_TO_FILE.rpm
Debian and Ubuntu:
dpkg -i PATH_TO_FILE.deb
On the leader, run the following command to take the node down for the upgrade:
chef-backend-ctl down-for-upgrade
Then issue the same command on the follower nodes:
chef-backend-ctl down-for-upgrade
Initiate the upgrade on the follower nodes first:
chef-backend-ctl upgrade
Then initiate the upgrade on the leader node:
chef-backend-ctl upgrade
On any Chef Infra Server frontend nodes using the Chef Backend cluster upgraded in the previous steps, run:
chef-server-ctl reconfigure
To continue the upgrades on Chef Infra Server frontend nodes using this backend cluster, see Upgrade Frontends Associated with a Chef Backend Cluster.
DRBD/Keepalived HA to Chef Backend 2.x
DRBD configurations are no longer supported. See End of Life Products.
For a guide to migrating to Chef Backend from DRBD see the Best Best Practices for Migrating Your Chef Server webinar from the Chef Blog.
Was this page helpful?