– Mirror pools: – aio_cache logical volumes Mirror pools make it possible to divide the physical volumes of a VG into separate  pools. A mirror pool is made up of one or more physical volumes. Each physical volume can  belong to only one mirror pool at a time. When creating a logical volume, each copy of  the logical volume being created can be assigned to a mirror pool. Logical volume  copies that are assigned to a mirror pool allocate only partitions from the physical  volumes in that mirror pool, which can restrict the disks that a logical volume copy can  use.  Without mirror pools, the only way to restrict which physical volume is used for  allocation when creating or extending a logical volume is to use a map file. Thus, using  mirror pools greatly simplify this process. Think of mirror pools as an  operating-system-level feature similar to storage consistency groups that are used  when replicating data. Although mirror pools are an AIX and not a GLVM-specific component, it is a best  practice to use them in all GLVM configurations. However, they are required only when  configuring asynchronous mode of GLVM. An aio_cache is a special type of logical volume that stores write requests locally while  it waits for the data to be written to a remote disk. The size of this logical volume  dictates how far behind the data is allowed to be between the two sites. There is one  defined at each site and they are  not  mirrored. Similar to data volumes, these volumes  must be protected locally, usually by some form of RAID. Figure 7-1 on page 269 shows a relatively basic two-site GLVM implementation. It consists of  only one node at each site, although PowerHA does support multiple nodes within a site. The New York site is considered the primary site because its node primarily hosts RPV  clients. The Texas site is the standby site because it primarily hosts RPV servers. However,  each site contains both RPV servers and clients based on where the resources are running. Each site has two data disk volumes that are physically associated with the site node. In this  case, the disks are hdisk1 and hdisk2 at both sites. However, the hdisk names do not need to  match across sites. These two disks are also configured as RPV servers on each node. In  turn, these are logically linked to the RPV clients at the opposite site. This configuration  creates two more pseudo-device disks that are known as hdisk3 and hdisk4. Their associated  disk definitions clearly state that they are RPV clients and not real physical disks. GLVM example  268  IBM PowerHA SystemMirror V7.2.3 for IBM AIX and V7.2.2 for Linux