Exascale computing is not just about FLOPS. It will also require a new breed of external storage capable of feeding these exaflop beasts. Panasas co-founder and chief technology officer Garth Gibson has some ideas on how this can be accomplished and we asked him to expound on the topic in some detail.

HPCwire: What kind of storage performance will need to be delivered for exascale computing?

Garth Gibson: The top requirement for storage in an exascale supercomputer is the capability to store a checkpoint in approximately 15 minutes or less so as to keep the supercomputer busy with computational tasks most of the time. If you do a checkpoint in 15 minutes, your compute period can be as little as two and a half hours and you still spend only 10 percent of your time checkpointing. The size of the checkpoint data is determined by the memory sizing; something that some experts expect will be approximately 64 petabytes based on the power and capital costs involved. Based on that memory size, we estimate the storage system must be capable of writing at 70 terabytes per second to support a 15 minute checkpoint.

HPCwire: Given the slower performance slope of disk compared to compute, what types of hardware technologies and storage tiering will be required to provide such performance?

Gibson: While we have seen peak rates of throughput on the hundreds of gigabytes per second range today, we have to scale 1000x to get to the required write speed for exascale compute. The challenge with the 70 terabyte-per-second write requirement is that traditional disk drives will not get significantly faster over the coming decade so it will require almost 1000x the number of spindles to sustain this level of write capability.

After all, we can only write as fast as the sum of the individual disk drives. We can look at other technologies like flash storage — such as SSDs — with faster write capabilities. The challenge with this technology, however, is the huge cost delta between flash-based solutions compared to ones based on traditional hard drives. Given that the scratch space will likely be at least 10 times the size of main memory, we are looking at 640 petabytes of scratch storage which translates to over half a billion dollars of cost in flash based storage alone.

The solution is a hybrid approach where the data is initially copied to flash at 70 terabytes per second but the second layer gets 10 times as much time to write from flash to disk, lowering storage bandwidth requirements to 7 terabytes per second, and storage components to only about 100x today’s systems. You get the performance out of flash and the capacity out of spinning disk. In essence, the flash layer is really temporary “cheap memory,” possibly not part of the storage system at all, with little of no use of its non-volatility, and perhaps not using a disk interface like SATA.

HPCwire: What types of software technologies will have to be developed?

Gibson: If we solve the performance/capacity/cost issue with a hybrid model using flash as a temporary memory dump before data is written off to disk, it will require a significant amount of intelligent copy and tiering software to manage the data movement between main memory and the temporary flash memory and from there on to spinning disks. It is not even clear what layers of the application, runtime system, operating system or file system manage this flash memory.

Perhaps more challenging, there will have to be a significant amount of software investment in building reliability into the system. An exascale storage system is going to have two orders of magnitude more components than current systems. With a lot more components comes a significantly higher rate of component failure. This means more RAID reconstructions needing to rebuild bigger drives and more media failures during these reconstructions.

Exascale storage will need higher tolerance for failure as well as the capability for much faster reconstruction, such as is provided by Panasas’ parallel reconstruction, in addition to improved defense against media failures, such as is provided by Panasas’ vertical parity. And more importantly, end to end data integrity checking of stored data, data in transit, data in caches, data pushed through servers and data received at compute nodes, because there is just so much data flowing that detection of the inevitable flipped bit is going to be key. The storage industry is started on this type of high reliability feature development, but exascale computing will need exascale mechanisms years before the broader engineering marketplaces will require it.

HPCwire: How will metadata management need to evolve?

Gibson: At Carnegie Mellon University we have already seen with tests run at Oak Ridge National Laboratory that it doesn’t take a very big configuration before it starts to take thousands of seconds to open all the files, end-to-end. As you scale up the supercomputer size, the increased processor count puts tremendous pressure on your available metadata server concurrency and throughput. Frankly, this is one of the key pressure points we have right now – just simply creating, opening and deleting files can really eat into your available compute cycles. This is the base problem with metadata management.

Exascale is going to mean 100,000 to 250,000 nodes or more. With hundreds to thousands of cores per node and many threads per core — GPUs in the extreme — the number of concurrent threads in exascale computing can easily be estimated in the billions. With this level of concurrent activity, a highly distributed, scalable metadata architecture is a must, with dramatically superior performance over what any vendor offers today. While we at Panasas believe we are in a relatively good starting position, it will nevertheless require a very significant software investment to adequately address this challenge.

HPCwire: Do you believe there is a reasonable roadmap to achieve all this? Do you think the proper investments are being made?

Gibson: I believe that there is a well reasoned and understood roadmap to get from petascale to exascale. However it will take a lot more investment than is currently being put into getting to the roadmap goals. The challenge is the return on investment for vendors. When you consider that the work will take most of the time running up to 2018, when the first exascale systems will be needed, and that there will barely be more than 500 publicly known petascale computers at that time, based on TOP500.org’s historical 7-year lag on the scale of the 500th largest computer.

It is going to be hard to pay for systems development on that scale now, knowing that there is going to be only a few implementations to apportion the cost against this decade and that it will take most of the decade after that for the exascale installed base to grow to 500. We know that exascale features are a viable program at a time far enough down the line to spread the investment cost across many commercial customers such as those in the commercial sector doing work like oil exploration or design modeling.

However, in the mean time, funding a development project like exascale storage systems could sink a small company and it would be highly unattractive on the P&L of a publicly traded company. What made petascale storage systems such as Panasas and Lustre a reality was the investment that the government made with DARPA in the 1990’s and with the DOE Path Forward program this past decade. Similar programs are going to be required to make exascale a reality. The government needs to share in this investment if it wants production quality solutions to be available in the target exascale timeframe.

HPCwire: What do you think is the biggest hurdle for exascale storage?

Gibson: The principal challenge for this type of scale will be the software capability. Software that can manage these levels of concurrency, streaming at such high levels of bandwidth without bottlenecking on metadata throughput, and at the same time ensure high levels of reliability, availability, integrity, and ease-of-use, and in a package that is affordable to operate and maintain is going to require a high level of coordination and cannot come from stringing together a bunch of open-source modules. Simply getting the data path capable of going fast by hooking it together with bailing wire and duct tape is possible but it gives you a false confidence because the capital costs look good and there is a piece of software that runs for awhile and appears to do the right thing.

But in fact, having a piece of software that maintains high availability, doesn’t lose data, and has high integrity and a manageable cost of operation is way harder than many people give it credit for being. You can see this tension today in the Lustre open source file system which seems to require a non-trivial, dedicated staff trained to keep the system up and effective.

HPCwire: Will there be a new parallel file system for exascale?

Gibson: The probability of starting from scratch today and building a brand new production file system deployable in time for 2018 is just about zero. There is a huge investment in software technology required to get to exascale and we cannot get there without significant further investment in the parallel file systems available today. So if we want to hit the timeline for exascale, it is going to have to take investment in new ideas and existing implementations to hit the exascale target.