When dealing with high-availability NFS setups where multiple servers provide access to the same SAN-backed storage, client-side failover becomes crucial. While Linux doesn't natively support active-active NFS failover at the protocol level, we can implement robust solutions using mount options and proper configuration.

The most effective approach combines several NFS mount options:

server1:/export /mnt/nfs nfs 
    rw,
    soft,
    timeo=100,
    retrans=3,
    retry=0,
    noacl,
    nolock,
    bg,
    mountproto=tcp,
    intr,
    _netdev

For true failover capability, use multiple NFS servers in your fstab:

server1:/export /mnt/nfs nfs 
    rw,soft,bg,noatime,nolock,intr,_netdev 0 0
server2:/export /mnt/nfs nfs 
    rw,soft,bg,noatime,nolock,intr,_netdev 0 0

A more sophisticated solution involves autofs configuration:

# /etc/auto.master
/mnt /etc/auto.nfs --timeout=60

# /etc/auto.nfs
nfs -fstype=nfs,soft,bg,intr,retry=0 \
    server1:/export \
    server2:/export

Verify your setup with these commands:

# Check current mounts
mount | grep nfs

# Force umount to test failover
umount -l /mnt/nfs

# Monitor NFS operations
nfsstat -c

For enterprise environments, consider these additional measures:

• Implement keepalived for VIP failover
• Use DRBD for synchronous replication between NFS servers
• Configure proper NFS version (v4.1+ preferred for better recovery)
• Set up monitoring with Nagios or Zabbix

Watch for these potential problems:

# Check NFS server availability
rpcinfo -p server1

# Examine kernel messages
dmesg | grep nfs

# Verify network connectivity
tcpdump -i eth0 port nfs

When working with critical NFS-mounted storage in Linux environments, achieving seamless failover between redundant NFS servers remains a common pain point. While clustered NFS server setups are well-documented, client-side failover configuration requires careful handling.

Contrary to what you might find in some search results, Linux does support NFS failover through several approaches:

• Using the mount command's nfs options
• Leveraging autofs with failover configurations
• Implementing custom scripts with monitoring

For CentOS 6.3, the most straightforward approach uses the nfs filesystem type's built-in capabilities:

# /etc/fstab entry:
server1:/export /mnt/data nfs timeo=50,retrans=5,retry=0,noatime,nodiratime,soft,intr,bg,rsize=32768,wsize=32768 0 0
server2:/export /mnt/data nfs timeo=50,retrans=5,retry=0,noatime,nodiratime,soft,intr,bg,rsize=32768,wsize=32768 0 0

Key parameters:

• bg: Mount in background if server is unreachable
• soft: Return error after retrans attempts
• retry=X: Number of minutes to retry failed mounts

For more sophisticated failover handling, autofs provides better control:

# /etc/auto.master:
/mnt /etc/auto.nfs --timeout=60

# /etc/auto.nfs:
data -fstype=nfs,soft,intr,bg,rsize=32768,wsize=32768 server1:/export server2:/export

For environments requiring active monitoring, implement a watchdog script:

#!/bin/bash
NFS_MOUNT="/mnt/data"
PRIMARY_SERVER="server1:/export"
BACKUP_SERVER="server2:/export"

if ! mountpoint -q "$NFS_MOUNT"; then
    echo "Attempting to mount $PRIMARY_SERVER..."
    mount -t nfs -o soft,intr,bg "$PRIMARY_SERVER" "$NFS_MOUNT"
    
    if [ $? -ne 0 ]; then
        echo "Primary server failed, trying backup..."
        mount -t nfs -o soft,intr,bg "$BACKUP_SERVER" "$NFS_MOUNT"
    fi
fi

When implementing NFS failover, consider these performance implications:

• Cache coherency between failovers
• Timeout values balancing responsiveness vs. false positives
• Client-side caching configuration

Common issues and solutions:

• Use rpcinfo -p server to verify NFS service availability
• Check /var/log/messages for mount-related errors
• Test failover scenarios with umount -f -l /mnt/data