IBM Eserver pseries HACMP V5.x Certification Study Guide Update

(1)

IBM

E

server pSeries

HACMP V5.x

Certification Study

Guide Update

Dino Quintero

Andrei Socoliuc

Tony Steel

Octavian Lascu

The latest HACMP features are

explained

Sample exercise questions are

included

Use as a deskside

reference guide

(2)

(3)

IBM

Eserver

pSeries HACMP V5.x Certification

Study Guide Update

February 2006

(4)

Second Edition (February 2006)

This edition applies to Version 5 of HACMP for AIX (product number 5765-F62).

Note: Before using this information and the product it supports, read the information in “Notices” on page xi.

(5)

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES

THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.

(12)

Trademarks

The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

Eserver® Eserver® Redbooks (logo) ™ pSeries® AIX 5L™ AIX® DB2®

Enterprise Storage Server® FlashCopy® HACMP™ IBM® Magstar® Redbooks™ RS/6000® Seascape® Tivoli® TotalStorage® WebSphere® The following terms are trademarks of other companies:

Java, JavaScript, Ultra, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

bookshelf, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

(13)

Preface

This IBM® Redbook update is designed as a study guide for professionals wanting to prepare for the certification exam to achieve IBMEserver® Certified Systems Expert - pSeries® HACMP™ 5.x for AIX® 5L™.

The pSeries HACMP 5.x for AIX 5L certification validates the skills required to successfully plan, install, configure, and support an HACMP 5.x for AIX 5L cluster installation. The requirements for this include a working knowledge of the following:

򐂰 Hardware options supported for use in a cluster, along with the considerations that affect the choices made.

򐂰 AIX 5L parameters that are affected by an HACMP 5.x installation, and their correct settings.

򐂰 The cluster and resource configuration process, including how to choose the best resource configuration for a customer requirement.

򐂰 Customization of the standard HACMP 5.x facilities to satisfy special customer requirements.

򐂰 Diagnosis and troubleshooting knowledge and skills.

This redbook helps AIX 5L professionals seeking a comprehensive and task-oriented guide for developing the knowledge and skills required for the certification. It is designed to provide a combination of theory and practical experience.

This redbook does not replace the practical experience you should have, but, when combined with educational activities and experience, should prove to be a very useful preparation guide for the exam. Due to the practical nature of the certification content, this publication can also be used as a deskside reference. So, whether you are planning to take the pSeries HACMP 5.x for AIX 5L

certification exam, or just want to validate your HACMP skills, this redbook is for you. For additional information about certification and instructions about how to register for an exam, contact IBM Learning Services or visit our Web site at:

(14)

The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Poughkeepsie Center.

Dino Quintero is a Senior Certified Consulting IT Specialist at the ITSO in Poughkeepsie, New York. Before joining the ITSO, he worked as a Performance Analyst for the Enterprise Systems Group and as a Disaster Recovery Architect for IBM Global Services. His areas of expertise include disaster recovery and pSeries clustering solutions. He is certified on pSeries system administration and pSeries clustering technologies. He is also an IBM Senior Certified Professional on pSeries technologies. Currently, he leads teams delivering redbook solutions on pSeries clustering technologies and delivering technical workshops

worldwide.

Andrei Socoliuc is an IT specialist at IBM Global Services in Romania. He provides technical support for the RS/6000® and IBMEserver pSeries. He is an IBM Certified Specialist in AIX and HACMP. His areas of expertise include AIX, HACMP, PSSP, and TSM. He holds a master’s degree in Computer Science from the Polytechnical University in Bucharest.

Tony Steel is a Senior IT Specialist in ITS Australia. He has 12 years experience in the UNIX® field, predominately AIX and Linux®. He holds an honors degree in Theoretical Chemistry from the University of Sydney. His areas of expertise include scripting, system customization, performance, networking, high

availability and problem solving. He has written and presented on LVM, TCP/IP, and high availability both in Australia and throughout Asia Pacific. This is the fourth redbook he has co-authored.

Octavian Lascu is a Project Leader at the International Technical Support Organization, Poughkeepsie Center. He writes extensively and teaches IBM classes worldwide in all areas of pSeries clusters and Linux. Before joining the ITSO, Octavian worked in IBM Global Services Romania as a software and hardware Services Manager. He holds a master's degree in Electronic Engineering from the Polytechnical Institute in Bucharest and is also an IBM Certified Advanced Technical Expert in AIX/PSSP/HACMP. He has worked with IBM since 1992.

Thanks to the following people for their contributions to this project: Paul Moyer, Elaine Krakower

IBM Poughkeepsie Gabrielle Velez

(15)

Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers.

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and apply online at:

ibm.com/redbooks/residencies.html

Comments welcome

Your comments are important to us!

We want our Redbooks™ to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways:

򐂰 Use the online Contact us review redbook form found at: ibm.com/redbooks

򐂰 Send your comments in an Internet note to:

[email protected]

򐂰 Mail your comments to:

IBM Corporation, International Technical Support Organization Dept. JN9B Mail Station P099

2455 South Road

(16)

(17)

Chapter 1.

Introduction

This chapter contains an introduction to IBM High Availability Cluster

Multi-Processing (HACMP) for AIX product line, and the concepts on which IBM high availability products are based.

The following topics are discussed: 򐂰 What is HACMP?

򐂰 History and evolution 򐂰 High availability concepts

򐂰 High availability versus fault tolerance

(18)

1.1 What is HACMP?

Before we explain what is HACMP, we have to define the concept of high availability.

High availability

In today’s complex environments, providing continuous service for applications is a key component of a successful IT implementation. High availability is one of the components that contributes to providing continuous service for the application clients, by masking or eliminating both planned and unplanned systems and application downtime. This is achieved through the elimination of hardware and software single points of failure (SPOFs).

A high availability solution will ensure that the failure of any component of the solution, either hardware, software, or system management, will not cause the application and its data to be unavailable to the user.

High Availability Solutions should eliminate single points of failure (SPOF) through appropriate design, planning, selection of hardware, configuration of software, and carefully controlled change management discipline.

Downtime

The downtime is the time frame when an application is not available to serve its clients. We can classify the downtime as:

򐂰 Planned:

– Hardware upgrades – Repairs

– Software updates/upgrades – Backups (offline backups)

– Testing (periodic testing is required for cluster validation.) – Development 򐂰 Unplanned: – Administrator errors – Application failures – Hardware failures – Environmental disasters

(19)

The IBM high availability solution for AIX, High Availability Cluster Multi

Processing, is based on the well-proven IBM clustering technology, and consists of two components:

򐂰 High availability: The process of ensuring an application is available for use through the use of duplicated and/or shared resources.

򐂰 Cluster multi-processing: Multiple applications running on the same nodes with shared or concurrent access to the data.

A high availability solution based on HACMP provides automated failure detection, diagnosis, application recovery, and node reintegration. With an appropriate application, HACMP can also provide concurrent access to the data for parallel processing applications, thus offering excellent horizontal scalability. A typical HACMP environment is shown in Figure 1-1.

Figure 1-1 HACMP cluster

HACMP Cluster pSeries Node Node A A pSeries Network ethernet Serial network Node Node B B Resource Group Application_01 Volume Groups File systems hdisk1 hdisk1 hdisk2 hdisk2 hdisk3 hdisk3 hdisk1 hdisk1 hdisk2 hdisk2 hdisk3 hdisk3 Resource Group Application_02 Volume Groups File systems

(20)

1.1.1 History and evolution

IBM High Availability Cluster Multi-Processing goes back to the early 1990s. HACMP development started in 1990 to provide high availability solution for applications running on RS/6000 servers.

We do not provide information about the very early releases, since those releases are nor supported or in use at the time this book was developed, instead, we provide highlights about the most recent versions.

HACMP V4.2.2

Along with HACMP Classic (HAS), this version introduced the enhanced scalability version (ES) based on RSCT (Reliable Scalable Clustering Technology) topology, group, and event management services, derived from PSSP (Parallel Systems Support Program).

HACMP V4.3.X

This version introduced, among other aspects, 32 node support for HACMP/ES, C-SPOC enhancements, ATM network support, HACMP Task guides (GUI for simplifying cluster configuration), multiple pre- and post- event scripts, FDDI MAC address takeover, monitoring and administration support enhancements, node by node migration, and AIX fast connect support.

HACMP V4.4.X

New items in this version are integration with Tivoli®, application monitoring, cascading with out fallback, C-SPOC enhancements, improved migration support, integration of HA-NFS functionality, and soft copy documentation (HTML and PDF).

HACMP V4.5

In this version, AIX 5L is required, and there is an automated configuration discovery feature, multiple service labels on each network adapter (through the use of IP aliasing), persistent IP address support, 64-bit-capable APIs, and monitoring and recovery from loss of volume group quorum.

HACMP V5.1

This is the version that introduced major changes, from configuration

simplification and performance enhancements to changing HACMP terminology. Some of the important new features in HACMP V5.1 were:

򐂰 SMIT “Standard” and “Extended” configuration paths (procedures) 򐂰 Automated configuration discovery

(21)

򐂰 Fast disk takeover

򐂰 Forced varyon of volume groups 򐂰 Heartbeating over IP aliases

򐂰 HACMP “classic” (HAS) has been dropped; now there is only HACMP/ES, based on IBM Reliable Scalable Cluster Technology

򐂰 Improved security, by using cluster communication daemon (eliminates the need of using standard AIX “r” commands, thus eliminating the need for the /.rhosts file)

򐂰 Improved performance for cluster customization and synchronization 򐂰 Normalization of HACMP terminology

򐂰 Simplification of configuration and maintenance 򐂰 Online Planning Worksheets enhancements 򐂰 Forced varyon of volume groups

򐂰 Custom resource groups

򐂰 Heartbeat monitoring of service IP addresses/labels on takeover node(s) 򐂰 Heartbeating over IP aliases

򐂰 Heartbeating over disks

򐂰 Various C-SPOC enhancements 򐂰 GPFS integration

򐂰 Fast disk takeover

򐂰 Cluster verification enhancements 򐂰 Improved resource group management

HACMP V5.2

Starting July 2004, the new HACMP V5.2 added more improvements in management, configuration simplification, automation, and performance areas. Here is a summary of the improvements in HACMP V5.2:

򐂰 Two-Node Configuration Assistant, with both SMIT menus and a Java™ interface (in addition to the SMIT “Standard” and “Extended” configuration paths).

򐂰 File collections.

򐂰 User password management.

򐂰 Classic resource groups are not used anymore, having been replaced by custom resource groups.

(22)

򐂰 Automatic cluster verification.

򐂰 Improved Online Planning Worksheets (OLPW) can now import a configuration from an existing HACMP cluster.

򐂰 Event management (EM) has been replaced by resource monitoring and a control (RMC) subsystem (standard in AIX).

򐂰 Enhanced security.

򐂰 Resource group dependencies. 򐂰 Self-healing clusters.

1.1.2 High availability concepts

What needs to be protected? Ultimately, the goal of any IT solution in a critical environment is to provide continuous service and data protection.

The high availability is just one building block in achieving the continuous operation goal. The high availability is based on the availability of the hardware, software (operating system and its components), application, and network components.

For a high availability solution you need: 򐂰 Redundant servers

򐂰 Redundant networks

򐂰 Redundant network adapters 򐂰 Monitoring

򐂰 Failure detection 򐂰 Failure diagnosis 򐂰 Automated fallover 򐂰 Automated reintegration

The main objective of the HACMP is eliminate Single Points of Failure (SPOFs) (see Table 1-1 on page 7).

Note: At the time this redbook was developed, both HACMP V5.1 and V5.2 were available. The certification exam only contains HACMP V5.1 topics.

(23)

Table 1-1 Single point of failure

Each of the items listed in Table 1-1 in the Cluster Object column is a physical or logical component that, if it fails, will result in the application being unavailable for serving clients.

1.1.3 High availability versus fault tolerance

The systems for the detection and handling of the hardware and software failures can be defined in two groups:

򐂰 Fault-tolerant systems 򐂰 High availability systems

Fault-tolerant systems

The systems provided with fault tolerance are designed to operate virtually without interruption, regardless of the failure that may occur (except perhaps for a complete site down due to a natural disaster). In such systems, ALL components are at least duplicated for either software or hardware.

Thus, CPUs, memory, and disks have a special design and provide continuous service, even if one sub-component fails.

Such systems are very expensive and extremely specialized. Implementing a fault tolerant solution requires a lot of effort and a high degree of customization for all system components.

Cluster object Eliminated as a single point of failure by:

Node (servers) Multiple nodes

Power supply Multiple circuits and/or power supplies

Network adapter Redundant network adapters Network Multiple networks to connect nodes TCP/IP subsystem A non- IP networks to back up TCP/IP Disk adapter Redundant disk adapters

Disk Redundant hardware and disk mirroring or RAID technology

Application Configuring application monitoring and backup node(s) to acquire the application engine and data

(24)

In places where

no

downtime is acceptable (life support and so on), fault-tolerant equipment and solutions are required.

High availability systems

The systems configured for high availability are a combination of hardware and software components configured in such a way to ensure automated recovery in case of failure with a minimal acceptable downtime.

In such systems, the software involved detects problems in the environment, and then provides the transfer of the application on another machine, taking over the identity of the original machine (node).

Thus, it is very important to eliminate all single points of failure (SPOF) in the environment. For example, if the machine has only one network connection, a second network interface should be provided in the same node to take over in case the primary adapter providing the service fails.

Another important issue is to protect the data by mirroring and placing it on shared disk areas accessible from any machine in the cluster.

The HACMP (High Availability Cluster Multi-Processing) software provides the framework and a set of tools for integrating applications in a highly available system.

Applications to be integrated in a HACMP cluster require a fair amount of customization, not at the application level, but rather at the HACMP and AIX platform level.

HACMP is a flexible platform that allows integration of generic applications running on AIX platform, providing for high available systems at a reasonable cost.

1.1.4 High availability solutions

The high availability (HA) solutions can provide many advantages compared to other solutions. In Table 1-2, we describe some HA solutions and their

characteristics. Table 1-2 Types of HA solutions

Solutions Standalone Enhanced Standalone

High Availability Clusters

Fault-Tolerant Computers

Downtime Couple of days Couple of hours Depends (usually three minutes)

Never stop

(25)

High availability solutions offer the following benefits: 򐂰 Standard components

򐂰 Can be used with the existing hardware 򐂰 Works with just about any application

򐂰 Works with a wide range of disk and network types 򐂰 Excellent availability at reasonable cost

The IBM high available solution for the IBMEserver pSeries offers some distinct benefits. Such benefits include:

򐂰 Proven solution (more than 14 years of product development)

򐂰 Flexibility (virtually any application running on a standalone AIX system can be protected with HACMP)

򐂰 Using “of the shelf” hardware components 򐂰 Proven commitment for supporting our customers

Considerations for providing high availability solutions include: 򐂰 Thorough design and detailed planning

򐂰 Elimination of single points of failure 򐂰 Selection of appropriate hardware 򐂰 Correct implementation (no “shortcuts”) 򐂰 Disciplined system administration practices 򐂰 Documented operational procedures 򐂰 Comprehensive testing

1.2 HACMP concepts

The basic concepts of HACMP can be classified as follows: 򐂰 Cluster topology

Contains basic cluster components nodes, networks, communication interfaces, communication devices, and communication adapters. 򐂰 Cluster resources

Entities that are being made highly available (for example, file systems, raw devices, service IP labels, and applications). Resources are grouped together in resource groups (RGs), which HACMP keeps highly available as a single entity.

(26)

Resource groups can be available from a single node or, in the case of concurrent applications, available simultaneously from multiple nodes. 򐂰 Fallover

Represents the movement of a resource group from one active node to another node (backup node) in response to a failure on that active node. 򐂰 Fallback

Represents the movement of a resource group back from the backup node to the previous node, when it becomes available. This movement is typically in response to the reintegration of the previously failed node.

1.2.1 HACMP terminology

To understand the correct functionality and utilization of HACMP, it is necessary to know some important terms:

򐂰 Cluster

Loosely-coupled collection of independent systems (nodes) or LPARs organized into a network for the purpose of sharing resources and communicating with each other.

HACMP defines relationships among cooperating systems where peer cluster nodes provide the services offered by a cluster node should that node be unable to do so.

These individual nodes are together responsible for maintaining the functionality of one or more applications in case of a failure of any cluster component.

򐂰 Node

An IBMEserver pSeries machine (or LPAR) running AIX and HACMP that is defined as part of a cluster. Each node has a collection of resources (disks, file systems, IP address(es), and applications) that can be transferred to another node in the cluster in case the node fails.

򐂰 Resource

Resources are logical components of the cluster configuration that can be moved from one node to another. All the logical resources necessary to provide a Highly Available application or service are grouped together in a resource group (RG).

The components in a resource group move together from one node to another in the event of a node failure. A cluster may have more than one resource group, thus allowing for efficient use of the cluster nodes (thus the “Multi-Processing” in HACMP).

(27)

򐂰 Takeover

It is the operation of transferring resources between nodes inside the cluster. If one node fails due to a hardware problem or crash of AIX, its resources application will be moved to the another node.

򐂰 Clients

A client is a system that can access the application running on the cluster nodes over a local area network. Clients run a client application that connects to the server (node) where the application runs.

1.3 HACMP/XD (extended distance)

The High Availability Cluster Multi-Processing for AIX (HACMP) base software product addresses part of the continuos operation problem. It addresses recovery from the failure of a computer, an adapter, or a local area network within a computing complex at a single site.

A typical HACMP/XD High Availability Geographic Cluster (HAGEO) is presented in Figure 1-2.

Figure 1-2 Typical HACMP/XD HAGEO configuration GEO_NET1

GMD: fkmgeolv1 fkmgeolog

PUB_NET1

icar_geo1 ulise_geo1 ajax_geo1

/fs1 /fkm /fkm StatMap: fkmsmlv1 fkmsmlog fkmvg1 AJAX fkmvg1 ULISE ICAR Site:Paris Site:Paris Site:Bonn Resource Group:GEO_RG(YOKO_RG) Serial network (via modem)

(28)

For protecting an application in case of a major disaster (site failure), additional software is needed. HAGEO provides:

򐂰 Ability to configure a cluster with geographically separate sites.

HAGEO extends HACMP to encompass two geographically distant data centers or sites. This extension prevents an individual site from being a single point of failure within the cluster.

The geo-mirroring process supplies each site with an updated copy of essential data.

Either site can run key applications, ensuring that mission-critical computing resources remain continuously available at a geographically separate site if a failure or disaster disables one site.

򐂰 Automatic failure detection and notification.

HAGEO works with HACMP to provide automatic detection of a site or geographic network failure. It initiates the recovery process and notifies the system administrator about all failures it detects and actions it takes in response.

򐂰 Automatic fallover

HAGEO includes event scripts to handle recovery from a site or geographic network failure. These scripts are integrated with the standard HACMP event scripts.

You can customize the behavior for your configuration by adding pre- or post- event scripts, just as you can for HACMP.

򐂰 Fast recovery from a disaster.

HAGEO also provides fast recovery of data and applications at the operable site. The geo-mirroring process ensures that the data is already available at the second site when a disaster strikes.

Recovery time typically takes minutes, not including the application recovery time.

򐂰 Automatic resynchronization of data during site recovery.

HAGEO handles the resynchronization of the mirrors on each site as an integral part of the site recovery process. The nodes at the rejoining site are automatically updated with the data received while the site was in failure. 򐂰 Reliable data integrity and consistency.

HAGEO’s geographic mirroring and geographic messaging components ensure that if a site fails, the surviving site’s data is consistent with the failed site’s data.

(29)

When the failed site reintegrates into the cluster, HAGEO updates that site with the current data from the operable site, once again ensuring data consistency.

򐂰 Flexible, scalable configurations.

HAGEO software supports a wide range of configurations, allowing you to configure the disaster recovery solution unique to your needs.

You can have up to eight nodes in an HAGEO cluster, with varying numbers of nodes at each site.

HAGEO is file system and database independent, since the geo-mirroring device behaves the same as the disk devices it supports. Because the mirroring is transparent, applications configured to use geo-mirroring do not have to be modified in any way.

1.3.1 HACMP/XD: HAGEO components

The software has three significant functions: 򐂰 GeoMirror:

Consists of a logical device and a pseudo device driver that mirrors at a second site; the data is entered at one site. TCP/IP is used as a transport for mirrored data.

GeoMirror can be used in synchronous and asynchronous mode, depending on the communication bandwidth between sites, and the application

transaction volume (which determines the amount of changed data). 򐂰 GeoMessage:

Provides reliable delivery of data and messages between GeoMirror devices at the two sites.

򐂰 Geographic topology:

Provides the logic for integrating the geo-mirroring facilities with HACMP facilities to provide automatic failure detection and recovery from events that affect entire sites.

򐂰 Recovering from disaster

When a disaster causes a site failure, the Cluster Manager on nodes at the surviving site detects the situation quickly and takes action to keep

geo-mirrored applications available.

Likewise, if the cluster is partitioned due to global geographic network failure, then the Cluster Manager on the site configured as non-dominant will bring itself down in order to avoid data divergence.

(30)

1.3.2 HACMP/XD: HAGEO basic configurations

You can configure an HAGEO cluster in any of the configurations supported by the HACMP base software. These include standby, one-sided takeover, mutual takeover, and concurrent access configurations.

򐂰 Standby configurations

The standby configuration is a traditional redundant hardware configuration where one or more nodes in the cluster stand idle until a server node fails. In HAGEO, this translates to having an idle site. A site is not completely idle since it may also be involved in the geo-mirroring process. But nodes at this site do not perform application work.

򐂰 Takeover configurations

In a takeover configuration, all nodes are processing; no idle nodes exist. Configurations include:

– Intrasite (local) takeover – Remote one-sided takeover – Remote mutual takeover 򐂰 Concurrent configurations

In a concurrent access configuration, all nodes at one site have simultaneous access to the concurrent volume group and own the same disk resources. The other site is set up the same way.

If a node leaves the site, availability of the resources is not affected, since other nodes have the concurrent volume group varied on.

If a site fails, the other site offers concurrent access on nodes at that site. A concurrent application can be accessed by all nodes in the cluster.

The HACMP Cluster Lock Manager must be running on all nodes in the cluster. Not all databases can be used for concurrent access that involves nodes across the geography.

1.3.3 HACMP/XD PPRC integration feature

This feature, introduced in simultaneously in HACMP V4.5 PTF5 and HACMP V5.1, provides automated site fallover and activation of remote copies of application data in an environment where the IBM Enterprise Storage Server® (ESS) is used in both sites and the Peer to Peer Remote Copy (PPRC) facility provides storage volumes mirroring.

(31)

In case of primary site failure, data should be available for use at the secondary site (replicated via PPRC). The data copy in the secondary site must be activated in order to be used for processing.

The HACMP/XD PPRC integration feature provides automated copy split in case of primary site failure and automated reintegration when the primary site

becomes available.

For detailed information, see High Availability Cluster Multi-Processing XD

(Extended Distance) V5.1: Concepts and Facilities for HAGEO Technology,

(32)

(33)

Chapter 2.

Planning and design

When planning and desiging a high availability cluster, you must follow all customer requirements. You should have a good understanding of the hardware and networking configuration and of the applications that are to be made highly available. You should also be able to control the behavior of the applications in a failure situation.

Knowing the behavior of the application in a failure situation is important to controlling how the cluster will react in such a situation.

The information necessary for planning and implementing a cluster should cover applications, environment, hardware, networks, storage, and also support and change procedures.

This chapter describes the following HACMP cluster topics: 򐂰 Node sizing considerations

򐂰 Cluster hardware planning 򐂰 Software planning

򐂰 Storage planning

򐂰 Disaster recovery planning

Note: Planning is one half of a successful implementation, but when it comes to HACMP, we cannot emphasize enough that proper planning is needed. If planning is not done properly, you may find yourself entangled in restrictions at a later point, and recovering from these restrictions can be a painful experience. So

(34)

take your time and use the planning worksheets that comes with the product; they are invaluable in any migration or problem determination situations or for documenting the plan.

2.1 Planning considerations

When planning a high availability cluster, you should consider the sizing of the nodes, storage, network and so on, to provide the necessary resources for the applications to run properly, even in a takeover situation.

2.1.1 Sizing: Choosing the nodes in the cluster

Before you start the implementation of the cluster, you should know how many nodes are required, and the type of the nodes that should be used. The type of nodes to be used is important in terms of the resources required by the

applications.

Sizing of the nodes should cover the following aspects: 򐂰 CPU (number of CPUs and speed)

򐂰 Amount of random access memory (RAM) in each node 򐂰 Disk storage (internal)

򐂰 Number of communication and disk adapters in each node 򐂰 Node reliability

The number of nodes in the cluster depends on the number of applications to be made highly available, and also on the degree of availability desired. Having more than one spare node for each application in the cluster increases the overall availability of the applications.

HACMP V5.1 supports a variety of nodes, ranging from desktop systems to high-end servers. SP nodes and Logical Partitions (LPARs) are supported as well. For further information, refer to the HACMP for AIX 5L V5.1 Planning and

Installation Guide, SC23-4861-02.

The cluster resource sharing is based on the applications requirements. Nodes that perform tasks that are not directly related to the applications to be made highly available and do not need to share resources with the application nodes should be configured in separate clusters for easier implementation and administration.

(35)

All nodes should provide sufficient resources (CPU, memory, and adapters) to sustain execution of all the designated applications in a fail-over situation (to take over the resources from a failing node).

If possible, you should include additional nodes in the cluster, to increase the availability of the cluster; this also provides greater flexibility when performing node failover, reintegration, and maintenance operations.

We recommend using cluster nodes with a similar hardware configuration, especially when implementing clusters with applications in mutual takeover or concurrent configurations. This makes it easier to distribute resources and to perform administrative operations (software maintenance and so on).

2.1.2 Sizing: Storage considerations

In the most commonly used configurations, applications to be made highly available require a shared storage space for application data. The shared storage space is used either for concurrent access, or for making the data available to the application on the takeover node (in a fail-over situation). The storage to be used in a cluster should provide shared access from all designated nodes for each application. The technologies currently supported for HACMP shared storage are SCSI, SSA, and Fibre Channel.

The storage configuration should be defined according to application

requirements as non-shared (“private”) or shared storage. The private storage may reside on internal disks and is not involved in any takeover activity.

Shared storage should provide mechanisms for controlled access, considering the following reasons:

򐂰 Data placed in shared storage must be accessible from whichever node the application may be running at a point in time. In certain cases, the application is running on only one node at a time (non-concurrent), but in some cases, concurrent access to the data must be provided.

򐂰 In a non-concurrent environment, if the shared data is updated by the wrong node, this could result in data corruption.

򐂰 In a concurrent environment, the application should provide its own data access mechanism, since the storage controlled access mechanisms are by-passed by the platform concurrent software (AIX/HACMP).

2.1.3 Network considerations

(36)

򐂰 IP network topology (routing, switches, and so on)

򐂰 IP network performance (speed/bandwidth, latency, and redundancy) 򐂰 ATM and/or X.25 network configuration

The IP networks are used to provide client access to the applications running on the nodes in the cluster, as well as for exchanging heartbeat messages between the cluster nodes. In an HACMP cluster, the heartbeat messages are exchanged via IP networks and point-to-point (non-IP) networks.

HACMP is designed to provide client access through TCP/IP-based networks, X.25, and ATM networks.

2.2 HACMP cluster planning

The cluster planning is perhaps the most important step in implementing a successful configuration. HACMP planning should include the following aspects: 򐂰 Hardware planning

– Nodes – Network – Storage 򐂰 Software planning

– Operating system version – HACMP version

– Application compatibility 򐂰 Test and maintenance planning

– The test procedures – Change management – Administrative operations

Hardware planning

The goal in implementing a high availability configuration is to provide highly available service by eliminating single points of failure (hardware, software, and network) and also by masking service interruptions, either planned or unplanned. The decision factors for node planning are:

򐂰 Supported nodes: Machine types, features, supported adapters, power supply (AC, DC, dual power supply versus single power supply, and so on). 򐂰 Connectivity and cables: Types of cables, length, connectors, model numbers,

(37)

2.2.1 Node configurations

HACMP V5.1 supports IBMEserver pSeries (stand-alone and LPAR mode), IBM SP nodes, as well as existing RS/6000 servers, in any combination of nodes within a cluster. Nodes must meet the minimum requirements for internal memory, internal disk, number of available I/O slots, and operating system compatibility (AIX version).

Items to be considered are:

򐂰 Internal disk (number of disks, capacities, and LVM mirroring used?) 򐂰 Shared disk capacity and storage data protection method (RAID and LVM

mirroring)

򐂰 I/O slot limitations and their effect on creating a single point of failure (SPOF) 򐂰 Client access to the cluster (network adapters)

򐂰 Other LAN devices (switches, routers, and bridges) 򐂰 Redundancy of I/O adapters and subsystems 򐂰 Redundancy of power supplies

2.2.2 Network configuration

The main objective when planning the cluster networks is to assess the degree of redundancy you need to eliminate network components as potential single points of failure. The following aspects should be considered:

򐂰 Network: Nodes connected to multiple physical networks

򐂰 For TCP/IP subsystem failure: Non-IP network to help with the decision process

򐂰 Network interfaces: Redundant networks adapters on each network (to prevent resource group failover in case a single network interface fails) When planning the cluster network configuration, you must chose the proper combination for the node connectivity:

򐂰 Cluster network topology (switches, routers, and so on).

򐂰 The combination of IP and non-IP (point-to-point) networks connect your cluster nodes and the number of connections for each node to all networks. The method for providing high availability service IP addresses:

򐂰 IP address takeover (IPAT) via IP aliases 򐂰 IPAT via IP Replacement.

(38)

For a complete list of nodes and adapters supported in HACMP configuration, refer to the HACMP for AIX 5L V5.1 Planning and Installation Guide,

SC23-4861-02; also, check the IBM support Web site at:

http://www-1.ibm.com/servers/eserver/pseries/ha/

2.2.3 HACMP networking terminology

Starting with HACMP V5.1, the terminology used to describe HACMP configuration and operation has changed dramatically. The reason for this change is to simplify the overall usage and maintenance of HACMP, and also to align the terminology with the IBM product line.

For example, in previous HACMP versions, the term “Adapter”, depending on the context, could have different meanings, which made configuration confusing and difficult.

IP label

The term

IP label

represents the name associated with a specific IP address, as defined in the name resolution method used on the cluster nodes (DNS or static - /etc/hosts). This replaces the

host name

, which may be confused with the output of the hostname command and may not be associated with any IP address. In HACMP V5.1, the term Adapter has been replaced as follows:

򐂰 Service IP Label / Address: An IP label/address over which a service is provided. It may be bound to a single node or shared by multiple nodes, and is kept highly available by HACMP.

򐂰 Communication Interface: A physical interface that supports the TCP/IP protocol, represented by its base IP address.

򐂰 Communication Device: A physical device representing one end of a point-to-point non-IP network connection, such as /dev/tty1, /dev/tmssa1, /dev/tmscsi1, and /dev/hdisk1.

򐂰 Communication Adapter: An X.25 adapter used to provide a highly available communication link.

Service IP address/label

The service IP address is an IP address used for client access. This service IP address (and its associated label) is monitored by HACMP and is part of a resource group.

(39)

There are two types of service IP address (label):

򐂰 Shared service IP address (label): An IP address that can be configured on multiple nodes and is part of a resource group that can be active only on one node at a time.

򐂰 Node-bound service IP address (label): An IP address that can be configured only one node (is not shared by multiple nodes). Typically, this type of service IP address is associated with concurrent resource groups.

The service IP addresses become available when HACMP is started and their associated resource group has an online status.

HACMP communication interfaces

The communication interface definition in HACMP is a logical grouping of the following:

򐂰 A logical network interface is the name to which AIX resolves a port (for example, en0) of a physical network adapter.

򐂰 A service IP address is an IP address over which services, such as an application, are provided, and over which client nodes communicate. 򐂰 A service IP label is a label that maps to the Service IP address.

A communication interface refers to IP-based networks and networks adapters. The networks adapters that are connected to a common physical network are combined into logical networks that are used by HACMP.

Each network adapter is capable of hosting several TCP/IP addresses. When configuring a cluster, you define the IP addresses that HACMP will monitor (base or boot IP addresses) and the IP addresses that HACMP will keep highly available (the service IP addresses) to HACMP.

Heartbeating in HACMP occurs over communication interfaces. HACMP uses the heartbeating facility of the RSCT subsystem (using UDP) to monitor its network interfaces and IP addresses. HACMP passes the network topology defined and stored in the ODM to RSCT, whenever HACMP services are started on that node, and RSCT provides failure notifications to HACMP.

HACMP communication devices

HACMP also provides monitoring of point-to-point non-IP networks. Both ends of a point-to-point network are AIX devices (as defined in /dev directory). These are the communication devices and they include serial RS232 connections, target mode SCSI, target mode SSA, and disk heartbeat connections.

(40)

The point-to-point networks are also monitored by RSCT, and their status information is used by HACMP to distinguish between node failure and IP network failure.

For example, a heartbeat over disk uses the disk device name (for example, /dev/hdisk2) as the device configured to HACMP at each end of the connection. The recommendation for such networks is to have at least one non-IP network defined between any two nodes in the cluster.

In case of disk heartbeat, the recommendation is to have one point-to-point network consisting of one disk per pair of nodes per physical enclosure. One physical disk cannot be used for two point-to-point networks.

Communication adapters and links

You can define the following communication links as resources in HACMP: 򐂰 SNA configured over LAN network adapters (ent*)

򐂰 SNA configured over X.25 adapter 򐂰 Native X.25 links

HACMP managed these links as part of resource groups, thus ensuring high availability communication links. In the event of a physical network interface failure, an X.25 link failure, or a node failure, the highly available communication link is migrated over to another available adapter on the same node, or on a takeover node (together with all the resources in the same resource group).

IP aliases

An

IP alias

is an IP address that is configured on a communication (network) interface in addition to the base IP address. An IP alias is an AIX function that is supported by HACMP. AIX supports multiple IP aliases on each communication interface. Each IP alias on the adapter can be on a separate subnet.

AIX also allows IP aliases with different subnet masks to be configured for an interface; this functionality is not yet supported by HACMP.

IP aliases are used in HACMP both as service and non-service addresses for IP address takeover, as well as for heartbeat configuration.

Network interface functions

For IP networks, we recommend that you configure more than one

communication interface per node per network. The communication interfaces will have specific roles each, depending on the HACMP cluster status.

(41)

򐂰 Service Interface

A service interface is a communications interface configured with one or more service IP addresses (labels). Depending on the IP address takeover (IPAT) method defined for each network, the service IP address will be added on top of the base IP address (IPAT via aliasing), or will replace the base (boot) IP address of the communication interface. This interface is used for providing access to the application(s) running on that node. The service IP address is monitored by HACMP via RSCT heartbeat.

򐂰 Boot Interface

This is a communication interface represented by its base (boot) IP address, as defined in an AIX configuration. If heartbeating over IP aliases is used, this IP address will not be monitored by HACMP, but the communication interface will be monitored via the IP alias assigned by HACMP at startup time.

No client traffic is carried over the boot interface; however, if a service interface fails, HACMP will move the service IP address(es) onto a

non-service interface. If a node fails, another interface on the takeover node will configure the service IP address when performing a resource group fallover.

򐂰 Persistent Node IP Label

A persistent node IP label is an IP alias that can be assigned to a specific node on a cluster network. A persistent node IP label:

– Is node-bound (always stays on the same node).

– Can coexist on a network adapter that already has a service or non-service IP label defined.

– Has the advantage where it does not require installation of an additional physical network adapter on that node.

– Is not part of any resource group.

Assigning a persistent node IP label provides a node-bound IP address, and is useful for administrative purposes, since issuing a connection to a

persistent node IP label will always identify that particular cluster node, even if HACMP services are not started on that node.

Note: A node can have from zero to seven non-service interfaces for each network. Using multiple non-service interfaces on the same network eliminates the communication interface as a single point of failure.

(42)

The persistent IP labels are defined in the HACMP configuration, and they become available the first time HACMP is started on each node. Once configured, the persistent IP labels (addresses) will remain available on the adapter they have been configured on, even if HACMP is stopped on the node(s), or the nodes are rebooted.

The persistent node IP labels can be created on the following types of IP-based networks:

– Ethernet – Token Ring – FDDI

– ATM LAN Emulator

The persistent IP label behavior is the following:

– If a network adapter that has a service IP label configured fails, and there is also a persistent label defined on this network adapter, then the persistent IP label (address) is moved together with the service IP label (address) over to the same non-service interface.

– If all network adapters on the cluster network on a specified node fail, then the persistent node IP label becomes unavailable. A persistent node IP label always remains on the same network, and on the same node; it does not move between the nodes in the cluster.

For more information, see 3.4, “Configuring cluster topology” on page 104.

IP aliases used for heartbeat

These IP addresses are allocated from a pool of private, non-routable addresses, and are used to monitor the communication interfaces without the need to change their base (boot) IP address.

This is useful in certain cases when it is not desirable to change the base IP addresses (as they are defined in AIX) of the network adapters on each node, and those addresses do not conform to the HACMP requirements (they are in the same subnet, so the network adapters cannot be monitored).

Note: It is possible to configure one persistent node IP label (address) per network per node. For example, if you have a node connected to two networks defined in HACMP, that node can be identified via two persistent IP labels (addresses), one for each network.

Restriction: It is not possible to configure a persistent node IP label on the SP Switch, on ATM Classical IP, or on non-IP networks.

(43)

For this purpose, HACMP provides the usage of heartbeat over IP aliases.

2.2.4 Network types

In HACMP, the term “network” is used to define a logical entity that groups the communication interfaces and devices used for communication between the nodes in the cluster, and for client access. The networks in HACMP can be defined as IP networks and non-IP networks.

Both IP and non-IP networks are used to exchange heartbeat (“keep alive”) messages between the nodes. In this way, HACMP maintains information about the status of the cluster nodes and their respective communication interfaces and devices.

The IP network types supported in HACMP V5.1 are: 򐂰 Ethernet (ether)

򐂰 Token ring (token) 򐂰 FDDI (fddi)

򐂰 SP Switch and SP Switch2 (hps) 򐂰 ATM (atm)

The following IP network types are not supported: 򐂰 Serial Optical Channel Converter (SOCC) 򐂰 Serial Line IP (SLIP)

򐂰 Fibre Channel Switch (FCS) 򐂰 802.3

򐂰 IBM High Performance Switch (HPS)

The non-IP networks are point-to-point connections between two cluster nodes, and are used by HACMP for control messages and heartbeat traffic. These networks provide an additional protection level for the HACMP cluster, in case the IP networks (or the TCP/IP subsystem on the nodes) fail.

The following devices are supported for non-IP (device-based) networks in HACMP:

򐂰 Target mode SCSI (tmscsi) 򐂰 Target mode SSA (tmssa) 򐂰 Disk heartbeat (diskhb) 򐂰 Serial RS232

(44)

Also, in its current release, HACMP does not support the AIX Virtual IP facility (VIPA) and IPV6.

2.2.5 Choosing the IP address takeover (IPAT) method

One of the key decisions to be made when implementing a cluster is the behavior of the resource groups and the service IP address(es) associated with them. Since most of the times HACMP is used to protect stand-alone, non-concurrent applications, one must chose the method to be used for providing highly available service IP addresses.

When an application is started or moved to another node together with its associated resource group, the service IP address can be configured in two ways:

򐂰 By replacing the base (boot-time) IP address of a communication interface; this method is known as IP address takeover (IPAT) via IP replacement. 򐂰 By configuring one communication interface with an additional IP address on

top of the existing one; this method is known as IP address takeover via IP aliasing.

The default IPAT method in HACMP V5.1 is via aliasing (IPAT via aliasing). To change this default behavior, the network properties must be changed using HACMP extended configuration menus.

IP address takeover

IP address takeover is a mechanism for recovering a service IP label by moving it to another physical network adapter on another node, when the initial physical network adapter fails. IPAT ensures that an IP address (label) over which services are provided to the client nodes remains available.

Note: HACMP now supports Ethernet aggregated (Etherchannel)

communication interfaces for IP address takeover in both AIX 5L V5.1 and AIX 5L V5.2. Etherchannel is not supported for:

򐂰 Hardware address takeover 򐂰 PCI hot plug

(45)

IPAT and service IP labels

We can explain the two methods of IPAT and how they will control the service IP label as follows:

򐂰 IP address takeover via IP aliases

The service IP address/label is aliased onto an existing communication interface, without changing (replacing) the base address of the interface. HACMP uses the ifconfig command to perform this operation.

Figure 2-1 IPAT via IP aliases

HACMP supports IP Address Takeover on different types of network using the IP aliasing network capabilities of AIX. IPAT via IP Aliases can use the gratuitous ARP capabilities on certain types of networks.

IPAT via IP aliasing allows a single network adapter to support more than one service IP address (label). Therefore, the same node can host multiple resource groups at the same time, without limiting the number of resource groups to the number of available communication interfaces.

IPAT via IP aliases provides the following advantages over IPAT via IP replacement:

– IP address takeover via IP aliases is faster than IPAT via IP replacement, because replacing the IP address takes a considerably longer time than adding an IP alias onto the same interface.

– IP aliasing allows the co-existence of multiple service labels on the same network interface, so you can use fewer physical network interface cards in your cluster.

Note: In this configuration, all base (boot) IP addresses/labels defined on the nodes must be configured on different subnets, and also different from the service IP addresses (labels). This method also saves hardware, but requires additional subnets. See Figure 2-1 on page 29.

node1

en0

en1

192.168.11.131 172.16.100.31 192.168.100.31 Service IP Label Boot IP Label Boot IP Label

node2

en0

en1

192.168.11.132 172.16.100.32 192.168.100.32 net mask : 255.255.255.0

(46)

򐂰 IP address takeover via IP replacement

The service IP address replaces the existing (boot/base) IP address on the network interface.

With this method, only one IP address/label is configured on the same network interface at a time.

Figure 2-2 IPAT via IP replacement

If the communication interface holding the service IP address fails, when using the IPAT via IP replacement, HACMP moves the service IP address on another available interface on the same node and on the same network; in this case, the resource group associated is not affected.

If there is no available interface on the same node, the resource group is moved together with the service IP label on another node with an available communication interface.

When using IPAT via IP replacement (also known as “classic” IPAT), it is also possible to configure hardware address takeover (HWAT). This is achieved by masking the native MAC address of the communication interface with a locally administered address (LAA), thus ensuring that the mappings in the ARP cache on the client side remain unchanged.

Note: In HACMP V5.1, IPAT via IP aliases is the default mechanism for keeping a service IP label highly available.

Note: In this configuration, the service IP address must be in the same subnet with one of the node’s communication interface boot address, while a backup communication interface’s base IP address must be on a different subnet. This method may save subnets, but requires additional hardware. See Figure 2-2 on page 30.

node1

en0

en1

192.168.100.131 172.16.100.31 192.168.100.31 Service IP Label Boot IP Label Boot IP Label

node2

en0

en1

192.168.100.132 172.16.100.32 192.168.100.32 net mask : 255.255.255.0

(47)

2.2.6 Planning for network security

Planning network security is also important to avoid unauthorized access at the cluster nodes.

Starting with HACMP V5.1, a new security mechanism has been introduced, by providing common communication infrastructure (daemon) for all HACMP configuration related communications between nodes.

The introduction of the new cluster communication daemon (clcomdES) provides enhanced security in a HACMP cluster and also speeds up the configuration related operations.

There are three levels of communication security: 򐂰 Standard

– Default security level.

– Implemented directly by cluster communication daemon (clcomdES). – Uses HACMP ODM classes and the /usr/es/sbin/cluster/rhosts file to

determine legitimate partners. 򐂰 Enhanced

– Used in SP clusters.

– Takes advantage of enhanced authentication method based on third-party authentication method provided by Kerberos.

򐂰 Virtual Private Networks (VPN) – VPNs are configured within AIX.

– HACMP is then configured to use VPNs for all inter-node configuration related communication operations.

By using the cluster secure communication subsystem, HACMP eliminates the need for either /.rhosts files or a Kerberos configuration on each cluster node. However, the /.rhosts may still be needed to support operations for applications that require this remote communication mechanism.

IBM Eserver pseries HACMP V5.x Certification Study Guide Update

IBM

E

server pSeries

HACMP V5.x

Certification Study

Guide Update

Dino Quintero

Andrei Socoliuc

Tony Steel

Octavian Lascu

The latest HACMP features are

explained

Sample exercise questions are

included

Use as a deskside

reference guide

IBM

Eserver

pSeries HACMP V5.x Certification

Study Guide Update

February 2006

Contents

Notices

Trademarks

Preface

The team that wrote this redbook

Become a published author

Comments welcome

Introduction

1.1 What is HACMP?

High availability

Downtime

1.1.1 History and evolution

HACMP V4.2.2

HACMP V4.3.X

HACMP V4.4.X

HACMP V4.5

HACMP V5.1

HACMP V5.2

1.1.2 High availability concepts

1.1.3 High availability versus fault tolerance

Fault-tolerant systems

no

High availability systems

1.1.4 High availability solutions

1.2 HACMP concepts

1.2.1 HACMP terminology

1.3 HACMP/XD (extended distance)

1.3.1 HACMP/XD: HAGEO components

1.3.2 HACMP/XD: HAGEO basic configurations

1.3.3 HACMP/XD PPRC integration feature

Planning and design

2.1 Planning considerations

2.1.1 Sizing: Choosing the nodes in the cluster

2.1.2 Sizing: Storage considerations

2.1.3 Network considerations

2.2 HACMP cluster planning

Hardware planning

2.2.1 Node configurations

2.2.2 Network configuration

2.2.3 HACMP networking terminology

IP label

IP label

host name

Service IP address/label

HACMP communication interfaces

HACMP communication devices

Communication adapters and links

IP aliases

IP alias

Network interface functions

IP aliases used for heartbeat

2.2.4 Network types

2.2.5 Choosing the IP address takeover (IPAT) method

IP address takeover

IPAT and service IP labels

node1

en0

en1