ORIGINALLY POSTED 5th February 2014

15,619 views on developerworks

I think I missed January, it certainly seems like February has snuck up on us – maybe its because every day here in the UK is merging into one… since us Brits love to talk about the weather… its been kinda boring, rain rain, oh look its raining. It feels more like being back in Scotland where we have many words to describe rain, my favourite being smirr or smirring.

Meanwhile back in the land of storage, I’ve been playing with my FlashSystem840 and using it to replace over 1000 15K RPM HDD and what was left of our 2008 “Project Quicksilver” and make our storage management so much easier. With SVC we always need huge amounts of backend performance to ensure we are really measuring the throughput capabilities of the SVC nodes, especially with new nodes – (more of that in the coming months…)

I’m not going to go over the data again, but you will be sure to have hopefully seen IBM’s recent update to its FlashSystem range – the 840. Building on the amazing performance and 30 years of experience we acquired with TMS, the 840 ticks the last few boxes that were missing, mainly concurrent firmware ugrades and more up to date GUI. (Both of which in some part are running SVC code – the new control canisters basically are another instance of SVC software on another hardware platform.)

I was going to post on ChrisM’s post on the register regarding “what the competition said” about our 840 product, but you don’t need to read that – the key word is underlined, what did you expect them to say?!

Meanwhile there has been a lot of guff  said about putting SVC nodes with the FlashSystem products to provide Enterprise functions. I think most vendor guff has been because they are jealous that they don’t have a product to match the capabilities of SVC, that must be why so many of them clamor to support their products behind SVC, and why almost all of the indie flash only vendors are also biting our hands off to be supported behind SVC.

Lots of said guff is about cost and performance. Cost wise when purchased as the Enterprise FlashSystem, there is not additional cost, its part of the product, and maybe those that are saying that need to also look at the base SVC costs. SVC has always been “seen” as costly – but I was in a great meeting at a customer site where an XXX (storage vendor initials removed) biggot  piped up, after ignoring most of what we’d all (customer OPs team and IBM) had been discussing with the vague statement of “OK, but that SVC thing is expensive…” When the IBM account team later explained how much they were paying for SVC they realised that it was less than their software licenses for their Tier2 storage products from said XXX vendor… all of which get replaced when you insert SVC.

Anyway I digress, I wanted specifically to reply to Chris Evans post from today, to set the record straight. (Chris and I have met on many occasions and have enjoyed a few #storagebeers) so I wanted to help educate as much as anything :

1. SVC does scale out. You start with 2 nodes and can extend to 8 – and its linear performance scaling all the way. The latency stays the same across the board.
2. SVC supports up to 4096 “mdisks” or Managed Disks – in a FlashSystem world, you don’t need to create more than 16 per system, and in the future 1 will be enough. The current 16, is only to ensure SVC is driving enough concurrency.
3. SVC supports 2048 volumes or “vdisks” per node pair. So up to 8192 for a full cluster.
4. Each volume is indeed made up of extents as Chris states, but the extent size in a FlashSystem world is almost irrelevant. Extents provide for wide striping, so allowing you to take a number of “mdisks” and stripe a “vdisk” across them all, giving you much higher performance when those mdisks are made up of spindles. Even then, if you are trying to improve random performance, extent sizes generally dont matter.
5. Extents can be 16,32,64,128,256,512,1024,2048,4096 and 8192 MB in size. For FlashSystem we recommend 1GB
6. We can manage 4M extents, and so at most 32PB when using the largest extent size, or 4PB when using the 1GB – Thats some 100 FlashSystems behind a single SVC cluster… more than enough for scale out on capacity.
7. Performance will be linear as you add node pairs, and yes there are finiite levels, but again you probably dont want 1M IOPs from just one application, or even 40TB, so add more SVC nodes to scale performance, oh and of course you can add any of the 200 other storage controllers you may have or want and tier between then…
8. Finally the comment about Thin Provisioning is semi-correct. Yes we do have to allocate an extent to a volume when that extent is first written to, but the actual allocation size if based on the grain size (256KB default recommended) within that extent. So we reserve space up to the extent size, then allocate at the finer grain size. This is subtly different from say HDS, where I know Chris has a lot of experience and knowledge where there isnt the distinction, and allocations are at the much higher extent sizes.

Anyway, just a few things I wanted to clarify, and set the record straight – didn’t mean to give everyone a lesson in ‘urban slang’ nor Scottish words for rain, but there you go…

🙂