CIFS and NFS Outage Testing

CIFS setup

  1. (Server): Install samba package:

    # apt-get install samba
    
  2. (Server): Setup shares in /etc/samba/smb.conf:

    [testing$]
    comment = Testing
    path = /srv/shared
    read only = no
    browseable = yes
    create mask = 0600
    directory mask = 0700
    

  3. (Server): Create samba user (no password for testing, do not use in production):

    # smbpasswd -a root
    
  4. (Server): Restart samba service

    # service smbd restart
    
  5. (Client): Install samba related packages:

    # apt-get install cifs-utils smbclient
    
  6. (Client): Mount remote filesystem

    # mount -t cifs //10.10.10.100/testing$ /mnt
    

Assuming that server’s ip address is 10.10.10.100. After that the shared directory is mounted on /mnt/.

NFS setup

  1. (Server): Install necessary pacakges:

    # apt-get install nfs-kernel-server nfs-common
    
  2. (Server): Setup exports in /etc/exports:

    /srv/shared    10.10.10.0/24(rw,no_root_squash)
    
    This exports directory /srv/shared/ (must exists) to hosts in 10.10.10.0/24 network.

  3. (Server): Restart nfs service:

    # service nfs-kernel-server restart   
    
  4. (Client): Install client package:

    # apt-get install nfs-common
    
  5. (Client): Mount exported directory:

    # mount 192.168.0.100:/srv/shared /mnt/
    

    Assuming that server’s ip address is 10.10.10.100. After that the shared directory is mounted on /mnt/.

Testing

Methodology

Both servers contains 5GB file containing random data created via:

    # dd if=/dev/urandom of=/srv/test.img bs=10M count=500

Check the MD5 sum of the file and save it into /tmp/test-checksum.md5:

    # md5sum /srv/test.img > /tmp/test-checksum.md5

Mount both storages on client and copy the file from storage and back into it. Check whether checksums are still equal to original one. For copying use preferably dd tool, due to it’s lowlevel “dumb” nature:

    # dd if=/mnt/test.img of=/srv/test.img bs=16M

NOTE: dd status could be easily checked via issuing kill -USR1 `pgrep ^dd$` from another terminal, causing the original terminal printing a status message. In combination with watch it’s simple “progress bar”

Repeat the previous step with simulation of interruption on server side. Following interruption were tested: - pausing VM - rebooting server - blocking ingoing network traffic via iptables for 20 and 300s - blocking ingoing network traffic via iptables for 20 and 300s - blocking all network traffic via iptables for 20 and 300s

Used iptables rules (block all):

time=20
clientaddress= 10.10.10.43
iptables -I INPUT -s ${clientaddress} -j DROP 
iptables -I OUTPUT -d ${clientaddress} -j DROP
sleep ${time}
iptables -D INPUT -s ${clientaddress} -j DROP 
iptables -D OUTPUT -d ${clientaddress} -j DROP

Result

Both filesystems are resilient against short-term disconnection (without remount). On the other hand, processes using the storages are stuck and they are unable to interrupt or end. The handling of disconnection and timeout setup is done only on client side or rather the process consuming the storage resources.

Last modified: 2017-05-25