tester

In the modern world, keeping your systems running isn’t just table stakes – it is non-negotiable. 

When it comes to software updates and what that means for your systems – well that is more complicated. On the one hand, security is the primary driver of updates today and that too is non-negotiable. Patches need to be implemented as soon as possible and across all systems to maintain the strongest security. 

The same holds true for software updates that carry important bug fixes, performance improvements and enhanced functionality. They too should be implemented in a timely fashion to leverage the improvements within. 

But what about downtime? Depending on your environment and operational processes, when security patches and software updates are applied, you may incur minor downtime due to service restarts, and you may introduce buggy code that causes major downtime until it is rolled back or updated. The puzzle of how to update and patch in a timely fashion without downtime is a tough one, and you need to make the right architectural decisions or your environment doesn’t stand a chance of being highly available.

The solution is to rely on software that guarantees sub-second restart times, even across hundreds of nodes. This is an area where we have invested heavily and, as a result, upgrading AIStor, even at scale, is non-disruptive. In this post we will outline the philosophy behind our approach and show you how to perform the non-disruptive upgrades that your high availability object storage requires.

AIStor is focused on non-disruptive restarts because we know how important your data is to you. Data is the blood of the modern enterprise. That means data storage is the heart. If it stops, the blood stops flowing – and, well, bad things happen. Since everything from applications, ETL, workflows, databases, AI/ML – even CDNs – depend on data, the data storage system must always be available – even as it consumes security and release updates. Failure to achieve non-disruptive upgrades accumulates technical debt and creates negative incentives for upgrading, thereby reducing the utility of the software and increasing risks to data privacy and ongoing business operations. 

General Principles

With AIStor, like with time, stability moves in one direction. The latest AIStor release will always be the most stable. Modern CI/CD oriented developers will understand this, while old school architects may not – but we assure you it is true. AIStor releases frequently, but intentionally, and each release is carefully planned, developed and tested. We always encourage our customers and community to be on the most recent release. 

Bugs found are fixed and are merged with the upstream from where the latest releases are made from. If specific customers require the fix can be backported on request, these are patches applied to older versions. Weekly latest releases are always made from the upstream. So our customers and community can rest assured that the latest version has the required fixes for the current version you are using, regardless of how old that version is.

While everyone should be on the most recent release, we also recognize that our release cadence and your deployment cadence, coupled with the necessary internal processes, may not coincide.  In a world where everyone runs a multitude of software packages and open source frameworks, it is rarely the case that all release and deployment cadences overlap.

Your cadence shouldn’t impact your downtime – and with AIStor it does not. 

So how does AIStor handle all of this? First and foremost, AIStor’s latest binary version  ensures that it is backward compatible with the oldest version possible. If the data is written in an older format, for example using the previous metadata structure, the new version will have logic to read it and perform an in-place upgrade of that data to the new format. The migration logic from each version is baked into the code itself so you don’t need to perform extra steps to update. 

In Linux, the package manager manages the config change. But this can get cumbersome because we need to teach the package manager about every single change. It’s a chain of all the changes someone has to remember and scripts to apply them.