Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Upgrading Contrail Service Orchestration Overview

 

If your installed version is Contrail Service Orchestration (CSO) Release 3.2.1 or later, you can use a script to upgrade to CSO Release 4.1.0.

Caution

The upgrade process supports n–1 release upgrade approach. For example, if you have CSO Release 3.3 and you intend to upgrade it to CSO Release 4.1.0, you must first upgrade to CSO Release 4.0.2 and, then follow the same steps to upgrade to CSO Release 4.1.0.

We recommend that you take snapshots of your current VMs before you proceed with the upgrade process.

You can roll back to the previous CSO release if the upgrade is unsuccessful, provided you have taken snapshots of the VMs.

To upgrade to CSO Release 4.1.0, you must run the scripts that are available in the Contrail_Service_Orchestration_4.1.0.tar.gz file in the following order:

  1. upgrade.sh— This script upgrades CSO software to Release 4.1.0. The upgrade.sh script, puts CSO in maintenance mode, takes a snapshot of all the VMs so that you can roll back to the previous release if the upgrade fails (optional), upgrades all microservices and infrastructure components, if required, performs health checks at various levels, validates if all the VMs, infracomponents, and microservices are up and running, and then puts the CSO in live mode.

    Note

    Before you upgrade ensure that all ongoing jobs are stopped; otherwise, the upgrade process will fail. During the upgrade, you experience a downtime as CSO goes into maintenance mode.

  2. revert.sh— Run this script only if the upgrade fails and if you have taken a snapshot of all VMs. This script reverts to the previously installed version.

Upgrade to CSO Release 4.1.0 is independent of the deployment type (HA and non- HA), environment type (small, medium or large), infrastructure components and microservices used, and the hypervisor type (KVM or VMware ESXi).

To ensure a smooth upgrade, the scripts perform a number of health checks before and after the upgrade. Health checks are performed to determine the operational condition of all components, the host, and VMs. If there is an error during the health check, the upgrade process is paused. You can rerun the script to rectify the error that you encounter.

Following are the types of health checks that are performed:

  • Component health checks—Checks the operational condition of the infrastructure components.

  • System health checks—Checks the following parameters of VMs and the host machine.

    • Available space on the host machine and VMs.

    • Operating System (OS) version of the host machine and VMs.

    • Kernel version of the host machine and VMs.

    • Disk space on the host machine and VMs.

Limitations

Note

The upgrade process is applicable to CSO Release 3.2.1 and later.

Upgrade to CSO Release 4.1.0 has the following limitations:

  • There are no changes to the device image or device configurations.

  • Upgrade cannot be performed through the GUI.

  • CSO Release 4.1.0 allows to separate OS and Data partitions for CSO deployments. This feature is not applicable for upgrades.

Impact of the CSO Upgrade

Table 1 describes the impact of the CSO upgrade to Release 4.1.0.

Table 1: Impact of the CSO Upgrade

Feature

After the Upgrade

Security Management

  • Release 4.1.0 security management-related features are supported on devices that are onboarded in Release 4.0.x or Release 3.3.x.

SD-WAN

  • For the Application Visibility feature, the trend data is reset after the upgrade. You can access the Release 3.2.1 trend data through the REST APIs.

  • The Application Quality of Experience (AppQoE) feature works only for the tenants that you create in Release 4.1.0. For more information on AppQoE, see Application Quality of Experience (AppQoE) Overview in the Contrail Service Orchestration User Guide.

  • Device Management functions work for Release 3.3.1 or later sites.

Cloud CPE

  • All functionalities of centralized and distributed deployments continues to work on Release 4.1.0 sites or devices that are onboarded in Release 3.3.1 or later.

  • Multi-region support for centralized deployment is not supported on Release 4.1.0 sites or devices that are onboarded in Release 3.3.1.

  • Device Management functions work for Release 4.1.0 sites.

  • High availability (HA) for VRRs is not supported for sites that are created in Release 3.2.1.

Related Documentation