HPE StoreVirtual Storage / LeftHand
cancel
Showing results for 
Search instead for 
Did you mean: 

Moving Data from multiple LUNs to a Single LUN LH P4300

Erick Arturo Perez
Frequent Advisor

Moving Data from multiple LUNs to a Single LUN LH P4300

Hi, Im looking for guidance from your experience about movind data between LUNs in a 3 node LH 4300.

 

Currently a customer created 3 LUNS to store MS Exchange 2010 databases. The total usage of those iSCSI exported LUNs is about 1 TB.

 

Due to some changes in the structure and the need to use volume replication between the LHP4300 and a group of P4500 we want to consolidate the 3 LUNs exposed for Exchange into 1 LUN (also reducing the iscsi sessions)

 

So far, reading LH docs, the quick solution will be to create a big LUN, and then from the XenServer/XenCenter host copy the virtual disks from LUNs A,B,C to LUN D. However this involves data movement from LH to Xen back to LH.

As I dont have reference figures, does anyone here have an idea of how much aprox time can take to do this operation? Because we also have to plan for email downtime, right?

 

Is there any other method that involves telling the LH "hey, move your contents from LUNs ABC to LUN D"? Or something along those lines?

 

Im using latest CMC fully patched.

 

Thanks for your help.

 

 

3 REPLIES
oikjn
Honored Contributor

Re: Moving Data from multiple LUNs to a Single LUN LH P4300

how many iSCSI connections are you talking about? 

 

I"m usually a "smaller is better" proponent for LUNs unless you are running into the iSCSI connection limit or your switches really really are terrible and you cannot upgrade them.  Reason is that a 1:1 Lun to partition ratio generally makes things easier to manage and minimizes snapshot/backup affects on other LUNs.  In addition, if you are going to use replication more smaller LUNs will minimize the affect of a runnaway LUN killing remote replication times for the other LUNs.  Split LUNs will also help you better identify a resource hog on the SAN if you run into performance issues.

 

Beyond that, "data" can't be read by the SAN, its only allocated bits.  This is not a NAS where it presents files.

 

If for some reason you think you have a really good benefit to joining the LUNs, you might as well just pick one existing LUN and use the expand function to grow it and then disk manager to create new partitions on it and either migrate the data or use another program to clone the existing drive data from one LUN to the other.  If this is 100% exchange data, I think you can move or change the data store locations with minimal/no downtime, but again...  why?

 

 

Erick Arturo Perez
Frequent Advisor

Re: Moving Data from multiple LUNs to a Single LUN LH P4300

Thanks for your answer.

Then, since my existing P4300 G2 is running aout of space and we have a new P4500 Storevirtual, what will be the best way to move from CLuster 1 (P4300) to Cluster 2 (P4500)? both are on same LAN, remote snapshot?

 

oikjn
Honored Contributor

Re: Moving Data from multiple LUNs to a Single LUN LH P4300

Will the all be in the same management group?  If so, then its really simple.  You simply create the new cluster and make sure the initiators have the new cluster VIP set for discovery and then you can right click on a LUN, click edit colume, go to the advanced tab and then you can change the cluster in the dropdown.    Click the "?" to bring up the help to show you what is needed for migrating or moving a volume just to understand what is going on.  Its very easy when they are in the same management group.

 

If they aren't in the same managment group, the easy way is to setup an initial remote snapshot replication partnership and then do a controlled failover to the remote snapshot and convert the remote snapshot to become a primary one.  That is a little more tricky than if they are in the same management group and that one I believe will require a short downtime, but its very short and still pretty easy to do.  The help section also talks about how to do this as well.

 

The great thing is that you can (and should) make some test LUNs to migrate before you do your actual data so you know how its done and can do it quicker :)