Deployment options

Install IBM® Connections in one of three deployment topologies to achieve optimum scaling, load balancing, and failover.

A network deployment can consist of a single server that hosts all IBM® Connections applications or two or more sets of clustered servers that share the workload. You must configure an additional system with WebSphere® Application Server Network Deployment Manager.

A network deployment provides the administrator with a central management facility and it ensures that users have constant access to data. It balances the workload between servers, improves server performance, and facilitates the maintenance of performance when the number of users increases. The added reliability also requires a larger number of systems and the experienced administrative personnel who can manage them.

Any of these deployments can be set up to allow employees and external users to work together. After you install IBM® Connections, you must register external users manually and then add them to the Profiles database. For more information, see the Configuring External Collaboration article in the IBM Connections wiki.

When you are installing IBM® Connections, you have three deployment options:
Small deployment
Install all IBM® Connections applications on a single node in a single cluster. This option is the simplest deployment but has limited flexibility and does not allow individual applications to be scaled up. All the applications run within a single Java Virtual Machine (JVM).
Note: The diagram depicts a topology with up to 8 servers. If you install the servers on shared systems, you do not need to deploy 8 separate systems.
Figure 1. Small deployment
Small deployment topology
Medium deployment
Install a subset of applications in separate clusters. IBM® Connections provides five predefined cluster names shared among all of its applications. Use this option to distribute applications according to your usage expectations. For instance, you might anticipate higher loads for the Profiles application and install it in its own cluster, while other applications could be installed in a different cluster. This option allows you to maximize the use of available hardware and system resources to suit your needs.
Figure 2. Medium deployment
Medium deployment topology
Large deployment
Install each application in its own cluster. IBM® Connections provides a predefined cluster name for each application. This option provides the best performance in terms of scalability and availability options but also requires more system resources. In most cases, you should install the News and Home page applications in the same cluster.
Figure 3. Large deployment
Large deployment topology
Notes:
  • In a multi-node cluster, you must configure network share directories as shared content stores. When using NFS, use NFS v4 because NFS v3 lacks advanced locking capability. When using Microsoft SMB Protocol for file-sharing, use the UNC file-naming convention; for example: \\machine-name\share-name.
    Tip: For shared and remote network file system requirements, review the footnotes for each supported operating system in the detailed system requirements.
  • You can assign various combinations of applications to clusters in many different ways, depending on your usage and expectations. For more information, visit the IBM® Connections wiki to read articles about deployment.
  • The number of JVMs that you need for each cluster depends on the user population and workload. For failover, you must have two JVMs per application, or two nodes for each cluster, scaled horizontally. Horizontal scaling refers to having multiple JVMs per application with each JVM running on a WebSphere® Application Server instance. Vertical scaling refers to running multiple JVMs for the same application on a single WebSphere® Application Server instance. Vertical scaling is not officially supported in IBM® Connections. However, it is typically not needed unless your server has several CPUs.
  • For performance and security reasons, consider using a proxy server in your deployment.
  • IBM® Cognos® Business Intelligence does not have to be deployed before you install the Metrics application. Even if you do not plan to deploy Cognos® now, you should install the Metrics application so that events are recorded in the Metrics database for use when Cognos® is available to provide reports.
  • For added security when you are planning to run 3rd party OpenSocial gadgets, such as those from iGoogle, you must configure locked domains. Locked domains are required to isolate these gadgets from access to your intranet and SSO information. The basic configuration of locked domains is as follows:
    • A second top-level domain that is not in your SSO domain. For example, if you organization's SSO domain is example.com, you will require a distinct top level domain, such as example-modules.com.
    • A wild card SSL certificate for this domain name.

    No additional server instances are required for the basic configuration. See Enabling locked domains for more details.

  • If you use Forms, Viewer, Polls, or Surveys, your deployment topology requires additional servers.
  • Connections failover scenarios are supported when a standby Connections server or servers are configured to use a standby database and a standby file share server. When a DNS switch from active to standby servers is needed, no server restart is required. In contrast, the scenario where a standby server and active file share server (such as NFS) are connecting to the same Connections environment requires a full Connections applications restart, and is not supported.