User manual DOT HILL REPLICATION BROCHURE

[. . . ] Both software modules are at the core of Dot Hill's data protection strategy. Please refer to Dot Hill's white paper called "Snapshots and Data Protection: The Dot Hill Difference" for a high-level overview of Dot Hill's snapshot service. This white paper provides a high-level overview of the Dot Hill's new asynchronous batch remote replication service. 2 Prerequisites Please note that any time "snapshot" or "snapshot service" is mentioned in this white paper, it refers to block-level sparse snapshot functionality. Asynchronous block data remote replication refers to the asynchronous duplication of data between distinct subsystems. [. . . ] Creation of snapshots Deletion of snapshots Roll-back of snapshots Management of snapshots Failover code than ensures a consistent state in case of RAID controller failure It is also important to note that since existing snapshot code, algorithms and data structures are used to implement a large portion of the batch replication functionality, the risk of virus infection is significantly reduced as a result of the use of the batch remote replication service. Note that the roll forward operation is functionally equivalent to a rollback operation in Dot Hill's snapshot architecture. 2 5 Data Transport Replication data will be transported from a local system to the remote systems using either TCP/IP (iSCSI) or fibre channel. Destination system addresses will be configured on the local system using a standard Dot Hill management interface, including CLI, WBI or SANscape. Retries and other guaranteed data delivery mechanisms will be built in to the protocol to ensure that the data is delivered from the local system to the remote systems without error. When transferring the snapshot delta data from the local system to the remote system or systems, the local system will maintain a high water mark that indicates the progress of the data transfer to each of the remote systems. It is necessary for the local system to maintain this state information for each remote target system because the state of the connection and the quality of the connection to each remote system cannot be guaranteed. For example, the connection from the local system to remote system #1 may provide excellent bandwidth while the connection to remote system #2 may be intermittent with little or no data transfer for several minutes at a time. In this case, the snapshot delta data transfer to remote system #1 will be "ahead of" the data transfer to remote system #2; hence the need for a water mark that maintains the address of the next data chunk that is to be transferred to each remote system. 6 Batch Replication Example This section provides an example of batch replication from a local system to a remote system and provides pictorial representations of the snapshot delta data replication process. Batch Replication is configured to snapshot and subsequently replicates the data at 7 AM, 8 AM and 9 AM. Since the Batch Replication process begins at 7 AM, it is necessary for the local system to take a snapshot at 7 AM in order to image stabilize the local volume. The 7 AM snapshot is taken and a remote volume copy of all the data as it existed on the local system volume at 7 AM is performed. That is, the data for all blocks on the volume from 0 to n-1 as they existed at 7 AM are transferred to the remote system. The remote system will write all of the blocks from the 7 AM image stabilized state to the remote volume. After all of the data blocks have been successfully transferred to the remote volume, the remote volume now has the state of the local volume at 7 AM. Please see Figure 1. Local System Local Volume 7:00 AM Snapshot Remote Volume 7:00 AM State Remote System Figure One: 7:00 AM Remote Volume Copy Batch replication on the local system will take another snapshot of the local volume at 8 AM in order to image stabilize the volume. The new data that has been written to the volume within the time period of 7 AM to 8 AM will now be replicated to the remote system and stored on the remote system as the 8 AM snapshot. Please see Figure 2. Local System Local Volume 8:00 AM Snapshot 7:00 AM Snapshot Remote System Remote Volume 7:00 AM State 8:00 AM Snapshot Figure Two: 8:00 AM Snapshot Replication Batch replication on the local system will take another snapshot of the local volume at 9 AM in order to image stabilize the volume. The new data that has been written to the volume within the time period of 8 AM to 9 AM will now be replicated to the remote system and stored on the remote system as the 9 AM snapshot. Please see Figure 3. Local System Local Volume 9:00 AM Snapshot 8:00 AM Snapshot 7:00 AM Snapshot Remote System Remote Volume 7:00 AM State 8:00 AM Snapshot 9:00 AM Snapshot Figure Three: 9:00 AM Snapshot Replication Since the batch replication data is stored on the remote system as point-in-time snapshots, it is possible for the system administrator to initiate a rollback of the remote volume using the standard snapshot rollback functionality. Therefore, the system administrator could choose to maintain the remote volume in the 7 AM state, or initiate a rollback operation to roll the volume forward to the 8 AM or the 9 AM state. It is also possible for the remote system to apply the snapshot delta data to the remote volume immediately upon receipt of the snapshot data. For example, after receiving the snapshot delta data for the 8 AM snapshot, the remote system could immediately apply the snapshot delta data to the remote volume in order to update the state of the remote volume to the 8 AM state. The 8 AM snapshot could then be optionally deleted in order to conserve backing store space. [. . . ] The process of replacing the master volume data with older data is called rollback, since this rolls the data on the master volume back to an earlier point in time. Snapshot: A snapshot is a point in time capture of data on a master volume (or another snapshot ­ not supported in initial implementation). The snapshot itself will define an array partition but is a virtual volume. That is, the snapshot volume itself does not exist. [. . . ]