Page tree
Skip to end of metadata
Go to start of metadata

This guide explains how to upgrade OnApp Cloud v4.3 to the v5.0 for the cloud with High Availability configured. If you have configured High Availability using version 4.3 and wish to upgrade to the 5.0 version you need to perform the following procedure to ensure that your system works correctly. Depending on the system you have, you need to upgrade Static compute resources and backup servers, or CloudBoot packages, compute resources and backup servers or both Static and CloudBoot components.

 

On this page:

See also:

Technical Details

Installation Guide for High Availability Clusters

Configure Cloud

5.0 Get Started - installation and upgrade guide for OnApp clouds without High Availability


Search for other docs:

Upgrade Control Panel Servers


 

Run the following commands on all three Control panel servers:

  1. In separate consoles, connect to all three CP servers and run the following command:

    watch /etc/init.d/lsyncd stop

    These processes should be left running while each CP is upgraded and ended before running the last step of this procedure, which is:

    crm resource start lsyncd-cluster



  2. Issue the following command:

    # rpm -Uvh http://rpm.repo.onapp.com/repo/onapp-repo.noarch.rpm
  3. Upgrade the OnApp installer package:

    # yum update onapp-cp-install
  4. Upgrade your server OS components (if required):

    # /onapp/onapp-cp-install/onapp-cp-install.sh -y
  5. Run the Control Panel installer:

    # /onapp/onapp-cp-install/onapp-cp-install.sh
  6. Run the following command on all Control Panel servers one by one:

    #service rabbitmq-server stop
  7. Run the following command on all nodes servers one by one:

    #service rabbitmq-server start

After you have successfully run the previous commands on all Control Panel servers, issue the following two commands on one of the CP servers:

  1. Switch all nodes back online by running the following command once on any of the nodes:

    # crm configure property maintenance-mode=false
  2. Enable file synchronization on all nodes by running the following command once on any of the nodes:

    # crm resource start lsyncd-cluster

Upgrade Static Compute Resources


At first upgrade your static compute resources.

  1. Make sure your compute resource is visible and online in the Control Panel.

  2. Download and install the latest OnApp YUM repository file:

    bash#> rpm -Uvh http://rpm.repo.onapp.com/repo/onapp-repo.noarch.rpm
  3. Upgrade OnApp compute resource installer package:

    yum update onapp-hv-install
  4. Update your server OS components (if required):

    For XEN compute resource:

    bash# /onapp/onapp-hv-install/onapp-hv-xen-install.sh -y

    For KVM compute resource:

    bash# /onapp/onapp-hv-install/onapp-hv-kvm-install.sh -y
  5. Run compute resource installer:
    For XEN compute resource:

    bash# /onapp/onapp-hv-install/onapp-hv-xen-install.sh 

    For KVM compute resource:

    bash# /onapp/onapp-hv-install/onapp-hv-kvm-install.sh

    Reboot XEN compute resource, which is running on CentOS 6.x, after upgrade to 4.4.3 XEN version.


    Perform the following steps if you plan to deploy Accelerator. Otherwise skip.

  6. Copy file:

    cp /home/mq/onapp/messaging/credentials{_example,}.yml
  7. Open vi /home/mq/onapp/messaging/credentials.yml and check the following details:

    ---
    host: 10.0.50.4  # RABBITMQ SERVER IP/FQDN
    port: 5672  	# RABBITMQ CONNECTION PORT(default: 5672)
    vhost: '/'  	
    user: accelerator-example # RABBITMQ USER NAME
    password: 'e{y31?s8l' # RABBITMQ ACCESS PASSWORD
    queue: 'hv-10.0.50.102' # hv-[IP Address of Compute Resource]
    exchange:
      name: 'acceleration'
      type: 'direct'
      durable: True 
  8. Change owner:

    chown -R mq:mq /home/mq
  9. Reboot static compute resources.
    For KVM compute resources only: the kernel package update is a part of "Upgrade Static Compute Resources" default procedure. So reboot is required, if kernel package was upgraded and customer is willing Compute Resource(s) running it (for security reason).

Upgrade Static Backup Servers


After you upgraded static compute resources, proceed to static backup servers upgrade.

  1. Download the OnApp repository:

    bash#> rpm -Uvh http://rpm.repo.onapp.com/repo/onapp-repo.noarch.rpm
  2. Update the package:

    yum update onapp-bk-install
  3. Run the following script:

    bash#>/onapp/onapp-bk-install/onapp-bk-install.sh
  4. Update your server OS components (if required):

    bash#> /onapp/onapp-bk-install/onapp-bk-install.sh -y

 

 

Upgrade CloudBoot Packages


Create a backup of the /tftpboot directory in case storage packages rollback will be needed.

To upgrade the OnApp Storage packages:

  1. Upgrade the repo:

    CP_host#> rpm -Uvh http://rpm.repo.onapp.com/repo/onapp-repo.noarch.rpm
    
  2. Upgrade the packages:

    CP_host#> yum update onapp-store-install
  3. Run the script:

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

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

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

    Perform the following steps if you plan to deploy Accelerator

  4. Restart OnApp service:

    service onapp restart
  5. When the CloudBoot packages upgrade is complete, stop all virtual servers which reside on the CloudBoot compute resources.
  6. 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 press repair button to resolve it, then continue with starting Virtual Servers.

    If after reboot of CloudBoot compute resources you can not create any VSs on these compute resources, run service onapp restart.

  7. Copy file:

    cp /home/mq/onapp/messaging/credentials{_example,}.yml
  8. Open vi /home/mq/onapp/messaging/credentials.yml and check the following details:

    ---
    host: 10.0.50.4  # RABBITMQ SERVER IP/FQDN
    port: 5672  	# RABBITMQ CONNECTION PORT(default: 5672)
    vhost: '/'  	
    user: accelerator-example # RABBITMQ USER NAME
    password: 'e{y31?s8l' # RABBITMQ ACCESS PASSWORD
    queue: 'hv-10.0.50.102' # hv-[IP Address of Compute Resource]
    exchange:
      name: 'acceleration'
      type: 'direct'
      durable: True 
  9. Change owner:

    chown -R mq:mq /home/mq
  10. Run the following:

    service onapp-messaging start

    Note that steps 7-10 of the above instruction should be done after every reboot of CloudBoot compute resource. You can run the following commands (using your parameters) to the custom config instead:

    cp /home/mq/onapp/messaging/credentials{_example,}.yml
    echo "---
    host: 10.0.50.4  # RABBITMQ SERVER IP/FQDN
    port: 5672      # RABBITMQ CONNECTION PORT(default: 5672)
    vhost: '/'
    user: accelerator-example # RABBITMQ USER NAME
    password: 'e{y31?s8l' #RABBITMQ ACCESS PASSWORD
    queue: 'hv-10.0.50.102' # hv-[IP Address of Compute Resource]
    exchange:
      name: 'acceleration'
      type: 'direct'
      durable: True" > /home/mq/onapp/messaging/credentials.yml
    chown -R mq:mq /home/mq
    service onapp-messaging restart

    Also you can monitor RabbitMQ server using a command-line tool for it.

Upgrade CloudBoot Backup Servers


 

Make sure to update CloudBoot packages before proceeding to the upgrade of CloudBoot backup servers.

 

CloudBoot backup servers are CloudBooted KVM compute resources that can be 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 Cloud Boot 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 menu.

  2. Click the Compute resources icon.

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

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

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

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

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

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

Upgrade CloudBoot Compute Resources


Simple RebootThis 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).

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.

If you are using Integrated Storage with caching, please contact support before upgrade.

 

Simple Reboot

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

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels