Category Archives: Learning VPLEX

Talkin’ about VPLEX and RecoverPoint Part 4

The past three editions of these have been very popular. Our marketing and CSE team has created some new videos in support of the Q2 launches for VPLEX and RecoverPoint. So here are twelve videos for you to dig into.

  1. Why VPLEX for VMware Environments: Don Kirouac does an excellent job explaining how VPLEX integrates with VMware environments.
  2. Why VPLEX for Oracle RAC: Don Kirouac from the Corporate Systems Engineering team talks about the integration between Oracle RAC and VPLEX Metro to deliver continuous availability
  3. VPLEX with XtremIO: Charlie Kraus from the Product Marketing team explains how VPLEX delivers value to XtremIO environments
  4. ViPR with VPLEX and RecoverPoint: Devon Helms from the Product Marketing team explains how provisioning for VPLEX and RecoverPoint can be made simple with the ViPR Controller.
  5. Why VPLEX for SAP: Jim Whalen from the Solutions Marketing Team explains how VPLEX can help deliver SAP Application Availability.
  6. Why VPLEX for Microsoft Hyper-V Environments: Charlie Kraus talks about how VPLEX integrates with Microsoft Hyper-V environments to deliver mobility and availability
  7. VPLEX with Vblock: Charlie Kraus delves into how VPLEX integrates with and provides value to a Vblock environment.
  8. VSPEX Solutions for VPLEX and RecoverPoint: Karl Connolly from the VSPEX Marketing Team

  9. MetroPoint topology: Paul Danahy and I walk through the benefits and value propositions of the MetroPoint topology
  10. VPLEX Virtual Edition: Paul Danahy and I introduce the VPLEX Virtual Edition solution and why we think this is such a game changer
  11. Simplified Provisioning with VPLEX: Paul Danahy and I talk through how VPLEX Integrated Array Services simplifies provisioning with VPLEX
  12. EMC AppSync for RecoverPoint: Parag Pathak from the AppSync Marketing team and Devon Helms talk about the integration between AppSync and RecoverPoint to deliver application consistent protection

2014 Launch Post 3: Management@Scale: VPLEX Integrated Array Services (VIAS)

On April 4th, 2014, as part of the Data Protection and Availability Division (DPAD) launch, there were three VPLEX and RecoverPoint items that were launched or GAd:

  • VPLEX Virtual Edition – Availability late Q2
  • MetroPoint Topology – Joint capability of VPLEX and RecoverPoint – Availability Late Q2
  • VPLEX Integrated Array Services – Available now

This is the third in a series of posts to walk through what was launched / delivered.

The IT World we live in

Customers are experiencing a massive growth in data center scale. This has been the result of a lot of consolidation across data centers, the growth of big data and fast data applications and specialized infrastructure to manage the different application workloads.

In addition, as VPLEX environments have mushroomed, they are subject to the same stresses and strains of the overall IT environment. So, it is a good news / bad news story. The good news is that customers are putting more and more of their IT infrastructure behind VPLEX. The bad news is that what used to be a few steps at smaller scale and therefore barely noticeable, at scale becomes a much bigger problem. Customers have come to us with a simple request – make provisioning simple!

And we listened

We are addressing this problem in multiple ways with the simplest being the Virtual Storage Integrator (VSI) plug in as a mechanism for VMware environments (see here) and the most elaborate being the incredible capabilities of the ViPR controller (see here).

And we are now providing customers with the means to do end-to-end provisioning natively through Unisphere for VPLEX. Basically, from within the VPLEX UI, you can now provision all the way to the backend storage without having to go to the backend UIs. This implies that when you provision storage, you no longer have to navigate between two or three GUIs to provision storage to VPLEX. This capability we are referring to as VPLEX Integrated Array Services (VIAS). The first installment of this GAd in March as a part of GeoSynchrony 5.3 and was launched on April 4th. For the initial release, we support the VMAX and VNX.

So how does it work?

The basic process works by exposing the backend Management interfaces to VPLEX. VPLEX uses SMI-S to talk to the backend arrays. As a result, while we support VMAX and VNX for the initial release, we expect to add more arrays to the VIAS support matrix.

The backend array needs to be configured to some notion of pools (collection of storage) – for the VNX, these are called storage pools, for VMAX, these are called storage groups. These pools are exposed to VPLEX as manageable entities via the management for described earlier.

From there on, the provisioning is managed entirely within VPLEX. You have to select what pool of storage you need to use, what level of protection you want (local mirror, distributed mirror), what consistency group to use and what storage view you want to expose to the host. VPLEX then coordinates the creation of the LUN on the underlying storage, exposing that to VPLEX (on the VPLEX backend), claiming this storage, creating a virtual volume on this new storage, adding into the appropriate consistency group and finally, if so desired putting it into a storage view to expose it to a host on the VPLEX front end. In counting the steps pre-VIAS and post-VIAS, we have been able to reduce the steps by over 90%. The effect of this is nothing short of transformational. Large data center environments suddenly become easy to manage and work with.

Here are some screenshots of how VIAS looks:

image
VIAS: Selecting consistency group
image
VIAS: Selecting protection options
image
VIAS: Selecting storage pool
image
VIAS: Selecting storage view
image
VIAS: Review and finish

Here is a demo put together by Jen Aspesi to show how VIAS works (Her post on VIAS is here).

Once again here is a brief video that Mr. Danahy and I put together to walk through the benefits of VPLEX Integrated Array Services (VIAS).

To us, VIAS represents a quantum leap forward in terms of simplifying the life of the VPLEX administrator and enabling them to address the data center sprawl. Do let us know what you think!

Talkin’ about VPLEX and RecoverPoint Part 3

It is that time again. Our marketing team has been at it developing more videos to communicate the value of VPLEX and RecoverPoint. Some of them have incredible art in them, others have things blowing up but they are all fun to share. So, without further ado, here is the next in the ‘Talkin’ about’ series:

  1. DataCrunchers: Data Center Detonation: Here Steve Todd (T: @SteveTodd and his wonderful Information Playground Blog) and Nga Nguyen demonstrate Continuous Availability with VPLEX by using some C4 explosives.

  2. Big Ideas; Big Tech: How to protect mission critical environments: This next one talks about the business impact of failure of mission critical environments and how with a combination of VMAX, RecoverPoint and VPLEX from EMC, you can build a comprehensive local and remote protection strategy for such environments.

Do take a look at these videos – I like how they simplify continuous availability concepts to make them consumable by a larger audience. Needless to say, I am a HUGE fan of these videos!

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

Virtual Volume Expansion - Step 1
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
Virtual Volume Expansion Step 2

You need to run the virtual-volume-expand command on VPLEX. Here is what the command looks like:
virtual-volume expand
[-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.

  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)
    • 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)
  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 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

Can engines in a VPLEX Cluster be split?

UPDATE Feb 1st, 2014: I had captured some details incorrectly about the Director Witness which I have corrected below.

This question has been asked on the EMC Community Network and comes up multiple times in various contexts.

The goal is to allow multiple engines within a VPLEX cluster to be deployed across multiple racks instead of a single rack.

There are two primary reasons that this request comes up:

  • Customer intends to upgrade the number of VPLEX engines. However, in the time between the original deployment and when new engines are being purchased, they have repurposed the space in the rack where VPLEX is deployed for other equipment.
  • Customer considers a single rack as a single point of failure. More on that later.

Our usual (only?) answer to this is that we do not support this configuration. That usually leads to some perplexed looks followed by a long explanation.

Let’s start with how the VPLEX HW is built.

VPLEX hardware has been built with redundancy all the way through for a high availability infrastructure. Every component in the platform is redundant. The basic building block is a VPLEX Engine that has two directors. As multiple engines are added, each of these engines are connected through an intra-cluster communication channel (colloquially called the Local COM). Again, with redundancy in mind, the Local COM consists of two physically independent networks.

The plot thickens. Some more platform details: The VPLEX directors share the responsibility of monitoring the Local COM for any failures so that partitions (severing of Local COM links between VPLEX engines) can be handled if appropriate. In fact, each VPLEX cluster has another witness we internally refer to as the Director Witness (not to be confused with its more illustrious and well known sibling – the VPLEX Witness which is responsible for monitoring across VPLEX Clusters).

Now, given the variability of potential customer deployments, it was critical that we find a scalable way of maintaining four physically redundant networks to enable delivery of the high availability that our customers expect.

The way that we accomplish this is by requiring that the engines be collocated in the same rack and configured in the same exact way. Without this requirement, the level of redundancy becomes difficult to ensure. Deployments can be highly variable and the core platform requirements that I described above get compromised. Not to mention the challenges to our services organization of working through these variable configuration details. The bottom line is that without mandating the strict configuration and deployment requirements I outlined above, the probability of multiple failures happening simultaneously increases leading to compromised availability.

If this explanation works for you, you can skip the next two paragraphs.

======== [gory tech detail alert begin] ===========
[For those who want the next level of detail, we dream up quadruple failures and argue about the probability of failures before determining how failure handling should take place within the system. If that sounds like a whole lot of fun, it is! With a co-racked system, the perturbations to the system are dramatically reduced, changing the equation for what assumptions the director witness can make.

The VPLEX Witness has completely different failure handling characteristics since it has to account for two separate racks, WAN links, two data centers … You get the idea].
======== [gory tech detail alert end] ============

There was one additional question above – about a rack being considered as a single point of failure. There are multiple things to consider:

  • First and foremost, VPLEX has hardware availability built from the ground up. Everything in the basic platform building block is a multiple of two. So, the classic reason for rack separation (around fault domain separation such as power phases etc) are accounted for in the HW deployment architecture.
  • As we started engaging in this conversation further, what usually emerges is that the customer is concerned about fault domain redundancy (e.g. I want to protect across sprinkler heads as an example). And VPLEX Metro with the Witness is designed precisely to enable this particular use-case.

We are always open to feedback from you about new use cases we can build our products for. And as I have seen, customers always provide insights that constantly confound our assumptions (and that is GOOD!). This is one which has some interesting possibilities that we continue to explore. So in case you want to talk, you know how to reach me!