Sun Microsystems 3 specification

When To Suspend Replication to the Secondary Site

For many customers, the Sun SNDR software is used to mirror the primary site’s information onto the alternate location as quickly as possible under the constraints of distance and technology. Operator errors, software bugs, and hardware data corruption are solid arguments for taking more deliberate, albeit less real-time, approaches to remote copies.

A deferred-write policy under such conditions delays remote updates until the local data has been confirmed to be good. The data integrity checks are performed periodically, followed by the remote copy. Some IT organizations reason that it is better to have slightly stale, good data at the remote site than to risk corrupting the remote copy with the lock-step updates. Consciously scrutinized database redo logs facilitate the recovery and update process, while minimizing the consequences of the errors.

Another method is to ship the data remotely in real time, take a snapshot of the data at the remote site with Sun StorEdge Instant Image software at a known point in time, and verify its integrity in the background before setting it aside for recovery.

Telco costs might similarly dictate a deferred copy policy. Some customers must timeshare narrow pipes between sites during the peak processing hours, leaving only off-hours for bulk intersite copies. Such prospects look for incremental update capabilities to reduce the transmission load and copy time. In other words, they prefer to send only what has changed since the previous remote image was generated.

Configuring The Sun SNDR Software for Mutual Replication

Sometimes the distinction between primary (A) and secondary (B) sites is blurred. As applications are geographically distributed, a secondary storage system at Site B might function as a remote volume replication to Site A and as a direct storage resource for applications on Host B. Under these circumstances, you might also elect to have critical applications running on Host B to have their volumes replicated to Site A. This reciprocal replication arrangement supported by the Sun SNDR software is known as mutual replication.

Each server can concurrently transmit and receive writes to and from its remote counterpart. Each system contains primary disks in a Sun SNDR software set that are accessible by local hosts, as well as remote mirrors secondary to remote hosts. Mutual replication might be used where critical applications and storage are split across sites, and both sites require remote replicated volumes.

12 Sun StorEdge Network Data Replicator 3.0 Configuration Guide • June 2001