In the event that you want to replicate over a long enough distance that synchronous mirroring is impossible, but require a recovery point of seconds rather than minutes, you can use semi-sync. We use something like it on our large block-only SAN that does all our databases. On Netapp, instead of mirroring NVRAM, it just mirrors consistency points, so you have recoverable data at the remote site with a recovery point measured in seconds.

On Wed, Nov 26, 2014 at 4:36 AM, Steiner, Jeffrey <Jeffrey.Steiner@netapp.com> wrote:

NetApp employee here.

 

Europe in general is covered with MetroCluster. I know of roughly 80PB of usable MetroCluster. Personally, I think it’s because of the easy availability of dark fibre and smaller distances. In the USA customers tend to replicate 500 miles and even in smaller distances you the network costs are higher. An RPO around 15 minutes to an hour is generally considered acceptable, and that’s easy to deliver with async snapmirror.

 

The advice I give sales teams is usually this – it’s a matter of scale. For example, if someone has 2 or 3 critical databases then it’s probably easier to leverage application-level mirroring like Oracle DataGuard and then do the work of ensuring your application server code is identical at both sites. Sure, you can use storage-level mirroring, but overall it’s probably going to be less work to use application-level mirroring and possibly some scripting to deal with DR. If you have 20,000 databases, as is the case with one particular customer, it’s just easier to use storage level mirroring. I know a customer in the UK that has replication up at the application itself. Changes are committed by the app to at least 2 of the 3 sites before proceeding. Few applications do that, though.

 

The question is where to draw the line, and that’s really a business decision based on skill sets, RPO, and RTO requirements. In an Oracle database context, once you go beyond 10 or so databases it’s probably easier to use storage mirroring that database mirroring.

 

I’m also seeing a small shift away from synchronous mirroring for two reasons. First is data volume. Everyone is keeping more and more data and the infrastructure and networking requirements are getting expensive with synchronous mirroring. Some customers are backing off and allowing for 5-15 minutes of data loss in some cases. The second reason is the use of Flash. Nobody really notices the extra millisecond of write latency when you use synchronous mirroring and a lot of spinning media, but as more and more Flash is used then the latency hit can become more noticeable. I don’t know that it’s necessarily causing a business problem, but it’s noticeable and everyone always wants better performance than they have now.

 

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Borzenkov, Andrei
Sent: Wednesday, November 26, 2014 9:03 AM
To: Strauss Wolfram; toasters@teaparty.net
Subject: RE: How widely is the MetroCluster construct used outside the DACH region?

 

There are quite a few installations in Russia.

 

 

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Strauss Wolfram
Sent: Tuesday, November 25, 2014 1:51 PM
To: toasters@teaparty.net
Subject: How widely is the MetroCluster construct used outside the DACH region?

 

NetApp MetroCluster, and the SyncMirror component in particular, is a construct mainly demanded by companies in the DACH region, as I was told by NetApp. We are a Swiss company and our management often demands synchronous data replication between two datacenters on the storage level, hence we have quite a couple of MetroClusters running. How many of you outside the DACH region are using MetroClusters?

 

And for those who don’t, how do you deal with synchronous replication of data? Do you solve the problem on higher layers (OS, application, etc.) or are your requirements simply less strict, so that e.g. snapmirror asnyc is sufficient?

 

 

Wolfram


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters