completion to the primary host. The primary host can continue to write to the primary virtual disk, butremote writes do not take place.When communication is restored between the RAID controller module owner of the primary virtual diskand the RAID controller module owner of the secondary virtual disk, a resynchronization takes place. Thisresynchronization happens automatically, or it must be started manually, depending on which writemode you chose when setting up the replication relationship. During the resynchronization, only theblocks of data that have changed on the primary virtual disk during the link interruption are copied to thesecondary virtual disk. After the resynchronization starts, the replicated pair transitions from anUnsynchronized status to a Synchronization in Progress status.The primary RAID controller module also marks the replicated pair as unsynchronized when a virtual diskerror on the secondary side prevents the remote write from completing. For example, an offlinesecondary virtual disk or a failed secondary virtual disk can cause the remote replication to becomeunsynchronized. When the virtual disk error is corrected (the secondary virtual disk is placed online orrecovered to an Optimal status), then synchronization is required. The replicated pair then transitions to aSynchronization in Progress status.ResynchronizationData replication between the primary virtual disk and the secondary virtual disk in a replicationrelationship is managed by the RAID controller modules and is transparent to host machines andapplications. When the RAID controller module owner of the primary virtual disk receives a write requestfrom a host, the RAID controller module first logs information about the write to a replication repositoryvirtual disk. The RAID controller module then writes the data to the primary virtual disk. The RAIDcontroller module then initiates a write operation to copy the affected data to the secondary virtual diskon the remote storage array.If a link interruption or a virtual disk error prevents communication with the secondary storage array, theRAID controller module owner of the primary virtual disk transitions the replicated pair into anUnsynchronized status. The RAID controller module owner then sends an I/O completion to the hostsending the write request. The host can continue to issue write requests to the primary virtual disk, butremote writes to the secondary virtual disk do not take place.When connectivity is restored between the RAID controller module owner of the primary virtual disk andthe RAID controller module owner of the secondary virtual disk, the virtual disks must be resynchronizedby copying the blocks of data that changed during the interruption to the secondary virtual disk. Only theblocks of data that have changed on the primary virtual disk during the link interruption are copied to thesecondary virtual disk.CAUTION: Possible loss of data access – Any communication disruptions between the primarystorage array and the secondary storage array while resynchronization is underway could resultin a mix of new data and old data on the secondary virtual disk. This condition would render thedata unusable in a disaster recovery situation.Remote Replication GroupAfter your Remote Replication premium feature is activated on both local and remote storage arrays, youmust create Remote Replication groups on the local storage array.A replication group contains at least one replicated virtual disk pair, one on the local storage and one onthe remote storage array, that share data synchronization settings. Multiple replicated pairs can reside in areplication group, but each pair can only be a member of one Remote Replication group.The following attributes also apply to a Remote Replication group:89
