Feeds:
Posts
Comments

Posts Tagged ‘Content Server’

There are a lot of discussions on various forums/threads regarding the Content Server High Availability Environment. But I have not come across any documentation providing the precise steps to implement it. This is an attempt to list the steps that I have been using for the implementation. It’s basically an integration of bits and pieces from various sources combined along with my experience in order to put a clear picture. These steps may not be exactly as suggested and supported by EMC.
The procedure listed below is specific to the Content Server Linux Oracle 6.5 SP2 version.

Prerequisites:

  • As it’s a HA environment, the content files should be present in a File Store that is shared across the Content Servers.
  • The Installation Owner and the Installation Path should be same on each Content Server.
  • Availability of a Database Server and its connectivity through each Content Server Host using Oracle Client.
  • Update the /etc/hosts file of the Content Server Hosts so that they can resolve their IP addresses and hostnames.

Once the above prerequisites are satisfied, the below steps can be used to establish the HA environment.

  • Install the Primary Content Server as per the standard procedure mentioned in Installation Guide.
  • Install the docbroker on the Secondary CS host.
  • Create a Secondary Server Config object using Documentum Administrator.
  • Copy server.ini, aek.key, dbpasswd.txt, dm_start_docbase and dm_shutdown_docbase from Primary CS Host to Secondary CS Host.
  • Update the server.ini on both the Hosts so that the docbrokers project to each other.
    server.ini on the Primary CS:

    [DOCBROKER_PROJECTION_TARGET]
    host = <primary docbroker>
    port = 1489
    [DOCBROKER_PROJECTION_TARGET_1]
    host = <secondary docbroker>
    port = 1489

    server.ini on the Secondary CS:

    [DOCBROKER_PROJECTION_TARGET]
    host = <secondary docbroker>
    port = 1489
    [DOCBROKER_PROJECTION_TARGET_1]
    host = <primary docbroker>
    port = 1489
  • Update the dm_shutdown_docbase as follows: 
      The line preceding to “shutdown,c,T,T” should be updated as follows:

    • Original:
      ./iapi <docbase> -U$DM_DMADMIN_USER -P -e << EOF 
    • Updated:
      ./iapi <docbase>.<secondary server config object name> -U$DM_DMADMIN_USER  -P -e << EOF
  • Update the dfc.properties of the Web Application as well as both the Content Server Hosts so that they point to both the docbrokers.
  • Create an ACS Config object using the below command:
      dmbasic -f dm_acs_install.ebs -e Install -- <docbase name> <installation owner> <password> <new acs config name> <secondary server config name> <JMS Port> <JMS protocol> <output log location>
  • Update the acs.properties accordingly.
  • Once the above steps are complete, shutdown the Primary CS and test the Secondary CS for expected functionality. There may be minor issues which may need few basic fixes. Such fixes include creation of sysadmin directory at $DOCUMENTUM/dba/logs/<repository id>/ in order to fix issues relating to jobs running on Secondary CS.

Start the Primary CS and now both the CS should be in HA.

Advertisements

Read Full Post »

Note: I am not sure how useful is this post. This post has remained private for more than a year. I am turning it public on Prasad’s request. Please read the disclaimer before reading the post.

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

Read Full Post »

Do check the comments for clarification.

I have a BIG DOUBT (appears big to me) and my only intention of writing this post is to get a clarification. So, if you are looking for some knowledge gain over here, you may instead be inviting a BIG PAIN in your head. I am inviting only contributors who can help me clarify MY BIG DOUBT. Anyone else reading this article will be doing so at his own risk.

Okay. Let me start now.
I was reading the first chapter, ECM Basics of Pawan Kumar’s book on Documentum Content Management Foundations and came across the following.

The term Content Server is used in two contexts – the Content Server software that is installed and resides on the file system and the Content Server instance, which is the running process that resides in memory and serves content at runtime. However there is little chance of confusion since the usage is often clear from the context and the term Content Server is typically used without additional qualification (software or process/instance).
A Content Server instance is dedicated to and manages only one repository. However, we will see later in architecture discussion that multiple Content Server instances can be dedicated to the same repository. This is typically done for performance reasons where the multiple Content Server processes divide up the load for serving content from the same repository.

Pawan is pretty clear in what he has mentioned. I got the doubt while relating it to the practical usage.

In practice while creating an environment setup we first install Content Server on a server (after installing database) system and then we create repositories. We can have multiple repositories. What we have now is one installation of Content Server Software and more than one repository.
Once all the installation and configuration process is over (including Content Server, Application Server, Webtop/Custom Application) and the application is ready for use, we can connect to the application through a browser. We get a login screen where we get the drop-down having the repository names to choose from. We can select any repository on the login screen and connect to it after authentication.

Now the thing which I am wondering about: As per the book the repositories have dedicated Content Server Instances. So if we have two repositories, we should as well be having two Content Server Instances which are actually running Processes/Programs. Where can I see these instances? When are they created? How can I make two Content Server Instances to serve single repository?

I don’t have an answer to these questions.
After a lot of brain storming I could think of starting/stopping of docbases using Documentum Server Manager. By starting a docbase we are indeed starting a process or a program. This program for sure is dedicated to the particular repository. So, shall it be correct if I say that by starting a docbase through Server Manager, I am actually starting a Content Server instance?

….BOOOOM….

I am sorry if it is a NON-SENSE of a very HIGH LEVEL, but this was the best I could think of. Even if I assume the statement to be true, how am I going to make an additional Content Server instance to serve the same repository? This is creating a much bigger pain in my head. I am confused and I am sure I am creating pain in my audience’s head too. Just wondering whether docbroker is also involved somewhere in the scene?

Let me stop here. This pain is becoming unbearable and I want to get rid of it.
Looking forward for some clarification. Any kind of help in this regard will be highly appreciated.

Uttkarsh's most interesting photos on Flickriver

Read Full Post »