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!!
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??
SRDF offers both synchronous and asynchronous replication but is
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.
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
