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
I’ve done a bunch, they’re pretty popular in certain verticals in the UK, too.. Mostly they have been in hospitals or universities…
From: Strauss Wolfram Wolfram.Strauss@emmi.commailto:Wolfram.Strauss@emmi.com> Date: Tuesday, 25 November 2014 10:50 To: "toasters@teaparty.netmailto:toasters@teaparty.net" toasters@teaparty.netmailto: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
Ed Morgan Technical Consultant
T: M:07875 628794 E: ed.morgan@ansgroup.co.uk
Disclaimer The information contained in this communication from ed.morgan@ansgroup.co.uk sent at 2014-11-2511:44:24 is confidential and may be legally privileged. It is intended solely for use by toasters@teaparty.net and others authorised to receive it. If you are not toasters@teaparty.net you are hereby notified that any disclosure, copying,distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. ANS Group Plc Terms & Conditions apply, all prices are subject to VAT, expenses excluded,E&O,E.
ANS Group Plc, Registered Office is Synergy House, Manchester Science Park, Manchester, M15 6SY. Reg No. 3176761. (Registered in England & Wales)
I've seen them for high availability configurations, however the distance is too short for some disaster recovery needs. In my shop, we don't use synchronous replication. The link distance we require (600KM) is too far for it, and reducing the distance enough that we could do synchronous mirroring would subject us to the risk of both datacenters failing to the same regional disaster.
On Tue, Nov 25, 2014 at 5:50 AM, Strauss Wolfram Wolfram.Strauss@emmi.com wrote:
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
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
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.netmailto: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.netmailto: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
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 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
-
Basil -
Borzenkov, Andrei -
Ed Morgan -
Steiner, Jeffrey -
Strauss Wolfram