ndecken Absent Member.
Absent Member.
2178 views

Migrate DST Shadow Volumes

Hi,
we have to migrate a server with shadow volumes to new hardware.
Assuming the following situation:

Source Server:
- SLES11 SP1 OES11
Pool DATA 500 GB with Volume DATA 500 GB almost full (Primary Volume)
Pool SH_DATA 500 GB with Volume SH_DATA 500 GB almost full (Shadow Volume)
No more space left on the Server

Target Server:
- SLES11 SP3 OES11 SP2
app. 2 TB free Space

What I found in the documentation:

Migrating with the Shadow Volume Relationship: Only 1 GB of data from the source server can be migrated to the primary volume Vol4 of the target server. If you need the data on all the volumes of source server to be migrated to the target server, perform the following:


NOTE:You require to stop the DST policies temporarily before performing migration.


1.Stop the existing DST policies.


2.Create a project to migrate the data less than or equal to 1 GB from the source server to the target server.


3.Perform the migration.


4.(Conditional) If some files or folders were open on the source server and did not get migrated to the target server, perform synchronization.

Synchronization must be performed before performing the next step.


5.Configure a DST policy on the target server to move the migrated data from the primary volume to the secondary volume.

As a result, there is space available on the primary volume of the target server to migrate additional data from the source server.


6.Stop the DST policy after the required data is moved from the primary volume Vol4 to the secondary volume Vol5.


7.Repeat Step 2 to Step 6 until the entire data is migrated.




Following the doku I have to perform 1000 migations for 1TB data?
Is there a smoother way to do the migration of the volumes?

Best regards
Nico
Labels (2)
Tags (3)
0 Likes
13 Replies
Knowledge Partner
Knowledge Partner

Re: Migrate DST Shadow Volumes

No, there's a better way, but you just have to be careful.

I'm going to paraphrase a lot here, so this is just a VERY brief overview:

You will stop any DST migrations (prevent it from running). You will need to make sure that nobody is changing quotas OR file rights as well.
Make sure your TARGET server has the same primary/shadow volume names (you can setup the disk space however you want, as long as it has AT LEAST the same amount as the SOURCE).

You will enable NCP binding on the SOURCE Shadow volume temporarily. You will immediately go into the Miggui and create your project, so that it "sees" both source volumes.

You can then disable the NCP binding on the SOURCE Shadow volume.

Migrate your data.

That's pretty much it.

--Kevin
0 Likes
ndecken Absent Member.
Absent Member.

Re: Migrate DST Shadow Volumes

Hi Kevin,
thanks for the brief description, life can be so easy 😉
I wonder why it is not in the documentation.
Best Regards
Nico
0 Likes
Knowledge Partner
Knowledge Partner

Re: Migrate DST Shadow Volumes

ndecken;2338140 wrote:
Hi Kevin,
thanks for the brief description, life can be so easy 😉
I wonder why it is not in the documentation.
Best Regards
Nico


Well, I'd heard that there were some issues with the scenario I described and that's why it's not officially supported (ie, if you enable the NCP binding and then someone changes file permissions, it totally screws things up).

There were two other scenarios I think, but I'd have to dig up my notes on that.

I was hoping by OES11 SP2 that they'd have something officially supported as obviously we weren't the only customers in the same boat where we didn't have enough disk space to re-shift back to the primary and we couldn't break the shadowing for days to copy the data either.

--Kevin
0 Likes
Knowledge Partner
Knowledge Partner

Re: Migrate DST Shadow Volumes

ndecken;2338140 wrote:
Hi Kevin,
thanks for the brief description, life can be so easy 😉
I wonder why it is not in the documentation.
Best Regards
Nico


If you can PM me your email address I'll see if I can scrub that section of our docs (we've obviously done this many times on most of our servers) if you want the step-by-step.

Keep in mind, the method I describe is NOT supported by Novell and you do run the risk (if someone is changing NSS rights/quotas) during the time you're exposing things via NCP that bad ju-ju can happen.

Or if you're going to brainshare, I can discuss further as well
--Kevin
0 Likes
ndecken Absent Member.
Absent Member.

Re: Migrate DST Shadow Volumes

kjhurni;2338229 wrote:
If you can PM me your email address I'll see if I can scrub that section of our docs (we've obviously done this many times on most of our servers) if you want the step-by-step.

Keep in mind, the method I describe is NOT supported by Novell and you do run the risk (if someone is changing NSS rights/quotas) during the time you're exposing things via NCP that bad ju-ju can happen.

Or if you're going to brainshare, I can discuss further as well
--Kevin


Hi Kevin,
sorry, I didn't saw that you was writing another post.
We didn't performed the migration yet, a step-by-step would be nice, I'll PM you my email address.
But an other scenario 😉
One of our customers has a FC-SAN and has several LUN's on it. some of these are DST volumes.
Now he get's an iSCSI low performance storage and want to move the DST volumes off from the FC-SAN to the iSCSI storage.
Both storages are visible by the Vsphere hosts, where the fileservers reside on.
My plan is:
1. create new volume on the iSCSI storage and name it DST_VOL2
2. turn off any DST policies
3. migrate the old DST Volume named DST_VOL1 to DST_VOL2
4. dismount and delete DST_VOL1
5. rename DST_VOL2 to DST_VOL1
will this work, or is there an other possibility to do this work?
Best regards
Nico
0 Likes
Knowledge Partner
Knowledge Partner

Re: Migrate DST Shadow Volumes

ndecken;2346853 wrote:
Hi Kevin,
sorry, I didn't saw that you was writing another post.
We didn't performed the migration yet, a step-by-step would be nice, I'll PM you my email address.
But an other scenario 😉
One of our customers has a FC-SAN and has several LUN's on it. some of these are DST volumes.
Now he get's an iSCSI low performance storage and want to move the DST volumes off from the FC-SAN to the iSCSI storage.
Both storages are visible by the Vsphere hosts, where the fileservers reside on.
My plan is:
1. create new volume on the iSCSI storage and name it DST_VOL2
2. turn off any DST policies
3. migrate the old DST Volume named DST_VOL1 to DST_VOL2
4. dismount and delete DST_VOL1
5. rename DST_VOL2 to DST_VOL1
will this work, or is there an other possibility to do this work?
Best regards
Nico


Hello Nico,

Massimo may be the better authority on this one, but I *think*:

IF you are on OES11 (preferably SP2), and the server in question can see both storage items, that you could simply do a pool MOVE of the DST Pool from the FC SAN to the iSCSI SAN and that would be all you'd have to do.

If you're not on OES11, I'd still suggest just upgrading to OES11 SP2 and then doing the pool move.
Unless Massimo or the others have a better idea of handling what you want.

--Kevin
0 Likes
HvdHeuvel Absent Member.
Absent Member.

Re: Migrate DST Shadow Volumes

On Wed, 11 Feb 2015 15:56:01 +0000, kjhurni wrote:

> ndecken;2346853 Wrote:
>> Hi Kevin,
>> sorry, I didn't saw that you was writing another post.
>> We didn't performed the migration yet, a step-by-step would be nice,
>> I'll PM you my email address.
>> But an other scenario 😉
>> One of our customers has a FC-SAN and has several LUN's on it. some of
>> these are DST volumes.
>> Now he get's an iSCSI low performance storage and want to move the DST
>> volumes off from the FC-SAN to the iSCSI storage.
>> Both storages are visible by the Vsphere hosts, where the fileservers
>> reside on.
>> My plan is:
>> 1. create new volume on the iSCSI storage and name it DST_VOL2 2. turn
>> off any DST policies 3. migrate the old DST Volume named DST_VOL1 to
>> DST_VOL2 4. dismount and delete DST_VOL1 5. rename DST_VOL2 to DST_VOL1
>> will this work, or is there an other possibility to do this work? Best
>> regards Nico

>
> Hello Nico,
>
> Massimo may be the better authority on this one, but I *think*:
>
> IF you are on OES11 (preferably SP2), and the server in question can see
> both storage items, that you could simply do a pool MOVE of the DST Pool
> from the FC SAN to the iSCSI SAN and that would be all you'd have to do.
>
> If you're not on OES11, I'd still suggest just upgrading to OES11 SP2
> and then doing the pool move.
> Unless Massimo or the others have a better idea of handling what you
> want.
>
> --Kevin


In order to use a 'pool move (or plsit)' you need to migrate date back
from Secondary to Primary first ....

https://www.novell.com/documentation/oes11/stor_dfs_lx/data/b9rhmux.html


Thanks
Hans
0 Likes
Knowledge Partner
Knowledge Partner

Re: Migrate DST Shadow Volumes

HvdHeuvel;2347030 wrote:
On Wed, 11 Feb 2015 15:56:01 +0000, kjhurni wrote:

> ndecken;2346853 Wrote:
>> Hi Kevin,
>> sorry, I didn't saw that you was writing another post.
>> We didn't performed the migration yet, a step-by-step would be nice,
>> I'll PM you my email address.
>> But an other scenario 😉
>> One of our customers has a FC-SAN and has several LUN's on it. some of
>> these are DST volumes.
>> Now he get's an iSCSI low performance storage and want to move the DST
>> volumes off from the FC-SAN to the iSCSI storage.
>> Both storages are visible by the Vsphere hosts, where the fileservers
>> reside on.
>> My plan is:
>> 1. create new volume on the iSCSI storage and name it DST_VOL2 2. turn
>> off any DST policies 3. migrate the old DST Volume named DST_VOL1 to
>> DST_VOL2 4. dismount and delete DST_VOL1 5. rename DST_VOL2 to DST_VOL1
>> will this work, or is there an other possibility to do this work? Best
>> regards Nico

>
> Hello Nico,
>
> Massimo may be the better authority on this one, but I *think*:
>
> IF you are on OES11 (preferably SP2), and the server in question can see
> both storage items, that you could simply do a pool MOVE of the DST Pool
> from the FC SAN to the iSCSI SAN and that would be all you'd have to do.
>
> If you're not on OES11, I'd still suggest just upgrading to OES11 SP2
> and then doing the pool move.
> Unless Massimo or the others have a better idea of handling what you
> want.
>
> --Kevin


In order to use a 'pool move (or plsit)' you need to migrate date back
from Secondary to Primary first ....

https://www.novell.com/documentation/oes11/stor_dfs_lx/data/b9rhmux.html


Thanks
Hans


Rats, that stinks. Kinda makes it useless for DST, but I think its' the wrong thing.

I'm referring to this:

https://www.novell.com/documentation/oes11/stor_nlvm_lx/data/move_pool.html

Not a DFS move which is very different.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Migrate DST Shadow Volumes

ndecken;2346853 wrote:
Hi Kevin,
sorry, I didn't saw that you was writing another post.
We didn't performed the migration yet, a step-by-step would be nice, I'll PM you my email address.
But an other scenario 😉
One of our customers has a FC-SAN and has several LUN's on it. some of these are DST volumes.
Now he get's an iSCSI low performance storage and want to move the DST volumes off from the FC-SAN to the iSCSI storage.
Both storages are visible by the Vsphere hosts, where the fileservers reside on.
My plan is:
1. create new volume on the iSCSI storage and name it DST_VOL2
2. turn off any DST policies
3. migrate the old DST Volume named DST_VOL1 to DST_VOL2
4. dismount and delete DST_VOL1
5. rename DST_VOL2 to DST_VOL1
will this work, or is there an other possibility to do this work?
Best regards
Nico


This may be changing since I was intending to refer to this when I said Pool Move:

https://www.novell.com/documentation/oes11/stor_nlvm_lx/data/move_pool.html

So hopefully the link Hans posted is only for DFS moves (which I'm not referring to).

IF the same rules apply then:

Well since we have some product limitations with the pool move at this point, I'm going to assume you're in a non-clustered setup?
If so, then I guess the only ways I can think of:
1) If you're on OES11, I believe the max size for pools in 9 TB now? Maybe you can expand the Primary pool to be large enough to then re-shift the Shadow pool back and THEN pool move and then re-shadow it? Depending upon your VMware version, you may need to use RAW disks (I think in 5.5 you're still limited to 2 TB disks?)

2) If you're going to use your above method, I think you'll need some significant downtime (I'm assuming you're using the same server, just diff. disks), because you'll need to break the DST shadow relationship, (not just stop the policies, literally de-shadow the volumes) which means users won't have access to their shadowed data and then do the copy/migrate as you mentioned.

3) IF you were going to another/different server, then you could use the miggui with my unsupported method (or maybe it's supported now) which only involves a brief break of the shadow (just long enough to build the migration project so it sees 2 diff. volumes) and then away you go.

Unless someone has another/better way to move storage items and retain the shadow relationship? I'm not a VMware expert, but MAYBE (not sure) there's an option in VMware to migrate a vdisk from one to another (or the vmdk files??) while the system is online? But I don't think so. I know there's a storage migration, but usually that's the entire VM Guest itself, not just a specific disk.

But, IF Vmware has something nifty, you could have a VM Storage that's on the iSCSI and maybe "move" the Virtual disk to that new iSCSI storage, but again, not sure how that'd be handled or what would happen in the underlying OS. I suppose it's possible to have the VM LUN/Storage be on iSCSI, yet be presented to the Guest as regular SCSI storage since it's virtualized??

I know Massimo does lots with iSCSI and such.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Migrate DST Shadow Volumes

HvdHeuvel;2347030 wrote:
On Wed, 11 Feb 2015 15:56:01 +0000, kjhurni wrote:

> ndecken;2346853 Wrote:
>> Hi Kevin,
>> sorry, I didn't saw that you was writing another post.
>> We didn't performed the migration yet, a step-by-step would be nice,
>> I'll PM you my email address.
>> But an other scenario 😉
>> One of our customers has a FC-SAN and has several LUN's on it. some of
>> these are DST volumes.
>> Now he get's an iSCSI low performance storage and want to move the DST
>> volumes off from the FC-SAN to the iSCSI storage.
>> Both storages are visible by the Vsphere hosts, where the fileservers
>> reside on.
>> My plan is:
>> 1. create new volume on the iSCSI storage and name it DST_VOL2 2. turn
>> off any DST policies 3. migrate the old DST Volume named DST_VOL1 to
>> DST_VOL2 4. dismount and delete DST_VOL1 5. rename DST_VOL2 to DST_VOL1
>> will this work, or is there an other possibility to do this work? Best
>> regards Nico

>
> Hello Nico,
>
> Massimo may be the better authority on this one, but I *think*:
>
> IF you are on OES11 (preferably SP2), and the server in question can see
> both storage items, that you could simply do a pool MOVE of the DST Pool
> from the FC SAN to the iSCSI SAN and that would be all you'd have to do.
>
> If you're not on OES11, I'd still suggest just upgrading to OES11 SP2
> and then doing the pool move.
> Unless Massimo or the others have a better idea of handling what you
> want.
>
> --Kevin


In order to use a 'pool move (or plsit)' you need to migrate date back
from Secondary to Primary first ....

https://www.novell.com/documentation/oes11/stor_dfs_lx/data/b9rhmux.html


Thanks
Hans


Hans, you sure about that? The docs imply it's regarding the DFS Move feature. I'm referring to the Pool Move command that was introduced in OES11 that allows you to consolidate the pool segments. DFS moving is different as it's regarding the Junction moves.

At least that's how it was in OES2 (no pool move feature, but DFS move operations aren't pool level events)
0 Likes
ndecken Absent Member.
Absent Member.

Re: Migrate DST Shadow Volumes

Hi Kevin,
looks like a pool move would be fine to me, since I use RAW devices for the NSS LUN's there is no way to do it with VMware tools.
I'll give it a try in our test environment.
Thank's a lot
Nico
0 Likes
ndecken Absent Member.
Absent Member.

Re: Migrate DST Shadow Volumes

The pool move works like a charm with DST Volumes, I've just tested it in our test environment.
Thanks for all
Best regards
Nico
0 Likes
Knowledge Partner
Knowledge Partner

Re: Migrate DST Shadow Volumes

ndecken;2347130 wrote:
The pool move works like a charm with DST Volumes, I've just tested it in our test environment.
Thanks for all
Best regards
Nico


Great, thanks for letting us know.

I'll try to remember to send you the migration document during the weekend. Keep in mind it's not supported by Novell, but it did work for us (and we did like 30 servers without issue).
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.