XtremIO: Native replication snapshot sets not viewable

           

   Article Number:     538509                                   Article Version: 3     Article Type:    Break Fix 
   

 


Product:

 

XtremIO HW Gen2 800GB Encrypt Capbl

 

Issue:

 

 

Trying to view the snapshot sets created by native replication results in "no matches found" via both CLI and GUI:   
   
    xmcli (tech)> show-remote-protection-snapshot-sets protection-session-id=1   
    No matches found   
    xmcli (tech)> show-remote-protection-snapshot-sets protection-session-id=2   
    No matches found   
   
    However, by checking the protection sessions themselves, we can see that the snapshot sets are indeed being created:   
   
   
   
    xmcli (tech)> show-remote-protection-session protection-session-id=1   
     Name: <Remote protection session name>   
     Index: 1   
     Replication-State: active   
     Replication-State-Details:   
     Replication-Direction: source_to_target   
     Block-Access-Type: read_only   
     Source-XMS-Id:   
     Name: <XMS name>   
     Index: 0   
     Source-Cluster-ID:   
     Name: <Cluster name>   
     Index: 1   
     Source-CG-Id:   
     Name: <CG name>   
     Index: 2   
     Target-XMS-Id:   
     Name: <XMS name>   
     Index: 0   
     Target-Cluster-ID:   
     Name: <Cluster name>   
     Index: 1   
     Target-CG-Id:   
     Name: <CG name>   
     Index: 1   
     Num-Of-Vols: 3   
     RPO: 60   
     Max-BW(MB/s): 0.000   
     Protection-Window-Num-Copies: 27   
     Protection-Window-Duration-in-Days: 4.000   
     Current-Protection-Window-Copies: 10   
     Source-Retention-Policy-ID:   
     Name: <Retention policy name>   
     Index: 1   
     Target-Retention-Policy-ID:   
     Name: <Retention policy name>   
     Index: 1   
     Number-Of-Target-PITs: 10   
     Target-Pit-Num-Copies-Status: ok   
     Target-Pit-Window-Size-Status: protection_window_not_full   
     Number-Of-Source-PITs: 2   
     Next-Scheduled-Cycle: xxxxxxxx   
     Replication-Mode: async   
     Lag: 30   
     BW(KB/s): 0   
     Max-BW(MB/s): 0.000   
     Transfer-Efficiency-Ratio(Ratio): 1   
     Cycle-Start-Time(Timestamp): Tue Sep 17 15:37:43 2019   
     Last-Cycle-Start-Time(Timestamp): Tue Sep 17 15:37:43 2019   
     Last-Cycle-Completed-Snapshot-Set: xxxxxxxxx   
     Last-Cycle-Duration: 1   
     Last-Cycle-Link-BW(KB/s): 70086   
     Last-Cycle-Effective-Bandwidth(KB/s): 13981303   
     Last-Cycle-Transfer-Efficiency-Ratio: 199.48671427   
     Cycle-Number(Count): 910   
     Num-Missing-Short-Period-Snapshot-Sets: 14   
     Num-Missing-Middle-Period-Snapshot-Sets: 3   
     Num-Missing-Long-Period-Snapshot-Sets: 0   
     Target-Missing-Pits-Alert: enabled   
     Test-Copy-Mode: False   
     Snapset-Backup-Snapset-Index: []   
     Current-Command-Name:   
     Current-Command-Status: none   
     Replication-Session-Consistency-State: consistent   
     Obj-Severity: information   
     
                                                           

 

 

Cause:

 

 

This issue is caused by a code bug that causes the Tasker process on the XMS to die. This affects the auto_sync job run by the XMS, and ultimately affects the way it gathers the native replication snapshot information from the SYM.    
     
                                                           

 

 

Change:

 

 

.    
     
                                                           

 

 

Resolution:

 

 

Found that this is a code bug with the current software on the array, and as a workaround, the refresh can be performed via CLI.                                                           

 

 

Notes:

 

 

If rebooting the XMS does not work, perform the following POA:   
   
    Ensure customer is aware that performing XMS recovery will result in the loss of the performance data, as well as their tags. Once customer approval is given for XMS recovery, perform the following:   
   
    Perform xms-recovery on both XMS.   
    1. dry run xms-recovery on source xms; then xms-recovery on source xms if dry-run succeeds.   
    2. dry run xms-recovery on target xms; then xms-recovery on target xms if dry-run succeeds.