Cray slaps an all-flash makeover on its L300 array to do HPC stuff

What is the goal to be accomplished?

Let's assume for the moment that we're talking about HPC. So far as I know, whether using Infiniband or RDMAoE, all modern HPC environments are RDMA enabled. To people who don't know what this means, it means that all the memory connected to all the CPUs can be allocated as a single logical pool from all points within the system.

If you had 4000 nodes at 256GB of RAM per node, that would provide approximately 1 Petabyte of RAM online at a given time. The amount of time to load a dataset into the RAM will take some time, but compared to performing large random access operations across NVMe which is REALLY REALLY REALLY slow in comparison, it makes absolutely no sense to operate from data storage. Also, storage fabrics, even using NVMe are ridiculously slow due to the fact that even though the layer-1 to layer-3 are in fact fabric oriented, the layer 4-7 storage protocols are not suited for micro-segmentation. As such, it makes absolutely no sense whatsoever to use NVMe for storage related tasks in super-computing environments.

Now, there's the other issue. Most supercomputing code is written using a task broker that is similar in nature to Kubernetes. It spins up massive numbers of copies related to where the CPU capacity is available. This is because that while many super computing centers embrace language extensions such as OpenMP to handle instruction level optimization and threading, they generally are skeptical about run-time type information which would allow annotation of code with attributes that could be used while scheduling tasks.

Consider that moving the data set to the processor upon which it will operate can mean moving gigabytes, terabytes or even petabytes of memory transfer. However, if the data set were distributed into nodes within zones, then a large scale dataset could be geographically mapped within the routing regions of a fabric and the processes which would require moving megabytes or gigabytes at worst can be moved to where the data is when needed. This is the same concept as vMotion but far smarter.

If the task is moved from one part of the super computer to another to bring it closer to the desired memoryset, the program memory can stay entirely in tact but only the CPU task will be moved. Then on heap read operations the MMU will kick in to access remote pages and then relocate the memory locally.

It's a similar principle to map/reduce except in a massive data set environment, map reduce may not work given the unstructured layout of the data. Instead, marking functions with RTTI annotation can allow the JIT and scheduler to move executing processes to the closest available zone within the super computer to access the memory needed by the following operations. A process move within a supercomputer using RDMA could happen in microseconds or milliseconds at worst.

Using a system like this, it could actually be faster to simply have massive tape drives or reel to reel for the data set as only linear access is needed.

But then again... why bother using the mllions of dollars of capacity you already own when you could just add a few more million dollars of capacity.

ClusterStor node uses slower SAS SSDs Cray has announced the L300F, an all-flash array for high-performance computing functioning as a speed booster for ClusterStor installations.