cfsd(8)

Index for
Section 8

Alphabetical
listing for C

Bottom of
page

cfsd(8)
NAME
cfsd - The CFS load monitoring daemon

SYNOPSIS
/usr/sbin/cfsd

DESCRIPTION
The CFS load monitoring daemon can monitor, report, and respond to file
system-related node and cluster activity. You can use cfsd to better
understand and manage the cluster's file systems. The cfsd daemon can
perform the following functions:

· Collect a variety of statistics on file system usage and system load.
You can use this data to understand how the cluster's file systems are
being used.

· Analyze the statistics that it collects and recommend file system
relocations that may improve system performance or balance the file
system load across the cluster.

· Monitor memory usage on cluster nodes and generate an alert when a
member is approaching the CFS memory usage limit.

· Assist in managing file systems by locating file systems based on your
preferences and storage connectivity. You can configure cfsd to
automatically relocate file systems when members join or leave the
cluster, when storage connectivity changes, or as a result of CFS
memory usage.

An instance of the cfsd daemon runs on each member of the cluster. If cfsd
runs in the cluster it must run on each member; cfsd depends on a daemon
running on each member for proper behavior. If you do not want cfsd to be
running in the cluster, no member should run it.

Each instance of the daemon collects statistics on its member and monitors
member-specific events such as low memory. One daemon from the cluster
automatically serves as the "leader" daemon and is responsible for
analyzing all of the collected statistics, making recommendations, and
initiating automatic relocations. The daemons are configured via a
clusterwide /etc/cfsd.conf configuration file.

cfsd monitors file system performance and resource utilization by
periodically polling the member for information, as deteremined by the
polling_schedule attributes of the /etc/cfsd.conf configuration file for a
given policy.

Based on the contents of the /etc/cfsd.conf configuration file, cfsd
collects information on each member's usage of each file system, on the
memory demands of each file system, on the system memory demand on each
member, and on member-to-physical storage connectivity. cfsd also
subscribes to EVM events to monitor information on general cluster and
cluster file system state, such as cluster membership, mounted file
systems, and device connectivity.

Gathering cfsd Statistics

When configured to gather statistics in /etc/cfsd.conf, each cfsd daemon
accumulates the statistics in the member-specific binary file
/var/cluster/cfs/stats.member. The data in this file is in a format
specific to cfsd and is not intended for direct user access. cfsd updates
and maintains these files; you do not need to periodically delete or
maintain them.

The following data is collected for each cluster member:

· svrcfstok structure count limit. (See the Cluster Administration guide
for information.)

· Number of active svrcfstok structures

· Total number of bytes

· Number of wired bytes

The following data is collected per file system per member:

· Number of read operations

· Number of write operations

· Number of lookup operations

· Number of getattr operations

· Number of readlink operations

· Number of access operations

· Number of other operations

· Bytes read

· Bytes written

· Number of active svrcfstok structures

Analyzing cfsd Statistics

After analyzing these collected statistics, cfsd places the results in the
/var/cluster/cfs/analysis.log file. /var/cluster/cfs/analysis.log is
actually a symbolic link to the most recent
/var/cluster/cfs/analysis.log.dated file. When a
/var/cluster/cfs/analysis.log.dated file becomes 24 hours old, a new
version is created and the symlink is updated. Prior versions of the
/var/cluster/cfs/analysis.log.dated file are purged. The cfsd daemon
posts an EVM event to alert you that the latest analysis contains
interesting results.

/var/cluster/cfs/analysis.log contains plain text, in a format similar to
the following:

Cluster File System (CFS) Analysis Report
(generated by cfsd[525485]
at Friday Nov 30 19:02:30 2001)

Recommended
relocations:

none

Filesystem usage summary:
cluster reads writes req'd svr mem
24 KB/s 0 KB/s 4190 KB

node reads writes req'd svr mem

rye 4 KB/s 0 KB/s 14 KB
swiss 19 KB/s 0 KB/s 4176 KB

filesystem
node reads writes req'd svr mem

test_one# 2 KB/s 0 KB/s 622 KB
rye 0 KB/s 0 KB/s
@swiss 2 KB/s 0 KB/s

test_two# 4 KB/s 0 KB/s 2424 KB
rye 1 KB/s 0 KB/s
@swiss 3 KB/s 0 KB/s
:
:
Filesystem placement evaluation results:

filesystem
node conclusion observations
test_one#
rye considered (hi conn, hi pref, lo use)
@swiss recommended (hi conn, hi pref, hi use)
test_two#
rye considered (hi conn, hi pref, lo use)
@swiss recommended (hi conn, hi pref, hi use)
:
:

The Recommended relocations section of the /var/cluster/cfs/analysis.log
file contains any recommended relocations, or indicates that no
recommendations were made. In the example, no relocations are recommended.

The Filesystem usage summary section summarizes cluster file system usage
with average byte read and write rates and approximate CFS server memory
requirements. The summary data is listed in finer granularity: first for
the entire cluster, then for each member, and finally on a per-file system
and a per-file system, per-member basis. The current CFS server of each
file system is indicated by an "at" symbol (@).

The Filesystem placement evaluation results section summarizes the file
system placement evaluation results. For each file system,
/var/cluster/cfs/analysis.log lists each member, its observations about the
file system-member pair, and the conclusion it reached regarding the member
acting as the server for the file system. The current CFS server of each
file system is indicated by an "at" symbol (@).

Possible conclusions (one per file system-member pair):

recommended
The cfsd daemon recommends that the member be the server for the
file system. The current server of a file system is recommended if
the file system cannot be relocated.

considered
The cfsd daemon considered the member as a potential server based
on administrator preference and device connectivity. A member may
have been considered but not recommended based on its usage of the
file system, its inability to meet the file system's memory
demands, or in an effort to balance the file system load across the
cluster nodes.

not considered
The cfsd daemon did not consider the member as a potential server
for the file system. This can be due to a variety of factors: the
member is not a preferred server, the member has limited device
connectivity, or the file system cannot be relocated.

Possible observations (one or more per file system-member pair):

no relo The file system cannot be relocated. This may be because relocation
is not supported for the file system type, the file system is a
member's boot partition, the file system is server-only
(partitioned), or the file system is managed by the hierarchical
storage manager (HSM), as described in dmapi(3).

bootpart
Indicates that the file system is a member's boot partition and
cannot be relocated.

dmapi The file system is mananged by the hierarchical storage manager
(HSM), as described in dmapi(3).

no conn, lo conn, hi conn
How well a member is connected to the file system's devices
relative to the other members in the cluster. Only members that
have high connectivity ratings are considered potential servers for
a file system.

no pref, lo pref, hi pref
A member's preference rating as a server for the file system
relative to the other members in the cluster. Only members that
have high preference ratings are considered potential servers for a
file system.

lo use, hi use
A member's use of a file system relative to the other members in
the cluster. Only members that have high use ratings are considered
potential servers for a file system. A member might not have a use
rating if it has a low connectivity and or a low preference rating.

no mem A member was qualified to serve a file system based on its use of
the file system, its preference as a server, and its device
connectivity, but that svrcfstok limit constraints prevented it
from being recommended as the server for the file system.

The cfsd daemon posts an EVM sys.unix.clu.cfsd.anlys.relocsuggested event
to alert you that the latest analysis contains interesting results. You
can use the results of this analyses to determine whether a different
cluster member should be the CFS server for a given file system. If the
current CFS server is not the recommended server for this file system based
on the cfsd analyses, you can use the cfsmgr command to relocate the file
system to the recommended server.

cfsd logs info to the syslog daemon log,
/var/adm/syslog.dated/current/daemon.log. You can check this file for cfsd
configuration file errors:

# cat /var/adm/syslog.dated/current/daemon.log | grep cfsd
Dec 12 17:13:16 rye cfsd[1065058]: performing filesystem analysis...
Dec 12 17:13:16 rye cfsd[1065058]: filesystem analysis complete
Dec 12 17:13:16 rye cfsd[1065058]: logging analysis results to "/var/cluster/cfs/analysis.log"

Notes

The cdfs daemon considers an AdvFS domain to be an indivisible entity.
Relocating a file system of type AdvFS affects not only the selected
fileset, but all filesets in the same domain. The entire domain is
relocated.

File systems of type NFS client and Memory File System (MFS) cannot be
relocated. In addition, member boot partitions, server-only file
systems (such as UFS file systems mounted for read-write access), and
file systems that are under hierarchical storage manager (HSM)
management cannot be relocated.

Direct-access I/O devices on a shared bus are served by all cluster
members on that bus. A single-server device, whether on a shared bus
or directly connected to a cluster member, is served by a single
member. If two or more file systems use the same single-server
device, cfsd does not relocate them due to performance issues that
would arise if the file systems were not served by the same node.

Starting and Stopping cfsd

The /sbin/init.d/cfsd file starts an instance of the cfsd daemon on each
cluster member. However, starting the daemon does not by itself make cfsd
active: the cfsd daemon's behavior is controlled via the active field of
the stanza-formatted file /etc/cfsd.conf. The active field enables cfsd if
set to 1.

cfsd is disabled by default (set to 0) and you must explicitly enable it to
use it.

cfsd reads the clusterwide /etc/cfsd.conf file at startup. You can force
cfsd to reread the configuration file by sending it a SIGHUP signal, in a
manner similar to the following:

# kill -HUP `cat /var/run/cfsd.pid`

If you modify /etc/cfsd.conf, send any cfsd the SIGHUP signal to force it
to reread the file. When you send SIGHUP to any cfsd daemon process in the
cluster, all cfsd daemons in the cluster reread the the file; there is no
need to issue multiple SIGHUP signals.

EVM EVENTS
cfsd posts an EVM sys.unix.clu.cfsd.anlys.relocsuggested event to alert you
that the latest analysis contains interesting results. You can use the
evmwatch and evmshow commands to monitor these events.

# evmget | evmshow -t "@name [@priority]" | grep cfsd
sys.unix.clu.cfsd.anlys.relocsuggested [200]

The following command provides additional information on cfsd EVM events.

# evmwatch -i -f "[name sys.unix.clu.cfsd.*]" | evmshow -d | more

EXIT STATUS
0 Success.

1 An error occurred. cfsd did not start.

EXAMPLES
1. You can force cfsd to reread the configuration file by sending it a
SIGHUP signal, in a manner similar to the following:
# ps agx | grep cfsd
1049924 ?? I 0:02.68 /usr/sbin/cfsd
1146714 pts/5 S + 0:00.01 grep cfsd

# kill -HUP `cat /var/run/cfsd.pid`

2. Assume that member swiss is the current CFS server of the test_two
domain and cfsd recommends that member rye be the CFS server:
test_two#
rye recommended (hi conn, hi pref, hi use)
@swiss considered (hi conn, hi pref, lo use)

If you agree with this analyses and want to implement the
recommendation, enter the following cfsmgr command to change the CFS
server to rye:
# cfsmgr -a server=rye -d test_two
# cfsmgr -d test_two
Domain or filesystem name = test_two
Server Name = rye
Server Status : OK

FILES
/etc/cfsd.conf
Clusterwide configuration file read by cfsd.

/var/cluster/cfs/stats.member
Member-specific binary data file.

/var/cluster/cfs/analysis.log
Clusterwide data analysis log file.

cfsd(8)

NAME

SYNOPSIS

DESCRIPTION

EVM EVENTS

EXIT STATUS

EXAMPLES

FILES

SEE ALSO