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

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.

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/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 setup a new log collector.

    You do not need to upgrade the log collector.

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

To upgrade CloudCenter deployments from CloudCenter 4.6x or 4.7.x, contact the CloudCenter Support team.

  • No labels
© 2017-2019 Cisco Systems, Inc. All rights reserved