About rolling upgrades

When installing or upgrading Venafi Platform, you have several options including options for high-availability (rolling upgrades), and a least-permissions model for database access. These options allow you to:

  • Improve high availability by allowing rolling upgrades of servers without needing to take all servers offline simultaneously, which can allow the services the cluster provides to stay online the entire time with the help of application delivery controllers.

    You may be concerned about the length of time involved in a rolling upgrade, and if that makes the product "half-updated." In fact, this process was designed so you can leave some servers unpatched for an extended period of time (even weeks) if needed. Of course, while it's preferable to upgrade the entire cluster as quickly as reasonably possible, the system remains fully functioning throughout the entire rolling upgrade process.

  • Leverage a least-permissions model for database access, so there is a transactional database user for daily interactions with the database, as well as an account with higher privileges used for installing and upgrading the system.

  • Improve the installation and upgrade experience by not requiring database scripts to be run manually, as Trust Protection Platform's upgrade installer uses the higher privileged database account to execute the queries automatically during the upgrade.

This enables enterprise services that depend on Venafi products as part of their pipeline to remain online during Venafi product upgrades. For example, if you have a customer-facing website that spins up web server nodes dynamically according to traffic demands, you may be injecting TLS certificates that are generated on demand from Venafi TLS Protect as part of the build pipeline. This process can continue to function during a Venafi server cluster upgrade because one or more servers remain online throughout the upgrade process.

Supported upgrade models

There are three supported models for upgrading to 24.3.

  • In place rolling upgrade. When using this upgrade model, you will remove one server at a time from the application delivery controller, upgrade it, and then replace it in the application delivery controller before upgrading the next server. This model requires both redundancy (i.e. all services the cluster provides are provided by at least two servers) and an application delivery controller (so the network traffic can be directed to the online servers while the offline server is being upgraded). This upgrade model results in no outage. This process takes significantly longer than offline upgrades. It also requires multiple configuration changes to the application delivery controller settings throughout the upgrade process. During the upgrade, you need to wait until there are no active connections on the ports that Venafi services before you can perform the upgrade on that Venafi server. For information on the steps for this upgrade model, see In place rolling upgrade.

  • Replace rolling upgrade. With this upgrade model, you will deploy new Windows servers. After Trust Protection Platform is installed and running on those servers, you will join them to the application delivery controller for the cluster. Finally, you will decomission the servers with the older version of Trust Protection Platform. This model requires you to deploy one new server for each existing server. For example, if you have six Venafi servers on your origin version (that you are upgrading from), you would need to deploy six new Windows servers for the target version, each one matching exactly the configuration of the server it will replace (including Venafi components, processing engine assignments, and network discovery zones).

    This model can often result in a cleaner upgrade process, and allows you to upgrade your Windows operating system at the same time you are upgrading your Venafi version, but results in extra manual configuration or steps that need to be scripted. For more information on the steps for this upgrade model, see Replace rolling upgrades.

  • Offline upgrade. (Not a rolling upgrade) In this model, you take down the entire Venafi server cluster at the same time. You turn off all services on all servers simultaneously. This causes an outage of Venafi service, but allows the upgrade to happen much faster. This model is often suitable for environments that have lower uptime requirements. This model is the only upgrade model that was supported in 19.4 and earlier. For more information on the steps for this upgrade model, see Offline upgrade.

Review each model, and determine which model you will use for your upgrade, as this decision impacts how you will proceed with the upgrade.

What's required

While there are many benefits of rolling upgrades , they take more time, configuration and infrastructure than an offline upgrade. To use a rolling upgrade model, you will need to meet the following requirements:

  • Server role redundancy. While this is already identified in the system requirements, it is important to evaluate if your cluster meets this requirements. Look at the servers you have in the cluster, what roles they have, and what network segments each server is servicing.

    For example, if you have four isolated network segments, and in each segment you have a single Venafi server that is used for discovery, validation, and certificate installation for the TLS Protect product, services in those network segments would be unavailable during an upgrade unless additional Venafi servers were brought online to cover those segments. For this example, you might consider the Replace Rolling Upgrade model, as the redundancy is only required during the upgrade process.

    If redundancy for fault tolerance is important to your organization's overall high availability requirements, you should consider deploying additional servers to each isolated network segment permanently.

  • Application delivery controller. All Venafi web services should be made available to clients through an application delivery controller (load balancer). This requirement allows one or more servers in the resource pool to be offline while still providing access through the same web service endpoint.

    Typically in either rolling upgrade model changes to the application delivery controller configuration are required during the upgrade to ensure new client connections are not routed to a server that is involved in an upgrade.