Upgrade Cloud with CloudBoot Servers (6.2 Edge 1/2 to 6.2)

This guide provides a walk-through on how to upgrade from OnApp Cloud 6.2 Edge 1 or 6.2 Edge 2 to 6.2 for a cloud where all servers are CloudBoot. Please follow the complete procedure of the upgrade process. All the packages (Control Panel and CloudBoot compute resources) must belong to the same major version to ensure the best performance of your cloud.

If you are using Integrated Storage, you need to upgrade all nodes in your IS data store. Otherwise, your functionality in this data store will be limited and the following actions unavailable:

  • create VDisk
  • repair membership
  • add/delete nodes from datastore
  • assign/unassign disks in Manage devices menu
  • rebalance VDisk

Upgrade Control Panel Server

To upgrade the Control Panel server, follow the procedure at Upgrade Guide for Control Panel Server

Upgrade CloudBoot Packages

Before you begin:

  • Create a backup of the /tftpboot directory in case the storage packages rollback is needed.
  • Power off Windows virtual servers before proceeding to the following procedures.
  • Make sure to run all the commands on the Control Panel host.

To upgrade the OnApp Storage packages:

  1. Update the following packages:

    # yum update onapp-ramdisk-centos6-xen
    # yum update onapp-ramdisk-centos6-kvm
    # yum update onapp-ramdisk-centos7-xen
    # yum update onapp-ramdisk-centos7-kvm
    # yum update onapp-ramdisk-centos7-default

    After the packages installation, go to the Control Panel > Settings menu > Configuration and click the Save Configuration button.

  2. Run the script:

    # /onapp/onapp-store-install/onapp-store-install.sh

    When running in the interactive mode, enter the required information.

    Be aware that the disk-less nodes password is the root password for the CloudBoot compute resources. By default it is blank.

Upgrade CloudBoot Backup Servers

Make sure to update CloudBoot packages on your Control Panel server before proceeding to the upgrade of CloudBoot backup servers.

CloudBoot backup servers are CloudBoot KVM compute resources that can be used as backup servers. The CloudBoot backup server upgrade procedure is almost the same as the CloudBoot compute resource upgrade. Follow the instructions provided in this section to upgrade CloudBoot backup servers in your cloud.

Once you have upgraded the CloudBoot dependencies, you have to reboot your CloudBoot compute resource to update the Cloud Boot RPM. You do not need to perform any backup server upgrade operations using console.

To do so:

  1. Go to your Control Panel Settings > Compute Resources menu.

  2. Click the label of the CloudBoot compute resource the backup server is based on.

  3. On the compute resource details screen, click the Actions button, then click Reboot Compute resource.

  4. A new screen will open asking for confirmation before reboot:

    • Are you sure you want to reboot this compute resource? Confirm that you want the compute resource to reboot.

  5. When you're certain you want to proceed with the reboot, click the Reboot button.

  6. Repeat these steps for all CloudBoot backup servers in your cloud.

  7. Once all are rebooted, proceed to CloudBoot compute resources upgrade.

Upgrade CloudBoot Compute Resources

Depending on the infrastructure, scale and needs of your cloud we suggest the following methods of upgrading CloudBoot compute resources:

Simple Reboot

This method is the simplest method technically. It also ensures all tools are updated. However, it will result in some limited downtime
(its duration depends on how many virtual servers are running on each compute resource).

Migrate and Reboot

For Xen only the cold migrate option is available.

This method involves migrating all virtual servers off each CloudBoot compute resource in turn.
The compute resource can then be safely rebooted, picking up the upgraded Integrated Storage and CloudBoot packages. 
Virtual servers that do not support hot migrate will have to be stopped.

In case you have applied any custom configuration to your CloudBoot servers, it is recommended to recheck that this customization does not break new cloud boot image version. For this, reboot a compute resource and run Storage Health Check and Network Health Check. Make sure that Vdisks hosted on a compute resource are redundant and healthy before rebooting a CloudBoot compute resource.

For more information about upgrade scenarios, refer to the OnApp Integrated Storage.

If you are using the auto healing functionality for Integrated Storage, make sure to disable it before an upgrade.

Simple Reboot

If you are using Xen compute resources, we recommend to reboot them only from the Control Panel interface. 

Follow the below procedure to upgrade the CloudBoot compute resources with reboot:

1. Upgrade CloudBoot Packages.

2. When the CloudBoot packages upgrade is complete, stop all virtual servers which reside on the CloudBoot compute resources.

3. Reboot all CloudBoot compute resources.

Once the compute resources are booted, the upgrade is complete. Before starting all Virtual Servers please ensure that the diagnostics page does not report any issue. In case of any issue, please click repair button to resolve it, then continue with starting Virtual Servers.

Note that virtual servers cannot be stopped simultaneously, but must be stopped in sequence. This can result in considerable downtime if there are a large number of virtual servers.

Migrate and Reboot

Use this procedure if you prefer migrating all virtual servers to another compute resource and conducting overall upgrade of your CloudBoot and Integrated Storage. Virtual servers that do not support hot migrate will have to be stopped.

Once you have upgraded the CloudBoot packages, you have to reboot your CloudBoot compute resources to update them.

To do so:

  1. Run the following command from the Control Panel server to connect via SSH to compute resources:

    CP_host# liveUpdate listHVs

    If there is an unknown host, a dialog box appears for you to confirm that the Control Panel server can connect to the host. To allow the Control Panel server to connect to unknown hosts without your confirmation, run liveUpdate listHVs  with the -nc option as follows:

    CP_host# liveUpdate listHVs -nc

    Ensure that you can trust all the unknown hosts before you run liveUpdate listHVs  with the -nc option.

    If the command liveUpdate is not available, then the list of available compute resources may be located in the sbin directory instead (cd /usr/local/sbin).

  2. Migrate all the virtual servers from the CloudBoot compute resource to another compute resource. Follow the instructions described in the Migrate Virtual Server section of the Admin guide to migrate virtual servers.

  3. After that, go to your Control Panel Settings menu.

  4. Click the Compute Resources icon.

  5. Click the label of the CloudBoot compute resource you have migrated all VSs from.

  6. On the compute resource details screen, click the Actions button, then click Reboot Compute resource.

    Rebooting a compute resource assigned to a data store with a single replica (single-replica compute resource) or degraded virtual disks may result in data loss.

  7. A new screen will open asking for confirmation (via two check boxes) before reboot:

    • Stop all virtual servers that cannot be migrated to another compute resource? Check this box if you want VSs that cannot be migrated to be powered off. When a compute resource is scheduled for a reboot, OnApp will first attempt to hot migrate all VSs it hosts. If hot migration is not possible for a VS, OnApp will attempt to cold migrate that VS. With this box checked, if cold migration fails, the VS will be stopped so the reboot may proceed. If you don't check this box, OnApp will attempt to hot and then cold migrate all VSs hosted by the compute resource being rebooted – but will stop the migration process if any VS cannot be migrated.
    • Are you sure you want to reboot this compute resource? A simple confirmation to confirm that you want the compute resource to reboot.

      Before the reboot, please ensure that all vdisks are fully synced and redundant. If some of them are not fully synced, the virtual server, that is owner of a degraded (or non-redundant) vdisk, can loose access to the vdisk. It can be manifested as IO errors during writes or reads to/from the vdisk inside the virtual server.

  8. When you're certain you want to proceed with the reboot, click the Reboot button.

  9. Repeat these steps for all CloudBoot compute resources in your cloud.

Local Read Policy

Enabling Local Read on a compute zone ensures that a locally stored copy of data will always be used for reads. This significantly reduces read latency and improves overall storage performance by reducing load on a SAN network. However, in order to use this policy, every compute resource must have sufficient physical drives to be able to store the number of stripes specified in the data store. For example, in a 2R4S data store, there must be at least four physical disks on the compute resource to use Local Read.

Changes to Local Read Policy Enforcement

Originally, when this policy was introduced, OnApp did not enforce the requirement for the minimum number of drives. Consequently, some users who set the policy, having insufficient drives may see the following error message:

Fatal: OnApp::Actions::Fatal Storage API Call failed: {"result"=>"FAILURE", "error"=>"Local reads have been enabled on the zone - members required per host: 4, required hosts: 2, available hosts: 0"}

The solution is to add additional drives to the compute resource and then add them to the data store or to disable Local Read.