+

Search Tips | Advanced Search

For up-to-date product documentation, see the IBM MobileFirst Foundation Developer Center.


Configure a server farm manually

You must configure each server in the farm according to the requirements of the single type of application server that is used for each member of the server farm.

When we plan a server farm, first create stand-alone servers that communicate with the same database instance. Then, modify the configuration of these servers to make them members of a server farm.


Procedure

  1. Choose the type of application server to use to configure the members of the server farm. IBM MobileFirst™ Platform Foundation supports these application servers in server farms:

    • WebSphere® Application Server full profile.

      Note: In a farm topology, we cannot use the RMI JMX connector. In this topology, IBM MobileFirst Platform Foundation supports only the SOAP connector.

    • WebSphere Application Server Liberty profile.
    • Apache Tomcat.

    To know which versions of application servers are supported, see System requirements.

    Note: IBM MobileFirst Platform Foundation supports only homogeneous server farms. A server farm is homogeneous when it connects application servers of the same type. Attempting to associate different types of application servers might lead to unpredictable behavior at run time. For example, a farm with a mix of Apache Tomcat servers and WebSphere Application Server full profile servers is an invalid configuration.

  2. Decide which database that we want to use. We can choose from:

    • DB2®
    • MySQL
    • Oracle

    MobileFirst Server databases are shared between the application servers in a farm, which means:

    • You create the database only once, whatever the number of servers in the farm.
    • We cannot use the Derby database in a farm topology because the Derby database allows only a single connection at a time.

    For more information about databases, see Set up databases.

  3. Set up as many stand-alone servers as the number of members that we want in the farm. Each of these stand-alone servers must communicate with the same database. You must make sure that any port used by any of these servers is not also used by another server that is configured on the same host. This constraint applies to the ports used by HTTP, HTTPS, REST, SOAP, and RMI protocols.

    Each of these servers must have the MobileFirst Server administration service, the MobileFirst Server live update service, and one or more MobileFirst runtimes deployed on it.

    For more information about setting up a server, see Constraints on MobileFirst Server administration service, MobileFirst Server live update service and MobileFirst runtime.

    When each of these servers is working properly in a stand-alone topology, we can transform them into members of a server farm.

  4. Stop all the servers that are intended to become members of the farm.
  5. Configure each server appropriately for the type of application server.

    You must set some JNDI properties correctly. In a server farm topology, the mfp.config.service.user and mfp.config.service.password JNDI properties must have the same value for all the members of the farm. For Apache Tomcat, we must also check that the JVM arguments are properly defined.

    • WebSphere Application Server Liberty profile

      In the server.xml file, set the JNDI properties shown in the following sample code. 

        <jndiEntry jndiName="mfp.topology.clustermode" value="Farm"/>
<jndiEntry jndiName="mfp.admin.serverid" value="farm_member_1"/>
<jndiEntry jndiName="mfp.admin.jmx.user" value="myRESTConnectorUser"/>
<jndiEntry jndiName="mfp.admin.jmx.pwd" value="password-of-rest-connector-user"/>
<jndiEntry jndiName="mfp.admin.jmx.host" value="93.12.0.12"/>
<jndiEntry jndiName="mfp.admin.jmx.port" value="9443"/>

      These properties must be set with appropriate values:

      • mfp.admin.serverid: The identifier that you defined for this farm member. This identifier must be unique across all farm members.
      • mfp.admin.jmx.user and mfp.admin.jmx.pwd: These values must match the credentials of a user as declared in the <administrator-role/> element.
      • mfp.admin.jmx.host: Set this parameter to the IP or the host name that is used by remote members to access this server. Therefore, do not set it to localhost. This host name is used by the other members of the farm and must be accessible to all farm members.
      • mfp.admin.jmx.port: Set this parameter to the server HTTPS port that is used for the JMX REST connection. We can find the value in the <httpEndpoint> element of the server.xml file.

    • Apache Tomcat

      Modify the conf/server.xml file to set the following JNDI properties in the administration service context and in every runtime context. 

        <Environment name="mfp.topology.clustermode" value="Farm" type="java.lang.String" override="false"/>
<Environment name="mfp.admin.serverid" value="farm_member_1" type="java.lang.String" override="false"/>

      The mfp.admin.serverid property must be set to the identifier that you defined for this farm member. This identifier must be unique across all farm members.

      You must make sure that the -Djava.rmi.server.hostname JVM argument is set to the IP or the host name that is used by remote members to access this server. Therefore, do not set it to localhost. In addition, we must make sure that the -Dcom.sun.management.jmxremote.port JVM argument is set with a port that is not already in use to enable JMX RMI connections. Both arguments are set in the CATALINA_OPTS environment variable.

    • WebSphere Application Server full profile

      You must declare the following JNDI properties in the administration service and in every runtime application deployed on the server.

      • mfp.topology.clustermode
      • mfp.admin.serverid

    1. In the WebSphere Application Server console, select Applications > Application Types > WebSphere Enterprise applications.
    2. Select the administration service application.
    3. In Web Module Properties, click Environment entries for Web Modules to display the JNDI properties.
    4. Set the values of the following properties.

      • Set mfp.topology.clustermode to Farm.
      • Set mfp.admin.serverid to the identifier that you chose for this farm member. This identifier must be unique across all farm members.
      • Set mfp.admin.jmx.user to a user name that has access to the SOAP connector.
      • Set mfp.admin.jmx.pwd to the password of the user as declared in mfp.admin.jmx.user.
      • Set mfp.admin.jmx.port to the value of the SOAP port.

    5. Verify that mfp.admin.jmx.connector is set to SOAP.
    6. Click OK and save the configuration.
    7. Make similar changes for every MobileFirst runtime application deployed on the server.
  6. Exchange the server certificates in their truststores between all members of the farm. Exchanging the server certificates in their truststores is mandatory for farms that use WebSphere Application Server full profile and WebSphere Application Server Liberty profile because in these farms, communications between the servers is secured by SSL.
    • WebSphere Application Server Liberty profile

      We can configure the truststore by using IBM® utilities such as Keytool or iKeyman.

      • For more information about Keytool, see Keytool in the IBM SDK, Java™ Technology Edition.
      • For more information about iKeyman, see iKeyman in the IBM SDK, Java Technology Edition.

      The locations of keystore and truststore are defined in the server.xml file. See the keyStoreRef and trustStoreRef attributes in SSL configuration attributes. By default, the keystore of Liberty profile is at ${server.config.dir}/resources/security/key.jks. If the truststore reference is missing or not defined in the server.xml file, the keystore that is specified by keyStoreRef is used. The server uses the default keystore and the file is created the first time that the server runs. In that case, a default certificate is created with a validity period of 365 days. For production, you might consider using your own certificate (including the intermediate ones, if needed) or changing the expiration date of the generated certificate.

      Note: If we want to confirm the location of the truststore, we can do so by adding the following declaration to the server.xml file: 

        <logging traceSpecification="SSL=all:SSLChannel=all"/>

      Lastly, start the server and look for lines that contain com.ibm.ssl.trustStore in the ${wlp.install.dir}/usr/servers/server_name/logs/trace.log file.

    1. Import the public certificates of the other servers in the farm into the truststore that is referenced by the server.xml configuration file of the server.

      The tutorial (Install MobileFirst Server in graphical mode) provides you the instructions to exchange the certificates between two Liberty servers in a farm. For more information, see step 5 of Create a farm of two Liberty servers that run MobileFirst Server section.

    2. Restart each instance of WebSphere Application Server Liberty profile to make the security configuration take effect.

      The following steps are needed for single sign-on (SSO) to work.

    3. Start one member of the farm. In the default LTPA configuration, after the Liberty server starts successfully, it generates an LTPA keystore as ${wlp.user.dir}/servers/server_name/resources/security/ltpa.keys.
    4. Copy the ltpa.keys file to the ${wlp.user.dir}/servers/server_name/resources/security directory of each farm member to replicate the LTPA keystores across the farm members.

      For more information about LTPA configuration, see Configure LTPA on the Liberty profile.

    • WebSphere Application Server full profile

      Configure the truststore in the WebSphere Application Server administration console.

    1. Log in to WebSphere Application Server administration console.
    2. Select Security > SSL certificate and key management.
    3. In Related Items, select Keystores and certificates.
    4. In the Keystore usages field, make sure that SSL keystores is selected. We can now import the certificates from all the other servers in the farm.
    5. Click NodeDefaultTrustStore.
    6. In Additional Properties, select Signer certificates.
    7. Click Retrieve from port. We can now enter communication and security details of each of the other servers in the farm. Follow the next steps for each of the other farm members.
    8. In the Host field, enter the server host name or IP address.
    9. In the Port field, enter the HTTPS transport (SSL) port.
    10. In SSL configuration for outbound connection, select NodeDefaultSSLSettings.
    11. In the Alias field, enter an alias for this signer certificate.
    12. Click Retrieve signer information.
    13. Review the information that is retrieved from the remote server and then click OK.
    14. Click Save.
    15. Restart the server.

Parent topic: Install a server farm