Beruflich Dokumente
Kultur Dokumente
new capabilities to reduce the number of AIX operating system images that need to be maintained
when consolidating multiple workloads on a single server.
WPARs will provide a way for clients to run multiple applications inside the same instance of an
AIX operating system while providing security and administrative isolation between applications.
We will discuss the GE (Global environment) and WPAR (Workload partitions) and, VWPAR (Ver
sioned WPAR) in further.
The status of the wpar can be checked by #lswpar command on the GE.
Defined (D)
The workload partition has been defined by the mkwpar command and is ready for use. But is not
active. Start workload partitions in this state with the startwpar command..
Loaded (L)
The workload partition has been configured in kernel, but processes have not yet been started.
Active (A)
The workload partition is running normally.
Frozen (F)
A checkpoint operatin is initiated, and the processes of the wpar are quiesced, awaiting the storing
phase.
Paused (P)
A checkpoint or restart operation has been performed and the wpar processes are ready to tbe
resumed or killed.
Broken (B)
An Administrative operation failed, leaving this workload partition is an unusable state.
Transitional (T)
An administrative operation is in progress, the wpar is in process of being created, started,
stopped, configured and so on.
Rootvg WPAR:
A system WPAR which is configured with its own root volume group on one or more dedicated
storage devices is called a rootvg WPAR.
System WPAR:
A system WPAR which is not a rootvg WPAR does not have its own root volume group, but has
file systems created in logical volumes created out of the root volume group of the global system.
1) Reduced AIX System administration
2) Application encapsulation, monitoring and control
3) Rapid environment creation of a new application
4) Separated system admin/ Security at application level.
5) Live application mobility
6) Reduced memory use (Minimum wpar=65MB)
7) Rapidly create a new AIX environment in minutes
Global Environment:
The Global Environment has an all-encompassing view of processes, Filesystems, Devices, and
other User level objects and system level objects within an AIX operating system.
The Global Environment is the same as the traditional AIX login environment. This Environment
allows you to view and interact with processes, filesystems, and other system components that are
assigned to an active WPAR on the system.
You can create new WPARs only in the Global Environment. Many Administrative tasks can be
performed only from the Global Environment.
WPAR:
Consolidation of isolated workloads with a single AIX instance.
VWPAR:
A versioned workload partition (VWPAR) provides a different version runtime environment than
the global system.
i.e Global Environment is 7.1 and inside WPAR is in 5.3, this environment is called VWPAR.
One of my customers was configuring a new AIX 5.3 Versioned WPAR when they came across a
very interesting issue. I thought I’d share the experience here, just in case anyone else comes
across the problem. We configured the VWPAR to host an old application. The setup was
relatively straight forward, restore the AIX 5.3 mksysb into the VWPAR and export the data disk
from the Global into the VWPAR, import the volume group and mount the file systems. Job done!
However, we noticed some fairly poor performance during application load tests. After some
investigation we discovered that disk I/O performance was worse in the VWPAR than on the
source LPAR. The question was, why?
We initially suspected the customers SAN and/or the storage subsystem, but both of these came
back clean with no errors or configuration issues. In the end, the problem was related to a lack of
ODM attributes in the PdAt object class, which prevented the VWPAR disk from using the correct
queue depth setting.
# uname -W
0
We set the disk queue depth to an appropriate number, in this case 256.
Note: This value will differ depending on the storage subsystem type, so check with your storage
team and/or vendor for the best setting for your environment.
Using the lsattr command, we verify that the queue depth attribute is set correctly in both the
ODM and the AIX kernel.
We can also use kdb to verify the setting in the kernel. Remember at this stage, we are
concentrating on hdisk3, which is referenced with a specific kernel device address in kdb.
From the output above, we can see that the queue depth is correctly i.e. set to 0x100 in Hex (256
in decimal).
Next, we export hdisk3 to the VWPAR using the chwpar command. The disk, as expected, enters a
Defined state in the Global environment. It is known as hdisk1 in the VWPAR.
In the VWPAR, we run cfgmgr to discover the disk. We create a new data volume group (datavg)
and file system (datafs) for application use (note: the steps to create the VG and FS are not shown
below). This is for demonstration purposes only; the customer imported the data volume groups
on their system.
# clogin p8wpar1
*******************************************************************************
* *
* Welcome to AIX Version 5.3! *
* *
* Please see the README file in /usr/lpp/bos for information pertinent to *
* this release of the AIX Operating System. *
* *
*******************************************************************************
Last login: Sun Apr 26 21:27:03 2015 on /dev/Global from
# uname -W
11
# lspv
hdisk0 00f94f58a0b98ca2 rootvg active
# cfgmgr ; lspv
hdisk0 00f94f58a0b98ca2 rootvg active
hdisk1 none None
# lsvg
rootvg
datavg
# lsvg -l datavg
datavg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
datalv jfs2 1024 1024 1 open/syncd /datafs
loglv00 jfs2log 1 1 1 open/syncd N/A
We perform a very simple I/O test in the /datafs file system. We write/create a 1GB file and time
the execution. We noticed immediately that the task took longer than expected.
# cd /datafs
# time lmktemp Afile 1024M
Afile
We ran the iostat command, from the Global environment, and noticed that “serv qfull” was
constantly non-zero (very large numbers) for hdisk3. Essentially the hdisk queue was full all the
time. This was bad and unexpected, given the queue depth setting of 256!
# iostat -DTRl 1
Now comes the interesting part. With a little help from our friends in IBM support, using kdb we
found that the queue depth was reported as being set to 1 in the kernel and not 256! You’ll also
notice here that the hdisk name has changed from hdisk3 to hdisk1. This happened as a result of
exporting hdisk3 to the VWPAR. The disk is known as hdisk1 in the VWPAR (not hdisk3) but the
kernel address is the same.
The kdb output above proved that the queue depth was set to 1 in the VWPAR. Even though the
ODM still had the attribute set to 256 (in both the Global and VWPAR environments).
APAR status
Error description
3. stopwpar -N <wpar_name>
Local fix
N/A
Problem summary
Fortunately, IBM support was able to provide us with a workaround. The first step was to add the
missing vparent PdAt entry to the ODM in the Global environment.
# cat addodm_pdat_for_vparent.txt
PdAt:
uniquetype = "wio/common/vparent"
attribute = "naca_1_spt"
deflt = "1"
values = "1"
width = ""
type = "R"
generic = ""
rep = "n"
nls_index = 0
# odmadd addodm_pdat_for_vparent.txt
# odmget PdAt | grep -p "wio/common/vparent"
PdAt:
uniquetype = "wio/common/vparent"
attribute = "naca_1_spt"
deflt = "1"
values = "1"
width = ""
type = "R"
generic = ""
rep = "n"
nls_index = 0
# clogin p8wpar1
# uname -W
11
In the VWPAR, we removed the hdisk and then discovered it again, ensuring that the queue depth
attribute was set to 256 in the ODM.
# uname –W
11
# rmdev -dl hdisk1
hdisk1 deleted
# cfgmgr
# lspv
hdisk0 00f94f58a0b98ca2 rootvg active
hdisk1 none None
# lsattr -El hdisk1 –a queue_depth
queue_depth 256 Queue DEPTH True
# odmget CuAt | grep -p queue
CuAt:
name = "hdisk1"
attribute = "queue_depth"
value = "256"
type = "R"
generic = "UD"
rep = "nr"
nls_index = 12
Back in the Global environment we checked that the queue depth was set correctly in the kernel.
And it was!
# uname -W
0
# echo scsidisk 0xF1000A01C014C000 | kdb | grep queue_depth
ushort queue_depth = 0x100;
We re-ran the simple I/O test and immediately found that the test ran faster and the hdisk queue
(for hdisk3, as shown by iostat from the Global environment) was no longer full. Subsequent
application load tests showed much better performance.
# iostat -DTRl 1
Please Note: kdb will not work inside a WPAR. If you attempt to run it, you’ll receive the
following error message. Run kdb from the Global environment instead.
# clogin p8wpar1
# kdb
The specified kernel file is a 64-bit kernel
open: A file or directory in the path name does not exist.
cannot open /dev/pmem