This configuration is useful for performing off-line data mining on recent copies of live data.
The configuration appears as follows:
- Site A contains Cluster A and Storage A.
- Site B has Cluster B, Storage B1 and Storage B2. Between B1 and B2 is a very high-bandwidth mirror link (typically, ShadowImage or TrueCopy); B1 and B2 can be in the same storage subsystem. The mirror relationship between B1 and B2 is broken during office hours. Cluster B loads spans from, and mounts file systems on, Storage B2. No cluster is connected to Storage B1.
- Between Storage A and Storage B1 is a mirror relationship over a medium- or high-bandwidth link: typically, TrueCopy, TrueCopy ED or HUR.
To bring Cluster B up to date with Cluster A
If the mirror between Storage A and Storage B1 is asynchronous, or near-synchronous, synchronize it. Only changed blocks are copied across the WAN, and so the time taken is acceptable. If the mirror between A and B1 is synchronous, this step is unnecessary, but more bandwidth is required between the two sites in order to maintain acceptable performance at Site A.
On Cluster B, use the span-prepare-for-resync command.
Remake the broken mirror relationship between Storage B1 and Storage B2. Because of the high-bandwidth link between these two sets of storage, the time taken to perform the update is acceptable, but synchronization is not instantaneous.
Once synchronisation is complete, break the mirror link between B1 and B2, bringing B1 and B2 back into the simplex state. B2 now has a copy of the data on B1, which in turn is a copy of the data that was on A at the start of step 1.
On Cluster B, use the span-reload-after-resync command. If Cluster B mounted file systems on Storage B1, it would write to the storage, even if file systems were mounted read-only. These writes would make it impossible to do an incremental update over the link between Sites A and B. However, the fast link between B1 and B2 makes a complete resynchronization realistic. This is why three copies of the data are required.