This is probably the most important improvement made to OpenIO. It is the first step towards what we call Service ID directory.
Instead of mapping internal services to IP addresses, they will be mapped to an internal service directory that is always accessible to all nodes in the cluster. By doing so, IP addresses are no longer important and cluster node addresses can change at any reboot. This feature will allow us to support hybrid (on-premises + cloud) configurations, Docker containers, and Kubernetes in production.
At the same time, many sysadmin operations will be simplified especially for cluster expansion, failures, disaster recovery, or node decommissioning.
As you may know, we have a FUSE-based file system connector: OIO-FS. It is a simple file system interface that maps a container to a file system so it can then be mounted on a Linux host.
Our customers initially adopted OIO-FS for use cases such as migrations, support of legacy file-based applications, backup targets, and so on. Later, they started to ask more from it, and we worked hard to improve its performance and usability with improved caching and a simplified internal data path.
The WebUI has been updated to support OIO-FS and simplify NFS mounts as well.
The FUSE-based file system connector has been improved, and this connector is now part of the standard subscription; all our customers will be able to take advantage of it without any additional cost. OIO-FS Enterprise will be available with the 18.10 release as an extra module for the standard subscription and will include the HA (High Availability) capability.
Improved S3 compliance
Our work on S3 compliance is constant; we continuously check with our customers to ensure that the S3 API and all its extensions attain the best compliance and map internal features and APIs correctly to S3 and Swift. In this release a lot of work has been done to assure that versioning and lifecycle management is consistent across different APIs and aligned with expectations of our customers.
Container snapshots (beta)
This is one of the coolest features we have introduced, in my opinion. It looks like a traditional snapshot from the outside, but internally the new container is built by duplicating metadata and links to original data chunks at the moment of the snapshot creation. Practically, you can create a new container (bucket), starting from an existing one, pointing to the same data chunks as the original container. Operations performed on the new container do not affect the original data, but create new objects or data chunks for their updated parts.
Container snapshots are very useful in big data and testing environments, for example, where you can have a copy of a data set quickly available to run applications against and destroy it afterwards.
Simplified deployment tools
The new scripts, based on Ansible, now include a pre-flight check procedure and all the necessary processes to make new nodes compliant with OpenIO requirements. This is not quite a “one-click” installation yet, but we are getting very close to it!
In addition, the entire set of playbooks has been simplified, output is more descriptive, and configuration files make it possible to set up more cluster parameters during the initial deployment, which also results in a smoother, simpler process.
As you can see, OpenIO 18.04 brings a lot of improvements, and also some new features, which are aimed at making the product more flexible, smarter, and faster.