Ultimately after four and a half months I got an opportunity to implement the Single Repository Multiple Content Server model. We had to shift our Documentum setup to a new server and I realized that it’s the perfect time to play around with the existing server. Multiple Content Servers can be implemented on the same host as well as on different hosts. The first two installation models discussed here were implemented on 6.5SP1 Windows SQL Server platform whereas the last one was implemented on 6.5SP2 Linux Oracle platform.
Multiple Content Servers on the same Server Host:
This case was much simple. We just need to create a new Server Configuration object, a new copy of server.ini with small changes and with a new name, some changes in Services File located at C:\WINDOWS\system32\drivers\etc and some entry in Windows Registry. The steps are described in the Content Server Installation Guide. The procedure was short and simple. Once the configurations are complete we get an additional Docbase Service in the Windows Services. The Docbase will be available if anyone of the two or both of these Docbase Services are running. The implementation should indeed increase the maximum possible number of concurrent sessions for a repository.
Multiple Content Servers running on different Hosts:
a) Content File Storage
In order to create Multiple Content Server running on different server machines for a single repository the first step is to create a Single Content Server – Single Repository installation on the first host. On the second host machine install the Content Server but don’t create any Docbase. Run the cfsConfigurationProgram.exe located at C:\Documentum\product\6.5\install. The program prompts for a Docbroker and displays the list of Docbase on authentication. The whole procedure is described in Content Server Installation Guide and Distributed Configuration Guide. While implementing this setup we ran into an error which read something like “Error – cannot find source: dbpasswd.txt Please read error log C:\Documentum\product\6.5\install\dmadmin.ServerConfigurator.log for more information“. We found a solution to this on geekweda.
The bug surfaces if you specify a domain name in one of the previous screens. To make your way around this bug, click “OK” on the error message to come back to the “Service Name” screen. Go back 4 screens by clicking “Back” button 4 times to come to the Repository and username selection screen and delete the Repository Super User Domain. Click next and continue with installation.
That solution was of immense help and that was the only issue we encountered in the installation process. Once the installation is complete a Docbase and a Docbroker service will be available on the remote server. Both Docbrokers are provided in the dfc.properties of the web application and each ACS Server is projected to the other docbroker as well. The Content File Storage configuration has a distributed filestore.
b) High-Availability Configuration
In order to achieve the HA Configuration the Database and the Filestore has to be shared across both the Primary and Secondary Content Server. The Installation of the Primary Content Server is same as any Single Content Server installation. While installing the Secondary Content Server, the same Database and the shared Filestore should be selected. Install the Docbroker. At this point instead of creating a new Docbase we will have to copy few files from the Primary CS. These files would include the server.ini, dbpasswd.txt, aek.key, dm_start_docbase, dm_stop_docbase etc. We will need minor changes in server.ini and dm_stop_docbase. Also a new Server Configuration Object is created. Both the Docbrokers are projected to each other and the dfc.properties of the application should mention both. I guess I have summed it up all. I could not find the process well documented in the CS Instalattion guide. CS Administration guide though provides some insight.
Now the Big question! Which one to choose from Content File Storage and High-Availability configurations?
Points to keep in mind: Content File Storage configuration offers a distributed Filestore whereas the High-Availability configuration needs a shared Filestore. I have also heard that the installation of an Index Server with the Content File Storage configuration limits the Full-Text Search Functionality. But the source of that information, as we all know can not be trusted. What I am sure of is that the Installation of an Index Server with High-Availability CS configuration works fine for both the Primary and Secondary CS. The High-Availability CS Installation with a High-Availability Index Server Installation is well supported.
*To be updated