8.7. Configuration optionsAdding disks to local clients opens two configuration options. You can use the local disk for swap space, or you can build an entire bootable system on it and put the root and swap filesystems on the local disk. This latter configuration is called a dataless client, and makes sense if the client does not need most of the local disk for a very large swap space. If the client has a large swap partition and uses it frequently, adding a local disk may improve performance by reducing the client's traffic to its boot server. In other instances, the local disk provides private storage for sensitive files. Dataless clients contain no user or data files on their local disks. Everything on the local disk can be reconstructed from operating system release tapes or from system installation scripts. The local disks are used for the root and swap filesystems, while /usr and all other filesystems are NFS-mounted. The dataless architecture provides some performance advantages from both the client and server perspective, particularly when the client has a large swap space. A significant portion -- usually more than 50% and sometimes 90% -- of a diskless client's network traffic is caused by reading and writing the root and swap filesystems. Clients with local disks place less of a load on the network and on the boot server by sending their swap traffic to this disk.
8.7.1. Dataless clientsYou may choose to use the dataless client configuration if you have to support a few machines of a new client architecture and would have to carve the disk space out of the server's /export partition. Adding a local disk keeps the server configuration simple and puts all files specific to the new client architecture on the local disks. The best network architecture for dataless clients is one in which desktop machines run application sets with large, randomly accessed virtual address spaces. If the machine has a reasonably high level of paging activity, depending on the speed of the network and capacity of the NFS servers, using a local disk improves performance. Dataless clients may appear to be more expensive per seat than diskless clients, since the diskless machines get root and swap space at "bulk" prices from the server. On the other hand, in a pure diskless client environment, you must purchase additional disk space to hold the clients' root and swap filesystems. If you allocate some portion of the server's cost as the cost of replacing local disks, the dataless and diskless architectures have much less of a price differential. Be careful when analyzing client/server cost projections. You'll get the fairest numbers when you compare the total cost of the desktop workstation, any local disk, and the desktop's share of the cost of servers providing root, swap, and user filesystems. When you do add local disks, it's important to choose your disk size carefully. If larger local disks are attached to dataless clients, they become inviting homes for user files that may not be backed up regularly. If you plan to configure dataless clients, use the smallest disk possible to contain the root and swap filesystems, with enough room on the local disk's root partition to contain a very large /var directory. Applications that use enough virtual memory to justify a local disk probably create huge temporary files on /var/tmp as well. Management of dataless nodes is slightly more complex than that of diskless nodes. Even though the local disks contain no user files or tools, they may still have host-specific configuration information in the /etc directory, such as software password files. Use care when modifying the private parts of a dataless node so that the entire node can be recreated from a boot tape or archive tape if the local disk must be replaced. You will probably want to create a script that creates spool directories, copies printer configuration files, and creates NFS mount points on the client; you can use this script on dataless or new diskless clients as well. If possible, mount the dataless client spool directories from an NFS server so that the dataless client's disk contains no host-specific information. Ideally, you should not have to do backups of a dataless client. After Solaris 2.5.1, the AdminSuite product stopped supporting the dataless configuration option. This is a bit of an inconvenience to you, but it is surmountable. Consider that a dataless client is like a disk-full client except that /usr is mounted from an NFS server instead of from a local disk. The steps for doing this are:
For a package that contains both root and /usr files, you could invoke the Solaris pkgadd command to install the package in a temporary place, and then copy the non-usr files to the dataless client's root:client # patchadd -R / -M . 107460-03
client # mkdir /tmp/scratch client # pkgadd -d . -R /tmp/scratch SUNWxxxx client # cd /tmp/scratch client # rm -rf usr client # find . -print | cpio -dump /
8.7.2. Swapping on a local diskIn this configuration option, the client's root and /usr filesystems are NFS-mounted, but swap is from a local disk. The AdminSuite software doesn't provide an option for diskless client accessing local swap, but again it is surmountable. The steps are:
honeymoon# swap -a /dev/dsk/c0t0d0s7 honeymoon# swap -d /dev/swap
Copyright © 2002 O'Reilly & Associates. All rights reserved.