From 45f934ab9b1d0b6b9ce1797aa37660c28d5b114c Mon Sep 17 00:00:00 2001 From: Lucas Di Pentima Date: Thu, 24 Aug 2023 17:35:39 -0300 Subject: [PATCH] 20889: Removes unnecessary documentation about rolling upgrades. Arvados-DCO-1.1-Signed-off-by: Lucas Di Pentima --- .../salt-multi-host.html.textile.liquid | 53 +------------------ 1 file changed, 2 insertions(+), 51 deletions(-) diff --git a/doc/install/salt-multi-host.html.textile.liquid b/doc/install/salt-multi-host.html.textile.liquid index cad0675449..81aa2ab099 100644 --- a/doc/install/salt-multi-host.html.textile.liquid +++ b/doc/install/salt-multi-host.html.textile.liquid @@ -31,7 +31,6 @@ SPDX-License-Identifier: CC-BY-SA-3.0 # "Initial user and login":#initial_user # "Monitoring and Metrics":#monitoring # "Load balancing controllers":#load_balancing -## "Rolling upgrades procedure":#rolling-upgrades # "After the installation":#post_install h2(#introduction). Introduction @@ -520,57 +519,9 @@ Once the infrastructure is deployed, you'll then need to define which node will ) -Note that we also set the @database@ role to its own node. +Note that we also set the @database@ role to its own node instead of just leaving it in a shared controller node. -h3(#rolling-upgrades). Rolling upgrades procedure - -Once you have more than one controller backend node, it's easy to take one at a time from the backend pool to upgrade it to a newer version of Arvados (which might involve applying database migrations) by adding its name to the @DISABLED_CONTROLLER@ variable in @local.params@. For example: - -
...
-DISABLED_CONTROLLER="controller1"
-...
- -Then, apply the configuration change to just the load-balancer: - -
./installer.sh deploy controller.xarv1.example.com
- -This will allow you to do the necessary changes to the @controller1@ node without service disruption, as it will not be receiving any traffic until you remove it from the @DISABLED_CONTROLLER@ variable. - -Next step is applying the @deploy@ command to @controller1@: - -
./installer.sh deploy controller1.xarv1.example.com
- -After that, disable the other controller node by editing @local.params@: - -
...
-DISABLED_CONTROLLER="controller2"
-...
- -...applying the changes on the balancer node: - -
./installer.sh deploy controller.xarv1.example.com
- -Then, deploy the changes to the recently disabled @controller2@ node: - -
./installer.sh deploy controller2.xarv1.example.com
- -This won't cause a service interruption because the load balancer is already routing all traffic to the othe @controller1@ node. - -And the last step is enabling both controller nodes by making the following change to @local.params@: - -
...
-DISABLED_CONTROLLER=""
-...
- -...and running: - -
./installer.sh deploy controller.xarv1.example.com
- -This should get all your @controller@ nodes correctly upgraded, and you can continue executing the @deploy@ command with the rest of the nodes individually, or just run: - -
./installer.sh deploy
- -Only the nodes with pending changes might require certain services to be restarted. In this example, the @workbench@ node will have the remaining Arvados services upgraded and restarted. However, these services are not as critical as the ones on the @controller@ nodes. +Each time you run @installer.sh deploy@, the system will automatically do rolling upgrades. This means it will make changes to one controller node at a time, after removing it from the balancer so that there's no downtime. h2(#post_install). After the installation -- 2.30.2