mft platform server in a clustered windows environment

Installing MFT Platform Server in a Clustered Windows Environment

March 12, 2013


Copyright © 1995 - 2013 TIBCO Software Inc. All Rights Reserved of 6 Updated: March 12, 2013

1. Introduction This document is intended for customers requiring redundancy in production TIBCO MFT

Platform Server environments. It is assumed that the reader has a basic understanding of the

MFT Platform Server and how it is installed on traditional systems. It is also assumed that the

reader has a basic understanding of certain concepts related to high availability including load

balancing, operating system clustering and data replication. These components will be required

in order to build a highly available environment.

The following TIBCO products will be discussed:

TIBCO® Managed File Transfer Platform Server for Windows

2. Requirements for Platform Server Clustering Verify the following requirements before installing Platform Server in a clustered environment:

The Platform Servers must be installed on a clustered operating system and configured in

an Active/Passive mode.

Certain Platform Server application configurations must be identical on each node

(Windows only - more information can be found in the guides listed below).

The Platform Servers must all read and write to the same shared storage file system. It is

recommended that the shared storage be mirrored or backed up in the event of disk

failures.

a. Directory structures and mount points of shared storage mounts should be

identical on both Platform Servers in the cluster.

b. If mounts are being used for external storage, TIBCO recommends using two

separate mounts.

1) One for the Platform Server application itself. Generally an ISCI mount is

used to house the Platform Server application files.

2) One for the data being stored by Platform Server. Generally an ISCI

mount or UNC share path is used to house flat files being transferred by

Platform Server.



3. Background The example procedure used in this document is based on Microsoft Windows 2000 Advanced

Server, with clustering hardware attached. The general concept and procedure should also apply

to other Windows systems. For the purposes of this document, a cluster is composed of one or

more physical servers with shared storage that can perform common tasks. Should one server

stop functioning, a process called failover will shift its workload to another server to continue

processing.

How it works in simple terms:

Assume the following scenario. Node A and Node B are components of a two node cluster called

Server C. This is shown in the following diagram:

Server C

192.168.200.3

Node A

192.168.200.1

Node B

192.168.200.2

The cluster may be accessed as Server C or by its IP Address of 192.168.200.3. External

applications do not need to know that Server C is a clustered virtual server. Therefore if Node A

was to fail or be taken out of service for maintenance, applications on the cluster would still

function and respond to requests. All services running on Node A would be smoothly

transitioned to Node B, or vice versa. Additionally, each node may have its own local storage,

where the operating system and applications can be installed. In addition, there are shared data

areas where application data is shared between the nodes in the event of a failover.

In the event of a failover, application processing is transferred automatically from the primary

server to the failover server without any intervention from MFT Platform Server.



4. Installation In order to configure Platform Server for a clustered environment, perform the following steps:

1. Install MFT Platform Server on the local disk of the first cluster node.

2. Apply a license key to each node based on its own node name, not the cluster name.

3. Modify the following registry entry for the PQF file:

a. Locate the following Registry Key:

HKEY_LOCAL_MACHINE\SOFTWARE\TIBCO\MFT Platform Server

Server\QueueManagerService\

b. Create or Edit if necessary the following Registry Value to reflect a file name on

the shared disk:

PersistentQueueFile: This should be set to a file name on the shared file

system in the event that a failover should occur, the other node can access

this PQF file.

4. Update the global configuration on the “Server Properties” page with any required

Platform Server configuration.

5. Open the MFT Platform Server Administrator

a. Highlight the Server Name

b. Click Server Properties

c. Click on the Responder Tab

d. Under Listen Adapter IP Address, fill in the IP Address of the Cluster (In our

example you would use 192.168.200.3)

e. Under Connect Adapter IP Address, fill in the IP Address of the Cluster (In this

example you would use 192.168.200.3)

f. Click on the Trace Tab

g. Click on the Log File Tab

h. Ensure the Enable Web Logging box is checked

i. Make sure the File Name points to a file name on the shared disk

j. Click OK

6. Repeat steps 1-5 for each node in the cluster.

7. Create required Platform Server nodes, responder profiles and profiles on node 1. A

description of how to do this can be found in the Platform Server for Windows guide.

8. Copy the Platform Server node, responder profile and profile configuration files from

node 1 to the remaining cluster nodes. These files are named cfnode.cfg, cfrprofile.cfg

and cfprofile.cfg and are located in the base directory where Platform Server is installed

(for example C:\Program Files\TIBCO\MFT Platform Server\).

9. Restart the Service on each node.

If SSL support is required in the clustered environment, perform the following steps:

1. Submit a single certificate request for all nodes in the cluster.

2. Request a CN of Server C rather than each individual node.

3. Copy the following files to all other nodes within the cluster once the Certificate Request

has been processed/signed:

a. Certificate

b. Private Key File

c. Trusted Authority File



4. Open the MFT Platform Server Administrator

5. Click on Configure->SSL

6. Enter the following information in the GUI provided

a. Click “Check Client Certificates”

b. Enter private key password

c. Enter Certificate File Name

d. Enter Private Key File Name

e. Enter Trusted Authority File Name

7. Click OK

5. Configuration

Every node of Platform Server must have identical application configuration. The

following settings need to be configured identically on each node (these are included in

the steps listed above):

All global Platform Server settings must be identical. For Windows, these are

found in the “Server Properties” section in the Platform Server Administrator.

Any scripts or software necessary to perform post processing should be located on

all PS nodes.

Platform Server nodes, profiles, responder profiles

Operating system usernames, passwords and groups being used by Platform

Server. It is recommended to use a domain user to ensure that the passwords are

always in sync on each node.

DNI templates. These are stored in the ftmssvr.pqf file.

Transfer templates. These are stored in the ftmssvr.pqf file.

Any mount point being used by the Operating System

Any environmental variables or user profiles that have been configured

Settings for nodes, profiles, responder profiles and transfer definitions can be more easily

managed from the TIBCO MFT Command Center. Refer to the document below for

more detailed information:

MFT High Availability.pdf



6. Performing Service Failover on the Cluster The following items should be considered when performing Active/Passive failover.

Only one MFT Platform Server Service should be running at any given time.

The MFT Platform Server service has a dependency of a shared disk (The shared

data disk must be mounted or added to the operating system before the MFT

Platform Server service is started).

The shared data disk should only be mounted to one cluster member at a time.

The MFT Platform Server service will give a failure when starting if the shared

disk is not mounted.

7. PQF File Platform Server contains a file called a PQF file. Understanding the contents of this file

is essential to configuring high availability for Platform Server.

The PQF file holds the following information:

Checkpoints for Checkpoint Restart

Transfer queue information

DNI Templates (Platform Server for Windows only)

Transfer Templates (Platform Server for Windows only)

When an Active Platform Server is performing file transfers, it is using the PQF file to

store this information. On most Windows file systems, Platform Server will hold a lock

on this file while the file is being written. This means that only one Platform Server can

be active at any given time in a highly available environment.

If the Active Platform Server fails, the Passive Platform Server will take over and use a

PQF file that is located on shared storage to continue queued transfers and checkpoint

restarting. When this occurs, the first Platform Server service must be stopped

completely so that it will no longer hold a lock on the PQF file.

mft platform server in a clustered windows environment

Documents