Assume I have a Windows SFHA cluster at Site A, with IO fencing enabled (EMC VMAX storage), with storage replication to remote site.
Hosts at Site A encounter issue, and there is a DR failover to remote site (app running at DR site now),
If there are fencing keys left behind on the data disks at Site A (server panic etc, keys remained), possible that could prevent storage replication to occur (From remote site back to Site A)?
If there are fencing keys left behind on the data disks on one of the nodes at Site A, then that node should still be able to join cluster at site A as long as it's heartbeats are working and there are other servers particapting in fencing. If a cluster cannot be formed (example all servers paniced), then no node will be able to import the diskgroups at Site A and if diskgroups can't be imported at site A, then site B cannot replicate to site A, but site B can still function without site A.
Note also it depends on how you failed over to site B - if all nodes were down at site A and you did a takeover, then site B will track changes in the DCM, NOT the SRL and so then even when diskgroups are imported at siteA, then replication will not take place until "vradmin fbsync" is run.
I think its SRDF Mike, not VVR. I can't see how the existence of keys on the disk would prevent replication but maybe the EMC forum would be better at answering that.
Thanks Mike and Riaan.
Am asking in general for array based replication, applies not only to SRDF but the rest of the array-based replication technologies (PPRC, ShadowCopy etc).
Am wondeing if the existence of fencing keys (not cleared when cluster nodes at Site A rebooted, and nodes have not rejoined cluster and VCS admin have not cleared the keys manually), would prevent array based replication from starting (Site B -> Site A).
SFW HA does not support fencing so the discussion around it is a moot point. Likewise, storage replication does not care whether are any bits set on disks, it moves bits in order so even with fencing keys an SF on Unix it would not prevent storage replication from happening.
SFWHA on Windows doesn't use IO fencing in the same way that SFHA does on UNIX / Linux. However, SFWHA does use SCSI-3 reservations on the data disks to help protect against data corruption.
These SCSI-3 reservations are host-based and so would only impact any operations carried out at the HBA level on the host (trying to imprt a diskgroup for example). SCSI-3 reservations in SFWHA have no impact to hardware replication technologies.