HP had a product called SVSP - they're phasing it out now (they sold the IP or lost the lease), but it beat the *pants* off of VPlex (which requires 24 front-side ports on your MDS - laughable to the 4 needed for HP SVSP). We've got 96Tb SVSP configuration and use it for our stretch VMWare cluster and it's doing a great job. I'm waiting for a firmware upgrade so I can use it with RHCS. There's an alua issue with the current version of the firmware and it causes issues with multipathd working correctly. Erik Redding Systems Programmer, RHCE Core Systems Texas State University-San Marcos On Dec 14, 2011, at 3:56 PM, <michael.trachtman@xxxxxxx> <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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
-- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
