For instructions on upgrading your Awingu environment, and details about the changes in the Awingu version, please take a look at our release notes.
This article contains important factors to keep in mind/to expect when planning to upgrade Awingu to the latest version.
- Awingu upgrades are incremental.
You may need to upgrade through multiple Awingu versions to be able to upgrade to the latest release, depending on your current version of Awingu. These are defined in our release notes; there's also an overview
at the end of this article.
- Take a snapshot of the appliance(s) (and if applicable: external database) before EACH upgrade.
Before carrying out an Awingu version upgrade, it is always highly recommended to shut down the appliance(s) and take a snapshot/backup of the appliance(s). If applicable: do the same for the external database. Quite often, Awingu appliances still need a reboot anyway
- If there are major issues during/after the upgrade:
- Contact the support team first for analysis, so the cause can hopefully be determined, and perhaps the failed upgrade can even be resolved. Without log files of the upgrade attempt, it's nearly impossible to determine the cause.
- Only if time is of the essence, try to keep a snapshot of each appliance in the Awingu cluster when the upgrade seems to fail.
- In the worst case, the support team will recommend restoring these snapshots, in order to restore accessibility to the Awingu appliance as quickly as possible.
- Download or Download & Upgrade.
When you are on the General Info page of the System Settings, there's an option to Download or Download & Upgrade (depending on which version).
Download will download the update packages, ready to install later (the button will change when the packages are downloaded.
Download & Upgrade will download the upgrade packages. When complete, the installation begins immediately.
- Service interruption.
When upgrading an environment, there will always be service disruption, a period where users cannot access/use the environment. This is also the case for a multi-node environment, so it's recommended to upgrade outside business hours.
- Service interruption period.
During an environment upgrade, the average estimated length can be calculated as about 15 minutes per appliance in the cluster.
For example, if there are 3 nodes in the cluster, this will take approximately 45 minutes to upgrade. This is because Awingu sequentially upgrades the nodes.
However, in some situations, the upgrade can take a lot more time per appliance (see below matrix), depending on the disk and network speed.
- Do not refresh the System Settings page.
While the upgrade is in progress, do not refresh the System Settings page. When using the built-in admin account to do the upgrade, the account will be automatically logged out after 15 minutes. This is no problem, just log in and open the System Settings again.
- NEVER reboot the appliance(s) manually during an upgrade unless told so.
It is important to never reboot appliances while they are in an upgrading state because "it feels like the upgrade is taking too long" (check the matrix below for an estimate and maximum expected service interruption).
This is a summary of the upgrade paths:
|3.6.4, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5, 4.0.6, 4.0.7, 4.0.8||4.0.9|
|4.0.9, 4.1.1, 4.1.2||4.1.3|
|5.0.1, 5.0.2, 5.0.3, 5.0.4, 5.0.5||5.0.6|
|5.0.6, 5.1.1||5.1.3||Notes: before upgrading to 5.1.3, it's necessary to migrate the audit logs. If still required, this is visible at the bottom of System Settings > Global > General info.
Mind that the upgrade to 5.1.3 is a long one as it also upgrades the underlying OS.
For an estimate, take 45 minutes per appliance.
|5.1.1, 5.1.3, 5.2.0, 5.2.2, 5.2.3||5.2.5|
|5.2.4, 5.2.5, 5.3.1, 5.3.2||5.3.3|
|5.3.3, 5.4.0, 5.4.2||5.4.4||Note: Mind that the upgrade to 5.4 is a long one as it also upgrades the underlying OS.
For an estimate, take 60 minutes per appliance.
|5.4.0, 5.4.2, 5.4.4||5.5.1 (latest version)|
Related info: No upgrades available / latest version not available .
Since upgrades can take a while, there are some alternative strategies that may work as well.
For example, as of version 5.3, this could be a strategy to minimize downtime.
- Communicate to users that they should not take certain actions until the upgrade has been performed.
- For example: if they would still share files through Awingu after backing up the environment, this will not be present in the final environment. Once the upgrade is completed, each user would need to "update" their shares to make them work again.
- Create an "environment backup".
- Do mind that it does not include the external database, so this would need to be backed up manually.
- Do mind that an environment backup has some limitations (see admin manual). For example, "shares" (files shared through Awingu) are not backed up/restored. After restoring, users will still see their shares, but they will need to press the "Upgrade" button again.
- Deploy a new node - this must match the existing Awingu version.
- When working with an external database, deploy a copy (restore from backup) on the database server.
- During the initial configuration wizard, this environment backup can be imported.
- Make sure to give this new node a new IP address.
- When using an external database, make sure the configuration no longer points to the original database, but to the copy.
- Update this newly deployed node as usual.
- In case of a multi-node environment: add new nodes (same version).
- Update the applicable network infrastructure (DNS, firewall, load balancer, ...) to point to the IP address(es) of the new appliance(s).
- Communicate to users that everything is up and running again.
- Shut down the original nodes. Decommission once everything is confirmed to be working smoothly.
Note: there will be some missing audit logs etc. from between the moment of backing up the original database, and the go-live with the new environment.