Autonomy and beyond! StorageOS 2.0 ditches centralised approach for better reliability

Autonomy and beyond! StorageOS 2.0 ditches centralised approach for better reliability

A good month after the first release candidate hit the cloud native community, StorageOS 2.0 is now ready for general consumption, offering users improved error handling and better replication capabilities.

The second major version of the persistent storage project for the container ecosystem comes better tested than its predecessors, thanks to a new infrastructure based on Weaveworks’ VM manager Weave Ignite

The reworked setup allows running test series for release candidates “each on a cleanly provisioned environment to prevent one test from polluting another”, while the team also “layers [..] tests in increasing complexity” for better coverage.

However, there are far more fundamental changes to earlier versions. A primary example is that StorageOS 2.0 allows grouped master/replica units, so-called volume groups, to act independently from the rest of the cluster now. This is meant to improve the system’s scalability and make it more reliable, should individual nodes fail. It also promises to minimise the impact of short network interruptions when compared to the former approach of using one node as central scheduler. 

The project team also looked into security enhancements and added traffic encryption as well as a fully automatic, internal certificate authority to the release. At some point in the future, users will be provided with the option of adding their own CAs for authentication, but for now this should be good enough to facilitate TLS usage for better security.

When seeding or catching up previously offline replicas, StorageOS makes use of a sync engine, which also saw a rewrite in the buildup to the current release. It now utilises a Hash List to find drifts between master and replica volumes, synchronising only changed blocks. This is said to keep impact on the cluster to a minimum and help find failed replicas faster.

StorageOS shares the Kubernetes storage space with projects such as CNCF-hosted Rook, which are lauded for the way they can handle the mostly distributed, more complex setups common in the Kubernetes ecosystem. Most storage vendors, however, offer similar capabilities via APIs and the container storage interface CSI.