This section provides details on the nuances for the CloudCenter platform and provides important tips on how to proceed with your upgrade.
The Appliance Jar Files
Upgrading the CloudCenter version generally requires only one step – to run the latest appliance jar files on each component.
CentOS Linux Security Vulnerabilities Addressed in CloudCenter 22.214.171.124
CloudCenter 126.96.36.199 includes updates to the operating system to address some security vulnerabilities that were found in an older version of CentOS 7 Linux kernel (that are currently shipped for CloudCenter 4.10.0 releases).
You must update these OS/kernels using the new core-upgrade binary files (downloadable from software.cisco.com) to address these vulnerabilities.
CloudCenter 188.8.131.52 includes a new os_upgrade option for the core_upgrade.bin file.
Use the os_upgrade option each time you upgrade to CloudCenter 184.108.40.206.
The core_upgrade file and the os_upgrade option only work for CentOS 7 operating systems and fetches the latest CentOS 7 version and kernel packages.
The os_upgrade option is not available for any other operating systems.
You must run the following command to complete any upgrade to CloudCenter 4.10.0.x.
The core_upgrade.bin file now contains these new options. You must restart the host for the updates to take effect. Perform the upgrade in the following order:
Upgrade the core_upgrade.bin file to use the new os_upgrade option
Restart the host.
Upgrade to RabbitMQ Version 3.6.16 which is available in CloduCenter 220.127.116.11.
Security Hardening Requirements
As a one-time task for all OS configurations, you must tighten the security configuration for all components used by the CloudCenter platform to ensure security compliance. When a component uses the *.jar, file, this security requirement is already handled by the component upgrade file. The following components do not use the *.jar file at upgrade time:
In these cases, you must follow this one-time procedure before upgrading:
Update /etc/sysctl.conf with the following values:
To persist the settings, execute the following command.
The Core Upgrade File
In releases involving security patches, upgrade of software packages and addition or change of software packages to a component would require an additional step to run core upgrade binary file.
In these cases, run this additional step – you must run the core upgrade binary file before running the appliance jars.
The core upgrade file is available for all releases. When you run this file, the CloudCenter platform performs a version check and automatically exits – if the core upgrade file is not required for your CloudCenter version.
If you are upgrading to CloudCenter 4.10x from one of the following releases:
Run the core_upgrade.bin command – you will see the message that is highlighted in the following image – if an upgrade is not required for this component! Depending on which release you upgrade from, you may or may not need this file.
When upgrading to CloudCenter 18.104.22.168, note the following:
HA Upgrade Tips
You must reconfigure the IP address for each load balancer after each HA upgrade. See High Availability Best Practices > Load Balancer Requirements for additional details.
Upgrading to CloudCenter 4.10 in HA Mode
When upgrading CCOs in HA mode, you MUST stop all the CCOs and then start them again. See Upgrade CCO for additional context.
Component Upgrade Order
Upgrade each CloudCenter component in the following order.
See Virtual Appliance Overview to understand components, modes, and roles.
Skip this section if:
You do not use custom REPO servers in your CloudCenter setup.
You are only using the Bundle Store (Conditional)
Skip this section, if you do not use a custom Bundle Store in your CloudCenter setup.
In all other cases, you must upgrade the Bundle Store as this component is not automatically updated by the CloudCenter platform – EVEN IF the bundle store and the REPO appliance were configured on the same server. This upgrade must be performed manually.
If you are upgrading from CloudCenter 4.8.2x or 4.9.x, you do not need to upgrade the PostgreSQL database VMs.
If you are upgrading from CloudCenter 4.8.2x or 4.9.x, you do not need to exchange the SSH keys for CCM HA environments.
As a one-time task for all OS configurations, you must tighten the security configuration for the PostgreSQL database and the load balancer to ensure security compliance. See the Security Hardening Requirements section above for additional context.
If you are migrating your environment to ensure tagless governance, you must use the CloudCenter 4.10.0 ccm-response.xml file to upgrade to CloudCenter 4.10.0. See Migrate to Tagless Governance for additional context.
As a one-time task for all OS configurations, you must tighten the security configuration for the load balancer to ensure security compliance. See the Security Hardening Requirements section above for additional context.
If your environment uses a Docker image, be sure to upgrade the Docker image on the CCO server by running the following command:
./core_upgrade.bin <os> <cloud> docker
As a one-time task for all OS configurations, you must tighten the security configuration for the log monitor to ensure security compliance. See the Security Hardening Requirements section above for additional context.
The CloudCenter platform converts the Monitor component to the LOG_COLLECTOR as part of the upgrade process – you do not need to delete the monitor instance and set up a new log collector.
You do not need to upgrade the log collector. In CloudCenter 22.214.171.124, use the following command to upgrade the log collector:
If you upgrade from 4.9 to 4.10, you must upgrade CCM, MGMTPOSTGRES, CCO, and AMQP in the same maintenance window. If you upgrade from a 4.10 maintenance release and if you plan to upgrade in different maintenance windows, upgrade the following components in the same maintenance window:
MGMTPOSTGRES and CCM
AMQP and CCO for a region
To upgrade CloudCenter deployments from CloudCenter 4.6x or 4.7.x, contact the CloudCenter Support team.
See Upgrade CCO for additional details.
All nodes are in version 4.0.17. You can confirm by running following command on the mongo shell on each node:
The output must be as follows:
- No labels