Upgrading Your Pagely VPS to Ubuntu 20.04 LTS

In May of 2021, we announced on our blog that we've upgraded our hosting stack to Ubuntu 20.04. If you have become a Pagely customer after May 2021, you are already on the new version of Ubuntu and this article does not apply to you. If you activated prior to that date, or you received a link to this article from Pagely regarding your specific service, please keep reading...

We will be upgrading the Operating System on your Pagely VPS. There is no action you need to take, but we have prepared some details below to help with any commonly asked questions.

Pagely manages the software lifecycle of your VPS hosting service. We take care of routine updates to the packages on your server, as well as major upgrades to the Linux Distribution your server is based on, in order to ensure that you are running on supported software over the entire lifetime of your service with Pagely. You do not need to perform this type of upgrade on your own. OS upgrades occur about once every 4 years and are driven by the Ubuntu release cycle.

We are currently in the process of upgrading all customer VPS instances to Ubuntu Linux version 20.04 LTS, which will remain supported through April 2025. This article will help you understand what that process entails and what you can expect.

Scheduling

Pagely will determine an appropriate scheduled time to conduct this upgrade for your server. The Alerts section of your Atomic Dashboard and the Pagely status page will specify the time this event will occur.

We select off-peak times that are localized to the hosting region your service is operating from. For instance, if your services are located in the London hosting region, the maintenance window would be during the US daytime hours (and vice versa). 

We will pre-select a time and date for you, but you can contact support to request a different time. We're also happy to perform the upgrade for you immediately if you want to get it squared away right now.

Upgrade Strategy

There are generally two strategies to upgrade the Operating System on a server:

• In-place upgrades (running sudo do-release-upgrade on the existing server)
• Provisioned upgrades (building a replacement server on the new OS version and then pointing traffic over to it)

Pagely always conducts provisioned upgrades when it comes to the OS version on your VPS. We never attempt to upgrade your server in-place because that process can take an unpredictable amount of time to complete and makes rolling back more complicated/impossible.

Because we use a provisioned upgrade strategy, we are able to minimize service interruptions during the process, as well as granting us a means to quickly rollback to the original environment if there are unforeseen problems with the upgrade.

Our system will keep your existing server online while a new Amazon EC2 instance is being provisioned. Once it is ready for Cutover, a DevOps Engineer will approve the action and supervise the automated process to completion.

Cutover Time (60 seconds - 5 minutes)

During the upgrade process, there is a very short period of downtime involved once we reach the cutover stage. This is typically as brief as 60 seconds, or in some cases up to 5 minutes. In exceptionally rare cases where the automated process detected a problem that requires manual intervention by our Engineers, it is possible to experience up to 30 minutes of downtime during the maintenance window. 

The minimum and unavoidable amount of downtime of around 60 seconds is due to re-associating your Elastic IP Address(es) and your SSD storage with the new instance. In order to perform that reassignment, those resources have to be detached from the current running resource and attached to the new one. We have automation that handles these steps in the correct order and in a timely manner and both steps typically complete within a 60 second timeframe. During that time, connections to your IP address will either hang briefly, report a connection timeout, or report a 5xx-level HTTP response code.

High Availability Plans will experience even less downtime, if any at all, provided that you have traffic pointed correctly. Generally this means making sure your DNS records point to a CNAME record such as wp####.host.pressdns.com; that record is backed by health checks and can automatically re-route traffic to the server that is online. If you are not sure how to check for this, please contact support prior to the maintenance window and we can help. We will process only one server at a time for your HA pair, making sure the other server is fully operational prior to approving the Cutover action.

Automated Pre/Post Healthchecks & Rollback

Our automation has rollback mechanisms built right in to the process. When we are first building the replacement VPS, we generate healthcheck data about every application that is running on your current server. We capture that data and then run the same checks again after the Cutover stage. If the HTTP response code does not match up with what was logged prior to the Cutover, or if connection errors are detected, an automatic rollback is initiated.

The rollback action simply moves your resources back to the original server. It can result in another brief downtime window while it is in progress.

In this scenario, our DevOps Engineers handling the upgrade will review the cause of the rollback and retry the Cutover. If we experience any major issues we will reach out to you with a support ticket.

DNS / IP Addresses

No DNS changes are required to complete this upgrade. We provide every customer with at least one Amazon Elastic IP address, which is able to be re-associated with a different server. You do not need to update your DNS A records or CNAME records as a part of this upgrade.

The private IP address of your VPS will be changing. Any areas where this is defined and used within our own configuration management is handled using a internal-to-Pagely DNS record resembling your-server-name-here.vps.pagelyhosting-private.com. After a successful Cutover, this record get updated to point to the new private IP. 

If you have defined the server's private IP address (an address like 10.0.6.83, not your public IP address) in any part of your code, we recommend changing it to the DNS name before the upgrade as we will update that record automatically. Please contact support if you need help determining if this part applies to you, but the vast majority of customers don't need to worry about this.

Data

Because we are simply re-attaching your existing EBS volume(s) to the new server, all code and static asset data for your WordPress applications are brought along to the new server. The contents of home directories for you or your Collaborators will also remain intact. Any custom Linux Crontab entries you may have configured will also be migrated. You do not need to re-upload anything and it is not possible for any singular files to be lost in the shuffle if they reside on your data volume. Nothing will be touched as far as your databases go.

Custom Integrations

Pagely supports a number of integrations for your managed WordPress VPS. Any custom integrations we detect will be configured on the new server after the Cutover action completes successfully. This can include things such as New Relic, Elasticsearch, PressThumb, CI/CD, or any other custom things we are managing for you using our Ansible codebase. 

Sunsetted Resources

After a successful upgrade, we place your old EC2 instance on cooldown for 7 days. This makes it possible to recover anything that may have been missed from the original server. We make every effort to bring everything you need over and this is just a contingency in case we miss anything.

Need More Help?

If you have any questions regarding this upgrade, please do not hesitate to contact our Support Team. We are ready to accommodate any special handling for you if you have a need for it. Above all else, we want to make sure your experience throughout this process is smooth and free of defects, so please let us know how we can help!