Stockage partagé avec SSHFS

Presentation

SSHFS utilise FUSE ("Filesystem in Userspace") pour créer un système de fichiers qui peut être partagé en transmettant les données via SSH.

Le client SSHFS - basé sur FUSE dans l'espace utilisateur - monte et interagit avec un système de fichiers distant comme s'il était local (i.e., stockage partagé). Il utilise sftp comme protocole de transfert, et dispose donc du même niveau de sécurité que SFTP. SSHFS est particulièrement commode lorsqu'on dispose d'un accès SSH au système distant, avec les permissions adéquates sur l'arborescence cible.

De plus il ne nécessite pas d'outils particuliers côté client comme serveur, et le port SSH est généralement ouvert sur les pare-feu, donc pas de configuration complémentaire nécessaire non plus de ce point de vue. Ceci ne nécéssite pas l'intervention d'un administrateur.

Installation

SSHFS n'est pas inclus dans les distributions typiques, donc avant de commencer:

• vérifier que le kernel dispose du module FUSE:

 $ lsmod |grep fuse
 fuse                   91880  3 

• installer le paquet sshfs sur la machine cliente qui veut monter un FS distant, par exemple pour Centos/rhel7, et vérifier que la commande répond:

 $ sudo yum install fuse-sshfs
 Installé :
   fuse-sshfs.x86_64 0:2.10-1.el7                                                                                        

 $ sshfs -V
 SSHFS version 2.10
 FUSE library version: 2.9.2
 fusermount version: 2.9.2
 using FUSE kernel interface version 7.19

Utilisation

Pour monter une arborescence distante via sshfs, la commande est du type:

 $ sshfs login@hostname:[rep-distant] [mnt-local]

avec:

• login@hostname : accès SSH distant
• [rep-distant]  : répertoire distant (relatif au home du login ou absolu)
• [mnt-local]  : répertoire local utilisé comme point de montage.

Exemple:

 $ sshfs autremoi@192.168.1.4:/share/DATA /home/moi/datadist

A ce stade, le répertoire local /home/moi/datadist montre l'arborescence distante sous /share/DATA. On peut copier dans les deux sens.

• les écritures vers le distant appartiendront au compte utilisé pour l'accès SSH.
• les fichiers sont vus avec les UID/GUI du distant. Faire donc attention au mapping des UID entre système local et distant. Si les permissions ne sont pas équivalentes sur les deux systèmes, il peut être nécessaire d'effectuer un mapping via les options -o idmap,uidfile,gidfile (voir man sshfs), pour que le système local montre les UID/GID qu'on souhaite. Exemple:

 $ sshfs -C -o allow_other,default_permissions -o nomap=ignore -o idmap=file -o uidfile=map_sshfs_id -o gidfile=map_sshfs_id test1@192.168.40.229:/home/share /tmp/test1
 $ cat map_sshfs_id
 user1:1002

Ici, on monte le répertoire /home/share du distant, avec le mapping de l'UID distant 1002 vers le compte local 'user1'. De plus, avec l'option allow_other,default_permissions, ce montage est accessible aux autres utilisateurs, et les permissions sont vérifiées par le kernel. (par défaut, sans l'option 'default_permissions', ce n'est pas le cas).

Optimisation des performances

Les performances semblent pouvoir être optimisées avec:

• des options sshfs:

   -o cache=yes
   -o kernel_cache
   -o compression=no
   -o large_read
   -o Ciphers=arcfour  (à éviter toutefois, cet algo n'est plus recommandé).

• des options TCP MTU et sysctl

   MTU 
       9000 côté “serveur”
       max possible côté “client” (voir tracepath -n pour vérifier le MTU vers le serveur ). Linux: outils de debug réseau, test connexion, SSL...

   sysctl:
       net.ipv4.tcp_rmem = 4096 87380 8388608
       net.ipv4.tcp_wmem = 4096 87380 8388608
       net.core.rmem.max = 8388608
       net.core.wmem.max = 8388608
       net.core.netdev.max_backlog = 5000
       net.ipv4.tcp_window_scaling = 1

Voir cet article http://www.admin-magazine.com/HPC/Articles/Sharing-Data-with-SSHFS pour d'avantage de détails.