Module 5

Repository Configurations

© 2005 EMC Corporation. All rights reserved.

Module Objectives

• Differentiate between a simple repository and a distributed

repository
• Differentiate between replicated content, and object
replication
• Set up proximity values
• Configure failover and load balancing

Repository Configurations 5-2

Single Server, Single Repository • Introduction to Distributed
Repositories
• Proximity Values
• Failover and Load Balancing
• Some Multi-Repository
Configurations

Client 1 Client 2 Client 3 Client 4

Seattle Seattle Seattle Seattle

• A single Content Server with a

single repository is used
Content
• It is the simplest repository
Server configuration
• However, many users accessing
a single repository slow down
Repository response time

Repository Configurations 5-3

Distributed Repository

Client 1 Client 2 Client 3 Client 4

Seattle Seattle Seattle Seattle

• Multiple Content Servers and a

Content Content
Server Server single repository is used to
distribute load
• With multiple Content Servers,
it is possible to
• Load balance user sessions
Repository • Place file content locally, where
needed (“distributed content”)

Repository Configurations 5-4

Challenge #1 (1 of 3)

Client 1 Client 2 Client 3

Seattle Seattle Milan

FAST! FAST! SLOW...

10 MB file 12 MB file

Content Content
Server Server Challenge: What if users in
Seattle Milan experience slow
download times for large
documents?
Solution: Store content files
Repository
close to the users that need
them!
Repository Configurations 5-5
Challenge #1 (2 of 3)

• Each Content Server stores files close to its users, for example
­ Italian-language documents stored in Milan
­ English-language documents stored in Seattle
• This example works well when users will primarily modify
local data
­ Milan users view/edit Italian-language documents stored in Milan
­ Seattle view/edit English-language documents stored in Seattle
• Advantage
­ Distributed content improves performance when accessing large
documents locally
• Challenges
­ Network bandwidth between remote Content Servers and local database
becomes more important
­ Distributed content requires a homogeneous Content Server
environment (All UNIX or all Windows)

Repository Configurations 5-6

Challenge #1 (3 of 3)

Client 1 Client 2 Client 3

Seattle Seattle Milan
12 MB file
FAST! FAST! FASTER!
10 MB file

Content Content
Seattle Server Server Milan

FASTER!
Documents
In English
Documents
In Italian
Database
Instance
(Seattle) Repository

Repository Configurations 5-7

Challenge #2

Client 1 Client 2 Client 3

Seattle Seattle Milan

FAST! SLOW! SLOW!

10 MB file

Content Content Milan

Seattle Server Server

Challenge: Milan users are

SLOW!
Database viewing large, documents in
Local Instance English stored in Seattle; the
(Seattle)
Content documents take a long time to
(Seattle)
load
Repository Solution: Use Content
Replication so that the
documents can be accessed
locally in Milan
Repository Configurations 5-8
Content Replication (1 of 2)
• To have content files stored locally in both the Seattle and Milan
Content Servers:
­ Create file storage areas in each location
­ Associate the file stores together as a distributed store
­ Create a Content Replication job to periodically copy files between storage
areas

Client 3
• When a client in Milan
Milan requests a file, and the file is
in a distributed store
Distributed Store
­ If the most recent copy is in
Milan, it is fetched from Milan

Replication
­ If the most recent copy is in
Seattle, it is copied from the
Seattle to the Milan file store
On demand copy, if needed
(dm_SurrogateGet method)
Seattle Milan

Repository Configurations 5-9

Content Replication (2 of 2)

Except for when files need to be copied from a far store, there is
quick performance for everyone!

Client 1 Client 2 Client 3

Seattle Seattle Milan

FAST! FAST! FAST!

Content Content
10 MB file Server Server
Seattle Milan

FAST! Database FAST!

Instance
(Seattle)
Replication
Content
Only

Repository
Repository Configurations 5-10
Challenge #3  Introduction to Distributed
Repositories
• Proximity Values
• Failover and Load Balancing
• Some Multi-Repository
Configurations

Client 1 Client 2
Seattle Milan

Seattle Milan Database request

Content Content Content request
Server Server

Challenge: How can an Administrator configure this

repository such that a client in Milan gets connected
to the Milan Content Server for content file requests
and to the Seattle Content Server for data requests?
Database Solution: The Administrator uses proximity values
Instance to make Milan the closest Content Server for
(Seattle) content requests and Seattle the closest Content
Server for data requests
Repository Configurations 5-11
Proximity Values (1 of 6)

• When the user selects a repository, the Documentum client

automatically connects to the closest Content Server for data
requests and for content file requests
• Sometimes, the Content Server that is closest for data requests
is not the same as the Content Server that is closest for content
file requests
­ In that case, two Content Server connections are made from the
client
• A connection to a Content Server for data requests
• A connection to another Content Server for content file requests

Repository Configurations 5-12

Proximity Values (2 of 6)

• Administrators configure Content Servers to project proximity

values to the connection broker
­ 0000 – 0999: a leading or absent zero indicates a Content
Server that can be used for data requests and content
requests
­ 9000 – 9999: a leading 9 indicates a Content Server that can
be used for content file requests
• Proximity values are stored in the server configuration object
(dm_server_config)

Repository Configurations 5-13

Proximity Values (3 of 6)

• The server configuration object can be set using DA or using DOCUMENTUM\

dba\config\<repositoryName>\server.ini
­ DA exposes the projection targets in the Proj Targets tab of the server
configuration object
• If the projection targets set in DA and server.ini conflict with each
other, the DA settings are used

Repository Configurations 5-14

Proximity Values (4 of 6)
• A connection broker determines how close it is to a Content
Server using proximity values
­ When setting up data connections, clients try connect to a Content
Server that has a ‘0’ in the thousandths position of the proximity value
­ When setting up content file connections, the connection broker
ignores thousandths position and looks at the other three digits only
• Example: For all clients that use espresso as their connection
broker:
­ Milan is used for content requests
­ Seattle is used for data requests
client
Seattle
0200
Seattle = 0200
Milan = 9001 9001
espresso Milan
Content
Content Server
Connection
Server
Broker
Repository Configurations 5-15
Proximity Values (5 of 6)

• Example: For all clients that use latte as their connection

broker:
­ Seattle is used for content requests
­ Seattle is used for data requests

client
Milan
9200
Seattle = 0001
Milan = 9200 0001
latte Seattle
Content
Content Server
Connection
Server
Broker

Repository Configurations 5-16

Proximity Values (6 of 6)
• Use dmcl.ini to make the client use the desired connection broker
• By directing the client (using dmcl.ini) to a particular connection broker,
it automatically connects to the “correct” Content Servers
­ client17 uses the connection broker on latte, which determines that the Content
Server Seattle is the closest for content and for data
­ Client84 uses the connection broker on espresso, which determines that Content
Server Milan is closest for content file requests and the Seattle Content Server is
the only (and therefore the closest) Content Server for data requests

client17 dmcl.ini client84 dmcl.ini

[DOCBROKER_PRIMARY] [DOCBROKER_PRIMARY]
host=latte host=espresso

latte Seattle Milan espresso

Seattle = 0001
Milan = 9200 Seattle = 0200
Milan = 9001
Content Content
Server Server

Connection Connection
Broker Broker
Repository Configurations 5-17
Proximity Values – Example 1

• If the primary Content Server is in Seattle and there are

additional Content Servers in New York and Milan, what will
the dm_server_config object contain in Seattle?
host=Seattle
proximity=X001 Connection Broker
Seattle

host=New York
20
proximity=X020
Connection Broker
host=Milan New
York 200
proximity=X200
150
• What is the value of each X?
Connection Broker
Milan

Repository Configurations 5-18

Proximity Values – Example 2

• If the primary Content Server is in Seattle and there are

additional Content Servers in New York and Milan, what will
the dm_server_config object contain in New York?

host=New York Connection Broker Seattle

proximity=XXXX
20
host=Seattle
proximity=XXXX Connection Broker New
York 200
host=Milan
proximity=XXXX 150

• What is the value of each X? Connection Broker

Milan

Repository Configurations 5-19

Content Server Failover  Introduction to Distributed
Repositories
 Proximity Values
• Failover and Load Balancing

• When a client session is disconnected from the

• Some Multi-Repository
Configurations

Content Server due to time out or Content Server failure, with

four exceptions, the client reconnects to a backup Content
Server seamlessly
• The exceptions:
­ If the client was waiting for search results, the search will have to be re-
initiated
­ If a content transfer is occurring between the client and the Content
Server, the content transfer must be restarted from the beginning
­ If the client had an open database transaction when the disconnection
occurred, the transaction is rolled back and must be restarted from the
beginning
­ If the original connection was started with a single-use login ticket or a
login ticket scoped to the original server, the session cannot be
reconnected to a failover server because the login ticket may not be re-
used

Repository Configurations 5-20

Challenge #4
• When there are a large number of users in a
repository, it may be beneficial to have
­ Multiple Content Servers on hand for failover
• If one Content Server goes down, one of the other Content
Server can seamlessly pick up its user sessions
­ Multiple Content Servers handle user sessions (“load
balancing”)
• Challenge: In a distributed repository environment with 2
Content Servers, how can the Administrator configure the
environment to use failover and load balancing?

Repository Configurations 5-21

Solution #4 (1 of 2)

• Install one connection broker for each Content Server

• Make each Content Server project to both connection brokers
• Using projection targets, make one Content Server appear to be
farther than the other for half of the user community
• Using projection targets, for the other half of the user
community, make the other Content Server appear to be closer
• Configure dmcl.ini to have a backup connection broker (see
next slide)

Repository Configurations 5-22

Solution #4 (2 of 2)
daisy hyacinth
Content Content
Server Server

0001 9001
9010 0010
a1 a2
Connection Connection
Broker Broker

dmcl.ini dmcl.ini
[DOCBROKER_PRIMARY] [DOCBROKER_PRIMARY]
host=a1 host=a2

[DOCBROKER_BACKUP_1] [DOCBROKER_BACKUP_1]
host=a2 host=a1

FirstFloorUsers SecondFloorUsers

Repository Configurations 5-23

Failover – WDK Applications (1 of 3)

• In clustered environments, WDK supports session failover to

other web application servers running the same WDK
application
­ Enables WDK to work in clustered web application server environment
• This environment includes additional web application servers (to
serve as failover servers) and a load balancer
­ Allows the user to continue working in WDK even in the case of a web
application server crash
• Transparent failover detection and recovery
­ All user preferences, the current view, current browsed location, are
preserved and restored in case of an web application server crash
• Targets enterprise customers with a large number of WDK
application users
­ If the main web application server goes down, the failover web
application server can seamlessly handle the client user sessions

Repository Configurations 5-24

Failover – WDK Applications (2 of 3)

• The administrator can enable or disable failover on a per-

application basis
­ This feature is supported in custom WDK applications and Webtop
­ By default, failover support is enabled
• Available in WDK 5.3 for Properties and Navigation
components
• In case of a web application server crash, the load balancer
mechanism will route the request to the secondary web
application server
­ Primary session state is on the server to which the client first connects
­ The session state is replicated to the secondary web application server
­ If the primary server goes down, the secondary server is used
• During failover recovery, the WDK infrastructure
­ Reinitializes user preferences, current location
­ Notifies components to perform cleanup operations
Repository Configurations 5-25
Failover – WDK Applications (3 of 3)

• Not all WDK components support failover

• Supported WDK Components:
­ Navigation (including drilldown components)
­ Properties (including view/update properties)
• If a WDK component does not support failover
­ Its state will not be replicated
­ In case of a web application server crash, the user view is
returned to the home page
­ Any changes made inside the component are lost

Repository Configurations 5-26

Disabling/Enabling WDK Application Failover

• Failover is enabled by default

• To disable failover
­ Edit the app.xml file in the custom directory for the desired WDK
application
• For example, for Webtop, app.xml is located in:
/<application_server>/webapps/webtop/custom/app.xml
• Modify the file, as shown below:

Inside the application

element, add the failover
element and the enable
element (set to false)

­ Re-start the web application server

Repository Configurations 5-27
Object Replication (1 of 2)  Introduction to Distributed
Repositories
 Proximity Values
 Failover and Load Balancing
• Some Multi-Repository
• Objects – that is, properties and content – are Configurations

copied from one repository to another repository

• Clients use a single repository for data and content file requests
• Object replication allows users in different locations to have
fast access to the same document
• Replicas can be checked out and modified
– When checked out, the source object is checked out also
– When checked in, the source object is updated to reflect any changes in
properties or content

Repository Configurations 5-28

Object Replication (2 of 2)

Client 1 Client 2 Client 3

Seattle Seattle Milan

10 MB file
FAST! FAST! FAST!
Seattle Milan

Content Content
Server Server

Master Replica
Updates

Replication
Content
and
Seattle Properties Milan Repository
Repository
Repository Configurations 5-29
Multi-Repository Configurations

Seattle Seattle Milan

European Sales
North American Corporate Repository
Sales Repository Repository
Tokyo
• Administration Challenge:
How to manage multiple users,
groups and associated permissions Asian
sets accessing several repositories? Sales
• Solution: Repository
Use a repository federation
Repository Configurations 5-30
Repository Federations

• A group of repositories bound together to manage global users,

groups, and external permission sets
• One repository in the federation is defined as the governing
repository on which changes are performed
• Automatic jobs then propagate changes to other repositories
known as member repositories

Governing Repository Member Repositories

European
Corporate
Sales

Asian
Federation A
Sales

Repository Configurations 5-31

 Summary  Introduction to Distributed
Repositories
 Proximity Values
 Failover and Load Balancing
 Some Multi-Repository

Repository Configurations Configurations

Simple Repository Federated Repository

Single Repository Multiple Repositories
Distributed
Seattle Milan
Content Content
Content
Seattle

Single Repository Replicated Objects

Multiple Servers Distributed Content Multiple Repositories
Single Repository

Seattle Milan
Content Content Seattle Milan
Seattle Milan Content Content
Content Content

Repository Configurations 5-32

Test Your Knowledge

1. What purpose do proximity values serve?

2. What does the ‘9’ signify in the proximity value 9001?
3. What is a repository federation?

Repository Configurations 5-33