The EOM date (end of marketing) has been announced for AIX 5.3: 04/11; meaning that AIX 5.3 will no longer be marketed by IBM from April 2011, and that it is now time for customers to start thinking about upgrading to AIX 6.1. The EOS (end of service) date for AIX 5.3 is 04/12, meaning AIX 5.3 will be serviced by IBM until April 2012. After that, IBM will only service AIX 5.3 for an additional fee. The EOL (end of life) date is 04/16, which is the end of life date at April 2016. The final technology level for AIX 5.3 is technology level 12. Some service packs for TL12 will be released though.

IBM has also announced EOM and EOS dates for HACMP 5.4 and PowerHA 5.5, so if you're using any of these versions, you also need to upgrade to PowerHA 6.1:

• Sep 30, 2010: EOM HACMP 5.4, PowerHA 5.5
• Sep 30, 2011: EOS HACMP 5.4
• Sep 30, 2012: EOS HACMP 5.5

Use this procedure to quickly configure an HACMP cluster, consisting of 2 nodes and disk heartbeating.

Prerequisites:

Make sure you have the following in place:

• Have the IP addresses and host names of both nodes, and for a service IP label. Add these into the /etc/hosts files on both nodes of the new HACMP cluster.
• Make sure you have the HACMP software installed on both nodes. Just install all the filesets of the HACMP CD-ROM, and you should be good.
• Make sure you have this entry in /etc/inittab (as one of the last entries):

  clinit:a:wait:/bin/touch /usr/es/sbin/cluster/.telinit

• In case you're using EMC SAN storage, make sure you configure you're disks correctly as hdiskpower devices. Or, if you're using a mksysb image, you may want to follow this procedure EMC ODM cleanup.

• Create the cluster and its nodes:

  # smitty hacmp
  Initialization and Standard Configuration
  Configure an HACMP Cluster and Nodes
  

  Enter a cluster name and select the nodes you're going to use. It is vital here to have the hostnames and IP address correctly entered in the /etc/hosts file of both nodes.
• Create an IP service label:

  # smitty hacmp
  Initialization and Standard Configuration
  Configure Resources to Make Highly Available
  Configure Service IP Labels/Addresses
  Add a Service IP Label/Address
  

  Enter an IP Label/Address (press F4 to select one), and enter a Network name (again, press F4 to select one).
• Set up a resource group:

  # smitty hacmp
  Initialization and Standard Configuration
  Configure HACMP Resource Groups
  Add a Resource Group
  

  Enter the name of the resource group. It's a good habit to make sure that a resource group name ends with "rg", so you can recognize it as a resource group. Also, select the participating nodes. For the "Fallback Policy", it is a good idea to change it to "Never Fallback". This way, when the primary node in the cluster comes up, and the resource group is up-and-running on the secondary node, you won't see a failover occur from the secondary to the primary node.
  
  Note: The order of the nodes is determined by the order you select the nodes here. If you put in "node01 node02" here, then "node01" is the primary node. If you want to have this any other way, now is a good time to correctly enter the order of node priority.
• Add the Servie IP/Label to the resource group:

  # smitty hacmp
  Initialization and Standard Configuration
  Configure HACMP Resource Groups
  Change/Show Resources for a Resource Group (standard)
  

  Select the resource group you've created earlier, and add the Service IP/Label.
• Run a verification/synchronization:

  # smitty hacmp
  Extended Configuration
  Extended Verification and Synchronization
  

  Just hit [ENTER] here. Resolve any issues that may come up from this synchronization attempt. Repeat this process until the verification/synchronization process returns "Ok". It's a good idea here to select to "Automatically correct errors".
• Start the HACMP cluster:

  # smitty hacmp
  System Management (C-SPOC)
  Manage HACMP Services
  Start Cluster Services
  

  Select both nodes to start. Make sure to also start the Cluster Information Daemon.
• Check the status of the cluster:

  # clstat -o
  # cldump
  

  Wait until the cluster is stable and both nodes are up.

# lspv | grep hdiskpower4
hdiskpower4   000a807f6b9cc8e5    None

• Create an concurrent volume group:

  # smitty hacmp
  System Management (C-SPOC)
  HACMP Concurrent Logical Volume Management
  Concurrent Volume Groups
  Create a Concurrent Volume Group
  

  Select both nodes to create the concurrent volume group on by pressing F7 for each node. Then select the correct PVID. Give the new volume group a name, for example "hbvg".
• Set up the disk heartbeat network:

  # smitty hacmp
  Extended Configuration
  Extended Topology Configuration
  Configure HACMP Networks
  Add a Network to the HACMP Cluster
  

  Select "diskhb" and accept the default Network Name.
• Run a discovery:

  # smitty hacmp
  Extended Configuration
  Discover HACMP-related Information from Configured Nodes
  

• Add the disk device:

  # smitty hacmp
  Extended Configuration
  Extended Topology Configuration
  Configure HACMP Communication Interfaces/Devices
  Add Communication Interfaces/Devices
  Add Discovered Communication Interface and Devices
  Communication Devices
  

  Select the disk device on both nodes by selecting the same disk on each node by pressing F7.
• Run a Verification & Synchronization again, as described earlier above. Then check with clstat and/or cldump again, to check if the disk heartbeat network comes online.

When you want to mount an NFS file system on a node of an HACMP cluster, there are a couple of items you need check, before it will work:

• Make sure the hostname and IP address of the HACMP node are resolvable and provide the correct output, by running:

  # nslookup [hostname]
  # nslookup [ip-address]
  

• The next thing you will want to check on the NFS server, if the node names of your HACMP cluster nodes are correctly added to the /etc/exports file. If they are, run:

  # exportfs -va

• The last, and tricky item you will want to check is, if a service IP label is defined as an IP alias on the same adapter as your nodes hostname, e.g.:

  # netstat -nr
  Routing tables
  Destination   Gateway       Flags  Refs  Use    If  Exp  Groups
  
  Route Tree for Protocol Family 2 (Internet):
  default       10.251.14.1   UG      4    180100 en1  -     -
  10.251.14.0   10.251.14.50  UHSb    0         0 en1  -     -
  10.251.14.50  127.0.0.1     UGHS    3    791253 lo0  -     -
  

  The example above shows you that the default gateway is defined on the en1 interface. The next command shows you where your Service IP label lives:

  # netstat -i
  Name  Mtu   Network   Address         Ipkts   Ierrs Opkts
  en1   1500  link#2    0.2.55.d3.75.77 2587851 0      940024
  en1   1500  10.251.14 node01          2587851 0      940024
  en1   1500  10.251.20 serviceip       2587851 0      940024
  lo0   16896 link#1                    1912870 0     1914185
  lo0   16896 127       loopback        1912870 0     1914185
  lo0   16896 ::1                       1912870 0     1914185
  

  As you can see, the Service IP label (in the example above called "serviceip") is defined on en1. In that case, for NFS to work, you also want to add the "serviceip" to the /etc/exports file on the NFS server and re-run "exportfs -va". And you should also make sure that hostname "serviceip" resolves to an IP address correctly (and of course the IP address resolves to the correct hostname) on both the NFS server and the client.

Issue when trying to bring up a resource group: For example, the hacmp.out log file contains the following:

cl_disk_available[187] cl_fscsilunreset fscsi0 hdiskpower1 false cl_fscsilunreset[124]: openx(/dev/hdiskpower1, O_RDWR, 0, SC_NO_RESERVE): Device busy cl_fscsilunreset[400]: ioctl SCIOLSTART id=0X11000 lun=0X1000000000000 : Invalid argument

• Enter into the SMIT fastpath for HACMP "smitty hacmp".
• Select Extended Configuration.
• Select Extended Resource Configuration.
• Select HACMP Extended Resources Configuration.
• Select Configure Custom Disk Methods.
• Select Add Custom Disk Methods.

      Change/Show Custom Disk Methods

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

                                                 [Entry Fields]
* Disk Type (PdDvLn field from CuDv)             disk/pseudo/power
* New Disk Type                                  [disk/pseudo/power]
* Method to identify ghost disks                 [SCSI3]
* Method to determine if a reserve is held       [SCSI_TUR]
* Method to break reserve [/usr/lpp/EMC/Symmetrix/bin/emcpowerreset]
  Break reserves in parallel                     true
* Method to make the disk available              [MKDEV]

In order to keep users and all their related settings and crontab files synchronized, here's a script that you can use to do this for you:

sync.ksh

HACMP is capable of using an alternative MAC address in combination with its service address. So, how do you set this MAC address without HACMP, just using the command line? (Could come in handy, in case you wish to configure the service address on a system, without having to start HACMP).

# ifconfig enX down
# ifconfig enX detach
# chdev -l entX -a use_alt_addr=yes
# chdev -l entX -a alt_addr=0x00xxxxxxxxxx
# ifconfig enX xxx.xxx.xxx.xxx
# ifconfig enX up

# ifconfig enX down
# ifconfig enX detach
# chdev -l entX -a use_alt_addr=no
# chdev -l entX -a alt_addr=0x00000000000

Some user accounts, mostly service accounts, may create a lot of email messages, for example when a lot of commands are run by the cron daemon for a specific user. There are a couple of ways to deal with this:

1. Make sure no unnecesary emails are sent at all

To avoid receiving messages from the cron daemon; one should always redirect the output of commands in crontabs to a file or to /dev/null. Also make sure to redirect STDERR as well:

0 * * * * /path/to/command > /path/to/logfile 2>&1
1 * * * * /path/to/command > /dev/null 2>&1

0 * * * * [ -x /path/to/command ] && /path/to/command > /path/to/logfile 2>&1

0 * * * * echo d1-$(let num="$(echo f|mail|tail -1|awk '{print $2}')-1000";echo $num)|mail >/dev/null

HACMP automatically runs a verification every night, usually around mid-night. With a very simple command you can check the status of this verification run:

# tail -10 /var/hacmp/log/clutils.log 2>/dev/null|grep detected|tail -1

# smitty clautover.dialog

# odmget HACMPcluster
# odmget HACMPtimersvc

With HACMP, you can run into the following error during a verification/synchronization:

WARNING: The LVM time stamp for shared volume group: testvg is inconsistent with the time stamp in the VGDA for the following nodes: host01

To correct the above condition, run verification & synchronization with "Automatically correct errors found during verification?" set to either 'Yes' or 'Interactive'. The cluster must be down for the corrective action to run.

This can happen when you've added additional space to a logical volume/file system from the command line instead of using the smitty hacmp menu. But you certainly don't want to take down the entire HACMP cluster to solve this message.

First of all, you don't. The cluster will fail-over nicely anyway, without these VGDA's being in sync. But, still, it is an annoying warning, that you would like to get rid off.

Have a look at your shared logical volumes. By using the lsattr command, you can see if they are actually in sync or not:

host01 # lsattr -Z: -l testlv -a label -a copies -a size -a type -a strictness -Fvalue
/test:1:809:jfs2:y:

host02 # lsattr -Z: -l testlv -a label -a copies -a size -a type -a strictness -Fvalue
/test:1:806:jfs2:y:

When you're using HACMP, you usually have multiple network adapters installed and thus multiple network interface to handle with. If AIX configured the default gateway on a wrong interface (like on your management interface instead of the boot interface), you might want to change this, so network traffic isn't sent over the management interface. Here's how you can do this:

First, stop HACMP or do a take-over of the resource groups to another node; this will avoid any problems with applications when you start fiddling with the network configuration.

Then open up a virtual terminal window to the host on your HMC. Otherwise you would loose the connection, as soon as you drop the current default gateway.

Now you need to determine where your current default gateway is configured. You can do this by typing:

# lsattr -El inet0
# netstat -nr

# odmget -q"attribute=route" CuAt

# lsattr -El inet0 | awk '$2 ~ /hopcount/ { print $2 }' | read GW
# chdev -l inet0 -a delroute=${GW}

# route add 0 [ip address of default gateway: xxx.xxx.xxx.254] -if enX

# chdev -l inet0 -a addroute=net,-hopcount,0,,0,[ip address of default gateway]

# chdev -l inet0 -a addroute=net,-hopcount,0,if,enX,,0,[ip address of default gateway]

# lsattr -El inet0
# odmget -q"attribute=route" CuAt