 |  |
Chapter 8. Diskless Clients
Contents:
NFS support for diskless clientsSetting up a diskless client
Diskless client boot process
Managing client swap space
Changing a client's name
Troubleshooting
Configuration options
Brief introduction to JumpStart administration
Client/server ratios
There are many motivations for using diskless clients:
-
They are quieter than machines with disks.
-
They are easier to administer, since there
is no local copy of the operating
system that requires updates.
-
When using fast network media, like 100Mb ethernet, diskless clients
can perform faster if the server is storing the client's data
in a disk array. The reason is that client workstations typically
have one or two disk spindles, whereas if the client data can be
striped across many, usually faster spindles, on the server, the
server can provide better response.
Solstice AdminSuite 2.3 software is no longer supported with the Solaris 8 operating environment. Any attempt to run Solstice AdminSuite 2.3 to configure Solstice AutoClients or diskless clients will result in a failure for which no patch is available or planned. While it may be possible to manually edit configuration files to enable diskless clients, such an operation is not recommended or supported.
Setting up a diskless client from scratch without tools is very impractical. Fortunately, Solaris 8, 1/01 Update has been released, which replaces the unbundled AdminSuite with bundled tools for administering diskless support on the Solaris 8, 1/01 Update servers. Unfortunately, Solaris 8, 1/01 Update was not available in time to write about its new diskless tools in this book. Thus, the discussion in the remainder of this chapter focuses on diskless support in Solaris through and including Solaris 7.
8.1. NFS support for diskless clients
Prior to SunOS 4.0, diskless clients were supported through a separate distributed filesystem protocol called Network Disk, or ND. A single raw disk partition was divided into several logical partitions, each of which had a root or swap filesystem on it. Once an ND partition was created, changing a client's partition size entailed rebuilding the diskless client's partition from backup or distribution tapes. ND also used a smaller buffer size than NFS, employing 1024-byte buffers for filesystem read and write operations.In SunOS 4.0 and Solaris, diskless clients are supported entirely through NFS. Two features in the operating system and NFS protocols allowed ND to be replaced: swapping to a file and mounting an NFS filesystem as the root directory. The page-oriented virtual memory management system in SunOS 4.0 and Solaris treats the swap device like an array of pages, so that files can be used as swap space. Instead of copying memory pages to blocks of a raw partition, the VM system copies them to blocks allocated for the swap file. Swap space added in the filesystem is addressed through a vnode, so it can either be a local Unix filesystem (UFS) file or an NFS-mounted file. Diskless clients now swap directly to a file on their boot servers, accessed via NFS.
The second change supporting diskless clients is the VFS_MOUNTROOT( ) VFS operation. On the client, it makes the named filesystem the root device of the machine. Once the root filesystem exists, other filesystems can be mounted on any of its vnodes, so an NFS-mounted root partition is a necessary bootstrap for any filesystem mount operations on a diskless client. With the root filesystem NFS-mounted, there was no longer a need for a separate protocol to map root and swap filesystem logical disk blocks into server filesystem blocks, so the ND protocol was removed from SunOS.
|  | |
| 7.6. NFS futures |  | 8.2. Setting up a diskless client |
