MANAGING SYSTEM STORAGE AREAS
LOGICAL VOLUME MANAGEMENT | SWAP, CRASH AND DUMP
SYSTEM RESOURCE ADMINISTRATION

STORAGE SPACE ALLOCATION | ARRAYS

Storage Space Allocation

AN OVERVIEW OF LOGICAL VOLUME MANAGEMENT | FILE SYSTEM/LOGICAL VOLUME SETUP
NEW PROJECTS | PROJECT SPACE INCREASES | RELEASE OF DISK SPACE

Under LVM, physical device layout is isolated from file system structure by assigning from one to as many as 32 physical devices (e.g., disk drives) to a logical device called a Volume Group. The figure below illustrates three Physical Volumes (disk drives) combined into a pool of available space which can then be divided into various sized Logical Volumes.

Relationship Between Physical Volumes and Volume Groups

Under LVM using Arrays the System Administrator has even more flexibility in the use of the computers storage capacity.

An array (supported by HP 9000/700 & 800 computers running HP-UX version 10.10 and higher) is a group of standard hard drives put together and controlled as a single unit by software and SCSI controllers. The Operating System sees an array as a single unit of storage space.

To increase performance and provide faster seek times and less head movement, each array can be sub-divided into a maximum of 8 Logical Units (LUNs). A LUN can be any size, from 1MB to the size of the un-allocated (free) space on the array. The Operating System sees a LUN as a hard drive.

In order to be used in LVM the LUNs need to be turned into Physical Volumes. Some folks say that they are 'formatted' into this state. I prefer to think of it another way. The LUN is an empty space that has no idea how big it is, how large it's Physical Extents are, or to which Volume Group it belongs. Changing the LUN into a Physical Volume gives it all that information. Actual formatting comes when you create Logical Volumes.

LUNs can be further sub-divided into Volume Groups.

Relationship Between Arrays, LUNs, Volume Groups, and Logical Volumes

The aggregate total of storage space "owned" by a Volume Group can then be allocated to Logical Volumes, which are utilized in a manner roughly analogous to traditional disk segments. A Volume Group can contain several Logical Volumes of various sizes and configurations. A single Logical Volume can span disks/LUNs and be larger than either. Like disk segments, Logical Volumes can hold file systems, swap and/or raw data areas.

File systems created on Logical Volumes are made accessible by mounting them on the directory structure. All of this is transparent to the users. From the system administrator’s perspective, however, there are major advantages:

Logical Volumes can span disks, LUNs and/or Arrays. As a result, the file systems, swap areas, or areas of raw disk space contained within Logical Volumes can be very small or be as large as 128 gigabytes. Logical Volumes are extendible. The sizes of Logical Volumes (and the file systems or other forms of disk usage residing in them) can be extended or reduced when needs change, without the need to re-format disks and restore data. Logical Volumes allow soft partitioning. You can create a Logical Volume of any size up to 128 GB. Soft partitioning means that they can be expanded as opposed to hard partitioning of set, unchangable sizes. Within a single Volume Group, you can create up to 255 Logical Volumes.

File System/Logical Volume Setup -
HP-UX file systems make disk space available to projects while maintaining control of the projects’ total disk space utilization. Under LVM this is done by creating a Logical Volume of an appropriate size for each project’s aggregate disk space requirement, creating a file system on that Logical Volume, and mounting the file system on the project’s base directory.

On systems with arrays Logical Volume/file system setup is a eight-step process:

1. Create LUNs from the array using arraycfg 2. Format the LUN using arrayfmt 3. Create Physical Volumes from the LUNs using pvcreate. 4. Create Volume Groups by combining PV’s using vgcreate. 5. Create Logical Volumes inside Volume Groups using lvcreate. 6. Put a file system on the Logical Volume using newfs. 7. Mount the file system using mount. 8. Modify the system /etc/fstab file to make the mount permanent (if WWdesired).

New Projects -
As new projects come into being, meet with the client and determine their space, backup and timing needs. Allocate disk space adequate for the project’s stated requirements, and create/mount the project file system.

Some clients expect to be allowed to set up their own file structures and space allocation - and some System Administrators let them do it. Under no circumstances should anyone except the SA add to or take from the system. You are responsible for that system and have a need to know everything about it. If I have a pet peeve concerning computers it's that SA's have a tendency to "allow" others to do things that they should not be doing. End of sermon.

Project Space Increases -
In the event that a client's allocated disk space (file system) becomes full - first, make an attempt to eliminate redundant, obsolete, unneeded files, "core" files, files not recently accessed, etc. If that doesn't alleviate the problem expand their allocated disk space.

You are encouraged to become familiar with the many options to the HP-UX find command, which can be used to generate lists of files based on criteria such as date of modification, size, ownership, etc. Examples of some can be found in "WORKBOOK/THE LOG BOOK/Forgettable Commands".

Release of Disk Space -
Eventually, projects terminate, software is replaced, and data becomes stale and unused. When this happens remove Logical Volumes, Volume Groups, Physical Volumes, etc. as necessary. See "WORKBOOK/THE LOG BOOK/System recovery Information". This section has advice on keeping a current, printed output of, among other things, PVs, VGs and LVs.

ARRAY SHUTDOWN
CREATING NEW LUNS
ARRAY CAPACITY/PERFORMANCE OPTIMIZATION
CREATING NEW PHYSICAL VOLUMES
ADDING PHYSICAL VOLUMES TO EXISTING VOLUME GROUPS
CREATING NEW VOLUME GROUPS
CREATING LOGICAL VOLUMES
CREATING AND MOUNTING FILE SYSTEMS
INCREASING THE SIZE OF A LOGICAL VOLUME
EXTENDING A LOGICAL VOLUME TO A SPECIFIC PV
EXTENDING A LOGICAL VOLUME AND EXTENDING A FILE SYSTEM
REDUCING THE SIZE OF A LOGICAL VOLUME
MOVING DATA IN LOGICAL VOLUMES FROM PV TO PV
REMOVING LOGICAL VOLUMES

Management of an array is conducted through the ARMServer process which is the server portion of the Hewlett-Packard Advanced Disk Array management software. It monitors the operation and performance of the disk array, and services external requests from clients executing disk array commands. The ARMServer process monitors disk array performance and status, maintains disk array logs, initiates diagnostics, and allows clients to examine and change the disk array configuration.

The ARMServer process ("arraymon") must be running to allow management of the disk array using the ARM command line utilities. Host I/Os are not dependent on the ARMServer process and are serviced regardless of whether the ARMServer process is running or not. Because of its importance in managing the disk arrays, the ARMServer process is launched automatically when the system is booted.

To start the ARMServer daemon -

/usr/init.d/hparray start

/usr/init.d/hparray stop

Arrays are meant to be used and used hard. They are designed for it. Diagnostics run against arrays with minimal use show a multitude of errors which go away as usage is increased.

There are three ways to manage arrays;

System Administration Manager (SAM) - about 45% of all array commands WWcan be done this way. AutoRAID Management utilities (ARM) - 100% of all array commands can be WWdone through keyboard input using ARM. Disk array control panel - about 80% of all array commands can be done using WWthe control panel menus.

You will not be able to utilize all of the storage space on an array. On arrays containing 12 - 2.1 Gigabyte hard drives (25.2GB total space); 2GB is reserved for Active Hot Spare, 2GB is reserved for Parity, and about 1GB is reserved for RAID 0/1 and SCSI controller overhead - leaving about 18.6GB for actual file system use. Active Hot Spare - when used, the array reserves enough capacity to rebuild the largest disk. Parity - capacity used to support the data protection provided by RAID 5. RAID 0/1 and controller overhead - capacity used to support the protection provided by RAID 0/1 which provides automatic striping and mirroring for the array.

Arrays are either RAID 0/1 or RAID 5. The System Administrator chooses one or the other when setting up the array. AutoRAID, an optional product from Hewlett-Packard, allows automatic switching from one to the other. It maintains RAID 0/1 as long as there is sufficient space on the array to do so and automatically switches to RAID 5 as the array fills to a set percentage of it’s capacity.

Array Shutdown -
      Consider shutting down the array -

For scheduled power outages. If the array will be shut down for more than a week. If you intend to move all of the array’s hard drives to another array. To replace the batteries in both controllers at the same time. To replace a controller in a single controller system.

Before an array Shutdown is performed, all mounted file systems and Logical Volumes mapped to the disk array must be unmounted.

mount - produces a list of all currently mounted file systems umount -a - unmounts all mounted systems umount /tmp - unmounts the tmp system umount /home - unmounts the home system

To work with arrays you need to know the array id number. It can be found by using the menu on the front panel of the array itself or by issuing the line command -

/usr/sbin/hpC2400/arrayscan -i - this will produce a list all of the arrays WWconnected to the system and their respective array id (serial) numbers.

arraydsp -R - will rescan for disk arrays. /usr/init.d/hparray start - starts the Array Monitor Daemon (arraymon). /usr/init.d/hparray stop - stops it.

arraymgr -s shut -v [array id] - this shuts down the array. It can also be WWshutdown using the control panel menu on the array. An array cannot be WWshutdown by SAM.

arraymgr -s start -v [array id] - restarts the array. It can also be restarted using WWthe control panel menu on the array. An array cannot be restarted by SAM.

Creating NEW LUNs -
Only capacity that is assigned to LUNs is visible to the operating system.

To improve performance, create several smaller LUNs instead on one large one. By increasing the number of LUNs you effectively increase the total size of the command queue, which assures that enough commands are set and waiting to keep the array busy.

Another factor to consider in sizing LUNs is backup. Avoid creating a LUN of greater size than the backup media. This allows you to backup an entire LUN without changing media.

arraydsp -l [array id] - this command will give you a list of all of the LUNs currently WWon the array.

arraycfg -L [number 0 to 7] -a [size in MB] - this configures the LUN, numbers it WWto the number you chose for it and at the size you want. It also sets up a special raw WWdevice file (/dev/rdsk/c?t?d?) and block device file (/dev/dsk/c?t?d?) for the WWLUN.

arrayfmt -L [LUN number] [array id] - this can be done using the control panel WWmenu. It cannot be done by SAM.

arraycfg -L [LUN number] -d [array id] - All data on a LUN is lost when deleting WWit or reformatting it.

NOTE: on arrays with dual controllers arraycfg will create 2 different sets of special device files. One set for the primary controller and another set for the secondary controller. Always use the special devices file associated with the primary controller in LVM commands. Use of the secondary controller special device files will cause unpredictable and unwanted results.

Array Capacity/Performance Optimization -
To increase -

Capacity - Make sure all of the capacity of the array is allocated to LUNs. Do not use Active Hot Spare. Not using the Active Hot Spare will eliminate protection from multiple disk failures). Performance -Leave some capacity unallocated. In most cases, the more RAID 0/1 space available, the better the disk array performance. Enable Active Hot Spare (the array uses this space as RAID 0/1 until needed). Data Redundancy - Enable Active Hot Spare. Enable Auto rebuild. Set Rebuild Priority to High. All this offers the best protection from disk failure. But, Active Hot Spare uses space and Auto Rebuild will greatly reduce performance when rebuilding a failed disk.

Creating NEW Physical Volumes -
Now that LUNs have been created and formatted it’s time to change them into Physical Volumes so you can combine them into, or add them to, Volume Groups.

Turning a LUN or even a regular hard drive into a Physical Volume (PV) is not formatting it. The change from a regular disk/LUN into a PV involves putting Logical Volume Management information on it in certain specific places, setting Physical Extent (PE) size, and reserving space for the PVRA area, the VGRA area, and the bad block pool.

Start by finding the LUN address -

ioscan -fnC disk - to get the special device file name for all disk devices on the system (since a LUN is treated as a disk, it will be listed here). You will need this file name for future LVM commands. Find the special device file to the right of and one line below the hardware path - it may look similar to this - 0/4.4.1 - which means Bus Converter 0, I/O card 4, Array Controller 4, LUN 1. The software state is CLAIMED if it has been successfully formatted and NO_HW if the LUN has been removed or renamed.

pvcreate /dev/rdsk/c?t?d? - Remember to use the device file associated with the WWprimary controller. There are 3 main options you can use with pvcreate -

-B - makes the PV bootable. -f - forces an overwrite of an existing file system on the PV. Use WWthis when the PV exists and you have to change it. -b - prompts for known bad blocks on the LUN or hard drive. WWUse this if the existing PV had known bad blocks.

Create PVs out of all the LUNs or hard drives you expect to use, then combine them into Volume Groups.

Adding Physical Volumes to EXISTING Volume Groups - In cases where a new project is being created on an existing Volume Group with unused space, only steps 5-8 are necessary.

LVM provides a specific utility for use when adding a newly-configured physical device to an already-existing Volume Group. The command format is:

vgextend [volume_group] [device_file_name] - this adds the physical disk space of the device specified by [device_file_name] to the Volume Group specified by [volume_group]. In this case, [device_file_name] refers to the block special device file name (/dev/dsk/c?t?d?) and [volume_group] refers to the Volume Group device file name (/dev/vg??).

Creating NEW Volume Groups -
You, as the System Administrator, will determine when an additional Volume Group should be defined. Specific instances requiring new Volume Groups include:

All appropriate existing Volume Groups already contain the maximum 32 physical ......devices. An existing Volume Group will require more than the maximum 255 Logical ......Volumes

1). Create all Physical Volumes (PVs) to be included in the new Volume Group. 2). Check the system for the next available Volume Group number/name so that VG ......numbers/names are not duplicated - ...... strings /etc/lvmtab - shows you existing Volume Groups and their respective ............names and Logical Volumes. 3). Create the Volume Group directory in /dev - ...... mkdir /dev/vg?? 4). Create the group special file - ...... mknod /dev/vg??/group c 64 0x??0000 - The mknod command is used to create ............a special file. It requires as arguments the major (driver) number, which is 64 for ............LVM, and a minor number in hexadecimal format. The first two characters of the ............minor number must correspond with the two numbers in the Volume Group name ............(as represented by ?? in the above examples). 5). Create the new Volume Group - ...... vgcreate /dev/vg?? /dev/dsk/c?t?d? /dev/dsk/c?t?d? - This will create a Volume ............Group containing two Physical Volumes. Any number of Physical Volumes may be ............listed, up to the maximum of 32.

Some of the more common vgcreate options - -s [Physical Extent size in MB] - if you want to change the PE size .........from it’s default 4MB to 1, 2, 4, 8, 16, 32, 64, 128 or 256MB. .........A change here sets the Physical Extent size for all Physical .........Volumes in the Volume Group. -e - Maximum number of Physical Extents per Volume Group. Set .........by the SysAdmin to control unwanted growth. -p - Maximum number of Physical disks in the Volume Group. Set .........by the SysAdmin to control unwanted growth.

Creating Logical Volumes -
Logical Volumes are created from the remaining disk space available within a Volume Group by using the lvcreate command. Before creating a Logical Volume, determine the characteristics it needs to have. At a minimum answer the following -

Is the volume to be used as a root or primary swap partition? How large (in MegaBytes) is the volume to be? Must the volume reside on a specified physical device, or will any .......device in the Volume Group be acceptable? Must the allocated disk space be contiguous? Is any special naming convention to be used for the Logical Volume?

Next select the Volume Group to be used and verify that it can support the desired characteristics. To determine the current configuration of a Volume Group -

vgdisplay -v /dev/vg?? | more - this will provide information on both the total available space in the Volume Group, as well as the space available on each Physical Volume it contains. For example; if the new Logical Volume requires 400 MB of space and must reside on one disk, then at least one of the physical devices in the Volume Group must contain 400 MB of free Physical Extents.

NOTE: PE (Physical Extents) are not expressed in MB. The default size of a PE is 4 MB, but can vary. Actual PE size in Mbytes is also provided in the vgdisplay output.

Then select the appropriate creation method. The primary method is to choose the appropriate flags of the lvcreate command and use it to create the Logical Volume. This is a single-step process, however, note that when you use this method you cannot specify which disk should hold the Logical Volume's data. But, you can create a Logical Volume using the default characteristics and change them later.

lvcreate [volume_group] [-L | -l size] [-p r|w] [-n [volume_name] [-r y|n] [-C y|n]

Some of the more common lvcreate options - -L - Is the size of the Logical Volume in megabytes. The size specified will ...........be rounded up to the nearest whole Logical Extent size (the default size ...........of a Logical Extent is four megabytes). -l - Is the number of Logical Extents in the Logical Volume. The default is ...........zero; you can create a Logical Volume and later change its size using ...........the lvextend command. Note that either -L or -l can be used but not both. -p - permissions either w for read/write or r for read only. -n - supply your own volume name instead of the default. -r - set the bad block relocation policy to either y for allow relocation or n ...........for prevent relocation. -C - set the contiguous allocation policy, yes or no.

When you create a Logical Volume, you cannot specify which disk should hold the Logical Volume's data. However, if you want to create a Logical Volume of a specific size that uses a specific disk, create the Logical Volume without the -L or -l flag, and then extend the Logical Volume by using lvextend to a specific Physical Volume.

This example shows how to create a Logical Volume of size 400 MegaBytes in the Volume Group vg01 -

lvcreate vg01 -L 400

Creating and Mounting File Systems -
HP-UX Version 10.10 supports two types of file systems--the High performance File System (HFS) and the Veritas File System (VxFS) sometimes called the Journal File System (JFS). The VxFS (JFS), at this time, cannot be run on a trusted system.

newfs is the command for creating a "new" file system. It creates the structure which the operating system needs to access the data on the device.

The command syntax for creating a file system on a newly-created Logical Volume (in this example lvol9 in Volume Group vg01) is -

newfs -F hfs -v /dev/vg01/rlvol9 -This command will create an HFS file system on the specified Logical Volume and provide verbose output describing the actions being taken. The size of the resulting file system will be the largest that the specified Logical Volume can support. This command format will suffice for most new file system creation required under normal operations.

Common newfs options - -F [file system type] - This option specifies the file system type (hfs or vxfs). -V - Echo the completed command line without executing the command. -R swap - Reserve Mbytes of swap/boot space past the end of the file system. -B - Reserve space for boot programs past the end of the file system. -L - Creates a file system with long file names, 256 characters maximum. -S - Creates a file system with short file names, 14 characters maximum. -v - verbose mode, list newfs actions.

Increasing the Size of a Logical Volume -
Logical Volumes are increased in size by using the lvextend command. You can also specify that you want the increased disk space (either in terms of extents or megabytes) allocated to a specific disk (Physical Volume), or you can let LVM determine where to allocate it. Wow, all these choices.

Suppose you want to increase a Logical Volume, /dev/vg01/lvol4, which is currently 48 megabytes, to 100 megabytes.

First, if it contains a file system, make sure the file system is unmounted -

umount /lvol4 - or whatever the mount point is named

lvextend -L 100 /dev/vg01/lvol4

When LVM implements the new size, it will use whole extent sizes. For example, if the extent size is the default four megabytes and you specified -L 98, LVM extends the Logical Volume to 100 megabytes.

Extending a Logical Volume to a Specific PV -
Suppose you have several PVs in a Volume Group. You want to extend a Logical Volume that resides on one of the PVs to 400 megabytes. Also, you want to make sure the increase is allocated to a specific PV. The same command format is used regardless of the previous size or location of the Logical Volume. The added extents will reside on the specified PV. Previously existing extents (if any) will remain in their current location.

To extend a Logical Volume (e.g., /dev/vg01/lvol4) to a specific PV (e.g., /dev/dsk/c3t1d0), explicitly specify the PV’s block device file.

lvextend -L 400 /dev/vg01/lvol4 /dev/dsk/c3t1d0

Extending a Logical Volume and Extending a File System -
If you have a file system which is nearing capacity, you can extend the Logical Volume that contains the file system, and then use the extendfs command to increase the file system.

NOTE: If the Logical Volume you are extending has a contiguous allocation policy in effect, the command to extend the Logical Volume will fail if no contiguous disk space is available.

Unmount the file system you want to extend -

umount /dev/vg4/lvol2

lvextend -L 100 /dev/vg4/lvol2

extendfs /dev/vg4/rlvol2

mount /dev/vg4/lvol2 /projects

The command extendfs -F hfs /dev/vg00/rlvol1 - will extend an existing file system into the newly added Logical Volume space. Note that you use the special device file rlvol9 before the file system is added or extended and lvol9 after. The r signifying that the the Logical Volume is in a raw state with no file system.

Reducing the Size of a Logical Volume -
You can reduce the size of a Logical Volume by using the lvreduce command. Reducing the size is appropriate when you want to use it for another purpose that requires less space.

Suppose you have a Logical Volume of 80MB. You no longer need the current data in it, and you would like to use it for another purpose that requires only 40MB:

lvreduce -L 40 /dev/vg03/lvol4

Moving Data in Logical Volumes From PV to PV -
You can use the pvmove command to move data contained in Logical Volumes from one PV (disk or LUN) to another within the same Volume Group.

For example, you can move a Logical Volume's data from one PV to another to gain space on the first PV for some other purpose. Also, you can move all data from one PV to another. You might want to do this so you can remove a LUN to create more space for RAID 0/1. After removing the Logical Volume data you can then remove the PV from the Volume Group.

Suppose you want to move the data in the Logical Volume, /dev/vg01/markets, from the PV /dev/dsk/c3t0d2 to the PV /dev/dsk/c4t0d2 both of which are in the same Volume Group -

pvmove -n /dev/vg01/markets /dev/dsk/c3t0d2 /dev/dsk/c4t0d2

If you want to move all the data on a given PV within a Volume Group, you can use the pvmove command to move the data to other specific PV’s or to other available space within the same Volume Group.

To move data off PV /dev/dsk/c4t0d2 to the destination PV /dev/dsk/c5t0d2 -

pvmove /dev/dsk/c4t0d2 /dev/dsk/c5t0d2

To move data off PV /dev/dsk/c4t0d2 and let LVM transfer the data to some other unspecified, available space in the same Volume Group -

pvmove /dev/dsk/c4t0d2

Removing Logical Volumes -
You can remove a Logical Volume with the lvremove command -

lvremove /dev/vg03/lvol2

SWAP | CRASH | DUMP

Swap -
Swap space is an area on a high-speed storage device, reserved for use by the virtual memory system for the paging process.

Physical memory is a finite resource on a computer. This means that only so many processes can fit into physical memory at any one time slice, even though many more processes may actually be ready to run or execute. Because demand for physical memory may exceed actual supply, the concept of swap was introduced to computer systems. When demand for physical memory is high, portions of processes are pushed out to the swap area on the disk. When physical memory demand is low, portions of processes are brought back into physical memory from the swap space.

Most processes are shared text processes. A shared text process is a process that allows its code to be shared among all users currently executing its code. Since text is shared, it cannot be altered and therefore the original copy of the text from the executable file is always up to date. Swap space is not required for text, since we can always page in text from the executable file. A process' space on the swap device is reserved at process start up time; therefore, swap must be large enough to hold all executing processes.

HP-UX swap space management allows you to allocate swap as needed, while the system is running, without having to regenerate the kernel.

System performance can degrade if the system spends too much time paging - a condition known as thrashing. Fix thrashing by adding more physical memory.

Remember, two swap areas on different physical disks are much better than one single swap area of equal size. And, don't create other swap areas on the disk containing the primary swap.

Types of Swap Space -

Use the command /etc/swapinfo to find out how much swap you have allocated.

Swap space computations are rather long and involved and not intended to be introduced here. Use the top command to check on the amount of physical memory being used. It will take watching it closely for several months to get a feel for who and what is using the memory and see if you detect an increase in the physical memory being used.

Crash -
The unexpected shutdown of a program or system. If the operating system crashes it requires the system to be rebooted. As it crashes it tries to store the contents of it's volatile memory on the hard drive. If successful it will be stored in the primary swap space and then transferred to /var/adm/crash/core.0/ which, on the T520 using 10.1+ is the default dump site, if there is enough room.

If you search /var/adm/crash/core.0/ after a crash, dump, or panic you will find several files, the number dependant on the size of the computers memory.
bounds will be a digit generated by the operating system to be added to the next set of dump files. The first dump will have .0 as the filename extension. Dump #2 will have .1, etc.
vmcore.0 (and there will be several of them) will be the core snapshot.
vmunix.0 will be a copy of the kernel at crash time.
you may also find some .gz files which would be vmcore files compressed using gzip.

All in all a rather large mass of data.

These files are extremely valuable for analysis by HP to determine the reason for the crash.

Dump -
A dump, also known as a 'core dump' is similar to a snapshot of your systems memory at the time of a panic, crash, or hang.

If a system hangs a dump can be forced by Transfer of Control (TOC). The resulting dump can then be analyzied for the cause of the hang.

The dump area is disk space used by the savecore command to write an image of the core memory after a crash, panic, or hang. The analysis of a core dump may be useful in trouble shooting and restoring the system to a good working order.

By default the primary swap device also serves as a dump area when no other dump area is specified. Using primary swap as the dump area will conserve disk space. You can, however, configure different or multiple dump spaces/devices on a disk or Logical Volume. This area can also be used for swap. Make sure that any areas used for dump are contiguous with no bad block relocation.

To insure that you get a full core dump in the event of a system crash make your dump area size one and one half times your physical memory.

To create a dump logical volume -

lvcreate -C y -r n -L 20 /dev/vg00

- set the contiguous allocation policy (-C y) and specify no bad block relocation (-r n). The -L switch is the Logical Volume size in MB. /dev/vg00 the dump space must be in this Volume Group. Use the -n switch if you wish to name the Logical Volume instead of accepting a default name.

Check the /stand/system file for an entry about dump locations. It is usually in the * Kernel Device Info section. It should say "dump lvol" if a dump Logical Volume is currently configured and "dump none" if not.

Two more things - (1) a dump Logical Volume must reside within the first 2GB of a Physical Volume. And, (2) the /sbin/lvlnboot command (prepare a Logical Volume to be root, primary swap, or dump volume) will not allow you to set up a dump logical volume larger than that BUT swap logical volumes can be - play with it.

CPU MONITORING | DISK MONITORING
ADDING/DELETING SOFTWARE | SOFTWARE INSTALLATION | PRE-INSTALLATION PROCEDURES | PRC INSTALLATION PROCEDURES | HEWLETT-PACKARD INSTALLATION PROCEDURES | HEWLETT-PACKARD REMOVAL PROCEDURES

CPU Monitoring -
The Hewlett-Packard HP-9000 T520 is a very efficient processing unit, and with 6 processors on line it is unlikely that Central Processing Unit (CPU) limitations will be a limiting factor on a continual basis. Nevertheless, during some CPU-intensive processing it is possible that the system load will reach levels where users may begin to notice performance degradation for short periods of time. The objective of the system administrator is to detect these usage "spikes", understand their cause, and implement long-term corrective action. In rare instances direct intervention may be required to reduce short-term system load, but this should be the exception.

Several tools are available to the System Administrators to assist in monitoring and controlling CPU usage. In addition to standard UNIX utilities such as sar, top, iostat, vmstat, and ps, the T520 also has the glance tool. These tools all share one serious limitation--they require hands-on monitoring and intervention, or the writing of complex shell scripts, to capture and preserve transitory performance data. This limitation could be overcome on the 9000/800 Series environment by installation of Hewlett-Packard’s OpenView suite of network management tools. Used in combination, these tools provide a capability for automated detection of potential performance bottlenecks and detailed analysis of performance problems.

Disk Monitoring -
The System Administrator has two distinctly different aspects of disk usage to monitor, the allocation of disk space and the efficiency of disk access. Allocation of disk space is primarily a front-end task which is accomplished through individual user account disk quotas and project file system sizing if these measures are necessary. These techniques set a hard limit on the maximum resource utilization of individuals and projects and have the benefits of being simple for the user community to understand and self-enforcing.

Monitoring and tuning of the system for efficient disk access is a much more complex task. The basic objective is to balance the I/O load across the available disk storage devices to the extent practical, thus ensuring the quickest possible read/write response for all system users. The Oracle RDBMS engine in particular is extremely I/O intensive and requires careful planning to ensure decent performance.

As mentioned before, several tools are available to the System Administrators to assist in monitoring and controlling disk usage including standard UNIX utilities such as sar, iostat, glance and Hewlett-Packard’s OpenView suite of network management tools.

Adding/Deleting Software -
Part of your job will be to install, remove, and/or upgrade Commercial Off-The-Shelf (COTS) software products which may from time to time be purchased for your units' or your clients' use. How the choice of software is made and who approves the selection is a different process in almost all installations. The main point to emphasize here (again) is that nothing gets added to, taken from, or changed on your system without your direct knowledge. The choice of host(s), installation directory, permissions, use times, backup schedules, etc., should be a coordinated effort between yourself, security (if it's an issue), your upline chain of command, and your client, based on the intended use of the product, its characteristics, and subject to the clients' guidelines.

Software Installation -
After the appropriate request/approval of COTS software, these products should be installed in accordance with the software vendor’s installation guide/manual instructions, but subject to the following restrictions:

No commercial software product shall be installed directly on the "/" (root) or "/usr" file systems. This is to prevent problems which can be caused by full root and /usr file systems. For the same reasons, application products which create and maintain databases or log files which grow over time, shall be installed in such a way that these logs or databases are not stored directly on "/" or "/usr".

Pre-Installation Procedures -
Before installing new software -

Read any Read Me First documents which come with the update media. Make a note of the device name for your installation device. Ensure that your TERM environment variable is set correctly. Obtain codewords and hardware IDs if using codeword-protected media. Ensure there is adequate disk space to perform the installation. Clean up the file system using fsck. Perform a full system backup. Save a copy of the kernel and system configuration files

PRC Installation Procedures -
Software products or upgrades procured through the PRC Super-Mini Program are usually installed using the prcinst program. Execution of this program is very simple - as root, issue the command prcinst from the command line after placing the distribution tape in the tape drive. Then follow the instructions which appear on the console. NOTE: The prcinst program is an executable shell script which assumes a default tape device name of /dev/rmt/0m. If errors are encountered during installation which seem to indicate an erroneous choice of tape drive, e.g. "device not found", view the command to verify that it is accessing the correct device, and if not modify the file to look for the tape device you are using for the installation.

Hewlett-Packard Installation Procedures -
All Hewlett-Packard software products (and many products from other vendors) utilize the swinstall utility (it's also the one I use). This utility looks for a software 'Depot', on the target device, from which it displays product availability information, and does preliminary analysis on products selected for installation. It will verify sufficient free space on the file systems to be used and prepare a log file with the results of that analysis.

The software 'Depot' can be in a directory on another server, a tape device, a directory on the installing host, or a directory on a CD-ROM. The installer should first verify that the 'Depot' initially identified by the swinstall program is the correct one, and input the fully-qualified path to the desired Depot if it is not correct. Note that for CD-ROM installations, the Depot location may be several directory levels under the /CD-ROM mount point.

Next, select and mark the product(s) to be installed, using the Actions/Mark for Install menu option. Once all desired products have been marked, use the Actions/Install (Analysis) option. This will perform the pre-installation analysis and produce a log of the results. Review the log for possible conflicts with the installation policies.

If no analysis errors or other problems are noted, select Actions/Install to initiate actual product installation. When complete, review the session logs before exiting swinstall. Complete any vendor set-up or licensing steps required.

Hewlett-Packard Removal Procedures -
HP-UX constructs a record of products installed using swinstall. This record is used by the swremove utility to manage clean removal of such products. The simplest way to determine if a product should be removed with swremove is to launch the swremove program and look for the product in the list generated by the program. The process of removal is essentially the same as for installation--choose a product, mark it for removal, run the analysis, and finally do the removal.

Prepared by: Everette Smith, Impact Innovations Government Group, Inc.

Back

Home | Index | Startup & Shutdown | SAM | LVM | Devices | Security | Workbook | Disaster | Information Sources | Glossary

Continue