![[RSS]](http://thefutureofstorage.com/wp-content/themes/dellscsi/images/rss_feed.gif)
Mirroring vs Replication in DR
Submitted by Lukas Kubin on April 23rd, 2008
As I wrote in my first insight, I’m a technician at a VAR company working with many clients on their SAN setups. We’ve been quite successful selling storage solutions with synchronous mirroring to our clients in recent months. The winning argument has always been the transparent failover in the case of an array failure. Hearing that they don’t have to touch anything to keep their apps running when the array breaks is always a pleasure for the administrators attending our meetings.
As synchronous mirroring is simple in logical design, it’s the best option for a highly-available SAN in my opinion. Still however, I am meeting many people say: “We’re not a bank. We can afford one or two hours break, so asynchronous replication within a single server room is good enough for us.” They usually expect asynchronous replication to be cheaper to purchase and simpler to install.
To me, as the guy involved in the recovery, the idea of doing a disaster recovery of asynchronously mirrored data appears close to a nightmare. Asynchronous always means the risk of losing some data in the case of an array failure. During the recovery process the administrators have to check if they can recover somehow from the primary storage to rescue as much data as they can. They can’t immediately redirect the storage traffic to a replica without ensuring there is no other way first. This phase is quite difficult to manage and depends heavily on the administrators’ skills. And that’s a big risk factor.
From this perspective I only see a place for non-synchronous mirroring in remote replications, where the connection between primary storage and its replica is not broad enough for synchronous transfers. In all other cases, the synchronous mirroring should be the only option.
How do I see the future of HA/DR? According to my ideas of simplicity and automation I would like to see SANs better integrated with applications stored on them. I haven’t said many nice words about asynchronous replication. Nevertheless I’m sure there will always be cases where async will be the only choice. For these cases, storage vendors should create some generic application-aware storage layer or tools to help admins pass the recovery process. Maybe even allow the recovery process to run unattended.
![[Ars Technica]](http://thefutureofstorage.com/wp-content/themes/dellscsi/images/icon_ars.gif){kind=icon}
April 24th, 2008 at 12:33 pm
To start some discussion on my own insight: What do you thing of the idea putting some application-level information into the storage protocol stack?
One such information might be a consistency bit. Today, when a SAN user needs to do a consistent snapshot of application LUN, it needs to perform quite complex dialog between the application and the SAN appliance to identify the moment when the LUN is in application consistent state. What is more, this dialog performs on LAN level, not the SAN.
What if this all was just a one-way information transferred through the SAN? Let’s say the storage layer on client computer will identify a low I/O moment, let the application finish writing opened transactions on the LUN (the same way it’s doing it now) and put a consistency bit in the storage protocol stream. Once such bit arrives to the storage controller, it decides based on some configured policy either to create a snapshot or pass the consistency bit to replica site to have a consistent LUN copy there.
Most of this idea is nothing new. Eg. FalconStor uses such consistency bit in their IP replication protocol. I thought however, there might be more uses or examples of putting similar information in the primary storage protocol.
April 24th, 2008 at 6:50 pm
“where the connection between primary storage and its replica is not broad enough for synchronous transfers”
This is the case most the time, the cost of the connection will be more then the SAN.
For synchronous you need a very low latency connection.. not going to get that on MPLS network and only in the same city center with a point to point.
So you going to need network connection just for your SAN and then other for your MPLS network.
May 13th, 2008 at 3:17 am
I am in the same position as Rif.
We host multiple solutions across multi data centres and for a full DR solution there is a requirement that the failover storage solution is hosted in a geographically different location to the primary solution.
To use sychronous replication across two data centres that are 100 miles apart would require a dedicated connection (I believe) with very low latency and so such would be very expensive if available at all. We have a primary data centre hosted in Scotland with it’s secondary (DR) site located in London. Imagine trying to achieve sychronous replication over that connection. I am investigating how else we can acieve a reliable backup data source so any suggestions would be welcome. I am currently looking at RecoverPoint from EMC.
January 29th, 2009 at 11:02 am
[...] what the next big things in storage areas could be. At first, I thought of protocols, so I wrote an insight about mirroring and some feature-related things. What I forgot completely was the core of current SANs — [...]