PowerHA profile "Turn"

Turn from: http://www.ibm.com/developerworks/cn/aix/library/au-powerhaintro/

Brief introduction

As business requirements grow, critical applications must remain available and the system must be tolerant of failures. However, the cost of these fault tolerant systems is high. As a result, these capabilities need to be provided through the application, and the application should also be economical and efficient.

A high-availability solution ensures that any component of the solution fails without the user being able to use the application and its data. The way to achieve this is to eliminate or obscure planned and unplanned outages by eliminating a single point of failure. In addition, special hardware is not required to maintain high availability of applications. PowerHA does not perform administrative tasks such as backups, time synchronization, and any application-related configuration.

Figure 1 is a schematic diagram of the failover feature. When one server is down, another server takes over.
Figure 1. Failover capabilities

Overview of the PowerHA

The two words PowerHA and HACMP can be used interchangeably. As mentioned earlier, it eliminates a single point of failure (SPOF). The following table lists the possible SPOF:

Cluster Objects	ways to eliminate SPOF
Node	Using multiple nodes
Power	Use multiple circuits or uninterruptible power supplies
Network adapters	Using a redundant network adapter
Internet	Using Multiple network connection nodes
TCP/IP Subsystem	Connecting neighboring nodes and clients using a non-IP network
Disk adapters	Using redundant disk adapters or Multipath hardware
Disk	Use multiple disks and mirrors or raid
Application	Add the node to take over; Configure Application monitor
VIO Server	Implementing a dual VIO server
Site	Add additional Sites

The primary goal is to have another server take over when one of the two servers fails. PowerHA Cluster technology provides redundancy for failover protection while extending horizontally through concurrent/parallel access support.

PowerHA Terminology

PowerHA uses many terms. They can be divided into two categories: topological components and resource components.

The topology component is basically a physical component. They include: node : System P server can be a separate partition or VIOS client network : IP Network and non-IP network communication interface : Token Ring or Ethernet adapter communication Device : RS232 or The heartbeat mechanism of the disk

Resource components are logical entities that need to maintain high availability. They include: application Server : It involves the application's start/Stop script. Service IP Address : End users typically connect to an application via an IP address. This IP address maps to the node where the application is actually running. Because the IP address needs to remain highly available, it belongs to the resource group. File System : Many applications need to mount file systems. Volume Groups : Many applications require a highly available volume group.

All resources together constitute a resource group entity. PowerHA the resource group as a single unit. It maintains a high availability of resource groups. A resource group has a policy associated with it. These policies include: start policy : This determines which node the resource group should activate. failover Policy : When a failure occurs, this determines the failover target node. Recovery Policy : This determines whether the resource group performs failback.

When a failure occurs, PowerHA looks for these policies and performs the appropriate actions.

subsystem of the PowerHA
Figure 2. subsystem of the PowerHA

The illustration above illustrates that PowerHA consists of a number of software components: The Cluster Manager clstrmgr is the core process that monitors cluster membership. The cluster Manager contains the topology manager for the management topology component, the resource manager for the Management Resource group, the event manager and event scripts that work through the RMC facility, and the RSCT that responds to the failure. The Clinfo process provides APIs for communicating between the cluster manager and the application. Clinfo also provides remote monitoring capabilities to run scripts when the cluster state changes. In PowerHA 5, Clcomdes enables the cluster manager to communicate in a secure manner without the need to use RSH and/.rhost files.

Configuring two node clusters

Before you start researching configurations, discuss PowerHA networking and storage considerations.

Web-connected

PowerHA uses network probing and diagnosing failures and provides high availability application access to clients.

Communication between nodes is also through the network. PowerHA directly detects three types of failures: Network, NIC, and node failures. It performs detection and diagnostics by using the RSCT daemon. RSCT actually detects whether a heartbeat packet sent across all networks is missing and is accurately lost (network, NIC, or node failure).

Figure 3 illustrates that all NICs transmit and receive heartbeat packets, which helps to diagnose failures.
Figure 3. Clusters formed from heartbeat packets

If the heartbeat packet's transmission stops, then two nodes will assume that the other is down, so try to get the resource group online. This can lead to massive data destruction.

To avoid this problem, PowerHA uses two types of networks: IP networks : such as Ethernet, Ether channel, and other non-IP networks : For example, RS232 (to ensure that PowerHA can differentiate between networks even in the event of a network failure) Barrier and node failure, non-IP network required

IP address takeover (IPAT)

Most applications require IP to be highly available. To ensure this, we include the service IP address in the resource group. The process of transferring a service IP address from one NIC to another is called an IP address takeover. There are two ways to implement IPAT: IPAT: PowerHA uses the AIX IP alias feature to add the service IP address to the NIC by replacing it with IPAT: PowerHA Replacing the interface IP address with a service Ip

Store

Storage devices are broadly divided into two categories: private storage : shared storage by only one node: owned by multiple nodes in the cluster

Data for all applications resides on a shared storage device. To avoid data inconsistency, shared storage protection can be done in the following ways: Shared storage protection based on retention/release : For standard volume groups based on RSCT shared storage protection: For enhanced concurrent volume groups

HACMP 5.x supports RSCT shared storage protection, which relies on the Aixs RSCT component to control the ownership of shared storage when using an enhanced concurrent volume group in a concurrency-dependent fashion.

Configuration

The cluster must be scheduled appropriately before the configuration is started. You can use the Online planning worksheet (OLPW) to make your plans. The configuration of a two-node cluster is explained below. In this example, two nodes have three Ethernet adapters and two shared disks.

Step 1: Install the file set

After you install AIX, the first step is to install the required set of files. Install the following set of files. A set of RSCT and BOS files can be found on the AIX Basic edition CD. Installing the HACMP file set requires the purchase of a PowerHA license.

RSCT File Set rsct.compat.basic.hacmp rsct.compat.clients.hacmp rsct.basic.hacmp Rsct.basic.rte Rsct.opt.storagerm Rsct.crypt.des Rsct.crypt.3des rsct.crypt.aes256

BOS File Set Bos.data Bos.adt.libm Bos.adt.syscalls Bos.clvm.enh Bos.net.nfs.server

HACMP 5.5 File Set cluster.adt.es Cluster.es.assist Cluster.es.cspoc Cluster.es.plugins Cluster.assist.license Cluster.doc.en_US.assist cluster.doc.en_US.es Cluster.es.worksheets Cluster.license Cluster.man.en_US.assist cluster.man.en_US.es Cluster.es.client Cluster.es.server Cluster.es.nfs Cluster.es.cfs

After the set of files is installed, reboot the partition.

Step 2: Set the path

Next, you need to set the path. To do this, add the following code in the/.profile file:

Export path= $PATH:/usr/es/sbin/cluster:/usr/es/sbin/cluster/utilities

Step 3: Network configuration

Configure the IP address on the Ethernet adapter by following these steps:

#smitty tcpip-> Minimum Configuration and Startup-> Choose Ethernet Network

There are three Ethernet adapters. Two of these are configured with private IP addresses, and the other is configured with a public IP address.

Here, enter the value of the associated field for En0, which will configure the public IP address.
Figure 1. Configuration of public IP addresses

This configures the IP address and starts the TCP/IP service on it.

Configure private IP addresses on EN1 and en2 in a similar way.
Figure 2. Configuration of private IP addresses

This configures the private IP 10.10.210.21 for EN2 and initiates the TCP/IP service.

Next, you need to add IP addresses (including node1 and node2 IP addresses and service IP db2live) and labels in the/etc/hosts file. The content should look like this:

# Internet Address Hostname # Comments 127.0.0.1 loopback localhost # loopback (lo0) name/address 192.168.20.72 node1.in.ibm.com node1 192.168.20.201 node2.in.ibm.com node2 10.10.35.5 node2ha1 10.10.210.11 node2ha2 10.10.35.4 node1ha1 10.10.210.21 node1ha2 192.168.22.39 db2live

Note that for name resolution, you should include all three ports and related labels for each machine.

Perform similar operations on the Node2. Configure the public IP for the En0, configure the private IP for EN1 and EN2, and edit the/etc/hosts files.

To test these configurations, you can ping individual IP addresses from each machine.

Step 4: Storage configuration

In order to create a heartbeat through the FC disk, a shared storage is required. You need to allocate disks from the SAN. When two nodes are able to see the same disk (you can use the LUN number to confirm), configure the heartbeat through the disk.

In order to avoid the single point of failure of Ethernet network/switch/protocol, this method does not use Ethernet.

The first step is to determine the primary number that is available on all nodes.
Figure 3. Determine which primary number is available

Select a unique number. Here, we choose 100.

On Node1 , create a volume group "HBVG" on the shared disk "Hdisk1" with enhanced concurrency capabilities.

#smitty MKVG

Figure 4. Create a volume group

After you create the HBVG, you need to disable the Autovaryon flag. To do this, run the following command:

#chvg-an HBVG

Next, create a logical volume in the volume group "HBVG". Enter a logical volume name, such as HBLOGLV, select 1 as the logical partition number, select Jfslog as the type, and set the scheduling to sequential. Other options remain in the default values. Press ENTER.

#smitty MKLV

Figure 5. Creating logical Volumes

After the logical volume is created, initialize the logform.