Dynamic Provisioning: What's with V-VOL Groups?
NOTE: HP calls HDP "ThP" and refers to DP-VOLs simply as VVOLs. Oh and the XP24000 and the USP-V are the same but with different front doors, although HP and HDS may not all support and recommend the same configurations. And finally, I currently work for neither.
FIRST THINGS FIRST
A V-VOL Group is to HDP, what a Parity Group is to normal LDEVs. Well pretty much anyway...... read on.
NO MORE PARITY GROUPS
Back in the day, before we had fancy technologies like HDP and Array Group Interleaving (I cant come to terms with referring to them as Concatenated Array Groups), you would install a four-disk package into your subsystem and format it with a RAID level. That four disk package is called a Parity Group. From your Parity Group you then carve up LDEVs and map them to the front end ports as LUNs.
Now way back then, knowing which Parity Group an LDEV belonged to was of huge importance. For example, you would never put a ShadowImage primary volume and secondary volume on the same Parity Group, well hopefully you wouldn't. And you would often dedicate Parity Groups to applications that demanded isolation and guaranteed performance.... etc etc
However, fast forward to the present day, and the ever increasing uptake of HDP, and we find ourselves in a world without Parity Groups. Well, not quite, still are still alive and well, but at least a world where we are told we don't need to pay as much attention to them as we once did.
This is due to the use of Pools. We "pool" together multiple Parity Groups (read "spindles") and HDP organises all the blocks in a Pool in a certain way so that we shouldn't have to think about Parity Groups when allocating LUNs.
The principle being, you throw lots and lots of Parity Groups (spindles) at your Pools and then build your DP-VOLs from your Pools rather than a single Parity Group. And then over time, as Pool pages are allocated, your LUNs will end up touching all of the Parity Groups in the Pool and thus benefit from the IOPs power of all spindles. Basically, they should perform better than had they been restricted to a single Parity Group.
Anyway, that's how it works outside of HDP. However, the tools and, no doubt many of the constructs existing with the microprogram that runs the USP, know and work with Parity Groups. This is evident from the seemingly clumsy way in which many of the tools display more modern incarnations of the Parity Group such as Array Groups (striping over two Parity Groups) and Concatenated Interleaved Array Groups.......
INTRODUCING THE V-VOL GROUP
Soooooo...... what has all of this got to do with HDP and V-VOL Groups?
Well. Because the tools and the ucode work with Parity Groups, there needs to be some equivalent when working with HDP and DP-VOLs. So to meat this requirement the V-VOL Group was born. And long may it live. Well, actually, hopefully not! Or I should say hopefully not so far as you and I, as people who live and work with these USPs and XPs, are concerned. We could easily live without V-VOL Groups, all they do at the moment is occasionally restrict us.
However, ignoring them or not treating them with respect while they still exist would be a mistake. And here we are about to get to a bit of a sticky topic.
DYNAMIC PROVISIONING IS DYNAMIC RIGHT?
At the moment you cannot dynamically expand a DP-VOL. So if you create one as 50GB and somewhere down the line you decide it should have been 100GB, you cannot dynamically expand it on the USP-V. You will have to use a volume manager or some other method.
However, I understand that the ability to dynamically expand a DP-VOL is just around the corner. Albeit no doubt limited to certain supported configurations at first release (e.g. limited to certain Operating Systems and probably not friendly to TrueCopy and ShadowImage yet). Still, definitely a step in the right direction.
Now for the sticky part. I am led to believe that you will only be able to expand the last DP-VOL in a V-VOL Group. So if you have a V-VOL Group containing multiple DP-VOLs, you will only be able to dynamically expand the last one in the group. This is at initial release of the feature, and this is so far as I am aware. Might I remind everyone that sadly I do not work for Hitachi, HDS or HP so am not privy to insider knowledge and reserve the right to be off the mark. What I know, I know from too many intimate relationships with USPs and from reading deeper into what I hear, such as current best practice advice, and the likes. But I try not to comment on something unless I am at least fairly sure.
So, at the moment I am told that best practice, especially if you want the ability to dynamically expand your DP-VOLs, is to create V-VOL Groups and DP-VOLs in a 1:1 relationship. Annoying, I know. Especially if you plan on creating lots of DP-VOLs. But worth it later down the line.
BUT WHY ONLY THE LAST ONE?
Now so far as I can tell, the reason why only the last DP-VOL in a V-VOL Group will be able to be expanded is again based on the internal workings of the USP.
Those of you familiar with the workings of the USP/XP will know that a traditional LDEV can only be made up of contiguous tracks/stripes within a Parity Group (the first LDEV created in a Parity Group is laid down on the outer most tracks of the Parity Group and subsequent LDEVs are created from tracks moving progressively closer to the centre of the disks). This is the reason why a Parity Group with two discrete 10GB areas of free space will only allow you to create two 10GB LDEVs and not a 20GB LDEV. See below for an example -
Parity Group 1-1
LDEV Size
01:01 10GB
01:02 10GB
FREE 10GB
01:04 10GB
01:05 10GB
FREE 10GB
In the above scenario you cannot create a new 20GB LDEV, despite the fact that there is 20GB of free space within the Parity Group. This is because of the aforementioned fact that an LDEV is built from contiguous tracks/stripes within a Parity Group. The two 10GB areas of free space, in the example above, are not contiguous.
Now then how this most likely maps to V-VOL Groups.......
Because HDP is no doubt coded to fit within existing parameters and around existing constructs within the microcode, it must confirm to many of the existing rules. So, if you have a V-VOL Group with 5 DP-VOLs associated with it, only the last V-VOL has free space after it. See example below -
V-VOL Group X1-1
DP-VOL Size
01:01 100GB
01:02 100GB
01:03 100GB
01:04 100GB
01:05 100GB
FREE XXXXXXGB
In the above example, only DP-VOL 01:05 has free space after it.
Of course this is all logical, because DP-VOLs are no longer created from consecutive stripes within a single Parity Group, they are in effect scattered here there and hopefully everywhere within a single Pool. Oh and some DP-VOLs might not be fully allocated yet either.
So it might seem a little strange that it would have to conform to the rules of previously staticly provisioned LDEVs. But, hey the USP is top notch enterprise storage and you don't go re-writing all the rules overnight, and rightly so. These things come in stages. Slowly but surely HDP is becoming a better and better product and we could say, more dynamic.
Please feel free to comment on this, Im open to discussion.
On of the reasons I post up here is partly to help other people in the day-to-day work. A few people have mentioned recently that they are creating multiple DP-VOLs per V-VOL Group and I don't want them to regret this. However, the USP is constantly evolving and getting better, resulting in the rules being constantly subject to change. This is no doubt why HDS rarely comment on things like this. So don't burn me at the stake if this is not the case in 10 years time and your still reading this ;-) I expect that later down the line the engineers might extend this functionality to all DP-VOLs in a V-VOL Group or make V-VOL Groups disappear from our view.
Nigel
DISCLAIMER: The opinions expressed in this post are just that, my opinions. I do not work for a vendor or a partner and therefore do not speak authoritatively. However, I do have fairly broad experience and knowledge of Hitachi storage.