Computational storage: A Computer Weekly analysis series
Software runs on data and data is often regarded as the new oil. So it makes sense to put data as close to where it is being processed as possible, in order to reduce latency for performance-hungry processing tasks.
Some architectures call for big chunks of memory-like storage located near the compute function, while, conversely, in some cases, it makes more sense to move the compute nearer to the bulk storage.
In this series of articles we explore the architectural decisions driving modern data processing.
Enter… computational storage
The Storage Network Industry Association (SNIA) defines computational storage as follows:
“Computational storage is defined as architectures that provide Computational Storage Functions (CSF) coupled to storage, offloading host processing or reducing data movement. These architectures enable improvements in application performance and/or infrastructure efficiency through the integration of compute resources (outside of the traditional compute & memory architecture) either directly with storage or between the host and the storage. The goal of these architectures is to enable parallel computation and/or to alleviate constraints on existing compute, memory, storage and I/O.”
TechTarget reminds us that what is really unique about computational storage devices is the inclusion of one or more multi-core processors. These processors can be used to perform many functions, from indexing data as it enters the storage device to searching the contents for specific entries to providing support for Artificial Intelligence (AI).
Areas for discussion
Computational storage enables a software and hardware system to offload and alleviate constraints on existing compute, memory and storage — so given this truth, how should software engineers identify, target and architect specific elements of the total processing workload to reside closer to computational storage functions?
In other words (to the above), how do we make the computational storage cut?
How much refactoring does it take to bring about a successful computational storage deployment and, crucially, how much tougher is that operation when the DevOps team in question is faced with a particularly archaic older legacy system?
If we agree that computational storage reduces Input/Output (I/O) bottlenecks and opens the door to greater data processing speed for certain applications, then is it only real-time apps and data services that really benefit, or are there other definite beneficiaries of this lack of latency?
With computational storage, we know that data is processed at the storage device level to reduce movement between the storage plane and the compute plane, to what degree does this approach directly enable Internet of Things (IoT) applications where we need to put as much total power as we can out on the edge?
In terms of nomenclature, computational storage is a storage subsystem, so there will be a requirement (at some point or other) to network all storage resources to gain a holistic view of system health… how is it that this administrative responsibility doesn’t ultimately create more work?
What is the computational storage payoff? As Computer Weekly has reported, research by the University of California Irvine and NGD Systems suggests that eight- or nine-fold performance gains and energy savings are possible, with most systems offering at least a 2.2x improvement… so how big is the real (or good) is the computational storage payoff?
We know that computational storage is effective when used within datacentres designed to manage and deliver media and entertainment needs for data streaming — given our online-always existence, could data streaming be the next killer app (or app function) to come?
In terms of definition and delineation, the SNIA separates out computational storage into:
- Fixed Computational Storage Services (FCSS) – optimised for compute-intensive workloads including compression or encryption… and so delivers a superior performance to cost ratio.
- Programmable Computational Storage Services (PCSS) – which can run a complete host operating system, normally Linux.
Given this duality, do organisations approaching their first use of computational storage know the difference and know how and when they should be looking at either option?
According to the Journal of Big Data, “Catalina is the first Computational Storage Device (CSD) equipped with a dedicated application processor running a full-fledged operating system that provides filesystem-level data access for the applications.” So how fundamental could Catalina be and what do we need to know about it?
The data-driven road ahead
Linux is widely agreed to be key to the onward development of computational storage. The open ecosystem of open source Linux is a key facilitating technology to creating the secure containerisation principles that express key elements of computational storage, but what really matters most when we consider the role of Linux here?
To really drive the adoption of Computational Storage Devices (CSDs), some technologists (ARM has said this) say that On-Drive Linux will be key. If standard hard drives rely upon NVMe (non volatile memory express) protocols to dispatch (or retrieve) chunks of data, then although that process works fine, the Solid State Drive (SSD) itself will remain blissfully ignorant of what the data it holds actually is, does or relates to i.e. it could be an image file, a video or voice file or it could be a text document, spreadsheet or other. Linux on the other hand has the power to mount the file system relating to the data that the SSD stores and be able to achieve awareness and cognizance of what the blocks of data actually are – discuss!
There are negatives with computational storage i.e. the network architecture required to run computational storage is inherently more complex and software engineers will need to think about the number of Application Programming Interfaces (APIs) that will needed to be “informed” about the existence of computational storage if systems are to progress forward – could this be the biggest challenge and if not, what else?
It’s still early days for computational storage and the SNIA itself only came into being as recently as 2019, so (arguably) we don’t even have 5-years worth of discussion, experimentation, prototyping and analysis to draw upon in the computational storage space… doesn’t that present a challenge and will standardisation milestones be the next key requirement for this technology?
We know that prime movers in this space include Eideticom, Samsung, NGD, Nyriad and ScaleFlux and we hope to feature insight from all of those usual suspects and more… come with and no dozing off please, this is storage not snorage.
Image: Wikipedia