• Choose a category
• All
• Classic-Fiction

Now, without client-side failover, each NFS client might have one of the following vfstab entries:

hamilton:/export/budget_stats - /stats/budget nfs - yes ro

wolcott:/export/budget_stats - /stats/budget nfs - yes ro

dexter:/export/budget_stats - /stats/budget nfs - yes ro

Suppose an NFS client is mounting /stats/budgetfrom NFS server hamilton, and hamilton stops responding. The user on that client will want to mount a different server. In order to do this, he'll have to do all of the following:

Terminate any applications that are currently accessing files under the /budget_stats mount point.

Unmount /stats/budget.

Edit the vfstab file to point at a different server.

Mount /stats/budget.

The user might have a problem with the first step, especially if the application has buffered some unsaved critical information. And the other three steps are tedious.

With client side failover, each NFS client can have a single entry in the vfstab file such as:

hamilton,wolcott,dexter:/export/budget_stat - /budget_stats nfs - yes ro

This vfstab entry defines a replicated NFS filesystem. When this vfstab entry is mounted, the NFS client will:

Contact each server to verify that each is responding and exporting /export/budget_stats.

Generate a list of the NFS servers that are responding and exporting /export/budget_stats and associate that list with the mount point.

Pick one of the servers to get NFS service from. In other words, the NFS traffic for the mount point is bound to one server at a time.

As long as the server selected to provide NFS service is responding, the NFS mount operates as a normal non-client-side failover mount. Assuming the NFS client selected server hamilton, if hamiltonstops responding, the NFS client will automatically select the next server, in this case wolcott, without requiring that one manually unmount hamilton, and mount wolcott. And if wolcott later stops responding, the NFS client would then select dexter. As you might expect, if later on dexter stops responding, the NFS client will bind the NFS traffic back to hamilton. Thus, client-side failover uses a round-robin scheme.

You can tell which server a replicated mount is using via the nfsstat command:

% nfsstat -m

...

/budget_stats from hamilton,wolcott,dexter:/export/budget_stats

Flags:

vers=3,proto=tcp,sec=sys,hard,intr,llock,link,symlink,acl,rsize=32768,wsize=32768,

retrans=5

Failover:noresponse=1, failover=1, remap=1, currserver=wolcott

The currserver value tells us that NFS traffic for the /budget_stats mount point is bound to server wolcott. Apparently hamilton stopped responding at one point, because we see non-zero values for the counters noresponse, failover and remap. The counter noresponse counts the number of times a remote procedure call to the currently bound NFS server timed out. The counter failovercounts the number of times the NFS client has "failed over" or switched to another NFS server due to a timed out remote procedure call. The counter remap counts the number of files that were "mapped" to another NFS server after a failover. For example, if an application on the NFS client had /budget_stats/1994/deficit open, and then the client failed over to another server, the next time the application went to read data from /budget_stats/1944/deficit, the open file reference would be re-mapped to the corresponding 1944/deficit file on the newly bound NFS server.

Solaris will also notify you when a failover happens. Expect a message like:

NOTICE: NFS: failing over from hamilton to wolcott

on both the NFS client's system console and in its /var/adm/messages file.

By the way, it is not required that each server have the same pathname mounted. The mount command will let you mount replica servers with different directories. For example:

# mount -o ro serverX:/q,serverY:/m /mnt

As long as the contents of serverX:/q and serverY:/m are the same, the top level directory name does not have to be. The next section discusses rules for content of replicas.

Properties of replicas

Replicas