Category Archives: migrations

Does VPLEX do migrations?

One of the fun parts of my job is interacting regularly with customers at various forums. And often, these discussions result in insights about what the product needs to do, where we need to focus. Once in while, it tells us about what we are communicating out, what our customers and field hear. Here was one such exchange at an EBC this past week.

ME: VPLEX is the best thing since sliced bread (paraphrasing my hyperbole here :-))
CUSTOMER: Does VPLEX do migrations?
ME: Yes, VPLEX does Mobility and Availability
CUSTOMER: Understand and we are really excited about that. However, can VPLEX allow me to refresh my storage
ME: (confused) Yes, it can
CUSTOMER: Meaning if I have VPLEX in place, I can bring a new storage array in and migrate my current array to that new array without any disruption to the host?
ME: (Getting the hang of what’s going on) Yes
CUSTOMER: And do the arrays need to be of the same type?
ME: No. They can be different.
CUSTOMER: Can VPLEX do this for non EMC arrays as well?
ME: Yes. We have over 45 different array families supported and more families are being added every month.
CUSTOMER: Nothing in the product details (white papers / collateral) describes this use-case …
ME: (Sheepishly) Valid feedback – I will take that back to my team to figure out what we can do about this.

For the customer who helped bring this to my attention (and you know who you are) – many thanks. You were TOTALLY right. Because here is what happened that very day. I got a note from our field team asking about which products to use for a migration activity. And the same discussion that we had in the morning happened as bits on the wire later that day. So, independent of what we say or dont say about migrations, it is clear that the message is not being heard as much as it should be. This post is to at least begin to set the record straight on VPLEX and Migrations.

So, VPLEX definitely does do migrations. There are two variants of the use-case.

  1. Tech-refresh of an array
    Here a new array is brought in (either because a lease on an existing array has run out or because a new array has been purchased). Volumes from an existing array or arrays are migrated onto the new arrays. Typically, the older arrays are then retired or repurposed for other usage.
  2. Load balancing across arrays
    Here there are multiple arrays behind VPLEX. Either because of capacity reasons or performance reasons or the need for some specific capability, volumes are moved from one array to another. Both arrays continue to be kept in service.

VPLEX Local can be used to accomplish both use-cases above. VPLEX Metro adds one more variant to the above use-case(s) – Migrating across arrays across data centers. In other words, VPLEX Metro extends the pool of arrays that you can manage beyond the confines of your data center.

Specifically, here are things to remember about VPLEX migrations:

  1. VPLEX migrations are non-disruptive. In other words, the application does not need to be stopped in order to migrate storage.
  2. VPLEX is fully heterogeneous. It supports both EMC and non-EMC arrays. My standard note to customers is always refer to the VPLEX Simple Support Matrix on powerlink.
  3. The source array and target array of the migration can be any of the supported set of arrays. In other words, you do _NOT_ need to migrate from like to like.

How do migrations in VPLEX work?

Initial state
Initial state

Here is the basic process of migrations within VPLEX:

  • The new array is connected and exposed to VPLEX and volumes from the new array are exposed to VPLEX
Step 1: Add New Array
Add New Array
  • From here, you have two options (really dependent on the scale of the operations):
    • Migrate on a volume by volume basis
    • Migrate as a batch (especially useful for the tech refresh piece)
Step 2: Create a Mirror
Create a Mirror
  • From then on, VPLEX does its thing and ensures that the volumes on the two arrays are in sync. During this time, I/Os from the host continue. As far as the host is concerned, it continues to see volumes from VPLEX. Host READ I/Os are directed to the source leg. Host WRITE I/Os (if the section has been copied over onto both legs) are sent to both legs of the mirror. After both volumes are in complete sync, I/Os continue until you decide to disconnect the source volume. It is worthwhile pointing out that even after the volumes are in sync, you have the option to remove the destination volume and go back to the source. From that point on, you make the call on when to disconnect the source volume.
Step 3: Disconnect the source array
Disconnect the source array

From the host standpoint, quite literally, it does not know that anything has changed.

More questions that I get about migrations:

  1. Can I control the amount of impact on my host I/Os?Before answering this question, it is important to understand why there may be impact (if any). FWIW, this explanation is true of all storage virtualization solutions doing migrations. Anyone that tells you otherwise is factually incorrect.The host connected to VPLEX has a fixed set of paths to the virtual target presented by VPLEX. The same for the target arrays connected to VPLEX on the backend. Think of these as fixed capacity pipes carrying your I/Os from the front-end to the back-end of VPLEX. Along these same pipes, VPLEX needs to perform copy I/Os (read from the source leg and write to the target leg). So, in a fixed pipe, a migration adds additional I/Os. In other words, some of the capacity in that I/O pipe gets consumed for migrations. How much of that can impact the host depends on how full the I/O pipe was in the first place.To account for the case when the pipe is completely full, VPLEX gives you three knobs that allow you to select the rate of migrations (ASAP / High / Medium / Low). As you can imagine, the higher the copy rate, the higher the impact on host I/Os. So, if you are concerned about host I/O impact, then you should start with the copy rate to low and increase the rate from there.
  2. What should my licensing model be if I have to migrate from old storage to new storage?This is more relevant to the tech refresh variant of the use-case. We heard feedback from a _LOT_ of customers about them wanting to use VPLEX for migrations. However, they were balking at having to license the storage that they were going to migrate from (i.e. the source array). To help with this, we have introduced a free 180-day migration license for VPLEX. This migration license is available with the purchase of an EMC array. So long as VPLEX is licensed on this new array, you have a 180-day license for unlimited capacity to migrate onto the array behind VPLEX. This is compelling if you are especially going through a storage consolidation phase in your data center.

Along the way, we have had some tremendous customer success stories with respect to migrations – right from customers who have reduced their migration times by 90+% to customers who no longer schedule maintenance time for migrations nor do they involve external professional services. We clearly have a lot of work to do with respect to educating everyone about VPLEX and its role in migrations. But this should be a good starting point for the conversation.