Hi, On Thu, 2011-12-15 at 13:06 +1100, yu song wrote: > Gents, > > beauty!! it is great to see your ideas. > > I found a doc from redhat kb, which has the following statement > > " > > Multi-Site Disaster Recovery Clusters > A multi-site cluster established for disaster recovery comprises two > completely different clusters. These clusters typically have the same > configuration, with one active and the other passive (and sometimes > powered off). If the primary site fails, the secondary site is > manually activated and takes over all services. > > > > Multi-site clusters are supported since implementation involves two > separate clusters with the same configuration/architecture at two > physical locations. Shared storage must be replicated from the primary > to the back-up site using array-based replication. During a site > failover, the cluster administrator must first toggle the > directionality of the storage replication so that the back-up site > becomes the primary and then start up the back-up cluster. These steps > cannot be automated since using heuristics like site-to-site link > failure might result in primary/back-up toggling when there are > intermittent network failures. > > " > > It does give me an answer what I am after. > > have a great Christmas!! > Also, just to clarify, these multi-site clusters are not supported when combined with GFS2, Steve. > > On Thu, Dec 15, 2011 at 8:56 AM, <michael.trachtman@xxxxxxx> wrote: > Actually, another product that implements "geographically > distributed storage" is VPlex (from EMC). VPlex is a product > for geographically distributed storage. It works quite > nicely. And, yes you can put a HA file system on top of > that. I haven't tried it with GSF2 yet; but I have tried it > with OCFS2, and there is no reason why GFS2 would be any > different. I.e. there is every reason why it should work. > > ..m > > > >>>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. > > -----Original Message----- > From: linux-cluster-bounces@xxxxxxxxxx > [mailto:linux-cluster-bounces@xxxxxxxxxx] On Behalf Of > Jankowski, Chris > Sent: Wednesday, December 14, 2011 3:03 AM > To: linux clustering > Subject: Re: GFS2 support EMC storage SRDF?? > > *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-bounces@xxxxxxxxxx > [mailto:linux-cluster-bounces@xxxxxxxxxx] On Behalf Of Bryn M. > Reeves > Sent: Wednesday, 14 December 2011 01:43 > To: linux clustering > Subject: Re: 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster > > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster > > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
