Chapter 2: Overview of Servers and Workspaces

Engineering Knowledge Manager

Administration Guide |

1.1. Path Variables |  | 2.1. Distributed Servers and Workspace Access
Prev |  | Next

## Chapter 2: Overview of Servers and Workspaces

EKM provides many ways to structure your information and manage multiple workgroups that are spread across multiple locations. Two concepts are defined in EKM for this purpose:

- EKM Server: A server that is a single installation of EKM whether it is clustered or not. For a clustered installation, all nodes are considered as a single server.

- Workspace: A partition of an EKM server that can contain its own data model, users, and groups. When you sign in to EKM, you sign in to a workspace on the EKM server.

Every EKM server contains one default user-accessible workspace with a repository for data. More workspaces can be created if needed. When you set up a workspace you determine who can access it, and specify the permissions that each user has in that workspace. Every EKM server also has a hidden workspace for caching data from remote servers. This workspace may be involved in file transfers when data is downloaded from or uploaded to a remote EKM server using the File Transfer Client.

Figure 2.1: Default Composition of an EKM Server

## Planning Server Installations

A single EKM server is sufficient if all users are located close to each other in the same region. But if a substantial number of users are accessing EKM from remote offices over a WAN and the connection speed between the offices is significantly impacting the data transfer rate, then multiple EKM servers can be installed (see Figure 2.2: Multiple EKM Servers in a Global Setup). The recommended architecture in this case is to use a “master” server, that will contain globally shared data, and to have a number of regional servers. You could have one regional server for each remote office or share a regional server with several closely located remote offices. Regional servers provide the following benefits:

- Data Cache: Any file uploaded to, or downloaded from, the master server from a remote office will be cached in the regional server. If the file does not change on the master server, then any subsequent download of that file from the remote office can be processed by the regional server without requiring a data transfer from the master. If the file is changed, then it is downloaded and cached again in the regional server.

- Asynchronous Uploads: When a user in a remote office uploads data to the master server, it is first stored in the regional server, which then uploads the data to the master server on the user’s behalf. This enables users to quickly and asynchronously transfer large amount of data to the local server and sign out or disconnect from their machine, without waiting for the full transfer to be complete.

- Regional Workspaces: If users in a remote office want to use EKM to collaborate among themselves without incurring the latency of transferring data to or from the master server, they can create a workspace in the regional server. These users can then directly sign in to the regional server, bypassing the master server altogether. This feature should be used with caution because it can cause data to be isolated and impede the sharing of data between users and groups belonging to other offices or regions. Therefore, these workspaces should be used only if the data being stored in regional servers is only relevant to the local users and will not be generally used by others in the company. For more information about workspaces, see How Workspaces are Used.

A detailed overview of regional servers and how they can be used for caching is provided in Distributed Servers and Workspace Access.

## How Workspaces are Used

Workspaces are primarily used as independent data partitions that can be configured independently of each other and that contain their own set of users and groups. Data from one workspace is not visible to, and cannot be accessed from, another workspace. This way, workspaces can be viewed as independent islands of data. Each server will have at least one production workspace that contains the primary data and user accounts, but additional workspaces can be created as explained in Creating and Managing Workspaces. Some of the reasons for creating additional workspaces are highlighted below:

- Sandbox: Users and groups that are new to EKM may want to get acquainted with the system through a dummy workspace. This workspace provides a sandbox for such users to experiment with usage, data entry and other features of EKM without worrying about the constraints imposed by a production workspace.

- Test: Configuration changes, such as edits to object lifecycles and custom data types, can be made dynamically in a workspace. But such changes usually require some iteration and review. Having a separate test workspace for this purpose enables administrators and other stakeholders to experiment with configuration changes without disturbing the production workspace.

In general, workspaces should not be used as a security mechanism to provide different groups in a company with their own private space. Data isolation can be achieved in a single workspace through the use of groups, per-user access level assignments, and object-level permissions. Multiple workspaces increase management overhead and impede the sharing of data between users and groups belonging to different workspaces. Even if data sharing is not a short-term requirement, it may become an issue in the long term.

Contains proprietary and confidential information of ANSYS, Inc. and its subsidiaries and affiliates.

Prev | Up / Contents | Next

Release 18.2 - © ANSYS, Inc. All rights reserved.