Upgrade Overview

Overview

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.

Installer Jars
java -jar <component>-installer.jar <component>-response.xml

CentOS Linux Security Vulnerabilities Addressed in CloudCenter 4.10.0.6

CloudCenter 4.10.0.6 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 4.10.0.6 includes a new os_upgrade option for the core_upgrade.bin file.

  • Use the os_upgrade option each time you upgrade to CloudCenter 4.10.0.6.

  • 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.

    ./core_upgrade.bin centos7 vmware os_upgrade
  • 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 4.10.0.6.

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:

  • Log Monitor

  • PostgreSQL

  • Load Balancer

In these cases, you must follow this one-time procedure before upgrading:

  1. Update /etc/sysctl.conf with the following values:

    net.ipv4.ipfrag_low_thresh=196608
    net.ipv4.ipfrag_high_thresh=262144
    net.ipv6.ip6frag_low_thresh=196608
    net.ipv6.ip6frag_high_thresh=262144
  2. To persist the settings, execute the following command.

    sysctl -p

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:

FromNotes
CloudCenter 4.9.1

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 4.10.0.7, note the following:

  • The core_upgrade.bin command is needed to upgrade OS packages and RabbitMQ to 4.10.0.6 and must be run for all components.

  • The MongoDB upgrade is separate from the CCO upgrade. After the core_upgrader.bin command is run with cco  option for upgrading CCO, a new option “mongo” must be run to update the MongoDB.

CloudCenter 4.9.0.1
CloudCenter 4.9.0
CloudCenter 4.8.2.1
CloudCenter 4.8.2
CloudCenter 4.8.1
CloudCenter 4.8.0
CloudCenter 4.7.3
./core_upgrade.bin <os> <cloud> <component>

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.

  1. REPO

    Skip this section if:

    1. You do not use custom REPO servers in your CloudCenter setup.

    2. You are only using the Bundle Store (Conditional)

  2. Bundle Store

    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.

  3. MGMTPOSTGRES/MGMTPOSTGRES_SLAVE/STOP_SLAVE/MGMTPOSTGRES_MASTER

    If you are upgrading from CloudCenter 4.8.2x or 4.9.x, you do not need to upgrade the PostgreSQL database VMs.

  4. CCM/CCM_SA/CCM_SA_PRIMARY/CCM_SA_SECONDARY

    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.

  5. AMQP/AMQP_PRIMARY/AMQP_SECONDARY

  6. CCO/CCO_PRIMARY/CCO_SECONDARY/CCO_TERTIARY

    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
  7. MONITOR/LOG_COLLECTOR

    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 4.10.0.7, use the following command to upgrade the log collector:

    ./core_upgrade.bin <os> <cloud> logcollector
  • Appliance jars are only applicable to the CCM, CCO, and AMQP components.

  • See Virtual Appliance Overview to understand roles and modes.

  • The CCM server requires additional memory for the changes in the underlying architecture – See Hardware Requirements for details.

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.

Upgrade MongoDB

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:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

The output must be as follows:

{ "featureCompatibilityVersion" : "4.0", "ok" : 1 } 



  • No labels
Terms & Conditions Privacy Statement Cookies Trademarks