HPE's Nimble Secondary Flash Array uses... disk? Having acquired Nimble Storage and its hybrid and all-flash arrays, HPE is positioning it as a kind of secondary storage. What does that mean? Its mainstream enterprise external storage product is the StoreServ 3PAR line of ASIC-accelerated hybrid and all-flash arrays, an XP7 array OEM'd from Hitachi. The Nimble arrays are …
My company has the pleasure of contributing to that 23,000 plus array count.
the CS-500 we have is easily on par with the 3240 pair that it replaced, as far as performance; we've not seen any evidence of I/O performance bottlenecks. If anything, the performance issues we have are on the host side. (something about having management deciding to cram 3 nodes worth of VMs onto a single blade without listening to the grunts screaming otherwise about it.)
While I don't have any comparison of Netapp vs the CS-220s we have, we've been running a couple of our sites on them since 2012 without a major hiccup, and only once instance of (scheduled) downtime (which was to move the appliance into a different cabinet.)
Not "designed" for Six Nines, but MEASURING 6 nines across the entire install base.
Upgrading performance, OS updates, adding capacity shelves, swapping controllers, disks, NICs, even migrating data from 1 array to another array... ALL happen with ZERO downtime to your end users.
Show me another product on the market that can do that and lunch is on me!
For years we called our Hybrid systems “Adaptive Flash Arrays” and apparently this was a non-issue...
That being said, we call it secondary Flash, because it performs like an AFA for the intended target market given the 100% inline data services it provides (Dedupe, Compression, Zero Pattern elimination)
I'm sure you'll agree it is very impressive for a hybrid system to run 100% inline dedupe and compression using High density drives. I could be mistaken, but I don't believe there are HFAs out there that run 100% inline data reduction without needing a massive flash staging area.
Secondly, the system is not just a backup Target. It is intended for those customers who would like to put their backups to work and expand usage onto test/dev and secondary workloads. Therefore, we needed to achieve a balance between IOPs and TPUT for the intended market and price bands.
Hope this helps
HPE-Nimble Employee
Nick Triantos
Disclosure netapp employee- opinions are mine not my employer
So "adaptive flash" and "secondary flash" are the "I can't believe it's not butter" of the flash array storage world ? Any way you cut it, they're hybrid flash arrays, with all the benefits and drawbacks that go along with that. Inline compression isn't hard to do, but if you're doing inline dedup and have to do inline verification of the blocks by reading them from NL-SAS drives as new writes come in, your performance drops off a cliff. Arrays that are truly optimised for secondary storage (Data domain and AltaVault) can get away with that using only NL-SAS but they know they'll never see a random read or write workload ever so they can ignore that usecase entirely. Unless something has changed CASL isn't like that.
I'm sure the tech is good, and that if you're careful with your workloads it should perform OK, but that's not what people expect out of a flash array, that's what you get from any well engineered and sized hybrid array.
It's called secondary flash ... But it's not actually flash is it ? it's a hybrid mix of mostly disk with a little bit of flash. I don't have an intrinsic problem with the tech, just the innacurate marketing name.
I'm also unconvinced about performance on a cache miss during inline dedup, but that's a different issue.
Hi all, Dimitris from HPE-Nimble here (http://recoverymonkey.org)
Nimble global inline deduplication in the SFA is extremely optimized so that what the user ends up with is a hybrid system that's really cost-effective and space-efficient, capped at about 40K r/w IOPS.
It's fully compatible with existing Nimble estates so it can be a replication target, etc. But it also has extremely deep integration with products such as Veeam.
The typical use case is things like backups that you can actually use to do stuff with (testing, development, whatever) without needing to restore first.
But I can also see people buying this to be even a general-purpose, very efficient system, as long as their performance needs fit what it can do.
If one needs to go very fast and have great data reduction, then a full-blown AF is of course the preferred vehicle. Less expensive yet fast and with decent data reduction, then a CS hybrid is still the answer.
Hybrid systems from other vendors typically can't sustain large-scale inline deduplication (notice how most vendors that offer AFAs and hybrids only offer the cooler inline data reduction tech for AFAs only).
Thx
D
This is a poorly-researched article.
Nimble has BOTH Adaptive-Flash and All-Flash arrays, and now a backup target that fits (REALLY well) into its respective niche. And Nimble (and Veeam) freely admit it fits a niche, so what's the problem?
Despite having a way to offer NEAR INSTANT Backups & Restores, and USE those backup imagies in innovative ways, you're preoccupied with, and judging it on, "throughput speeds"??? Clearly, you don't "get" the concept behind the SFAs.
It probably can; Data Domain appliances are generally fast on the ingest, but slow on the rehydration/restoration side. Empirical evidence based on dump SQL full backups to a DD-640 via a CIFS share. Same file that took 10 minutes to dump to the unit took a good 15 to restore directly back from it.
It takes me ~20 minutes with the Web GUI for both Nimble and vCenter to resurrect a machine from a cloned snapshot sitting on the nimble; most of that time is spent with the ESX host spinning it's wheels picking up the LUN; The downside is that it's a pot shot if the snapshot contains a viable machine, only because we don't have the nimble ask vCenter to quiesce the VMs on the volume. (it's on my list of 'things what need to be fixed in my copious free time')
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
