Mirror pools

GLVM requires that volume groups use super strict mirror pools. Super strict mirror pools must follow these rules:

• Local and remote disks cannot belong to the same mirror pool.
• No more than three mirror pools per volume group.
• Each mirror pool must contain at least one copy of each logical volume, with some exceptions:
  • When you create a logical volume, you need to configure it so that each mirror pool gets a copy. However, if you create a mirror pool in a volume group where logical volumes already exist, logical volume copies are not automatically created in the new mirror pool. You need to create them by running the mirrorvg command or the mklvcopy commands.
  • Asynchronous GLVM mirroring will require a new type of logical volume for caching of asynchronous write requests. This logical volume should not be mirrored across sites. Super strict mirror pools handle this new aio_cache logical volume type as a special case.

Additionally, mirror pools provide extra benefits to the asynchronous mirroring function:

• Synchronous or Asynchronous is an attribute of a mirror pool. Rather than having to configure individual RPV devices, mirror pools provide a convenient way for users to manage asynchronous mirroring at a higher level.
• The decision of whether to mirror synchronously or asynchronously is made at the mirror pool level. Therefore, you can decide to mirror from the production site to the disaster recovery site asynchronously, and then mirror from the disaster recovery site back to the production site synchronously. This can be accomplished by configuring the mirror pool that contains the disaster recovery site disks as asynchronous while configuring the mirror pool that contains the production site disks as synchronous.

This example shows a geographically mirrored volume group, where the disks at the production site have been placed into Mirror Pool 1, and the disks at the disaster recovery site have been placed into Mirror Pool 2. Both mirror pools are configured for asynchronous mirroring.

The following figure displays a geographically mirrored volume group:

This volume group has a total of five logical volumes. The user data is stored in three logical volumes. Logical volumes datalv1 and datalv2 contain file systems, and logical volume loglv3 contains the file system log. These three logical volumes are mirrored across both sites, because they have copies in both mirror pools.

Logical volumes aiocachelv1 and aiocachelv2 are used for caching of asynchronous write requests. They are not mirrored across both sites.

In the figure, the volume group is varied online at the production site. Writes to the local disks in Mirror Pool 1 occur synchronously, in the usual manner. However, writes to the remote disks in Mirror Pool 2 are processed asynchronously. The RPV clients on Node A use logical volume aiocachelv1, which resides on a local disk in Mirror Pool 1, for caching of asynchronous write requests.

The opposite would be true if the volume group was varied online at the disaster recovery site. Writes to the local disks in Mirror Pool 2 would occur synchronously, in the usual manner. However, writes to the remote disks in Mirror Pool 1 would be processed asynchronously. The RPV clients on Node B would use logical volume aiocachelv2, which resides on a local disk in Mirror Pool 2, for caching of asynchronous write requests.