Migrating Volumes Used by SMO and DFM datasets
2017-08-26 07:22 PM
I'm planning to migrate source and destination volumes of snapvault relationships to new filers, but all SnapVault relationships are being managed by DFM, and to add more complexity I have some Oracle servers running SMO with SnapVault relationships also being managed by DFM.
So, let's suppose my current source filers are old-src1, my current destination filer is old-dst1, my new source file is new-src1 and my new destination filer is new-dst1.
I don't have any problem to migrate primary volumes from old-src1 to new-src1, and also from old-dst1 to new-dst1. The steps below summarize what I'm doing:
1) Create new src and dst volumes in both filers (using the same original name);
2) Perform SnapMirror from old filers to new filers;
3) Break SnapMirror relationships;
>>>> NOW THE STEPS IN THE DFM STARTS <<<<
4) Set 'dpReaper' in the DFM to "Never". This is to make sure that during the migration, the conformance or reaper does not reap any relationship;
5) Suspend all DFM datasets that will have src/dst volumes migrated to new filers;
6) Relinquish the relationships in the DFM;
7) Remove the current primary vols/qtrees from the 'Primary data' node;
8) Remove the current snapvault destination volumes from the 'Backup' node;
9) Relinquish the primary qtrees from the DFM datasets;
10) Add the snapvault configuration information to the filer new-dst1 through the command snapvault start -r -S.
Note: After this command, filer new-dst1 recognizes all snapvault relationships coming from filer new-src1
11) Add the new snapvault destination volumes (in new-dst1) in the DFM;
12) Import the new external relationships (from new-src1 to new-dst1) to the dataset;
13) Resume the DFM datasets
14) Set 'dpReaper' in the DFM to "Orphans".
This procedure works fine but I have two "inconveniences":
A) Specific for SMO I have two commands to do (below) on the Oracle servers running SMO as last steps:
> snapdrive dataset changehostname -dn <DATASET_NAME> -oldname old-src1 -newname new-src1
> smsap storage rename -profile <SMO_PROFILE> -oldname old-src1 -newname new-src1
Finally, after the above steps I can run the following SMO operations using snapvault snapshots created before the migration:
-> Create backups (primary and secondary) with SMO;
-> I can mount primary snaps using SMO;
-> I can clone the DB using primary snaps through SMO;
-> I can restore the DB using primary snaps through SMO;
But I CANNOT perform Mount, Clone and Restore operations through SMO using snapvault snapshots created before the migration (it works when I use snapvault snapshots created after the migration). I receive a message saying "Could not locate remote snapshot". It seems that SMO is not being able to find the snapshots created before migrate the filers, BUT WHY?. See the full error message below:
--[ INFO] SMO-13036: Starting operation Backup Mount on host rhel65-oradb01
--[ INFO] SMO-13046: Operation GUID 402880745e052eac015e052eb47e0001 starting on Profile PROF_ORADB02
--[ INFO] DS-10001: Connecting mountpoints [/u02/oradb02/datafiles] from snapshot smo_prof_oradb02_oradb02_f_h_1_402880745dfd9eec015dfd9ef5ab0001_0 in copy 63 of backup 1503198695 of dataset smo_rhel65-oradb01_oradb02.
--[ERROR] FLOW-11019: Failure in ExecuteConnectionSteps: SD-10028: SnapDrive Error (id:2868 code:102) Could not locate remote snapshot or remote qtree for new-src1:/vol/vol_ora_datafiles02:smo_prof_oradb02_oradb02_f_h_1_402880745dfd9eec015dfd9ef5ab0001_0
--[ERROR] FLOW-11010: Operation transitioning to abort due to prior failure.
--[ INFO] SD-00016: Discovering storage resources for /opt/NetApp/smo/mnt/-u02-oradb02-datafiles-20170820004027188_0.
--[ INFO] SD-00016: Discovering storage resources for /opt/NetApp/smo/mnt/-u02-oradb02-control-20170820004027174_0.
--[ INFO] SD-00016: Discovering storage resources for /opt/NetApp/smo/mnt/-u02-oradb02-archives-20170820004027185_0.
--[ WARN] FLOW-11011: Operation aborted
--[ERROR] FLOW-11008: Operation failed: SD-10028: SnapDrive Error (id:2868 code:102) Could not locate remote snapshot or remote qtree for new-src1:/vol/vol_ora_datafiles02:smo_prof_oradb02_oradb02_f_h_1_402880745dfd9eec015dfd9ef5ab0001_0
--[ERROR] SMO-13032: Cannot perform operation: Backup Mount. Root cause: SMO-11007: Error cloning from Snapshot copy: FLOW-11019: Failure in ExecuteConnectionSteps: SD-10028: SnapDrive Error (id:2868 code:102) Could not locate remote snapshot or remote qtree for new-src1:/vol/vol_ora_datafiles02:smo_prof_oradb02_oradb02_f_h_1_402880745dfd9eec015dfd9ef5ab0001_0
--[ INFO] SMO-13039: Successfully aborted operation: Backup Mount
--[ERROR] SMO-13048: Backup Mount Operation Status: FAILED
--[ INFO] SMO-13049: Elapsed Time: 0:00:26.059
B) When I delete the old filers (old-src1 and old-dst1) from the DFM, all backups created before the migration disappears from Protection Manager (Restore Wizard). I only can see backups created after migrate volumes to new filers. I'm only able to use Operations Managers to restore secundary backups (snapvault snapshots).
I really appreciate if someone can help me understand why it happens, and if there is an option to fix it, or even an workaround. The issue 'A' is my first priority.
Thanks a lot.
Flávio Onofre de Souza