[DSS6] Primary Disk Activity HALTS when Secondary crashes

Hello,

I have a FAILOVER/iSCSI configuration running with 2 XenServers for a customer.
I noticed a few times that when the Secondary Unit reboots, crashes or when I uncable it... There is NO more diskactivity on the Primary unit. I just don't see the lights of the disks on the Primary unit blinking anymore... As soon as I reboot the Secondary or plug it's cables again... The disk Activity on the Primary continues.
I think it buffers all writes because it couldn't get an acknowledge from the secondary unit,.. and so it doesn't give a acknowledge back to the Xenservers/VMs. However.. if that's really the case, it's pretty dangerous because then I would be dependent on the running/failing of the Secondary unit.

Is this normal behaviour?

Kind regards,

Roel Broersma
OECE

You should have disk activity, if the secondary is down lets say then data is being written to the primary. Not that I dont believe what you are seeing but if your data is beyond the cache point then you wouldn't be able to write. When the secondary is back on line then the volume replication is syncing the delta difference.

Thanks for the info Todd,

I'm trying to remember the situation:
- Customer was using version 6.0up95.xxxx.6156 (2012-04-05)
- The Primary was master and the Secondary was slave.
- The secondary was had a RAID-5 volume and 2 disks were pulled out, so the volume 'Failed'. The Areca card probably gave 'failed' back to the Operating System and you couldn't see any volumes in Open-E.

What I am saying is: The secondary was still running but it's raid-set failed so the volumes were gone. Could this trigger a situation in which the Primary would stay waiting for an acknowledge? (The heartbeat and all other processes were still running and successfull I guess). I am just thinking about a 'secondary is half alive' scenario..

-Roel

We would have to look at the logs but most likely the Primary noticed that the secondary was dead and placed itself in a degraded state. Also I recommend to use build 6335 6135 was pulled off, not due to the Auto Failover.