back to article Quick as a flash: A quick look at IBM FlashSystem

IBM completed the acquisition of TMS (Texas Memory Systems) in October 2012. The company (TMS) has a long history of developing memory-based storage products, based initially on DRAM and later SLC and eMLC technology. I looked at the ramsan range years ago as a potential customer and my abiding memory is the relative cost of the …

  1. Nate Amsden

    I think I know the answer

    But the most obvious question to me is - is there a reason to buy these products unless you are already an 'IBM shop'.

    To me the answer has always been no. In the earlier days of TMS the cost was always too high for companies I have worked for, in the more recent years the competition is more than good enough for most workloads. So what can IBM's flashsystem do that others can't? The article didn't say. I assume it doesn't do it for the fraction of the cost of the competition.

    I suppose if you are in the market for the absolutely fastest network based flash w/no software features then someone should consider IBM Flashsystem(without SVC of course). Though the relative market for that is quite small. And even then with no software features there is probably more reason to consider one of the newer NVMx based flash systems since they don't have software either.

    The only other market opportunity I see for IBM really is IBM shops.

    1. Lee McEvoy

      Re: I think I know the answer

      Here's an interesting article I'd point people at when they had made assumptions about relative costs - you may have read it already:

    2. PowerMan4Evr

      Re: I think I know the answer

      I've worked with SVC in multi-platform shops for years. I recommend it to customers regardless who their primary SAN storage vendor is. SVC gives every shop freedom & flexibility because the SVC is storage agnostic - it doesn't care if it is managing EMC, IBM, HDS, NetApp, Compellent, HDS, Pure, etc, etc. Now, your FC relationship to servers, hosts & VM's can remain static allowing you the freedom to perform maintenance, migrate out/in or upgrade storage without disruption. Yes, it implies you have more than 1 storage subsystem to get all of the bells & whistles but for uptime, flexibility while maintaining performance levels you can't beat an SVC.

      1. Anonymous Coward
        Anonymous Coward

        Re: I think I know the answer

        10 plus years ago it made sense, but SVC is showing its age. It doesn't have dedupe, it uses out moded snap tech, there are scale limitations, no VM aware functionality. The concept is great, but IBM needs to spend some cash and create an SVC Mark II. I don't think IBM's management wants to put money into hardware. They believe everything is cloud bound, may be right.

        1. El Storage Master

          Re: I think I know the answer

          IBM's de-dupe box is the A9000. Study up a bit.

      2. Anonymous Coward
        Anonymous Coward

        Re: I think I know the answer

        SVC is very 10 years ago.

        Most of its value prop is now contained within VMware.

        it's missing critical functionality and as the conversation moves from IOPS to latency, the additional hop and step of this product is going to be like a sore thumb in the infrastructure.

        IBM is now claiming that they have encryption in SVC. Do you really want even more latency?

        Sorry, but paying an IBM tax every time I add storage to my environment is not my cup of tea.

    3. Matt Bryant Silver badge

      Re: Nate Amsden Re: I think I know the answer

      Used the old TMS systems as fast disk for Oracle databases in a billing system - expensive but did the trick!

  2. chrismevans

    Nate, I don't think FlashSystem can do anything unique. As you say, sold by IBM in bundles with other solutions they sell. It will be interesting to see the announcement coming up in the next few weeks, as it will show us the level of commitment to the platform. The IBM storage business in general is heading down the tubes.


    1. returnofthemus

      I don't think FlashSystem can do anything unique.

      What you mean the ability to virtualise all that under-utilised storage from third-party vendors, let's not forget FlashSystems have been shipping in more volume than both Pure and EMC for that very reason, as for Dedupe yeah, great for email, virtual server & desktop, not so great for OLTP, Data Warehouse or Analytics, which is where RtC plays. However, IBM have partnered with SANBlox for dedupers, though stay tuned on FlashSystems are on the way ;-)

      1. Nate Amsden

        Re: I don't think FlashSystem can do anything unique.

        If you are saying FlashSystem can virtualize other systems is that not what SVC does? I thought SVC was also available as a standalone product as well so if you really want SVC you don't have to buy Flashsystem (I think SVC also is included in some form in Storewize storage too ?)

        1. Lee McEvoy

          Re: I don't think FlashSystem can do anything unique.


          you've got the right sort of idea, but I think you've made it sound like a negative, which I'd disagree with.

          Spectrum Virtualise (what used to be called SVC code) runs on a variety of controller "engines".

          If you want to use it to enhance* a large estate of existing (perhaps heterogeneous) FC block storage you'll likely run it on SVC nodes, if you want some of your environment to be AFA you'll likely have V9000 (there's a licence cost saving in most cases), if you want a midrange array you'll most likely go for a Storwize V7000 (although a lot of V7000 customers virtualise FlashSystem 900 too). If you want low cost block storage, the V3700 and V5010 are there for that.

          Given the common code base, you can replicate between different members of the family, which is good if your DR doesn't need to be as fast or big as production. Just pick the "engine" or "engines" based on your performance/capacity/function requirement.

          So, you are correct when you say "if you really want SVC you don't have to buy Flashsystem", but you've missed the point that amongst AFAs, that functionality is unique.

          If you don't like SVC, that's fine! Get yourself along to one of the Flash events IBM are running at the end of the month (I'll be at the one in London) - you'll probably like what you'll hear.

          *"enhance" could include enabling existing kit to stretch/hyperswap between sites (or just normal replication as sync/async/async with snapshots), be realtime compressed and/or encrypted, pretty much irrespective of the backend storage (which is nice if you have a heterogenous environment following an acquisition). Having a "legacy" also means that you can work (and be supported) on OS that are also legacy - not many AFAs can do that as they tend to only support what is mainstream when they're designed/launched.

    2. Anonymous Coward
      Anonymous Coward

      Not true. 57TB in 2U is at the leading end of density. I have all kinds of customers running Oracle RAC on it and getting sub-250 microseconds of sustained latency. It is the fastest box out there amongst the known AFAs. Also, check IDC tables 5 and 7 from the Nov 2014 report. Math shows IBM is the cheapest AFA out there (really). Don't judge FlashSystem on IBM's storage rep 5 years ago.

  3. Nate Amsden

    Sorry just meant that SVC isn't exclusive to flash system.

    The concept of virtualizing other arrays is certainly cool.

    1. Anonymous Coward
      Anonymous Coward

      It was an HDS idea originally.... IBM's contribution was that they didn't make people buy the giant USP-V in order to virtualize external arrays (kind of defeats the purpose in the HDS model... you can run whatever storage you want, provided you first buy our high end array). You can just virtualize whatever you want behind SVC. The issue is that SVC is old and hasn't been upgraded enough. The concept is cool, but IBM still uses copy on write snaps (can't scale), a lot of legacy scale limitations in the node pairs, no dedupe, legacy volume/LUN instead of VMs, etc.

      The TMS tech is really fast. IBM just cut a corner on the software stack and used what they already had on the shelf instead of a next gen software stack of the Tintri mold.

      1. Anonymous Coward
        Anonymous Coward

        you heard HDS talk about it first, doesn't make it their idea originally

        IBM Research published in 1999 a paper around "COMmodity PArts Storage System" (Compass) architecture and the first SVC product was launched in 2003.

        USP-V was launched in 2004.

        I'm going to call that as an IBM original, but I'd also bet that in the early days of storage virtualisation, most people heard about if* their incumbent vendor mentioned it to them, but that if EMC had invented it, everyone would have heard of it......

        *lots of IBM customers didn't hear about it

  4. CheesyTheClown

    Hmmm... But why?

    SAN is something with a relatively short shelf life.

    Consider first why SAN is interesting to begin with.

    1) Physical machines (VM hosts need to be boot, preferably without local storage) and as such a block based storage system is attractive. This means a single reliable 4-60gb image mirrored for every blade/server is desired. Using "thin provisioning", this is about 1.2gb of storage altogether.

    2) VMware and storage guys seem to think that fiber channel is king. There is much legacy here and almost never any sensible reasoning for this thought process. Fiber channel is generally pretty slow. But it let's people do things how they always have. Most data centers based on FC almost never has NPV configured properly. But also consider that since vHBAs are NEVER hardware accelerated. As such, block storage places much silly wasteful overhead on host CPUs.

    Ok, so what's the alternative?

    With VMware, you're typically screwed because VMware behaves like a primadonna regarding their driver development tools. So, without paying $5000 and signing a ridiculous NDA with blocks open source, you can't use NFS on any home built system. Also, it's become kind of a religious thing for VMware users that the system should always be SAN boot. This is wasteful and basically stupid.

    In modern times, whether for cache or other reasons, servers should always contain local storage. The performance difference is huge. Simply adding a few local SSDs make the servers scream compared to clogging a fiber channel pipe with swapping and nonsense reads. Therefore, there is no reason to boot servers from SAN. Instead, simply push via PXE an image of the latest boot to the blades. In fact, this makes management REALLY EASY. So bye bye block storage over a wire here. If you really need remote block storage, consider StarWind (much much less expensive than DataCore and quite usable and more manageable). Or from Linux, just create a glusterFS and use LIO to share via iSCSI. I've also used LIO for FC but SGST seems more reliable for this.

    Second, scale out file servers have absolutely no limits on performance or scale as SANs do. I've been seeing million+ IOPS on generic hardware for a while now. With 8 servers running 20 cores and 384gigs of RAM as well as hybrid storage on Windows Storage Spaces you can fully saturate 8 40Gbe interfaces per blade. Unlike this cute little IBM SAN, that's 320Gbe x 8 servers for closer to 100GB/s. Add enough SSD to each server and it will fly.

    What's more, unlike IBM's tech which requires hopes and prayers that Veeam will be nice to them or that customers have to use crumby generic backup systems, Linux GlusterFS and Windows Storage Spaces are first class citizens for backup.

    The bigger selling point to DIY storage is that IBM now has like 12 different storage systems. I have dozens of customers who spend tens of millions of dollars constantly just to upgrade storage... Why? Because vendors make something new and the old stuff doesn't matter to them anymore. SAN loses 80% of its value the moment you place the order.

    1. pPPPP

      Re: Hmmm... But why?

      I agree with you that servers should have internal storage, particularly for temp areas which do not need to be on shared storage.

      If you think that fibre-channel is slow, then I'm afraid you're just wrong. Simple as that. Fibre-channel may be slower than attaching a flash device directly to a system, but there are reasons for shared storage, and those reasons are still as valid now as they were when we all started using shared storage. Ethernet is a crap conduit for storage, which is why it's still a drop in the ocean compared with FC.

      You mention million+ IOs. Of course, anyone who knows anything about storage will know that IOPs is a valueless metric: it's a big number to shout about and is only used for marketing reasons as it's a crude way of comparing one thing with another.

      What's actually important is latency, which is what this article is about.

      I'm a big proponent of DIY storage such as Ceph. It has its place and can provide a relatively cost-effective way of getting a half decent storage system. It has its drawbacks though:

      - You have to build it yourself. This takes time.

      - You have to maintain it yourself. So if the guy who set it up leaves the company, or is on holiday or ill, and you have an outage that you can't fix, then you lose your business and you're all out of jobs. That's the main reason people are willing to spend money on enterprise storage.

      - While you might be using off-the-shelf hardware, this is typically servers with some disks shoved in the front. The storage vendors also use off-the-shelf nowadays, but they use dedicated disk enclosures and fewer servers, which means far less power consumption and far higher capacity density. Data centres cost money.

      I'm not sure why you single out Veeam, but I do know the product and I do know that they're a business and like all businesses they care about their customers. If getting it to work smoothly with IBM is something their customers need, then that's what they'll do.

      As for your last paragraph, this sums up your lack of understanding entirely. The infrastructure on which a business runs its IT is entirely valueless. The continued functioning of the business is the only thing which ultimately has any value. If it were able to function more efficiently in today's world with something other than computing then it would. Businesses don't set out to buy servers, networks or storage systems: they want something which allows their business to reliably function.

      People pay a lot of money to the likes of IBM (I don't work for them by the way) because they trust them to provide the means to allow their business to run. This will naturally include software, hardware and the networking to connect it all together but those are low down on the list.

      So yes, a couple of techies could quite easily screw together a system with decent performance and basic functionality for a fraction of the price, but if they leave the company, go sick or just realise they don't know what to do when it all goes tits up, then the cheap price you paid goes down the pan with the rest of your business. That is why people pay millions of dollars. They're not the stupid ones.

  5. Anonymous Coward
    Anonymous Coward


    The largest issue with SVC/V9000 is the legacy copy on write snaps with scalability constraints. IBM needs to fix it but it seems to be well baked into SVC.

    1. Anonymous Coward
      Anonymous Coward

      Re: Snaps

      There's a good reason for copy-on-write on SVC: it's the only way you can use a tiered storage model. Redirect-on-write only works if the snapshot is on the same type of storage as the source.

      It's a bit more complex than that actually. SVC relies on extent allocation and that includes thin-provisioning. When you take a snapshot it pre-allocates an extent (typically 1 GiB) and then fills that up until it's depleted. Taking snapshots of snapshots results in a complex chain of dependencies and if you use a combination of storage tiers you can end up with data on a tier 1 snapshot being allocated on tier 3 storage, for example, although the source volume will always be where it should be.

      Deleting snapshots is even more complex as a deallocation operation is required. This is true for most snapshot implementations, but in the case of SVC, all of the dependencies need to be tidied up, and because they are all in-line, this directly impacts performance and snapshot deletion can take a very long time.

      Ultimately, SVC is a legacy architecture, designed two decades ago. This has its benefits: unlike the new guys on the scene IBM can shout about over a decade worth of installations in the field. It's a valid point and not one to be ignored. However, they are also stuck with some major headaches. Availability will never be higher than 5-9s (although availability figures need to be taken with a pinch of salt) and performance will always take a big hit when a controller goes down. Extent-based allocation is incredibly inefficient and is getting worse as capacities increase: thin provisioning is one of many crude additions to the product.

      Fixing SVC's problems would require significant architectural redesign and corresponding rewriting of the code. This would take a lot of time and money (IBM no longer invests in its legacy business) and would destroy its decade-long legacy in the field. So it's not going to happen.

      Having said that, I'd still recommend it as a product. Yes, it has its issues, and funnily enough IBM doesn't shout about them. But then again, so does everyone's product. If you're looking at buying something new, then you should always take time to ensure that you understand what you're buying. Ask the vendor: if they're not able to explain the complexities, including the deficiencies, then you probably shouldn't be buying from them. Ask other customers and ask online: there are plenty of place, such as the forums here or on Linkedin. SVC has its deficiencies but ultimately they're minor compared with the benefits that it can give you: it's a very useful bit of kit but not right for everyone.

      1. Anonymous Coward
        Anonymous Coward

        Re: Snaps

        Yeah, agree with everything you wrote. I think the problem with SVC in the V9000 mold is that 99% of people are not tiering. They are just using the V9000 as a stand alone Flash array and SVC happens to be the included software stack. In that case, snaps are a big problem. Most people want to use snaps these days as a DevOps tool and not just a data protection tool. IBM never considered that developers would be taking a million snaps of live environments when they built SVC and keeping those snaps for a longer period of time.

        There are definitely some pluses of SVC, but that snap restriction is a killer because of the Dev requirements. I know an IBM shop that was using SVC with XIVs behind the SVC that decided to just drop SVC, not because of the added SVC cost but because they were unable to manage SAP changes with SVCs snap model and they could with native XIV re-direct. At the end of the day, if you are selling a storage software stack to rule them all (which IBM is with SVC), you had better be sure that the meta software stack is top notch and way better than the stacks on the underlying systems that you are turning into dumb storage. IBM, probably because it would be a big effort and they don't want to spend that sort of cash on hardware, hasn't kept it up to par.... The dedupe thing is particularly bad as that would be a relatively simple addition without a rewrite. I have no idea why they haven't added dedupe to SVC or anything else in their storage portfolio, other than it would cost money.

        1. returnofthemus

          Re: Snaps

          The FlashSystem V9000 is not a Copy Data Management solution, however what it does offer is the ability to create full copies, as opposed to fully leveraged snapshots, which you to maintain one original copy and store delta changes through space efficient snapshots, enabled through it's FlashCore technology and Microlatency modules in coordination with Spectrum Protect (formerly TSM) snapshots.

          However in environments where snapshots are abound IBM have partnered with Catalogic for exactly these purposes.

        2. Anonymous Coward
          Anonymous Coward

          Re: Snaps

          Wrong. They can use the 900 as Tier O stand-alone with no external controllers as well, and do.

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

Other stories you might like