Upgrading Cisco Elastic Services Controller

Cisco Elastic Service Controller supports two type of upgrades:

  • Backup and Restore Upgrade: This upgrade process involves stopping the ESC keepalive daemon (for ESC HA), backing up the database, stopping and renaming (or deleting) the ESC instances, re-installing the ESC instances, and restore database. For information on the supported ESC versions for ESC 6.0 upgrade, see the table below.

You can upgrade the ESC instance as a standalone instance or as a high availability pair. The upgrade procedure is different for standalone and high availability pair.

This chapter lists separate procedures on how to upgrade ESC standalone and ESC High Availability instance. You must review these instructions before you decide to upgrade the ESC instance. See the Installation Scenarios for more information on the installation scenarios.

  • ESC only support direct upgrade from previous two minor releases. For example, ESC 6.0 will support direct upgrade from ESC 5.10 and ESC 5.9. For any release older than the supported versions for direct upgrade, you need to perform the staged upgrade.

    Note

     

    Example of an ESC major release, ESC 3.x, ESC 4.x,and ESC 5.x

    Example of an ESC minor release, ESC 5.1.x and ESC 5.4.x

    Example of an ESC maintenance release, ESC 5.4.0.x and 5.4.1.x;

    Example of an ESC patch release, ESC 5.4.0.88, ESC 5.4.0.89, and ESC 5.4.0.100.

  • For ESC upgrade, you should be familiar with ESC installation process.

    • For OpenStack, refer to the OpenStack installation procedures, see Chapter 4: Installing Cisco Elastic Services Controller in OpenStack.

    • For VMware, refer to the VMware Installation installation procedures, see Chapter 7: Installing Cisco Elastic Services Controller in VMware vCenter.

    • For ESC HA, please refer to the ESC HA installation procedures, see Chapter 5 : Configuring High Availability for OpenStack and Chapter 8: Configuring High Availability for VMware.

Table 1. Supported ESC Versions for Upgrading to ESC 6.0

Virtual Infrastructure Manager

Supported Versions for Backup and Restore Upgrade

Supported Versions for In-Service Upgrade

OpenStack, KVM

5.10, 5.9

In Service Upgrade is not supported from 5.x to 6.0 due to Base Operating System change.

VMware, vCD

5.10, 5.9

 In Service Upgrade is not supported from 5.x to 6.0 due to Base Operating System change.

IMPORTANT NOTES

  • After upgrading to the new ESC version, ESC service will manage the life cycle of all VNFs deployed in the previous release. To apply any new features (with new data models) to the existing VNFs, you must undeploy and redeploy these VNFs.

  • Upgrade is supported for Active/Active HA only.


Note

Do not change the VIP in ESC upgrade in ETSI deployment.

If you change ETSI's REST schema, from http to https in-flight, ESC stops sending recovery notification from ESC core for any existing deployment.

Upgrading Standalone ESC Instance

To upgrade standalone ESC instance, perform the following tasks:

  1. Back up the ESC database. For more information, see Backup the Database for ESC Standalone Instance.


    Note

    To backup any custom scripts used by the deployments, and for restoring them before restoring the database, you must re-install the scripts on the backup as well.

  2. Redeploy the ESC instance. For more information, see the below section, Deploy the ESC for Upgrade.

  3. Restore the ESC database on the new ESC instance. For more information, see the below section, Restoring the ESC Database.

Deploy the ESC for Upgrade

After backing up and shutting down of the old ESC VM, a new/upgraded (based on new ESC package) ESC VM should be installed. All parameters for ESC installation should be the same as the old ESC VM deployment.
  • For OpenStack, you need to register the new ESC qcow2 image using the Glance command with a new image name and then use new bootvm.py script and new image name to install ESC VM.

    Note

    In OpenStack, if an old ESC VM was assigned with floating IP, the new ESC VM should be associated with the same floating IP after the installation.

  • For VMWare, you need to use the new ESC OVA file to install ESC VM. All other configurations and property values should be the same as the old VM.

Restoring the ESC Database

Restore the ESC database on the new ESC instance , using the following procedure:

Procedure

Step 1

Connect to the new ESC instance using SSH. 

$ ssh USERNAME@NEW_ESC_IP

Step 2

Stop the ESC service. 

$ sudo escadm stop

Step 3

Check ESC service status to make sure all the services are stopped. 

$ sudo escadm status

Step 4

Restore the database files. 


$ scp://<username>:<password>@<standby_ip>:<filename>
$ sudo escadm restore --file /path/where/file/scp-ed/to/db.tar.bz2

Step 5

Start the ESC service: 

$ sudo escadm start

After ESC service is started, the standalone ESC upgrade is complete. You can check the health of the new ESC service by running $ sudo escadm status in the new ESC VM.

Step 6

In Openstack, after restoring the database successfully, delete the old ESC instance: 

$ nova delete OLD_ESC_ID

Important Notes:

After upgrading to the new ESC version, ESC service will keep doing life cycle management of all VNFs deployed by the old version. However, to apply any new features (with new data models) to the VNFs deployed by the ESC with old version is not guaranteed. If you want to apply any new feature of the new ESC version to existing VNFs, you have to undeploy and redeploy those VNFs.

Upgrading ESC HA Active/Standby Instances

To upgrade ESC HA Active/Standby nodes, perform the following tasks:

  1. Back up the database from an old ESC HA Active/Standby active instance. For more information, see Backup the Database from the ESC HA Active/Standby Instances.


    Note

    To backup any custom scripts used by the deployments, and for restoring them before restoring the database, you must copy the scripts on the backup as well.

  2. Deploy new ESC HA Active/Standby nodes based on new ESC version. For more information, see the below section, Deploy the ESC HA Active/Standby nodes for Upgrade.

  3. Restore the database on active ESC instance (Standby ESC instance will sync with the active ESC instance ). For more information, see the below section, Restoring the ESC Database on New Active and Standby Instances.

Deploying the ESC HA Active/Standby nodes for Upgrade

After backing up and shutting down the two old ESC VMs, based on new ESC package install the new ESC VMs.
  • For OpenStack, you need to register the new ESC qcow2 image using the Glance command with a new image name and then to use new bootvm.py script and new image name to install ESC VM. All other bootvm.py arguments should be the same as used to setup an old VMs.
  • For VMWare, there are two steps to bring up HA Active/Standby pair in VMware: 1) setup two standalone instances 2) reconfigure each instance with HA Active/Standby info. All other configurations and property values should be the same as the old VMs.
  • If VIP is used for Northbound access, keep VIP the same for the new deployment as used to reconfigure the old HA Active/Standby pair.

Restoring the ESC Database on New Active and Standby ESC Instances

Procedure

Shut down the Standby ESC instance.

Step 1

Connect to the standby ESC instance using SSH. 

$ ssh USERNAME@ESC_STANDBY_IP

Step 2

Verify that the ESC instance is standby and note the name of the standby ESC HA Active/Standby instance : 

$ sudo escadm status

If the output value shows "STANDBY", the node is the standby ESC node.

Note

 

If a dynamic mapping file (dynamic_mapping.xml) is used by ESC service, the dynamic mapping file should be restored into the standby ESC VM. Before power off the standby ESC node, you need to copy the backup dynamic mapping file (dynamic_mapping.xml) to the path /opt/cisco/esc/esc-dynamic-mapping/ .

Step 3

Shutdown the standby ESC instance through OpenStack Kilo/Horizon using Nova command. For ESC VM instances based in VMware vSphere, shutdown the active instance through VMware client dashboard. An example of shutting down the standby ESC instance in OpenStack is shown below: 

$ nova stop NEW_ESC_STANDBY_ID

Restore the database on the new Active ESC instance.

Step 4

Connect to the active ESC instance using SSH. 

$ ssh USERNAME@ESC_ACTIVE_IP

Step 5

Verify that the ESC instance is active. 

$ sudo escadm status

If the output value shows 'ACTIVE' , the node is the active ESC node.

Step 6

Stop the ESC services on the active node and verify the status to ensure the services are stopped. 


$ sudo escadm stop
$ sudo escadm status

Step 7

Restore the database files. 


$ sudo escadm restore --file /tmp/db.tar.bz2
$ scp://<username>:<password>@<standby_ip>:<filename>

Note

 

If a dynamic mapping file (dynamic_mapping.xml) is used by ESC service, the dynamic mapping file should be restored into the ESC VM. Before starting the ESC node, you need to copy the backup dynamic mapping file (dynamic_mapping.xml) to the path /opt/cisco/esc-dynamic-mapping/.

Step 8

Reboot the VM to restart the full ESC service: 

$ sudo escadm restart

Step 9

Use the $ sudo escadm status to check the status of the ESC service.

Step 10

Start the standby ESC node.

Power on the standby ESC node through OpenStack Nova/Horizon or VMware client. After starting the standby node, ESC HA Active/Standby upgrade process should be complete.

Step 11

Delete the old HA Active/Standby instance through OpenStack Nova/Horizon or VMware client. An example of deleting the VM on OpenStack is shown below: 

$ nova delete OLD_ESC_ACTIVE_RENAMED OLD_ESC_STANDBY_RENAMED

Upgrading VNF Monitoring Rules

To upgrade the VNF monitoring rules, you must back up the dynamic_mappings.xml file and then restore the file in the upgraded ESC VM. For more information, see the backup and restore procedures. For upgrade of HA Active/Standby instance, see Upgrading HA Active/Standby instance. For upgrade of the standalone instance, see Upgrading Standalone instance.