Bug 1326187

Meeting and discussions underway with Soumya and Shashank to finalize on the content.

Hello Aurelion,

The document is further updated to address the issues raised by you as mention in the bug description:

http://jenkinscat.gsslab.pnq.redhat.com:8080/view/Gluster/job/doc-Red_Hat_Gluster_Storage-3.1.3-Administration_Guide%20%28html-single%29/lastBuild/artifact/tmp/en-US/html-single/index.html#sect-NFS_Ganesha


I have added my response inline to the comments shared by you: Let me know if these changes addresses the issues raised.

____________________________________________________________________________

1- along our docs we mention a VIP for each node, but nowhere does it say wether we're supposed to define a VIP in the same network range, as an alias to an existing interface, as a new interface, or let PCS handle the creation of that VIP (I went with the last option in the end)

Bhavana: Added a note under 7.2.4.3. Highly Available Active-Active NFS-Ganesha immediately after step 1. 

2- the doc doesn't clearly explain how the VIP_hostname variable is supposed to be formatted e.g. VIP_node1_example_com for node1.example.com - the template file only says VIP_node1 assuming there is no domain

Bhavana: The example details under "Creating the ganesha-ha.conf file" is now edited to show the format

3- once a volume is created and made 'HA', how is one supposed to mount that volume in an HA manner? Mounting from one of the nodes VIP? Any node? Any VIP? e.g. mount node3_vip:/vol /mnt/vol should work?

Bhavana: At the beginning of 7.2.4.6. Accessing NFS-Ganesha Exports, the sentence is further modified that says the mount operation can be performed from the VIP of any node.

4- how does one test the resiliency of the resulting HA volume? Once mounted from a VIP like I did in step 3 I killed the node from which I was mounting the volume from and still couldn't access the volume after 5 full minutes - is that expected behaviour?

Bhavana: This behavior is described under section 7.2.4.7. NFS-Ganesha Service Downtime. This was also verified by the eng team. However, if you do not see the expected result it was suggested by the eng team that a functionality bug can be filed. 

5- what are the port ranges required for a complete end-to-end gluster-pcs-nfs-ganesha setup? I tried to find out details online, there is a Red Hat KB article which only covers the Gluster ports but nothing around the PCS/Ganesha stuff that I could find. Enterprise firewalls do not use iptables/firewalld and need a list of ports/protocols/flow directions which we need to provide to our Clients.

Bhavana: A new section 7.2.4.1. Port Information for NFS-Ganesha is now created where all the port information is added.

6- how much pcs knowledge does a Client has to have to debug/maintain/fix/operate an NFS Ganesha setup? From the tickets I've seen it seems like they already need to know PCS well which we don't document at all either. Maybe a list of pcs commands related to the NFS Ganesha setup would be highly beneficial?

Bhavana: The basic details regarding Pacemaker and corosync is documented in the prerequisites section. For in depth knowledge one could refer the set of documents under "Clustering". We have already provided a link to the same in section 7.2.4.3. Highly Available Active-Active NFS-Ganesha. 

_________________________________________________________________

Thanks!

Kaleb,

Kindly review the changes mentioned in the above comment. Also please suggest anyone from HA team to get the section where in we mentioned the ports to be used by cluster services, reviewed.

1- yes, pcs creates the VIP. New note in 7.2.4.3 looks good.

2- example is:
#
# Virtual IPs for each of the nodes specified above.
#VIP_server1.lab.redhat.com="10.0.2.1"
#VIP_server2.lab.redhat.com="10.0.2.2"
....

should be:

#
# Virtual IPs for each of the nodes specified above.
#VIP_server1_lab_redhat_com="10.0.2.1"
#VIP_server2_lab_redhat_com="10.0.2.2"
....

(for the curious, the VIP_ lines in the conf file are expanded by bash. Any '.' may confuse bash (but sometimes it works if you're lucky. The ganesha-ha.sh setup script will convert the all '_' in the VIP_ lines to '.' where it needs to.)

3- explanation and note look good to me.

4- explanation and notes look good to me

5- ports look correct. We can ask Andy Beekhof or Ken Gaillot to confirm. The ports that pacemaker and corosync use should also be documented in their respective documentation, although I am unable to find it in either Red Hat's or clusterlabs.org documentation.

6- I think documenting pacemaker work-arounds and helpful commands is nice, but beyond the scope of this document. Can maybe reference the pacemaker docs? Unfortunately yes, pacemaker is complex (rich feature set, which we don't use most of) and it will be helpful if an admin knows something about it.

Thanks Kaleb,

I have updated the example file as suggested:

http://jenkinscat.gsslab.pnq.redhat.com:8080/view/Gluster/job/doc-Red_Hat_Gluster_Storage-3.1.3-Administration_Guide%20%28html-single%29/lastBuild/artifact/tmp/en-US/html-single/index.html#sect-NFS_Ganesha

Moving the bug to ON_QA

(In reply to Kaleb KEITHLEY from comment #11)

Thanks Kaleb. 

> 
> 5- ports look correct. We can ask Andy Beekhof or Ken Gaillot to confirm.
> The ports that pacemaker and corosync use should also be documented in their
> respective documentation, although I am unable to find it in either Red
> Hat's or clusterlabs.org documentation.


Andrew/Ken,

Kindly take a look at the above mentioned document and confirm if the details about the ports used by HA services are correct? Thanks!

Yes, the ports are correct. To clarify which ports go with which service:

  TCP 2224 - pcsd
  TCP 3121 - Pacemaker Remote
  TCP 21064 - DLM
  UDP 5404 and 5405 - corosync

When referring users to the cluster documentation, it may be a good opportunity to remind users that Red Hat doesn't support clusters without fencing.

Hi Bhavana,

Below changes are required in table 7.5

The following table lists the port details for NFS-Ganesha

Current port details:

corosync	2224	TCP
pcsd	3121	TCP
pacemaker_remote	5404	UDP
pacemaker_remote	5405	UDP


To be Changed:

pcsd              2224           TCP
pacemaker_remote  3121           TCP
corosync          5404 and 5405  UDP

Let me know once done.

Hi Shashank,

The link is now updated:

http://jenkinscat.gsslab.pnq.redhat.com:8080/view/Gluster/job/doc-Red_Hat_Gluster_Storage-3.1.3-Administration_Guide%20%28html-single%29/lastBuild/artifact/tmp/en-US/html-single/index.html#sect-NFS_Ganesha

All the updated contents, in the doc link provided in comment 17, looks good and takes care of all the suggestions mentioned in the description of the bug.

Based on the above observation, marking this bug as Verified.