Page History

3. Reboot all CloudBoot compute resources.

Anchor
migrate migrate

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 terminal to display the list of compute resources with their IP addresses. Make a note of the list of IPs:

   Code Block
   CP_host#> liveUpdate listHVs

   This command will also show whether compute resources are eligible for live upgrade.

   Info
   If the command liveUpdate is not available then it may be located in the sbin directory instead (cd /usr/local/sbin).

2. Run the following command for every compute resource:

   Code Block
   CP_host#> liveUpdate updateToolstack <HV IP Addr>

   Once all the toolstacks are updated run the following command for every compute resource: 

   Code Block
   CP_host#> liveUpdate refreshControllers <HV IP Addr>

   Info

   Wait several minutes for all degraded disks to come to synchronized state. The synchronization will take approximately three minutes for each compute resource. After each controller restart, check for any issues on the backup server (or on one Compute resource from each zone): 1. Log on via SSH to the backup server (or Compute resource). 2. Run getdegradednodes from the SSH console. 3. Run getdegradedvdisks from the SSH console.

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

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

5. Click the AppliancesCompute Resources icon.

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

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

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

   
   

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

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

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

10. Once the compute resource is booted, repair the disk that were degraded during the reboot.

    1. Make sure no disks are out of sync. To do so, check the Diagnostics page in CP at Dashbord > Integrated Storage > Compute zonelabel > Diagnostics. Alternatively, log into a compute resource and run the command below: 
       

       Code Block
       HV_host#> getdegradedvdisks

    2. Repair all the degraded disks before proceeding to the upgrade process. To do so, log in to your CP and go to Integrated Storage > Compute zonelabel > Diagnostics page. Alternatively, run one of the following commands:

       Code Block
       HV_host#> onappstore repair uuid=

       Code Block
       HV_host#> parallelrepairvdisks

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

Anchor
live live

Live Upgrade

Use this procedure to upgrade without rebooting your servers:

1. Make sure no disks are out of sync. To do so, check the Diagnostics page in CP at Dashbord > Integrated Storage > Compute zonelabel > Diagnostics. Alternatively, log into a compute resource and run the command below: 
   

   Code Block
   HV_host#> getdegradedvdisks

2. Repair all the degraded disks before proceeding to the upgrade process. To do so, log in to your CP and go to Integrated Storage > Compute zonelabel > Diagnostics page. Alternatively, run one of the following commands:

   Code Block
   HV_host#> onappstore repair uuid=

   Code Block
   HV_host#> parallelrepairvdisks

3. Run the following command from the CP server to stop the OnApp service:

   Code Block
   CP_host#> service onapp stop

4. Stop the Apache server:

   Code Block
   CP_host#> service httpd stop

5. Make sure to update CloudBoot packages before proceeding to the following steps.

6. Run the following command from the Control Panel server terminal to display the list of compute resources with their IP addresses. Make a note of the list of IPs:

   Code Block
   CP_host#> liveUpdate listHVs

   This command will also show whether compute resources are eligible for live upgrade.

   Info
   If the command liveUpdate is not available then it may be located in the sbin directory instead (cd /usr/local/sbin).

7.  Run the following command for every compute resource:

   Code Block
   CP_host#> liveUpdate updateToolstack <HV IP Addr>

   Once all the toolstacks are updated run the following command for every compute resource: 

   Code Block
   CP_host#> liveUpdate refreshControllers <HV IP Addr>

   Info

   Wait several minutes for all degraded disks to come to synchronized state. The synchronization will take approximately three minutes for each compute resource. After each controller restart, check for any issues on the backup server (or on one Compute resource from each zone): 1. Log on via SSH to the backup server (or Compute resource). 2. Run getdegradednodes from the SSH console. 3. Run getdegradedvdisks from the SSH console.

8. Restarts the storage controllers. This command can be performed later at a more suitable time. 
   Run the following command for each compute resource in turn:

   Code Block
   CP_host#> liveUpdate restartControllers <HV IP Addr>

   Note
   Please make sure you restart all controllers and don’t leave your cloud in a partially updated state for too long. Note that when operating in LiveUpdated mode (e.g. with the tool stacks updated but before you have performed the controller restart) you cannot use disk hot plug.

   Info
   After each controller restart check for any issues on the backup server or one Hypervisor from each zone: 1. Log on via SSH to the backup server (or Hypervisor). 2. Run getdegradednodes from the SSH console. 3. Run getdegradedvdisks from the SSH console. If there are any issues seen please rectify them before continuing with the next controller restart.

9. Make sure that the package versions are upgraded by running the following command on each compute resource:

   Code Block
   HV_host#> cat /onappstore/package-version.txt | grep Source

10. Start the Apache server:

    Code Block
    CP_host#> service httpd start

11. Start the OnApp service:

    Code Block
    CP_host#> service onapp start

Configuration for Accelerator

Perform the following steps for your Cloudboot compute resources if you plan to deploy Accelerator. These steps are to be performed on each of the compute resources.

1. Copy file:

   Code Block
   cp /home/mq/onapp/messaging/credentials{_example,}.yml

2. Open vi /home/mq/onapp/messaging/credentials.yml and check the following details:

   Code Block
   --- 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

3. Change owner:

   Code Block
   chown -R mq:mq /home/mq

4. Run the following:

   Code Block
   service onapp-messaging start

   Note

   Note that steps 1-4 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: Code Block 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.