[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] GFS2 support EMC storage SRDF??



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 emc com> 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 redhat com
>         [mailto:linux-cluster-bounces redhat com] On Behalf Of
>         Jankowski, Chris
>         Sent: Wednesday, December 14, 2011 3:03 AM
>         To: linux clustering
>         Subject: Re: [Linux-cluster] 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 redhat com
>         [mailto:linux-cluster-bounces 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
>         
>         
>         --
>         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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]