MFT Platform Server in A Clustered Windows Environment

Installing MFT Platform Server in a
Clustered Windows Environment

March 12, 2013

Installing MFT Platform Server in a Clustered Windows Environment

Copyright 1995 - 2013 TIBCO Software Inc. All Rights Reserved Page 2 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

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MFT Platform Server in A Clustered Windows Environment

Uploaded by

Copyright:

Available Formats

Installing MFT Platform Server in a

Clustered Windows Environment

You might also like