*Unidirectional* replication is probably a better phrase to describe what EMC SRDF and all other typical block mode storage arrays do for replication.
Typically this is used for manual or semi-automated DR systems and works very well for this purpose. This approach splits the HA and DR domains. It can also be used with a HA stretched cluster configuration for failing over services from one site to the other. You need to integrate into the service scripts unmounting of the filesystems for the service on one site, changing the direction of the replication and mounting the filesystem on the other site. This is quite complex and fiddly to say the least. I have yet to see an implementation where the users will be really happy with the robustness of the integrated solution. To implement a HA cluster that uses a cluster filesystem such as GFS2 across geographical area you need a different type of storage - a geographically distributed storage to have a chance of the cluster surviving the inter-site link failure or site failure. Standard unidirectional replication won't do for this. I know of only one such storage - Left Hand Networks iSCSI arrays (now owned by HP - the P4300, P4500 and P4800 storage arrays). Again, implementation of such cluster is very complex. IMHO it is easier to have local HA clusters on both sites and a good DR process based on replication. You could also try to implement the stretched cluster purely in software using separate LUNs on storage arrays in two sites and mirroring them. Personally, I believe that this will not yield a robust solution with the current versions of software. Regards, Chris Jankowski -----Original Message----- From: linux-cluster-boun...@redhat.com [mailto:linux-cluster-boun...@redhat.com] On Behalf Of Bryn M. Reeves Sent: Wednesday, 14 December 2011 01:43 To: linux clustering Subject: Re: [Linux-cluster] GFS2 support EMC storage SRDF?? On 12/12/2011 03:29 AM, yu song wrote: > My question is that GFS2 supports SRDF ?? looking at KB in redhat site, it > only says that GFS2 does not support using asynchronous or active/passive > array based replication. but it seems like does not apply for SRDF. SRDF offers both synchronous and asynchronous replication but is active/passive. I.e. the administrator can configure whether the primary (R1) site waits for write acknowledgement from the remote (R2) site or not but at any one time it is only possible to write to either the R1 or the R2 device. Synchronous replication guarantees write order fidelity for the R2 copy and ensures the remote copy is crash consistent at all times. Asynchronous replication allows SRDF to support longer distances (or lower bandwidth / higher latency inter site links) by packaging multiple writes into delta sets to be sent to the remote site. More complex modes and combinations exist that allow consistency to be maintained among a group of devices, for example a database's data store and redo logs, or that relax some of the synchronous replication guarantees to improve efficiency (semi-synchronous operation). Active/passive in the context of storage replication usually refers to the states of the devices on the two sites. In active/active replication both sides are fully active at all times and writes may be issued on either side of the replication (a bit like multi-master application layer replication). An active/passive design only allows one side to be active for writes at a time. Most array based implementations are active/passive and offer asynchronous, synchronous or semi-synchronous operation. Regards, Bryn. -- Linux-cluster mailing list Linux-cluster@redhat.com https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@redhat.com https://www.redhat.com/mailman/listinfo/linux-cluster
