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:
Read the release notes.
Request the upgrade prerequisites from AppsAnywhere Support.
Provide details of the prerequisites to the AppsAnywhere team and schedule a prerequisite check.
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
Applications will be republished by Cloudpaging Server after the upgrade, so .stp files that have been incorrectly moved will need to be replaced before the upgrade can commence.
Ensure the repository contains all the applications published in AppsAnywhere by checking the Publishing Status for each one in Cloudpaging Server.
Failure to do so may prevent applications from launching for end users.
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
Confirmation all pre-upgrade requirements are met
Functionality tests via the test machine
The login process is functional
Verifying basic navigation
Launching of applications
Access to the admin interface and confirmation of version numbers
Major upgrade procedure
Step | Action | Performed by |
---|---|---|
SERVICE AT RISK / LIMITED CAPABILITY WINDOW BEGINS | ||
1 | Stop services on server group 1 | Cloudpaging engineer |
2 | Perform functionality tests against server group 2 via load balancer | Cloudpaging engineer / Cloudpaging administrator |
3 | Upgrade service components on server group 1 | Cloudpaging engineer |
4 | Configure service components on server group 1 | Cloudpaging engineer |
SERVICE DOWNTIME BEGINS | ||
5 | Run the database upgrade command | Cloudpaging engineer |
6 | Stop services on server group 2 | Cloudpaging engineer |
7 | Perform functionality tests via the load balancer against server group 1 | Cloudpaging engineer / Cloudpaging administrator |
LIMITED SERVICE RESTORED (Service At Risk / Limited Capability Persists) | ||
8 | Upgrade service components on server group 2 | Cloudpaging engineer |
9 | Configure service components on server group 2 | Cloudpaging engineer |
10 | Start all services on server group 2 | Cloudpaging engineer |
11 | Stop all services on server group 1 | Cloudpaging engineer |
12 | Perform functionality tests via the load balancer against server group 2 | Cloudpaging engineer / Cloudpaging administrator |
13 | Start all services on server group 1 | Cloudpaging engineer |
14 | Perform final functionality tests via the load balancer | Cloudpaging engineer / Cloudpaging administrator |
15 | Customer verification and sign-off | Cloudpaging engineer / Cloudpaging administrator |
FULL SERVICE RESTORED (SERVICE AT RISK / LIMITED CAPABILITY ENDS) |
Minor upgrade procedure
Step | Action | Performed by |
---|---|---|
SERVICE AT RISK / LIMITED CAPABILITY WINDOW BEGINS | ||
1 | Stop services on server group 1 | Cloudpaging engineer |
2 | Perform functionality tests against server group 2 via load balancer | Cloudpaging engineer / Cloudpaging administrator |
3 | Upgrade service components on server group 1 | Cloudpaging engineer |
4 | Configure service components on server group 1 | Cloudpaging engineer |
5 | Run the database upgrade command | Cloudpaging engineer |
6 | Stop services on server group 2 | Cloudpaging engineer |
7 | Perform functionality tests via the load balancer against server group 1 | Cloudpaging engineer / Cloudpaging administrator |
8 | Upgrade service components on server group 2 | Cloudpaging engineer |
9 | Configure service components on server group 2 | Cloudpaging engineer |
10 | Stop all services on server group 1 | Cloudpaging engineer |
11 | Perform functionality tests via the load balancer against server group 2 | Cloudpaging engineer / Cloudpaging administrator |
12 | Start all services on server group 1 | Cloudpaging engineer |
13 | Perform final functionality tests via the load balancer | Cloudpaging engineer / Cloudpaging administrator |
14 | Customer verification and sign-off | Cloudpaging engineer / Cloudpaging administrator |
SERVICE AT RISK / LIMITED CAPABILITY WINDOW ENDS |
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.
Review deployment logs for errors
Correct cause of errors where possible
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:
A significant problem is encountered during the upgrade procedure and the remaining window is unlikely to allow for investigation and resolution.
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
If upgrades were made to the database schema during a major upgrade, the database will need to be restored from backup.
If the servers are virtual and snapshots were taken before the upgrade process, these snapshots can be restored at this point.
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.
Uninstall all server components
Reboot Server
Re-install server components
Re-connect to the existing database