I spent some time today with the good folks at 3Par, as offered by Marc Farley a few posts ago. It was good to get more of a background on the product and also see what's happening in the future (although I can't talk about that!).
I think most of their technology is fairly well known (thin provisioning, wide striping etc), but two features stood out for me.
Dynamic Optimisation
Dynamic Optimisation allows a LUN to be moved around the array based on a number of parameters. One of the most interesting is the ability to change the RAID type without any outage or downtime. Think about it; you create LUNs as RAID-10 devices then realise you don't need to have that level of performance. With a couple of clicks, your LUN is changed and re-laid out as anything from RAID-5 2+1 to 8+1. The key factor here is that this is seamless, needs no outage or no host-based migration.
Compare and contrast this to a traditional "monolithic" array like a DMX-4 or USP. Well, the DMX-4 uses hypers (slices of a physical disk) which are combined up to create RAID devices. Naturally, the hypers used to create a RAID-5 device are a different size to those used on a RAID-1 device when creating a LUN of the same usable size. Re-purposing a LUN simply isn't possible; a RAID-1 LUN is a RAID-1 LUN for it's lifetime. In fact, releasing storage and recreating different LUNs although technically possible, is very rarely done as it's a complete nightmare to accomplish. If you like analogies (and I do), re-structuring an existing DMX array is a little like going back in time to a WWII RAF or Navy Operations room with lots of little models of ships being pushed around by wooden paddles, compared to today's modern ATC systems.The way forward for monolithic or enterprise arrays has to be flexibility, especially with the need to provide storage for virtualised environments.
Thin Built In
So thin provisioning is on everyone's lips as a must have feature and 3Par claim to be the grandfather of the technology. I say claim, as TP has been done before, but that's not what I'm concerned about. What interests me more is the issue of Fat->Thin LUN migration. That is, copying "full size" LUNs onto a thin provisioned array. TP is great for new data. Create the LUNs, provision out the storage and voila!, more than 100% allocation on your array! TP relies on the fact that writing data to a LUN is a block-level process, and blocks are not necessarily written to sequentially, so there can be plenty of unwritten space on the LUN. However, copying a LUN from a standard array to a TP array will write all of the data blocks, negating the TP benefit.
3Par's arrays now have "Thin Build In", a custom ASIC which can detect unused space as data is written. This means fat->thin can be achieved as data is moved onto the array without any other intervention. It's worth thinking this one through; perhaps someone can answer whether EMC's TP implementation in 73 code and HDS's TP implementation on USP-V can do that and if not, how they expect to migrate existing data onto their arrays and still see the TP benefit.
While I'm on the subject, what happens if you defrag a TP volume? Well, data will be consolidated onto contiguous blocks of space and the location where data is moved from will get logically freed, but I don't believe products such as Diskeeper will write anything on the old data. What if it did? Well if that space was cleared, a 3Par array could reclaim this storage. So defragmenters out there - do you do this?
Anyway, thanks to the 3Par guys for the head's up on their technology; the next few years certainly are going to be interesting in this space!
Posts
6 comments:
As far as I know, as of Symmetrix microcode 5773, you can use Virtual Migrator to change RAID protection on the fly and migrate from smaller to larger LUNs. So I think EMC offers about what 3PAR offers in this particular case.
But I'm glad Marc and Craig treated you to a rousing game of Battleship!
Hi Chris, thanks for providing folks with a "peek in" into our future!
I just want to make sure readers know that the functionality to convert existing fat volumes to thin volumes is not available. We are not quite there yet, but will be relatively soon.
Stephen (and Chris), the little subtlety with dynamic optimization is that it uses wide striping to re-layout data over the all disks in the system. When you add new drives to an InServ you don't have to specify that you want to use them for specific volumes, you simply run dynamic optimization and it automatically changes the disk layout to include both old and new disk drives. It's not a matter of making larger LUNs (although you can do that) - it's a matter of making more spindles available to increase performance.
Marc - I merely discussed what was already online http://www.3par.com/inservtclass/
:-)
VP in the DMX world still has some limitations; for example I think it's still the case that if you add additional disk to your VP pool, it will not dynamically relay-out the existing LUNs and spread across the additional spindles. The initial release of VP was of limited use, it is getting better tho' (at a cost).
Hi Chris, interesting post.
Quite a few years ago I looked after some Compaq EVAs which in my opinion were years ahead of their time. You could add more disks in to a disk pool and the EVA would re-level data to include to new spindles. This was great but had a draw-back. Performance would nose dive during the re-levelling process. So its an out of hours job usually.
As for thin provisioning. Ive done a fair bit of it (the HDS variety) and I dont see many customers looking at it for the space saving benefits. Seeing what a "run" on Northern rck did to our fractional reserve banking system makes me and others very very hesitant to over provision storage. Nobody wants a "run" on their storage pool. The performance benefits are another ting though. Most people are looking at TP for performance and ease of management benefits (in my experience).
As for the idea of the controller knowing what is free space on a FAT LUN while migrating to a thin volume..... your got my interest on this one. I assume I will be as cautious as I am about over provisioning but it sounds interesting.
Nigel
Post a Comment