Unsolved
This post is more than 5 years old
2 Posts
0
5493
VPlex encapsulation
Hi,
We are in the process of planning some fairly major migrations using VPLex.
We will be using the VPlex encapsulation process to virtualise our existing LUNs behind the Vplex, then at a future date migrate these onto new Storage.
So onto my question...
During previous migrations using HDS storage we have used a product called Hitachi Tiered Storage manager (pretty similar to what the VPlex does).
With HTSM it is possible to map the LUNs being virtualised to a spare port on the Source Subsystem then virtualise these behind the target Subsystem prior to the Host cutover
ie. the host is connected to ports 1a and 1b on the source subsystem for instance, however the LUNs assigned to that host are also presented down a different pair of ports ie. 1c & 1d and it is these ports that connect to the virtualisation Subsystem.
(SCSI reservations etc. are handled by setting a mode on the externalistion ports)
What this means is that there is much less downtime when you come to cut the Servers over to the new storage as you don't have to wait for the "encapsulation" process to complete. Furthermore, it is also possible to gather the UID/WWID information up front, which saves a lot of time bringing the virtualised LUNs back into the OS.
Is there similar functionality with VPlex ?
e.g. Can I map my host LUNs to a spare port on my source Subsystem, connect my VPlex to these ports, and encapsulate the LUNS up front prior to the host cutover, or does the VPlex need to sit in the datapath post encapsulation for some reason ?
echolaughmk
522 Posts
0
July 2nd, 2015 05:00
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
Kelv1
2 Posts
0
July 2nd, 2015 07:00
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.
snalluri
28 Posts
0
July 2nd, 2015 08:00
Thanks for your prompt reply..thanks alot !!
echolaughmk
522 Posts
0
July 2nd, 2015 08:00
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.
snalluri
28 Posts
0
July 2nd, 2015 08:00
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 ?
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
September 20th, 2016 20:00
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.