/docs/MyDocs

Ganesha-NFS

===========

 - Ganesha is user-space implementation of NFS. Working trough the user-space

 GlusterFS library, it reduces user/kernel context switches. Unlike Gluster native

 NFS support which is limited to NFS3, Ganesha supports NFS4.1 and pNFS. 

 - It also supports RDMA transport using mooshika (SoftiWARP can be used to run it

 over Ethernet network, but is not need for native Infiniband cards). However, support

 is still very unstable. I need few patches to be able to mount the NFS partition. However,

 it fails during the data transfer. To me it is unclear if the problem the Ganesha or 

 actual RDMA support in native Linux RDMA client. However, Ganesha defenitively crashes from

 time to time.

 - To enable Ganesha, the kernel NFS and nfs support in all volumes should be turned off. 

        gluster volume set pdv nfs.disable on

 - Gluster does not any other changes. The Ganesha should configure Gluster volumes individually,

 no configuration required for RDMA. It is enabled by default:

    * It is possible to export subdirectories, just give a full path.

    * Unlike standard NFS, it is possible to export both directory and its subdirectories as separate shares

        Export_Id = 1; Path = "/pdv"; Pseudo = "/pdv";

        Access_Type = RW; Squash = No_Root_Squash; SecType = "sys";

        FSAL { Name = "GLUSTER"; Hostname = localhost; Volume = "pdv"; }

 - Mounting

        192.168.26.170:/pdv /pdv nfs4 defaults,minorversion=1,_netdev,nofail,soft,nodiratime,noatime,noauto 0 0

        192.168.26.170:/pdv /pdv nfs defaults,_netdev,nofail,soft,nodiratime,noatime,nofail,soft 0 0

        192.168.26.170:/pdv /pdv nfs _netdev,nofail,vers=4,proto=rdma,port=20049,nofail,soft,nodiratime,noatime 0 0

 - Setting access rights (in EXPORT {} block)

    * No global option and %include is not working in EXPORT block

    * First more specific with more rights.

        Access_type = none;

        CLIENT {

            clients = 141.52.64.104;

            Access_type = RO;

        } CLIENT {

            clients = 141.52.64.0/23;

            Access_type = RO;

        }

        

 - Version ganesha-2.2.0/ntirpc-0.1.1 performs well in synthetic benchmarks, but very

 slow for real data movements. ganesha-2.3.0pre/ntirpc-1.2.1 seems fine.

 

 

NFS HA

======

 - NFS with high avalability. It is possible to specify replicas in /etc/exports on NFS server. The following

 options have to be added.

        -vers=4,replicas=/mnt@serv1.org:/mnt@serv2.org

 In this case, the client will use avaialble server. It is also possible to include a folder into the tree 

 exposed by serv1 the directory from serv2. This is done with adding new export with the following options:

        -vers=4,refer=/mnt/b@serv2

 - However, Ganesha does not support this. RH proposes to use floating IPs to provide availability and 

 recommends to use CTDB to achieve this (with heartbeat). However, this is not enough as there are caches

 sitting in between. After, the IP changed the caches have to be made obsolete.

 

Ganesha HA (standard way)

==========

 - Gluster may configure High Availability for NFS using RedHat HA cluster (gcs, corosync, pacemaker). All

 relevant packages have to be installed but it is not necessary to configure them.

 - However, some glusterfs modifications are required:

    * We need to create gluster_shared_storage volume and mount it under /var/run/gluster/shared_storage

        gluster volume create gluster_shared_storage replica 2 transport rdma 192.168.11.131:/mnt/raid/gluster2/gss 192.168.11.132:/mnt/raid/gluster2/gss

    * There is two parameters formats of pcs utility depending on the version

        'pcs cluster setup --name cluster_nfs ...' or 'pcs cluster setup cluster_nfs ...'

    it is necessary to configure appropriate type in the /usr/lib/ganesha/ganesha-ha.sh. With current version in OpenSuSE, the '--name' is required and,

    therefore, the following line have to be commented out.

         RHEL6_PCS_CNAME_OPTION=""

    * Then, it seems the ganesha pid file is expected at '/var/run/ganesha.nfsd.pid', besides the location of configuration file have to be specified. 

    The following lines have to be added into the /etc/sysconfig/ganesha

        OPTIONS="-L /var/log/ganesha.log -f /etc/ganesha/ganesha.conf -N NIV_EVENT -p /var/run/ganesha.nfsd.pid"

        CONFFILE=/etc/ganesha/ganesha.conf

    * If inifiniband addresses are not asociated with names, we need to set names in /etc/hosts

    * An empty (yes, it is required) ganesha.conf should be added to /etc/ganesha and ganesha-ha.conf have to be configured

        HA_NAME="gluster_nfs"

        HA_VOL_SERVER="ibcompute2"

        HA_CLUSTER_NODES="ibcompute1,ibcompute2"

        VIP_ibcompute1="192.168.26.170"

        VIP_ibcompute2="141.52.64.22"

 - Then, pcs servers have to be started on all gluster nodes and authenticated

        pcs cluster auth -u hacluster ibcompute1 ibcompute2 ibcompute3

 - Then, we need to enable global ganesha support 

        gluster nfs-ganesha enable

    it will create configured corosync cluster and register number of pacemaker resources 

    for synchronization. Type 'pcs status' to get configuration:

             Clone Set: nfs-mon-clone [nfs-mon]

                 Started: [ ibcompute1 ibcompute2 ]

             Clone Set: nfs-grace-clone [nfs-grace]

                 Started: [ ibcompute1 ibcompute2 ]

             ibcompute1-cluster_ip-1        (ocf::heartbeat:IPaddr):        Started ibcompute1 

             ibcompute1-trigger_ip-1        (ocf::heartbeat:Dummy): Started ibcompute1 

             ibcompute2-cluster_ip-1        (ocf::heartbeat:IPaddr):        Started ibcompute2 

             ibcompute2-trigger_ip-1        (ocf::heartbeat:Dummy): Started ibcompute2 

    

 - And, enable ganesha for specific volumes

    gluster vol set test1 ganesha.enable on

 * This actually turns cache invalidation on. Which has significant performance impact making 

 usage impossible.

    gluster volume get test1 features.cache-invalidation

    + Possibly, it can be switched off, but I am unsure which effect it will have on cache

    consistency.

        gluster volume set test1 features.cache-invalidation off

 

Ganesha pNFS

============ 

- Parallel NFS. All gluster nodes holding the bricks should run ganesha. One of the servers should 

 run NFS MDS (metadata server). It will be used by clients to mount the partition (no high avalability

 yet). The MDS is configured in ganesha configuration by adding:

        GLUSTER { PNFS_MDS = true; }

 The volume should set cache invalidation on (However, this really affects performance and stability

 data accesses often stalls when this option is turned on).

        gluster volume set test1 features.cache-invalidation on

 Then volumes should be able to mount with (not tested)

        mount -t nfs4 -o minorversion=1 ...

 * Multiple MDS servers are currently not supported and recommended. All clients should connect to the

 same MDS server.

 * The GlusterFS performance is not stable when cache-invalidation is turned on. Also, if PNFS_MDS is 

 enabled in Ganesha configuration, the speed is horribly reduced. Either of option brings down speed 

 from ~ 100 MB/s to 4 MB/s. So, it is unusable as of now.