AIX
Booting Process explained below.
I.
Read
Only Storage Kernel Init Phase
Motherboard
is Checked - POST --> look for Bootlist if found (Detected by
ROS)------> look for boot image---Bootstrap code is loaded from
disk
-
BLV contains AIX Kernel, rc.boot scripts, reduced ODM, and boot
commands.
-
BLV get uncompressed in RAM and kernel gets released from it.
-
Then AIX kernel gets the control
-
AIX Kernel creates a RAMFS
-
Kernel Starts the init process from BLV
-
init executes rc.boot script from the BLV in the RAM
II.
Base
Device Configuration Phase
1.
All devices are configured with cfgmgr command - init process from
RAMFS executes rc.boot 1
-
restbase command copies ODM from BLV to RAMFS
-
cfgmgr will run and configure all the base devices
III.
System
Boot Phase
1.
Logical volumes are varied on - rc.boot 2 is executed.
-
ipl_varyon will varyon the rootvg
-
run fsck on / and mount the same to RAMFS
-
run fsck on /usr and mount the same to RAMFS
-
run fsck on /var and mount the same to RAMFS
2.
Paging is started - copycore command checks the occurrunce of the
dump and copies the same from primary dump device to /var/ras/adm
-
unmount /var and activate the paging space
-
mount /var
-
Now /, /usr and /var are mounted in rootvg in hdisk
3.
/etc/inittab is processed - Kernal remove RAMFS
-
init process is started from / in rootvg
-
in rc.boot3, init processes /etc/inittab and remaining devices are
configured.
-
/etc/init starts /etc/inittab and runs /sbin/rc.boot 3
-
run fsck on /tmp and mount the same.
-
syncvg for rootvg and reports the stale PPs
4.
Relevant Services according to run level starts. srcmstr daemon
controls this - starts the deamons like errdaemon, syncd etc..
*
AIX 6.1, November 9, 2007
o
Workload Partitions o Live Application Mobility
o
Role Based Access Control RBAC o AIX Security Expert hardening tool
o
Trusted AIX o Encrypting JFS2 filesystem
o
Trusted Execution o Concurrent Kernel Maintenance
o
Kernel exploitation of POWER6 storage keys o probevue dynamic
tracing
o
Systems Director Console for AIX o Integrated filesystem snapshot
o
Partition mobility on POWER6
*
AIX 5L 5.3, August 13, 2004
o
NFS Version 4 support o Advanced Accounting
o
Virtual SCSI o Virtual Ethernet
o
Simultaneous multithreading (SMT) support o Micro-Partitioning
support
o
POWER5 support o JFS2 quota support
o
JFS2 filesystem shrink support
*
AIX 5L 5.2, October 18, 2002
o
Introduced support for the IBM BladeCenter JS20 with the PowerPC 970.
o
Minimum level required for POWER5 hardware
o
Support for MPIO Fibre Channel disks
o
iSCSI Initiator software
o
Dynamic LPAR support
*
AIX 5L 5.1, May 4,2001
o
Introduced support for the IA-64 architecture, although this never
went beyond beta,[1]
o
Minimum level required for POWER4 hardware and the last release that
supported Micro Channel architecture
o
Introduction of 64-bit kernel, installed but not activated by default
o
JFS2
o
introduced Logical Partitioning on POWER4
o
The L stands for Linux affinity
o
Trusted Computing Base (TCB)
Startup
Mode
Normal
Mode
Login
Prompts
All
processes running
Multi
User Mode
System
Management Services
Not
AIX
Runs
from firmware
sets
boot list
Maintainance
Mode
Maintainance
Menu
Recover
root password
Fix
machines that wont boot
Dignostic
AIX
diagnostic
If
device state is
undefined------>Supported
Devices------->Predefined Database
defined--------->Not
Usable------------------>Customized Database
Available---
--->Ready for use-------------->Customized Database
Seven
types supported:
Journaled
File System (JFS)
Enhanced
Journaled File System (JFS2)
CD-ROM
File System (CDRFS)
DVD-ROM
File System (UDFS)
Network
File System (NFS)
Common
Internet Filesystem (CIFS)
Proc
File System (PROCFS)
Defaults
Lvs and Filesystems on it
AIX
Installation method
New
and Complete Overwrite Installation:
You
have a new machine without a prior or useful system installation. You
want to install onto a hard disk that contains an existing root
volume group that you wish to completely overwrite. You want to
reassign your hard disks, that is, to make your rootvg smaller and
assign less disk space to it.
Migration
installation
Use
the migration installation method to upgrade AIX Version 4.2, 4.3,
AIX 5L Version 5.1, or Version 5.2 to AIX 5L Version 5.3 while
preserving the existing root volume group. The installation process
determines which optional software products must be installed. With
the exception of /tmp, this method preserves most file systems,
including the root volume group, logical volumes, and system
configuration files.
Preservation
installation
Use
the preservation installation method when a version of the BOS is
installed on your system, and you want to preserve the user data in
the root volume group. However, this method overwrites the /usr,
/tmp, /var, and / (root) file systems by default, so any user data in
these directories is lost. These file systems are removed and
recreated, so any other LPPs or filesets that you installed on the
system will also be lost. System configuration must be done after
doing a preservation installation.
The
/etc/preserve.list file contains a list of system files to be copied
and saved during a preservation BOS installation. The
/etc/filesystems file is listed by default. You can add the full path
names of any additional files that you want to
save
during the Preservation installation to the preserve.list file.
Trusted
Computing Base
The
Trusted Computing Base (TCB) is the part of the system that is
responsible for enforcing the information security policies of the
system. By installing a system with the TCB option, you enable the
trusted path, trusted shell, trusted
processes,
and system-integrity checking. Because every device is part of the
TCB, every file in the /dev directory is monitored by the TCB
Network
Installation Management
Network
Installation Management (NIM) allows you to manage an automated
installation of the Base Operating System (BOS) and optional software
on one or more machines. You can install a group of machines with a
common configuration or customize an installation for your specific
needs. The number of machines you can install simultaneously depends
on the throughput of your network, the disk access throughput of the
installation servers, and the platform type of your servers.
The
types of machines that can be managed in the NIM environment are
stand-alone, diskless, and dataless clients.
NIM
resource objects represent files and directories that are used to
support some type of NIM operation a
copy of the current running rootvg to another disk, be sure to have
all the file systems mounted that you want cloned across.
Alternate
Disk Installation
Alternate
disk installation, available starting with AIX Version 4.3, allows
for system installation on a system while it is still up and running.
Install or upgrade downtime decreases considerably. It also allows
large facilities to manage an
upgrade,
while the systems are still running at the existing version. The
switch over to the new version can then happen with a simple reboot,
with the possibility to roll back to the original situation in case
of problems.
Cloning
the rootvg to an alternate disk has many advantages. One advantage is
having an online backup available, as in the case of a disk crash.
Keeping an online backup requires an extra disk or disks to be
available on the system. where
altinst_rootvg
is the
cloned non-active/varied off rootvg. The cloned rootvg has all its
logical volumes prefixed with the name 'alt'. The boot list is also
changed to boot off altinst_rootvg. AIX likes to do things like this;
it assumes you will want to boot off the cloned and not the real
rootvg.
Alternate
disk installation can be used in one of two ways:
1)
Cloning
the current running rootvg to an alternate disk. smitty
alt_clone
2)
Installing
a mksysb image on another disk. smitty
alt_mksysb
With
a mksysb
image,
you can clone one system image onto multiple target systems. However,
the target systems might not contain the same hardware.
By
default, using the alt_disk_install
command
does the following:
1.
Creates an /image.data file based on the current rootvg's
configuration. A customized image.data file can be used.
2.
Creates an alternate rootvg (altinst_rootvg).
3.
Creates logical volumes and file systems with the alt_inst prefix.
4.
Generates a backup file list from the rootvg, and if an exclude.list
file is given, those files are excluded from the list.
5.
Copies the final list to the altinst_rootvg's file systems.
6.
If specified, the installp
command
installs updates, fixes, or new filesets into the alternate file
system.
7.
The bosboot
command
creates a boot logical volume on the alternate boot disk.
8.
If a customization script is specified, it runs at this point.
9.
The file systems are then unmounted, and the logical volumes and file
systems are renamed.
10.The
logical volume definitions are exported from the system to avoid
confusion with identical ODM names, but the altinst_rootvg definition
is left as an ODM placeholder.
11.By
default, the bootlist is set to the new cloned rootvg for the next
reboot.
Maintenance
Level
A
Maintenance Level (ML) is the service updates that are necessary to
upgrade the base operating system (BOS) or an optional software
product to the current release level.
Technology
Level
A
Technology Level (TL) is the new term for the twice yearly AIX 5L
releases, which contain new hardware and software features and
service updates. The first TL will be restricted to hardware features
and enablement, as well as software service. The second TL will
include hardware features and enablement, software service, and new
software features.
Fileset
A
fileset is the smallest installable base unit for the AIX 5L
operating system.
Package
A
package is a group of separately installable filesets that provide a
set of related functions. For example, bos.net is a package
Licensed
Program Product
A
Licensed Program Product (LPP) is a complete software product
including all packages associated with that licensed program. For
example, the BOS is a licensed program.
Bundle
A
bundle is a list of software that can contain filesets, packages, and
LPPs that are suited for a particular use, such as providing personal
productivity software or software for a client machine in a network
environment
PTF
PTF
is an acronym for Program Temporary Fix. A PTF is an updated fileset
or a new fileset that fixes a previous system problem. PTFs are
installed in the same way as regular filesets by the use of the
installp command
APAR
APAR
is an acronym for Authorized Program Analysis Report. An APAR is an
emergency fix, or interim fix, to a unique problem on the system.
APARs will eventually become PTFs after testing and verification.
APARs are applied to the
system
through the use of the instfix command
Applied
State
The
applied state places software on the system and retains the previous
version of the software. When an update is in the applied state, the
previous version is stored in the /usr/lpp/PackageName directory,
where PackageName could be bos.net which is a package.
Commited
State
The
committed state places software on the system and removes all
previous levels of the software from the /usr/lpp/PackageName
directory. If committed software needs to be removed, you cannot go
back to the previous version without a complete reinstall of the
previous version software.
SUMA
automatic
download, scheduling, and notification capabilities through the new
Service Update Management Assistant (SUMA) tool
Object
Data Manager
The
ODM is a repository in which the operating system keeps information
regarding your system, such as devices, software, or TCP/IP
configuration. The ODM is an object-oriented database that contains
vital data, keeps this data
consistent
with the actual state of the system, and prevents the administrator
from altering it by mistake.
System
data managed by the ODM includes:
Device
configuration information
Display
information for SMIT (menus, selectors, and dialogs)
Vital
product data for installation and update procedures
Communication
configuration information
System
resource controller data information
Error
log and dump information
Network
Installation Manager (NIM) information
ODM
data is stored in binary format. You cannot modify ODM files with a
text editor. You must use special commands that are designed to
interact with the ODM.
The
basic components of the ODM are
Object
classes
Each
file of the database is an object class. Each object class consists
of objects having similar definitions.
Objects
Each
object is one record in an object class. It is a stand-alone entity
and has one or more descriptors.
Descriptors
The
descriptors describe the layout of the objects. They determine the
name and data type of the fields that are part of the object class.
The descriptors of an object and their associated values can be
located and changed using ODM commands.
ODM
information is divided in three parts in order to support diskless or
dataless systems. The names of these three directories as follows:
/usr/lib/objrepos
Contains
the predefined objects classes, SMIT menu object classes and the four
object classes used by SWVPD for the /usr part of the installable
software product. The object classes in this repository can be shared
across the network by /usr clients, dataless and diskless
workstations. Software installed in the /usr part can be shared among
several machines with compatible hardware architecture.
/usr/share/lib/objrepos
Contains
the four object classes used by the SWVPD for the /usr/share part of
the installable software product. The /usr/share part of a software
product contains files that are not hardware dependent. They can be
shared among several systems, even if these have a different hardware
architecture. An example are terminfo files that describe terminal
capabilities. Because terminfo is used on many UNIX systems, terminfo
files are part of the /usr/share part of the software product.
/etc/objrepos
Contains
the customized devices object classes and the four object classes
used by SWVPD for the / part of the installable software product. To
access information in the other directories, this directory contains
symbolic links to the predefined devices object classes. These links
are needed because the ODMDIR variable points to only
/etc/objrepos.
It contains the part of the product that cannot be shared with other
systems. Most of this
software
requiring a separate copy for each machine is associated with the
configuration of the machine or
product.
The
ODM commands are:
odmadd
Adds
objects to an object class.
odmchange
Changes
specific objects in a specified object class.
odmcreate
Creates
empty object classes.
odmdelete
Removes
objects from an object class.
odmdrop
Removes
an entire object class.
odmget
Retrieves
objects from object classes and puts the object information into
odmadd
command
format.
odmshow
Displays
the description of an object class.
System
Management Interface Tool
System
Management Interface Tool (SMIT) provides an alternative to the
typical method of using complex command syntax, valid parameter
values, and custom shell path names for managing and maintaining your
operating
system
configuration.
Software
Installation and Maintenance
Software
License Management
Devices
System
Storage Management (Physical & Logical Storage)
Security
& Users
Communications
Applications and Services
Print
Spooling
Advanced
Accounting
Problem
Determination
Performance
& Resource Scheduling
System
Environments
Processes
& Subsystems
Applications
Installation
Assistant
Cluster
Systems Management
Using
SMIT (information only)
SMIT
runs in two modes: ASCII (non-graphical) and X-Window (graphical).
ASCII SMIT can run on both terminals and graphical displays. The
graphical mode, which supports a mouse and point-and-click
operations, can be run only on a
graphical
display and with X-Window support. The ASCII mode is often the
preferred way to run SMIT because it can be run from any machine.
To
start the ASCII mode, type at the command line:
smitty
or
smit
-a
To
start the graphical mode, type:
smit
or
smit
-m
SMIT
is an interactive, menu-driven user interface that allows you to more
easily perform routine system management tasks and to manage and
maintain your operating system configuration.
SMIT
uses three types of screens: menu, selector, and dialog screens. Menu
screens display a list of items that you can select. Selector
screens, often presented as a pop-up menu, display a list of items
from which you specify or select a particular item Dialog screens are
the interface to a command or task that you perform
Trusted
Program,
A
trusted program, or trusted process, is a shell script, a daemon, or
a program that meets a particular standard of security.
Examples
of trusted daemons are:
_
ftpd
_
rexecd
_
telnetd
Examples
of non-trusted daemons are:
_
rshd
_
rlogind
_
tftpd
Bootlist
Command
The
bootlist
command
allows the user to display and alter the list of possible boot
devices from which the system may be booted. This command supports
the updating of the following:
Normal
boot list
The
normal list designates possible boot devices for when the system is
booted in normal mode.
Service
boot list
The
service list designates possible boot devices for when the system is
booted in service mode.
Previous
boot device
This
entry designates the last device from which the system booted. Some
hardware platforms may attempt to boot from the previous boot device
before looking for a boot device in one of the other lists.
Network
Configuration Files
$HOME/.netrc
The
$HOME/.netrc file contains information used by the automatic login
feature
of the rexec
and
ftp
commands.
It is a hidden file in a user's home directory and must be owned
either by the user executing the command or by the root user.
$HOME/.forward
When
mail is sent to a local user, the sendmail
command
checks for the $HOME/.forward file for that user. The $HOME/.forward
file can contain one or more addresses or aliases. Any messages are
then sent to the addresses or
aliases
in the $HOME/.forward file.
/etc/hosts.equiv
and $HOME/.rhosts
The
/etc/hosts.equiv file, along with any local $HOME/.rhosts files,
defines the
hosts (computers on a network) and user accounts that can invoke
remote commands on a local host without supplying a password. A user
or host that is
not
required to supply a password is considered trusted, though the
daemons that initiate the connections may be non-trusted in nature
(for example, rlogind).
Intreduction
to rc.* files
rc.boot
file
The
/sbin/rc.boot file is a shell script that is called by the simple
shell init and the
standard init
command
to bring up a system. It controls the machine boot process. When the
system is booting, the /sbin/rc.boot file is called on each boot
phases,
each time being passed a different parameter.
Depending
upon the type of boot device, the rc.boot file configures devices and
also calls the appropriate applications.
Appropriate
applications include:
_
Booting
from disk (boot phase 1)
_
Varying
on a root volume group (boot phase 2)
_
Enabling
file systems (boot phase 2)
_
Calling
the BOS installation programs or diagnostics
/etc/rc
file
The
/etc/rc file performs normal startup initialization; its entry in the
/etc/inittab file
is located after the rc.boot entry. The init
command
reads the /etc/inittab file and creates a process for the /etc/rc
file. The contents of the /etc/rc file are installation specific. If
all of the necessary operations complete successfully, the file exits
with a zero return code that allows the init
command
to start loggers to complete normal initialization and startup.
Many
bringup functions are done by the /etc/rc file, such as:
_
Vary
on all volume groups marked as auto-varyon.
_
Activate
all paging spaces listed on /etc/swapspaces (using the swapon
–a command).
_
Configure
all dump devices (using the sysdumpdev
-q command).
_
Perform
file system checks (using the fsck
-fp command).
_
Perform
mounting of file systems marked as mount=true on the /etc/filesystems
file (using the mount
all command).
rc.net
file
The
/etc/rc.net file is a shell script that contains network
configuration information
The stanzas allow you to enable the network interfaces and set the
host name, the default gateway, and any static routes for the current
host. This file can be used as a one-step configuration alternative
to using individually the set of commands and files necessary to
configure a host.
The
rc.net shell script is run by the configuration manager program
during the second phase of configuration. If TCP/IP is installed, a
second script, rc.tcpip, is run from the init
command
after the second phase of configuration has completed and after the
init
command
has started the SRC master.
rc.tcpip
file
The
/etc/rc.tcpip file is a shell script that, when executed, uses SRC
commands
to initialize selected daemons. The rc.tcpip shell script is
automatically executed with each system restart. It can also be
executed at any time from the command line.
Most
of the daemons that can be initialized by the rc.tcpip file are
specific to
TCP/IP. These daemons are:
_
inetd
(started
by default)
_
gated
_
routed
_
named
_
timed
_
rwhod
/etc/tcp.clean
can
be used to stop TCP/IP daemons.
System
boot without starting rc.tcpip
Removing
the rc.tcpip entry in /etc/inittab means that you are not starting
any server applications during IPL.
Without
the server applications started, you will not be able to telnet
or
ftp
to
this machine from another host.
However,
as long as you have not brought down the network interface, you can
still utilize the client network services. You can still ping
other
hosts, and you can still telnet
or
ftp
to
other hosts.
The
/etc/services file
The /etc/services file
contains information about the known services used in the DARPA
Internet network by inetd. Each service listed in /etc/services runs
on a specific port number for communications, in a specific format,
such as TCP or UDP.
If
you edit the /etc/services file, run the refresh
-s inetd
command, in order for your changes to be used.
File
System Issues
Network
File System
The
Network File System (NFS) is a distributed file system that allows
users to access files and directories of remote servers as though
they were local. For example, you can use operating systems commands
to create, remove, read,
write,
and set file attributes for remote files and directories. NFS is
independent of machine types, operating systems, and network
architectures because of its use of remote procedure calls (RPC) for
these services.
For
the successful implementation of an NFS environment, you need the
following things:
1.
The NFS daemons should be running on the server and the clients.
2.
The file systems that need to be remotely available will have to be
exported.
3.
The exported file systems need to be mounted on the remote (client)
systems.
The
following are a list of terms that are used throughout this
discussion:
Server
A
computer that makes its file systems, directories, and other
resources available for remote access.
Clients
The
computers, or their processes, that use a server’s resources.
Export
The
act of making file systems available to remote clients.
Mount
The
act a client needs to do to access the file systems that a server
exports.
The
following describes the mounting process:
When
the server starts, the /etc/rc.nfs script runs the exportfs
command,
which reads the server /etc/exports file and then tells the kernel
which directories are to be exported and which access restrictions
they require.
The
rpc.mountd
daemon
and several nfsd
daemons
(eight, by default) are then started by the /etc/rc.nfs script.
When
the client starts, the /etc/rc.nfs script starts several biod
daemons
(eight, by default), which forward client mount requests to the
appropriate server.
Then
the /etc/rc.nfs script executes the mount
command,
which reads the file systems listed in the /etc/filesystems file.
The
mount
command
locates one or more servers that export the information the client
wants and sets up communication between itself and that server. This
process is called binding.
The
mount
command
then requests that one or more servers allow the client to access
the directories in the client /etc/filesystems file.
The
server
rpc.mountd
daemon
receives the client mount requests and either grants or denies them.
If the requested directory is available to that client, the
rpc.mountd
daemon
sends the client's kernel an identifier called a file handle.
The
client kernel then ties the file handle to the mount point (a
directory) by recording certain information in a mount record.
There
are three types of NFS mounts: predefined, explicit, and automatic.
Predefined
mounts are specified in the /etc/filesystems file.
Explicit
mounts are usually made for short periods of time when there is a
requirement for occasional unplanned mounts. There is no entry for
shared file system in /etc/filesystems
Automatic
mounts are controlled by the automount
command,
which causes the AutoFS kernel extension to monitor specified
directories for activity. If a program or user attempts to access a
directory that is not currently mounted, then AutoFSintercepts the
request, arranges for the mount of the file system, and then services
the request.
The
following describes the mounting process:
1.
When the server starts, the /etc/rc.nfs script runs the exportfs
command,
which reads the server /etc/exports file and then tells the kernel
which directories are to be exported and which access restrictions
they require.
2.
The
rpc.mountd
daemon
and several nfsd
daemons
(eight, by default) are then started by the /etc/rc.nfs script.
3.
When the client starts, the /etc/rc.nfs script starts several biod
daemons
(eight, by default), which forward client mount requests to the
appropriate server.
4.
Then the /etc/rc.nfs script executes the mount
command,
which reads the FS listed in the /etc/filesystems file.
5.
The mount
command
locates one or more servers that export the information the client
wants and sets up communication between itself and that server. This
process is called binding.
6.
The mount
command
then requests that one or more servers allow the client to access the
directories in the client /etc/filesystems file.
7.
The server rpc.mountd
daemon
receives the client mount requests and either grants or denies them.
If the requested directory is available to that client, the
rpc.mountd
daemon
sends the client's kernel an identifier called a file handle.
8.
The client kernel then ties the file handle to the mount point (a
directory) by recording certain information in a mount record.
The
inetd daemon
The
/usr/sbin/inetd
daemon
provides Internet service management for a network.
This daemon reduces system load by invoking other daemons only when
they are needed.
If
you change the /etc/inetd.conf using SMIT, then the inetd
daemon
will be refreshed automatically and will read the new /etc/inetd.conf
file. If you change the file using an editor, run the
#
refresh -s inetd
or
#
kill -1 InetdPID
Existing
sessions are not affected when the inetd
daemon
is stopped,
but no new telnet
and
ftp
sessions
can be established without first restarting the inetd
daemon.
The
portmap daemon
The
portmap
daemon
converts remote procedure call (RPC) program numbers into Internet
port numbers.
/etc/netsvc.conf Specifies
default order for Host name resolutions
/etc/hosts provides
a list of server names or aliases and their IP addresses
/etc/resolv.conf Name
resolution file
Maximum
transmission unit:
MTU
size is critical for proper network communications. Packets that are
too
small
in length may be lost during transmission. Packets that are too long
in length may collide with other packets that are being transmitted.
These factors can lead to slower transmission rates and other network
problems as packets must then be retransmitted.
To
automate the NTP start after reboot:
#
vi /etc/inittab
ntp:2:wait:/usr/bin/startsrc
-sxntpd
OR
Uncommented
the commented the line from /etc/rc.tcpip
start
/usr/sbin/xntpd "$src_running"
Virtual
Ethernet
Virtual
Ethernet enables inter-partition communication without the need for
physical network adapters assigned to each partition. Virtual
Ethernet allows the administrator to define in-memory connections
between partitions handled at system level
Paging
Space.
To
accommodate a large virtual memory space with a limited real memory
space, the system uses real memory as a work space and keeps inactive
data and programs on disk. The area of the disk that contains this
data is called the
system
paging space.
*Do
not allocate more than one paging space logical volume on a physical
volume.
*Avoid
putting a paging space logical volume on a heavily active logical
volume.
*Make
each paging space logical volume equal in size.
*Do
not extend a paging space logical volume onto multiple physical
volumes.
LVM
Concepts
The
fundamental concepts used by LVM are physical volumes, volume groups,
physical partitions, logical volumes, logical partitions, file
systems, and raw devices. Some of their characteristics are presented
as follows:
Each
individual disk drive is a named physical volume (PV) and has a name
such as hdisk0 or hdisk1.
One
or more PVs can make up a volume group (VG). A physical volume can
belong to a maximum of one VG.
You
cannot assign a fraction of a PV to one VG. A physical volume is
assigned entirely to a volume group.
Physical
volumes can be assigned to the same volume group even though they are
of different types, such as SCSI or SSA.
Storage
space from physical volumes is divided into physical partitions
(Pps). The size of the physical partitions is identical on all disks
belonging to the same VG.
Within
each volume group, one or more logical volumes (LVs) can be defined.
Data stored on logical volumes appears to be contiguous from the user
point of view, but can be spread on different physical volumes from
the same
volume
group.
Logical
volumes consist of one or more logical partitions (LPs). Each logical
partition has at least one corresponding physical partition. A
logical partition and a physical partition always have the same size.
You can have up to three
copies
of the data located on different physical partitions. Usually,
physical partitions storing identical data are located on different
physical disks for redundancy purposes.
Data
from a logical volume can be stored in an organized manner, having
the form of files located in directories. This structured and
hierarchical form of organization is named a file system.
Data
from a logical volume can also be seen as a sequential string of
bytes. This type of logical volumes are named raw logical volumes. It
is the responsibility of the application that uses this data to
access and interpret it correctly.
Volume
Group Descriptor Area
The
volume group descriptor area (VGDA) is an area on the disk that
contains information pertinent to the volume group that the physical
volume belongs to. It also includes information about the properties
and status of all physical and logical volumes that are part of the
volume group. The information from VGDA is used and updated by LVM
commands. There is at least one VGDA per physical volume. Information
from VGDAs of all disks that are part of the
same
volume group must be identical. The VGDA internal architecture and
location on the disk depends on the type of the volume group
(original, big, or scalable).
Volume
Group Status Area
The
volume group status area (VGSA) is used to describe the state of all
physical partitions from all physical volumes within a volume group.
The VGSA indicates if a physical partition contains accurate or stale
information. VGSA is used for monitoring and maintained data copies
synchronization. The VGSA is essentially a bitmap and its
architecture and location on the disk depends on the type of the
volume group.
Logical
Volume Control Block
A
logical volume control block (LVCB) contains important information
about the logical volume, such as the number of the logical
partitions or disk allocation policy. Its architecture and location
on the disk depends on the type of the volume group it belongs to.
For standard volume groups, the LVCB resides on the first block of
user data within the LV. For big volume groups, there is additional
LVCB information in VGDA on the disk. For scalable volume groups, all
relevant logical volume control information is kept in the VGDA as
part of the LVCB information area and the LV entry area.
Logical
Track Group
Logical
track group (LTG) size is the maximum allowed transfer size for an
I/O disk operation.
#
lquerypv -M hdisk0
Quorum
The
quorum is one of the mechanisms that the LVM uses to ensure that a
volume group is ready to use and contains the most up-to-date data.
A
quorum is a vote of the number of Volume Group Descriptor Areas and
Volume Group Status Areas (VGDA/VGSA) that are active. A quorum
ensures data integrity of the VGDA/VGSA areas in the event of a disk
failure. Each physical disk in a volume group has at least one
VGDA/VGSA. When a volume group is created onto a single disk, it
initially has two VGDA/VGSA areas residing on the disk. If a volume
group consists of two disks, one disk still has two VGDA/VGSA areas,
but the other disk has one VGDA/VGSA. When the volume group is made
up of three or more disks, then each disk is allocated just one
VGDA/VGSA.
A
quorum is lost when at least half of the disks (meaning their
VGDA/VGSA areas) are unreadable by LVM. In a two-disk volume group,
if the disk with only one VGDA/VGSA is lost, a quorum still exists
because two of the three VGDA/VGSA areas still are reachable. If the
disk with two VGDA/VGSA areas is lost, this statement is no longer
true. The more disks that make up a volume group, the lower the
chances of quorum being lost when one disk fails.
When
a quorum is lost, the volume group varies itself off so that the
disks are no longer accessible by the LVM. This prevents further disk
I/O to that volume group so that data is not lost or assumed to be
written when physical problems occur. Additionally, as a result of
the vary-off, the user is notified in the error log that a hardware
error has occurred and service must be performed.
There
are cases when it is desirable to continue operating the volume group
even though a quorum is lost. In these cases, quorum checking can be
turned off for the volume group. This type of volume group is
referred to as a nonquorum volume group. The most common case for a
nonquorum volume group occurs when the logical volumes have been
mirrored. When a disk is lost, the data is not lost if a copy of the
logical volume resides on a disk that is not disabled and can be
accessed. However, there can be instances in nonquorum volume groups,
mirrored or nonmirrored, when the data (including copies) resides on
the disk or disks that have become unavailable. In those instances,
the data might not be accessible even though the volume group
continues to be varied on.
Unlock
VG
A
volume group can become locked after an abnormal termination of an
LVM command. You can remove the lock using the chvg -u command.
Journaled
file system
This
type of file system is named journaled because the system uses
journaling techniques to maintain the
integrity
of control structures. Each journaled file system must reside on a
distinct jfs logical volume. Therefore, the
file
system size will be a multiple of the size of a logical partition.
Enhanced
journaled file system
This
is the enhanced version of the initial journalized file system. It
uses extent based allocation to allow higher
performance,
larger file systems, and a larger file size. Each enhanced journaled
file system must reside on a
distinct
jfs2 logical volume. When the operating system is installed using the
default options, it creates JFS2 file
systems.
Controll
Growing file
/var/adm/wtmp
/etc/security/failedlogin
/var/adm/sulog
/var/spool/*/*
$HOME/smit.log
$HOME/smit.script
$HOME/websm.log
$HOME/websm.script
JFS
and JFS2 Difference
Superblock
The
superblock contains control information about a file system, such as
the overall size of the file system in 512 byte blocks, the file
system name, the file system log device, the version number, the
number of inodes, the list of free
inodes,
the list of free data blocks, date and time of creation, and file
system state. All this data is stored in the first logical block of
the file system. Corruption of this data may render the file system
unusable. This is why the system keeps a second copy of the
superblock on logical block 31.
Allocation
group
An
allocation group consists of inodes and its corresponding data
blocks. An allocation groups spans multiple adjacent disk blocks and
improves the speed of I/O operations. Both JFS and JFS2 file systems
use allocation groups. For a JFS file system, the allocation group
size can be specified when the file system is created.
Inodes
The
inode contains control information about the file, such as type,
size, owner, and the date and time when the file was created,
modified, or last accessed. It also contains pointers to data blocks
that store the actual data of the file. Every file has a
corresponding inode.
For
JFS file systems, the maximum number of inodes, and hence the maximum
number of files, is determined by the number of bytes per inode
(nbpi) value, which is specified when the file system is created. For
every nbpi bytes of your file system, there will be an inode created.
The total number of inodes is fixed. The nbpi values needs to be
correlated with allocation group size. The JFS restricts all file
systems to 16 MB (224) inodes. JFS2 file systems manages the
necessary space for inodes dynamically so there is not any nbpi
parameter.
Data
blocks
Data
blocks store the actual data of the file or pointers to other data
blocks. The default value for disk block size is 4 KB.
Fragments
Fragments
of logical blocks can be used to support files smaller than the
standard size of the logical block (4 KB). This rule applies only to
the last block of a file smaller than 32 KB.
For
JFS file systems only, you have the option to use compression to
allow all logical blocks of a file to be stored as a sequence of
contiguous fragments. Compression for a file system will increase the
amount of CPU and I/O activity
when
using that file system. These features can be useful to support a
large number of small files. Fragment
size
must be specified for a file system at installation time. Different
file systems can have different fragment sizes.
Device
logs
The
journaled file system log stores transactional information about file
system metadata changes.This data can be used to roll back incomplete
operations if the machine crashes. JFS file systems are used for
logging logical volumes of type jfslog, while JFS2 file systems are
used for logging logical volumes of type jfs2log.
Data
from data blocks are not journaled. Log devices ensure file system
integrity, not data integrity. After the operating system is
installed, all file systems within the rootvg volume group use
logical volume hd8 as a common log. You can create a JFS2 file system
that can use inline logs. This means the log data is written into the
same logical volume as the file system, and not into the log logical
volume.
Full
backup
All
the files are put on media during a full backup.
Differential
Backup
The
differential backup strategy first looks for the modification time of
a file and compares it with the last full backup time. In other
words, only modified files are backed up, but only if they changed
after the latest full backup. Differential backups are cumulative;
once a file has been modified, it will be included in every
differential backup until the next full backup.
Incremental
backups
Incremental
backups are similar to differential backups in that both back up only
modified files. However, incremental backup checks the difference
between the modification time of a file and the last backup time
(either being full or
incremental
backup). If the modification date is more recent than the last backup
date, the file is backed up.
MKSYSB
The
mksysb
command
creates a bootable image of all mounted file systems on the rootvg
volume group. You can use this backup command to restore a system to
its original state. The tape format includes a BOS boot image, a BOS
install image, and a dummy table of contents (TOC) followed by the
system backup (root volume group) image. The root volume group image
is in backup-file format, starting with the data files and then any
optional map files.
User-defined
paging spaces, unmounted file systems, and raw devices are not backed
up.
The
BOS boot image contains a copy of the system’s kernel and device
drivers needed to boot from the mksysb tape. It is created by the
bosboot
command.
There
are three important files in the mkinsttape image (the second section
of the mksysb
tape):
./tapeblksz, ./bosinst.data, and ./image.data. The ./tapeblksz file
contains the block size the tape drive was set to when the mksysb
command
was run.
The
./bosinst.data file allows you to specify the requirements at the
target system and how the user interacts with the target system. This
file contains the customized BOS install procedures and dictates how
the BOS install program will
behave.
You can customize this file before issuing the mksysb
command
or use a procedure to customize this file after the image backup is
done.
The
./image.data file contains information describing the image installed
during the BOS installation process. This information includes the
sizes, names, maps, and mount points of logical volumes and file
systems in the rootvg. You
can customize this file before using the mksysb
command, or
run mksysb
-i to
generate a new ./image.data file on the tape during a backup.
The mkszfile
command
generates the ./image.data file. The ./image.data file is arranged in
stanza
format. Each stanza contains one or more fields.
The
dummy table of contents (TOC) is used so that the mksysb
tape
contains the same number of images as a BOS install tape.
The
rootvg data area contains all data in the rootvg volume group backed
up by the mksysb
command.
The mksysb
command
uses the backup
command
to save the contents of mounted JFS data in rootvg, excluding raw
data.
When
you need to make a mksysb
backup
of a system, and you want to exclude some data file systems from the
system, you need to edit the /etc/exclude.rootvg file. Make sure that
there are no empty lines.
^./tmp/
Restoring
mksysb
An
mksysb image enables you to restore the system image onto target
systems that might not contain the same hardware devices or adapters,
require the same kernel (uniprocessor or microprocessor), or be the
same hardware platform (rs6k, rspc, or chrp) as the source system.
You
have several possibilities to restore the mksysb image:
-If
restoring on exactly the same machine, you can boot directly from the
mksysb media and restore from there.
-If
restoring on a different type of machine, you use the cloning
function
-If
you do not want to interfere with the production environment, you can
use the alt_mksysb
command.
Multibos
The
multibos command allows the root level administrator to create
multiple instances of AIX on the same rootvg. The multibos setup
operation creates a standby Base Operating System (BOS) that boots
from a distinct boot logical volume (BLV). This creates two bootable
sets of BOS on a given rootvg. The administrator can boot from either
instance of BOS by specifying the respective BLV as an argument to
the bootlist command or using system firmware boot operations. Two
bootable instances of BOS can be simultaneously maintained. The
instance of BOS associated with the booted BLV is referred to as the
active BOS. The instance of BOS associated with the BLV that has not
been booted is referred to as the standby BOS. Currently, only two
instances of BOS are supported per rootvg.
The
multibos command allows the administrator to access, install
maintenance and technology levels for, update, and customize the
standby BOS either during setup or in subsequent customization
operations. Installing maintenance and technology updates to the
standby BOS does not change system files on the active BOS. This
allows for concurrent update of the standby BOS, while the active BOS
remains in production.
In
this case, the biggest difference is that multibos will create and
copy only the following Logical Volumes (LVs):
/;
/usr;
/var;
/opt,
and;
hd5
(Boot logical volume).
All
others LVs will be shared with the original root volume group,
although more logical volumes can be specified and copied.
Multibos
supports a new TL update, but AIX version upgrades are not supported
by multibos.
Failed
Disk Replacement
If
the disk
you are going to replace is mirrored,
we recommend following these steps:
1.
Remove copies of all logical volumes that were residing on that disk
using either the rmlvcopy
command
or unmirrorvg
command.
2.
Remove the disk from the volume group using the reducevg
command.
3.
Remove the disk definition using the rmdev
command.
4.
Physically remove the disk. If the disk is not hot-swappable, you may
be required to reboot the system.
5.
Make the replacement disk available. If the disk is hot-swappable,
you can run cfgmgr;
otherwise, you may need to reboot the system.
6.
Include the newly added disk into the volume group using the extendvg
command.
7.
Recreate and synchronize the copies for all logical volumes using
either mklvcopy
or
mirrorvg.
If
the disk
you are going to replace is not mirrored and is still functional,
we recommend following these steps:
1.
Make the replacement disk available. If the disk is hot-swappable,
you can run cfgmgr; otherwise, you may need to reboot the system.
2.
Include the newly added disk into the volume group using the extendvg
command.
3.
Migrate all partitions from the failing disk to the new disk using
either the migratepv command or the migratelp command. If the disks
are part of the rootvg, you should consider the following:
– If
the disk to be replaced contains a copy of the BLV, you have to clear
it using the chpv -c command.
– A
new BLV image must be created on the new disk using the bosboot
command.
– The
bootlist must be updated to reflect these changes using the bootlist
command.
– If
the disk to be replaced contains a paging space or a primary dump
device, you should disable them. After the migratepv
command
completes, you should reactivate them.
4.
Remove the failing disk from the volume group using the reducevg
command.
5.
Remove the disk definition using the rmdev
command
If
the disk
is not mirrored,
has failed
completely,
and
there are other disks available in the volume group,
we recommend following these steps:
1.
Identify all logical volumes that have at least one partition located
on the failed disk.
2.
Close the logical volumes and unmount all the corresponding file
systems using the umount
command.
3.
Remove the file systems and logical volumes using the rmfs
command.
4.
Remove the failing disk from the volume group using the reducevg
command.
5.
Remove the disk definition using the rmdev
command.
6.
Physically remove the disk. If the disk is not hot-swappable, you may
be required to reboot the system.
7.
Make the replacement disk available. If the disk is hot-swappable,
you can run cfgmgr;
otherwise, you may need to reboot the system.
8.
Include the newly added disk into the volume group using the extendvg
command.
9.
Recreate all the logical volumes and the corresponding file systems
using the mklv
command
and the crfs
command.
10.If
you have a backup of your data, restore your data from backup.
If
the disk
is not mirrored,
has
failed completely,
there
are no other disks available in the volume group
(the volume group contained only one physical volume or all the
physical volumes failed simultaneously), and
the volume group is not rootvg,
we recommend the following steps:
1.
Export the volume group definition from the system using the exportvg
command.
2.
Ensure that /etc/filesystems does not contain any incorrect stanzas.
3.
Remove the disk definition using the rmdev
command.
4.
Physically remove the disk. If the disk is not hot-swappable, you may
be required to reboot the system.
5.
Make the replacement disk available. If the disk is hot-swappable,
you can run cfgmgr;
otherwise, you may need to reboot the system.
6.
If you have a volume group backup, restore it using the restvg
command.
7.
If you do not have volume group backup, recreate the volume group,
all the logical volumes, and the corresponding file systems using the
mkvg
command,
the mklv
command,
and the crfs
command.
8.
If you have a backup of your data, restore your data from backup.
If
the disk
is not mirrored,
has
failed completely,
there
are not other disks available in the volume group
(the volume group contained only one physical volume or all physical
volumes failed simultaneously), and
the volume group is
rootvg,
we recommend following these steps:
1.
Replace the failing disk.
2.
Boot the system in maintenance mode.
3.
Restore the system from an mksysb image.
RAID
Levels
RAID
0
Also
known as striping. Data is split into blocks of equal size and stored
on different disks. There is no
redundancy.
If one disk fails, your data is lost.
RAID
1
Also
known as mirroring. Data is split into blocks of equal size.
Duplicate copies are kept on separate
physical
disks. If one disk fails, the second copy is used and data is still
available.
RAID
5
Also
known as striping with parity. Data is split into blocks of equal
size. An additional data block
containing
parity information is generated. Both data blocks and the parity
block are written onto separate
physical
disks. If one disk storing a block of data fails, the system will
reconstruct the data from the failed
drive
using the parity information and the remaining data from the other
drives.
RAID
10
Also
known as RAID 0+1 or enhanced RAID. It is a combination of mirroring
(RAID 1) and striping (RAID
0).
SSH
Securities:
# vi
/etc/ssh/sshd_config
And make
following changes for better security
PermitRootLogin
no Disabled the Direct root login
Protocol
2 Good security concepts
Banner
file Set the banner in a file
IgnoreRhosts
yes If .rhosts is configured then ignored
PermitEmptyPassword
no Disabled the acceptance of null password
HostBasedAuthentication
no Disabled the host based authentication
TCP Wrapper:
TCP wrapper often called
a s just a wrapper. It allows a system administrator to control
access of TCP-based services or daemons that are wrapper aware.
Download the “tcp_wrappers_7.6-ipv6.4.tar.gz” and install it.
Replaced
To
and
# refresh -s inetd
Wrapper first check
host.allow, if match found access is granted. If match found in
host.deny the access is resticted for perticular services.
# vi /etc/host.allow
telnetd,sshd:
.mydomain.com :allow
telnetd,sshd:192.168.4.10
, 192.168.6. : allow
# vi /etc/host.deny
telnetd : 192.168.8.,
192.168.9. : deny
telnetd : 192.168.6. :
allow
# tcpdchk-v
check the syntax in host.allow and host.deny
Audits in
AIX:
AIX auditing provides a
framework within which to capture pertinent system and security
related information, such as failed login attempts, cron usage etc.
It is recommended that auditing is enabled as part of a group of
measures designed to provide enhanced logging of system and security
changes.
Create a /audit
filesystem, at least 100 MB in size. The script always creates a
standard jfs filesystem. If the /audit filesystem exists, this step
is skipped:
# mklv -y <LV name>
-t jfs -u 1 -c 1 rootvg 1 hdisk0
# crfs -v jfs -d auditlv
-m /audit -A yes -t no mount /audit
# vi
/etc/security/audit/configt /audit
start:
binmode = on
streammode = off
bin:
trail = /audit/trail
bin1 = /audit/bin1
bin2 = /audit/bin2
binsize = 10240
cmds =
/etc/security/audit/bincmds
Add the auditing entries
for root and all other users below the pre-defined audit classes
users:
root =
general,SRC,mail,cron,tcpip,ipsec,lvm
<user 1> =
general,SRC,cron,tcpip
<user 2> =
general,SRC,cron,tcpip
etc.
Update the
/usr/lib/security/mkuser.default auditclasses entry to ensure that
auditing is set up for any newly created users
# chsec –f
/usr/lib/security/mkuser.default –s user –a
auditclasses=general,SRC,cron,tcpip
Add the audit startup
command into /etc/inittab.
# mkitab
"audit:2:boot:audit start > /dev/console 2>&1 # Start
audit"
Simultaneous
Multi-Threading
Simultaneous
multithreading is the ability of a single physical processor to
simultaneously dispatch instructions from more than one hardware
thread context. Because there are two hardware threads per physical
processor, additional instructions can run at the same time. The
POWER5™ processor is a superscalar processor that is optimized to
read and run instructions in parallel. Simultaneous multithreading
allows you to take advantage of the superscalar nature of the POWER5™
processor by scheduling two applications at the same time on the same
processor.
Simultaneous
multithreading is primarily beneficial in commercial environments
where the speed of an individual transaction is not as important as
the total number of transactions that are performed. Simultaneous
multithreading is expected to increase the throughput of workloads
with large or frequently changing working sets, such as database
servers and Web servers.
Multiple Hardware threads
can run on one physical processor at the same time
-A processor appears as
two or four logical CPUs (lcpu) to AIX
-Beneficial for most
commercial environments
-SMT is enabled by
default with max no of logical CPUs
Can change between SMT2
to SMT4 (POWER 7 only)
Can Disabled and enabled
AIX
6.1 Terminology
What
are WPARs?
In
contrast to LPARs, which are created and managed at the server's
firmware level, AIX WPARs are software partitions that are created
from, and share the resources of, a single instance of the AIX
operating system. This means that you must have AIX 6.1 to create
WPARs, but you can create WPARs on any System p hardware that
supports AIX 6.1, including POWER4, POWER5, and POWER6 hardware. You
don’t need an HMC or IVM to create or manage WPARs.
There
are two kinds of WPARs:
System
WPARs
Application
WPARs
System
WPARs
System
WPARs System WPARs are autonomous virtual system environments that
have their own private file systems, users and groups, login, network
space, and administrative domain. To users and applications, a system
WPAR appears almost exactly like a full AIX system. Operating system
services, such as telnet, are supported, so if network information
has been configured, users can telnet into a system WPAR as root or
any other defined user, issue commands, and run applications as they
would on any other AIX system.
-Autonomous
virtual system environment
Shared
file system with global environment: /usr and /opt
Private
file system for wpar’s own use:/, /var, /tmp
Unique
set of users, groups, and network addresses
-Can
be access via Network protocol (telnet or ssh)
Login
from the global environment using the clogin command
-Can
be stopped and restarted
Application
WPARs
Application
WPARs provide an environment for isolation of applications and their
resources to enable checkpoint, restart, and relocation at the
application level. An application WPAR is essentially a wrapper
around a running application or process for the purposes of
isolation and mobility. It lacks some of the system services provided
by system WPARs—for example, it’s not possible to log in or
telnet into an application WPAR. When the application running in an
application WPAR terminates, the WPAR also ceases to exist.
Application WPARs are most useful when you want to enable Live
Application Mobility—that is, when you want to be able to move a
running application from one AIX system to another. You might want to
relocate applications to avoid downtime resulting from scheduled
maintenance or to improve performance by moving an application to a
more powerful server
-Isolate
an individual application
-Light
weight; quick to create and remove
Created
with wparexec command
Removed
when stopped
Stopped
when the application finished
-Shares
file systems and devices with the global environment
-No
user login capabilities
WPAR
Manager
IBM
Workload Partitions Manager for AIX (WPAR Manager) is a platform
management solution that provides a centralized point of control for
managing workload partitions across a collection of managed systems
running AIX 6.1. The managed systems might all be LPARs on a single
physical server, or they might be located on multiple physical
servers. Using WPAR Manager, you can monitor the health and status of
multiple WPARs on multiple managed AIX systems. You can also perform
all the basic WPAR life cycle operations—including create, view and
manage properties, start, stop, and delete.
WPAR
Manager also supports relocation of WPARs between systems in a
collection of managed servers. WPAR Managersupports two kinds of
relocation:
Manual
relocation—This type of relocation is initiated by the user.
Policy-based
relocation—This type of relocation is initiated by WPAR Manager in
response to workload conditions defined in a relocation policy.
WPAR
Manager is not part of AIX—it’s a separately purchased licensed
program
Multi-system
management
Managing
WPARs on multiple AIX systems using the WPAR Manager requires two
initial installation and configuration steps. First, you install and
configure the management server software on an AIX system in your
environment. Then, you install the WPAR Manager agent software on
each AIX system that will be managed by WPAR Manager. The agent must
then be configured to share WPAR data with a specific management
server. After the WPAR Manager and agent components have been
configured and started, the WPAR Manager automatically discovers all
the managed systems, and begins to record data transmitted by the
agents in an internal database.
Live
Application Mobility
Live
Application Mobility is the capability to relocate a WPAR from one
hosting system to another without having to restart any applications
or processes running in the WPAR. Partition mobility refers to the
ability to move an entire running AIX LPAR from one physical server
to another.
Live
Partition Mobility
Live
Partition Mobility allows you to migrate partitions that are running
AIX and Linux operating systems and their hosted applications from
one physical server to another without disrupting the infrastructure
services. The migration operation, which takes just a few seconds,
maintains complete system transactional integrity. The migration
transfers the entire system environment, including processor state,
memory, attached virtual devices, and connected users.
Live
Partition Mobility helps you meet increasingly stringent
service-level agreements (SLAs) because it allows you to proactively
move running partitions and applications from one server to another.
Live
Partition Mobility may also be used as a mechanism for server
consolidation, because it provides an easy path to move applications
from individual, stand-alone servers to consolidation servers. If you
have partitions with workloads that have widely fluctuating resource
requirements over time.
Live
Partition Mobility can be automated and incorporated into system
management tools and scripts. Support for multiple concurrent
migrations allows you to liberate system resources very quickly. For
single-partition, point-in-time
migrations,
the Hardware Management Console (HMC) and the Integrated
Virtualization Manager (IVM) interfaces offer easy-to-use migration
wizards
Partition
Mobility is a hardware-based function, partition mobility is only
supported on POWER6 hardware; application mobility is supported on
any hardware that supports AIX 6.
Partition
Migration
A
partition migration operation can occur either when a partition is
powered off (inactive), or when a partition is providing service
(active).
The
migration process can be performed either with a powered-off or a
live partition. The following two available migration types are
discussed in more detail in the next sections:
Inactive
migration
The
logical partition is powered off and moved to the destination system.
Active
migration
The
migration of the partition is performed while service is provided,
without disrupting user activities.
Policy-based
relocation
WPAR
Manager also has the capability to monitor performance of workloads
running in WPARs and relocate those workloads to different AIX
systems to improve performance. For example, if CPU or memory usage
in a WPAR or group of WPARs is, on average, higher than a value that
you specify, then the WPAR Manager might attempt to relocate one or
more WPARs to a more powerful, or less busy, server in your
datacenter. The detailed mechanics of how the policy engine works are
beyond the scope of this article, but will be covered in a later
article.
Encrypted
File System
The
Encrypted File System (EFS) is a J2 filesystem-level encryption
through individual key stores. This allows for file encryption in
order to protect confidential data from attackers with physical
access to the computer. User authentication and access control lists
can protect files from unauthorized access while the operating system
is running; however, it’s easy to circumvent the control lists if
an attacker gains physical access to the computer.
One
solution is to store the encrypted files on the disks of the
computer.
In
EFS, a key is associated to each user. These keys are stored in a
cryptographically protected key store and upon successful login, and
the user's keys are loaded into the kernel and associated with the
process credentials. When the process needs to open an EFS-protected
file, the system tests the credentials. If the system finds a key
matching the file protection, the process is able to decrypt the file
key and file content. The cryptographic information is kept in the
extended attributes for each file. EFS uses extended attribute
Version 2, and each file is encrypted before being written on the
disk. The files are decrypted when they are read from the disk into
memory so that the file data kept in memory is in clear format. The
data is decrypted only once, which is a major advantage. When another
user requires access to the file, their security credentials are
verified before being granted access to the data even though the file
data is already in memory and in clear format. If the user is not
entitled to access the file, the access is refused. File encryption
does not eliminate the role of traditional access permissions, but it
does add more granularity and flexibility.
Snapshot
The
snapshot functionality was provided so that administrators could
create consistent, integrated snapshots of an online (or offline)
JFS2 file system. A point-in-time copy of the source file system is
created. The snapshot operation executes quickly and requires very
little disk space. Multiple snapshots can be taken, which can be very
handy if you need to perform multiple changes to a system with
corresponding backups at each stage.
The
snapshot retains the same permissions as the original file system.
Once the image has been created, you can use it to restore files or
an entire file system to a known point in time. Or, you can mount the
snapped file system and perform a backup of it to tape (via Tivoli
Storage Manager for example). This could help reduce your backup time
requirements.
There
are two types of JFS2 snapshots.
The
first is an external
snapshot
which uses a separate logical volume for the snapshot image.
The
second type allocates space out of the original file system, this is
known as an internal
snapshot.
An
external snapshot can be mounted separately on its own mount point. A
file system can use only one type of snapshot method at a time; that
is, you cannot take an external snapshot of a file system and then
take an internal snapshot of the same file system while the external
exists (and vice versa).
It
is also important to note that you cannot use internal snapshots
unless the file system was enabled to support them at the time of
file system creation. So if you want to use snapshots on an existing
file system and you did not enable it for internal snapshots, you
will need either to recreate the file system with the snapshot option
or use an external snapshot.
One
of the big advantages to using JFS2 snapshots is that we do not need
to create a complete copy of all of the data. Nor do we need to
recover the entire contents of the data. Thus reducing overhead and
saving time.
Network
Installation Management
Benefits
of NIM
NIM
allows system administrators to install, upgrade, back up and
maintain AIX 5L systems remotely
Multiple
machines can be installed or maintained at the same time
Multiple
AIX 5L versions, Maintenance Levels (MLs) or Technology Levels (TLs)
can be used in the same NIM environment
Disaster
recovery - local systems can be recovered quickly with NIM
Systems
can be installed with standard and consistent AIX 5L operating system
images
Recovering
a system backup (mksysb) from tape can be difficult when booting from
CD media
Cloning
systems is another excellent feature of NIM which can assist you in
moving from one server to another, or even from one site to another
site
NIM
Overview
A
basic NIM environment consists of several IBM System p machines (at
least two) connected via a TCP/IP network. A physical network can be
shared by several NIM environments, therefore the machines attached
to the same
physical
network can be part of several NIM environments
The
machines (or clients) can be standalone systems, LPARs, diskless, and
dataless clients (also known as “thin clients”). The machines can
be controlled by one (or more) Hardware Service Console
Master
Master
refers the machine where you set up and maintain your NIM
environment. You can also initiate installations from here (push
mode). It is the key piece of the NIM environment. Refer to 2.1.4,
“NIM master selection” on page 26, for information about how to
chose a machine to become the NIM master.
Client
The
NIM client can be the target for NIM master-initiated operations such
as installation, updates, and so forth (push mode). Also, a client
can initiate its own installation or update (pull mode). A NIM client
automatically becomes a
resource
server when it holds NIM resources.
Resource
server
Any
machine (the master or a standalone client) can be configured by the
master as a server for a particular software resource. In most
environments, the master is also resource server.
If
other machines are already reporting to the master and they are
installed (AIX), you can chose one of them to act as a resource
server, thus relieving the NIM master of the heavy I/O load (disk and
network). In such cases, the NIM master is only used to run
administrative tasks.
Push
and pull modes
The
push mode operation is initiated from the master. The pull mode
operation is initiated from the client. The very first time a client
is installed, only the pull mode can be used.
NIM
database
The
NIM database is stored in the AIX Object Data Management (ODM)
repository on the NIM master and is divided into four classes:
machines, networks, resources, groups.
Networks
class
The
network is what allows the machines in a NIM environment to
communicate which each other. If the network is a simple local area
network (LAN), the definition of the network object is simplified.
The purpose of the network object is to depict the network topology
used by the NIM environment. Each modification made on the physical
network must be reflected to the NIM database.
Resources
class
A
NIM resource is a pointer to a file or a directory located on a
Resource Server, and the NIM Master is the default Resource Server.
For example, the bosinst_data resource points to a file that contains
information used to perform
the
installation process without requiring any manual intervention. The
basic characteristics of a resource are the NIM name, the location
(the location of the file or directory), and the resource server
hosting the resource
Groups
class
A
group is a collection of either machines or resources. Only two types
are available:
#
res_group, for grouping a set of resources
#
mac_group, for grouping a set of machines
SPOT
SPOT,
or Shared Product Object Tree, is a directory of code (installed
filesets) that is used during client booting procedure. It is
equivalent in content to the code that resides in the /usr file
system on a system running AIX 5L
(binary
objects - executables and libraries, header files and shell scripts).
This resource (directory) replaces the content of the basic ramdisk
image available on installation CDs.
The
SPOT also contains the code needed to generate the boot images
(kernels, which will be stored in the /tftpboot directory) that the
client uses until it can manage to NFS-mount the SPOT directory.
lpp_source
An
lpp_source is a directory similar to AIX install CDs. It contains AIX
Licensed Program Products (LLPs) in Backup File Format (BFF) format
and RPM Package Manager (RPM) filesets that you can install
mksysb
This
resource is a file containing the image of the root volume group
(generated with the AIX mksysb command) of a machine. It is used to
restore a machine, or to install it from scratch (also known as
“cloning” a client). A mksysb resource can be defined by first
creating the mksysb image with SMIT or the mksysb command, and then
defining the resource that references the backup image file.
bosinst_data
The
bosinst_data resource is a flat ASCII file similar to the
bosinst.data file used for restoring system backup images from tape
or CD/DVD. When you start the installation of a IBM System p machine,
you will be prompted to
select
the console, language, installation method, the target disk(s) for
rootvg, and so on. This resource comes in handy for both push or pull
installation of multiple machines at the same time, because it will
automate the installation
process
without requiring interactive answers for the installation
parameters.
script
The
script resource is a file. After the BOS installation is finished on
your client, you can perform customization such as file system
resizing, additional user creation, and so forth. The script resource
points to a file (usually a shell
script)
that contains all the commands needed to perform customization.
To
rebuild and recover a NIM client /etc/niminfo file, use the niminit
command on the client:
niminit
-a master=<MASTER_HOSTNAME> -a name=<CLIENT_NIM_NAME>
NIM
improovement in AIX 5.3
nimsh
Alternate
NIM master
Creating
an SPOT resource from a mksysb
mksysb
migration using NIM
Removing
a NIM client definition
/tftpboot
This
is used for storing NIM master boot images (kernels) and info files
for the NIM clients.
/export/lpp_source
This
is used for storing versions of AIX base level filesets in specific
directories; a NIM lpp_source resource represents a directory in
which software installation images are stored
/export/spot
This
is used for storing non-/usr Shared Product Object Three (SPOT) in
individual directories (one per SPOT version). A SPOT is required to
install or initialize all types of machine configurations, as well as
to generate a
specific
kernel image used for network booting a client system. Everything
that a client machine requires in a /usr
file
system, such as the AIX kernel, executable commands, libraries, and
applications, should be included in the
SPOT.
/export/images
This
is used for storing system backup images. These images can be created
by using the NIM mksysb operation (“pulling” a mksysb image from
a NIM client), or by copying a system backup as a file from a
previously created backup file, tape, or DVD. To create
subdirectories during NIM mksysb creation, you must
export
the NIM_MKSYSB_SUBDIRS=yes variables before using the command
#
nim -o
define -t mksysb
Basic
Naming Conventions
lpp_source lpp<OS#><TL#><SP#>
spot spot<OS#><TL#><SP#>
mksysb mksysb<OS#><TL#><SP#>
network net_<IP#NET>
Initializing
NIM master
nimconfig
command can be used to perform a nim initializing
Configuring
the NIM master using the nimconfig
command
creates the master, boot, the first network object, nim_script with
the /export/nim directory; the master (nimesis)
daemon is also started.
root@master:/:
lsnim
master
machines master
boot
resources boot
nim_script
resources nim_script
net_10_1_1
networks ent
To
convert an old NIM master into a client:
Create
a client definition on the NIM master.
Remove
the /etc/niminfo file (this will remove also the nim
command
from the system).
Uninstall
the bos.sysmgt.nim.master fileset.
Check
whether the bos.sysmgt.nim.client fileset is installed.
Use
the niminit
command
to register with the new NIM master (client registration must be
enabled for this procedure to work).
Verify
auxiliary services (inetd, bootpd and tftpd)
root@msater:/:
lssrc -ls inetd
tftp
/usr/sbin/tftpd tftpd -n active
bootps
/usr/sbin/bootpd bootpd /etc/bootptab active
The
NIM
master
uses
the
bootpd
(BOOT
Protocol)
and
tftpd
(Trivial
File
Transfer
Protocol)
daemons
(services).
Both services are normally started by the inetd
daemon
(InterNET master daemon).
SMS
and Console flow during NIM client installation
At
the Initial Program Load (IPL) menu, press the 1 key to access SMS
Menu.
select
2. Setup
Remote IPL (Initial Program Load
Select
the desired adapter from the NIC Adapters list,
select
1.
IP
Parameters
to
access the IP Parameters menu
1.
From the IP Parameters menu select 1.
Client IP Address,
to set the Client IP Address.
2.
From the IP Parameters menu select 2.
Server
IP
Address,
to set the Server IP Address (NIM master).
3.
From the IP Parameters menu select 3.
Gateway
IP
Address.
Leave it if the NIM master and client are on the same IP subnet.
4.
From the IP Parameters menu select 4.
Subnet
Mask,
to set the Subnet Mask for the IP network.
5.
Press ESC
and
return to the previous menu
Network
Parameters menu, select 3.
Ping
Test
From
the Network Parameters menu, select 1.
Execute
Ping Test
Next,
press M
from
the Ping Test menu to return to the Main Menu
From
the Main Menu, choose 5.
Select
Boot
Options
From
the Multiboot menu, choose 1.
Select
Install/Boot Device
From
the Select Device Type menu, select 6.
Network
to
choose a network
From
the
NIC Adapters list, in this case, select 1.
to
access the Select Task
menu
From
the Select Task menu, select 2. Normal Mode Boot
From
the exit SMS menu select 1. Yes to let the network installation begin
First
the network boot (IPL) is initiated for the LPAR.
Next,
the LPAR issues BOOTP requests to the server IP-address specified in
the IP Parameters menu. It receives the BOOTP record information from
/etc/bootptab on the NIM master. This record specifies the TFTP
server for sending a bootable kernel. The LPAR issues TFTP requests
to the server listed in the /etc/bootptab sa field from the NIM
master.
Then
control is passed to the transferred and loaded AIX 5L kernel.
In
this case the installation is made using a NIM mksysb resource.
After
installing the software, the boot image is created.
Once
the installation is finished and the LPAR is restarted and The newly
installed kernel is loaded and the LPAR is restarted
LPAR
and VIO Server Terminology
Logical
partitioning
Logical
partitioning (LPAR) is the ability to logically slice up a single
system's CPU, memory, and other resources to create multiple and
separate servers. Each LPAR has its own allocation of CPU, memory,
and I/O devices. This type of partitioning is done at the firmware
level, not at the physical resource level. Thus, with the IBM System
p5 servers, you are able to create LPARs using Micro-Partitioning™
-- assigning less than one physical CPU per LPAR.
Virtual
I/O Server
It
is a special kind of partition called a Virtual I/O Server (VIO
Server). The VIO Server provides the ability to share I/O resources
among several LPARs. You define virtual Ethernet and disk devices on
the VIO Server and then make them available to the other LPARs on the
system. Without the ability to share I/O devices on the managed
system, each LPAR would require its own dedicated devices. If you
have two LPARs on a system, you would need at least two Ethernet
cards and two disk controllers. However, if you have 15 LPARs, then
you would need at least 15 Ethernet cards and 15 disk controllers.
With the use of VIO LPARs, you could host 15 LPARs with a much
smaller number of Ethernet and disk controllers.
Of
course, you are still able to dedicate I/O devices to an AIX
partition if you need to for performance reasons. For example, if you
have a large database LPAR that requires a large amount of
throughput, you can dedicate a disk controller to that LPAR so that
it won't have to compete for I/O resources with other LPARs using the
VIO's disk controller.
On
the other hand, you might have several small LPARs that do not
require a large amount of data throughput. They would be ideal
candidates for using the VIO Server since each of them would not
completely utilize the full capacity of an Ethernet card or disk
controller (see Figure 3). Together they could take full advantage of
the hardware's capacity
Dynamic
logical partitioning
Not
only are you able to logically carve up your hardware into multiple
LPARs, but IBM provides the capability of dynamically adding,
removing, or moving resources between the partitions while they are
up and running. You can add or remove CPU, memory, or I/O slots to a
running partition without first shutting that LPAR down.
Dynamic
logical partitioning (DLPAR) provides a great deal of flexibility to
your computing environment. As conditions change in your environment,
you are able to react by moving hardware resources to where they are
needed without interrupting services to the LPARs. The options for
using this feature are endless. A word of caution, though, not all
applications are able to handle the removal of CPUs or memory
gracefully, so testing is needed in your particular situation before
you begin to use this feature in a production environment.
In
the rest of this article, I'll discuss the steps you need to follow
to configure an installed p5 system. It is impossible, in an article
of this length, to discuss all the options available to you in
configuring an LPAR system. Throughout the article, I'll cover the
configuration basics and then point you to documents that provide
more detailed information for that particular component. I'm also
assuming the hardware is installed and connected to your network.
Micro-Partitioning
Micro-Partitioning
is the ability to distribute the processing capacity of one or more
physical processors among one or more logical partitions. Thus,
processors are shared among logical partitions.
System
Profile
A
system profile is a collection of one or more partition profiles.
System profiles can be used to specify which partition profiles are
activated at the same time.
Partition
Profile
A
partition profile represents a particular configuration for a logical
partition. A partition profile contains information about the
resources assigned to the partition. These resources include memory,
processor processing capacity, and physical I/O slots. Partition
profiles also include information about which devices provide
important partition functions
Memory
in LPAR
There
are three memory values for a partition profile:
#
Minimum memory: This amount of memory is required for the partition.
The profile will fail to activate if the minimum memory is not met.
#
Desired memory: This is the requested amount of memory for the
partition. On profile activation, the partition will receive an
amount of memory between the minimum and desired amounts depending on
what is available.
#
Maximum memory: The maximum represents the upper limit for memory.
Memory allocations cannot go above the maximum. In order to go above
the maximum, the maximum value needs to be changed.
Dedicated
Processor
Dedicated
processor means you are working with whole processors that are
dedicated to a single partition. The dedicated processor handles the
processing for one specific logical partition. If you choose to
assign dedicated processors to a logical partition, you must assign
at least one processor to that partition.
Shared
Processor
The
shared processing pool allows you to assign partial processors to a
logical partition. The physical processors are held in the shared
processing pool and are shared among logical partitions. At partition
creation time, the shared processing units can be defined as 0.1.
There
are two types
Capped
and
Uncapped
Capped
prohibits the LPAR from using more processing units than is currently
allocated to it. If an LPAR is allocated 1.5 processing units but the
workload requires 2.2 units, the LPAR would not be allowed access to
the additional units, even if they were available in the shared
processor pool.
Uncapped
allows the LPAR to use more processing units than is currently
allocated. In this example, the LPAR would have access to the
additional 0.7 processing units needed for the workload. If Uncapped
is selected, you need to provide the Weight value for this LPAR.
LPARs with higher Weight values receive higher priority when shared
pool resources are fully used.
Virtual
Processor
Virtual
processors tell the LPAR's OS how many physical processors it has.
The OS cannot use parts of a processor, so you have to tell it in
whole numbers how many processors it can use. Also, the number of
virtual processors limits how many physical processors an LPAR can
use. For example, if you give an LPAR two virtual processors, it
cannot use more than two physical processors even though Maximum
processing units is higher than two.
■Minimum
number of virtual processors: You must have at least one virtual
processor for every part of a physical processor assigned to the
LPAR. For example, if you have assigned 2.5 processing units to the
LPAR, the minimum number of virtual processors is three.
■Desired
number of virtual processors: You can assign a virtual processor to
every 0.1 processing unit allocated to the LPAR. There is no
recommended value for this configuration setting. You need to use
trial and error to determine what is the best setting for your
application(s).
■Maximum
number of virtual processors: You can only have 10 virtual processors
per processing unit. Therefore, you cannot assign a value greater
than 10 times the maximum processing units value.
Virtual
I/O Adapter
Virtual
IO adapters give a partition the flexibility to use certain types of
resources with requiring the physical hardware to be present. If the
partition will be using virtual IO, make sure that the Yes
radio
button is selected. Otherwise, select the No
radio
button.
The
following virtual IO adapters can be created:
Virtual
Ethernet
Virtual
Serial
Virtual
SCSI
Virtual
Ethernet
Virtual
Ethernet technology is supported on AIX® 5.3 on POWER5™ hardware.
This technology enables IP-based communication between logical
partitions on the same system using a VLAN capable software switch in
POWER5 systems. Shared Ethernet Adapter technology (part of the
optional Virtual I/O Server feature on POWER5 hardware) enables the
logical partitions to communicate with other systems without
assigning physical Ethernet slots to the logical partitions.
The number
of virtual Ethernet adapters for each LPAR varies by operating
system. AIX 5.3 limits the number of virtual Ethernet adapters to 256
virtual Ethernet for each LPAR. Besides a PVID, the number of
additional VID values that can be assigned for each virtual Ethernet
adapter is 20, which indicates that each virtual Ethernet adapter can
be used to access 21 networks. The HMC generates a locally
administered Ethernet MAC address for the virtual Ethernet adapters
so that these addresses do not conflict with physical Ethernet
adapter MAC addresses. To ensure uniqueness among the virtual
Ethernet adapters, the address generation is based on the system
serial number, LPAR ID, and adapter ID.
When
using the Integrated Virtualization Manager, only PVID is allowed (no
additional VLANs), and only the PVID may only be 1-4.
Virtual
Serial
Virtual
serial adapters provide a point-to-point connection from one logical
partition to another, or from the Hardware Management Console (HMC)
to each logical partition on the managed system. Virtual serial
adapters are used primarily to establish terminal or console
connections to logical partitions.
When you
create a logical partition, the HMC automatically creates two virtual
server serial adapters on the logical partition. These virtual server
serial adapters allow you to establish a terminal or console
connection to the logical partition through the HMC.
You can
also create pairs of virtual serial adapters on logical partitions so
that you can access and control one logical partition directly from
another logical partition. For example, one logical partition uses
the disk resources of another logical partition using virtual SCSI
adapters. You can create a server serial adapter on the logical
partition that uses the disk resources and a client serial adapter on
the logical partition that owns the disk resources. This connection
allows the logical partition that owns the disk resources to shut
down the logical partition that uses the disk resources before you
back up data on the logical partition that owns the disk resources.
Virtual
SCSI
Virtual
SCSI (Small Computer Systems Interface) adapters provide one logical
partition with the ability to use storage I/O (disk, CD, and tape)
that is owned by another logical partition.A virtual SCSI client
adapter in one logical partition can communicate with a virtual SCSI
server adapter in another logical partition. The virtual SCSI client
adapter allows a logical partition to access a storage device being
made available by the other logical partition. The logical partition
owning the hardware is the server
logical partition,
and the logical partition that uses the virtualized hardware is the
client
logical partition.
With this arrangement, the system can have many server logical
partitions.
NPIV
(Network Port ID Virtualization)
N_Port
ID Virtualization is a fibre channel industry standerd method for
virtualizing a physical fibre channel port. NPIV allows one F_Port
to be associated with multiple N_Port Ids, so a physical fibre
channel HBA can be shared accross multiple guest operating systems.
On
POWER, NPIV allows logical partitions (LPARs) to have dedicated
N_Port IDs, giving the OS a unique identity to the SAN, just as if it
had a dedicated physical HBA(s).
