![]() ![]() ![]() |
Chapter 4: HACMP Cluster Hardware and Software
This chapter describes:
The IBM hardware that is used with HACMP and implements the base level of a highly available environment. The following IBM hardware is used with HACMP:
Nodes Disks subsystems Networks Ethernet, Token-Ring, ATM, SP Switch, and other networks. For information on administering particular types of networks, see the Installation Guide.For detailed information, follow the links in the preceding table, or see the section Enhancing Availability with IBM Hardware.
Other sections in this chapter are:
Enhancing Availability with IBM Hardware
Building a highly available cluster begins with reliable hardware. Within the AIX 5L environment, the IBM eServer pSeries family of machines as well as the SP and its supported disk subsystems provide a robust, stable platform for building highly available clusters.
IBM pSeries
Some IBM pSeries servers, such as the 690 (Regatta), let you configure multiple logical partitions that can be used as separate nodes. The pSeries 690 delivers true logical partitioning (LPAR). Each system can be divided into as many as 16 virtual servers, each with its own set of system resources such as processors, memory and I/O. Unlike partitioning techniques available on other UNIX servers, LPAR provides greater flexibility in matching resources to workloads. Based on business requirements, these resources can be allocated or combined for business-critical applications resulting in more efficient use of the system.
With the IBM eServer Cluster 1600 and AIX 5L operating system, you can mix or match up to 128 units (512 via special order) including up to 32 pSeries 690 systems. An LPAR of a pSeries 690 is viewed by a Cluster 1600 as just another node or server in the cluster. Up to 16 LPARs per system and up to 128 LPARs per cluster are supported on pSeries 690. Up to 4 LPARs per system are supported on pSeries 650, and up to 2 LPARs are supported on pSeries 630.
HACMP now supports the following:
Micro-partioning under AIX 5L 5.3 on Power5 systems IBM 2 Gigabit Fibre Channel PCI-X Storage Adapter. IBM eServer p5 models 510, 520, 550, and 570
HACMP supports the new POWER5 -based IBM eServer p5 servers running AIX 5L v.5.2 and up. The eServer p5 Express family uses the IBM POWER5™ microprocessor. The POWER5 processor can run both 32- and 64-bit applications simultaneously.
The optional IBM Virtualization Engine™ systems technologies feature provides innovations like Micro-Partitioning™ that allow the system to be finely tuned to consolidate multiple independent applications. Virtual systems can be defined as small as 1/10th of a processor and changed in increments as small as 1/100th of a processor.
IBM eServer p5 model 575
HACMP supports the IBM p5-575 (9118-575) high-bandwidth cluster node with applicable APARs.
The IBM p5 575 delivers an 8-way, 1.9 GHz POWER5 high-bandwidth cluster node, ideal for many high-performance computing applications.
IBM eServer p5 models 590 and 595
HACMP 5.2 and above support the IBM eServer p5-590 and IBM eServer p5 595. The p5 590 and p5-595 servers are powered by the IBM 64-bit Power Architecture™ microprocessor—the IBM POWER5™ microprocessor—with simultaneous multi-threading that makes each processor function as two to the operating system.
The p5-595 features a choice of IBM’s fastest POWER5 processors running at 1.90 GHz or 1.65 GHz, while the p5-590 offers 1.65 GHz processors.
IBM eServer i5 models 520, 550 and 570 iSeries and pSeries Convergence
HACMP supports the IBM eServer i5, which is a new hardware platform of iSeries and pSeries convergence. You can run native AIX 5L v.5.2 or v.5.3 with its own kernel (versus current PASE's SLIC kernel) in an LPAR partition. This is an excellent way to consolidate AIX 5L applications and other UNIX-based applications, running in a separate pSeries box or other UNIX box, onto a single i5 platform.
You can run AIX 5L on i5 in logical partitions allowing you to optimize your investments: Share processor and memory resources, move resources to where they are needed, exploit i5/OS storage subsystem, and leverage skills and best practices.
RS/6000 SP System
The SP is a parallel processing machine that includes from two to 128 processors connected by a high-performance switch. The SP leverages the outstanding reliability provided by the RS/6000 series by including many standard RS/6000 hardware components in its design. The SP’s architecture then extends this reliability by enabling processing to continue following the failure of certain components. This architecture allows a failed node to be repaired while processing continues on the healthy nodes. You can even plan and make hardware and software changes to an individual node while other nodes continue processing.
Disk Subsystems
The disk subsystems most often shared as external disk storage in cluster configurations are:
SCSI disks. See Appendix B on OEM disks in the Installation Guide for information on installing and configuring OEM disks.
For complete information on IBM Storage Solutions, see URL: http://www.storage.ibm.com
IBM Serial Storage Architecture Disk Subsystem
You can use IBM 7133 and 7131-405 SSA disk subsystems as shared external disk storage devices in an HACMP cluster configuration.
If you include SSA disks in a volume group that uses LVM mirroring, you can replace a failed drive without powering off the entire subsystem.
IBM 2105 Enterprise Storage Server
IBM 2105 Enterprise Storage Server provides multiple concurrent attachment and sharing of disk storage for a variety of open systems servers. IBM eServer pSeries processors can be attached, as well as other UNIX and non-UNIX platforms. Attachment methods include Fibre Channel and SCSI.
The ESS uses IBM SSA disk technology (internally). ESS provides many availability features. RAID technology protects storage. RAID-5 techniques can be used to distribute parity across all disks in the array. Sparing is a function that allows you to assign a disk drive as a spare for availability. Predictive Failure Analysis techniques are utilized to predict errors before they affect data availability. Failover Protection enables one partition, or storage cluster, of the ESS to take over for the other so that data access can continue.
The ESS includes other features such as a web-based management interface, dynamic storage allocation, and remote services support. For more information on ESS planning, general reference material, and attachment diagrams, see URL: http://www.storage.ibm.com/disk/ess
IBM 2104 Expandable Storage Plus
The IBM 2104 Expandable Storage Plus (EXP Plus) provides flexible, scalable, and low-cost disk storage for RS/6000 and pSeries servers in a compact package. This new disk enclosure is ideal for enterprises—such as Internet or application service providers—that need high-performance external disk storage in a small footprint.
Scales from up to 2055 GB of capacity per drawer or tower to more than 28 TB per rack Shared storage for all major types of servers Single or split-bus configuration flexibility to one or two servers High-performance Ultra3 SCSI disk storage with 160 MB/sec throughput Up to fourteen 10,000 RPM disk drives, with capacities of 9.1 GB, 18.2GB, 36.4 GB and 73.4GB and 146.8GB High availability to safeguard data access Scalability for fast-growing environments. IBM TotalStorage DS8000 and DS6000 Storage Devices
HACMP supports the IBM TotalStorage DS8000 and DS6000 Series Disk Storage Devices with applicable APARs.
The DS8000 series incorporates IBM's POWER5 processor technology to provide functionality, flexibility, and performance for enterprise disk storage systems at improved levels of cost effectiveness while the DS6000 series brings this level of enterprise-class technology into a modular package.
IBM TotalStorage DS4000 Storage Servers
The DS4000 series (formerly named the FAStT series) has been enhanced to complement the entry and enterprise disk system offerings with DS4000 Storage Manager V9.10, enhanced remote mirror option, DS4100 Midrange Disk System (formerly named TotalStorage FAStT100 Storage Server, model 1724-100) for larger capacity configurations, and EXP100 serial ATA expansion units attached to DS4400s.
The IBM TotalStorage DS4300 (formerly FAStT600) is a mid-level disk system that can scale to over eight terabytes of fibre channel disk using three EXP700s, over sixteen terabytes of fibre channel disk with the Turbo feature using seven EXP700s. It uses the latest in storage networking technology to provide an end-to-end 2 Gbps Fibre Channel solution.
IBM DS4400 Storage Server (formerly FAStT700) delivers superior performance with 2 Gbps Fibre Channel technology. The DS4400 is designed to offer investment protection with advanced functions and flexible features. It scales from 36GB to over 32TB to support growing storage requirements created by e-business applications. DS4400 offers advanced replication services to support business continuance.
IBM DS4500 (formerly FAStT900) delivers offers up to 67.2TB of fibre channel disk storage capacity with 16 EXP700s or 16 EXP710s. DS4500 offers advanced replication services to support business continuance and disaster recovery.
The IBM System Storage DS4800 is designed with 4 gigabit per second Fibre Channel interface technology that can support up to 224 disk drives in IBM System Storage EXP810, EXP710, EXP700, or EXP100 disk units. Additionally, the DS4800 supports high-performance Fibre Channel and high-capacity serial ATA (SATA) disk drives.
For complete information about IBM Storage Solutions, see the following URL:
HACMP Required and Supported Hardware
For a complete list of required and supported hardware, see the sales guide for the product. You can locate this document from the following URL:
After selecting your country and language, select HW and SW Desc (SalesManual, RPQ) for a Specific Information Search.
HACMP Cluster Software
This section describes the HACMP software that implements a highly available environment.
It contains the following subsections:
Software Components of an HACMP Node
The following figure shows the layers of software on a node in an HACMP cluster:
The following list describes each layer:
Application layer. Any applications made highly available through services provided by HACMP for AIX 5L. HACMP for AIX 5L layer. Software that recognizes changes within a cluster and coordinates the use of AIX 5L features to create a highly available environment for critical data and applications. HACMP complements lower layers by providing additional services to enable applications with their associated communications, and data storage services to be highly available. RSCT layer. The IBM Reliable Scalable Cluster Technology services previously packaged with HACMP/ES (prior to HACMP v 5.1) are now packaged with AIX 5L. The RSCT layer provides facilities for monitoring node membership; network interface and communication interface health; event notification, synchronization and coordination via reliable messaging, in distributed or cluster environments. RSCT includes the Resource Monitoring and Control (RMC), Group Services, and Topology Services components. For more information, see the section IBM Reliable Scalable Cluster Technology Availability Services in this chapter and the RSCT documentation. AIX 5L layer. Software that provides the underlying support for an HACMP cluster, including: Logical Volume Manager (LVM) subsystem layer, which manages data storage at the logical level. TCP/IP subsystem layer, which provides communications support for an HACMP cluster. HACMP Software Components
The HACMP software has the following components:
Cluster Manager
Changes in the state of the cluster are referred to as cluster events. On each node, the Cluster Manager monitors local hardware and software subsystems for these events, such as an application failure event. In response to such events, the Cluster Manager runs one or more event scripts, such as a restart application script. Cluster Managers on all nodes exchange messages to coordinate any actions required in response to an event.
The Cluster Manager is a daemon that runs on each cluster node. The main task of the Cluster Manager is to respond to unplanned events, such as recovering from software and hardware failures, or user-initiated events, such as a joining node event. The RSCT subsystem informs the Cluster Manager about node and network-related events.
Beginning with HACMP 5.3, the Cluster Manager starts and runs independently of the RSCT stack and therefore starts and runs immediately after installation. The HACMP MIB is accessible as soon as the system comes up, even without a configured cluster. When started, the Cluster Manager responds to SNMP (Simple Network Monitoring Control) requests; however, until a full configuration is read, only a subset of MIB variables is available.
Note: In HACMP clusters, the RSCT software components—Group Services, Resource Monitoring and Control (RMC), and Topology Services—are responsible for most of the cluster monitoring tasks. For more information, see the RSCT documentation. For information on the architecture of the HACMP 5.4 (which includes the Enhanced Scalability functionality) product system, see the diagram in the section IBM Reliable Scalable Cluster Technology Availability Services.
Cluster Manager Connection to Other HACMP Daemons
The Cluster Manager gathers information relative to cluster state changes of nodes and interfaces. The Cluster Information Program (Clinfo) gets this information from the Cluster Manager and allows clients communicating with Clinfo to be aware of a cluster’s state changes. This cluster state information is stored in the HACMP Management Information Base (MIB).
If your system is running TME 10 NetView, the connection to the Cluster Manager also allows the HAView utility to obtain cluster state information and to display it graphically through the NetView map. See Chapter 7: HACMP Configuration Process and Facilities, for information about how HAView communicates with the Cluster Manager.
Cluster Secure Communication Subsystem
HACMP has a common communication infrastructure increases the security of intersystem communication. Cluster utilities use the Cluster Communications daemon that runs on each node for communication between the nodes. Because there is only one common communications path, all communications are reliably secured.
Although most components communicate through the Cluster Communications daemon, the following components use another mechanism for inter-node communications:
Component Communication Method Cluster Manager RSCT Heartbeat messaging RSCT Cluster Information Program (Clinfo) SNMP
For users who require additional security, HACMP 5.2 and up provides message authentication and encryption for messages sent between cluster nodes.
Note: HACMP 5.4 integrates the functionality of the SMUX Peer daemon (clsmuxpd) into the Cluster Manager. This integrated function eliminates the clsmuxpd daemon.
Connection Authentication
HACMP provides two modes for connection authentication:
Standard. Standard security mode checks the source IP address against an access list, checks that the value of the source port is between 571 and 1023, and uses the principle of least-privilege for remote command execution. Standard security is the default security mode. Kerberos. Kerberos security mode uses Kerberos security for authentication. Kerberos security is available only on systems running the PSSP software (SP or IBM eServer Cluster 1600). For added security, you can set up a VPN for connections between nodes for HACMP inter-node communications.
Message Authentication and Encryption
Message authentication and message encryption provide additional security for HACMP messages sent between cluster nodes. Message authentication ensures the origination and integrity of a message. Message encryption changes the appearance of the data as it is transmitted and translates it to its original form when received by a node that authenticates the message.
You can configure the security options and options for distributing encryption keys using the SMIT interface.
IBM Reliable Scalable Cluster Technology Availability Services
The IBM Reliable Scalable Cluster Technology (RSCT) high availability services provide greater scalability, notify distributed subsystems of software failure, and coordinate recovery and synchronization among all subsystems in the software stack.
RSCT handles the heartbeats and network failure detection. The HACMP and RSCT software stack runs on each cluster node.
The HACMP Cluster Manager obtains indications of possible failures from several sources:
RSCT monitors the state of the network devices AIX 5L LVM monitors the state of the volume groups and disks Application monitors monitor the state of the applications. The HACMP Cluster Manager drives the cluster recovery actions in the event of a component failure. RSCT running on each node exchanges a heartbeat with its peers so that it can monitor the availability of the other nodes in the cluster. If the heartbeat stops, the peer systems drive the recovery process. The peers take the necessary actions to get the critical applications running and to ensure that data has not been corrupted or lost.
RSCT services include the following components:
Resource Monitoring and Control (previous versions of HACMP use the Event Management subsystem). A distributed subsystem providing a set of high availability services. It creates events by matching information about the state of system resources with information about resource conditions of interest to client programs. Client programs in turn can use event notifications to trigger recovery from system failures. Group Services. A system-wide, highly available facility for coordinating and monitoring changes to the state of an application running on a set of nodes. Group Services helps in both the design and implementation of highly available applications and in the consistent recovery of multiple applications. It accomplishes these two distinct tasks in an integrated framework. Topology Services. A facility for generating heartbeats over multiple networks and for providing information about network interface membership, node membership, and routing. Network interface and node membership provide indication of NIC and node failures respectively. Reliable Messaging uses the routing information to route messages between nodes around adapter failures. For more information on these services, see the following URL:
http://www.ibm.com/servers/eserver/pseries/library/clusters/aix.html
The following figure shows the main components that make up the HACMP architecture:
HACMP Comprises IBM RSCT Availability Services and the HA Recovery Driver
Cluster Manager and SNMP Monitoring Programs
An HACMP cluster is dynamic and can undergo various transitions in its state over time. For example, a node can join or leave the cluster, or another IP label can replace a service IP label on a physical network interface card. Each of these changes affects the composition of the cluster, especially when highly available clients and applications must use services provided by cluster nodes.
SNMP Support
The Cluster Manager provides Simple Network Management Protocol (SNMP) support to client applications. SNMP is an industry-standard specification for monitoring and managing TCP/IP-based networks. SNMP includes a protocol, a database specification, and a set of data objects. This set of data objects forms a Management Information Base (MIB). SNMP provides a standard MIB that includes information such as IP addresses and the number of active TCP connections. The standard SNMP agent is the snmpd daemon.
You can extend SNMP to include enterprise-specific MIBs that contain information relating to a discrete environment or application. In HACMP, the Cluster Manager maintains information about the objects defined in its MIB and passes this information on to a specialized network monitoring or network management station.
HACMP MIB
The Cluster Manager maintains cluster status information in a special HACMP MIB. When the Cluster Manager starts on a cluster node, it registers with the SNMP daemon snmpd, and then continually gathers cluster information. The Cluster Manager maintains an updated topology of the cluster in the HACMP MIB as it tracks events and the resulting states of the cluster. For more information on the HACMP MIB, see the Programming Client Applications Guide.
Cluster Information Program
The Cluster Information Program (Clinfo), the clinfo daemon, is an SNMP-based monitor. Clinfo, running on a client machine or on a cluster node, queries the MIB for updated cluster information. Through Clinfo, information about the state of an HACMP cluster, nodes, and networks can be made available to clients and applications.
Clients can be divided into two categories: naive and intelligent.
A naive client views the cluster complex as a single entity. If a cluster node fails, the client must be restarted (or at least must reconnect to the node), if IP address takeover (IPAT) is not enabled. An intelligent client, on the other hand, is cluster-aware—it reacts appropriately to node failure, connecting to an alternate node and perhaps masking the failure from the user. Such an intelligent client must have knowledge of the cluster state. Note: For conceptual information about IP address takeover, see Chapter 2: HACMP Cluster Nodes, Sites, Networks, and Heartbeating.
The HACMP software extends the benefits of highly available servers, data, and applications to clients by providing notification of cluster state changes to clients through the Cluster Manager and Clinfo API functions. See Chapter 1: Cluster Information Program in the Programming Client Applications Guide for more information on Clinfo.
Responding to Cluster Changes
Clinfo calls the /usr/es/sbin/cluster/etc/clinfo.rc script whenever a cluster, network, or node event occurs. By default, the clinfo.rc script flushes the system’s ARP cache to reflect changes to network IP addresses, and it does not update the cache until another address responds to a ping request. Flushing the ARP cache typically is not necessary if the HACMP hardware address swapping facility is enabled because hardware address swapping maintains the relationship between an IP address and a hardware address. Hardware address swapping is described in more detail in Chapter 5: Ensuring Application Availability.
In a switched Ethernet network, you may need to flush the ARP cache to ensure that the new MAC address is communicated to the switch, or use the procedure described in the Troubleshooting Guide to ensure that the hardware address is communicated correctly. (See “MAC Address Is Not Communicated to the Ethernet Switch” in Chapter 4 of the Troubleshooting Guide.
You can add logic to the clinfo.rc script if further action is desired.
Clinfo APIs
The Clinfo APIs provide application developers with both a C and a C++ language interface for accessing cluster status information. The HACMP software includes two versions of the Clinfo APIs: one for single-threaded applications and one for multi-threaded applications.
Clinfo and its associated APIs enable developers to write applications that recognize and respond to changes in a cluster. For more information, see the Programming Client Applications Guide.
Highly Available NFS Server
The highly available NFS server functionality is included in the HACMP product subsystem. A highly available NFS server allows a backup processor to recover current NFS activity should the primary NFS server fail. The NFS server special functionality includes highly available modifications and locks on network filesystems (NFS). You can do the following:
Use the reliable NFS server capability that preserves locks and dupcache (2-node clusters only) Specify a network for NFS cross-mounting Define NFS exports and cross-mounts at the directory level Specify export options for NFS-exported directories and filesystems Configure two nodes to use NFS. Note: While HACMP clusters can contain up to 32 nodes, clusters that use NFS can have a maximum of two nodes.
Shared External Disk Access
The HACMP software supports two methods of shared external disk access: non-concurrent and concurrent. Both methods of shared external disk access are described in the following sections.
Non-Concurrent Shared External Disk Access
In a non-concurrent environment, only one node has access to a shared external disk at a given time. If this node fails, one of the peer nodes acquires the disk, mounts filesystems defined as resources, and restarts applications to restore critical services. Typically, this takes from 30 to 300 seconds, depending on the number and size of the filesystems.
A non-concurrent configuration can use:
SCSI disks SCSI disk arrays serial disks SSA disks as shared external disks Fibre Channel direct-attached disks Fibre Channel SAN-attached disks. For more information about supported devices, see the section Disk Subsystems in this chapter.
To prevent a failed disk from becoming a single point of failure, each logical volume in a shared volume group should be mirrored using the AIX 5L LVM facility. If you are using an IBM Enterprise Storage System or other supported RAID array, do not use LVM mirroring. RAID devices provide their own data redundancy.
Most software that can run in single-machine mode can be managed by the HACMP software without modification.
Non-concurrent access typically does not require any code changes to server programs (a database management system, for example), or to applications to provide a highly available solution. To end users, node failure looks like a very fast machine reboot. One of the surviving nodes takes ownership of the failed node’s resource groups and restarts the highly available applications. The Journaled Filesystem, the native AIX 5L filesystem, guarantees filesystem integrity. The server program guarantees transaction data integrity.
End users simply log onto one of the surviving nodes and restart the application. The logon and application restart procedures can be driven by the HACMP software. In some HACMP configurations, users can continue without having to take any action—they simply experience a delay during fallover.
Concurrent Shared External Disk Access
Note: For information on enhanced concurrent access, see the section Enhanced Concurrent Mode in this chapter.
The concurrent access feature enhances the benefits provided by an HACMP cluster. Concurrent access allows simultaneous access to a volume group on a disk subsystem attached to multiple (up to 32) nodes. Using concurrent access, a cluster can offer nearly continuous availability of data that rivals fault tolerance, but at a much lower cost. Additionally, concurrent access provides higher performance, eases application development, and allows horizontal growth.
Since concurrent access provides simultaneous access to data from multiple nodes, additional tools may be required to prevent multiple nodes from modifying the same block of data in a conflicting way. The HACMP software provides the Clinfo program that prepares an application to run in a concurrent access environment. The Clinfo API provides an API through which applications may become "cluster-aware". The Clinfo tool is described earlier in this chapter.
The benefits of concurrent shared external disk access include the following:
Transparent Recovery Increases Availability. Concurrent access significantly reduces the time for a fallover—sometimes to just a few seconds—because the peer systems already have physical access to the shared disk and are running their own instances of the application. In a concurrent access environment, fallover basically involves backing out in-flight transactions from the failed processor. The server software running on the surviving nodes is responsible for recovering any partial transactions caused by the crash.
Since all nodes have concurrent access to the data, a client/server application can immediately retry a failed request on the surviving nodes, which continue to process incoming transactions.
Harnessing Multiple Processors Increases Throughput. Applications are no longer limited to the throughput of a single processor. Instead, multiple instances of an application can run simultaneously on multiple processors. As more processing power is required, more systems can be added to the cluster to increase throughput. Single Database Image Eases Application Development and Maintenance. In a non-concurrent environment, the only route to improving performance is to partition an application and its data. Breaking code and data into pieces makes both application development and maintenance more complex. Splitting a database requires a high degree of expertise to make sure that the data and workload are evenly distributed among the processors.
Partitioning code and data is not necessary in a concurrent access environment. To increase throughput, multiple instances of the same application running on different processors can simultaneously access a database on a shared external disk.
A concurrent configuration can use:
SCSI disks SCSI disk arrays serial disks SSA disks as shared external disks Fibre Channel direct-attached disks Fibre Channel SAN-attached disks. For more information about supported devices, see the section Disk Subsystems in this chapter.
When creating concurrent access logical volumes, use LVM mirroring to avoid having the disks be a single point of failure, except for RAID disk subsystems that supply their own mirroring.
Concurrent access does not support the use of the Journaled Filesystem. Therefore, the database manager must write directly to the raw logical volumes or hdisks in the shared volume group.
An application must use some method to arbitrate all requests for shared data. Most commercial UNIX databases provide a locking model that makes them compatible with the HACMP software. Check with your database vendor to determine whether a specific application supports concurrent access processing.
Concurrent Resource Manager
The Concurrent Resource Manager of HACMP provides concurrent access to shared disks in a highly available cluster, allowing tailored actions to be taken during takeover to suit business needs.
Concurrent Resource Manager adds enhanced-concurrent support for shared volume groups on all types of disks, and concurrent shared-access management for supported RAID and SSA disk subsystems.
Enhanced Concurrent Mode
AIX 5L provides a new form of concurrent mode: enhanced concurrent mode. In enhanced concurrent mode, the 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. Support for enhanced concurrent mode and prior concurrent mode capabilities has the following differences:
Any disk supported by HACMP for attachment to multiple nodes can be included in an enhanced concurrent mode volume group; the special facilities of SSA disks are not required. 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. Keep in mind the following when planning an HACMP environment:
When concurrent volume groups are created on AIX 5L, they are created as enhanced concurrent mode volume groups by default. SSA concurrent mode is not supported by AIX 5L v.5.3. You must convert them to enhanced concurrent mode. If one node in a concurrent resource group runs a 64-bit kernel, then it must use an enhanced concurrent mode volume group. SSA concurrent mode is not supported on 64-bit kernels. SSA disks with the 32-bit kernel can use SSA concurrent mode. The C-SPOC utility does not work with RAID concurrent volume groups. You need to convert them to enhanced concurrent mode (otherwise, AIX 5L sees them as non-concurrent). The C-SPOC utility does not allow you to create new SSA concurrent mode volume groups on either AIX 5L v.5.2 or 5.3. (If you upgraded from previous releases of HACMP, you can use existing volume groups in SSA concurrent mode, but C-SPOC does not allow you to create new groups of this type.) You can convert these volume groups to enhanced concurrent mode. If you are running AIX 5L v.5.3, you must convert all volume groups to enhanced concurrent mode. You can include enhanced concurrent mode volume groups into shared resource groups. HACMP lists them in volume group picklists in resource group configuration SMIT panels. When enhanced concurrent volume groups are used in a non-concurrent environment, the volume groups are not concurrently accessed, they are still accessed by only one node at any given time. You can turn volume groups that are enhanced concurrent into geographically mirrored volume groups, if you have installed HACMP/XD for GLVM. For information, see Sites in Chapter 2: HACMP Cluster Nodes, Sites, Networks, and Heartbeating. Fast Disk Takeover
Failed volume groups are taken over faster than in previous releases of HACMP due to the improved disk takeover mechanism. If you have installed AIX 5L v. 5.2 or 5.3 and HACMP, and if you include in your non-concurrent resource groups enhanced concurrent mode volume groups, HACMP automatically detects these volume groups, and ensures that the faster option for volume group takeover is launched in the event of a node failure.
This functionality is especially useful for fallover of volume groups made up of a large number of disks.
Note: Fast disk takeover is not used in clusters with HACMP/XD for GLVM, if you use enhanced concurrent mode volume groups as geographically mirrored volume groups.
During fast disk takeover, HACMP skips the extra processing needed to break the disk reserves, or update and synchronize the LVM information by running lazy update. As a result, the disk takeover mechanism used for enhanced concurrent volume groups is faster than disk takeover used for standard volume groups.
In addition, enhanced concurrent volume groups are included as choices in picklists for shared resource groups in SMIT panels for adding/changing resource groups, and in C-SPOC SMIT panels.
Complementary Cluster Software
A broad range of additional tools aids you in efficiently building, managing and expanding high availability clusters in AIX 5L environments. These include:
General Parallel File System (GPFS) for AIX 5L, a cluster-wide filesystem that allows users shared access to files that span multiple disk drives and multiple nodes. Workload Manager for AIX 5L provides resource balancing between applications. Smart Assist software for configuring Oracle, DB2, and WebSphere in HACMP clusters. HACMP/XD features provide software solutions for disaster recovery. For more information, see the section on HACMP/XD in About This Guide.
![]() ![]() ![]() |