ONTAP Discussions

32 bit to 64 bit aggregate migration of destination volumes

emanuel
7,617 Views

Hello all ... this is a follow up on previous post on moving Snap Vault destinations.

The current information is probably related to OnTAP 7G installations but now comes OnTAP 8.X with 64 Bit aggregates.

Kb Article - https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb48810

Uses Snap Mirror as the tool to move to old destination to new destination however VSM is not supported between 32bit and 64bit ( http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel40/pdfs/workflow.pdf page 20 )

Protection Manager's Secondary Space Management is not picking up any of the 64-bit aggregates created on site.

any guidance?

12 REPLIES 12

ron_tech_2010
7,583 Views

Release of reference: DOT 8.0.1 RC1 When replicating volumes by using SnapMirror, synchronously or asynchronously, the source and destination volumes must be of the same type. Both the source and destination volumes must be 64-bit volumes or they must both be 32-bit volumes. When replicating qtrees by using SnapMirror, the source and destination volumes can be of different types. Either the source and or destination volume can be 64-bit or 32-bit. Are you using the same type of destination as the source?

thomas_glodde
7,583 Views

Ron,

he is talking about SnapVault, which is file driven, and can be replicated from 32 to 64bit.

Kind regards

Thomas

smoot
7,583 Views

Yes, the existing relationships are SnapVault, but ProtMgr wants to use VSM (or "vol copy", which has the same restriction) to move the volume between aggregates. That's the issue.

adaikkap
7,583 Views

Starting DFM 4.0 we stopped rebaseline from primary if the destination/secondary volume is out of space or out of inodes.

The only way forward is the migrate the destination volume using Secondary Space Management, which uses VSM to copy the data from old volume to new volume.

Since Ontap does not support VSM between 32bit and 64 bit Aggr SSM throws error that the dst aggr is not suitable for migration.

But SV, QSM and NDMPCopy support copying data between 32 and 64 bit aggr. So re-baseline from primary is the way.

  1. The only way forward is the remove the 32bit RP from the dataset node.
  2. Then set the following options.
      • dfm options set dpReaperCleanupMode= Orphans if its not imported relationships.

      • dfm options set dpReaperCleanupMode=Automatic if its imported relationship
      • Then remove the secondary volume from the dataset.
      • Add the RP containing the 64bit Aggr to the dataset secondary node.

      This will do a rebaseline from primary to the new volume created in the 64 bit aggr, using SV or QSM as per the protection policy.

      The reaper process will cleanup the relationship within 2 to 3 hours.So the new updates dont go to the old volume, but those backup version registered with the dataset are available for restore.

      The advantage is if you need a logner retention then you might be limited by the 255 snapshots and using SSM will not help as that copys the entire volume so the same procedure is required.

      Another way is to instead of step 3 do the below.

      Remove the primary from the old dataset.

      Create a new dataset.

      Add it to the new dataset.

      Add the 64bit RP to the destination node of the dataset.

      By this way you will achieve the same.

      But you will have to retain the old dataset so that the backup version expire on the old secondary volume.( This will help because once all backup version expire you know which secondary volume to delete.)

      But if you go with the first approach you will have to make note of all the destination volume names.

      Another down fall of this approach is conformance will unnecessarily run on the first dataset( we increase the nubmer of dataset count and impact the performance if there a more number of dataset.)

      Regards

      adai

      cschnidr
      7,583 Views

      Guys, this should be possible with this:

      http://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb9540

      I'havent yet the time to try this in the lab. This could be automated by using the powershell plug-in.

      Christoph

      irakli_natsvlishvili
      7,583 Views

      Do I understand correctly that there is no way currently or in future to move from 32-bit to 64-bit volumes when flexclone is used in the source with the preservation of flexclone savings?

      We have bunch of volumes where we use file based flexcones in virtualization environment. Most space savings are 3-5 times greater then original volume size. In one volume we have 1TB physically and 12 TB effectively used data. Moving thee volumes to 64bit without flexclone savings means that we need to buy 5-9 more storage arrays which obviously won't ever happen.

      So, does netapp plans to have an migration option from 32 bit to 64 bit volumes which have flex savings enabled in a forcible future?

      israelmmi
      7,583 Views

      Is there a way to move a plain old LUN and/or Volume without any of the bills and whistles?  For example, if we have a simple file share or SQL LUN which we want to move from x32 to x64, without flexclones or anything else, is there a way?

      BrendonHiggins
      7,583 Views

      We needed to snapvault between 32 and 64 bit aggregates.  Tried to get it working last year

      http://communities.netapp.com/people/BrendonHiggins/blog/2010/06/10/upgrading-to-data-ontap-8

      Would not recommend unless you have DoT 8.0.1 which is now out.  Event then I would not be keen to rush in with a production system until operations manager and other tools have all been upgraded.

      It is my understanding that DoT 8.0.1 has online / in place upgrade to 64 bit aggregates.  Not sure if you could upgrade source and destination while keeping the relationship.  Just it is time to RTFM the feature list.

      Hope it helps

      Bren

      radek_kubka
      7,583 Views
      It is my understanding that DoT 8.0.1 has online / in place upgrade to 64 bit aggregates.  

      Sadly this is (still) not the case:

      http://communities.netapp.com/message/44913#44913

      "Volume SnapMirror and volcopy between different aggregate address types is not supported with Data ONTAP 8.0.x."

      So, reading between the lines, there may be some hope for 8.1 to fix it eventually (whenever it surfaces).

      Regards,
      Radek

      aborzenkov
      5,857 Views

      No; you still have to pay the bills.

      Sorry, could not resist ☺

      sriegerdss
      5,857 Views

      use qsm to migrate it, yes its still a copy but it works

      tcraig
      5,857 Views

      http://now.netapp.com/NOW/knowledge/docs/ontap/rel81rc1/html/ontap/rnote/GUID-F2B77643-0CF9-4CCB-9734-6146F2653B8F.html

      Supportfor volume SnapMirror replication between 32-bit and 64-bit volumes

      Startingwith Data ONTAP 8.1, you can replicate volumes by using SnapMirror between32-bit and 64-bit volumes. For both synchronous and asynchronous volumereplication, the SnapMirror source and destination volumes can be either 32-bitor 64-bit.

      Public