The Business Case for Storage Networks [Electronic resources] نسخه متنی

Replication

Replication of data has long been a key factor in most companies' plans for disaster recovery. A key trait of replication is that it has never been easy to do, and like many other storage management solutions, products that could perform to customers' needs were, until recently, difficult to come by. In many cases, instead of a packaged software solution, what is used for long-distance replication is a conglomeration of homegrown scripts designed to preserve, manage, and copy transaction logs from a primary site to a second (or third) geographically-remote site at the time the logs are applied to a waiting database. This solution, although primitive (it is subject to QoS constraints on the IP networking framework and prone to human error) has worked well for many customers in lieu of commercially available solutions.

Asynchronous Replication

The manual process of copying and applying logs is a form of asynchronous replication, whereby the two data sets are not kept completely in sync, but are synchronized during a period or periods of batch processing. Software solutions provided by external disk vendors and specifically designed to manage disk-to-disk copies asynchronously between locations are able to ensure, through discrete algorithms, that the data is staged in the proper order as it arrives, with minimal impact to the application or to the IP backbone. The benefits of asynchronous replication are clear: less consumption of network bandwidth and less impact on the performance of the remote application. The disadvantage of asynchronous replication should be obvious in terms of business continuance: If the business is impacted by a catastrophic failure or natural disaster, there is a window of opportunity during which the data is not synchronized with production.

Synchronous Replication

Synchronous replication is ideal for environments in which little or no downtime is acceptable in the event of an outage. Cutover to the secondary or disaster recovery environment should be transparent to the end user or occur Chapter 1, likely candidates for these types of solutions. The obvious disadvantage of synchronous replication is the possibility of latency. Given the intolerance for latency built into most databases and applications, synchronous replication is typically performed over an optical network to minimize delay.

During synchronous replication, writes are acknowledged only when the data from the source is updated at the target. Therefore, in some cases, synchronous data replication might not be an ideal solution for long distances, without the use of traffic management techniques such as QoS to maintain performance, which can increase the complexity of the solution and the amount of hands-on management required. Synchronous replication is, however, the best way to ensure that the production and the disaster recovery copies are kept updated as of the last transaction.

Disaster recovery planners who work with applications that are more tolerant of latency or delay might find significant ROI in architecting disaster recovery environments based on IP storage, the primary advantage of which is dispensing with the distance limitations of native or dark fiber.

Both types of replication can take place via software-only solutions (such as those manufactured by Topio or Alacritus) or over additional out-of-band appliances (such as those manufactured by Kashya). This type of technology is often referred to as continuous data protection or just data protection. Replication traffic can be carried over SAN extensions or for shorter distances over native fiber.

Fibre Channel SANs not only allow sharing of storage devices between logical groups of hosts, but the nature of fiber-based transport is such that it can carry high-speed (up to 2125 Mbps) data over long-distances (up to 10 KM unassisted) to extend the physical footprint of SANs and link datacenters for the purposes of disaster recovery and data sharing. Figure 2-5 demonstrates linking two datacenters via a single Fibre Channel SAN fabric.

In the example in Figure 2-5, a development and a production datacenter are linked together over a single Fibre Channel fabric. Two director class switches act as gateways between each datacenter. For increased availability, (assuming that multiple, redundant fiber runs are available between each location), these switches can be augmented with an additional pair of director class switches at both sites. The previous example creates a virtual datacenter via native Fibre Channel, and it extends the any-to-any model up to 10KM.