File systems are a critical component of the modern supercomputing architectural model. Tying together vast numbers of compute nodes to achieve the highest computational speeds depends on a set of robust, coordinated fire hoses of data to connect the compute to the storage. Just as the computational model has gone parallel, so too has the storage.

Recent exascale plans call for a technology demonstration system in the 2015 timeframe. That system is planned for 400 petaflops peak and thus requires more data than can be delivered in a single stream. Using the aging ASC* ratios of 1000:1, 400 petaflops would require 400 terabytes/second from the file system.

To satisfy these kinds of I/O demands, should the HPC community start from scratch or build out from current file system technologies? File systems must go ultra-parallel to keep up with increasing data speed requirements, but what technical approach is best?

Evolutionary or revolutionary is the key question.

The hardware story is deja vu. With compute, the answer that worked was to boost performance on the single unit and go widely parallel. Until power limitations and massive parallelism issues get in the way, this approach is a proven strategy. With storage, for hundreds to thousands of storage units, this approach will carry the weight as well. Today, as individual scalable storage units (SSUs) accelerate toward double-digit gigabytes per second, a terabyte per second of I/O bandwidth – the stretch goal for current DOE work – is within reach.

On the software side, however, building parallel file systems has proven to be a challenge. It is widely believed that it takes ten years to mature a file system to the point it is usable in production HPC environments. That is not to say that a newcomer could not steal the show, but it does give some indication of the level of effort required to establish a new file system. By that metric it is already late in the game to start up a new file system project.

As the best example of the evolutionary path, there are multiple and significant benefits to the Lustre file system. It is open source, it is mature, it is widely used in government and academic sites, it has years of strong corporate support and it has the right architectural base from which to conduct cutting edge development.

Lustre is the market leading storage solution for HPC. It is extremely popular, especially in government and academic HPC. Lustre is implemented in about 70 of the top 100 systems in the Top 500 list (http://www.top500.org/) and many of these sites have made considerable investments into using and developing Lustre.

Being open source, Lustre has also been used extensively in the academic community as a development workbench. This has given students and researchers a unique opportunity to try out their ideas “for real” rather than relying on simulation results. When you are looking for solutions to a very large and complicated problem, you can do no better than to have a great number of academic research institutions already familiar with the technology, using it, and contributing to its growth.

HPC file system technologists generally agree that the POSIX storage API imposes fundamental obstacles to scalability and, therefore, will have to be abandoned for exascale. Any unintended contention or serialization is prohibitive at exascale and although there is disagreement on the specifics, there is general consensus that exascale file systems will be based on some sort of object store.

Since Lustre is based on an object store, it already has the right fundamental architecture for exascale. The evolution that is required is to make this object store accessible safely and tractably to applications and users. One possible approach is to introduce new file types to Lustre that will provide exascale object storage semantics internally. This will require development of the underlying object model, but it holds the promise that the same file system will be able to support the full range of applications from (legacy) POSIX through to exascale.

Finally, Lustre is both mature and stable today, which is a necessary starting point for rapid and diverse development. Lustre started as a project in 1999 and was developed by the company that created it, Cluster File Systems, until that company was acquired by Sun in 2007. After the acquisition, Sun and subsequently Oracle invested considerable money and effort in Lustre to prioritize stability and maturity. One example was that in 2008, Sun joined the Hyperion consortium created by Lawrence Livermore National Laboratory (LLNL) and made extensive use of the 1,152 node test Hyperion cluster. The results have been impressive and Lustre 1.8.5 released by Oracle is in wide and stable use throughout the world. At just over 13 years old, Lustre has indeed passed the ten-year-to-maturity metric.

The path to exascale is risky, but an evolutionary approach with Lustre, the leading open source technology, seems the best way to mitigate the risk. Starting over entails re-inventing much of the infrastructure (e.g., networking and data movement, metadata and recovery capabilities) that makes up a distributed file system and seems a needless diversion from getting to the meat of the problem.

By starting with proven, robust and mature technologies, it is possible to focus on the significant issues relating to exascale performance. What's more, an open source solution already popular in the research community primes the research agenda to ensure the best talent is engaged and the best answers will emerge.

The end result may not contain so much of the original Lustre code base and it may not even share the same name by the time we get to exascale. But starting with Lustre gives our community the best chance of success producing the exascale file system performance, reliability and maturity that will be required by high performance computing.

-----

* In 1995, the Advanced Simulation and Computing (ASC) program was conceived to support the Department of Energy’s National Nuclear Security Administration (NNSA) mission of maintaining the country's nuclear arsenal without the benefit of underground nuclear testing.

-----

About the author

Brent Gorda, Whamcloud CEO and President, joined Whamcloud from the US Department of Energy where he was involved in program funding and strategic adoption of the Lustre File System at the Lawrence Livermore National Laboratory and other ASCI labs.