Can someone please explain to me if/or how synchronous volume replication is buffered in reposnse to (a) a replication link failure or congestion, and (b) destination system performance? I have read some posts about this, but I am still not 100% clear.
(buffering could take place in the source or destination)
On one hand, it would seem that a synchronous replication "step" has been actioned when the destination has either received the packet or comitted it to disk (depending on the daemon's configuration). If that cannot be achieved (failed link or slow destination server), then the source with either (a) accept no more IO write traffic, or (b) start buffering changes. When the link has been restored, then any changes buffered would be transmitted.
I am sure other SANs we have read about using fully synchronous replication say all writes to the source are stopped until the destination is online again. But this Open-E document (http://www.kb.open-e.com/entry/15/) suggests that writes to the source are not stopped, and all changes are correct handled and not lost (via ECC data). This means it is almost acting asynchronously then?
Can we please consider 2 senarios involving a fast DSS source system, plus...
So my question is, how does DSS's synchronous volume replication handle these 2 cases.
- a WAN link that can handle the replication traffic on average ok, but not the short bursts the source system experiences (like many real-world system do)
- a fast LAN link but to a slower destination server (eg. with a slower disk sub-system, or heavily loaded), and as above senario, can keep up on average, but not the peak writes.
After understanding this, my next question will be how these could (or not!) work with iSCSI auto-failover. Cheers.