ViPR Controller : Ingestion of Recoverpoint protected XtremIO volumes fails to create a block Consistency group

           

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

 


Product:

 

ViPR Controller,ViPR Controller Controller 3.6 SP2

 

Issue:

 

 

The user is unable to successfully ingest all Recoverpoint (RP) Consistency Group (CG) volumes into ViPR Controller to allow creation of the Block Consistency Group in ViPR-C.                                                           

 

 

Cause:

 

 

The replication mechanism used by RecoverPoint for XtremIO volumes is based on exploiting the capabilities of the XtremIO array which are significantly different from all other RecoverPoint replication mechanisms, both if the XtremIO array contains production volumes and if it contains copy volumes.   
   
    When XtremIO is the production source, RecoverPoint takes advantage of the native XtremIO capability to create snapshots and to export the difference between two consecutive snapshots. RecoverPoint manages and orchestrates the creation, deletion, and mapping of snapshots for replication.   
   
    Issue #1.  In general all volumes in a Recoverpoint CG need to be ingested to create the CG in VIPR-C.   
    However, RP related Xtremio snapshots (RP-SMP) associated with the Recoverpoint CG are not supported in ViPR-C and need to be excluded from the ingestion process.   
   
    Issue #2. Ingestion of the last un-ingested volume of the RP CG results in the creation of the Consistency Group in the ViPR Controller database.   
    If the last un-ingested volume is exported then VIPR-C fails to initiate this CG creation.
                                                           

 

 

Change:

 

 

No changes made. This is a new VIPR Controller implementation.                                                           

 

 

Resolution:

 

 

Workaround :   
   
    A solution exists for this issue, but intervention from Dell-EMC technical support personnel is required.   
    Support personnel must access your storage system to fix this issue.   
   
    Contact the Dell-EMC Customer Support Center or your service representative for technical assistance and quote this article ID.   
    Include the ViPR Controller Order History text as well as logs covering the time frame when you contact Dell-EMC for technical assistance.   
   
   
    Resolution:   
   
    ViPR Engineering is currently addressing this problem, but has not provided a fix in a released patch.    
    This solution will be updated with the patch details when it has been released.   
   
   
     
                                                           

 

 

Notes:

 

 

Issue #1     
     
      Ingestion of an RP-SMP
snapshot (Snapshot Mount Point) fails with the following error :   
    vipr1 vipr1 apisvc 2019-02-07 10:37:59,821 [AsyncTaskExecutorService_900] INFO VolumeIngestionUtil.java (line 672) Determining if the unmanaged volume TESTVOLUME1._aad893fc0dc5abc_0_7e2573d3_44b06523e2d2ad01_0_aeec25b85bad_RPSMP belongs to an unmanaged consistency group      
      vipr1 vipr1 apisvc 2019-02-07 10:37:59,821 [AsyncTaskExecutorService_900] INFO VolumeIngestionUtil.java (line 677) The unmanaged volume TESTVOLUME1._aad893fc0dc5abc_0_7e2573d3_44b06523e2d2ad01_0_aeec25b85bad_RPSMP belongs to an unmanaged consistency group      
      vipr1 vipr1 apisvc 2019-02-07 10:37:59,822 [AsyncTaskExecutorService_900] INFO IngestStrategyFactory.java (line 345) strategy key is RP_SNAPSHOT      
      vipr1 vipr1 apisvc 2019-02-07 10:37:59,823 [AsyncTaskExecutorService_900] ERROR IngestVolumesUnexportedSchedulingThread.java (line 99) Exception occurred java.lang.NullPointerException at com.emc.storageos.api.service.impl.resource.blockingestorchestration.IngestStrategy.ingestBlockObjects(IngestStrategy.java:31) at com.emc.storageos.api.service.impl.resource.blockingestorchestration.IngestVolumesUnexportedSchedulingThread.run(IngestVolumesUnexportedSchedulingThread.java:82) 
   
   
   
    If the RPSMP snapshot volumes have been removed from UnManagedVolume CF & but the "HAS_REPLICA"  & "SNAPSHOTS=" keys have not been removed from the volumes being ingested you will see the following in the logs.   
   
    vipr1 vipr1 apisvc 2019-03-29 10:23:24,118 [AsyncTaskExecutorService_853]  INFO  BlockIngestOrchestrator.java (line 1150) Expected replicas : 0 -->Found replica URIs : 0     
      vipr1 vipr1 apisvc 2019-03-29 10:23:24,118 [AsyncTaskExecutorService_853]  INFO  BlockIngestOrchestrator.java (line 1152) Expected replicas  : Found  :      
      vipr1 vipr1 apisvc 2019-03-29 10:23:24,118 [AsyncTaskExecutorService_853]  INFO  BlockIngestOrchestrator.java (line 868) Ended algorithm to check all replicas ingested for parent     
      vipr1 vipr1 apisvc 2019-03-29 10:23:24,118 [AsyncTaskExecutorService_853]  INFO  BlockRecoverPointIngestOrchestrator.java (line 251) Not all the parent/replicas of unManagedVolume XTREMIO+CKM00000000000+UNMANAGEDVOLUME+45fe002023534c7e9f9ff1dca61fdd67 have been ingested , hence marking as internal