VMware Cloud Community
Tanner_R
Enthusiast
Enthusiast
Jump to solution

Move ESX clusters out from behind VPLEX?

Hello everyone,

We currently have several ESX clusters sitting on a VMAX array behind VPLEX. We want to keep the clusters on VMAX, but move them out from behind the VPLEX array (direct attach from VMAX).

I am predominantly a Storage Analyst, so forgive me for my ignorance. These are the three (potential) options I see:

  1. Provision new LUNs directly from the VMAX, vMotion VMs onto the new LUNs and decom the VPLEX LUNs. - I know this will work, but it will require the most effort.
  2. Leave the VPLEX LUNs connected, and attach the same LUNs to the cluster from the VMAX. - this would be the easiest, but I am not confident it would work because the disk NAA is virtualized on the VPLEX. This would mean that the ESX cluster would see the same disk with two different NAA numbers.
  3. Take an outage on the entire cluster, remove the disks from VPLEX, reattach the same LUNs directly from VMAX. - I think this would work, as long as VMWare can still recognize the VM data once the disks are re added?

  

My question is, does anyone have experience with #2 or #3? Will either work, or is there a better way?

Any information is appreciated.

Thanks,

Tanner

Tags (3)
1 Solution

Accepted Solutions
Tanner_R
Enthusiast
Enthusiast
Jump to solution

Hi Depping,


We were going to proceed with testing, but we got some helpful information from the EMC support community. They had the following to say:

"...the VPLEX has its own read cache, so if a volume is written to outside of VPLEX (directly to VMAX) the cache will contain invalid data for those blocks, as the VPLEX would not know they had been updated since the last time they were read from disk, and you could get data corruption."


In light of this point, we have decided to just provision new direct attached VMAX LUNs and vMotion as necessary. As with most shops, we cant take a chance that something gets messed up and we loose data.

Thanks,

Tanner


View solution in original post

0 Kudos
4 Replies
Tanner_R
Enthusiast
Enthusiast
Jump to solution

As I suspected, it looks like option #3 is really out of the picture at this point (cannot take the outage). Still curious if anyone has any experience with scenario #2.

0 Kudos
depping
Leadership
Leadership
Jump to solution

I would simply test this with 1 newly created LUN, present it through VPLEX to the cluster, deploy a VM on it. Now remove it from VPLEX and present it from VMAX and see what happens. My guess is that you will need to register the VM again as it is being seen as a different LUN. But it would be best to discuss this with EMC

Tanner_R
Enthusiast
Enthusiast
Jump to solution

Hi Depping,

Assuming we get approval from management, we plan to do exactly that. We have a test cluster that we are going to try the process on. I will post back the results.

Thanks,

Tanner

0 Kudos
Tanner_R
Enthusiast
Enthusiast
Jump to solution

Hi Depping,


We were going to proceed with testing, but we got some helpful information from the EMC support community. They had the following to say:

"...the VPLEX has its own read cache, so if a volume is written to outside of VPLEX (directly to VMAX) the cache will contain invalid data for those blocks, as the VPLEX would not know they had been updated since the last time they were read from disk, and you could get data corruption."


In light of this point, we have decided to just provision new direct attached VMAX LUNs and vMotion as necessary. As with most shops, we cant take a chance that something gets messed up and we loose data.

Thanks,

Tanner


0 Kudos