VPLEX VOLUME RESIZE

HOW TO: EXPAND VPLEX VIRTUAL VOLUMES

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:
1.

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)
2.
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.
3.
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
Geometries for virtual volume expansion
Supported virtual volumes can be:
1.
A local virtual volume that is fully mapped to a single storage volume (1:1 mapped,
RAID-0)
2.
A local virtual volume that is mirrored across two storage volumes (RAID-1, R1)
3.
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. lets 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.

Virtual Volume Expansion Step 1

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.

Virtual Volume Expansion Step 2

You need to run the virtualvolumeexpand command on VPLEX. Here is what the
command looks like:

virtualvolumeexpand
[v|virtualvolume]contextpath
[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.
1.

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.
2.
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)

expandablecapacity (how much capacity is available to expand)

expansionmethod (what method needs to be used for volume

expansion)

expansionstatus (if a volume is being expanded, what is the current

status)
3.
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.

4.

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
5.
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
6.
If a virtual volume is undergoing migrations, or if the system is undergoing a nondisruptive upgrade or if the system or the virtual volume has a failing health check, then
VPLEX will block expansion of the virtual volume
VOLUME EXPANSIONVPLEX