Using a Script to Migrate CPUs
Having
booted the vPars and with them up and running, the example could stop
here. Each of the vPars is running as an independent operating system
with full operating system isolation. However, there are two unused
CPUs in the nPartition. Furthermore, the nature of the workloads in zoo24 and zoo25
allows the CPUs to be migrated between the two vPars, which would mean
better performance for each of the workloads during their peak
utilization times.
The
CPUs could be migrated manually on demand, but a preferred method would
be an automated process for moving CPUs when they are needed. The
script shown in Listing 18
automates the process of migrating a specified number of CPUs from one
vPar to another. The script starts by parsing the command-line
arguments and ensuring that all required arguments are given. The final
steps remove the specified number of CPUs from the source vPar and add
the CPUs to the destination vPar.
While
this script illustrates the flexibility of vPars and the power provided
by having the ability to dynamically move CPUs based on workload
demand, it isn't suited for production use. Most important, it does no
error-checking to ensure that the commands will succeed. Instead, it
just tries to perform the operation and if it doesn't work, it returns
the error. In addition, before this script is initially executed, the
two unassigned CPUs must be assigned to one of the vPars.
Listing 18. Script for Migrating CPUs
#!/usr/bin/sh
# ***************************************************************
# Migrate CPUs
# ---------------------------------------------------------------
#
# Usage:
# migrate_cpus -s <source vpar> -d <dest vpar> -c <count>
#
# Description:
#
# This script will move <count> CPUs from <source vpar> to
# <dest vpar>.
#
# This script is for illustration purposes only.
#
# ***************************************************************
#
# Initialize variables
#
SOURCE=""
DEST=""
COUNT=""
USAGE="migrate_cpus -s <source vpar> -d <dest vpar> -c <count>"
#
# Parse the command line arguments, see getopt(1) for usage details.
#
set -- $(getopt c:d:s: $*)
if [ $? -ne 0 ]; then
print -u2 "$USAGE"
exit 1
fi
while [ $# -gt 0 ]; do
case "$1" in
'-c')
COUNT=$2
shift 2
;;
'-d')
DEST=$2
shift 2
;;
'-s')
SOURCE=$2
shift 2
;;
--)
break # this is the end of parameters
;;
esac
done
#
# Ensure all of the required parameters were specified
#
if [ -z "$SOURCE" -o -z "$DEST" -o -z "$COUNT" ]; then
print -u2 "ERROR: Missing required argument(s)"
print -u2 "$USAGE"
exit 1
fi
vparmodify -p $SOURCE -d cpu::$COUNT || exit $?
sleep 10
vparmodify -p $DEST -a cpu::$COUNT
exit $?
|
The sleep command between the two vparmodify commands is required because the removal of CPUs from a vPar is asynchronous. The vparmodify
command that removes the CPUs will return immediately. However, the
CPUs will be delayed for an indeterminate amount of time before they
are actually removed from the vPar and become available for assignment
to another vPar. This is a result of pending threads and processes
being serviced by the CPUs. A 10-second sleep is sufficient for most
cases, but in fact a busy system could delay the removal of CPUs even
longer. This script could be enhanced to poll the vparstatus command to check for the availability of the removed CPU.
Using Cron to Automatically Migrate CPUs
The migrate_cpus
script doesn't provide much value alone. For manual CPU migration,
simply invoking the two vparmodify commands in succession isn't
difficult. The value of a script such as migrate_cpus is
realized when it is integrated with a task scheduler such as cron. In
this case, two cron entries results in a simple but dynamic computing
environment. The migrate_cpus command could be added as a set of cron entries such as:
# crontab -l
00 22 * * * /usr/local/bin/migrate_cpus -s zoo24 -d zoo25 -c 2
00 06 * * * /usr/local/bin/migrate_cpus -s zoo25 -d zoo24 -c 2
The combination of the migrate_cpus
script and the cron entries illustrates the power and flexibility
provided by vPars. However, there are several technical issues with
this solution. The migrate_cpus script has no concept of what
the initial and final states should be. As a result, it is unable to
ensure that the configuration is correct at the end of the script. For
example, assume that the 10-second delay is not adequate for the
removed CPUs to become available. In this situation, assigning the CPUs
to the destination vPar would fail. Assuming no user intervention, the
next time the script was executed, the first vparmodify command that
removes the CPUs from the source vPar would fail. This effectively
would result in no CPUs being migrated until an administrator manually
intervened and corrected the situation. The HP Virtual Server
Environment has a robust solution for this problem.
Shutting Down Virtual Partitions
Virtual partitions are shut down and rebooted independent of one another using the traditional HP-UX reboot and shutdown commands. The only recommended modification to the shutdown process is to run the vparstatus
command immediately before shutting down the operating system. This
forces the vPar monitor's in-memory copy of the database to be
synchronized with the file on the vPar's file system. This ensures that
the copy of the database on the vPar's file system reflects the most
recent configuration changes that may have been made. In a dynamic
environment where CPUs are being migrated from one vPar to another on a
regular basis, this is especially important.
When
vPars are running within nPartitions, there is a special situation that
should be understood. If a change is made to an active nPartition
containing vPars that results in a pending SCCD such as removing a cell
from an nPartition, then all of the vPars must be shut down before the
change can take effect. When a pending SCCD is present and a vPar is
rebooted, the vPar will not be restarted until all of the vPars are
shutdown and the nPartition becomes inactive. This is true regardless
of the auto attribute for the vPar. Therefore, it is recommended that
changes to an nPartition containing vPars that require the nPar to be
shut down for reconfiguration be performed when all of the vPars are in
the down state and the cells are inactive.
