Equallogic Lost Path Redundancy

[lobo519]

We recently switched to an Equallogic 6100X array at our Co-Location. Use use Veeam to replicate a few servers to the equallogic through out the day. Since moving to this new array we are receiving errors from vCenter "Lost path redundancy to storage..." and it will report only of the equallogic volumes. Usually an RDM that is mounted to our Veeam Proxy server. We are using MEM 1.1.2. We often see well over 50ms latency when a snapshot is being removed from one of our replicas and this is usually when we received the error from vCenter.

Anyone experience a similar issue?

[Vitaliy S.]

Does this also happen when you create (wait long enough) and then remote the snapshot manually for the VM in question?

[haslund]

Which version of ESXi are you on?

[lobo519]

Sorry for the delay - I have been working with Dell.

We are running 5.0 Update 1. I'm less convinced it has to do with the snapshot removal and more leaning towards the actual data being transferred to the Array.

Dell asked that is disable DelayedACK which I had already done but I couldn't remember if I rebooted the hosts after making the change which they insisted had to be done for the change to take effect. After rebooting the hosts the amount of messages from vCenter greatly reduced and now for the last 3 nights since the change I have only received the errors between 11:00PM and 12:00AM. This is the exact time I have a back up job running from our main site to our co-location where this array sits. Specifically this in window our exchange servers are being backed up. These servers have by far the most changed data.

Our backup job is configured:

Reverse Incremental
Extreme Compression
WAN Target.
The Repo is a VM with a RDM to an Equallogic Volume.

[lobo519]

FYI - This was determined to be an issue in the Equallogic firmware 6.0.2 and to be fixed in 6.0.3.

[travis.vanholland]

I had this issue as well. We resolved this issue by implementing the vmkernel heartbeat.

[lobo519]

I had this issue as well. We resolved this issue by implementing the vmkernel heartbeat.

The Heartbeat kernel port did not resolve this particular issue.