I'd like to clarify and correct a few of the above points.
If you do straight out encapsulation (also known as 1:1) where you claim the storage volume, create a single full size extent on the storage volume then create a simple device on that one extent and then create a virtual volume on that device, then the application consistency flag (appc) is unnecessary.
In the GUI there is a simple way to encapsulate as rpwagner indicated above and we expect most people to use this type of encapsulation most of the time.
Where appc comes into play is if you are not doing straight out encapsulation of storage volumes with data already on them. The intent of the appc flag is to protect storage volumes that contain data on them while you do your provisioning. You would claim only those storage volumes necessary with the appc flag. One example of its use is if you were going to be creating a mirrored device (raid-1). Having the appc attribute set would help prevent the possible loss of data caused by accidentally selecting the wrong extent as the mirror. If you didn't have appc on such a target, the VPLEX would begin syncing the two mirror legs overwriting the target mirror extent that was mistakenly specified. But if appc is flagged, then the attach-mirror operation is prevented. The mirroring operation is about the only process that I can think of where VPLEX could overwrite data.
To correct what rpwagner said above, the appc flag can be changed after the fact, but you would want to be careful about it's use. If improperly turned on (it is an attribute) then it might slow you down, but it can easily be turned off via CLI.
Personally, I think the appc attribute has it's uses, but I do agree that in most typical usage, it is unnecessary. I like it because you can use it to be more cautious about bringing VPLEX into an existing environment. Especially if more than one person is doing the work. There is less chance of user error causing loss of data. But if everyone is careful and on the same page, then it is actually unnecessary.
Aha! So that's what that does. Thanks for the information.
At the training we were just told to use it when encapsulating existing storage.
The explanation was simply that your existing storage would (possibly? probably?) get corrupted if you didn't use the flag.
I'd really like to get a little deeper into the concepts. Maybe i should check again if there's some kind of admin guide for VPLEX, so i can read more about it all. I couldnt find anything on Powerlink last time i checked. But that was a little while ago.
I've found the Find-bar already of course. But to be honest, it doesn't really help much right now. It just scrolls through all the matches one by one. I think it'd be nicer if it actually filtered the list, so it doesn't show the lines that aren't matched at all. How does that sound?
I must admit i've skipped over the second tab in the main interface (can't access it right now) in my mind automatically once i had the training to get through to the concepts. It kind of feels like a beginner's version of the third tab with all the drawings beside it and everything.
I didn't realise there could be actually things in there that aren't in the third tab at all. I guess if i can find it there, it should be ok.
You can use "Step 1: Claim storage & create virtual volumes" to encapsulate all the storage in one go.
B.t.w. i've found that you can also do it from the tab "Provision Storage". There's a button "Create Virtual Volumes" in the Storage Volumes screen which has the same effect.
Thanks for your inputs Cihl. I will definitely try to make use of it.
Regarding some "improvements in the VPLEX GUI", I'd like to see a feature that lets you create multiple extents - especially when the sizes of each extent is the same. Right now I use the CLI, create the extents and then again open up my GUI and rename each of the extent to something which makes more sense - like HostName, Size, etc. etc.
Yep, agreed. Right now, the interface will only let you create a single extent from each of the chosen storage-volumes. I also use the CLI when i need to make more of them.
Some more ideas:
1) I think it'd be a good idea if the interface would let me create a virtual-volume of any size directly from a storage-volume and do the in-between steps for me.
2) Mobility central should, i think, allow me to move a device to a different storage-volume and create a mirror extent/device for me. Of course, it would then have to prompt me to confirm that it'll work out the way i want to.
3) Mobility central should allow moving stuff between clusters. It's more convenient than the CLI for local objects, but doesn't work at all for metro-movements (so to speak).
Andrew-F
27 Posts
1
February 10th, 2012 08:00
Hi,
I'd like to clarify and correct a few of the above points.
If you do straight out encapsulation (also known as 1:1) where you claim the storage volume, create a single full size extent on the storage volume then create a simple device on that one extent and then create a virtual volume on that device, then the application consistency flag (appc) is unnecessary.
In the GUI there is a simple way to encapsulate as rpwagner indicated above and we expect most people to use this type of encapsulation most of the time.
Where appc comes into play is if you are not doing straight out encapsulation of storage volumes with data already on them. The intent of the appc flag is to protect storage volumes that contain data on them while you do your provisioning. You would claim only those storage volumes necessary with the appc flag. One example of its use is if you were going to be creating a mirrored device (raid-1). Having the appc attribute set would help prevent the possible loss of data caused by accidentally selecting the wrong extent as the mirror. If you didn't have appc on such a target, the VPLEX would begin syncing the two mirror legs overwriting the target mirror extent that was mistakenly specified. But if appc is flagged, then the attach-mirror operation is prevented. The mirroring operation is about the only process that I can think of where VPLEX could overwrite data.
To correct what rpwagner said above, the appc flag can be changed after the fact, but you would want to be careful about it's use. If improperly turned on (it is an attribute) then it might slow you down, but it can easily be turned off via CLI.
Personally, I think the appc attribute has it's uses, but I do agree that in most typical usage, it is unnecessary. I like it because you can use it to be more cautious about bringing VPLEX into an existing environment. Especially if more than one person is doing the work. There is less chance of user error causing loss of data. But if everyone is careful and on the same page, then it is actually unnecessary.
Cihl
15 Posts
0
February 11th, 2012 11:00
Aha! So that's what that does. Thanks for the information.
At the training we were just told to use it when encapsulating existing storage.
The explanation was simply that your existing storage would (possibly? probably?) get corrupted if you didn't use the flag.
I'd really like to get a little deeper into the concepts. Maybe i should check again if there's some kind of admin guide for VPLEX, so i can read more about it all. I couldnt find anything on Powerlink last time i checked. But that was a little while ago.
Cihl
15 Posts
0
February 11th, 2012 11:00
Hi!
I've found the Find-bar already of course. But to be honest, it doesn't really help much right now. It just scrolls through all the matches one by one. I think it'd be nicer if it actually filtered the list, so it doesn't show the lines that aren't matched at all. How does that sound?
I must admit i've skipped over the second tab in the main interface (can't access it right now) in my mind automatically once i had the training to get through to the concepts. It kind of feels like a beginner's version of the third tab with all the drawings beside it and everything.
I didn't realise there could be actually things in there that aren't in the third tab at all. I guess if i can find it there, it should be ok.
Kennedy_Doss
79 Posts
0
March 7th, 2012 12:00
RPWAGNER:
This is in reference to your 2nd Screenshot. We too use VPLEX 5.0.1. I dont remember seeing "EZ-Provisioning Tab". Where do I find it?
Cihl
15 Posts
1
March 7th, 2012 23:00
It's the second tab "Provisioning Overview".
You can use "Step 1: Claim storage & create virtual volumes" to encapsulate all the storage in one go.
B.t.w. i've found that you can also do it from the tab "Provision Storage". There's a button "Create Virtual Volumes" in the Storage Volumes screen which has the same effect.
Kennedy_Doss
79 Posts
0
March 8th, 2012 08:00
Thanks for your inputs Cihl. I will definitely try to make use of it.
Regarding some "improvements in the VPLEX GUI", I'd like to see a feature that lets you create multiple extents - especially when the sizes of each extent is the same. Right now I use the CLI, create the extents and then again open up my GUI and rename each of the extent to something which makes more sense - like HostName, Size, etc. etc.
-Kennedy
Cihl
15 Posts
0
March 9th, 2012 00:00
Yep, agreed. Right now, the interface will only let you create a single extent from each of the chosen storage-volumes. I also use the CLI when i need to make more of them.
Some more ideas:
1) I think it'd be a good idea if the interface would let me create a virtual-volume of any size directly from a storage-volume and do the in-between steps for me.
2) Mobility central should, i think, allow me to move a device to a different storage-volume and create a mirror extent/device for me. Of course, it would then have to prompt me to confirm that it'll work out the way i want to.
3) Mobility central should allow moving stuff between clusters. It's more convenient than the CLI for local objects, but doesn't work at all for metro-movements (so to speak).