Plan the configuration of a server farm

A server farm is composed of multiple stand-alone application servers not federated or administered by a managing component of an application server.

MobileFirst Server internally provides a farm plug-in as the means to enhance an application server so that it can be part of a server farm.

When to declare a server farm

Declare a server farm in the following cases:

• MobileFirst Server is installed on multiple Tomcat application servers.

• MobileFirst Server is installed on multiple WebSphere Application Server servers but not on WebSphere Application Server Network Deployer.

• MobileFirst Server is installed on multiple WAS Liberty servers.

Do not declare a server farm in the following cases:

• The application server is stand-alone.

• Multiple application servers are federated by WAS ND.

Each time a management operation is performed through the operations console or through the administrative services application, the operation needs to be replicated to all instances of a runtime environment. Examples of such management operations are the uploading of a new version of a wlapp or of an adapter. The replication is done via JMX calls performed by the administrative services application instance that handles the operation. The administration service contacts all runtime instances in the cluster. The runtime can be contacted through JMX only if a farm is configured. If a server is added to a cluster without proper configuration of the farm, the runtime in that server will be in an inconsistent state after each management operation, and until it is restarted again.

Work flow

1. Choose a stand-alone application server for the server farm.

   IBM MobileFirst Platform Foundation supports the following applications servers for server farms:

   • WebSphere Application Server Base
   • WAS Liberty
   • Apache Tomcat

   IBM MobileFirst Platform Foundation v6.3.0 supports only homogeneous server farms. A server farm is said to be homogeneous when it connects application servers of the same type. Attempting to associate different types of application servers would lead to unpredictable behavior at run time. For example, a farm of Tomcat servers and WebSphere Application Server servers is an invalid configuration.

2. Write an XML configuration file for the server farm.

   This file specifies the connectivity settings for each server. The farm plug-in reads the file at run time. Each server in the farm uses the same configuration file at run time. This file can either be duplicated on the file system of each server or be placed in a shared directory, with appropriate read rights for each server.

3. Deploy the following elements on each of the N servers.

   • The WAR file for administrative services.

   • The WAR file for the operations console. (Optional).

     If we do not install the console, complete management operations in one of the following ways:

     • Using wladm Ant tasks.
     • Using the wladm program.

   • The WAR file for each runtime environment.

   The databases for administrative services, runtime environments, and reports are shared among all the servers.

   The Derby database is not supported in a server farm.

4. Exchange the server certificates in their truststores.

   This exchange is mandatory for WAS and WAS Liberty farms because communication is secured with SSL between the server. The exchange is optional for Tomcat farms.

Parent topic: Install a server farm