Unsolved
This post is more than 5 years old
3 Posts
0
890
September 22nd, 2015 12:00
VNXe 3200 Block-Level Replication Stalling/Freezing
Recently my company deployed dual VNXe 3200 series SANs for one of our clients. This client has a primary and a disaster recovery SAN. We currently utilize the built-in replication engine within the VNXe operating system. This is block-level replication technology that is used to replicate individual datastores across the client network to a remote site.
Currently, there are 4 datastores being replicated over to the remote site every hour. Just recently we discovered that 1 of the 4 datastores had stopped or became “hung/frozen.” All other datastores are replicating without issue. The problematic datastore has only 1 virtual machine stored in this location. EMC’s tier 1 support only response is to purge the destination datastore and reseed all of the data for the problematic datastore. Then reboot storage processors at source and destination sites. EMC blames this kind of problem on network related issues/outages. However, we have not be able to determine an outage lasting longer than 30 seconds.
My issue, is that if EMC is stating this is a network problem, then why haven't the other datastores had the same issue yet?
Anyone else run into this type of issue? This is what the replication session looks like currently. No change in the statistics since 9/11/2015.
0 events found


DCsafe
8 Posts
0
September 24th, 2015 14:00
How about
- trying to recreate replication pair [replacing target lun] and run replication manually and separately than other three
- If the 4th datastore lun has single VM as you mentioned and presumably less data and less number of IOs then move it over to other SP with new replication pair configuration and see what happens
Just a thought for little testing
claydavis2
3 Posts
0
October 8th, 2015 07:00
We have 2 LUN's on SPA and 2 LUN's on SPB on the Source and Target VNXe3200.
Here is a functioning replication session. Source = LUN00 SPA Destination = LUN00 SPBA
Here is the problematic replication session. Source = LUN03 SPB Destination = LUN03 SPBBA