INVALIDATE THE VPLEX CACHE

This is a brief note about a new capability we have introduced starting

GeoSynchrony 5.2. I have been seeing a bunch of questions on our internal
mailing lists about this. Hopefully, this note addresses a bunch of them.
Why do you need it?
Quite a few VPLEX Local and Metro customers use local replication on backend
arrays as an example, if the backend array is a VMAX, this would be using
TimeFinder Snaps and Clones. The same is true for all supported EMC and nonEMC arrays on VPLEX. In the lifecycle management of these local replicas, you
often need to expose a copy of the data as the original volume itself (when
recovering from operational errors or going back to a different point in time).
From a host standpoint, this volume would be indistinguishable from the original
volume it has the same volume identifier etc.
Let me now draw up the problem statement for you.
VPLEX Local and Metro have a read cache. In other words, for a given volume /
consistency group, VPLEX will store data so as to enable cache access for that
volume / consistency group without having to access the backend. This cache
access is accurate assuming that the media underneath (i.e. the storage volume
from the backend array) is not changed.
For such a volume exposed to the host, when you decide to mount the replica for
that volume and present it to the host, in effect, the underlying media has been
altered. This renders (unavoidably) that the VPLEX cache is out of sync with that
underlying volume (since the cache may be written later than the replica
timestamp). Any host that is likely to access the volume is likely to detect an
inconsistency in the data. If you like analogies, this is equivalent to the disk
drives being changed on your computer while the applications are running.
Yeah, BAD idea.
Up until GeoSynchrony 5.2, the way to address this was to remove the virtual
volumes for which the replica was mounted from the storage view and then readd that volume back in. This would force VPLEX to delete any cached data
associated with that volumes allowing the volume to be consistent with the
backend storage. And, in case you are wondering, yeah not our favorite
procedures either:-).
So, starting GeoSynchony 5.2 (released in May this year), we introduced the
cache invalidate command which performs the invalidation function described
above without having to remove and re-add the volume into the storage view.
Lets look at the command in more detail.
How the command works
The cache-invalidate command operates in the virtual volume as well as the
consistency group context. In the virtual volume context, the command clears
the cache for that virtual volume on _all_ directors where the volume is made
visible within that cluster. In the consistency group context, the same operation
as above is accomplished except for all volumes in the consistency group across
all VPLEX directors within the cluster where the consistency group (or volumes
from it) are made visible. Once you do this, any subsequent read for the volume /
consistency group will result in a cache miss and will be performed off the
backend array.

So, what does the command look like

virtual-volume cache-invalidate [-v |volume] virtual-volume force
consistency-group cache-invalidate [-g |consistency-group ] consistencygroup force
Things to remember
There are a few things to remember while executing this command:

This command will suspend host I/Os while the cache is being invalidated.
Ideally, host I/Os should be stopped prior to invalidating cache. Remember
that suspending I/Os on a live system could cause the host to detect a
data unavailability (depending on how timing sensitive it is)

This command performs pre-checks to see if the volume is healthy on all

directors before executing. If the volume is not healthy, you will get
warnings about this.

The VPLEX cluster should not be undergoing an NDU while this command
is being executed

There should be no mirror rebuilds or migrations in progress for virtual

volumes affected by this command

No volume expansions (more about this in a later post) when this

command is executed

Checking the status of the command

We have introduced a supplemental *get* style command to help customers
understand what the current status of the cache-invalidate command when
executed.
cache-invalidate-status [-h | help] [verbose] [-v | virtual-volume=]
The output from the command will have the following potential values:

Status

in-progress: cache-invalidate is running.

completed: cache-invalidate has completed execution successfully.
error: cache-invalidate has finished but with error.
unknown: This status is reported when a particular director where
the command needed to be executed cannot be reached
Result

successful: cache-invalidate completed successfully.

failure: cache-invalidate finished with failure. Cause field indicates
the appropriate reason
error: cache-invalidate is in error state.
Cause

This is a text string indicating the reason for any failure / error
during execution.

And from there you are good to go! Happy cache-invalidating! If you have any
questions, please post them in the comments section.

Update:
Don Kirouac (@kirostor) made me aware via twitter of a whitepaper that
describes the usage of cache invalidate. Thanks Don!