back to article Keep up with the fast-moving world of all-flash array storage

An all-flash networked array can do wonders in speeding up data accesses by applications running in connected servers. It is obviously best if the all-flash array is seamlessly integrated with your existing networked storage infrastructure. Suppliers of new integrated flash arrays say that getting the best use out of flash …

  1. Guus Leeuw

    Dear Chris,

    "existing disk array suffer from latency". Really? Sure, if the cache is full and no intelligent pre-fetching is implemented. Ie not very often...

    "Virtualising servers and threading application software makes the servers much better at keeping their cores busy processing application code than the old inefficient multi-tasking operating systems such as Windows NT and Unix." The same old inefficient multi-tasking algorithms that live nowadays within the same old operating systems such as Unix are now performing far better, due (in large) to the way modern CPUs are designed and implemented. Virtualising a server does nothing towards making that server run faster. In fact, virtualising a server vs putting that server on the same physical hardware as the hypervisor would logically dictate that the latter will outperform the former!

    "Effectively, a two-socket, 12-core server has 24 cores running in parallel" - How is it that a two-socket 12-core server has 24 cores running in parallel? The fact that there is a socket doesn't mean that there is a CPU which may have 12 cores... Be precise, and you will see that in your own head things all of a sudden actually make sense... It has been said before: Don't use one word to mean something else than its very definition. Socket != CPU...

    "and imposing a storage array access burden that is roughly 24 times greater overall." In the past we had 24 single CPU single core servers running those applications. Inefficiently, but still the workload was there. The fact that this workload is now centralised on one server that has 24 cores doesn't make a difference in terms of workload for the storage array... The workload may come to the array more densely, but just saying that a 24-times more powerful machine will request 24 times more data is cutting the corner a bit too finely, Chris!

    "CPUs access data from main memory in nanoseconds" CPU access data from a storage array in nanoseconds as well, Chris. What you mean to say is that internal memory is accessed far faster than external memory. Accessing external memory that sits on mechanical drives and is accessed directly (by by-passing caches on the way) is slower still.

    "In the time it takes for a disk array access, say 7 milliseconds, a waiting CPU core could execute 7 million instructions." 7 milliseconds = 7000 microseconds = 7000000 nanoseconds. Gigaherz stands for the number of cycles in billions per second. so 3 Ghz executes 3 billion parts of instructions per second. Therefore in one millisecond, 3 thousand parts of instructions are executed. Thusly, in 7 milliseconds, 21 thousand parts of instructions are executed. Why "parts of instructions": not every assembler instruction takes just one cycle to complete. 1 nano = 10^-9, 1 milli = 10^-3, one GHz = 10^9, one Mhz = 10^6... just dropping or adding 10^3 is a bit of a leap, IMHO.

    quoting Flash array supporters: "and that means your servers can do more"... No, it actually means that your servers do less waiting for data than when compared to traditional storage arrays. Why would one want to put the word "can" in there? "Can" is a statement of uncertainty: they can, but they also cannot... "coulda woulda shoulda; didn't"...

    "as you move up the list" - you mean, as you move down the list?!!

    "applications such as financial trading and mass online sales" - Please clarify, what are mass online sales? amazon-mass, where a billion people by one product each? resulting in tiny storage transactions, but a whole lot of them, and where each transaction is "old" after 1 month? How is financial trading stacking up against flash-only? Is it jusitified?

    What you see a lot of the time, and flash unfortunately helps in this regard, is that people write bad software, that uses a badly designed (and sometimes worse implemented) database, all of which sit on a number of servers not designed for the job at hand, all of which want storage.

    Keeping all your data in live tablespaces, and not having appropriate indices, and not managing existing *and* minimising the impact of slow queries, not appropriately paging answer sets, etc etc all make it look as though faster storage is the solution. But let's not forget that faster storage in 80% of the cases will only ever give a 20% better performance for the end-user (if that...)! And for the 20% where faster storage actually makes a big impact: well, that's very often to do with over-saturation at the storage end, so badly managed capacity and system usage...

    Flash helps, but let's not just throw flash at a badly written application and make it run faster... It's better to get a good team of people to write and operate good software/databases/servers, than to just chuck millions at a randomly generated problem because some dope forgot to put an index on a textual column somewhere...

    I don't quite agree with your conclusion. Flash arrays are good, for sure, but should be implemented where justified, and just across the board because somebody doesn't want to actually fix the software...

    Just my two cents,


  2. Ant Evans


    @Guus, flash is indeed used to mask poor design, just as fast processors and more RAM are used to mask poor design, especially in the database world. But the poor design is not always in the application layer. OSes have got bigger than most apps, and they are storage pigs with big peak loads, bigger management overhead, and a lot of redundant writes. Customers can't really optimize OS workloads significantly. Virtualizing whole machines exacerbates this linearly. So you can thank MSFT and VMW for some growing fraction of storage demand, and for a chunk of the demand for flash, which handles stormy workoads better than Winchester disks.

    Flash is not the only way to deal with boot storms - you can create virtual clones and serve common blocks from RAM, maybe until Patch Tuesday. But flash is both easier than cloning, and reassuringly expensive.

    Interesting that Chris only mentions flash cache once (flash array type 2). This is not what most people think of as a flash array, but any serious array has had flash and NVRAM for years. For dull workloads, cache works, and you don't need solid state storage at all. Nobody seems to want to hear this. It's just not flashy enough.

    Finally, while consolidation is actual magic, it has some obvious and undesirable side effects: you get an increasingly entropic workload. You might not even know what's running on your array. Maybe caching will work next week, and maybe not. Why hang your arse in the wind? Faster gear makes for shinier underpants. Always has.

    1. Trevor_Pott Gold badge

      Re: Cache

      DRAM cache is never the solution to a disk array. Fucking. Never. Oh, life's good until you run out of bloody cache, then you're not going from DRAM to NAND, you're going from DRAM to crushing up flowers and smearing the walls with the results.

      Disks are slow and horrible. They are a last resort, nothing more. Every time you have to read or write directly to disk you have failed. And if the only think between your application and those disks is DRAM, you are setting yourself up for failure at the moment of highest demand...right when you need it to just work more than you've ever needed it to do so before.

  3. Nate Amsden Silver badge

    hybrid not tiering

    IMO anyways more traditional folks that have SSD+HD in the same system and do sub LUN tiering aren't hybrid. I would call that tiering. I would call hybrid more transparently integrated like Nimble, or a few others that I forget the names now because I'm really tired.

    I got my 7450 installed on monday though so I'm pretty happy. maybe next week will have time to play with it

  4. storman

    Understand Your workloads first

    Deciding the best AFA, HFA, or ADA vendor/product for your specific application workloads is the not an easy decision. The key to successfully deploying flash is to fully understand the workload performance requirements before making purchase or deployment decisions. The only way to make intelligent decisions is to use workload modeling and storage performance validation solutions from companies like Load Dynamix. Every workload will perform differently on each vendor's products. For example, the vendor's implementations of dedupe and compression can impact flash storage response times by a factor of 3X or more. Storage performance validation tools give you the data to make educated decisions on flash and hybrid deployments

    1. Trevor_Pott Gold badge

      Re: Understand Your workloads first

      When considering spinning rust even as a possibility you need to go beyond "modelling". You need to ask yourself "how gracefully does this degrade"? "What will happen if my requirements suddenly spike?" Most importantly of all: "how heavy is the weight dangling above my sensitive bits if performance should spike and the DRAM cache should start diverting requests to the disks"?

      Flash starts looking very good, very quickly.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019