dm_blog

In my last few posts, I described how to install a Content Server with distributed filestores. In this blog post, I’ll discuss a few DQL queries to track your files in a distributed setup.

The first set of DQL queries will help you get information regarding storage of content, include its filestore and path:

This query returns the actual file system path to object’s content file. Use this query in conjunction with the second query to find out exactly where your content files are stored on the content server.

To find file system path of an object’s content file:

select file_system_path from dm_location where object_name in (select root from dm_filestore where name in(select a_storage_type from dm_document where r_object_id = ‘object_id’))

To find file store a file is saved on:

Now that you have the file system path, use the following query to identify the file store your file is stored on:

select a_storage_type from dm_sysobject where r_object_id = ‘object_id’

With above two queries, you should be able to zero down on the location of the file.

To find the default file store of a type:

To find out the default filestore for a type (e.g. my_document), use the following query:

select name from dm_store where r_object_id in(select default_storage from dmi_type_info where r_type_id in(select r_object_id from dm_type where name = ‘my_document’))

You can also find the default location for a type via DA. Just log on to DA and go to “Types” in the navigation tree on left. Browse or Search your desired type and check default storage.

To find out disk space used by a particular file store:

select sum(content_size) from dmr_content where storage_id in (select r_object_id from dm_store where name =  ‘file store name’)

Again, this can also be checked via DA (DA->Storage->filestore)

And finally, to find out the root directory of the filestore of particular type i.e. my_document, use the following DQL

select file_system_path from dm_location where object_name in(select root from dm_filestore where r_object_id in(select default_storage from dmi_type_info where r_type_id in(select r_object_id from dm_type where name = ‘my_document’)))

In my next post, I’ll discuss tips and tricks to identify and resolve issues in a distributed setup.

admin Content File Server, Distributed Setup, Documentum, Documentum 6.5, Documentum distributed setup, Remote Content File Server, single repository distributed storage Distributed Filestores, DQL, find location, location, multiple filestores, track files

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.

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.

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:

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.

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.

Stay tuned!

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