Scaling out an on-prem livepatch deployment

There are several possible scenarios where scaling out a livepatch deployment could be necessary:

  1. High traffic due to large amount of machines being serviced
  2. High availability setups

The livepatch on-prem deployment consists of 3 main components: the haproxy reverse-proxying requests, postgresql storing livepatch data and livepatch server itself. Any one (or all) of these components can be scaled out.

image5

Scaling out haproxy

To deploy more than one ingress haproxy unit, run the following juju command:

$ juju add-unit haproxy -n 1

-n 1 indicates the number of units to add

If more than one haproxy unit is being used, the DNS entry pointing to the livepatch server should contain links to all the haproxy units.

Scaling out postgresql

Scaling out postgresql will deploy additional follower units that can take over in case the leader fails.

To deploy additional postgresql units, run the following juju command:

$ juju add-unit postgrseql -n 1

-n 1 indicates the number of units to add

Scaling out livepatch

Deploying additional livepatch units will let them share the load of handling machine requests. The filesystem patch storage type is not compatible with a scaled out livepatch setup.

To deploy additional livepatch units, run the following juju commands:

$ juju add-unit livepatch -n 1

-n 1 indicates the number of units to add

Once the units have been added, an additional command will have to be run for each of the new units:

$ juju run-action livepatch/{i} get-resource-token

{i} is the number of the new livepatch unit in the juju status output