Multi-Site Cluster Configuration Considerations

In Multi-Site Cluster configurations, a bitmap only file system shared between local nodes must be allocated for storing the bitmap files used to tracked changes to the replicated file system being protected. This allows for seamless switchovers and failovers between local nodes as all changes to the replicated file system are tracked in the bitmap file on the file system shared between the local nodes. Additional things to consider when configuring LUNs:

• The file system should be between only the local nodes and only used for storing bitmaps.

• Add one LUN for bitmap storage for each additional replicated file system in the configuration. Other data replication resources and LUN must NOT be shared.

• The file system size should be largest enough to hold the bitmap. The size required to store the bitmap file can be calculated based on the size of the replicated file system. For each 64KB of space in the replicated file system 1 bit is allocated in the bitmap when using default settings. For example, a replicated file system size of 64MB would require a 1000 bit bitmap file.

 

Resource Configurations to be Avoided

Before you begin your system configuration, it is important to understand what hierarchy configurations should to be avoided in a Linux Multi-Site Cluster environment.

Below are three examples of hierarchy configurations that should be avoided in Linux Multi-Site Cluster environments. In all these examples, the Linux Multi-Site Cluster hierarchy shares an underlying device with another hierarchy. When a failure or a switchover occurs in one of these hierarchies, the related hierarchies are affected. This could possibly produce unintended consequences such as application failure or mirror breakage; which would require a full-resync process. In addition, complications could result when the mirror source is switched over to the DR site to mirror back to the primary site. Since the mirror target system will have the lower level disk resources in service, LifeKeeper will not prevent any shared resources using this disk from also being operational (ISP) on the same node as the mirror target.

Example	Description
1	Using the Multi-Site Cluster hierarchy’s mirror disk resource more than once in the same or different hierarchies.
2	Using the same Multi-Site Cluster file system or disk resource for the mirror bitmap in more than one Multi-Site Cluster hierarchy. (Each mirror’s bitmap file must reside on a unique LUN and can’t be shared.)
3	Using the bitmap file system, device or disk resource with another hierarchy (Multi-Site or non-Multi-Site).