.rws extension LUNs

[dayoojediran]

Hi,

I want to retire a FAS270, so I migrate the data from a FAS270 to a FAS2040c using snapmirror.

On FAS270, I have this from lun show -v

/vol/emailsv06/email.lun   550.0g (590575104000)  (r/w, online, mapped)
                Serial#: hpmNNoDWUqLl
                Share: none
                Space Reservation: enabled
                Multiprotocol Type: windows
                Maps: NGPWCAS05=0
        /vol/emailsv06/{7bf1b7a4-7513-4c16-99e5-8fd8482364b7}.rws  550.0g (59057
5104000)  (r/w, online, mapped)
                Serial#: hpmNNoVZ4R-a
                Backed by: /vol/emailsv06/.snapshot/{25a7bcfb-732b-4bda-8ca7-7c4
479bd71d1}/email.lun
                Share: none
                Space Reservation: disabled
                Multiprotocol Type: windows
                Maps: NGPWCAS05=1

On FAS2040c, I have this from lun show -v

/vol/emailsv06/email.lun   550.0g (590575104000)  (r/o, online)
                Serial#: P3gnVZVoHgz0
                Share: none
                Space Reservation: enabled
                Multiprotocol Type: windows
        /vol/emailsv06/{7bf1b7a4-7513-4c16-99e5-8fd8482364b7}.rws  550.0g (59057
5104000)  (r/o, online)
                Serial#: P3gnVZVoHgzH
                Backed by: /vol/emailsv06/.snapshot/{25a7bcfb-732b-4bda-8ca7-7c4
479bd71d1}/email.lun
                Share: none
                Space Reservation: disabled
                Multiprotocol Type: windows

So I break the snapmirror from the FAS2040c, used snapdrive on the windows server to unmap the original lun from FAS270 and cli to unmap the .rws lun from FAS270 again.

From this windows server, I used snapdrive to map the replicate lun to the server. But when I checked the data on the server, I found that the data was two week old. So I thought that some data still reside on the replicated .rws lun. Then I created an igroup manually and mapped this .rws lun, still the data I found was still old by two weeks.

when i revert back to FAS270, the data was up-to-date. Can somebody help me out on this?

[ogra]

Okay first thing 1st.

.rws luns are the extensions of LUN's which are clones. i.e they are backed up by a Parent LUN using a Snapshot.

I think what is happening here is your Snapmirroring your 2 weeks old Snapshot. Hence both the LUNs are giving you 2 weeks old data.

Check if your Volume has enough space for Snapmirror snapshot. Also, paste us the o/p of the snapshot list when SnapMirror is happening for  the Volume emailsv06.

Also give the 'df -h emailv06' o/p.

You will be able to solve this. We will definitely help you out in this.

Cheers !!!!

[ogra]

Also 1 more thing, do let us know your o/p of /etc/snapMmrror.conf on the destination.

[dayoojediran]

The issue is that my client wants to upgrade its FAS270 to FAS2040c.

So, the plan is to migrate the data on the FAS270 to the FAS2040c with snapmirror,

disconnect the servers connected to the FAS270 and map them to their corresponding LUNs

on the FAS2040c after breaking the snapmirror from FAs2040c.

Following this plan, after making sure that there is a replica on the FAS2040c, the mirror

was broken and the first server, email server, was unmap from the FAS270 using snapdrive

and the re-map to FAS2040c.

When I check the mails on this email server, I discovered that the latest mail was two weeks old.

So, I unmap this server from the FAS2040c and map it back to the FAS270 and I discovered that

the mail were up-to-date.

Ogra, my observation is this, with lun show command on the source filer, FAS270 and the destination filer FAS2040c, I observed that for the email

server LUN, and for some other servers, there were duplicate LUNs but with .rws extension.

/vol/emailsv06/email.lun   550.0g (590575104000)  (r/w, online, mapped)

/vol/emailsv06/{7bf1b7a4-7513-4c16-99e5-8fd8482364b7}.rws  550.0g (590575104000)  (r/w, online, mapped)

Could it be that some data is trapped in this .rws LUNs? I could I resolve this

without losing Data

.

This is from /etc/snapmirror.conf

NGPWC-NETAPP1:emailsv06 ngpwc-netapp1a:emailsv06 - 5,15,25,35,45,55 * * *

This is tyhe output from snap list for emailsv06

Volume emailsv06
working...

  %/used       %/total  date          name
----------  ----------  ------------  --------
  2% ( 2%)    1% ( 1%)  Apr 10 19:37  ngpwc-netapp1a(0135080052)_emailsv06.1 (sn
apmirror)
  2% ( 0%)    1% ( 0%)  Apr 10 05:21  NGPWC-NETAPP2(0084293416)_emailsv06.516
19% (18%)   13% (12%)  Mar 20 21:14  {25a7bcfb-732b-4bda-8ca7-7c4479bd71d1} (bu
sy,LUNs)
33% (20%)   27% (13%)  Mar 08 12:10  NGPWC-NETAPP2(0084293416)_emailsv06.515 (s
napmirror)
34% ( 3%)   28% ( 2%)  Mar 05 21:14  {77f16d25-261e-4da7-9e95-f5941d0ebfd1}

This is the output from lun show -v

/vol/emailsv06/email.lun   550.0g (590575104000)  (r/w, online, mapped)
                Serial#: hpmNNoDWUqLl
                Share: none
                Space Reservation: enabled
                Multiprotocol Type: windows
                Maps: NGPWCAS05=0
        /vol/emailsv06/{7bf1b7a4-7513-4c16-99e5-8fd8482364b7}.rws  550.0g (59057
5104000)  (r/w, online, mapped)
                Serial#: hpmNNoVZ4R-a
                Backed by: /vol/emailsv06/.snapshot/{25a7bcfb-732b-4bda-8ca7-7c4
479bd71d1}/email.lun
                Share: none
                Space Reservation: disabled
                Multiprotocol Type: windows
                Maps: NGPWCAS05=1

[ogra]

Okay.

What I observed is you are doing VSM ( Volume SnapMirror).

Are you aware of doing a QSM ( Qtree SnapMirror ) ? It will try doing a SnapMirror for that particular LUN which you are migrating and not all the LUN's in it.

The current scenario is :

You have a Volume emailsv06 which has 1 data LUN in R/W mode.

/vol/emailsv06/email.lun   550.0g (590575104000)  (r/w, online, mapped)
                Serial#: hpmNNoDWUqLl
                Share: none
                Space Reservation: enabled
                Multiprotocol Type: windows
                Maps: NGPWCAS05=0

The other LUN is a Clone of the Parent LUN which is also  in R/W mode.

/vol/emailsv06/{7bf1b7a4-7513-4c16-99e5-8fd8482364b7}.rws  550.0g (590575104000)  (r/w, online, mapped)
                Serial#: hpmNNoVZ4R-a
                Backed by: /vol/emailsv06/.snapshot/{25a7bcfb-732b-4bda-8ca7-7c4479bd71d1}/email.lun
                Share: none
                Space Reservation: disabled
                Multiprotocol Type: windows
                Maps: NGPWCAS05=1

But if you see the difference you Space reservation for Original LUN enabled while for the Cloned LUN it's disabled ( Which is as per the default parameters).

Now, what should be the next step before Migrating the Data is to identify where is you data actually residing ?

It means you have 2 LUN's mapped on the server and both are in R/W state. You need to carefully study this since you might have 2 versions of you original data.

If you aren't sure on this, let us know how much space you have available in the Volume and Aggregate ?

From the Snapshot list you can easily see

%/used       %/total  date          name
----------  ----------  ------------  --------
2% ( 2%)    1% ( 1%)  Apr 10 19:37       ngpwc-netapp1a(0135080052)_emailsv06.1 (snapmirror)
2% ( 0%)    1% ( 0%)  Apr 10 05:21       NGPWC-NETAPP2(0084293416)_emailsv06.516
19% (18%)   13% (12%)  Mar 20 21:14  {25a7bcfb-732b-4bda-8ca7-7c4479bd71d1} (busy,LUNs)
33% (20%)   27% (13%) Mar 08 12:10  NGPWC-NETAPP2(0084293416)_emailsv06.515 (snapmirror)
34% ( 3%)   28% ( 2%)  Mar 05 21:14   {77f16d25-261e-4da7-9e95-f5941d0ebfd1}

If you don't require old snapshots, you can go ahead and delete them. Also, I think there are 2 SnapMirror relationships you are maintaining. (Highlighted in Red).

Best way forward is to

1) Identify the Original data LUN which you want to transfer, if not sure about the other simply detach the other. Using 'lun clone split <lun-path>' command.

2) This will give you 2 LUN's which have different data written on top of them. Next step should be to remove all Snapshot and keep only 1 latest one.

3) Delete the all the SnapMirror relationships for that Volume.

4) Create a fresh SnapMirror relation, since you have multiple LUN's in the source volume I suggest you start the QSM rather then VSM.

And finally get back to us with the results.  Good Luck !!!

If any time you think you don't have the skill sets in doing the above mentioned steps, you can any time engage NetApp PS folks for Data Migration.

-Bakshana