As we begin a new monthly series, let’s talk about something that all customers experience – upgrades. Whether it’s the classic “reboot required” or the “happens so fast you missed it”, upgrades are a certainty, much like death and taxes.
Qumulo is no different in this field, with upgrades released at a fairly regular pace. When Qumulo implemented the OS as a container back with the release 3.3.2, we also introduced the concept of platform and instant upgrades. At their most base level, they accomplish the same thing, and for the most part, in much the same manner. Both copy the image out across all nodes. Both will run a series of pre-tests (colloquially referred to as pre-flight checklists) to ensure the upgrade will be successful. Lastly both will have some sort of system restart – either of the container in the case of instant or the node in the case of a platform or rolling reboot.
One of the most common questions we’re asked in support is ‘what is my upgrade path?’, or ‘how do best go from version X to version Y’?
Let’s start with a breakdown of the release naming scheme.
X.Y.Z.a
Where
X is the fiscal year
Y is the fiscal quarter, starting at 0
Z is the release in that quarter
a is there on an as needed basis if some extra features slipped in (e.g. third party supportability, firmware, and the occasional bug fix)
For example, 5.3.4 is going to be:
Fiscal year 5, fourth quarter, 4th release in the quarter.
Why is this important? Qumulo has what are called “Quarterly Releases” denoted by the third digit being a 0 – or the first release of every quarter. There’s nothing particularly fanciful about these, it just happens to be where they land in the calendar year. However, we will use those as a stepping point for the next quarter, so as a Qumulo customer you need to upgrade to every .0 quarterly release.
I recently spoke with a customer who hadn’t touched their system for a good 2 years. If it isn’t broke, don’t fix it (more on this later). Since they had to upgrade to every .0 quarterly release, our upgrade path was pretty lengthy as you can imagine.
3.2.0 -> 3.3.0 -> 4.0.0.2 -> 4.1.0.1 -> 4.2.0 -> 4.3.0 -> 5.0.0.1 -> 5.1.0.1 -> 5.2.0.2 -> 5.3.0 -> 6.0.0.2
The next most common question we hear around upgrades is ‘how long is this going to take?’ Instant upgrades usually take place within sub-10 seconds and applications seldom seem to mind. Platform upgrades take as long as the system takes to boot – which is typically in the 5-10 minute range. If we take our upgrade path laid out above and add in if they’re Instant (I) or Platform (P) we get –
3.2.0 (P) -> 3.3.0 (I) -> 4.0.0.2 (I) -> 4.1.0.1 (I) -> 4.2.0 (I) -> 4.3.0 (P) -> 5.0.0.1 (I) -> 5.1.0.1 (I) -> 5.2.0.2 (P) -> 5.3.0 (I) -> 6.0.0.2 (P)
Given the above, if we assume 8 minutes for a platform, we’re looking at 4 of those, and 7 instants. Call it 35 minutes total give or take. Schedule an hour and get a good power nap in.
A great document for checking if it will be a platform or instant upgrade is located on the docs.qumulo.com page here..
You may be looking at that and wondering why 6.0.0.2 was labeled a platform upgrade when it clearly states it’s ‘Instant, Quarterly’. This is where the next bit of upgrade trivia comes into play.
If you scroll down that chart, you’ll see there was a platform upgrade that took place at 5.3.1. Since we’re hitting that version as part of the 6.0.0.2 quarterly, its platform upgrade gets pushed into our quarterly release. It’s nuanced, but can catch you off guard if you aren’t looking for it.
Two final things I alluded to that will come into play before we tie a bow on this one. The first is hardware related. While not directly tied to Moore’s law (RIP Gordon Moore, you had a good run), hardware advances happen at a thoroughbred rate. As such, something as benign as a hard drive that comes out this year, won’t have been tested against software made 2 years prior. At Qumulo we maintain an internal hardware compatibility list within the code. These are components that have been rigorously tested to ensure high standards. As such, if you’re running on an older release and a replacement is needed, it’s possible the newer part hasn’t been qualified against the older software. We see this from time to time, and typically we’ll look to get the software upgraded to a more recent release.
The other item to note is replication. Recent versions of Qumulo require you to be within two quarterly releases of each other (that’s the second number in our naming scheme above). When planning upgrades, keep this in mind – especially for example, if you plan to upgrade your disaster recovery site weeks before your source. We’ll talk more about replication and associated best practices next month, but for now if you have any questions, comments, or concerns, please don’t hesitate to reach out to Qumulo Support in your dedicated slack channel.
Until next month…
