The network: Your next big storage problem A few days ago I had an interesting chat with Andy Warfield at Coho Data and the topic of the network/storage relationship came up several times. (Quick disclaimer: I'm currently doing some work for Coho). In a couple of my latest articles (here and here), I talked about why many large IT organizations prefer PODs to other …
Not bad at all.
Mentioning Coho Data and Andy Warfield (who he?) puts it in quasi-Advertorial territory since they're irrelevant to the subject matter, but there was no gratuitous plugging of "DataStream".
Moderately informative content.
Conference plug at the end: innocuous and easily ignored.
I've already run into this on my systems. Server has dual 6 core, HT Xeons, 48 GB ECC RAM, PCIe SSD, at least four SSD's in RAID 0 (currently up to 8 on a PCIe x8 controller btw), and you can see that there's some serious choke-points in normal operation, let alone benchmarks. We'll have to revisit pretty much the entire kernel, component by component, to remove constraints introduced to compensate for the impedance mismatches that either no longer exist or require rebalancing. Certainly Linux and the BSD's look good here since we can examine the code. Windows? Ouch.
Meanwhile, I'm looking to upgrade my storage server and the server above to 10Gbps ethernet. Not enough oomph on the storage server to think about anything faster.
Oh yes, NUMA. Makes me reach for a couple of my 750mg aspirins thinking about that in the mix. Still, the concept applied to storage makes sense. What we're down to is mixed IOPS and latencies but not anything where we used to seeing in the differentials. What I do see, now, is that we may (Hell, no may about it!) need to revisit the assumptions and methods in all database products especially when it comes to all the packages we've been toying with for "Big Data."
I need a beer.
The latency introduced by a network and array controller are always going to be much higher than those of direct-attached storage in the era of SSDs. The future is farms of shared-nothing servers with high-speed NVMe direct-attached storage, with aggregation being done by higher-level protocols or frameworks like Hadoop, Spark, Cassandra, pNFS et al. If you look at all the web-scale operators, Amazon, Google, FB et al, that's how they all operate, none of them use expensive and underperforming arrays. Enterprises will keep buying arrays out of sheer inertia for a little while, but as they shed workloads to the cloud, the dynamic is not favorable to the outdated mainframe-era array model.
"If you look at all the web-scale operators, Amazon, Google, FB et al, that's how they all operate, none of them use expensive and underperforming arrays."
That's not quite true...in fact, "web scale" in the hyper-marketing term that hyper-converged vendors are throwing around right now is actually a legacy design in the operators you name.
There's lots of room in the datacenter for storage platforms and systems... but not expensive, underperforming systems from the legacy boys.
Or is this article positing that networking will become a bottleneck without actually referencing forthcoming changes in network tech?
SDN gets mentioned like once, but the whole thing seems predicated on STP being a bit shit from a throughput point of view... but we already knew STP was shit, which is why things like TRILL and SPB are being worked on to permit multiple paths across the network. We're not going to be consolidating traffic on a single wire once HP and Cisco quit bickering and pick a standard, which kind of breaks the argument.
I thought the really big issue with SCM is that it obsoletes the slow-storage-fast-compute assumption which developers have been working with forever... which is kind of a bigger problem than the networking being slow, since it will fundamentally screw most legacy software.
Or have I missed the point? Genuine question, not being sarky.
I don't believe that Andy is making a protocol/transport comment, he is making an architecture comment. Most storage arrays doesn't increase connectivity (eg number of clients that can access the same dataset at linear high performance increase) with capacity. Even much of available scale out doesnt behave this way and relies on partitioning schemes or gateway schemes to transfer io's to a master node for that part of the name space. Ideal would be if the network path of the system is sufficiently abstracted and virtualized so that adding underlying resources increases bisectional bandwidth and connections linearly to the entire dataset all the way from the client and not only behind the entry point to the system. Linearly scalable front end and backends that parallelize sufficiently for efficient resource utilization without hot spots is hard both for old school numa computing systems as well as for scalable storage.
Or at least this is what I think is the argument the author is trying to make.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
