Upgrading Cloudpaging Server

Overview

To provide our customers with the latest features and fixes, as well as important security and performance enhancements AppsAnywhere Support will ensure the latest version of Cloudpaging Server is made available.

Each component (AppsAnywhere and Cloudpaging) is upgraded separately if required and upgrades can be carried out by AppsAnywhere Support under the support agreement. 

On average, new releases are provided every 3-4 months and these usually alternate between major and minor releases. Patches, bug fixes and workarounds can be applied as and when required, if applicable.

Information on AppsAnywhere upgrades is available on Upgrading to a new appliance.

To upgrade Cloudpaging, customers need to:

1. Read the release notes.

2. Request the upgrade prerequisites from AppsAnywhere Support.

3. Provide details of the prerequisites to the AppsAnywhere team and schedule a prerequisite check.

4. Once the prerequisites are complete, an upgrade scheduling link will be provided to schedule a maintenance window.

AppsAnywhere Cloud Customers

Instances hosted on AppsAnywhere Cloud will be upgraded by AppsAnywhere.

• Upgrades will be applied within 6 months of release.

• A maintenance window will be scheduled, and AppsAnywhere Support will provide at least 2 weeks' notice in advance of an upgrade being applied.

Upgrade Types

There are two types of Cloudpaging server upgrade, major and minor. 

Downtime is indicated on the basis that at least two servers for each service are running in a load-balanced pool. Whether or not downtime will be required depends on the type of upgrade, and will be communicated when the upgrade is requested.

Servers are upgraded in groups to maintain service for as long as possible during the upgrade procedure. A group of servers includes one Cloudpaging Admin/License server and one Paging server.

Major upgrades (downtime required)

A major upgrade, would take you from version 1.1 to version 2.0. Major upgrades require changes to the database and consequently downtime from when the database schema is updated until the first group of servers are updated.

Changes to files on the Cloudpaging servers, and upgrades to additional components will usually be included.

To minimize the duration of downtime, a longer service at risk window is required so that servers can be upgraded sequentially according to the below procedures.

Minor upgrades (downtime not required)

A minor upgrade would take you from version 1.1 to 1.2. If your infrastructure is load balanced with health checks in place, a minor upgrade can be completed without any downtime.

Minor upgrades or patches only involve changes to files on the Cloudpaging servers, and occasionally upgrades to additional components.

As there are no database changes, only a restart of services is required as part of the upgrade procedure. Downtime is avoided on the basis that there are two servers for each service running in a load-balanced pool.

Scheduling an Upgrade

The timing of an upgrade usually depends on whether downtime is required and your own institutional policy restrictions or procedural requirements. AppsAnywhere recommend that upgrades are undertaken during a period when usage is at a minimum, to minimize any impact to service users.

Upgrades can be scheduled at any time during AppsAnywhere Support business hours. You can also request that an upgrade take place outside of normal support hours in your region (taking advantage of our support personnel in different time zones) and we will aim to meet your request where staff availability permits.

On-premises upgrade dates cannot be confirmed until we've wrapped up all the necessary prep work and given it the green light from our AppsAnywhere Support team.

Once everything's good to go, we'll share a scheduling link with you. If you try to schedule upgrades before we finish the prep, we might need to reschedule, so it's best to wait until we give the all-clear. Thanks for your understanding!

Major upgrades

Customers should notify service users of:

• Service at Risk / Limited Capability – number of servers x 10 minutes

• Service Downtime – starting approx. 5 minutes in for about 15 minutes

If load balancing configuration (with health checks) is not in place, then the service will be unavailable during the entire upgrade (Service at Risk / Limited Capability) window.

Minor upgrades

Customers should notify service users of:

• Service at Risk / Limited Capability – number of servers x 10 minutes

If load balancing configuration (with health checks) is not in place then the service will be intermittent during the entire upgrade (Service at Risk / Limited Capability) window.

Servers and Components

The following components are installed on each Cloudpaging server and are modified during an upgrade.

• Cloudpaging Server

• Open JDK

• Apache Tomcat

A typical load balanced Cloudpaging environment for AppsAnywhere will include a minimum of:

• 2 x Cloudpaging Admin/License Servers

• 2 x Cloudpaging Stream servers

A server group consists of one server from each of the above server (service) types.

If you do not have this number of servers already, we are happy to install and configure additional servers so that you can implement load balancing.

See AppsAnywhere Support and load balancing services for more information.

We are aware of an issue with older A10 load balancers (e.g. A10 AX2500) and the newer versions of TLS used by Cloudpaging Server.

Please inform Support prior to upgrade if you are using an A10 load balancer that explicitly use older encryption cyphers such as TLS v1.0.

Pre-Upgrade Requirements

Customer Contacts

Contact details must be provided for at least one lead customer contact who will be available for the duration of the upgrade. The AppsAnywhere engineer will need to establish a line of communication.

The following customer personnel will also need to be available / contactable for the duration of upgrade window:

• AppsAnywhere administrator

• Load Balancer administrator

The following customer personal should be contactable in case of any issues:

• Hypervisor / server administrator

• Database administrator

• Network administrator

• Active Directory administrator

If the following requirements are not met, AppsAnywhere reserve the right not to proceed with an upgrade.

Remote Access

Upgrades are usually done remotely using the remote access method that should already be in place for support purposes.

If you have not yet agreed a method by which an AppsAnywhere engineer can access your servers remotely, this will need to be arranged prior to the upgrade window.

Test Machine

To confirm that upgrades have been successful, an AppsAnywhere engineer will need a test user account and access to a test machine.

Installation Files

Prior to the upgrade it is helpful if you can download the Cloudpaging server installers and place them in an accessible location, such as a network share.

The download will be provided by AppsAnywhere Support.

Otherwise, please ensure that internet access is provided.

Server Backups

Provision for backups should be made before the upgrade procedure begins. Backups are required in case any of the rollback procedures need to be enacted.

Where servers are hosted on virtual infrastructure, snapshots should be taken by the customer immediately prior to upgrade. Snapshots can be deleted once the upgrade is successfully completed.

Database Backup

For a major upgrade, a full backup of the database (StreamDB) must be taken prior to upgrade. The backup can be done by the AppsAnywhere engineer if required, providing the relevant access and permissions are in place.

Repository Validation

File Structure

As a precaution AppsAnywhere Support will make a backup copy of all the relevant directories on each server prior to upgrade.

Upgrade Procedures

Our recommended AppsAnywhere infrastructure is designed to provide a resilient app delivery service to thousands of simultaneous users. Components are also developed with ease of upgrade and service continuity in mind.

As with all support from AppsAnywhere, regular upgrades are covered under our managed service agreement.

Each server is independent and connects directly to the database. Thus, with load balancing in place, service can be maintained while an individual server is taken offline.

Upgrade procedures are designed to minimize or eliminate downtime as far as possible. In the event of any complications arising during an upgrade, AppsAnywhere engineers will follow these procedures in order resolve the problem, or if necessary, revert to the pre-upgrade state.

AppsAnywhere Engineers will open a line of communication with the customer to report on progress of the upgrade.

Functionality Tests

Before starting an upgrade and at various stages during the upgrade, service will be tested to confirm functionality. Tests include

1. Confirmation all pre-upgrade requirements are met

2. Functionality tests via the test machine

3. The login process is functional 

4. Verifying basic navigation

5. Launching of applications

6. Access to the admin interface and confirmation of version numbers

Major upgrade procedure

Minor upgrade procedure

Issues During Upgrade

An AppsAnywhere engineer will keep you informed during the upgrade window should there be any issues during the upgrade process.

The first action will be to review the deployment logs which detail each step of the process along with any errors that may have occurred.

In almost every case, the deployment logs provide enough information relating to a failure for the issue to be resolved and the upgrade to be completed successfully.

1. Review deployment logs for errors

2. Correct cause of errors where possible

3. Re-initiate or complete the upgrade procedure

If sufficient time remains in the current upgrade window, one or more of the rollback procedures may also be used, before attempting the upgrade again.

Rollback Procedures

If there is a problem with the deployment of an upgrade, and less than 1 hour of the agreed upgrade window is remaining, the AppsAnywhere engineer will discuss this with you and ask for authorization for one of the following rollback procedures.

There are two main scenarios in which a rollback is advisable:

1. A significant problem is encountered during the upgrade procedure and the remaining window is unlikely to allow for investigation and resolution.

2. The upgrade is completed but does not function as desired, as determined by the post-upgrade functionality tests.

In either of these cases, servers can be reverted to the last known good configuration, using one of the following methods.

Rollback Procedure

1. If upgrades were made to the database schema during a major upgrade, the database will need to be restored from backup.

2. If the servers are virtual and snapshots were taken before the upgrade process, these snapshots can be restored at this point.

3. OR - Cloudpaging servers can be reverted by installing the previous software version and re-connecting to the database.

Rebuild Procedure

In the event of a severe failure during the upgrade of a server, and in the unlikely event that it is not possible to successfully complete one of the rollback procedures, severs can rebuilt from scratch.

This would only be required where there has been a major corruption of the server itself, caused by a bad update or disk failure, for example.

As detailed in the overview, AppsAnywhere is designed in such a way that any (or all) of the servers can be completely rebuilt without data loss. This effectively gives us a clean installation.

1. Uninstall all server components

2. Reboot Server

3. Re-install server components

4. Re-connect to the existing database