The nodes participating in geographic mirroring must be in the same cluster, the same device domain, and the same cluster resource group. Before configuring geographic mirroring, you must specify a site name and the TCP/IP address(es) for each node in the recovery domain. If you have more than one node at a site, then the hardware (disk units) you select for the disk pool must be switchable between the nodes at the site. If you only have one node at a site, the hardware does not have to be switchable and should be non-switchable (private).
See Configure geographic mirroring with dedicated independent disk pools and Configure geographic mirroring with switchable independent disk pools for more information.
When geographic mirroring is configured, the mirror copy has the same disk pool number and name as the original disk pool, the production copy. Geographic mirroring is logical mirroring, not physical mirroring. The two disk pools must have similar disk capacities, but the mirror copy may have different numbers and types of disk units as well as different types of disk protection.
To maintain the data integrity of the mirror copy, the user cannot access the mirror copy while geographic mirroring is being performed. The user can detach the mirror copy to perform save operations, to create reports, and to perform data mining. However, the mirror copy must be synchronized with the production copy after it is reattached.
The production copy can function normally during synchronization, but performance might be negatively affected. During synchronization, the contents of the mirror copy are unusable, and it cannot become the production copy. If the independent disk pool is made unavailable during the synchronization process, synchronization resumes where it left off when the independent disk pool is made available again. Note that the first % complete message (CP1095D), after resuming an interrupted synchronization, shows 0%.
Full synchronization
Partial synchronization
When you set the attributes for geographic mirroring, you can set the synchronization priority. If synchronization priority is set high, the system uses more resources for synchronization, which results in a sooner completion time. The mirror copy is eligible to become a production copy faster, so you are protected sooner. However, high priority can cause degradation to your application. It is recommended that you try high priority first, so you are protected as soon as possible. If the degradation to your application performance is not tolerable, then lower the priority.
In addition to synchronization priority, you can also set recovery time out. The recovery timeout specifies how long your application can wait when geographic mirroring cannot be performed. When an error, such as IP failure, prevents geographic mirroring, the source system waits and retries for the specified recovery timeout before suspending geographic mirroring which allows your application to continue. The trade-off is between blocking your application or requiring synchronization after suspending geographic mirroring. When your application is blocked for an extended time, other jobs might also be blocked waiting for resources and locks owned by the applications using the geographic mirrored disk pool. When geographic mirroring is suspended, you no longer have the protection of the mirror copy. If your application can tolerate a delay, it is recommended to set recovery timeout from 2 to 5 minutes. If the volume of your data is large (over a terabyte), consider a longer recovery timeout value to reduce the possibility of suspending geographic mirroring. If mirroring is suspended without tracking, the system performs a full synchronization. If geographic mirroring is suspended with tracking, the system performs a partial synchronization.
When you configure the cluster for geographic mirroring, you have many options for defining the availability and protection of the independent disk pool. When you create the switchable hardware group, you list the order of the backup systems to which the independent disk pool will failover or switch over. If the primary node switches to a backup node at the same site, a hardware switch will occur. If the primary node switches to the other site, the mirror copy on the backup node changes roles to become the production copy. The old primary node becomes the new backup node, and the production copy becomes the mirror copy. The new production copy is now accessible for updates on the remote system. If the independent disk pools are part of a disk pool group, all of the disk pools in the group will switchover together. See Example: Independent disk pools with geographic mirroring.