Upgrading from everRun Release 7.x to 8.x or Higher

Use the instructions in this topic to upgrade the system software from everRun Release 7.x to 8.x or higher. (If you need to upgrade a system already running Release 8.x to a later version of 8.x, go directly to Upgrading everRun Software Using an Upgrade Kit.)

Caution: Consider contacting your authorized Stratus service representative for assistance before upgrading your system from everRun Release 7.x to 8.x. They can help you to evaluate your system, ensure that it meets the prerequisites, locate any potential restrictions, and, if needed, discuss a strategy for the upgrade. If you encounter any problems during the upgrade process, contact your authorized Stratus service representative for assistance as soon as possible to avoid complications and potential data loss.
Prerequisites:

Before upgrading from everRun Release 7.x to 8.x or higher:

  • For the latest information about upgrade paths, restrictions, and special procedures, see the everRun Release 8.0.0.0 Release Notes at http://everrundoc.stratus.com and Knowledge Base article KB0015903 in the Stratus Customer Service Portal. In summary, you can upgrade any everRun Release 7.9.x.x system directly to 8.x or higher. If you are upgrading from a version earlier than Release 7.9.x.x, you need to upgrade to Release 7.9.x.x first.

  • Ensure that each physical node of the everRun system has at least 8 GB of RAM.

  • Ensure that all PMs and VMs are in good health. Examine the everRun Availability Console to verify that there are no alerts indicating PM or VM problems.
  • Eject any VCDs or USB media from the VMs before upgrading the system software. If VCD or USB media is still connected to the VMs, it prevents the system from migrating the VMs and putting the PMs into maintenance mode for the upgrade process.
  • To verify that the system meets the requirements of the upgrade kit, use the Qualify button.
  • Back up the VMs and make note of any system preferences, customized configurations (for example, certificates, snmpd.conf modifications, or iptables rule changes), and logs. To export VMs on a everRun Release 7.x system to OVF and VHD files as a backup, see Exporting a Virtual Machine.

    In case of any failures during the upgrade process, you can use these backups to restore the system. Because the upgrade involves a migration from the earlier CentOS-based host operating system to the new Ubuntu-based host operating system, if the upgrade from Release 7.x to 8.x fails and there is no backup data, you cannot restore the system to its original status.

  • In some cases, one or more VMs may be configured but stopped or intentionally shut down. If this situation applies to your system, it is important to start each of the VMs and allow them to complete any required synchronization before you start the upgrade procedure.

  • When performing the upgrade, ensure that you log on to a local user account of the everRun Availability Console. To prevent an unexpected loss of access during the upgrade process, do not use an Active Directory user account.

    If your system is configured with Active Directory, you need to reconfigure Active Directory after the upgrade. See KB0015895 for information about creating a new rootCA SSL certificate and installing it into the Java keystore of the everRun system to enable the more secure Active Directory/LDAP over SSL support in Release 8.x or higher.

  • To complete the upgrade, you must have access to the physical console (keyboard and monitor) or an out-of-band, lights-out management utility for each node in the everRun system. The following procedures discuss upgrade using only the physical console of the system.

  • Record any of your current passwords for the system. The everRun Availability Console password remains the same, but, for example, the password for the host operating system on each node will revert to the default setting, and you need to change it after the upgrade to secure your system.

  • If you use the snapshot feature as described in Managing Snapshots, and you delete any snapshots before upgrading, consider waiting for the coalescing operation of VM disks to complete before starting the upgrade. For more information, see Removing a Snapshot and KB0013465. Starting an upgrade while the coalescing operation is in progress could result in much more downtime than expected for the VM and the system.

  • Ensure that you plan a dedicated maintenance period for the upgrade process. The upgrade requires at least 120 minutes of downtime. This time estimate does not include the time it takes to back up data from the node(s) undergoing upgrade. The upgrade also includes a loss of access to the everRun Availability Console. During the upgrade procedure, the everRun system will be completely unavailable for business connectivity.

The steps are:

I. To download the upgrade kit
II. To upload the upgrade kit to the system
III. To qualify the software
IV. To upgrade the system software from everRun Release 7.x to 8.x or higher
V. To complete post-upgrade tasks

I. To download the upgrade kit

Download the upgrade kit that contains the new system software.

Note: You must manually download the everRun Release 8.x upgrade kit from the Stratus website and add (upload) the kit to the Upgrade Kits page of the everRun Availability Console. You cannot download the upgrade kit directly to the Upgrade Kits page.
  1. Open the Downloads page at https://www.stratus.com/services-support/downloads/?tab=everrun.
  2. Scroll down to the upgrade section and then click the everRun 8.x.x.x Upgrade Kit link to download the kit.
  3. Specify a location on a local computer to save the file. If necessary, transfer the file to the remote management computer running the everRun Availability Console.

II. To upload the upgrade kit to the system

Upload the upgrade kit to the everRun system from the remote management computer that is running the everRun Availability Console.

Note: The Upgrade Kits page of the everRun Availability Console allows only two saved kits. If the page lists two kits and you want to upload another kit, you first need to delete a kit.
  1. In the everRun Availability Console, click Upgrade Kits in the left-hand navigation panel.

  2. On the Upgrade Kits page, click the Add a Kit button beneath the masthead, which opens the everRun - Kit Upload Wizard.

  3. In the everRun - Kit Upload Wizard dialog box, click Browse and then browse to select a .kit file.

  4. After you have selected a .kit file, click Upload, Import, or Finish (they perform the same function). A message such as Uploading file (DO NOT CLOSE WIZARD) appears while the file is uploading. The upload may require up to two minutes for a file stored locally, to ten or more minutes for a file stored over a network. If the upload fails, the wizard displays the message Failed to upload file.

  5. After the upload is complete, the wizard closes and the Upgrade Kits page lists the state and version number of the upgrade kit. The Qualify, Upgrade, and Delete buttons also appear with the Add a Kit button.

  6. If more than one upgrade kit is loaded, select the kit for 8.x.x-xxx.

III. To qualify the software

Qualify the software to verify that your system meets the requirements of the upgrade kit. (Qualifying the software is recommended, but not required.)

To do so, select the upgrade kit you want to qualify on the Upgrade Kits page, and then click Qualify.

The qualification may require up to six minutes. If the qualification succeeds, continue with the next step.

If the qualification fails, a pop-up window appears with messages indicating the cause of the failure. These messages may indicate unsupported releases, insufficient storage, partition problems, VMs that need to be shut down, or other information associated with upgrading the system. For example, if the system has insufficient disk space to complete the upgrade, the message Insufficient free space appears reporting the amount of space needed. If you need help resolving a qualification issue, search for the qualification error message in the Knowledge Base in the Stratus Customer Service Portal at https://service.stratus.com.

IV. To upgrade the system software from everRun Release 7.x to 8.x or higher

After verifying that your system meets the Prerequisites for upgrade, completing steps I-III of the upgrade process, and completing backups of your VMs and data, continue with the following procedure to upgrade the system software to everRun 8.x or higher.

  1. Log on to the everRun Availability Console with a local user account (not a networked Active Directory account) for the upgrade.

  2. Confirm that all PMs and VMs are healthy. In the everRun Availability Console:

    • The Dashboard page displays green check marks () with no outstanding issues.

    • The Physical Machines page displays green check marks () for each PM.

    • The Virtual Machines page displays green check marks () for each VM.

  3. On the Preferences page, click IP Configuration. Record the current network settings of the everRun system or take a screen capture of the IP Configuration page in case this information is necessary to access or restore the system.

  4. Verify the health of each node in the system. Check the system logs for any memory, network, CPU, or storage errors (for example SMART disk errors) by doing the following:

    1. Open an ssh connection to the host operating system of a node in the everRun system at one of the IP addresses you recorded in a previous step.

    2. Open logs including /var/log/messages in a text editor or use system commands to examine the log entries for any issues.

    3. Repeat these steps on the second node in the system.

  5. Verify the health of each VM. For each running VM, do the following:

    1. On the Virtual Machines page, record the Name of each VM.

    2. Open an ssh connection to the host operating system of a node in the everRun system at one of the IP addresses you recorded in a previous step.

    3. For each VM, execute the following command, where vmname is the name of the VM recorded in a previous step:

      # /opt/ft/bin/axcons vmname ax1.scp show pvm status | grep PVM

      Verify that the output is similar to the following, where the VM's state in the first column is Good.

      # /opt/ft/bin/axcons myVM ax1.scp show pvm status | grep PVM
      PVM        Good      None     None          None

      For any VM that is Stopped, start and verify the VM as described in the next step. Wait for it to synchronize, and run the axcons command again to confirm that the VM is in a Good state.

      Caution: If the state of the VM is anything other than Good or Stopped (for example, Degraded, Transitioning, or Crashed), defer the upgrade and contact your authorized Stratus service representative for assistance.
  6. On the Virtual Machines page, if any VMs are currently stopped or intentionally shut down, verify that it is safe to introduce the VMs to your network, start each VM to verify that it is working, and allow each VM to complete any required synchronization before continuing the upgrade procedure. If insufficient resources (vCPUs or RAM) prevent all VMs from running at the same time, shut down a VM to accommodate the requirements of another VM until all VMs have been verified.

    Caution: Resolve any outstanding issues before continuing with the upgrade. If you need assistance with any repairs required to meet the health and redundancy requirements in the previous steps, contact your authorized Stratus service representative for assistance before proceeding any further.
  7. On the Virtual Machines page, on the Boot tab for each VM:

    • Record the current Auto Start Mode setting (Last, On, or Off), so you can restore it after the upgrade.

    • Set the Auto Start Mode setting to Off to prevent the VM from starting during the upgrade.

  8. On the Virtual Machines page, on the CD Drives & USB Devices tab for each VM, ensure that no media is connected to the VMs. If needed, disconnect the media in the guest operating system(s), and then click Eject CD or Detach USB Device in the everRun Availability Console until no devices are connected.

  9. On the Support Logs page, create a diagnostic file for the system as described in Creating a Diagnostic File and download the file to a management PC.

    Note: When you upgrade from everRun Release 7.x to 8.x, the upgrade process does not preserve the system logs from the original Release 7.x (CentOS) system. It is important to create a diagnostic file to preserve the log history before upgrading the system.
  10. On the Virtual Machines page, gracefully shut down all VMs that are running on the system.

  11. On the Upgrade Kits page, begin the upgrade by clicking Upgrade.

    A Confirm window appears, asking you to confirm the upgrade to the selected upgrade kit.

    Note: Selecting the check box to enable pause has no effect. When upgrading from Release 7.x to 8.x, the system automatically pauses before upgrading the second node.
  12. Click Yes to continue the upgrade. When the upgrade begins, node0 reboots and node1 shuts down in preparation for the upgrade.

    The everRun Availability Console loses its connection to the everRun system until the upgrade is complete on node0. To continue the upgrade, access the keyboard and monitor attached to the physical console of node0.

    Caution: Do not power on node1 or start any VMs during the upgrade process. If VMs start or reboot, any business transactions occurring during this time might fail or might not be completed.
  13. The physical console screen of node0 displays a text-based grub boot menu with a highlighted, default Upgrade option and waits for user interaction. Press Enter to proceed

  14. Select a language option. The node boots from the Ubuntu OS.

  15. In the text-based Upgrade Wizard, do one of the following:

    • To initiate the upgrade, press Enter and type yes. The upgrade begins on node0. You can monitor the upgrade progress on the physical console screen of node0. Continue with the next step.

    • To cancel the upgrade, press 1, c or C. Node0 shuts down. If you cancel the upgrade at this point, the next time you power on node0 the grub boot menu displays the original CentOS configuration as the default boot option and automatically boots CentOS after 30 seconds if there is no user interaction.

    Caution: After you initiate the upgrade on node0, you cannot stop or cancel the upgrade on node0.
    Caution: If the node0 upgrade is unsuccessful for any reason, do not power on node1. Contact your authorized Stratus service representative for assistance before proceeding any further.
  16. When the upgrade completes on node0, the node reboots. The grub menu displays the new Ubuntu configuration as the default boot option and automatically boots the Ubuntu OS after 30 seconds if there is no user interaction.

  17. After the Ubuntu OS starts, the console displays the node0 and system IP addresses after a few minutes. If needed, record the system IP address to access the everRun Availability Console in the next step. The system IP address is the second IPv4 address.

    everRun
    IPv4 address 10.201.128.201 <-- node0 IPv4 address
    IPv4 address 10.201.128.200 <-- system IPv4 address
    IPv6 address 3d00:feed:face:1083:225:64ff:fe8d:1b6e
    IPv6 address fe80::225:64ff:fe8d:1b6e
  18. If the everRun Availability Console is still running on the remote management computer, refresh the web browser to view the current status of the system; or, if needed, open a web browser, load the system IP address, and log on to the everRun Availability Console.

    Note: After the system upgrades node0, but node1 has not been updated yet, the nodes are running different types of the system software. During this time, the everRun Availability Console masthead might display healthy, critical, warning, or other health states, which is expected because the nodes are unable to communicate with each other. VMs, volumes, storage groups, and networks will also have warnings () because they are currently in simplex mode.
  19. In the everRun Availability Console, confirm both of the following:

    • On the Physical Machines page, verify that only node0 is currently running and displayed as node0 (primary), whereas node1 is lost.

    • In the everRun Availability Console masthead, verify that the system is now running everRun Release 8.x. For example:

      ocean.abc.com
      IP: 123.109.50.34 | Asset ID: ee-12345
      Version: 8.x.x-xxx

    If these conditions are met, continue with the next step; otherwise, contact your authorized Stratus service representative for assistance.

  20. Start the VMs one at a time and verify that they operate normally. For each VM, do the following:

    Caution: It is important to verify the VMs, but note that when you start a VM, it acquires new data from the network, and this copy of the VM becomes the most up-to-date version of the VM. If you roll back to the original everRun Release 7.x system, you might need to re-export the VMs before rolling back to preserve any changes.
    1. Start the VM and verify that it reaches the running state. If the VM appears stuck in the booting state, verify its network connections and retry.

    2. Log on to the console of the VM.

    3. Evaluate the VM as it is admitted to its networks.

    4. If the VM is operating normally, reconfigure its Auto Start Mode as desired.

    Caution: If the node0 upgrade is unsuccessful for any reason, do not power on node1. Contact your authorized Stratus service representative for assistance before proceeding any further. If you proceed with the next step, the upgrade process overwrites node1, and you cannot roll back to the original, CentOS-based host operating system without fully reinstalling the everRun software.
  21. After verifying that node0 has been upgraded successfully, manually power on node1 to continue the upgrade.

  22. The physical console screen of node1 displays a text-based grub boot menu with a highlighted, default Upgrade option and waits for user interaction. Press Enter to proceed

  23. Select a language option. The node boots from the Ubuntu OS.

  24. In the text-based Upgrade Wizard, do one of the following:

    • To initiate the upgrade, press Enter and type yes. The upgrade begins on node1. You can monitor the upgrade progress on the physical console screen of node1. Continue with the next step.

    • To cancel the upgrade, press 1, c or C. Node1 shuts down. If you cancel the upgrade at this point, the next time you power on the system the grub boot menu displays the original CentOS configuration as the default boot option and automatically boots CentOS after 30 seconds if there is no user interaction.

  25. When the upgrade completes on node1, the node reboots. The grub menu displays the new Ubuntu configuration as the default boot option and automatically boots the Ubuntu OS after 30 seconds if there is no user interaction.

  26. After the upgrade completes on node1, it takes a few minutes for node1 to join the system.

    • On the Physical Machines page, node0 will be running with a warning () and node1 will be (in Maintenance) mode.

    • After node1 joins the system, both nodes will be in the running state. The warnings () might continue until the system synchronizes all data been the nodes.

    • After all volumes have synchronized, all warnings disappear, and all components should have green check marks ().

    Confirm that there are no critical alerts in the masthead or on the Dashboard page of the everRun Availability Console. Resolve any remaining issues. When the system is healthy, the upgrade is complete.

  27. Ensure that the system is running correctly by checking all of the features.

V. To complete post-upgrade tasks

  1. Remove the obsolete VirtIO ISO file.

    After the upgrade, the everRun Availability Console might still contain an old VirtIO driver ISO file from everRun Release 7.x. You must remove the ISO file as follows:

    1. In the everRun Availability Console, open the Virtual CDs page.

    2. On the Virtual CDs page, remove the virtio-win-0.1.171_rev1 ISO by selecting the ISO and clicking Remove.

      Caution: Do not remove the virtio-win-0.1.190_rev2 or higher ISO associated with everRun Release 8.x or higher.
  2. Update the VirtIO drivers on all Windows-based VMs, as described in Updating the VirtIO Drivers (Windows-based VMs). Ensure that you install the VirtIO drivers from the new virtio-win-0.1.190_rev2 or higher ISO associated with everRun Release 8.x or higher.

  3. Reset the root password on each node in the system.

    After the upgrade, the password on each node resets to the default KeepRunning. Log on to the host operating system of each node and reset the root password to secure your system. If the node does not prompt for a new password upon login, issue the passwd command to change the password.

  4. If applicable, restore your Active Directory configuration. Create a new security certificate, install the certificate, and reconfigure Active Directory to allow secure logins as described in KB0015895.

  5. Restore any other security certificates, as needed.

  6. Restore any host operating system customizations.

  7. Continue to configure and test the everRun system, as needed.

  8. Optionally, migrate virtual machines to 512e storage, as described in Migrating Virtual Machines to 512e Storage.