VNX: File Replication – Completing transfer failed:DpRequest_vs_BranchExist. Session inactive (User Correctable)

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



VNX2 Series,VNX8000,VNX5200,VNX5400,VNX5600,VNX5800

A replication session may encounter the following rare error which halts the replication transfer:

“completing transfer failed:DpRequest_vs_BranchExist. Session inactive.”

“internal policy has become inactive:DpRequest_vs_BranchExist.”

/nas/log/sys_log will display the following:

Aug 9 06:53:38 2017:DART:REP:ERROR:18:Slot 4:Source=CKMXXXXXXXXXXX_2017_CKMXXXXXXXXXXX(alias=repl_1), completing transfer failed:DpRequest_vs_BranchExist. Session inactive.Aug 9 06:53:38 2017:DART:DPSVC:ERROR:13:Slot 4:The replication session:CKMXXXXXXXXXXX_2017_CKMXXXXXXXXXXX internal policy has become inactive:DpRequest_vs_BranchExist.Aug 9 06:57:48 2017:DART:REP:ERROR:18:Slot 4:Source=CKMXXXXXXXXXXX_2017_CKMXXXXXXXXXXX(alias=repl_1), completing transfer failed:DpRequest_vs_BranchExist. Session inactive.Aug 9 06:57:48 2017:DART:DPSVC:ERROR:13:Slot 4:The replication session:CKMXXXXXXXXXXX_2017_CKMXXXXXXXXXXX internal policy has become inactive:DpRequest_vs_BranchExist.Aug 9 07:01:38 2017:DART:REP:ERROR:18:Slot 4:Source=CKMXXXXXXXXXXX_2017_CKMXXXXXXXXXXX(alias=repl_1), completing transfer failed:DpRequest_vs_BranchExist. Session inactive.Aug 9 07:01:38 2017:DART:DPSVC:ERROR:13:Slot 4:The replication session:CKMXXXXXXXXXXX_2017_CKMXXXXXXXXXXX internal policy has become inactive:DpRequest_vs_BranchExist. 

This error causes the replication session to come to an abrupt halt and can only be resumed when a replication stop and start is completed from the Source side array.

This error is logged when there are checkpoints with duplicate ID’s saved in DART memory at the time the message was logged. This state is temporary while checkpoints are being deleted or refreshed and new checkpoints are being created.

Perform a stop of the affected replication session from the Source side array. When the session is stopped, perform a replication start to resume the replication session.

Example:

(1) Stop the replication session from the Source side:

nas_replicate -stop repl_1

(2) Start the replication session from the Source side:

nas_replicate -start repl_1

(3) Verify that the replication session has resumed:

nas_replicate -i repl_1


In the case of further re-occurrences , please contact DELL EMC Customer Service and quote this service request for further assistance.

Related:

  • No Related Posts

ECS: One node will not power on in an ECS Gen1 or Gen2 system.

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



ECS Appliance,ECS Appliance Hardware,Elastic Cloud Storage

This KB article addresses when only one node will not power-on in an ECS Gen1 or Gen2 system.

One node will not power on in an ECS Gen1 or Gen2 system.

Bad blade server or bad chassis.

N/A

For ECS Gen1 and Gen2 systems, there are redundant Power Supply Units (PSUs) which supply power to a chassis and up to 4 blade servers in the chassis.

Based on this, if 1 node out of 4 will not power on, the issue can’t be the PSUs because the other nodes in the same chassis are powered on.

The issue has to be the blade server or the chassis itself.

Using an example where node 4 will not power on, one can swap the blade server from the node 3 position to the node 4 position and vice versa.

If the issue stays with the slot where node 4 resides, the issue is the chassis. If the issue follows the blade server, then the blade server is at issue.

Note: This sort of troubleshooting can only be done at install time before the OS and ECS software is loaded on the system.

Related:

  • No Related Posts

Avamar: Avamar Callhome is not working after migration to Office365

To setup an SMTP Relay on Office365

In Office365, click Admin, then click Exchange to arrive on the Exchange Admin Center

Click mail flow, and then connectors

User-added image


Use the “+” to start the wizard to create a new connector:

– From = your organisation’s email server

– To = Office 365

– Enter a name for SMTP Relay

– By verifying that the IP address of the sending server matches one of these IP addresses that belong to your organization sender’s IP address = all Avamar utility nodes that are configured on customer site (IP should match public IP address of location sending email).

And click save to create the connector.

Then you can test it by doing the telnet command:

telnet <smtp office365> 25

EHLO

MAIL FROM:avamar_user_configurated@xxxx.com

It return now:

250 2.1.0 Sender OK

Avamar callhome and dialhome is now working.

Related:

  • No Related Posts

Connectrix B-Series: Device logging in as a loopback

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



Connectrix,Connectrix B-Series Hardware

Why does a HBA or storage device automatically configure to a loopback port?

This could be caused by controller configuration on the HBA or storage.

Check if the end device is configured for Fiber Channel Arbitrated loop (FC-AL). Also check the integrity of the SFP and cable and reset the port as follows

– portcfgpersistentdisable

– portcfgdefault

– portcfgpersistentenable.

If the status of the port is still loopback after doing the above, move the cable to a free port. If the issue follows then it could well be an issue with the connected device and more troubleshooting would need to be done at that end.

Related:

  • No Related Posts

ScaleIO: ScaleiO Ready Node (AMS) reports “The SVM used disk space exceeds the configured threshold”

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



ScaleIO Ready Node Series

scaleio-trace-log reports:

NODE_SVM_OS_DISK_USED_SPACE_HIGH

Collected the following outputs from each node in order to determine where the space is being consumed.

# du -d 1 -h /

# find ./ -size +5M -exec ls -lh {} ;

Upon reviewing the above outputs, it could be seen that (/root/MegaSAS.log) was consuming the space.

MegaSAS.log filling up on each node.

The contents of these logs appear to be the controller configurations and version information, which are being repeatedly printed into the log file.

This is a known issue which is stated to be fixed in version 3.0.

The MegaSAS.log is only required if you have an issue with the RAID Controller.

Workaround:

Save off the logs, then run the following command on each server, to wipe out the contents of the MegaSAS.log.

# cp /dev/null /root/MegaSAS.log

This should stop the error being reported.

Related:

  • No Related Posts

ViPR SRM: After the upgrade of SRM to 4.1.1 SNMP Device Discovery and compliance frontend not working

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



ViPR Family,ViPR SRM 4.1

SNMP Device Discovery and Compliance Frontend URL’s doesn’t work, they just return blank page after the upgrade to 4.1.1

Errors seen on Catalina logs;

Sep 21, 2017 10:35:37 AM org.apache.catalina.core.StandardContext startInternal

SEVERE: One or more listeners failed to start. Full details will be found in the appropriate container log file

Sep 21, 2017 10:35:37 AM org.apache.catalina.core.StandardContext startInternal

SEVERE: Context [/device-discovery] startup failed due to previous errors

Sep 21, 2017 10:36:19 AM org.apache.catalina.core.StandardContext startInternal

SEVERE: One or more listeners failed to start. Full details will be found in the appropriate container log file

Sep 21, 2017 10:36:19 AM org.apache.catalina.core.StandardContext startInternal

SEVERE: Context [/compliance-frontend] startup failed due to previous errors


Errors seen on Localhost logs;

21-Sep-2017 10:35:37.739 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.listenerStart Exception sending context initialized event to listener instance of class com.watch4net.apg.gui.servlet.ApplicationListener

java.lang.IllegalStateException: Can’t create master accessor.

Caused by: javax.naming.NameNotFoundException: Name [jdbc/master] is not bound in this Context. Unable to find [jdbc].

21-Sep-2017 10:36:19.211 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.listenerStart Exception sending context initialized event to listener instance of class com.watch4net.apg.gui.servlet.ApplicationContextListener

java.lang.IllegalStateException: An error occurred notifying listeners !

Caused by: java.lang.IllegalStateException: An error occurred creating the datasource.

Caused by: javax.naming.NameNotFoundException: Name [jdbc/master] is not bound in this Context. Unable to find [jdbc].

Login to Frontend server via putty.

Navigate to the location:

/opt/APG/Web-Servers/Tomcat/Default/conf/Catalina/localhost

Edit the device-discovery.xml and compliance-frontend.xml files as below:


The device-discovery.xml file had the incorrect entry to the database entries;

<ResourceLink name=”jdbc/master” global=”jdbc/master” type=”javax.sql.DataSource”/>

Changed it to

<ResourceLink name=”dba/master” global=”dba/master” type=”com.watch4net.apg.gui.datasource.DatasourceConfiguration”/>

Compliance-frontend.xml file had incorrect master db configuration

<ResourceLink name=”jdbc/master” global=”jdbc/master” type=”javax.sql.DataSource”/>

Changed it to

<ResourceLink name=”dba/master” global=”dba/master” type=”com.watch4net.apg.gui.datasource.DatasourceConfiguration”/>

Restarted the tomcat and resolved the issue


Also, verify if the resource link entries are same as above in context.xml for both the modules under location:

context.xml for device-discovery:

/opt/APG/Web-Servers/Tomcat/Default/webapps/device-discovery/META-INF

context.xml for compliance-frontend:

/opt/APG/Web-Servers/Tomcat/Default/webapps/compliance-frontend/META-INF

Related:

  • No Related Posts