Six months after organizational changes at Intel’s High Performance Data (HPDD) division, most in the Lustre community have shed any initial apprehension around the potential changes that could affect or disrupt Lustre development. Customers who have adopted the technology as their main parallel file system now have a clearer picture of what the future holds for the world’s most utilized parallel file system. Lustre remains strong and will continue to dominate the persistent parallel file system arena, at least for the foreseeable future.

The new Lustre development and adoption strategy has turned out to be surprisingly simple, and more clear and consistent than anticipated. Like the old Whamcloud days, Lustre development has returned to a single code stream, thereby avoiding confusion and lack of discernment regarding different distributions, features, capabilities, and source code differentiation. Quietly released in July 2017, 2.10 is the LTS (Long Term Support) release of Lustre that should be the mainstream version through mid to early 2019.

As a major contributor to the Lustre community, DataDirect Networks (DDN) announced in 2016 that all of its Lustre features will be merged over time into the Lustre master branch. This convergence gives the entire community transparent access to the code, reducing the overhead of code development management and better aligning with the new features released in Lustre 2.10.

A very sophisticated set of features has been announced on Lustre 2.10 such as Progressive File Layouts (PFL), Project Quotas, IB Multi-rail and NRS Delay policy. Progressive file layouts allow system administrators and users to adjust file layouts, and how a file is stripped – the number of stripes and stripe block size now may vary according to the file size. There are several use cases that would take huge advantage leveraging PFL while simplifying the storage administration in the process. The storage administrator could define standard default layouts for different types of files, minimizing the need of users to manipulate file layouts by themselves (although the user is still able to define their own layouts). With the increasing utilization of flash technologies in a hybrid parallel file system (SSDs and NVMe devices mixed with standard rotational drives) it is now possible to create sophisticated mechanisms to optimize data location using PFL and OST pools.

Another feature, possibly the most latent need among the current Lustre users, is the Project Quotas. Project Quotas allows quota definition per “Project” which could be, for example, associated with a specific directory. Previously, Lustre only allowed standard POSIX User and group quotas. With Project Quotas we move one step ahead on the realm of managing spaces among users, groups and projects and planning for capacity and growth. Project Quota adds space accounting and enforcements of capacity utilization based on OSTs, sub-directories and file-sets, providing the granularity needed to manage several different use cases.

Some have asked about the impact of performance related to Project Quotas. Results of various tests have been impressive and encouraging, showing no degradation compared to the standard POSIX quota. Project Quotas is a feature available for Lustre running with a LDISKFS backend.

Although the feature has been only landed on Lustre 2.10, as the developer responsible for this feature, DDN has backported it into its Exascaler 3.2 (based on Lustre 2.7). Historically speaking, the latest and greatest version of Lustre usually brings the most advanced technologies with a price to pay, which is the un-tested and unproven chunk of codes that usually require a few cycles to stabilize. Since Project Quotas is a need for a huge range of customers that are not ready to move to Lustre 2.10 currently, Lustre 2.7 users can get the ability to run Project Quotas and get full support for it. In the case of customers running Project Quotas on Lustre 2.7, once they decide to upgrade to Lustre 2.10, data will be totally preserved (note that any users going from Lustre versions prior to 2.7, to Lustre 2.10 and activating Project Quotas require a reformat of the file system).

LNET IB Multi Rail allows users to take advantage of multiple infiniBand adapters, aggregating the bandwidth for Lustre LNET. This technique is widely used by Ethernet users through Ethernet Bonding. InfiniBand users were previously unable to “bond” interfaces and they were somehow limited to the performance of a single IB card. There was a need for increased bandwidth, especially on the client side. New architectures, such as HPE UV, have multiple sockets and a huge amount of memory capable to run multiple and much larger compute jobs. Those scenarios bring an unbalanced CPU/MEMORY to IO ratio, where even an IB EDR running 100Gbps may turn into a bottleneck. IB Multi Rail leverages Lustre on larger SMP like nodes, aggregating network bandwidth performance and proving a balanced CPU/Memory to IO ratio. On the server side, the biggest advantage is on the high availability capabilities. Having more than one IB link provides redundancy, avoiding scenarios that trigger server failover due an IB failure. Now in network failure scenarios the failures and their recovery are handled transparently, without compromising on performance.

NRS delay policy, which simulates high server load as way of validating the resilience of Lustre under load, is another feature introduced in Lustre 2.10. This is one valid way to perform fault injection and load simulation, usually very important during stabilization phases, performance characterization and overall debugging techniques.

Along with these recently announced features, a new approach has been proposed for Lustre’s policy engine (LiPE), designed to reduce installation and deployment complexity while delivering significantly faster results when executing and managing storage policies. LiPE relies on a set of components that allows the engine to:

• Scan Lustre metadata targets (MDTs) quickly,
• Create an in-memory map of the file system’s objects, and
• Implement data management policies based on that mapped information.

This approach would allow users to define policies that trigger data automation via Lustre HSM hooks or external data management (copy tools, for example) mechanisms.

In the next stage of development, LiPE may be integrated with a File Heat Map mechanism for more automated and transparent data management, resulting in a better utilization of parallel storage infrastructure.

In regard to Lustre performance, a new initiative within the community is investigating the implementation of high-level tools, possibly at the user level, that would improve utilization and configuration of Lustre Quality of Service (QoS). In support of those efforts, a new QoS approach has been developed that is based on the Token Bucket Filter algorithm on the OST level. It allows system administrators to define the maximum number of RPCs to be issued by a user/group or job ID to a given OST. Throttling performance provides I/O control and bandwidth reservation that can guarantee that higher priority jobs run in a more predictable time, avoiding performance variations due to I/O delays.

In keeping with new HPC trends, a tremendous amount of work has also been invested in the integration of Lustre with Linux container-based workloads, providing native Lustre file system capabilities within containers, support for new kernel and specialized Artificial Intelligence and Machine Learning appliances.

2017 was a productive year for Lustre that showcased a very active and growing Lustre community and that positioned Lustre as the “go to” choice for many high-performance computing organizations and data centers. Moving into 2018, look for Lustre roadmaps to solidify this position with enhanced security, performance, Remote Access Service (RAS), and data management capabilities, as well as the addition of more enterprise-class features.