|
|
United States-English | |
|
|
 |
|
HP Servers and Workstations: Managing Systems and Workgroups > Chapter 2 Planning a Workgroup
Setting Disk-Management Strategy |
|
|
This section covers:
Read these guidelines in conjunction with “Distributing Applications and Data”.
As with memory, the simple answer to the question, “How much disk capacity should you buy?” is “As much as you can afford.” You can almost guarantee that however much capacity you buy now, your users and their applications will find a way to exhaust it within a year. All the same, you need to plan. Even if you are equipping your workgroup from scratch, and the team of users is being formed from scratch, it’s likely that the work the team will be doing has not just been invented; somewhere in your company the same or similar work is being done, and that’s where you need to start.
The answers to these questions will give you a starting point for determining how much disk space to allow in the non-“system” volumes of your file and application servers - that is, in the application (/opt), work, mail and home directories and in the database volumes. It will not hurt to allow for 100% growth in the first year in these directories (or more than that if you if you do not plan to control the growth of user directories with disk quotas - see “Managing Disk Space Usage with Quotas”). During the year you can monitor actual growth and plan next year’s purchases accordingly. There is no standard way for estimating swap, except that swap must be at least equal to the memory of the local system. This may be sufficient for clients; it almost certainly will not be for servers. “Managing Swap and Dump” provides some guidelines for estimating swap needs, but there is often no substitute for running the applications and seeing what happens. ExampleHere’s what we did to figure out how much swap would be used by the tools used to develop this document. We booted a workstation (an HP9000 715 running HP-UX 10.01 with 96MB RAM), started up VUE, opened one window, then started up all the applications one after another, using swapinfo(1M) to check swap usage each time.
Running HP-UX at run-level 3 took 19-20 MB of reserved swap. Transitioning to run-level 4 and opening one VUE window brought us up to 39-40 MB of reserved swap; this is shown in the first row of the table; subsequent rows show what happened as we started up the applications. Totals in the right-hand column are cumulative. Table 2-2 Sampling Swap Usage
We repeated the experiment on another, much smaller system (32 MB RAM) and got similar results, drawing the conclusion that a workstation running these applications locally would need to have about 30 MB of swap available, for a minimum of 70 MB configured swap. In our particular situation, since we didn’t have a powerful application server at the time, and did have several moderately powerful workstations, we decided it made sense for us to import these applications onto the workstations (via NFS mounts from our file server), and accordingly we added file-system swap to those systems that looked as if they would need it. If you were to run such an experiment on a multiuser application server, you would need to run as many copies of each application as would actually be running at peak times, and would need to be a good deal less simple-minded than we were in terms of the functions the applications performed and the frequency and complexity of the samples. A workstation needs enough space on the local disk to hold the operating system, plus sufficient swap for the workspace manager and whatever applications will be running locally. Plan on providing each workstation with at least a 1 GB disk. Both HP-UX and NT workstations may be able to get by with 500 MB, but barely, particularly if some sizeable applications are running locally (via NFS or from the local disk); see “Swap”. This section provides a brief summary of the disk-management tools HP-UX provides; for details see Chapter 6 “Administering a System: Managing Disks and Files”. LVM is the most common disk-management method for current versions of HP-UX on all platforms. As of release 10.20, it is the default on Series 800 systems (except those installed with a root disk smaller than 1GB), and is required on Series 700 systems whose root disk is larger than 2GB. LVM divides up the disk in much the same way as the “hard partitions” implemented under earlier versions of HP-UX for systems, but logical volumes are very much easier to reconfigure than partitions, and they can span two or more disks. These two attributes make LVM a much more powerful and flexible tool than hard partitions. The VERITAS Volume Manager provides alternative online disk management to the HP Logical Volume Manager and HP MirrorDisk/UX products. The VERITAS Volume Manager is included on the HP-UX 11i Application CD and, as of the September 2002 release of HP-UX 11i version 1, VxVM is included in the operating environments and enables VxVM rootability. With VxVM rootability, you can choose to configure your root volume during installation with Ignite-UX, or you can use the conversion tools installed with VxVM to configure your root volume at a later time. For more information and details, read HP-UX 11i Installation and Update Guide and the VERITAS Volume Manager 3.5 documents:
For additional information on other versions of VERITAS Volume Manager, see the “VERITAS Volume Manager and File System” neighborhood at HP’s HP-UX documentation web site: http://docs.hp.com/hpux/os/11i/index.html#VERITAS%20Volume%20Manager%20and%20File%20System
The alternative to LVM is “whole-disk” management, which as the name implies treats the disk as a single unit. Advantages of a logical volume manager:
Disadvantage of LVM:
You should certainly use LVM on file and application servers; on workstations that have only a single disk, used only to store the operating system and for swap, LVM is not necessary, though you may choose to implement it anyway for the sake of uniformity, or because you expect to add more disks to some workstations over time. Disk mirroring is available only under LVM. See “Logical Volume Manager (LVM)”. Disk mirroring allows you to keep a live copy of any logical volume; the data in that volume is in effect being continuously backed up. Strict mirroring ensures that the mirror copy is on a separate disk (in the same volume group). Disk mirroring has the obvious advantages of increased data protection and system availability, and the equally obvious disadvantage of consuming twice as much disk space (or as many times more as there are mirror copies). Use disk mirroring for volatile, mission-critical data; you do not need to mirror volumes containing static software such as the operating system. Disk striping is available only under LVM. See “Logical Volume Manager (LVM)”. Disk striping distributes logically contiguous data blocks (for example, chunks of the same file) across multiple disks. This speeds I/O throughput for large files when they are read and written sequentially (but not necessarily when access is random). The disadvantage of disk striping is that the loss of a single disk can result in damage to many files, since files are purposely spread piecemeal across two or more disks. Consider using disk striping on file systems where large files are stored, if those files are normally read and written sequentially and I/O performance is important. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
