The IBM Connections product manual provides a detailed description of the deployment options
and considerations in planning an IBM Connections deployment. In this section, we describe the planning considerations for our lab environment (see the figure below) which is a slightly modified small deployment scenario.
While this is the easiest of the deployment scenarios to build, the basic architecture permits scaling horizontally or vertically into the larger style deployments should it be necessary. Using IBM WebSphere Application Server Network Deployment allows future scaling to be performed and hence can act as a good starting point for your own deployment.
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. IBM Cognos® Business Intelligence is an optional component in the deployment. If used, Cognos must be federated to the same Deployment Manager as the IBM Connections servers. However, Cognos servers cannot be configured within an IBM Connections cluster. 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 experienced administrative personnel who can manage them.
It is important to distinguish between the physical needs of the IBM Connections server and the ability of WebSphere to allow you to scale the IBM Connections applications themselves horizontally or vertically. To be clear by "physical needs", we mean:
- The presence of a database management system such as DB2 or Oracle;
- The presence of an HTTP server, in our case IBM HTTP Server
- The ability of the system to connect to one or more LDAP servers to authenticate users and create profiles.
- The number and location of WebSphere Application Servers.
With these physical needs addressed, the individual IBM Connections applications can be scaled across multiple WebSphere Application Servers (WAS). A single WAS can also run more than one application (and frequently does - in a standard "Small Deployment" one where the WebSphere Application Server server runs all the applications). By "application" we mean Activities, Blogs, Communities, Wikis, Profiles, and so on. Each of these in WebSphere Application Server terms are applications in their own right and by chance or design, they happen to share the same databases and look and feel.
For example, suppose you have an existing Enterprise Content Management solution which manages your organization's files. The need for the Files application in IBM Connections would be restricted to the mandatory requirements of the wikis, activities, and so forth. The need to provide a highly-scalable Files solution has already been solved through the ECM system. Thus, you might choose to run the Files application on a single WebSphere Application Server node. Similarly, however, it might be that the Profiles application is one of the main aspects of your deployment and as such needs, to be highly-responsive. You would choose in that situation to cluster the Profiles application across two or more WAS nodes.
In our deployment, we have chosen to use a modified small deployment where the applications are split between two WAS servers. We are not clustering applications (that is, running the same application in a synchronized manner across multiple nodes), but simply dividing the total number of applications we are deploying across more than one node.