2.1.3. Running Jobs in a Distributed Environment

Engineering Knowledge Manager

Administration Guide | Chapter 2: Overview of Servers and Workspaces | 2.1. Distributed Servers and Workspace Access |

2.1.2. Setting Up Caching |  | Chapter 3: Setting Up Users and Groups
Prev |  | Next

### 2.1.3. Running Jobs in a Distributed Environment

In a multi-region deployment, each region may have its own resources for running batch and interactive jobs. Each regional EKM server can be configured to use its own local scheduling configuration while sharing one common set of centrally-stored data. This is accomplished by setting up Master and Slave workspaces.

Figure 2.4: Master and Slave EKM Server Setup

#### 2.1.3.1. Slave Workspaces

A Slave workspace is a specially configured workspace without any data stored locally. All of its data resides in an associated workspace on another EKM server, which is referred to as the Master EKM server. A server that contains a Slave workspace is referred to as a Slave EKM Server. The workspace on the Master EKM Server will be referred to as the Master workspace.

##### Limited Functionality

A Slave workspace provides a subset of the functions available in a standard EKM workspace. Users will be working in a limited environment similar to the job-only view.

When a workspace is configured as a slave:

- The Home, Data and Processes sections are not available.

- The applications panel is not available.

- The EKM repository is not accessible.

- The preferences available in the Settings dialog box are streamlined to show only settings that are applicable to job objects and job management.

- When downloading server files to the Master repository, progress can be monitored using a Transfer Progress dialog box, as described in Monitoring Transfers from Slave Servers to a Master Server.

In a Slave workspace, users and administrators can:

- Run jobs.

- Transfer files from the job working directory to the Master repository.

Note:

- Slave workspaces are not intended for users with `Basic` access. For information about different access types, see Licensing and Access.

- `Admin` users will still have access to the Administration section in a Slave workspace.

- In a Slave workspace, you cannot transfer files between your local disk and the Master repository, and vice versa. All file transfers are between the Master repository and job working directories.

#### 2.1.3.2. Running Jobs in a Slave Workspace

No data can be stored in a Slave workspace, so all data will be accessed from a corresponding workspace on the Master EKM server.

Rather than using the File Transfer Client to get files, which always requires users to log in on the Master EKM server, users are able to sign in directly to their local regional EKM server (the Slave EKM server). The EKM administrator will configure workspaces on a Slave EKM server to point to associated workspaces on a Master EKM server.

Conveniently, users who sign in to the Master server will also be able to easily run a job in a Slave workspace. See Running Jobs on Slaves from a Master Server.

When you are signed in to a Slave workspace, and accessing data in that workspace, (My Data or Shared Data), the data will in fact be coming from a different EKM server (the Master). However, the experience is seamless, and EKM behaves in the same way that it does in a standard deployment.

When starting a job on a Slave server, and choosing files and folders from the repository to be used for the job, EKM will actually upload those files and folders from the Master EKM server’s repository to the Job Data Directory configured on the Slave server. (Note that this directory is not necessarily on the Slave itself, but rather a directory that is visible to the cluster.)

When a job has completed, you can choose to download files from the job’s working directory to the repository, just as you can in a standard EKM deployment:

But in this case, those files will be downloaded from the Job Data Directory configured on the Slave to the EKM Master server. The Slave workspace contains no data, so the job data will be downloaded to the EKM Master server and imported into the Master workspace. A Transfer Progress dialog box will be displayed to monitor the status of the transfer. For details see Monitoring Transfers from Slave Servers to a Master Server.

#### 2.1.3.3. Caching in a Master-Slave Configuration

As mentioned in the previous section, data needs to be transferred back and forth between the Master and Slave EKM servers in a Master-Slave configuration. To improve performance, all data transferred will be automatically cached on the Slave EKM server. This is similar to the caching that takes place when transferring files via cache servers.

Once some jobs have been run and files from the Master server’s repository have been transferred to folders under the slave’s EKM Job Data Directory, data will begin to populate the cache workspace on the Slave server. If a user starts a job that requests files from the Master workspace, and those files have been used for a previous job, EKM will be able to access those files locally from the cache workspace and skip the transfer from the Master, provided that the content of the Master copy has not changed.

Over time, performance will become similar to that of a standard EKM setup, where data is exported from the EKM repository to the Job Data Directory. In this case, data will be exported from a cache workspace on the Slave to the Job Data Directory configured on the Slave. Files downloaded to the Master workspace at the end of a job run will also be written to the cache workspace to keep the cache workspace up-to-date.

#### 2.1.3.4. Running Jobs on Slaves from a Master Server

It is possible for users who have signed in to a workspace on the Master EKM server to run jobs on any slave workspaces associated with that Master workspace. This is an optional convenience that requires some additional configuration should you wish to implement it. This configuration is ideal if you have users who need to work directly with repository data and perform tasks other than job submission on the Master server.

Whether you choose to configure EKM this way or not, users can always sign in to their regional Slave servers and run jobs from there, as described in Running Jobs in a Slave Workspace.

To enable users who are signed in to a Master workspace to run jobs in Slave workspaces, you must sign in to the Master server and define a new cache server. See Creating a New EKM Cache Server.

When you enable jobs to be run on Slave servers from the Master server, users who are signed in to the Master server will see a new option on the Execute menu when they start a job from a repository file (see Starting a Batch Job from Repository Files). This option will enable users to select a Slave workspace for the job:

#### 2.1.3.5. Authentication in a Master/Slave Setup

##### Sign-In to the Master from a Slave

When users sign in to a Slave workspace, EKM will automatically sign them in on the Master server so that they can access the Master workspace data. This sign-in will occur transparently. Also, when users sign out of the Slave workspace, they will be signed out of the Master workspace automatically.

By default, the credentials used to sign in to the Slave workspace are used to sign in to the Master workspace. If a user's Slave credentials cannot be used to sign in to the Master, that user will need to sign in to the Slave workspace and specify a credential override for the Master workspace in the Connections dialog box.

For example, if Slave server `ekmslave1` is configured to point to the `Default` workspace on Master server `ekmmaster`, and the credentials that John Smith uses to sign in to `ekmslave1` (for example, user name = `jsmith`) are not valid for accessing `ekmmaster`, then John must sign in to `ekmslave1` and create a connection that specifies the URL of the Master server, the workspace that contains the central repository, and credentials needed to access that workspace (for example, user name = `johnsmith1`):

For more information see Defining Connections to Other Repositories.

##### Sign-In to a Slave from the Master

When users sign in to a Master workspace, they have the option of running jobs in any Slave workspace that is configured to use that Master workspace. See Running Jobs on Slaves from a Master Server.

By default, when a user chooses to run a job on a Slave, the credentials used to sign in to the Master workspace are used to sign in to the Slave workspace. If a user's Master workspace credentials cannot be used to sign in to the Slave workspace, that user will need to sign in to the Master workspace and specify a credential override for the Slave workspace in the Connections dialog box.

Following the example above in Sign-In to the Master from a Slave, if John Smith signs in to `ekmmaster` using his credentials for the Master workspace (user name = `johnsmith1`), and then chooses to run a job on `ekmslave1`, the credentials he used for signing in to `ekmmaster` cannot be used to sign in to `ekmslave1`, because the credentials needed to sign in to `ekmslave1` are different (user name = `jsmith`).

John will need to sign in to the Default workspace on `ekmmaster` and create a connection that specifies the URL of the Slave server, the workspace in which he wants to run jobs, and the credentials needed to access that workspace (user name = `jsmith`):

For more information see Defining Connections to Other Repositories.

Note: The sign-in/sign-out behavior in this scenario is different than the behavior exhibited when you are accessing the Master server via a Slave. When starting a job on a Slave via a Master server, you are signed in to the Slave server on a new browser tab, just as if you had signed in to the Slave workspace directly. Also, you will not be signed out of the Slave workspace automatically. You must sign yourself out of the Slave workspace when finished.

#### 2.1.3.6. Steps for Setting Up a Master/Slave Configuration

If you would like to create a multi-region deployment in which users can run jobs on Slave servers using data from a central Master repository, follow the steps below.

1. Install and start EKM on the machine that will be designated as the Master server. This is where the central data repository will reside.

2. Install and start EKM on each machine that will serve as a Slave server.

3. On each Slave server, perform the required steps to set up batch job submission on that server. If the Master server will also be used to run jobs, set up batch job submission on that server as well.

4. For each Slave server, sign in to the workspace where jobs will be run, then start restricted configuration. Edit the WorkspaceConfig.xml file to point the Slave workspace to the Master workspace that contains the central data repository. Refer to Associating a Master Workspace with a Slave Workspace.

5. (Optional) If users will be signing in to the Master to run jobs on Slaves, as described in Running Jobs on Slaves from a Master Server, sign in to the Master and create a cache server definition. Refer to Creating a New EKM Cache Server. This step is not required if users will only be signing in to Slaves to run jobs.

6. Individual users may need to specify credential overrides for the Master or Slave servers. For more information see Authentication in a Master/Slave Setup.

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.