2014-10-07 05:29 PM
Has anyone seen this error before? I am trying to mirror a 7 mode volume to a Cluster mode volume but the transfer gets to 3264 KB done then fails.
Tue Oct 7 20:06:16 EDT 2014 Initialize:51f4e849-4e7b-11e4-a809-123478563412 Trace_WDP (1 of 7 log entries): src path: sp-san304-ac1:OIT_ExchangeBackupArchive01, src vserver UUID: 3e71d16c-4e29-11e4-a809-123478563412, src_vsid: 0, src_dsid major_id: 0 minor_id: 0, src_dblade_UUID: , src_cluster_UUID:
Tue Oct 7 20:06:16 EDT 2014 Initialize:51f4e849-4e7b-11e4-a809-123478563412 Trace_WDP (2 of 7 log entries): dst path: D1_C19_SRM01:OIT_ExchangeBackupArchive01, dst vserver UUID: a30d80ee-4b07-11e4-a809-123478563412, dst_vsid: 9, dst_dsid major_id: 1054 minor_id: 0, dst_dblade_UUID: a0b06a2a-d2bb-11e2-b52a-1f89bbf99535, dst_cluster_UUID: ae397990-d341-11e2-8d8f-123478563412
Tue Oct 7 20:06:16 EDT 2014 Initialize:51f4e849-4e7b-11e4-a809-123478563412 Trace_WDP (3 of 7 log entries): handle: 6f862857-4e7e-11e4-a809-123478563412, rel_type: 4, control_op: 0, mirror_state: 0, sm_command: 0, host: 0, snapname_specified: false, dry_run: false, preserve: false, quiesce: false, hard: false
Tue Oct 7 20:06:16 EDT 2014 Initialize:51f4e849-4e7b-11e4-a809-123478563412 Trace_WDP (4 of 7 log entries): ref_snap_state_signal: SM_REF_SNAP_UNKNOWN, wdp_seq_state: SM_WDP_SEQ_NONE, src_xfer_snaps_cleanup: false
Tue Oct 7 20:06:16 EDT 2014 Initialize:51f4e849-4e7b-11e4-a809-123478563412 Trace_WDP (5 of 7 log entries): pending_overrun: false, pending_snap: false, pre_xfer_cleanup: false
Tue Oct 7 20:06:16 EDT 2014 Initialize:51f4e849-4e7b-11e4-a809-123478563412 Trace_WDP (6 of 7 log entries): target_snap_name: snapmirror.a30d80ee-4b07-11e4-a809-123478563412_2147484704.2014-10-07_200247, policy_name: DPDefault, schedule_name: -, aggr_uuid: c7fb326a-de6c-4ac9-b5ec-f37d1cf9f2bc, bytes_transferred: 0
Tue Oct 7 20:06:16 EDT 2014 Initialize:51f4e849-4e7b-11e4-a809-123478563412 Trace_WDP (7 of 7 log entries): active_xfer_snap: -, newest_snap_name: -, exported_snap_name:-, newest_snapshot_crTime: 0, exported_snapshot_crTime: 0, total_xfer_size: 0, xfer_start_crTime: 1412726567, rel_cache_flags: 0
Tue Oct 7 20:06:16 EDT 2014 Initialize:51f4e849-4e7b-11e4-a809-123478563412 SrcPath:sp-san304-ac1:OIT_ExchangeBackupArchive01 DstPath1_C19_SRM01:OIT_ExchangeBackupArchive01 Prim=SM:cid=101,mid=1008, sm_7toc_convert_error:207, Msg=Transfer failed.
Tue Oct 7 20:06:16 EDT 2014 Initialize:51f4e849-4e7b-11e4-a809-123478563412 Trace_Buf (1 of 1 log entries): (EVT#53);(EVT#58);[GDSpd:STempty];[GDSpd::0];(EVT#68);(EVT#124);(EVT#123);(p6620144);(EVT#125);(p6620144);(EVT#88);(p6620144);(EVT#89);
Tue Oct 7 20:06:16 EDT 2014 Initialize:51f4e849-4e7b-11e4-a809-123478563412 SrcPath:sp-san304-ac1:OIT_ExchangeBackupArchive01 DstPath1_C19_SRM01:OIT_ExchangeBackupArchive01 Prim=SM:cid=101,mid=1301, sm_stm_update_relation_status:1709, Msg=Failed to update relationship information. Reason: Unable to get checkpoint information.
Solved! SEE THE SOLUTION
2014-10-07 08:59 PM
Could you please let us know more details so that we can help better.
1. How is the snapmirror being created?initialized and updated
2. Are you using some tool like 7mode Transition Tool (7MTT?) or CLI for this
3. What is the volume size,type at 7 mode source , version of both 7 mode filer,c-mode filer used (i am looking for configuration details on 7 mode filers)
4. Error message posted says => Reason: Unable to get checkpoint information.
DstPath1_C19_SRM01IT_ExchangeBackupArchive01 Prim=SM:cid=101,mid=1301, sm_stm_update_relation_status:1709, Msg=Failed to update relationship information. Reason: Unable to get checkpoint information.
is the system really busy? (in terms of CPU etc)
5.output of command = on cmode =
snapmirror show -destination-path <VSERVER>:DstPath1_C19_SRM01IT_ExchangeBackupArchive01
2014-10-08 03:26 AM
I've created it several ways. CLI and 7MTT. Each one ends up doing the same thing. The size of the volume is 30TB with about 16TB used. The cluster mode system is new and has plenty of room. & mode is running 8.1.2P4 and cluster mode is running 8.2.1P2.
Here are the commands I used in CLI:
peer transition create -local-vserver D1_C19_SRM01 -src-filer-name sp-san304-ac1 -local-lifs ic01_ac2
volume create -vserver D1_C19_SRM01 -volume OIT_ExchangeBackupArchive01 -aggregate d1_310_ac2_aggr_fcache01 -size 30TB -type DP -space-guarantee none -security-style ntfs
snapmirror create -source-path sp-san304-ac1:OIT_ExchangeBackupArchive01 -destination-path D1_C19_SRM01:OIT_ExchangeBackupArchive01 -type TDP
snapmirror initialize -destination-path D1_C19_SRM01:OIT_ExchangeBackupArchive01
Here are the 7mode vol settings:
Here is the snapmirror show
System not busy at all
2014-10-08 03:31 AM
hmmm... wonder if the SIS setting may be affecting this. I saw in some documentation something about disabling sis on the volume. It is sitting idle right now.
/vol/OIT_ExchangeBackupArchive01 Enabled Idle Idle for 06:29:26
I will turn it off and see if that could be the issue.
2014-10-08 05:37 AM
Okay. I got it to work from the other copy (original primary) that I had at D2-SAN304-AC1. It was real easy. I did not even have to mess with host files or snapmirror.conf (multi settings) on D2-SAN304-AC1. All I had to do was set snapmirror access to “all” and create a route on the source so it would use the mirror vlan. Then I had to create the peer relationship and host entry on the destination. The only difference is d2-san304-ac1 uses 10GB and sp-san304-ac1 uses 1GB. I will have to dig further to see if there are any more differences. I believe there were two things that kept me from getting the mirror to work from sp-san304-ac1. Network (1Gb to 10GB, packet sizes, throttle) and possibly dedupe (SIS).
OIT_ExchangeBackupArchive01 was being mirrored from D2 to SP.
I broke that mirror and deleted the relationship so that I could stand the secondary (SP side) up as a “primary”. I then tried to mirror that volume to D1-SAN310-AC2 (d1-cluster01) but could not get it to work.
I finally gave up and decided to use the original primary at D2 (active CIFs share). It worked on that side using all the same commands I was using before. It literally took 2 minutes to get the mirror up and running so that tells me it had to be a network issue or possibly dedupe because I made the destination volume on the CDOT side 40TB not 30TB.
The reason I made it 40TB is because I checked out the dedupe savings on the original and saw that the volume would actually be using over 28TB plus the 20% snap reserve (34.6 TB total) if not for dedupe. The original destination volume I was trying to use was 30TB which matches how the volume looks today. Unfortunately I did not try that on the SP transfer before I decided to use the D2 filer. Once I am done with this current project I will come back and try the SP volume again. If making the volume 40TB on the destination side gets the mirror to work from SP then we know that was the issue and not the network.
All that being said, the mirror from d2 to d1 is cooking. This is how we are looking so far. Don’t worry about that error you see. I forgot to adjust the snapmirror access on my first attempt. 401 GB in less than 90 minutes. Not bad at all. I will update this thread when i do some more testing.