Configuring GLVM on AIX

Here as shown, Node A is in production site and Node B is in disaster/backup site with TCP/IP connectivity between them. Say 'ex_gmvg' is the GMVG which is on PV1 and PV2 of Node A and PV3 and PV4 of Node B. A volume group which contains one or more RPVs is called GMVG (Geographically Mirrored Volume group).How to create a gmvg spanning across sites will be explained in further sections of this article.

As mentioned, GLVM is based on the concept of RPV (Remote Physical volume) which enables LVM at production site to access the disks PV3 and PV4 of disaster site as if they were locally attached .So, when Application or Filesystem reads/writes to logical volume of ex_gmvg at production site, LVM at production site processes read/write requests for remote disks by reading/writing to its RPV clients. So users have to define PV3 and PV4 as RPV Clients at production site and then RPV Clients communicate with RPV Servers at remote site to perform actual I/O to PV3 and PV4(Here again, users have to define PV3 and PV4 as RPV Servers at disaster site). RPVServer reads/writes to the real disk and passes the results back to RPV client, which in turn passes the results back to LVM.

Consider the figure below to have clear view of how GLVM operates,

Figure 2: Synchronous GLVM

It is actually the RPV device driver of GLVM which allows LVM at production site to access the disks at disaster site as if they were locally attached. This RPV device driver consists of two parts. One being the RPV Client, which is a pseudo device on local system to send I/O requests to the RPV Server. Another is the RPV Server which is a kernel extension on the remote system to processes I/O requests from a remote RPV client. It is RPV server which performs actual I/O to the PVs.

The principle of Synchronous mirroring is that Each Logical Volume Write is not considered complete until data has been written to disks at both sites. So with synchronous Mirroring, both the sites have same latest data.

Advantages

• Faster to read from local disk (since both the sites have same data)

• No data loss with site failure.

Disadvantages

• Reads and writes on remote physical volumes are much slower.

• Affected by the factors of network latency and network bandwidth.

Asynchronous Mirroring

With Asynchronous Mirroring, Writes are considered complete after data is written to local disks. RPV writes are cached at local site and mirroring to remote site takes place in background. From PowerHA System Mirror v5.5, Support was added for Asynchronous mirroring.

Before getting into the details of GLVM Asynchronous Mirroring, Understand the following terms which are associated with GLVM Asynchronous Mirroring

Terms Associated with GLVM Asynchronous mirroring

• LVM provides a new feature known as mirror pools from AIX 61D. A "mirror pool" is a user-specified collection of disks that will be used by LVM to contain one and only one copy of each of the logical volumes in a volume group. Asynchronous mirroring requires the RPV device driver to coordinate processing of asynchronous write requests across a set of disks in order to maintain data integrity and consistency and mirror pools provide a convenient way to group disks together for this purpose.

• Data divergence is a state where each site disks contain data updates that have not been mirrored to the other site. Assume if the production site goes down due to some failure, then disaster site may have back level of data as some of writes may not have got mirrored. If at later point of time, production site comes up, users will have two copies of data.

The decision of whether to mirror synchronously or asynchronously is made at the mirror pool level. Therefore, the user 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.

Asynchronous GLVM

Asynchronous mirroring builds upon LVM mirror pools. (Mirroring happens from, Say mirror pool MP1 to other mirror pool MP2.) So users might have to define local PVs in one mirror pool(MP1) and remote disks in other mirror pool(MP2).GLVM works the same at synchronous and asynchronous modes of mirroring, when the interaction of RPV clients and RPV Servers and the data replication across TCP/IP is considered. The difference lies only at how reads/writes are handled. With Asynchronous mirroring, it might happen that users have two copies of data due to data divergence. At this point, GLVM provides option to users, either to select the copy at production site or disaster site. With PowerHA System Mirror, this choice can be automated such that it always chooses the copy at production site A when it comes back.

Advantages

• Application response time can be improved.

• Heavy writes are absorbed in cache during heavy bursts

Disadvantages

• Remote site will always have back-level data so data loss might happen if local site goes down suddenly.

• Possibility of data divergence.

GMVG Creation

GMVGs can be created through "smitty storage" or using AIX commands. AIX commands are given below. Appropriate attributes should be used in smitty storage to create GMVGs.

Steps to Create Sync GMVG

1. To create Sync GMVG without mirror pools

   2. To Create Volume Group(GMVG),Logical Volumes and Filesystems

1. Create Mirror Copy on RPVs

3. To Create Mirror Copy on RPVs

We can also create Sync GMVG with mirrorpools on Scalable Volume Group as follows

1. To create Sync GMVG with mirror pools

3. To Create Volume Group(GMVG),Logical Volumes and Filesystems

1. Create Mirror Copy on RPVs

3. To Create Mirror Copy on RPVs

Now we will see the requirements for Async Mirroring

Requirements for Async Mirroring

1. Only supported on AIX 6.1 technology level 2 and up.

2. Must be SVG (Scalable Volume Group) type.

3. Must be super strict mirror pool enabled.

4. Must be non-concurrent volume group.

5. Auto varyon and bad block relocation disabled.

6. Async GMVG cannot contain paging type device.

7. Cannot be snapshot volume group.

8. rootvg cannot be configured for asynchronous mirroring.

Now As we know the requirements for Async mirroring let us get into the details of creating GMVG.

Steps to Create Async GMVG

1. Create Volume Group(GMVG),Logical Volumes and Filesystems

3. To Create Volume Group(GMVG),Logical Volumes and Filesystems

1. Create Mirror Copy on RPVs

3. To Create Mirror Copy on RPVs

1. Create aio_cache Logical Volumes

Asynchronous GLVM mirroring will require a new type of logical volume for caching of asynchronous write requests. We do not want this logical volume to be mirrored across sites. Super strict mirror pools will handle the new aio_cache logical volume type as a special case.

To Create aio_cache Logical Volumes

1. Enable super strict mirror pools; turn off auto-varyon and bad block relocation. the user must configure the volume group to use super strict mirror pools

3. To Turnoff auto-varyon and bad block relocation

1. Configure Async properties

High water mark says how much the cache can fill up before new write requests have to wait for mirroring to catch up. This value is expressed in megabytes.

To Set Async Properties

Basic Steps of GLVM Configuration (common for both sync and Async)

1. Install PowerHA System Mirror/XD(glvm filesets)

TO configure RPV site name and RPV devices use smitty glvm_utils

1. configure RPV Site name

3. To define RPV Site name

1. configure RPV Servers

3. To create RPV Servers

1. configure RPV Clients

3. To create RPV Clients

1. Create GMVG on RPV Devices. Make sure RPV clients are up the node where you create GMVG and appropriate RPV Servers to which these RPV Clients point to, are up on the other site. Also, RPV Devices shouldn’t be up on rest of the nodes of the cluster.

please refer to the section of GMVG Creation above, for steps to create Sync/Async GMVG.

1. Import GMVG on to the remaining nodes Please make sure that RPV clients and RPV servers are up on appropriate nodes while importing nodes. Also, RPV Devices shouldn’t be up on rest of the nodes of the cluster.

2. Basic PowerHA System Mirror Configuration steps.

   • PowerHA System Mirror site names should be same of RPV Site names.

   • Configure XD_data network

   • Use node-bound service-ip or persistent service-ip labels.

   • Set forced varyon option true for gmvgs.

   • Set allow varyon with missing data updates to true.

   • Give default choice for data divergence recovery.(siteA)