One of the important yet lesser known additions to the VPLEX 5.2 release was the ability to expand virtual volumes non-disruptively.
Actually, let me step back a bit. VPLEX has always had the capability of expanding local-only (i.e. non-distributed) virtual volumes. We accomplished this by concatenating the virtual volume with another segment that needed to be tacked onto the virtual volume. In GeoSynchrony 5.2, we introduced a newer method as a complement to the existing method. In general, this newer method is our preferred method of virtual volume expansion.
Why the new method?
To understand why we embarked on developing a new virtual volume expansion method, you need to understand the limitations of the concatenation approach:
- Local only volumes can be expanded by using concatenated volume expansion. For distributed volumes, there was no convenient way to expand the virtual volume. (You would have to break the distributed volume, expand the underlying device and rejoin the distributed virtual volume with a complete resync)
- If you are using array based local replication functionality (aka snaps and clones) (Look at ViPR with VPLEX for an example of how you can do this), then when you concatenate different volumes to create a larger volume, those local replicas are no longer useful.
- Concatenating volumes (especially those coming from different arrays or from different performance tiers from different arrays) is generally not a good practice from a performance standpoint. There are two reasons why: First, imagine the two portions of the same volume having different performance characteristics. Secondly, for I/Os that cross the volume boundaries, you end up having to break I/Os into multiple smaller parts which usually (again, 80:20 rule in play here) leads to poorer relative performance.
Alright – tell me more about the new method
We call this the storage-volume based virtual volume expansion method. If you look at the constraints established above, preservation of the volume map geometry becomes crucial to address all the goals outlined above. This method works for local as well as distributed virtual volumes.
Supported geometries for storage-volume based virtual volume expansion
Here are the supported geometries for this method.
Supported virtual volumes can be:
- A local virtual volume that is fully mapped to a single storage volume (1:1 mapped, RAID-0)
- A local virtual volume that is mirrored across two storage volumes (RAID-1, R1)
- A distributed virtual volume that is mirrored completely across two storage volumes (Distributed RAID-1, DR1)
If you confirm that the virtual volume you need meets the criteria above, you are ready to expand!
Step 1: Expanding the storage-volume
The first step is array specific. You now need to expand the storage volume on the array to the capacity that you need (e.g. let’s say you have a 500GB storage volume. You would now expand it to 750GB on the backend if you need to add 250GB). Remember that if you have a mirrored VPLEX virtual volume, then you will need to do this for every leg of that mirror.
You now need to get VPLEX to detect the increased capacity for the storage volumes. If you have I/Os going on to the virtual volume (and therefore, to the storage volume), then upon volume expansion, the storage volume will generate a Unit Attention that VPLEX will detect and probe the storage volume to detect the additional capacity. If I/Os are not running to the storage volume, then you can run the rediscover command on VPLEX to reprobe the array to detect the added capacity.
Step 2: Expanding the virtual volume
The next step is to expand the virtual volume so that it uses the additional capacity.
You need to run the virtual-volume-expand command on VPLEX. Here is what the command looks like:
[-v | –virtual-volume] context path
[-e | –extent] extent
[-f | –force]
NOTE: I have listed the optional extent parameter above to be complete. This is used by the concatenation expansion method not by the storage volume expansion method.
To expand the volume, you issue the above command with the specific virtual volume that you need to expand. The command makes some checks (more on that later) and lo and behold, you have expanded the virtual volume without ever stopping I/Os.
Things to remember
This section captures an assortment of varied details that are important to know or tips and tricks about the command that I find useful.
- While VPLEX supports non-disruptive expansion of virtual volumes, Whether a host mounted volume can be expanded depends on the OS, File-systems and in some cases, applications. Windows, for example, allows non-disruptive volume expansions with a host rescan. Older UNIXs do not. Check your host OS, filesystem or application details for clarification on this. From a SCSI standpoint, once the additional capacity is available, VPLEX will report a Unit Attention indicating that the LUN capacity has changed. Host rescans will also show the added capacity.
- We have added four new attributes to help you figure out whether a volume can be expanded and what its current status is. If you run an ll on a VPLEX virtual volume, you can now see:
- expandable (boolean denoting whether a virtual volume can be expanded or not)
- expandable-capacity (how much capacity is available to expand)
- expansion-method (what method needs to be used for volume expansion)
- expansion-status (if a volume is being expanded, what is the current status)
- What if my volume is not one of the supported geometries? – If your volumes are not mapped 1:1, then you have two choices:
- Perform an extent migration to migrate the extent to a storage volume that is 1:1 mapped
- Migrate the virtual volume to a larger storage volume to become 1:1 mapped
From there you should be able to perform the virtual volume expansion as above.
- The newly added capacity of the virtual volume will be zero initialized (i.e. VPLEX will write zeroes to the new capacity) prior to the additional capacity being exposable to the host. The reason to do this is especially true on mirrored volumes (R1s or DR1s) since from a host perspective, the added capacity should return the *same* data on read from either leg. In other words, as with everything else, VPLEX ensures single disk consistency even with distributed virtual volumes when the capacity is added
- Today RecoverPoint protected virtual volumes cannot be expanded while the protection is in effect. This is something we are looking at for future releases. For now, you can turn off the RP protection and then expand the virtual volume and re-engage the RP protection for that virtual volume
- If a virtual volume is undergoing migrations, or if the system is undergoing a non-disruptive upgrade or if the system or the virtual volume has a failing health check, then VPLEX will block expansion of the virtual volume