Archive

Archive for the ‘Documentum installation’ Category

Distributed Setup in Documentum IV - Configuring a distributed store

December 25th, 2008
Comments

 

In my last post we installed a remote content file server. Despite all that configuration and installation, our dear distributed store is still unusable. Although the store is online now and is visible to the primary content server, content server can not still store the content, as we have not added it to the distributed storage area. Further, once we add it to the distributed storage area, we must create and configure network locations and ACS servers, so that Content Server is able to store and route content to appropriate file stores.
So let us start by adding this remote content file server and its store to the distributed storage area that we created previously.
Log on to Documentum Administrator of the primary and click on storage node on the navigation tree on the left. If you installation of the remote content file server was successful, you should see a new remote file store listed under storage. The new file store would typically be named as fs_rcs_hostname_xxx where xxx is the name of the instance you specified during installation. The screen below shows the new file store in my setup:

 


Right click on the distributed store that you created previously (distributed_store) and and select properties. Click on the components tab and add the newly created remote file store. Your distributed store should now contain a local filestore (filestore_02) and a remote filestore(fs_rcs_yyy_xxx) and should look similar to screen below:


Press OK to save settings.

Next, you need to tell each content server instance (The primary as well as remote) which file stores are local to them and which are remote file stores, so that they may store files appropriately. To do this, expand Administration Node in DA by click + against it, and click on Content Servers. The Content Server Configuration Screen on right should list at least two instances - one primary and one remote. If the remote instance is missing, your installation for remote content server was not successful. The remote instance can be identified by a prefixed hostname_ (hostname followed by an underscore). The screenshot below depicts the same:


To add the far stores, right click on the primary content server (WEALTH in my case) and select properties from the context menu. Click on the Far Store Tab. Click the add button and add the remote file store that was created by Remote Content file server installation program. Don’t add any other store. Your screen should look like the one below:


Click OK to save. Now right click on the remote content file server instance (hostname_xxx) and click properties. Select the Far Stores tab and add all file stores of the PRIMARY SERVER e.g. filestore_02. The screen below shows my configuration:



In case you are confused about which file stores to add where, think about it this way: Any file stores that you define as Far Stores for a give content server will NOT BE accessed directly by that content server. In other words, content server WILL ACCESS ONLY those file stores directly that ARE NOT LISTED here. So in case of primary content server, the list will include only the remote file store. In case of the remote content server, the list will include all file stores of primary content server e.g. file store_02, filestore_01 etc.

Click OK and save the configuration.

 

Now its time to configure ACS servers and network locations. Accelerated Content Services or ACS is a component that is used by Content Server to save and retrieve files from content server. Normally, on a stand alone installation, you will not come across this creature. Its role only becomes evident when you go distributed. Any read or write request that is generated by a user, is handled by an ACS instance. When content server receives a read or write request, it determines the ACS that is nearest to the user and instructs the client to read or write from that content server. For determining the nearest ACS server, content server uses network locations. Thus, it is very important that you configure these two correctly, otherwise the whole setup will not work.

 

There are two ways in which you can configure an ACS instance. The most obvious way is via the “ACS Configuration screen under Administration->Distributed Content Configuration->ACS Servers Configuration.

The second, not so obvious way is via the Content Server Configuration Screen under Administration->Basic Configuration->Content Servers.

 


But before we do that, let us first create Network Locations. As I explained before, Content Server determines the nearest file store to a user using a Network Location. The process is very simple. When you define a network location, you associate a range of IP address with that location and assign a name and ID to that range. You also define a network locations proximity to content server i.e. how close those IP addresses are to a give content file server. When a client later access a repository, content server first identifies the network location of that client using the IP address range that you defined while creating network locations. Once content server determines the network location, it then identifies the nearest file stores using the proximity values that you defined.
Therefore, it is very important that you model network locations and proximity values to properly reflect your networks topology. In DA, select Network Locations under Administration->Distributed Content Configuration. Select “Network Location” form File->New.

 


On the New Network Location Popup, type in the a unique Id for this network location. Add a description if you want. Type in a display name. This name is different form the unique id that you specified earlier. Display name is only for informative purpose and is displayed to users when they log on. Click the “Add” button to add IP address range to this network location. Click OK when done.

Your screen should look similar to the one below:


In my setup, this network location identifies all network traffic originating from my floor in Johannesburg.

Since in this setup, I had two different file stores, I must define at least one network location to correctly route files between two file stores. However, explicitly state my rules and to exemplify this setup, I will add another network location for the remote file store. The setup for second network location is shown below:


This network location called “Lalucia” identifies all network traffic originating from our branch in La Lucia, near Durban. Note that I have added two IP address ranges.

After adding these two network locations, my final setup looks like this:


Now that we have identified our network traffic, its time to associate its proximity to ACS servers.
Click on Content Servers under Administration->Basic Administration on the left navigation tree and right click on your primary content server and select properties:

 


Click on the Network Locations Tab and add BOTH the network locations. Set a proximity value for each network location. Proximity values are nothing but numbers that define relative distance of network locations and ACS servers. A network location that has a proximity of 50 is close to an ACS server compared to one that has 100. Same locations can have different proximity values for different ACS servers, for obvious reasons. The values can range between 0 and 999. In my case, since the content server is located in Johannesburg the Johannesburg network location will have the lower value than any other network location.
However, after adding the network locations, enable ONLY THAT location, which you want to be served by THIS content sever. For example, in my case, my primary content server is located in Johannesburg and I want only Johannesburg’s traffic to be served by this content server. So I added both network locations but only enabled Johannesburg’s network location for this primary content server:

 


Click OK and save the configuration. Similarly, add the network locations for the remote content file server as well by selecting your remote content file server (hostname_xxx) under Administration->Basic Administration->Content Servers. My configuration for the remote content file server looks like following:


Now that we have defined network locations, the final step is to project this configuration to both the docbrokers (local and remote). In simple terms, this means telling both docbrokers that such a configuration exists and they should act accordingly when it handles a client request.

We need to add projections to BOTH content servers - local and remote. To add projections, right click on the primary content on the same (Content Server Configuration) screen and select properties.


On the Sever Configuration Properties pop up screen, click on Connection Brokers Tab and click on Add button to add a connection broker:


Enter the hostname of the primary docbroker, leave the default port as it is, enter a proximity value of 9001, check the enabled check box and click OK.

Click on the Add button again, enter the host name of the remote content file server docbroker, and enter a proximity value of 100. Click OK. Your screen should look similar to one below:


You might be wondering as why I entered two drastically different proximity values. There are two kinds of projects - one for data or file store and one for meta data server. Proximity values for a metadata server are always between 0 and 999 and proximity values for a data or file server are in range of 9000 to 9999. Thus, when the primary ACS server for metadata projects to remote content file server, it projects 100. When it projects the local file store i.e. when it tells the local docbroker that it also has a file store, it projects that file store’s proximity as 9001 i.e. it is the nearest file store. The primary does not need to project its own meta data server to itself, as it is the only one in the setup.

Click OK to save the configuration.


Right click on the remote content file server and click properties.
Click on the connection brokers tab and add the two connection brokers as shown below:

 


Note that this is REMOTE CONTENT FILE SERVERS projection to the two docbrokers. To the primary it projects a proximity value of 9100, suggesting that is a remote file server with a proximity of 100 and a proximity value of 9001 to itself suggesting that the file store located on the remote server is closer that the file store located on primary server at Johannesburg. Note that this is optional but I added it for sake of brevity and to make my rules even more explicit.
Click OK to save configuration.

 

 

Before we test, couple of final checks. First, let us ensure that ACS is set to read configuration from Server config objects instead of ACS config object.
In DA, select ACS servers under Administration->Distributed Content Configuration. On the ACS servers configuration screen, right click the primary ACS server (identified by HOSTNAMEACS1) and click properties:

 


On the Info Tab, ensure that “Access Local Stores Only” is selected under Content Access. Click on Projections and Stores tab and ensure that “Associated content sever: xxxx” is selected under “Source: Use projections and stores from”, where xxx is your repository name.

 


Click Ok. Again, on the ACS Servers configuration screen, select the remote content file server (identified by leading A followed by hostname followed by _ and service name), right click and select properties. Ensure the above mentioned settings are set properly (Access Local stores and Source). Click OK and save.

The last and final check is for surrogateGet method. When a file is not found on a local file store, content server uses this method to retrieve file from a remote file store. To ensure this is set properly, click on Storage node on the left navigation tree. On the storage administration page on right, right click the distributed file store (distributed_store) you created and select properties. Ensure that “GetMethod” is set as “dm_SurrogateGet”. If not, click on SelectMethod and choose dm_SurrogateGet.


Click OK and save. Repeat the same process for the local file store that you created (filestore_02) and the remote file store that was added by installation of remote content file server.

Restart all the content servers and docbrokers for configuration to come into effect. To test the configuration, try accessing DA or Webtop from different locations (those falling within defined Network locations) and checking where your file is stored.

 

This post completes the configuration of a repository with distributed storage areas. In this blog, I discussed only two file stores. You can however add as many as you want.
In my last and final post of this series, I’ll be discussing how to test this setup and some results that we concluded out of our internal testing.

 

Stay tuned!

 


[Post to Twitter]  [Post to Plurk]  [Post to Yahoo Buzz]  [Post to Digg]  [Post to Reddit]  [Post to StumbleUpon] 

cucumberboy Distributed Setup, Documentum, Documentum 6.5, Documentum distributed setup, Documentum installation, Remote Content File Server, performance improvement, single repository distributed storage , , , , , , , , ,

Distributed Setup in Documentum III - Installing Remote Content File Server

December 21st, 2008
Comments

In my last post, we discussed setting up of the primary site for a Single Repository Distributed Setup. In this post, we will look at installing the Remote Content File Server - the distributed storage component of a Distributed Setup. However, before we start the installation of the remote file server, we need to make a few changes to the configuration of primary content server that we installed in previous post. These settings include setting up of a distributed storage area and moving all system objects (dm_sysobject) to this distributed storage area.

Documentum abstracts all the details of distributed stores into what is known as a “Distributed Storage Area”. If you have worked with file stores and storage areas in Documentum Administrator (DA) before, you might already be aware of it. A distributed storage area is collection of filestores local or remote that are grouped together into a single logical unit. A filestore is just a drive or folder that has been allocated to Documentum to store documents and files. When you add filestores to a distributed storage area, all of them become part of a single storage area. When a user writes or saves a file to such a distributed storage area, content server determines the location and proximity of the user relative to the filestores in the distributed storage area and stores the file in a filestore that is nearest to the user. Internally, Content Server uses the concept of “Network Locations”, “Proximity Values” and “Remote file stores” to achieve this. All this is however, transparent, to the end user.

To prepare the primary content server for distributed setup, fire up your browser and point it to Documentum Administrator (DA) for the primary content Server. Login as either the installation owner or a superuser. On the navigation tree on left hand side, select “Storage” to bring up storage administrtion page. The screen should look the one below:



Before we setup a distributed storage area, we need to create a new local file store that will be part of this distributed area. The reason for creating a local filestore is two fold. One, it will be best to store all system files locally for obvious reasons. Therefore, after creating the new local file store we will move all dm_sysobjects to this filestore. And two, this filestore will also store any files that will be saved and accessed locally by users that are in proximity of this file store. You may also chose not to store any file on this file store. In this case, the final configuration will look slighlty different. Stay tuned for my next post for details. And yes, according to EMC’s distributed configuration guide, leaving the filestore_01 as it is, is a good choice for compatibility reasons.

To add a new local filestore, select “File Store” from File -> New menu, as shown below:


Enter a name for the file store e.g. filestore_02 and choose a path. Select “Select Server Path” option under “Location or Path” and choose a directory to store the content files in. This could be any location on SERVER’s hard drive where you’d like to store your content file e.g. “C:\Data”. Press “OK” when done.


Now that we’ve created a local filestore, it is time to create a distributed storage area. From File menu, select Distributed Store under New as shown below:


On the “New Distributed Store” webpage, specify a name for the distributed store e.g. distributed_store and select “Fetch Content Locally Only” checkbox. When you select this option on a give file/distributed store, content server only serves file that are on that files store. If a store has been identified as the nearest one for a particular user and the requested file is not present on that file store, content server WILL NOT fetch file directly from any other store. Instead, it will request the file from the other file store on behalf of this file store. The file in question will first be copied on to the local file store and only then will it be served to the user. This ensures that any subsequent fetches for this file from that file store’s region are fast.


Click on the “Components” tab or press the “Next” button.


Click the “Add” button and add the local file store you just created (filestore_02) by selecting filestore_02 (or whatever name you chose) and pressing the ” |>” button as shown below.


So that you screen looks like the one below.


Click OK and then click Finish to close the dialog box.

You should see you newly created file store and distributed storage area in the Storage administration screen now:


Once done, its now time to set the default storage area for all sysobjects to the newly created distributed storage area. To do this, select “Types” from navigation tree on left in DA and locate “dm_sysobject” on right frame.


Right click on dm_sysobject and select “Properties”. You should see a screen similar to the one below:


Under the “Info” tab, look for a drop down list called “Default Storage” and select the distributed storage area that you created above (distributed_store). Click “OK”

Now that you’ve told Content Sever to store all new dm_sysobjects in the distributed storage area, its time to move the ones that are already there to the distributed storage area.

From the Tools menu in DA, select “DQL Editor”.


The DQL page should open up. Copy and paste the following DQL query replacing ‘distributed_store’ with whatever name you chose for your distributed storage area above and press Execute button. Please be patient as this query might take while to finish.

UPDATE dm_sysobject (ALL) OBJECTS SET a_storage_type=’distributed_store’ where a_storage_type=’filestore_01′

After a few seconds or minutes, you should see a screen like the one below:


If this is a fresh content server installation, you should not get any errors. In case you do, try and resolve those errors first before moving on. The most likely and obvious cause of an error could be that the files are in use and could not be moved by Content Server. Try restarting the content server or deleting the files if they are not system or data files e.g. logs.

Finally, set the server time out value in primary server’s server.ini to 30 minutes. You do this by selecting “Edit Server.ini” from “Docbase” tab in Documentum Server Manager (Start menu->All Programs->Documentum->Documentum Server Manager), as show below:


Look for a section called [SERVER_STARTUP] and add the following entry as shown below:

client_session_timeout=30


Save the file and close notepad and Documentum Server Manager.

Now that we have moved all files to the new storage area, it is time for us to install and configure the remote content file server.

Copy the entire Documentum Installable on the server that is designated to become a remote file store. The installation will not work over a network. Extract the files on a local disk and double click a file called “serverWinSuiteSetup.exe”. The installation program should begin.

The installation program for Documentum is organized as follows:

  • The basic installation program that installs required content server binaries etc.
  • Once the base install is over, you can either choose to configure a new docbase or a remote content file server.
  • If you choose to configure a new docbase, then you can add a new docbroker and a new docbase
  • Or else, you can create a new docbroker and a new remote content file server.

As you can see, the base install is must for both docbase and file server installation. Follow the instructions in my previous post to complete the base installation. You know that the base install is over when you see a screen like this:


Choose “Configure Content-File Server for use with an existing repository” and press Next>.


The next screen is just an informative screen. Click Next. If you get a screen prompting you to restart you computer, restart. You should “Content File Server Configuration Program” after you log back in:


Press next to continue.



Enter the password for installation owner and press next. This username and password for installation owner has to be identical for primary content server and remote content file server (including domain) otherwise the setup will not work.

Enter the name of the docbroker for the PRIMARY content server (the one created in previous post). Installation program will use this docbroker to retrieve a list of repositories accordingly will create a remote content file server. Press next to continue.


You will be presented with a drop down list of repositories know to that docbroker. Select the repository you want to add a file store to and type in super user user name, password and domain. Click next.


You will be asked to select the connection mode for clients. Select Native and Secure and press next to continue.


On the following screen, specify a directory where you’d like to store content files for the distributed store and press Next. Note that this is the area where a users documents and other content files will be stored.


Again, enter the location for storing shared files -jars, dlls etc or just let it be a default location and press next.


The next screen will prompt you to enter a service name. This is the name of filestore’s service that will run on this distributed store machine. I usually go with the default choice (same as docbase name). Press next to continue with installation.


Okay, this is where the fun starts now. You should see a screen similar to the one below:


followed either by a success message (unlikely) or a screen with an error (most likely) message which looks like this and says “Error - cannot find source: dbpasswd.txt Please read error log C:\Documentum\product\6.5\install\dmadmin.ServerConfigurator.log for more information”


My experience tells me that this error can be caused by two reasons:

  1. The DSN name for the database are different on primary and content file server. Check the names and if they are different, change the DSN name on the content file server to match the name on Primary server.
  2. There is a bug in one of scripts that installer runs while configuring the remote content file server. The script is called dm_rcs_copyfiles.ebs. 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.

The installation program caches the values entered by the user, so if even after changing DSN name or removing domain name you still get the error, quit the installation program completely and start remote content file server configuration program from scratch. To start the configuration program locate a file called cfsConfigurationProgram.exe in C:\Documentum\product\6.5\install and double click on it.

In you are lucky not to get the error first time, you should see a success screen saying that your configuration of a remote content file server is complete and successful.

The configuration program not only creates a local docbroker and a filestore, it also registers this file store in the primary content server. All you now need to do is add this filestore to the distributed storage area you created before and configure ACS and network locations. How exactly to configure, will be discussed in next post. Stay tuned!


[Post to Twitter]  [Post to Plurk]  [Post to Yahoo Buzz]  [Post to Digg]  [Post to Reddit]  [Post to StumbleUpon] 

cucumberboy Content File Server, Distributed Setup, Documentum, Documentum 6.5, Documentum distributed setup, Documentum installation, EMC, Remote Content File Server, dbpasswd.txt, single repository distributed storage , , , , , , , , ,