![]() ![]() ![]() |
Appendix B: OEM Disk, Volume Group, and Filesystems Accommodation
This appendix describes how you can customize HACMP software to integrate Original Equipment Manufacturer (OEM) disks, volume groups, and filesystems in an HACMP cluster. The appendix contains these sections:
Integrating OEM Disks in an HACMP Cluster
HACMP lets you use either storage disks manufactured by IBM or OEM physical storage disks as part of a highly available infrastructure, as long as the disks are defined in AIX 5L and are part of AIX 5L LVM volume groups.
Depending on the type of OEM disk, custom methods allow you (or an OEM disk vendor) either to tell HACMP that an unknown disk should be treated the same way as a known and supported disk type, or to specify the custom methods that provide the low-level disk processing functions supported by HACMP for that particular disk type.
This section contains the following topics:
Overview
Custom methods for OEM disks provide a means for configuring and supporting OEM disks in an HACMP cluster. These methods depend on the types of disks that are supported by the HACMP software, and on the different ways they are handled. A level of similarity between certain types of disks allows you to configure an OEM disk that is unknown to HACMP as you would a similar type of disk known to HACMP. Alternatively, you can select one or more of the disk processing methods used by HACMP to safely deal with an OEM disk.
The disk processing methods include:
Identifying ghost disks Ghost disks are duplicate profiles of the disks created during disk configuration processing. Ghost disks must be removed to allow AIX 5L to vary on the volume group residing on the original disks.
Determining whether another node in the cluster is holding a disk reserve Breaking a disk reserve Making a disk available for use by another node. Handling Disks in HACMP
HACMP handles disks according to AIX 5L LVM disk requirements. The AIX 5L Logical Volume Manager (LVM) by default is not designed to handle multiple nodes accessing the same set of disks, which are referred to as shared. Therefore, HACMP performs special disk processing for shared disks in a cluster. When nodes in the HACMP cluster join and leave the cluster, HACMP brings the shared disks into a state where the LVM commands work correctly.
In the LVM, one or more disks, also known as physical volumes, can be grouped together to form a volume group. Logical volumes can be built on top of a volume group and filesystems can be built on top of logical volumes. See AIX 5L LVM documentation for more information.
HACMP supports two modes of access to volume groups in a cluster: serial access mode and concurrent access mode.
Serial Access to Volume Groups
In serial access mode, the volume group is active on one node at a time. From the LVM’s point of view, this is an ordinary volume group. Since the LVM does not handle multiple node access to the disks on which the volume group resides, when such a volume group is active on one of the nodes, the LVM instructs the device driver layer on that node to establish a reserve on the disks. A disk reserve is a hardware-level command that tells the disk to accept commands only from the SCSI adapter that sent the reserve request. This restriction prevents other cluster nodes from inadvertently modifying the volume group.
The reserve function is absolutely critical for disks that are used to hold Journaled File System(s) (JFS). JFS function by aggressively caching file data and filesystem-specific information in real memory. JFS have no mechanism by which one node can inform another node that its cache is no longer valid. Therefore, if multiple nodes access a disk holding a JFS, and the filesystem is mounted and being accessed on those nodes, the result would be invalid data being returned on read requests, a node failure, and corruption of the JFS.
A disk reserve remains active on the node even if the node that established the disk reserve fails. For serial access volume groups, HACMP must ensure that, in the event of a node failure, a takeover node can access the disks. To do this, the takeover node must break the disk reserve established by the failed node. To break the disk reserve, the takeover node uses special low-level commands, typically specific to the attachment mechanism and the disk subsystem.
Concurrent Access to Volume Groups
In concurrent access, the volume groups residing on shared disks are activated and can be simultaneously accessed in read/write mode by all active nodes in the cluster.
Note: AIX 5L introduced enhanced concurrent mode. When concurrent volume groups are created on AIX 5L, they are automatically created as enhanced concurrent mode, except when SSA disks are used. Convert your SSA and RAID concurrent volume groups to enhanced concurrent mode volume groups. For details, see the chapter Planning Shared LVM Components in the Planning Guide.
Accessing disks in concurrent mode requires that software packages running above the LVM coordinate their operations across the cluster to ensure data integrity. The AIX 5L Journaled File System is not supported on volume groups accessed in concurrent mode. Consult the provider of any middleware to determine whether that middleware can reliably function in concurrent mode.
For concurrent access volume groups, HACMP must ensure that no disk reserve is placed on the disk, so that access by other nodes is possible.
The question arises as to whether any disk can be used in concurrent mode. The answer is no, because of a practical requirement to mirror data in an HACMP cluster, so that data is not be lost if any of the disks fails. Even though most disks could be accessed without establishing a disk reserve on them, many disks still cannot be used in concurrent mode, because the LVM cannot simultaneously update all the copies of a single logical partition. Even when the writes on a disk are done in parallel, they may not actually be completed at the same time, due to other activity on the disk, or the physical characteristics of the disks. If one node writes data and the other node reads it, there is no guarantee that the reader gets the latest copy. Additionally, if the LVM cannot update its structures on a disk, it ceases to write to that disk and marks it as failed. In a multi-node cluster, this situation creates a single point of failure.
The following section describes how these practical problems with concurrent access volume groups are handled in the HACMP software.
Disks Supported by HACMP
HACMP supports four kinds of disks:
Enhanced Concurrent Mode Disks
AIX 5L v.5.2 and up support enhanced concurrent mode. In enhanced concurrent mode, instances of the Concurrent Logical Volume Manager (CLVM) coordinate changes between nodes through the Group Services component of the Reliable Scalable Cluster Technology (RSCT) facility in AIX 5L. Group Services protocols flow over the communications links between the cluster nodes.
With enhanced concurrent mode:
Any disk supported by HACMP for attachment to multiple nodes can be included in an enhanced concurrent mode volume group. The same capabilities for online changes of volume group and logical volume structure that have always been supported by AIX 5L for SSA concurrent mode volume groups are available for enhanced concurrent mode volume groups. Enhanced concurrent mode volume groups require the Concurrent Resource Manager. This provides the cluster initialization that is needed for CLVM to provide enhanced concurrent mode support. True Concurrent Mode Disks
True concurrent mode disks are managed across the cluster by the Concurrent Logical Volume Manager (CLVM), an extension to the AIX 5L LVM that is enabled when HACMP is installed.
HACMP software supports one type of true concurrent mode IBM disks: SSA disks. This type of disks has the covert channel facility, which CLVM uses to allow multiple instances of the CLVM on the nodes across the cluster. This makes it possible to keep the local LVMs and the disk contents synchronized. These disks also provide a “fencing” function, which is the multi-node equivalent of disk reserves: It allows the specified subset of cluster nodes to access the shared disks while blocking out other nodes. For this type of disks, HACMP automatically fences out failed nodes to prevent inadvertent modification of the disks.
For true concurrent mode disks, the CLVM can keep the individual LVMs on the cluster nodes synchronized. The CLVM also allows you to make changes to the volume group configuration (such as adding or extending a logical volume, or adding or deleting a disk on a node), and propagate the changes to all other cluster nodes. The CLVM uses the covert channel facility to coordinate updates across the cluster, and to inform other nodes that they must reread the LVM structures on the disk to pick up the latest information. This ensures that the nodes in the cluster will not pick up stale data by reading an obsolete disk mirror.
RAID Concurrent Mode Disks
RAID concurrent mode disks, like true concurrent mode disks, can be accessed in read/write mode by multiple cluster nodes, and the shared volume groups residing on these disks can be varied on multiple nodes in a cluster.
The RAID concurrent mode disks do not have a covert channel. The CLVM provides no direct management or coordination of LVM updates across nodes in a cluster.
The following two functions allow support for RAID concurrent mode disks in an HACMP cluster:
Static configuration. A RAID disk is an abstraction of a number of physical disks, with data and parity information scattered across the physical disks in a manner defined by RAID implementation. Since the RAID controller manages the physical disks, the LVM perceives a RAID disk device as a certain number of hdisks that is smaller than the number of present physical spindles. The RAID controller handles most data redundancy concerns; the LVM’s capabilities for data mirroring and online modification of a volume group are not used. Lack of mirroring. As mentioned previously, the RAID controller handles data redundancy; LVM does no mirroring. As a result, it is not possible for a node to read the wrong mirror copy. Note: It is possible to mirror a RAID disk, although this is generally considered unnecessary and is not supported when the disk is used in a concurrent access volume group.
Note: RAID concurrent mode disks provide no communication mechanisms to keep the individual LVMs on the cluster nodes synchronized. The lack of a covert channel in RAID concurrent mode disks prevents dynamic modifications to the volume group structure (for example, expanding a logical volume).
For information about RAID disks, see the following URL:
Serial Access Mode Disks
Only one node at a time can access serially accessed disks in read/write mode, and the shared volume groups residing on these disks can be varied on only one node in a cluster. The LVM perceives these disks as normal disks. The actual hdisks as perceived by the LVM can be either physical spindles (a configuration sometimes referred to as “JBOD”—Just a Bunch of Disks—to contrast it with RAID), or RAID disks. For JBOD configurations, configure the LVM to provide mirroring for data reliability.
The following shell script contains most of the processing for HACMP disk takeover: /usr/sbin/cluster/events/utils/cl_disk_available.
Supporting Disks with Known Characteristics
All the disks supported by HACMP adhere to some form of the SCSI standard. However, this standard has undergone considerable evolution over time and allows for many implementation choices. Even so, many disks behave in similar ways. HACMP provides mechanisms that will allow you, while configuring a cluster, to direct HACMP to treat an unknown disk exactly the same way as another disk it supports. You do this by making simple additions to ASCII files using any available text editor. In particular, changes to the following files will be necessary:
/etc/cluster/conraid.dat
Use this file to tell the CRM HACMP that a particular disk is a RAID disk that can be used in concurrent mode. The file contains a list of disk types, one disk type per line. The value of the Disk Type field for a particular hdisk is returned by the following command:
This command returns a response similar to the following:
This file is referenced by /usr/sbin/cluster/events/utils/cl_raid_vg.
/etc/cluster/lunreset.lst
Use this file to tell HACMP that a particular disk supports LUN resets, even though its response to the SCSI inquiry command indicates that the disk does not support the SCSI command set. The file contains the Vendor Identification field. A SCSI inquiry command returns the value of this field. Consult the disk manufacturer for the value of this field.
/etc/cluster/disktype.lst
Use this file to tell HACMP that it can process a particular disk the same way it processes disks that it supports. The file contains a series of lines of the following form:
To determine the value of the PdDvLn field for a particular hdisk, enter the following command:
This command returns a response similar to the following:
The supported disk types are:
Disk Name in HACMP Disk Type SCSIDISK SCSI -2 Disk SSA IBM Serial Storage Architecture FCPARRAY Fibre Attached Disk Array ARRAY SCSI Disk Array FSCSI Fibre Attached SCSI Disk
This file is referenced by /usr/sbin/cluster/events/utils/cl_disk_available.
HACMP does not modify the previously described files after they have been configured and are not removed if the product is uninstalled. This ensures that customized modifications are unaffected by the changes in HACMP. By default, the files initially contain comments explaining their format and usage.
Keep in mind that the entries in these files are classified by disk type, not by the number of disks of the same type. If there are several disks of the same type attached to a cluster, there should be only one file entry for that disk type. In addition, unlike other configuration information, HACMP does not automatically propagate these files across nodes in a cluster. It is your responsibility to ensure that these files contain the appropriate content on all cluster nodes. Use the HACMP File Collections facility to propagate this information to all cluster nodes. For more information on the HACMP File Collections facility, see Administration Guide.
Customizing HACMP Disk Processing
Some disks may behave sufficiently differently from those supported by HACMP so that it is not possible to achieve proper results by telling HACMP to process these disks exactly the same way as supported disk types. For these cases, HACMP provides finer control. While doing cluster configuration, you can either select or specify one of the specific methods to be used for the steps in disk processing.
HACMP supports the following disk processing methods:
Identifying ghost disks Determining whether a disk reserve is being held by another node in the cluster Breaking a disk reserve Making a disk available for use by another node. HACMP allows you to specify any of its own methods for each step in disk processing, or to use a customized method, which you define. This allows you to use a custom defined method only for configuring a disk, and to use the existing HACMP methods for other disk operations.
The following methods are supported by HACMP for each of the steps in disk processing:
Identifying Ghost Disks
Ghost disks are duplicate profiles of the disks created during disk configuration processing. You must remove ghost disks in order to allow AIX 5L to vary on the volume group residing on the original disks.
A ghost disk is created when the disk configuration method is run while a disk is being reserved by another node. In this case, the configuration method cannot read the PVID of the reserved disk to identify it as an existing disk. This can easily happen when:
A node fails HACMP takes over the failed disks. During the takeover, the other node breaks any outstanding disk reserve on the failed node and establishes its own reserve on the disks. The failed node reboots. The disk configuration method run at boot time cannot read the disks due to the disk reserve held by another node. Ghost disks are a problem for two reasons:
The presence of superfluous disk profiles is confusing to the system If the ghost disk is in an available state and the PVID is returned by lsdev, then any attempt to make the real disk available will fail, since the two disks refer to the same device. This prevents use of the real disk for operations such as varyon. Identifying a ghost disk is supported in HACMP in the following way:
1. The method is passed as an input hdisk name, such as hdisk42.
2. The method writes to standard output a list of disk names that are ghost disks for the given disk.
3. If there are no ghost disks for the given disk, nothing is returned.
A return code of 0 indicates success; any other value will cause processing to be terminated for the given disk.
HACMP supports values of SCSI2 and SCSI3 for the name of this method. If either of those values is specified, HACMP uses the existing disk processing that is being used to identify ghost disks for IBM SCSI-2 or SCSI-3 disks:
SCSI2 ghost disks are those with different names from the given disk, but identical parent and location attributes in CuDv. SCSI3 ghost disks are those with different names from the given disk, but identical parent and location attributes in CuDv; and identical lun_id, scsi_id and ww_name attributes in CuAt. Determining Whether a Disk Reserve Is Held by Another Node
A disk reserve restricts access to the disk by a specific node. If the node that established the reserve has failed, HACMP takes special steps to remove that disk reserve.
This method is passed as an input hdisk name, such as hdisk42. It passes back a return code with one of the following values:
0—The disk is not reserved, and it is readable and writable. 1—A disk reserve is currently held by another node. 2—An error has occurred. HACMP should terminate processing for this disk. Any other value will be interpreted as equivalent to 2.
HACMP supports a value of SCSI_TUR for the name of this method. If this value is specified, existing processing in HACMP is used to determine whether a disk reserve is being held. The processing opens the disk device and sends a SCSI Test Unit Ready command via ioctl(). A response of reservation conflict means that there is a disk reserve held by another node.
Breaking a Disk Reserve
Disk reserves can be broken in parallel. Any serialization requirements must be handled by user-supplied methods.
This method is passed as input two formal parameters:
The name of the owning adapter for the disk, such as scsi1. This is determined by HACMP by running the command: lsdev -Cc disk -l <hdisk name> -F parentThe hdisk name, such as hdisk42. A return code of 0 (zero) indicates success; any other value causes HACMP to terminate processing for this disk.
HACMP supports values of TARGET, PSCSI, and FSCSI for the name of this method. If one of these values is specified, HACMP uses existing processing for this method. The processing breaks the disk reserves for these types of disks:
TARGET. A SCSI target ID reset will be sent by executing openx(<hdisk name>, ,SC_FORCED_OPEN)Specifying the TARGET value is appropriate for SCSI devices with only one LUN per SCSI ID.
PSCSI. The disk is treated as a parallel SCSI device. In particular, the SCSI and LUN ID information is retrieved from the position attribute in the CuDV entry for the hdisk. The disk is opened, and either a LUN reset or a target reset is sent, depending on whether a SCSI inquiry command reports this device as being SCSI-2 or SCSI-3. Note, that an entry in /etc/cluster/lunreset.lst causes a LUN reset to be sent to a device that identifies itself as SCSI-2. FSCSI. The disk is treated as a fiber-attached SCSI device. In particular, the LUN ID is retrieved from the lun_id field in the CuAt entry for this device. Making a Disk Available for Use by Another Node
This method allows for making a disk available in the AIX 5L state, as returned by lsdev command. A device must be in an available state for the LVM to be able to access it and to vary on a volume group.
This method is passed as an input hdisk name, such as hdisk42.
A return code of zero indicates success; any other value causes HACMP to terminate processing for this disk.
HACMP supports a value of MKDEV for the name of this method. If this value is specified, HACMP uses existing processing for this method and attempts to run the following command up to four times:
Configuring OEM Disk Methods in SMIT
You can add, change, and remove custom disk processing methods for a specific OEM disk using SMIT. You can select existing HACMP-supported custom disk methods or use your own custom disk methods.
/etc/cluster/conraid.dat
/etc/cluster/lunreset.lst
/etc/cluster/disktype.lst
These are text files that can be modified with an editor. For more information on how to change these files, see Supporting Disks with Known Characteristics.
Adding Custom Disk Methods
To add a custom disk method:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Extended Resource Configuration > HACMP Extended Resources Configuration > Configure Custom Disk Methods > Add Custom Disk Methods and press Enter.
3. Enter field values that define the disk processing methods you want to specify for the particular OEM disk:
Note: The custom disk processing method that you specify for a particular OEM disk is added only to the local node. This information is not propagated to other nodes; you must copy this custom disk processing method to each node manually or use the HACMP File Collections facility.
Once you have made the selections, the information is applied to the disks defined on the local node.
4. Configure the same custom disk processing method on each other node in the cluster and synchronize the cluster resources. The cluster verification process ensures that the method that you configured exists and is executable on all nodes. The synchronization process ensures that the entries in the HACMP configuration database are the same on all nodes, but will not synchronize the methods named in the database entries.
Changing Custom Disk Methods
To change a custom disk method:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Extended Resource Configuration > HACMP Extended Resources Configuration > Configure Custom Disk Methods > Change/Show Custom Disk Methods and press Enter.
3. Select a name of a particular disk method and press Enter. SMIT displays the current information.
4. Enter new information in the fields you want to change and press Enter.
Note: The characteristics of the method are changed on the local node but they are not updated on remote nodes. Custom disk methods should be updated manually on other nodes in the cluster, or you can use the HACMP File Collections facility for this purpose.
Removing Custom Disk Methods
To remove a custom disk method:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Extended Resource Configuration > HACMP Extended Resources Configuration > Configure Custom Disk Methods > Remove Custom Disk Methods and press Enter.
3. Select a disk method you want to remove and press Enter. SMIT prompts you to confirm your selection. If you choose to continue, the corresponding entry in HACMPdisktype will be deleted.
Note: HACMP deletes the characteristics of the disk methods on the local node but does not update them on remote nodes. Manually delete custom disk methods on other nodes in the cluster.
Integrating OEM Volume Groups in an HACMP Cluster
You can configure OEM volume groups in AIX 5L and use HACMP as an IBM High Availability solution to manage such volume groups, their corresponding filesystems, and application servers. (Applications servers are defined as start and stop scripts for the applications supported by the volume groups).
For information on filesystems, see Integrating OEM Filesystems in an HACMP Cluster.
Note: Different OEMs may use different terminology to refer to similar constructs. From now on, this appendix uses the term volume groups to refer to OEM and Veritas volume groups.
In particular, HACMP 5.4 automatically detects and provides the methods for volume groups created with the Veritas Volume Manager (VxVM) using Veritas Foundation Suite (VFS) v. 4.0. Note, Veritas Foundation Suite is also referred to as Veritas Storage Foundation (VSF). This documentation uses VFS.
Use the following table to identify the terminology used for the storage components by IBM and Veritas. Other manufacturers may use similar terminology:
AIX 5L Logical Volume Manager (LVM) Veritas Volume Manager (VxVM) Physical Volumes Disk Media Logical Volumes Volumes Volume Groups Disk Groups
For general information on OEM volume groups and filesystems, see the corresponding vendor storage documentation. In particular, for Veritas volume groups see the latest Veritas Volume Manager Migration Guide for AIX 5L.
This section contains the following topics:
Overview
Depending on the type of OEM volume, custom methods in HACMP allow you (or an OEM vendor) either to tell HACMP that a volume unknown to AIX 5L LVM should be treated the same way as a known and supported volume or to specify the custom methods that provide the volume groups processing functions supported by HACMP.
You can either use custom methods for volume groups offered by HACMP, or create your own custom methods to use for the non-IBM volume groups in the cluster. These functions are performed within the normal HACMP event processing.
OEM Volume Group Functions Performed by HACMP
When HACMP identifies OEM volume groups of a particular type, it provides the following built-in processing functions for them or lets you specify your own custom methods for any one of these functions:
List volume groups of a specified type defined on the nodes. List physical and logical disks comprising a specified volume group. Bring a volume group online and offline. Determine a volume group status. Verify volume groups configuration. Provide a location of log files and other debugging information. You can then view this information by using the AIX 5L snap -e command. HACMP enables you to manage OEM volume groups in an HACMP cluster by bringing them online and offline as needed for cluster event processing.
Before bringing a volume group online or offline, HACMP checks the volume group type to determine whether it must use the corresponding built-in custom method to manage the volume group and filesystem and bring it online or offline as needed.
OEM Volume Groups and Filesystems as Resources in an HACMP Resource Group
You can include OEM disks, volume groups, and filesystems in an HACMP resource group. HACMP recognizes OEM volume groups and filesystems and handles them as the AIX 5L LVM volume groups and filesystems by listing, activating, checking and taking them offline when it is necessary for the cluster event processing tasks.
You can also mix the OEM disks, volume groups and filesystems with AIX 5L volume groups and filesystems in a single HACMP resource group.
When you include OEM or Veritas volume groups or filesystems into HACMP resource groups, Automatically Import Volume Groups field should be set to false. Also OEM volume groups should be set to not automatically varyon when the node is restarted; OEM filesystems should be set to not automatically mount when the node is restarted.
To view OEM disks, volume groups and filesystems used in the HACMP cluster, you can use the HACMP SMIT interface.
Prerequisites
In order for HACMP to handle OEM volume groups and filesystems in your configuration, the volume groups and filesystems must adhere to these conditions:
Each OEM volume is composed of one or more physical disks (equivalent to hdisks in AIX 5L) and the system can determine the names of the physical disks from the name of the volume. OEM disks, volume groups, and filesystems must have operations and sequences of operations comparable to the functions of AIX 5L LVM, although the command names, syntax, and arguments may differ. For Veritas volume groups, HACMP automatically uses them once they are configured in HACMP with the SMIT panels described below. For other OEM volume groups, HACMP uses the custom methods that you specify in SMIT. Limitations
HACMP identifies OEM volume groups and filesystems and performs all major functions with them. See OEM Volume Group Functions Performed by HACMP and OEM Filesystems Functions Performed by HACMP.
However, some of the HACMP functions have limitations for OEM volume groups and filesystems:
You cannot use C-SPOC (Cluster Single Point of Control) to manage OEM disk, volume, and filesystems operations. In particular, if you use C-SPOC for your other operations, HACMP does not include OEM disks, volume groups and filesystems in picklists for your selection in SMIT. HACMP does not automatically discover OEM volume groups and filesystems and does not list them for your selections in picklists in SMIT. HACMP does not use NFS (Network Filesystem) functions for OEM filesystems. HACMP does not provide a workaround for any limitations of OEM disks, volume groups, and filesystems that exist outside of HACMP. In addition to listing, varying on and off, and verifying volume groups and filesystems created with the AIX 5L LVM, HACMP supports other extended functions for its “own” volume groups and filesystems, such as enhanced concurrent mode, active and passive varyon process, heartbeating over disk, selective fallover upon volume group loss and other. These functions of HACMP utilize the AIX 5L LVM capabilities, and since OEM volume groups and filesystems do not use AIX 5L LVM, HACMP does not support these functions for OEM volume groups.
HACMP’s mechanism for fast disk takeover cannot be utilized for mixed physical volumes, that is, for disks comprised of both IBM and non-IBM disks. The LVM enhanced concurrent mode capabilities of AIX 5L are used to enable fast disk takeover—only LVM supported disks can be used with enhanced concurrent mode and the Fast Disk Takeover feature. The Automatic Error Notification methods available in AIX 5L cannot be configured in HACMP for OEM volume groups and filesystems. You can have sites defined in the cluster, but you cannot configure and use HACMP/XD replicated resources (with the use of PPRC or Geographic LVM) in the cluster that utilizes OEM volume groups. The inter-site management policy for resource groups should be set to Ignore. HACMP does not support the LVM cross-site mirroring function for resource groups with OEM volume groups and filesystems. Software Requirements
HACMP supports Veritas volume groups in AIX 5L v.5.2 (depending on the version level supported by VFS 4.0).
Supporting Veritas Volume Groups
Among other OEM volume groups and filesystems, HACMP 5.4 supports volume groups and filesystems created with VxVM in Veritas Foundation Suite v.4.0.
To make it easier for you to accommodate Veritas volume groups in the HACMP cluster, the methods for Veritas volume groups support are predefined in HACMP and are used automatically. After you add Veritas volume groups to HACMP resource groups, you can select the methods for the volume groups from the picklists in HACMP SMIT menus for OEM volume groups support.
Note: After you configure Veritas volume groups or filesystems in HACMP cluster, the HACMP cluster verification utility runs the associated Veritas verification check. This verification check is effective only for the volume groups or filesystems that are currently online on the node on which the verification is being run.
Configuring OEM Volume Groups Methods in SMIT
You can add, change, and remove custom volume groups processing methods for a specific OEM volume group using SMIT. You can select existing custom volume group methods that are supported by HACMP, or you can use your own custom methods.
You can add, change, and remove the methods that HACMP will use to manage OEM volume groups.
See these sections:
Adding Custom Volume Group Methods
To add a custom volume group method:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Extended Resource Configuration > HACMP Extended Resources Configuration > Configure Custom Volume Group Methods > Add Custom Volume Group Methods and press Enter.
Note: If you are configuring Veritas volume groups, perform this operation in SMIT on the same node on which the volume group is currently active.
3. Enter field values that define the volume group processing methods you want to specify for the particular OEM volume group:
Note: The custom volume group processing method that you specify for a particular OEM volume group is added to the local node only. This information is not propagated to other nodes; you must copy this custom volume group processing method to each node manually. Alternatively, you can use the HACMP File Collections facility to make the disk, volume, and filesystem methods available on all nodes.
Once you have made the selections, the information is applied to the volume groups on the local node.
4. Configure the same custom volume group type on other nodes in the cluster and synchronize the cluster resources. You may configure it manually or use the HACMP File Collections facility. The cluster verification process ensures that the type that you configured exists and is executable on all nodes. HACMP also verifies the root user permissions for the type and methods you specified, and the fact that the methods do not reside on a shared physical volume. The synchronization process ensures that the entries in the HACMP configuration database are the same on all nodes and synchronizes the methods named in the HACMP File Collections. HACMP runs the specific verification checks for the OEM-type volume groups only if they are configured in the cluster.
Note: After you configure Veritas volume groups or filesystems in HACMP cluster, the HACMP cluster verification utility runs the associated Veritas verification check. This verification check is effective only for the volume groups or filesystems that are currently online on the node on which the verification is being run.
Changing Custom Volume Group Methods
To change a custom volume group method:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Extended Resource Configuration > HACMP Extended Resources Configuration > Configure Custom Volume Group Methods > Change/Show Custom Volume Group Methods and press Enter.
SMIT displays a picklist containing the names of the specified volume group processing types (or methods).
3. Select a name of a particular volume group type and press Enter. SMIT displays the current information.
4. Enter new information in the fields you want to change and press Enter.
Note: Unless you use the HACMP File Collections facility, the method’s characteristics are changed on the local node, but they are not updated on remote nodes. Manually update the custom volume group method on other nodes in the cluster.
Removing Custom Volume Group Methods
To remove a custom volume method:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Extended Resource Configuration > HACMP Extended Resources Configuration > Configure Custom Volume Group Methods > Remove Custom Volume Group Methods.
SMIT displays a picklist with the names of the specified volume group types (or processing methods).
3. Select a type or method you want to remove and press Enter. SMIT prompts you to confirm your selection. If you choose to continue, HACMP will delete the corresponding entry.
Note: Unless you use the HACMP File Collections facility, HACMP deletes the characteristics of the volume group types or methods on the local node but does not update them on remote nodes. Manually delete custom types or methods on other nodes in the cluster.
Integrating OEM Filesystems in an HACMP Cluster
You can configure OEM filesystems in AIX 5L and use HACMP as an IBM High Availability solution to manage such volume groups, their corresponding filesystems, and application servers. (Applications servers are defined as start and stop scripts for the applications supported by the volume groups).
This section contains the following topics:
Overview
Depending on the type of OEM volume, custom methods in HACMP allow you (or an OEM vendor) to tell HACMP that a filesystem unknown to AIX 5L LVM should be treated the same way as a known and supported filesystem to specify the custom methods that provide the filesystems processing functions supported by HACMP.
You can either use custom methods for filesystems offered by HACMP, or create your own custom methods to use for the non-IBM filesystems in the cluster. These functions are performed within the normal HACMP event processing.
In particular, HACMP 5.4 automatically detects and provides the methods for filesystems created with Veritas Filesystem (VxFS) using Veritas Foundation Suite v. 4.0.
OEM Filesystems Functions Performed by HACMP
When HACMP identifies OEM filesystems of a particular type, it provides the following processing functions for them or lets you specify your own custom methods for any one of these functions:
Determine a list of filesystems belonging to a specified type of volume group. List volume groups hosting a specified filesystem. Bring the filesystem online and offline. Determine the filesystem status. Verify the filesystems configuration. Provide the pathnames to the filesystems log files, for troubleshooting purposes. OEM Volume Groups and Filesystems as Resources in an HACMP Resource Group
You can include OEM disks, volume groups, and filesystems in an HACMP resource group. HACMP recognizes OEM volume groups and filesystems and handles them as the AIX 5L LVM volume groups and filesystems by listing, activating, checking and taking them offline when it is necessary for the cluster event processing tasks.
You can mix the OEM disks, volume groups and filesystems with AIX 5L volume groups and filesystems in a single HACMP resource group.
When you include OEM or Veritas volume groups or filesystems into HACMP resource groups, Automatically Import Volume Groups field should be set to false. Also OEM volume groups should be set to not automatically varyon when the node is restarted; OEM filesystems should be set to not automatically mount when the node is restarted.
To view OEM disks, volume groups and filesystems used in the HACMP cluster, you can use the HACMP SMIT interface.
Prerequisites
In order for HACMP to handle OEM volume groups and filesystems in your configuration, the volume groups and filesystems must adhere to these conditions:
Each OEM volume is composed of one or more physical disks (equivalent to hdisks in AIX 5L) and the system can determine the names of the physical disks from the name of the volume. OEM disks, volume groups, and filesystems must have operations and sequences of operations comparable to the functions of AIX 5L LVM, although the command names, syntax, and arguments may differ. Limitations
HACMP identifies OEM volume groups and filesystems and performs all major functions with them. See OEM Volume Group Functions Performed by HACMP and OEM Filesystems Functions Performed by HACMP.
However, some of the HACMP functions have limitations for OEM volume groups and filesystems:
You cannot use C-SPOC (Cluster Single Point of Control) to manage OEM disk, volume, and filesystems operations. HACMP does not automatically discover OEM volume groups and filesystems and does not list them for your selections in picklists in SMIT. HACMP does not use NFS (Network Filesystem) functions for OEM filesystems. HACMP does not provide a workaround for any limitations of OEM disks, volume groups, and filesystems that exist outside of HACMP. In addition to listing, varying on and off, and verifying volume groups and filesystems created with the AIX 5L LVM, HACMP supports other extended functions for its “own” volume groups and filesystems, such as enhanced concurrent mode, active and passive varyon process, disk heartbeating and selective fallover upon volume group loss and other. These functions of HACMP utilize the AIX 5L LVM capabilities, and since OEM volume groups and filesystems do not use AIX 5L LVM, HACMP does not support these functions for OEM volume groups.
The Automatic Error Notification methods available in AIX 5L cannot be configured in HACMP for OEM volume groups and filesystems. You can have sites defined in the cluster, but you cannot configure and use HACMP/XD replicated resources (with the use of PPRC or Geographic LVM) in the cluster that utilizes OEM volume groups. The inter-site management policy for resource groups should be set to Ignore. HACMP does not support the LVM cross-site mirroring function for resource groups with OEM volume groups and filesystems. The HACMP’s mechanism for fast disk takeover cannot be utilized for mixed physical volumes, that is, for disks comprised of both IBM and non-IBM disks. The LVM enhanced concurrent mode capabilities of AIX 5L are used to enable fast disk takeover—only LVM supported disks can be used with enhanced concurrent mode and the Fast Disk Takeover feature. HACMP uses its serial method of processing resource groups if they contain OEM volume groups or filesystems. Software Requirements
HACMP 5.4 supports Veritas volume groups in the following software environment:
AIX 5L v.5.2 (depending on the version level supported by VFS 4.0). Supporting Veritas Filesystems
Among other OEM volume groups and filesystems, HACMP 5.4 supports volume groups and filesystems created with VxVM in Veritas Foundation Suite v.4.0.
To make it easier for you to accommodate Veritas filesystems in the HACMP cluster, the methods for Veritas filesystems support are predefined in HACMP. After you add Veritas filesystems to HACMP resource groups, you can select the methods for the filesystems from the picklists in HACMP SMIT menus for OEM filesystems support.
Note: After you configure Veritas volume groups or filesystems in HACMP cluster, the HACMP cluster verification utility runs the associated Veritas verification check. This verification check is effective only for the volume groups or filesystems that are currently online on the node on which the verification is being run.
Configuring OEM Filesystems Methods in SMIT
You can add, change, and remove custom filesystems processing methods for a specific OEM filesystem using SMIT. You can select existing custom filesystems methods that are supported by HACMP, or you can use your own custom methods.
See these sections:
Adding Custom Filesystems Methods
To add a custom filesystem method:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Extended Resource Configuration > HACMP Extended Resources Configuration > Configure Custom Filesystems Methods > Add Custom Filesystem Methods and press Enter.
Note: If you are configuring Veritas filesystems, perform this operation in SMIT on the same node on which the filesystem is currently active.
3. Enter field values that define the filesystem processing methods you want to specify for the particular OEM filesystem type:
Note: The custom filesystem processing method or custom filesystem type is added to the local node only. This information is not propagated to other nodes; you copy this method or type to each node manually. Alternatively, you can use the HACMP File Collections facility to make the disk, volume, and filesystem methods available on all nodes.
4. Configure the same custom filesystems processing method on other nodes in the cluster and synchronize the cluster resources. The cluster verification process ensures that the method (or the filesystem type) that you configured exists and is executable on all nodes. HACMP also verifies the root user permissions for the methods you specified, and the fact that the methods do not reside on a shared physical volume. The synchronization process ensures that the entries in the HACMP configuration database are the same on all nodes and synchronizes the methods named in the HACMP File Collections.
Note: After you configure Veritas volume groups or filesystems in HACMP cluster, the HACMP cluster verification utility runs the associated Veritas verification check. This verification check is effective only for the volume groups or filesystems that are currently online on the node on which the verification is being run.
Changing Custom Filesystems Methods
To change a custom filesystem method:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Extended Resource Configuration > HACMP Extended Resources Configuration > Configure Custom Filesystem Methods > Change/Show Custom Filesystems Methods and press Enter.
3. Select a name of a particular filesystem method (or type) and press Enter. SMIT displays the current information.
4. Enter new information in the fields you want to change and press Enter.
Note: Unless you use the HACMP File Collections facility, the type or method characteristics are changed on the local node but they are not updated on remote nodes. Manually update the custom methods or types on other nodes in the cluster.
Removing Custom Filesystems Methods
To remove a custom filesystem method:
1. Enter smit hacmp
2. In SMIT, select Extended Configuration > Extended Resource Configuration > HACMP Extended Resources Configuration > Configure Custom Filesystem Methods > Remove Custom Filesystem Methods and press Enter.
3. Select the filesystem type or method you want to remove, and press Enter. SMIT prompts you to confirm your selection. If you choose to continue, HACMP will delete the corresponding entry.
Note: Unless you use the HACMP File Collections facility, HACMP deletes the characteristics of the types or methods on the local node but does not update them on remote nodes. Manually delete custom types or methods on other nodes in the cluster.
![]() ![]() ![]() |