The Global Document Storage should be considered as an extension to the LiveCycle database. It is used for all persistent document storage and also for temporary files.
Before installing and configuring LiveCycle, one should create a folder for the GDS and you can find some very good information about the GDS here for clusters http://help.adobe.com/en_US/livecycle/9.0/prepareinstallcluster.pdf and here for single servers: http://help.adobe.com/en_US/livecycle/9.0/prepareinstallsingle.pdf.
When creating a cluster, one needs to create a shared folder, accessible by all nodes of the future cluster, that will be the GDS.
Recently I had to create an LC cluster (2 nodes) in a UNIX environment (RHEL) and I faced a specific Unix situation.
In order to have a shared folder, I had decided to create an NFS share on a third server. For the sake of the explanation let’s use the following topology:
- server node 1: machine A
- server node 2: machine B
- server hosted the GDS: machine C
- path to GDS: GDS_path
So I created an NFS share on C. I then decided to create a mounting point on A and B for the GDS. To make things simple, I had made the choice to keep the same path on all 3 machines so my GDS_path was /u01/LC/GDS.
In order to make the mounting process as simple as possible, I had edited the /etc/fstab on A and B so the GDS would be mounted at boot time automatically:
machine C ip address:/u01/LC/GDS /u01/LC/GDS nfs
After rebooting A and B i tested the shared folder and everything worked fine. I carried on with the installation of Livecycle and when I ran the Livecycle Configuration Manager I entered the path to the GDS accordingly: /u01/LC/GDS.
A few steps later and the cluster was up and running.
Note that after creating the NFS share I never went back to the machine C.
Later on I noticed that on B, the /u01/LC/GDS was empty whereas on the same location on A I could see the 3 usual folders: audit, backup and docm.
I ran the df -h command in my terminal on A and B and could see that machine C ip address:/u01/LC/GDS had failed to be mounted.
So this means that when I installed Livecycle and specified the path to the GDS in the LCM, it installed things locally on A since i was running LCM from that machine.
I went back to my terminal and l manually mounted the shared folder on both A and B. I then noticed that the 3 folders that had been created on A under /u01/LC/GDS no longer existed. In fact they disappeared but have not been deleted.
This is a basic UNIX behaviour where the mounting folder is pointing to the remote rather that the local drive.
In order to recover from this, I had to backup and delete what had been created on A under /u01/LC/GDS and then copy it on C under /u01/LC/GDS. Made sure the folder was mounted on A and B and could see the 3 subfolders (audit, backup and docm) on all nodes.
This would have never happened on a Windows machine since when a map drive is successful, a path is valid and there is no local mounting point on the machine where the map drive is created. In this scenario, the LCM would have detected the path to not be valid.
Suggestion to avoid surprises where the mounting would have failed without notice:
The best practice is probably to arrange things so that the UNIX mount point is not used as the root of the GDS, but instead use some directory within it as the GDS root.
On machine C it could be the same path as before /u01/LC/GDS.
On A sand B it could be a mount point /u01/LC with the following fstab:
machine C ip address:/u01/LC /u01/LC/ nfs
Specify the GDS_path in LCM (or adminui) to /u01/LC/GDS
If for some reason the mount does not succeed, the bare mount point does not contain a GDS directory and the cluster will fail predictably since it cannot find any GDS at all. There will be no local writing and no recovery action needed.