On-Site Process Servers

on-site-related topic

You can use Process Servers to perform the following activities on a computer inside your network.

  • Run operating system (OS) processes.
  • Watch for file events.
  • Observe the system load.
  • Act as file servers for OS process files.

To perform such activities, you must install a Platform Agent on the computer. The Platform Agent then makes the specific OS system calls required for running OS processes and monitoring the system.

A Process Server communicates with a Platform Agent over the TCP/IP network using the HTTP or HTTPS protocols. The illustration below shows a Process Server (bottom) communicating over TCP/IP with several Platform Agents running on various platforms.

To configure a Process Server to run OS processes via a Platform Agent, you must both set up the Process Server and install and configure the Platform Agent.

The Process Server is a logical object in the central RunMyJobs server. It uses two threads: one for sending messages to the Platform Agent, and the other is for processing messages coming from the Platform Agent. To configure a Process Server, use Process Server Parameters.

Tip: When installing a Platform Agent on an SAP application server, Redwood recommends naming the Process Server <SID>_<APP_SVR>_PlatformAgent, where <APP_SVR> is the hostname of the application server.

You can configure overall settings for all Platform Agents with Platform Agent Registry Entries.

A Platform Agent consists of a number of different executables and/or scripts, each playing their own role. How these interact is documented in more detail in the pages below, but in general there are usually at least the following programs:

  • network-processor is the program that is responsible for communicating with the central RunMyJobs server.
  • (UNIX, Windows, OpenVMS) job-processor is the program that is responsible for a single process. When a process starts, an instance of the job-processor starts.
  • jtool and derivatives form the Command-Line System Tools.

For more details see:

Platform Process Servers that schedule workload or use file events require at least one of the following keys:

  • ProcessServerService.External.limit: The total number of external Process Servers (Platform Agents, distinct web service endpoints, and SAP connectors).
  • ProcessServerService.OS.limit: The total number of Platform Agent Process Servers.

Monitoring-only Process Servers on Windows and UNIX are free of charge, but they must have the PlatformAgentService service and they cannot have any Definition Types or file events.

Support for Networked File Systems

This section describes RunMyJobs' support for Platform Agents in networked file systems. In this context, the term networked file system means NAS systems, also known as SMB X/NFS/SSHFS file shares.

Note: You must install Platform Agents on a local file system. SAN file systems may be considered local (if they are mounted as iSCSI, for example). NFS and Windows shares are not supported because they may not be available at all times.

On Windows computers, the installation directory and DataRootDirectory must be located on a local file system.

On UNIX computers, the installation directory can be on a network share. If the DataRootDirectory is on a non-local file-system, the following restrictions apply.

  • The network file share should support UNIX file modes such as setuid and setgid bits, or restrictions may apply to user switching.
  • The default mechanism for detecting locked files will not work. A workaround that uses file age is available.

Tip: If a Process Definition needs to store and manage large files, you can link files from outside of the DataRootDirectory.

Note: Performance on a network file system will be substantially slower, due to the additional networking overhead when accessing files over the network.

Agent Connection

RunMyJobs communicates with a Platform Agent (the network-processor process, to be exact) via a TCP connection with the HTTP protocol. A Platform Agent is always contacted by the central RunMyJobs Java server, and not the other way around. In other words, in terms of the TCP/IP connection the Platform Agent is the server and the central RunMyJobs server is the client. This way, you do not have to enable any incoming TCP ports on the central RunMyJobs Server to schedule processes on a computer behind a firewall.

The default installation procedure also establishes secrets. These secrets are a simple form of key that ensure that a particular Platform Agent only talks to the Java server that is in possession of the same secret. Message data is also protected by a hash value. The combination of these measures makes it very hard for an attacker to falsify the communications and act as a Java server.

If, however, you need to protect the content of the data connections as well, you need encryption. To encrypt content, you need an optional layer that is available only directly from Redwood, because it contains some third-party source code. For more information, see Secure Agent Connections.

Overriding Process Server Default Values

You can override Process Server parameter default values globally by setting the following registry entry:

/configuration/ProcessServerParameters/<name>

Here, <name> is the name of the Process Server parameter you want to set a default for.

Note: This registry entry only affects default values. If you specify a Process Server parameter directly, that value will have precedence over the value of the registry entry.

Note: Only the scheduler-isolation-administrator can create and edit these registry entries.