unx33.htm

Linux Unix揭密.高质量电子书籍.对学习Linux有大帮助,欢迎下载学习.

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP: </B>You must not only consider who will use the system right away, but because you only install UNIX once, consider who might use the system over the next six months to a year.

<BR></NOTE>

<HR ALIGN=CENTER>

<H5 ALIGN="CENTER">

<CENTER><A ID="I7" NAME="I7">

<FONT SIZE=3><B>For What Purpose?</B>

<BR></FONT></A></CENTER></H5>

<P>UNIX systems that are being used as shared development machines, or are going be placed in a common user area, will need a lot of swap space, a large section of the disk for temporary files, and more of the packages from the operating system than 
systems that are just being used on a single user's desk. In addition, if the system is going to be used as a computation or database server, it will need increased swap space.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I8" NAME="I8">

<FONT SIZE=3><B>What Other Systems Are Located on This Segment of the LAN?</B>

<BR></FONT></A></CENTER></H4>

<P>As stated in the section &quot;What Do I Need to Know from the Start?,&quot; you have to consider all of the systems on this segment of the LAN. You are looking for systems that provide access to sections of the operating system, provide access to 
application disk areas, have sufficient disk and memory resources to handle your diskless clients, and make suitable servers for the other systems on the segment.

<BR></P>

<P>In UNIX it is a good idea to remotely serve systems with most of the operating system packages. Dataless systems are a good idea. Sharing the operating system not only saves disk space, it also makes the future task of upgrading the operating system 
easier. You only have to upgrade the server system with the full distribution, a process that can take an hour or more. For the Dataless clients, a small, few-minute procedure will update the small amount of the system that is located on their private 
disks.

<BR></P>

<P>If a little disk sharing is good, isn't a lot better? If you are running diskless clients, they need no upgrade at all. All of the upgrade is done on the server. However, there is a downside to diskless systems: excessive network traffic. A diskless 
system depends on its server not only for the operating system, but also for its swap and temporary disk space. The network is not as fast as a local disk, especially if it is getting overloaded by too many diskless clients. A reasonable trade-off is to 
use diskless clients for small systems that are used by application users, and dataless clients for the rest.

<BR></P>

<P>When you make a system a diskless or dataless client, you reduce redundancy in the segment. These systems are totally dependent on their servers to function. If the server is down for any reason, these systems are also down. This causes many systems to 

go down if a server is down. (This includes while upgrading the server with a new revision of the operating system.) You should not place mission-critical applications on systems that are clients of other systems. Having a mission-critical system freeze 
due to NFS Server Unreachable is not good.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I9" NAME="I9">

<FONT SIZE=3><B>Determining Suitable Servers</B>

<BR></FONT></A></CENTER></H5>

<P>It's usually easier to determine suitable servers than suitable clients, so start there. To make a good server system, you need the following:

<BR></P>

<P><B>Plenty of RAM</B>&#151;A server must not only cache files for its own use, but also for the demands of its clients. Having plenty of RAM so the in-memory disk cache managed by UNIX can be large really helps on servers. With the rapid drop in memory 
prices, what used to be a good-sized buffer might not be any more, but as a minimum, consider 32 MB of RAM in the system.

<BR></P>

<P><B>Fast Disks</B>&#151;The client sees the delay to read a disk block as the time to ask the server for the block, the time the server takes to read the block, and the time to transmit the block over the network back to the client. If the server has a 
fast disk, this time might be no longer, and is often shorter, than reading the same number of blocks locally.

<BR></P>

<P>Since a server is handling multiple clients, including itself, it is more likely that a disk block is already in the server's disk cache. This is especially true for program files and the operating system utilities, as they are used often. Access is 
then very fast, as the disk read time is not needed at all. This helps make servers as responsive as if they were reading the disk block locally on the client server.

<BR></P>

<P><B>Sufficient disk space</B>&#151;A server will hold not only its own files and a copy of the UNIX operating system, but also the swap and temporary space for its diskless clients. A suitable server should have some spare disk space for adding not only 

the current clients, but some extra to account for growth.

<BR></P>

<P>Dataless clients do not use space on the server for swap and temporary files.

<BR></P>

<P><B>Spare CPU resources</B>&#151;A server needs to have enough CPU cycles to serve its local users and still provide disk and network access services to its clients. But that does not mean to make the fastest system the server. Often you should do just 
the opposite.

<BR></P>

<P>It does not take much CPU power to be a server. File access in UNIX is very efficient, as is network traffic. A system that is heavily loaded will delay the response of disk block requests for its clients. To keep response time up for the clients, leave 

your power users on the faster systems and use a system with sufficient other resources and a light user load for the server, even if this system has a slower-model CPU.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I10" NAME="I10">

<FONT SIZE=3><B>Determining Suitable Clients</B>

<BR></FONT></A></CENTER></H5>

<P>Once the server is determined, choosing suitable clients is a balancing act. You need to mix performance, ease of administration, network traffic, and available resources.

<BR></P>

<P><B>Diskless clients</B>&#151;These are the easiest to determine. If the system does not have a disk, it must have a diskless client. Choose a server for this system that is going to be relatively lightly loaded. Diskless clients make larger demands on 
their servers than do dataless clients.

<BR></P>

<P>Make sure the server for diskless clients is on the same segment of the network as the client. Although NFS requests for disk blocks will cross out of a segment and across a router to a different LAN segment, the boot request will not. It is a local 
broadcast packet. The diskless client needs its bootp server, the system that holds its boot files and responds to its diskless request, to be local to the segment on which it resides. Even if the system that holds its boot files responds to its diskless 
boot request, the segments are not connected by routers today. Follow this rule: when the segments are converted to using routers to reduce backbone traffic, the system will be unbootable without a local bootp server.

<BR></P>

<P><B>Dataless clients</B>&#151;Since a dataless client accesses the utility portions of the UNIX operating system only from its server, it makes relatively small demand on its server. Almost any system that is not critical that it operates if the server 
is down makes a good choice for use as a dataless client.

<BR></P>

<P>If a system will have a large number of disk accesses to user files, such as for a local database, it still can be a dataless client. It can keep on its local disk a file system for those heavily used files, and still access the server for the portions 

of the system that are not on its local disk. This will free more of the space on its local disk for the local file system.

<BR></P>

<P>For those systems that support a newer type of NFS remote mount, called a Cached File System, consider its use for the read-only mounting of the shared portions of the UNIX installation. It provides the remote access desired and can greatly reduce the 
amount of network traffic. It is ideal for these partitions because they are read-only anyway.

<BR></P>

<P>If you have a very reliable server, such as a redundant system, consider placing the UNIX OS server on the backbone with multiple LAN connections on it, servicing each of the local LANs. This can greatly reduce the overhead in maintaining the server and 

keeping it up to the latest release. This is only practical if the server can provide sufficient I/O band width to support all its clients.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I11" NAME="I11">

<FONT SIZE=3><B>Managing Network Traffic</B>

<BR></FONT></A></CENTER></H5>

<P>Before you can decide how to install the new system, you need to check on the amount of traffic on the network. Sources of this traffic include the following:

<BR></P>

<UL>

<LI>Traffic from the systems in Department A to its local server for the following:

<BR>

<BR>Remote file systems, including accessing shared UNIX OS partitions and user files.

<BR>

<BR>Access to client/server applications hosted on the Department A server.

<BR>

<BR>Diskless client access to swap, temporary, and spool partitions.

<BR>

<BR></LI>

<LI>Traffic between the systems in Department A, including the following:

<BR>

<BR>Client/server application traffic.

<BR>

<BR>Remote display updates (a window on one system showing output from a process on a different system).

<BR>

<BR>Sharing of local file systems that are not on the server.

<BR>

<BR></LI>

<LI>Traffic between the systems in Department A and the backbone server, including the following:

<BR>

<BR>Remote file access to company-wide files.

<BR>

<BR>Access to client/server applications running on the backbone, such as a master database.

<BR>

<BR></LI>

<LI>Traffic between the systems in Department A and those in Department B, including the following:

<BR>

<BR>Access to files located locally at Department B.

<BR>

<BR>Access to client/server applications running on the systems in Department B.

<BR>

<BR>Remote file access to local disks on Department B systems.

<BR>

<BR></LI></UL>

<P>The additional traffic generated by the installation of this new system must be compared to the existing traffic on the network. Adding a diskless client on a network segment running at 80% utilization is asking for trouble.

<BR></P>

<P>You don't need sophisticated tools to monitor network traffic. Just take one of the workstations and use the tools provided by your vendor to count the packets it sees on the network. A simple approach is to use a tool such as etherfind or snoop to 
place the EtherNet interface into promiscuous mode, where it listens to all the packets on the network, not just those addressed to itself. Then count the number of packets received by the system over a period of time and their respective length. Most UNIX 

systems can drive an EtherNet segment up to about 800 KB/second in bursts and over 500 KB/second sustained. If the traffic is anything close to this, consider splitting the segment into two segments to reduce the traffic.

<BR></P>

<P>There is a mistake in the silicon of many EtherNet chips, causing them not to be able to reach the numbers described before having excessive collisions. If the netstat -i command is consistently showing a significant number of collisions, say over 1 
percent, even though the traffic levels are well below those numbers, you should consider the segment overloaded. You might have several systems on your network with chips with that problem.

<BR></P>

<P>When splitting the network into segments, if you can place a server and its systems into each of the split segments, often you can use a less expensive bridge to reduce the traffic on each segment rather than using a router.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I12" NAME="I12">

<FONT SIZE=3><B>Summarizing What You Need to Know Before Starting</B>

<BR></FONT></A></CENTER></H4>

<P>In summary, before starting to plan for the actual installation of the new system, you need to determine who is going to use the system. You need to determine how much disk access they will be performing and how much they will contribute to the overall 

network traffic; whether this system is going to be a client or a server; and whether the network can tolerate another system on this segment before the segment has to be split because of overloading.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I13" NAME="I13">

<FONT SIZE=4><B>Planning for the Installation</B>

<BR></FONT></A></CENTER></H3>

<P>You now have to determine on which segment to install this new system, decide what type of user it's for, and decide where to place it. What more do you need to plan for other than where to plug in the power cord and network connection?

<BR></P>

<P>This section guides you through a short pre-installation checklist to make the installation process go smoothly. It will have you answer the following questions:

<BR></P>

<UL>

<LI>From where am I going to install?

<BR>

<BR></LI>

<LI>Is this to be a diskless, dataless, stand-alone, or server system?

<BR>

<BR></LI>

<LI>What is its name?

<BR>

<BR></LI>

<LI>What is its address?

<BR>

<BR></LI>

<LI>Which packages should be installed?

<BR>

<BR></LI>

<LI>How should the disk be partitioned?

<BR>

<BR></LI>

<LI>Should you use a network database?

<BR>

<BR></LI></UL>

<P>These are some of the questions the system will ask as you install UNIX. Most of the rest have obvious answers, such as what time zone are you in.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I14" NAME="I14">

<FONT SIZE=3><B>From Where Am I Going to Install?</B>

<BR></FONT></A></CENTER></H4>

<P>Traditionally one installed a system by placing the medium in a drive and booting from that medium, such as floppy, tape, or CD-ROM. With the advent of networking, things are no longer so simple, but they actually can be a lot more convenient.

<BR></P>

<P>You have two choices for installing: locally and remotely. A local installation is the traditional case, where the media is inserted into some drive attached to the computer being installed, and the software is copied onto the system. A remote 
installation further falls into two types.

<BR></P>

<P>You might use the remote systems's CD-ROM or tape drive to read the media because the system you are installing does not have one. But if there is a large number of systems to install you would access an install server, which already has all of the 
installable files and boot images on its local disks. Since the local disks are faster than CD-ROM or tape, this is faster. It's only worthwhile to set up the install server, however, when you have a lot of systems to install.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I15" NAME="I15">

<FONT SIZE=3><B>Media Distribution Type</B>

<BR></FONT></A></CENTER></H5>

<P>With 300 MB of software to install, floppies are no longer practical. UNIX software vendors have switched from floppies to either a tape or CD-ROM as the install media. Currently, different UNIX vendors use different tape formats, some offering more 
than one. You need to make sure you know which format your vendor is supplying, and that you will have access to a drive capable of reading the data.

<BR></P>

<P>If you have a choice, choose the CD-ROM media. It has several advantages over tape. Although it is slower than tape, it is random access. This makes the install process easier, as it is no longer necessary for the install to proceed in the order of the 

data written on the tape.

<BR></P>

<P>Another advantage is that the media is read-only. It is impossible to overwrite it by mistake or by hardware malfunction. In addition, a CD-ROM is much less expensive to produce and holds more than the tape or floppies it replaces. Usually with a CD-ROM 

there is no need to change media part way through the installation.

<BR></P>

<P>If your computer is unable to boot off the tape or CD-ROM, the vendor also supplies what is called a mini-root on floppy. This is a minimal RAM-based system that is loaded off the floppy and is used to read the tape or CD-ROM. Most workstations have 
boot roms that are capable of booting directly off the tape or CD-ROM. Most PC-based systems do not, and they require boot floppies.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="caution.gif" WIDTH = 37 HEIGHT = 35><B>CAUTION: </B> If you need boot floppies, be sure you order the proper boot floppies for your system. Many vendors of System V Releases 3 and 4 provide different boot floppies for systems that use SCSI-based 

tape drives than for those that use dedicated controllers for the tape drive. Also some provide different floppies for CD-ROM than for tape and for different versions of disk controllers.

<BR></NOTE>

<HR ALIGN=CENTER>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="caution.gif" WIDTH = 37 HEIGHT = 35><B>CAUTION: </B>Read the release notes carefully. Most PC-based UNIX systems support only a limited set of hardware. Be sure your display adapter card, network card, and disk controller are supported. Check to 

see if any special device drivers are required and that you have those drivers for your version of the operating system.

<BR>

<BR>If not, before you start the installation be sure to acquire current drivers for those cards from the manufacturer of the cards or from your UNIX vendor. Be sure the driver is specific to the version of UNIX you will be installing.

<BR>

<BR>If the installation procedure does not ask you to install these drivers, be sure to install them before rebooting from the mini-root used to install the system to the operating system just installed. Otherwise the system will not boot.

<BR></NOTE>

<HR ALIGN=CENTER>

<H5 ALIGN="CENTER">

<CENTER><A ID="I16" NAME="I16">

<FONT SIZE=3><B>Using a Local Device or a Remote Device for Installation</B>

<BR></FONT></A></CENTER></H5>