Section 9.4. Local and Remote Mirroring

   

---

9.4 Local and Remote Mirroring

Mirroring was mentioned in Section 9.1 but not examined in detail. Mirroring is simply making a duplicate copy of the data available to ensure that another copy of the data is available in case the primary data store becomes unavailable for some reason.

Some popular reasons for mirroring or replication include the following:

• To provide a disaster recovery solution

• To provide load distribution or content distribution

• To provide high availability

• To use a secondary volume for data warehousing, backup, or testing with live data

Mirroring is local or remote. Local mirroring can happen at various levels:

• Application level in the host server . The application issues two identical write requests to two different disks, as illustrated in Figure 9.15.

  Figure 9.15. Mirroring at the Application Level

  

• Host-based RAID level . The application issues a single write request. Host-based RAID implemented in the form of a volume manager driver turns the single write request into two identical write operations, as illustrated in Figure 9.16.

  Figure 9.16. Mirroring at the Host-Based RAID Level

  

• HBA level . The application issues a single write request, which is turned into two identical write requests by the HBA in the host server, as illustrated in Figure 9.17.

  Figure 9.17. Mirroring at the HBA Level

  

• Storage controller level . This type of mirroring is done within the storage subsystem, as illustrated in Figure 9.18.

  Figure 9.18. Mirroring at the Storage Subsystem Level

  

All of these solutions apply only to local mirroring. The problem is that local mirroring is not exciting. The solutions described remain local simply because of limitations on buses; for example, SCSI devices can be only tens of feet away. One could put in a Fibre Channel SAN and have the storage unit farther away, of course. Alternatively, one could put ligence behind the replication at both ends (that is, both a source and a destination for replication), as illustrated in Figure 9.19.

Figure 9.19. Remote Mirroring with Intelligence at Both Ends

Having intelligence at both ends of replication nodes allows for some interesting possibilities, including:

• Performing the replication in a synchronous or asynchronous manner

• Performing the replication in a bidirectional fashion, thus allowing the server at each end to actively perform a service while simultaneously acting as a standby for the other server

• Performing intelligent error recovery and check pointing

Replication can be done at the disk block level (in other words, below the file system) or by means of a file system filter driver that can replicate files and directories.

Replication can be synchronous or asynchronous. With synchronous replication , a write operation is applied to both nodes (source and secondary, where the mirroring is being done), and a confirmation is received from both that the write was completed successfully before the application gets an acknowledgment that the write completed successfully. Thus, application performance is adversely affected. With asynchronous replication , the write request to the remote end is queued, the write request to the local node is issued while control returns to the application, and the write operations are executed asynchronously.

Synchronous replication favors data synchronization at the cost of poorer application performance. Asynchronous replication favors application performance at the cost of the two mirrored disks being temporarily out of sync while the data is "in flight." Once the data arrives and is applied to the remote disk, the two mirrored disks will once again be identical. Both synchronous and asynchronous replication solutions preserve the order of write operations to the storage device.

Several solutions have been developed by ISVs to enable high availability in a Windows NT environment using a replication solution and are already available. Note that some products will switch dynamically between synchronous and asynchronous I/O. The solution starts out handling all replication in a synchronous fashion, but if a glitch arises on the remote end, the volume is marked as nonsynchronized or unhealthy, and the system will switch to an asynchronous replication model.

Sections 9.4.1 through 9.4.3 examine some commercially available products. Note that the choice of products examined does not represent any recommendations, implicit or otherwise . Nor does the fact that a product is not described here reflect any opinion about that product. The choices were made with two characteristics in mind:

1. Information about these products was available relatively easily.

2. The sum of the products reviewed covers the various different ways in which a solution with the desired functionality might exist.

9.4.1 VERITAS Volume Replicator and VERITAS Storage Replicator

VERITAS is another ISV that specializes in storage, storage management, and disaster recovery solutions for a host of platforms, including Windows NT platform.

VERITAS Volume Replicator provides replication of volumes and deals with disk block data. VERITAS Volume Replicator leverages the fact that it already has a filter driver between the file system and the disk class driver ”that is, the VERITAS Volume Manager. A new filter driver hooks into the Volume Manager driver and forwards write requests to the remote volume.

VERITAS Storage Replicator replicates file data rather than disk block data. As Figure 9.20 shows, a file system filter driver overlays itself above the file system. The VERITAS Storage Replicator also preserves the order of the data written. A Windows NT system can be both the primary and the secondary system; that is, it can act as both source (which generates replication data) and target (which receives replication data from another system running VERITAS Storage Replicator). When making configuration changes, services may need to stop and be restarted for the VERITAS Storage Replicator to function as desired. This is not the case with VERITAS Volume Replicator, which requires no reboot. Figure 9.20 shows the architecture for the VERITAS Volume Replicator and VERITAS Storage Replicator products.

Figure 9.20. VERITAS Volume Replicator and VERITAS Storage Replicator

Both the Volume Replicator and the Storage Replicator products use the Transport Driver Interface (TDI) library interface to send and receive data. The VERITAS Storage Replicator product is a file system filter driver that layers itself over a file system. The VERITAS Volume Replicator product is a disk filter driver (rather than a file system filter driver). Figure 9.20 attempts to emphasize the fact that the TDI is a linked library rather than a stand-alone driver.

9.4.2 LEGATO RepliStor

RepliStor is an asynchronous file- and directory-level replication solution from LEGATO (through its acquisition of Octopus) that attempts to make copies of files (and keep them synchronized) to ensure performance and high availability. RepliStor can also replicate registry keys.

While specifying files, directories, or shares, RepliStor also allows specification of a list of files or directories excluded from the replication. RepliStor can also synchronize open files as long as the files synchronized are specified before they are opened by any application. RepliStor can also replicate Windows NT 4.0 Dfs shares, but not Windows 2000 Dfs shares. The Windows 2000 version of RepliStor has Active Directory integration, which allows users to store configuration data in Active Directory. Once a file has replicated, RepliStor replicates only the delta when a file is changed.

RepliStor can be optionally configured to use a dedicated NIC (network interface card) in an effort to isolate the RepliStor network traffic. Further, this network traffic is encrypted to protect the data during transmission. Each network packet allows for digital signature as well.

RepliStor can replicate information on a one-to-one or one-to-many basis. The target of the replication may be another Windows NT server (which could be running on different hardware) or a cluster member. The source of the replication can also be a cluster member server. RepliStor achieves replication in an asynchronous manner; that is, the writes to the remote site queue up, while local writes happen without confirmation from the remote site.

RepliStor complements the other LEGATO offerings, such as Co-StandbyServer, which cannot mirror system disks (the drive from which Windows NT is booted ). Because RepliStor is a file- and directory-based replication engine, it can replicate system disks as well.

RepliStor offers a configurable timer that causes the source system to ping the secondary system. If the ping fails, the secondary system first sends an ICMP (Internet Control Message Protocol) ping to ensure that the primary has really failed.

When a switchover does occur, RepliStor allows several configurable actions, including the following:

• The services will be started on the secondary system as part of the failover.

• The IP address and subnet mask values are forwarded to the secondary system.

• The commands execute on the secondary system as part of the failover; these commands can include batch files.

9.4.3 LEGATO Co-StandbyServer

LEGATO Co-StandbyServer is a clustering solution for Windows NT. Each server in the cluster can be active, and changes made by each server to disk replicate bidirectionally. If any of the clustered servers fail, Co-StandbyServer can fail over IP addresses, shares, server names , and other resources to the remaining healthy server.

As Figure 9.21 shows, LEGATO Co-StandbyServer offers bidirectional synchronous block-level replication capabilities between two Windows NT servers that can be up to 10 kilometers (approximately 6.25 miles) apart. Note that both ends can act as source and sink for each other. Thus, Figure 9.21 shows that whereas one disk is replicated from left to right, the other disk is replicated from right to left.

Figure 9.21. LEGATO Co-StandbyServer

The two servers between which the block-level mirroring happens need not be identical; the only requirement is that both servers be running Windows NT and have hardware that is on the Windows NT hardware compatibility list. The mirroring function cannot exist on the system boot drive.

LEGATO Co-StandbyServer has some problems when it is used with Windows 2000 LDM striping configurations. Co-StandbyServer offers two different pieces of functionality:

1. Mirroring , where writes on one server are duplicated to the other.

2. Shared storage mode , where if one server storage fails, data from the shared storage is made available to that server so that it can continue working.

The advantages of the LEGATO Co-StandbyServer include the following:

• No special hardware is required, and the primary and secondary servers may be running on different hardware; for example, one can be a multiprocessor system while the other is a single processor system.

• Co-StandbyServer includes support for multiple kinds of Windows 2000 servers, including domain controllers, member servers, and others.

• Co-StandbyServer includes supporting scripts to implement failover for popular Windows NT applications, such as IIS, SQL, or Exchange.

---

Top