* Posts by NickT

4 publicly visible posts • joined 18 Sep 2015

HPE's Nimble Secondary Flash Array uses... disk?

NickT

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

Pure Storage to punt out supersized FlashArray system

NickT

Re: Nimble's AFA?

Disclaimer: Nick Triantos Nimble Employee

Nimble's AFA scales to 553TB raw per system, x 4 for scale-out = 2.2PB Raw. Effective would be 8.1PB using a 5:1 data reduction.

How many VMs it supports? Well a vague question deserves a vague answer :-)

It depends on what the VMs do.

This applies to everyone except those who have figured out a way to beat common sense. :-)

Cheers

Nimble whips out fat boxen: We're here for the all-flash array market

NickT

A few thoughts

Hi everybody,

Disclaimer: My name is Nick Triantos and I am and Nimble Storage employee

Lots of interesting comments in the thread, some with good intent, so I will dignify those.

For those not familiar with the Nimble Architecture...

CASL is a Log Structured Filesystem. Two of the basic principles of Log structured file systems are that you only write in free space and that space that has already written to can't be overwritten until it’s garbage collected first. If this this sounds familiar it’s because this Principle that also exists in Flash.

https://lwn.net/Articles/353411/

In fact, all SSDs under the hood use a form of a Log Structured File System (link above). Why ? Because, unlike disk, reads and writes in Flash are very Asymmetric. It takes much more time to erase and write a flash cell, than it takes to read. Flash also has a finite lifetime, therefore how storage writes to it becomes very important.

CASL writes to SSDs in chunks. A chunk is the amount of data that will be written to an SSD before writing to the next. Our chunk size is an even multiple of an Flash Erase Block. This leads to lower write amplification and wear.

Additionally, our RAID layout has changed. We write across 20 data drives vs 9 which means our Segment size vs our Hybrid has increased by 2.5x. Additionally, we use some of the SSD overprovisioned space as spare chunks. That allow us to reserve less space for rebuilds as well as have one of the highest raw:usable % in the industry.

Furthermore, not only do we protect against ANY Three Simultaneous SSD failures vs the standard industry approach of 2, but we also provide Intra-Drive Parity which affords us the ability to recover from 1 sector failure on the remaining SSDs.

Anyone who has read Google's recently published USENIX paper on a 6 years SSD reliability study, will understand why we provide these extensive levels of Data protection along with Data Integrity techniques for Lost and Mis-directed writes, segment checksums, snapshot checksums, Quick RAID rebuilt and many more only found in Tier 1 Enterprise systems.

http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/23105-fast16-papers-schroeder.pdf

CASL also does system level GC and uses the TRIM command to notify SSD Flash Translation Layer (FTL) of copy forwarded blocks. We do this to optimize write efficiency.

Throughout our development and almost 6 mos beta process we've used IDC's vdbench guidelines to test our AFA just so to make sure our performance isn't impacted like some of our competitors when capacity increases to dangerous levels and with inline data reduction on. So we don't take our foot of the pedal and continue process *everything* inline.

Lastly as a common sense point…, any architecture who can so effectively and transparently Garbage Collect on an SATA and NL-SAS drives as CASL has done the last 6 years, can Garbage Collect on SSDs.

Thank You

Nick Triantos

Nimble flashes the all-flash array as ‘intense’ consolidation period approaches

NickT

Re: Not so fast...

Disclaimer: I work for Nimble Storage

CASL is a Log Structured File system. Log Structured file systems maintain a log within the file system itself. Data and metadata are written to the disk, in the form of a log.

Do not confuse Log Structured file systems like CASL, with logging file systems. Logging filesystems track changes to the file system in a separate circular log or transaction log which is separate from the on-disk data. Logging file systems have been written for and optimized for disk and while they do write in free space they also fill holes when contiguous free space become scarce.

The principle of a Log structured file system is that once blocks are written they can't be overwritten until they are completely erased. Does this sounds familiar in the SSD world? Thus new writes or overwrites are written in Free space. This is done primarily to improve upon the write efficiency of the file system and reduce Write Amplification. Older or invalid, data blocks are garbage collected and erased which means CASL is not a write in place file system, is not a hole filling file system which also means CASL does inherently system wide garbage collection already. This process should also sound familiar as we think about SSDs.

Also CASL already provides variable block inline compression and inline zero block dedupe which means fewer back-end writes again minimizing WAF and extending endurance while minimizing wear. Additionally, CASL already writes in large segment chunks per drive corresponding to an even multiple of SSD blocks. So we do pay very close attention how we write because although our cache is used for read-acceleration we do have to write blocks to it for reads...

By the way, all SSDs internally use some form of a Log Structured File system today.

https://lwn.net/Articles/353411/

Cheers

Nick Triantos