VPlex encapsulation

With VPLEX you can prepare many of the encapsulation tasks ahead of time and present the LUNs you plan to encapsulate that are being natively accessed today to the VPLEX ahead of time and even claim the volumes in some scenarios where SCSI reservations won't prevent you from doing so. Doing these preparation steps ahead of time (masking/zoning) will enable you to cut down on the cutover time and it essentially becomes a quick process to cutover the volumes. Items you can prepare ahead of the encapsulation:

1. Host zoning to VPLEX FE ports

2. Host Registration of initiators in VPLEX

2. LUN masking/zoning to the VPLEX BE Ports

3. Storage View container creation in VPLEX (put only the VPLEX FE ports in this for now)

Therefore the cutover process would look like this when it comes time:

1. Bring down host and native LUN access

2. Remove native LUN access/masking

3. Claim/Encapsulate the LUNs under VPLEX control (LUN masking and zoning to VPLEX BE has already been prepped)

4. Create a 1:1 mapping of Storage volume:virtual volume with the EZ Provisioning Wizard (this step is quick and you want 1:1 mapping to preserve the data in its current state)

5. Add the newly encapsulated 1:1 virtual volume into the previously created Storage View container and add the previously registered host initators to the Storage View as well at this time

6. Rescan the host and import the LUNs (Note the VPD ID of the LUNs will change since they are presented through VPLEX now and not natively, so you will just have to import on the host side accordingly depending on the OS and LVM)

What might be key to note here (and I don't know about how HTSM does it) is that the "encapsulation" process is fairly quick on the VPLEX side. You had mentioned you had to wait for some amount of time above, but there is no process for encapsulating a LUN on a VPLEX - it is really just a matter of zoning/masking the same LUN through the VPLEX. This is using the 1:1 mapping which essentially preserves the existing LUN layout all the way through and takes second to do so. So I'm not if the case is the same with HTSM, but wanted to point it out since even if you didn't do the prep steps above, the cutover process is pretty quick (as quick as you can do zoning and masking tasks )

HTH,

-K

Perfect, thanks K,

This clarifies what I thought was the case i.e. that the VPlex needs to be placed in the data-path prior to the encapsulation task.

All the best

Kelv.

Thanks for your prompt reply..thanks alot !!

That can be done with some operating systems ahead of time, but I generally don't recommend it for conservative reasons. Some operating systems or reservation conflicts (like clusters) will prevent this if you try to claim the storage volume so you will get an error and have to wait until the LUNs are not accessed (when you power down the host or export volume groups).

The workaround if you can't or want to be very conservative with the process is to potentially script the claiming wizard and creation through CLI as well.

I have a question here, If there are too many luns presented to multiple hosts, it will take time to encapsulate them right ? Once you have B/E,F/E zoning ready,registered the initiators,SViews in place , Is that ok to encapsulate all these volumes up to the virtual volume level but not going to present them to Storage view so that we can reduce more downtime ?

A bit off topic but related to the Encapsulation itself. Does Encapsulation work or works well for Thick LUNs to Thin LUNs between two VNXs at backend?

Thanks.