Optimizing Filesystem Layouts in AIX to Increase Performance

AIX

################################################################################
# Optimizing Filesystem Layouts in AIX to Increase Performance
################################################################################

# Regular logical volume striping is no longer a best-practice
# in AIX. The overhead is too high, the consequences of disk
# failure are too great, and it is frankly better done on your
# storage array than in your operating system. You can, however,
# do a form of “poor man’s striping” that can give you
# substantial performance gains by spreading I/O across multiple
# volumes in your volume groups. This procedure describes how to
# safely do this using INTER POLICY, reorgvg and defragfs.
#
# Requirements: You’ll ideally need a version of AIX where the
# defragfs command supports the “-f” flag. You can proceed
# without this, but for maximum efficacy, it’s the way to go.
# You’ll also need your volume groups to be spread over multiple
# physical volumes- this procedure does no good for single-disk
# VGs. Also- do not ever run this on rootvg for any reason.
# Ideally every disk in your VG should be the same size. If it
# is not, you’ll have problems growing filesystems later (a fix
# for this is provided below). These scripts take a LONG TIME to
# run- do not ever run them in the foreground as they can cause
# significant damage if interrupted. Depending on the age and
# workload on your SAN, this procedure might have a negative
# impact while actively running steps I and II. The performance
# gain after the change is usually quite significant, however.

# Procedure:

# I. This degfrags every filesystem on your machine. Skip this
# if your version of AIX does not support defragfs with the
# “-f” flag.
# Create a script in /tmp with the following contents
# (e.g.- vi /tmp/defrag.sh; chmod 755 /tmp/defrag.sh )
#

#!/bin/ksh
{
lsvg -o | while read a
do
lsvgfs $a | while read b
do
echo defrag of $a – $b:
timex defragfs -f -y $b
done
done
echo finished.
}

# Run it with the following:
cd /tmp
rm nohup.out
nohup ./defrag.sh &
tail -f nohup.out
# You’ll know it’s complete when you see “finished.” in the output
# at which point you can exit the tail -f with ctrl-C.

# II. This will set a maximum INTER-POLICY and then reorgvg the
# volume groups to get the best possible spread of I/O across
# the volumes.
# Once again – this does no good for volume groups on a single
# physical volume and you must never do this to rootvg.
# Create a script in /tmp with the following contents
# (e.g. vi /tmp/reorg.sh; chmod 755 /tmp/reorg.sh )

#!/bin/ksh
{
lsvg -o | grep -v rootvg | while read b
do
lsvg -l $b | tail -n +3 | awk ‘{ print $1 }’ | while read a
do
chlv -e x $a
done
echo reorgvg of $b:
timex reorgvg $b
done
echo “finished.”
}

# Run it with the following:
cd /tmp
rm nohup.out
nohup ./reorg.sh &
tail -f nohup.out
# This will take a very long time- frequently on the order of 24
# hours or more!
# You’ll know it’s complete when you see “finished.” in the output
# at which point you can exit the tail -f with ctrl-C.

# III. (optional) If the disks in your volume groups are of
# different sizes, you’ll find that you won’t be able to expand
# filesystems following part II above when the smallest disk
# becomes full. This is not a problem, you just need to turn off
# maximum INTER-POLICY that was set above. You can turn this on and
# off without a reboot or any real impact as follows. (Note this
# does not “undo” the work done above, but it will leave a part
# of the newly resized LVs not optimally striped. Repeating step
# II at a later time will fix this.
# Create a script in /tmp with the following contents
# (e.g. vi /tmp/minpol.sh; chmod 755 /tmp/minpol.sh )

#!/bin/ksh
{
lsvg -o | grep -v rootvg | while read b
do
lsvg -l $b | tail -n +3 | awk ‘{ print $1 }’ | while read a
do
chlv -e m $a
done
done
}
# Run it with the following:
cd /tmp
./minpol.sh

################################################################################

guvf-cebprqher-jnf-gnxra-sebz-orafubeg.pbz
rznvy-oybt@orafubeg.pbz-sbe-qrgnvyf

################################################################################

Using the IBM summ Command for Deeper Analysis of AIX errpt and Sense Data

AIX

################################################################################
# Using the IBM summ Command for Deeper Analysis of AIX errpt and Sense Data
################################################################################

################################################################################
# IBM unofficially offers a perl script called “summ” that will give you
# diagnostic information about I/O errors (mostly disk and disk adapters- but
# also some enhanced information about core dumps, dump devices, etc.) by
# analyzing the data and sense data in errpt. Below is some information about
# this tool.

# Requirements: You’ll need to download the summ script to an AIX machine- it
# doesn’t really need to be the same AIX machine that you want to analyze.
# The machine where summ runs must have perl installed.

# As of this writing (late 2019), you can get a tar file from IBM containing
# the newest version of summ from this link:

https://www.ibm.com/support/pages/sites/default/files/inline-files/$FILE/summ_version_1.tar

# (Note- the link above does not work with curl or wget. You must use a browser.)

# It’s always best to check for newer versions from the main summ page:

https://www.ibm.com/support/pages/node/1072626

# And if that has moved, then you can find it again from the AIX Support Center
# Tools webpage, found here:

https://www-01.ibm.com/support/docview.wss?uid=aixtools_home

# Simply un-tar the file and pipe “errpt -a” into it to run:

tar xvf ./summ_version_1.tar
errpt -a | ./summ

# You can also bring over “errpt -a” output from another machine to analyze:

errpt -a > my.errpt.txt
# transfer my.errpt.txt to the machine and directory containing summ
cat my.errpt.txt | ./summ

# When using summ to analyze disk errors, it will usually produce an error that
# ends with something like this:

EWRPROTECT
EFORMAT
..etc.

# If you are unfamiliar with these failure codes, you can look them up on any
# AIX machine in the file /usr/include/sys/errno.h for more information.
# e.g.:

$grep EWRPROTECT /usr/include/sys/errno.h
define EWRPROTECT 47 /* Write-protected media */

################################################################################
guvf-cebprqher-jnf-gnxra-sebz-orafubeg.pbz
rznvy-oybt@orafubeg.pbz-sbe-qrgnvyf
################################################################################

How To Test IBM i 5250 Console Connectivity for AIX Administrators

HMC, IBM i

################################################################################
# How To Test IBM i 5250 Console Connectivity for AIX Administrators
################################################################################

################################################################################
# As AIX or POWER Linux administrators it is often expected that we share our
# machines with IBM i (often still mis-called OS/400 or AS/400) LPARs. IBM i
# does not use vtmenu for its console- it uses telnet 5250 protocol. Since HMC
# connectivity is often left in the hands of the AIX administrators, I wrote
# the procedure below for testing 5250 connectivity in a way that your IBM i
# administrators will probably not want to use for their day-to-day operations.

# Requirements:
## A Linux machine that can reach your HMC on port 2300/tcp
## A login-enabled account on your HMC

# Procedure:
# Install the tn5250 client on your linux machine-
# Red Hat and several of its derivatives inherently have this package available:
$ yum list | grep 5250

tn5250.x86_64 0.17.4-10.el7 @rhel-7-server-rpms

tn5250.i686 0.17.4-10.el7 rhel-7-server-rpms

tn5250-devel.i686 0.17.4-10.el7 rhel-7-server-optional-rpms
tn5250-devel.x86_64 0.17.4-10.el7 rhel-7-server-optional-rpms

# In that case just run:
yum install tn5250

# If you are running a version of Linux that does not have the package
# available from the distribution’s package provider, you can get tn5250
# from here (there’s even a windows version):

http://tn5250.sourceforge.net/

# To connect, you’ll need to run something like this:

tn5250 map=37 env.TERM=IBM-3477-FC <hmc hostname or ip>:2300

# So, for example, if your HMC is called “hmc01”, the command would be:

tn5250 map=37 env.TERM=IBM-3477-FC hmc01:2300

# You’ll know immediately if you have connected properly or not, as you will
# be presented with a menu from which to select your locale. For US English
# enter:

21

# Or press <esc>+8 (press escape then type 8) to scroll through the other
# options.

# Press enter and you will be taken to the HMC login screen. Put in your
# username and password and press <enter>.
# You should now be presented with a list of your CECs (physical machines).
# Select a CEC by number and press enter. You will now see a list of the IBM i
# LPARs on that CEC. Put a 2 next to the LPAR you want to access and press
# <enter>. You will now be asked for a session key- type in whatever you
# like twice (there are some complexity rules, but nothing too challenging).
# Voila! You are now at the console of your IBM i LPAR.

# To disconnect, press <control>-q (this will write an error to the screen
# that does not seem to be avoidable).

# If you need to use function keys (F1-F12) then press the <esc> key
# followed by typing the number.

################################################################################
guvf-cebprqher-jnf-gnxra-sebz-orafubeg.pbz
rznvy-oybt@orafubeg.pbz-sbe-qrgnvyf
################################################################################