IBM HACMP 6.1 for AIX：高可用性集群多处理概念指南

3星 · 超过75%的资源需积分: 9 31 浏览量更新于2024-07-31 1 收藏 1.81MB PDF 举报

"IBM HACMP 6.1的概念与设施指南" IBM High Availability Cluster Multi-Processing for AIX（简称HACMP）是一款针对AIX操作系统的企业级高可用性集群解决方案，旨在提供关键业务系统的无中断运行能力。HACMP 6.1是该产品的一个版本，发布于2009年11月。本指南（SC23-4864-12）详细介绍了HACMP 6.1的相关概念和技术特性，以帮助用户理解和配置这个集群系统。 HACMP的主要目标是确保在硬件故障、网络问题或其他系统异常情况下，应用程序和服务能够持续运行，减少宕机时间，从而提高业务连续性和数据保护。它通过将多个物理服务器连接成一个集群，共享资源，并在单个节点出现故障时自动将工作负载转移到其他健康的节点上。在HACMP 6.1中，主要涉及以下几个核心概念： 1. 集群：由两个或更多服务器组成的网络，这些服务器协同工作以提供高可用性。在HACMP中，集群成员共享系统状态信息，以便在必要时进行故障切换。 2. 节点：集群中的每一个物理服务器被称为一个节点。每个节点都有自己的操作系统实例，并可以运行应用程序和服务。 3. 集群资源组：资源组是一系列相互依赖的资源，如数据库、网络服务等，它们作为一个单元进行管理。当一个节点发生故障时，整个资源组会被迁移到另一个节点。 4. 心跳：集群节点之间通过心跳通信来检测彼此的状态。如果心跳中断，HACMP会识别到可能的故障，并采取行动。 5. 故障切换：当检测到节点或资源故障时，HACMP会自动将受影响的资源组迁移到健康的节点上，实现故障恢复。 6. 网络分区处理：HACMP支持网络分区检测和恢复机制，即使在网络部分中断的情况下，也能保持集群的正常运行。 7. 配置和管理：HACMP提供了丰富的管理工具，如HACMP控制台和命令行接口，用于监控集群状态、配置资源组和执行故障切换操作。本指南还涵盖了安装、配置、监控和维护HACMP 6.1集群的具体步骤，包括设置集群网络、创建和管理资源组、定义故障策略以及进行性能优化等。此外，文档还包括对美国政府用户的特殊条款，强调了使用、复制和披露的限制。通过深入理解和应用HACMP 6.1的这些概念和功能，IT专业人员能够构建一个强大的高可用性环境，保障关键业务系统的稳定运行。同时，IBM提供了读者评论表单，鼓励用户对文档内容提供反馈，以不断改进产品文档的质量。

v Device-based network. Provides a point-to-point connection between two cluster nodes for HACMP

control messages and heartbeat traffic. Device-based networks do not use the TCP/IP protocol and,

therefore, continue to provide communications between nodes in the event the TCP/IP subsystem on a

server node fails.

Target mode SCSI devices, Target Mode SSA devices, disk heartbeat devices, or RS232 point-to-point

devices are defined as device-based networks.

Clients

A client is a processor that can access the nodes in a cluster over a local area network.

Clients each run a ″front end″ or client application that queries the server application running on the

cluster node. The HACMP software provides a highly available environment for critical data and

applications on cluster nodes. The HACMP software does not make the clients themselves highly

available. AIX clients can use the Cluster Information (Clinfo) services to receive notice of cluster events.

Clinfo provides an API that displays cluster status information. HACMP provides a cluster status utility,

the /usr/es/sbin/cluster/clstat. It is based on Clinfo and reports the status of key cluster components—the

cluster itself, the nodes in the cluster, the network interfaces connected to the nodes, and the resource

groups on each node. The cluster status interface of the clstat utility includes web-based, Motif-based and

ASCII-based versions.

Related concepts

“Cluster information program” on page 36

The Cluster Information Program (Clinfo), the clinfo daemon, is an SNMP-based monitor.

Goal of HACMP: Eliminating scheduled downtime

The primary goal of high availability clustering software is to minimize, or ideally, eliminate, the need to

take your resources out of service during maintenance and reconfiguration activities.

HACMP software optimizes availability by allowing for the dynamic reconfiguration of running clusters.

Most routine cluster maintenance tasks, such as adding or removing a node or changing the priority of

nodes participating in a resource group, can be applied to an active cluster without stopping and

restarting cluster services. In addition, you can keep an HACMP cluster online while making

configuration changes by using the Cluster Single Point of Control (C-SPOC) facility. C-SPOC makes cluster

management easier, as it allows you to make changes to shared volume groups, users, and groups across

the cluster from a single node. The changes are propagated transparently to other cluster nodes.

HACMP cluster nodes, sites, networks, and heartbeating

This chapter introduces major cluster topology-related concepts and definitions that are used throughout

the documentation and in the HACMP user interface.

Cluster nodes and cluster sites

A typical HACMP cluster environment consists of nodes that can serve as clients or servers. If you are

using the HACMP/XD software or LVM cross-site mirroring, sites or groups of nodes become part of the

cluster topology.

Nodes

A node is a processor that runs both AIX and the HACMP software.

Nodes may share a set of resources - disks, volume groups, file systems, networks, network IP addresses,

and applications. The HACMP software supports from two to thirty-two nodes in a cluster. In an

HACMP cluster, each node is identified by a unique name. In HACMP, a node name and a hostname can

usually be the same. Nodes serve as core physical components of an HACMP cluster. For more

information on nodes and hardware, see the section Nodes. Two types of nodes are defined:

8 High Availability Cluster Multi-Processing for AIX: Concepts and facilities guide

v Server nodes form the core of an HACMP cluster. Server nodes run services or back end applications

that access data on the shared external disks.

v Client nodes run front end applications that retrieve data from the services provided by the server

nodes. Client nodes can run HACMP software to monitor the health of the nodes, and to react to

failures.

Server nodes

A cluster server node usually runs an application that accesses data on the shared external disks. Server

nodes run HACMP daemons and keep resources highly available. Typically, applications are run, storage

is shared between these nodes, and clients connect to the server nodes through a service IP address.

Client nodes

A full high availability solution typically includes the client machine that uses services provided by the

servers. Client nodes can be divided into two categories: naive and intelligent.

v A naive client views the cluster as a single entity. If a server fails, the client must be restarted, or at

least must reconnect to the server.

v An intelligent client is cluster-aware. A cluster-aware client reacts appropriately in the face of a server

failure, connecting to an alternate server, perhaps masking the failure from the user. Such an intelligent

client must have knowledge of the cluster state.

HACMP extends the cluster paradigm to clients by providing both dynamic cluster configuration

reporting and notification of cluster state changes, such as changes in subsystems or node failure.

Related concepts

“Nodes” on page 6

Nodes form the core of an HACMP cluster. A node is a processor that runs AIX, the HACMP software,

and the application software.

Sites

You can define a group of one or more server nodes as belonging to a site.

The site becomes a component, like a node or a network, that is known to the HACMP software.

HACMP supports clusters divided into two sites. Using sites, you can configure cross-site LVM

mirroring. You configure logical volume mirrors between physical volumes in separate storage arrays,

and specify to HACMP which physical volumes are located at each site. Later, when you use C-SPOC to

create new logical volumes, HACMP automatically displays the site location of each defined physical

volume, making it easier to select volumes from different sites for LVM mirrors. In addition, the

HACMP/XD (Extended Distance) feature provides two distinct software solutions for disaster recovery.

These solutions enable an HACMP cluster to operate over extended distances at two sites.

v HACMP/XD for Metro Mirror increases data availability for DS8000

volumes, DS6000

™

volumes, and

IBM TotalStorage

Enterprise Storage Server

(ESS) volumes that use Peer-to-Peer Remote Copy

(PPRC) to copy data to a remote site for disaster recovery purposes. HACMP/XD for Metro Mirror

takes advantage of the PPRC fallover/fallback functions and HACMP cluster management to reduce

downtime and recovery time during disaster recovery.

When PPRC is used for data mirroring between sites, the physical distance between sites is limited to the

capabilities of the ESS hardware.

v HACMP/XD for Geographic Logical Volume Manager (GLVM) increases data availability for IBM volumes

that use GLVM to copy data to a remote site for disaster recovery purposes. HACMP/XD for GLVM

takes advantage of the following components to reduce downtime and recovery time during disaster

recovery:

v AIX and HACMP/XD for GLVM data mirroring and synchronization. Both standard and enhanced

concurrent volume groups can be made geographically mirrored with the GLVM utilities.

Concepts and facilities guide 9

v TCP/IP-based unlimited distance network support (up to four XD_data data mirroring networks can

be configured).

v HACMP cluster management. HACMP ensures that in case of component failures, a mirrored copy of

the data is accessible at either local or remote site. Both concurrent and non-concurrent resource groups

can be configured in an HACMP cluster with GLVM, however, inter-site policy should not be

concurrent.

For information about HACMP/XD for Metro Mirror, and HACMP/XD for GLVM, see the

documentation for each of those solutions.

Related information

Planning guide

Metro Mirror: Planning and administration

Geographic LVM Planning and administration

Cluster networks

Cluster nodes communicate with each other over communication networks.

If one of the physical network interface cards on a node on a network fails, HACMP preserves the

communication to the node by transferring the traffic to another physical network interface card on the

same node. If a ″connection″ to the node fails, HACMP transfers resources to another node to which it

has access.

In addition, RSCT sends heartbeats between the nodes over the cluster networks to periodically check on

the health of the cluster nodes themselves. If HACMP detects no heartbeats from a node, a node is

considered as failed and resources are automatically transferred to another node.

We highly recommend configuring multiple communication paths between the nodes in the cluster.

Having multiple communication networks prevents cluster partitioning, in which the nodes within each

partition form their own entity. In a partitioned cluster, it is possible that nodes in each partition could

allow simultaneous non-synchronized access to the same data. This can potentially lead to different views

of data from different nodes.

Related concepts

“Heartbeating over networks and disks” on page 15

A heartbeat is a type of a communication packet that is sent between nodes. Heartbeats are used to

monitor the health of the nodes, networks and network interfaces, and to prevent cluster partitioning.

Physical and logical networks

A physical network connects two or more physical network interfaces.

There are many types of physical networks, and HACMP broadly categorizes them as those that use the

TCP/IP protocol, and those that do not:

v TCP/IP-based , such as Ethernet or Token Ring

v Device-based , such as RS232 or TM SSA.

As stated in the previous section, configuring multiple TCP/IP-based networks helps to prevent cluster

partitioning. Multiple device-based networks also help to prevent partitioned clusters by providing

additional communications paths in cases when the TCP/IP-based network connections become

congested or severed between cluster nodes.

Note: If you are considering a cluster where the physical networks use external networking devices to

route packets from one network to another, consider the following: When you configure an HACMP

cluster, HACMP verifies the connectivity and access to all interfaces defined on a particular physical

network. However, HACMP cannot determine the presence of external network devices such as bridges

10 High Availability Cluster Multi-Processing for AIX: Concepts and facilities guide

and routers in the network path between cluster nodes. If the networks have external networking devices,

ensure that you are using devices that are highly available and redundant so that they do not create a

single point of failure in the HACMP cluster.

A logical network is a portion of a physical network that connects two or more logical network

interfaces/devices. A logical network interface/device is the software entity that is known by an

operating system. There is a one-to-one mapping between a physical network interface/device and a

logical network interface/device. Each logical network interface can exchange packets with each logical

network interface on the same logical network.

If a subset of logical network interfaces on the logical network needs to communicate with each other

(but with no one else) while sharing the same physical network, subnets are used. A subnet mask defines

the part of the IP address that determines whether one logical network interface can send packets to

another logical network interface on the same logical network.

Logical networks in HACMP:

HACMP has its own, similar concept of a logical network.

All logical network interfaces in an HACMP network can communicate HACMP packets with each other

directly. Each logical network is identified by a unique name. If you use an automatic discovery function

for HACMP cluster configuration, HACMP assigns a name to each HACMP logical network it discovers,

such as net_ether_01. An HACMP logical network may contain one or more subnets. RSCT takes care of

routing packets between logical subnets.

Related concepts

“HACMP cluster hardware and software” on page 29

You can use different types of IBM hardware with HACMP to implement the base level of a highly

available environment.

Global networks:

A global network is a combination of multiple HACMP networks.

The HACMP networks may be composed of any combination of physically different networks, and/or

different logical networks (subnets), as long as they share the same network type, (for example, ethernet)

and the networks can communicate with each other through some external device (such as a bridge or

router). Global networks allow you to combine networks where subnetting rules would not necessarily

indicate the networks are reachable from one another. HACMP treats the combined global network as a

single network. RSCT handles the routing between the networks defined in a global network. Global

networks cannot be defined for all IP-based networks but only for those IP-based networks that are used

for heartbeating. Having multiple heartbeat paths between cluster nodes reduces the chance that the loss

of any single network results in a partitioned cluster.

Local and global network failures:

When a failure occurs on a cluster network, HACMP uses network failure events to manage such cases.

HACMP watches for and distinguishes between two types of network failure events: local network

failure and global network failure events.

Local network failure

A local network failure is an HACMP event in which packets cannot be sent or received by one node over

an HACMP logical network. This may occur, for instance, if all of the node’s network interface cards

participating in the particular HACMP logical network fail. Note that in the case of a local network

failure, the network is still in use by other nodes. To handle local network failures, HACMP selectively

Concepts and facilities guide 11

moves the resources (on that network) from one node to another. This operation is referred to as selective

fallover.

Global network failure

A global network failure is an HACMP event in which packets cannot be sent or received by any node over

an HACMP logical network. This may occur, for instance, if the physical network is damaged. Note: It is

important to distinguish between these two terms in HACMP: a “global network” and a “global network

failure event.” A global network is a combination of HACMP networks; a global network failure event

refers to a failure that affects all nodes connected to any logical HACMP network, not necessarily a global

network.

HACMP communication interfaces

An HACMP communication interface is a grouping of a logical network interface, a service IP address and a

service IP label that you defined in HACMP.

HACMP communication interfaces combine to create IP-based networks. An HACMP communication

interface is a combination of:

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

network interface card.

v A service IP address is an IP address (for example, 129.9.201.1) over which services, such as an

application, are provided, and over which client nodes communicate.

v A service IP label is a label (for example, a hostname in the /etc/hosts file, or a logical equivalent of a

service IP address, such as node_A_en_service) that maps to the service IP address.

Communication interfaces in HACMP are used in the following ways:

v A communication interface refers to IP-based networks and NICs. The NICs that are connected to a

common physical network are combined into logical networks that are used by HACMP.

v Each NIC is capable of hosting several TCP/IP addresses. When configuring a cluster, you define to

HACMP the IP addresses that HACMP monitors (base or boot IP addresses), and the IP addresses that

HACMP keeps highly available (the service IP addresses).

v Heartbeating in HACMP occurs over communication interfaces. HACMP uses the heartbeating facility

of the RSCT subsystem to monitor its network interfaces and IP addresses. HACMP passes the network

topology you create to RSCT, while RSCT provides failure notifications to HACMP.

HACMP communication devices

HACMP also monitors network devices that are not capable of IP communications. These devices include

RS232 connections, diskhb connections, mndiskhb connections, and Target Mode (disk-based) connections.

Device-based networks are point-to-point connections that are free of IP-related considerations such as

subnets and routing—each device on a node communicates with only one other device on a remote node.

Communication devices make up device-based networks. The devices have names defined by the operating

system (such as tty0). HACMP allows you to name them as well (such as TTY1_Device1).

For example, an RS232 or a point-to-point connection would use a device name of /dev/tty2 as the

device configured to HACMP on each end of the connection. Two such devices need to be defined - one

on each node.

Note: The previous sections that described local and global network failures are true for TCP/IP-based

HACMP logical networks. For device-based HACMP logical networks, these concepts do not apply.

However, the heartbeating process occurs on device-based networks.

12 High Availability Cluster Multi-Processing for AIX: Concepts and facilities guide

剩余107页未读，继续阅读

hnwenyu

粉丝: 2
资源: 2

IBM HACMP 6.1 for AIX：高可用性集群多处理概念指南

IBM_红皮书_HACMP_V5.1_for_AIX_中文版

AIX Version 6.1

HACMP6.1_安装配置手册v1.0

hacmp 日常系统管理

hacmp、集群、多实例三种实现mq

华为防火墙ssh配置命令

redia和MySQL怎么保证同步

高可用集群软件（HACMP）的安装和使用

AIX6.1操作系统及HACMP版本和补丁升级

IBM HACMP的安装

最新资源