Configuring Platform Agents on Microsoft Cluster Service

note

Scheduling workload or using file events on Microsoft Windows process servers is only possible when your license includes a non-zero value for the license key ProcessServerService.OS.limit. The value of this key determines how many active platform agents (across all platforms) you can run. You may create an unlimited number of monitoring only platform agents.

Using Microsoft Cluster nodes you can create a platform agent that has the same availability characteristics as the Microsoft Cluster. When the node of the platform agent fails or becomes unreachable its service is moved by Microsoft Cluster Service to a backup node.

Cluster Fail Over

• Processes that are executing when the cluster node moves will be reported as Unknown; the system does not know what happened to them.
• A process that finishes immediately before the cluster node moves will get a proper status update to Completed, Error, or any other final status code (except Unknown ), when the job-processor still had access to the physical disk at the time when the process finished. If the physical disk resource was already disabled or moved to the winning node in the cluster the process status will be lost and the process will get status Unknown.

Platform Agent Network Timeout

A network timeout has been introduced to solve networking issues, when no message has been received in at most twice the MessageInterval, the platform agent will attempt to reconnect.

Cluster Services and Auto Update of the Platform Agent

Auto-update will update one cluster node at a time. Suppose that cluster node A is in operation when the system is updated. Only the service on node A will be updated. Only when the cluster fails over to node B will the service on node B be updated.

Installation

• Install the agent in the same directory on the Windows disk drive or another "fixed" path that is identical on all nodes. For example, if you install the agent in C:\\Program Files\\Redwood\\Agent then you must install it in this path on every node.
• Create an instance. Give this instance the same name and port number on all nodes.
• Create an instance. Give this instance the same name on all nodes.
• Do not register the agent.

After you have installed the agents, ensure that the configuration data is identical, in particular the secret. The standard installation generates different secrets on every node, so you need to override these. This configuration data can be found in the net subdirectory relative to where you installed the agent.

It is probably easiest to stop all platform agent instances and copy the ${InstallDir}\net\instance\${Instance} directory. The DataRootDirectory where configuration and output files are stored as well as the installation directory must not reside on a NAS (NFS or SMB share); a SAN will be considered local if it is mounted via iSCSI, for example.

note

Redwood recommends strongly against installing the software on a networked file system. If this recommendation is ignored, and you have random errors that Redwood believes are caused by the NAS (NFS or SMB share), that Redwood cannot reproduce on local storage, you will be required to demonstrate that the issue can be reproduced when installed on local storage. The resolution to this issue may require that you reinstall on local storage.

Prerequisites

To create a service that is managed by the Microsoft Cluster Service you need:

• A Microsoft Windows Server cluster consisting of at least two nodes.
• A shared physical drive that is available on those nodes.

Procedure

1. Install the Redwood Server Platform Agent on all nodes in the cluster, see Creating a Microsoft Windows Process Server (Advanced) for details. Install the product using the guidelines in the Installation section above. Ensure you create a process server in the central Redwood Server, such that it uses the cluster IP address and sets DataRootDirectory to a directory on the shared physical drive.
2. Use the Microsoft Cluster Administrator software to add a new resource that is in the same group as the cluster IP address and shared physical disk. Ensure that the platform agent is made dependent on both resources.
3. Start the platform agent (scheduler) resource. The cluster group will show that the Scheduler is off-line. Bring the Platform Agent online. Move the cluster group to a different node to verify that the platform agent service can run on all nodes.
4. Start the process server. Using the Redwood Server ui, start the process server. After a few moments the scheduler should go to the Running status. If not, check the operator messages. To verify that everything works, submit and run a process. Move the cluster group to a different node. Run another process. Both processes should run successfully, but make sure they ran on different nodes.

Values

Here is an example of the data that is filled in

• New Resource

  Name: Scheduler platform agent <instance>
  Description: Redwood Server Scheduler platform agent
  Resource Type: Generic Service
  Group: Suggested: same group as the IP address and physical disk

• Possible Owners

  Add the nodes in the cluster that have the platform agent installed.

• Dependencies

  Add the Cluster IP Address and the physical disk.

• Generic Service Parameters

  Service name: jcs_<instance>   (MUST be already present on the nodes set in Window 2)
  Start parameters: Empty.

• Registry Replication is not needed, choose Finish.

See Also

• Configuring Platform Agents on Windows
• Configuring Load Balancing on Platform Agents
• Automatically Updating Platform Agents
• Securing Communications for Platform Agents and System Tools
• Creating a Monitoring Platform Agent
• Monitoring External Systems with Platform Agents

onsiteTopic