Exascale supercomputing poses a number of significant challenges, perhaps none more so that of the storage system, and particularly the software it entails. I/O capabilities in high performance computing have typically lagged behind the computing capabilities of such systems, especially at the high end. If not addressed, these exascale storage issues promise to become even more intractable by the time these first machines start to appear toward the end of the decade.

The motivation to bring storage I/O capabilities in line with exaflops supercomputers lies primarily with the end users of such systems and the storage vendors who will be providing the solutions. Fortunately, a group of stakeholders have come together to help develop a solution.

Soon after its founding in December of 2010, the non-profit European Open File System (EOFS) consortium created an Exascale IO Workgroup (EIOW). Its stated mission is to design and build open source, I/O middleware to meet the needs for exascale storage, with the hope that the resulting solution will be adopted by the HPC community and storage vendors targeting this upper rung of the market.

On February 7 in Munich, Germany, the first EIOW meeting was held to bring the interested parties to the table and kick-start the effort. Peter Braam, who heads up the File Systems group at Xyratex and is one of the principle drivers behind EIOW, helped facilitate much of the initial discussion in Munich. We asked Braam about the outcome of the first workshop gathering, the significance of the EIOW effort, and why exascale I/O needs special attention.

HPCwire: How did the EOFS Exascale IO Workgroup come about and what’s your role in it?

Peter Braam: Factual evidence, such as market trends in chip prices and noise from researchers started to come at us left and right that, possibly, a much more radical departure from the current parallel file system paradigm is needed to approach exascale storage. I talked with Andre Brinkman from the University of Mainz, Thomas Lippert from the Jülich Supercomputing Centre, and Toni Cortes from the Barcelona Supercomputing Center about this and we decided to get something off the ground.

My role is to facilitate the discussions using an industry standard process to design architectures. One point that we all agreed with is that we need to start with the applications, putting aside current models, and what is it that applications will require in the exascale era. So we are currently gathering requirements from application developers as the primary contributors and also with an array of storage experts.

As a result of the insights revealed by this application focus, we are concentrating on middleware. That means the APIs that applications and the runtime can use to control the storage. We don’t intend to specify a backend so that storage vendors can layer this on with either an existing or a new solution.

HPCwire: What the relationship between this effort and other exascale work going on under OpenSFS and the broader Lustre community?

Braam: The initial picture is that the middleware might well utilize Lustre or another parallel file system as a backend store, but that future, newer architectures, for example, distributed key value stores or platforms targeting integrated hierarchical storage like flash, could also provide a backend.

I’m not sure if OpenSFS has discussed this effort just yet, but it has been recently endorsed by EOFS.

HPCwire: I/O in HPC seems like it’s always been behind the curve in regard to user needs. Why do you think this is so?

Braam: Well historically HPC has been so focused on compute that often I/O was an afterthought. However I think quite clearly that is changing, with I/O getting more and more focus. I think one thing that we have done with this initiative is to really focus on what it is the users need, so perhaps with the increased focus on I/O and the user focus we are now bringing to bear, we can address previous imbalances.

HPCwire: Why the focus to fix all this at exascale?

Braam: For up to hundreds of petaflops, a modification to use flash caches or burst buffers will likely provide a “good enough” solution. When we go beyond that, the numbers — the number of drives required — demand a new paradigm of managing data. So exascale is where the game is changing.

HPCwire: At the first workgroup meeting that took place on February 7 in Munich, what were the main topics of discussion?

Braam: The main topics were how application programmers envision using huge data stores, more precisely what their requirements are. It’s probably best summarized in the technical summary at EOFS Exascale IO Workgroup website http://www.eiow.org/technical-summary.

HPCwire: What were some of the exascale I/O requirements discussed?

Braam: The three that were most prominent, and perhaps least expected, were the so-called guided mechanisms: how can applications influence the life cycle of the data in terms of re-use, longevity and importance; the topic of nested metadata, for example, providing “bundles” with all the data belonging to an application; and schemas to describe metadata and data structure.

Finally there was a lot of emphasis on building a stackable system that is general enough to include multiple existing schema providing very clear understandings of, for example, transactional consistency, data integrity behavior through several layers of software.

All the usual suspects including scalability, manageability, diagnostics and performance were, of course, also coming up.