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
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
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 clients
You 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:
-
Install the operating system on a disk-full client. If possible
(depending on how many disks you have and how big they are), install
all the software without specify a /usr
partition. If you have to, specify a separate
/var partition if that is what it takes to
prevent a /usr partition from being created.
It's OK to have the /usr partition
created, but once you mount /usr from the NFS
server, the question then is what do you do with the redundant local
disk space? You can always mount it as another partition, say
/spare, and have it around for future additional
needs such as more swap, or more
/var space.
-
Edit /etc/vfstab on the client to mount
/usr from an NFS server that has been set up for
diskless client support. If there was an entry for
/usr in /etc/vfstab,
comment it out. For example you might comment out /usr
's vfstab:
# /dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /usr ufs 1 no -
and add:
wahoo:/export/exec/Solaris_2.7_sparc.all/usr - /usr nfs - - ro
-
Edit /etc/hosts and add the IP address of the
NFS server. Both dataless and diskless clients require this, because
while the system is booting, without /usr
available, the software needed to access NIS or DNS won't be
around, so /etc/hosts is needed to resolve the
name of the NFS server to an IP address:
130.141.14.2 wahoo
-
Test this by rebooting the client. If you run into any problems, you
can always shut the system down, and boot the system as single user.
There is a drawback to this scheme. Applying some patches and
packages will be less straightforward, because patches and packages
can contain both
/usr and
root files, but the dataless client's
/usr partition won't be writable by the
utilities used to add patches and packages. The workaround for this
is very dependent on the patch and packaging scheme used by the
operating system. In case of Solaris,
the
patchadd utility has a
-R
pathname option, which is normally used to apply
patches to a diskless client's root partitions. In that case,
patchadd is run on the NFS server. In the case
of a dataless client, you would invoke
patchadd
as:
client # patchadd -R / -M . 107460-03
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 # 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 disk
In 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:
-
If not already done, add the diskless client to the boot server via
the AdminSuite software. Go ahead and define a swap partition on the
server so that you don't run the risk of confusing the
AdminSuite software.
-
Boot the client from the boot server.
-
Identify and create the swap partition from the local disk. In
Solaris, the easiest way to this is via the
format command. When you invoke the
format command, it will display the list of
disks attached to the client. You then select one of the local disks
and then use the "partition" command from inside
format to find an existing partition and resize
it, or create a partition with the desired size.
-
Edit /etc/vfstab on the client to mount
swap from the partition you identified in the
previous step. For example you might change the two NFS-related
swap vfstab entries from:
wahoo:/export/swap/honeymoon - /dev/swap nfs - - -
/dev/swap - - swap - - -
to:
/dev/dsk/c0t0d0s7 - - swap - no -
-
Reboot the client via diskless boot.
In general, the swap partition should cover most, if not all, of the
local disk.
Of course, if you followed the example in
Section 8.4, "Managing client swap space", then you know you ought to be able to
switch from NFS swap to local swap without a client reboot. This is
only possible if the local swap partition is at least as big as the
NFS-mounted swap file. Instead of rebooting the client in step 5,
you
would
do:
honeymoon# swap -a /dev/dsk/c0t0d0s7
honeymoon# swap -d /dev/swap
