Professional Documents
Culture Documents
This white paper describes the various distributed architectures supported by EMC Documentum and the relative merits and demerits of each model. It can be used to evaluate which distributed model or combination of models would be most suitable based on the business needs. This would be particularly relevant to organizations with users who are dispersed throughout a large region or across the world, and where improving the speed and efficiency of information collaboration and production across their enterprise would be the primary objective
Table of Content
1. Introduction 2. Abbreviation and Acronyms used 3. The Foundation: The Documentum Repository 4. Why Distributed Access? 5. Documentum Solutions For Optimizing Content Responsiveness 6. Relative Comparison Between Single And Multiple Repositories 7. Documentum Distributed Architectures 8. References And Citations 3 3 3 4 5 6 7 16
Introduction
This paper attempts to outline the various options available to a design or solution architect while planning to implement a distributed architecture environment using EMC Documentum. It details the relative merits and demerits of each model that are essential to be considered during the planning stage before finalizing on a best-fit distributed architecture for any Documentum implementation.
Central Site
Remote Site
Content Server
Local Client
WAN
Remote Client
File System
Multiple Repository Model ? multiple repositories, a user at one location will not With
be able to see a document uploaded by a user from the remote location unless the replication job has run.
Asynchronous write operations ensure that a user does not wait for content to be saved to the repository when the network communication lines are slow. Additionally, other users in the network locations served by the BOCS server on which the content is parked have immediate access to the content. Asynchronous write operations are best used when: The branch office and primary office are connected by slow network lines. When the content is used primarily by users at the network locations served by the BOCS servers. The content to be saved or checked in is a large content file. Limitations Using asynchronous write has the following limitations: Parked content is unavailable to users who are not accessing the repository through the BOCS server on which the content is parked. If an application needs immediate access to particular content, asynchronous write cannot be used for that content unless the application is rewritten to check for the parked state before obtaining the content.
Central Site
Remote Site
Content Server
Database Local Client
Metadata
Remote Client
Content
File System
WAN
BOCS Cache
Single Repository With Multiple Content Servers In this model, content is stored in a distributed storage area. A distributed storage area has multiple component storage areas. One component is located at the repositorys primary site. Each remote site has one of the remaining components. Each site has a full Content Server installation. This model can be used for either Web-based clients or Desktop clients. In this configuration, metadata requests are handled by the Content Server at the primary site, and requests to write content to storage are handled by the Remote Content Servers (RCS) as depicted in the following figure.
Content Server
Local Client
Remote Client
File System
WAN
File System
Content may be at either location, but distributed so that frequently used content is close to its user
10
11
Single Repository With Multiple Content Servers Using Content Replication Documentum provides the ability to replicate content to one or more locations. This option entails a single repository with multiple content severs same as in the previous option. However, the content replication functionality will need to be used in this case as depicted in the following figure. The content is replicated from its source component to the remaining components by user-defined content replication jobs.
Content Server
Local Client
Remote Client
File System
WAN
File System
This model allows supporting the situation where the same piece of content is frequently accessed from multiple locations. Content In A Distributed Storage Area In this model, content is stored in a distributed storage area. A distributed storage area is a single storage area made up of multiple component storage areas. All sites in a model using a distributed storage area share the same repository, but each site has a distributed storage area component as its own local storage area to provide fast, local access to content. One component is located at the repositorys primary site, and each remote site has one of the remaining components. Each site has a full Content Server installation and an Application server (for Web-based clients) installation for the repository. The content is replicated from its source component to the remaining components by user-defined content replication jobs. This model can be used for either web-based clients or Desktop clients. Desktop clients at the remote sites use Content Server at the remote site to access content. In this configuration, metadata requests are handled by Content Server at the primary site, and content operations are handled by the distributed content servers at the remote sites as shown in the following figure.
12
Primary Site
Content Server Distributed Store Component 1 DMS
Web Server
Web Server
Web Client
Web Client
Figure 5: Single Repository with Distributed Storage In this model, users in Site 1 and Site 2 are closer to Remote Site 1 and will access the content stored in the distributed storage component 2 located at the Remote site 1 distributed content server, whereas users in Site 3 and site 4 are closer to Remote Site 2 and will access content stored in the distributed storage component 3 located at the Remote site 2 distributed content server. If the users are logging in using a Web-based client, content requests are handled through the Web server at the appropriate branch office in the Remote sites 1 or 2. If the users are logging in using a Desktop-based client, content requests are handled by the Content Server in Remote sites 1 or 2. Content Replication Content replication is a process of replicating content files among distributed storage area components. This process ensures that users at each site have local copies of the files to access. Content replication can be scheduled to run automatically or it can be performed manually. Automatic Replication The tools that can be used to replicate content automatically are: - ContentReplication tool The ContentReplication tool provides automatic replication on a regular schedule. It is implemented as a job. Once the parameters of the job are defined, the agent exec process executes it automatically on the preferred schedule. - Surrogate get feature The Surrogate get feature provides replication on demand. In this mode, when users request a content file that is not present in their local storage area, the server automatically searches for the file in the component storage areas and replicates it into the users local storage area.
13
Manual Replication To manually replicate content files, the following administration methods can be used: - REPLICATE The REPLICATE administration method copies a file from one storage area to another. The disks on which both component storage areas reside must be accessible to the server. IMPORT_REPLICA The IMPORT_REPLICA administration method imports a file from another component of the distributed storage area, or from an external file system into a storage area.
Both these methods can be executed from Documentum Administrator, the EXECUTE statement or the Apply method.
14
Multiple Repositories, Using Object Replication In this model, an actual and complete repository resides at each location. The repositories are synchronized with Documentum's Object Replication functionality. This ensures that when a new content is created, it is replicated to each location as shown in the following figure.
Central Site
Remote Site
Content Server
Local Client
Remote Client
Content Server
Database
WDK/App Server
WDK/App Server
Database
File System
WAN
File System
15
Multiple Repositories, Using Federation This option is similar to the above option; however, a Federation provides some additional functionality. In this option, multiple repositories are bound together to facilitate management of global users, groups, and ACLs. Users, groups, and ACLs are automatically propagated to all of the repositories of the federation from the "governing" repository.
Limitations
Same ? disadvantages as with the previous model, with some added complexity in setting up the Federation.
16
To know more about how we help companies in the High Tech Industry overcome their challenges to achieve real business results, Contact: hitech.marketing@tcs.com
All content / information present here is the exclusive property of Tata Consultancy Services Limited (TCS). The content / information contained here is correct at the time of publishing. No material from here may be copied, modified, reproduced, republished, uploaded, transmitted, posted or distributed in any form without prior written permission from TCS. Unauthorized use of the content / information appearing here may violate copyright, trademark and other applicable laws, and could result in criminal or civil penalties. Copyright 2008 Tata Consultancy Services Limited
www.tcs.com