This topic describes considerations for choosing the correct environment to install and configure Expeditor Server.
Expeditor Server supports the following environments:
- Typical install with local database
- Custom install
- Multiple systems with a cluster of Expeditor Servers
- Setting up an LDAP registry
- High availability considerations
- Client Management services considerations
Typical install with local database
For a single system install, select a Typical
install and specify local database from the options offered during the Lotus® Expeditor Server installation and configuration. As a result of this selection, all of the server components and databases are installed on a single system. This scenario is intended for developer or proof-of-concept installs. If you choose this install scenario, you will not be able to cluster the Lotus Expeditor Server. For instructions on installing a single system with a local database, see Installing a single server
You can customize which services of Lotus Expeditor Server are deployed by selecting the Custom
install option. With a custom install, only the core server files are installed. You use the configuration wizard to decide which components to install and configure. Prerequisite checking, specific to the component, is performed during the "add component" process. While a Typical install scenario requires DB2®, a custom install scenario allows you to configure Client Management Services with the Derby database that is included with WebSphere®. You must choose the custom install path if you plan to deploy Expeditor Server services in a WebSphere Network Deployment managed environment and more advanced WebSphere cluster environment.
Multiple systems with a cluster of Expeditor Servers
You can create a cluster that would allow Lotus Expeditor Server to grow to multiple server systems. If you plan to install Lotus Expeditor Server on multiple systems, you must create a cluster on a single system installed with a remote database and configured into a WebSphere managed environment. This requires a WebSphere Application Server Deployment Manager. WebSphere MQ Everyplace® is not clustered because it is not an application server. To share MQe queues among multiple servers, you must create the queues on media that is accessible from all systems (for example, shared DASD). For instructions on setting up an initial cluster, see Creating a cluster
In a high volume production environment, you might find it necessary to add additional Expeditor Servers to increase capacity or provide high availability for Expeditor Server services. After you have created the cluster from an initial installation, you can add additional Expeditor Server systems to the cluster. For instructions on how to add servers to your scaled environment, see Adding an additional server
Setting up an LDAP registry
Lotus Expeditor Server require access to a user registry. Lotus Expeditor Server supports user registries configured using WebSphere Application Server's federated repository support (Virtual Member Manager). See the WebSphere Information Center
for information on supported repositories.
High availability considerations
Consider the following when setting up a highly-available Expeditor Server system:
- Queues created with WebSphere MQ Everyplace must be on shared storage that is available to all systems. See the ../com.ibm.rcp.tools.doc.servermqe/welcome.html section for more information.
- Consider other single points of failure in your system that might affect access to your Lotus Expeditor system. Some components to consider are as follows:
- LDAP server used to store Lotus Expeditor users and groups
- Web servers used to gain access to the Lotus Expeditor servers
- Load balancers (optional) used to distribute workload across WebSphere Everyplace Access servers
- Database server where the Lotus Expeditor databases are stored
Follow the instructions in Installing Expeditor Server
to install and configure systems in a Lotus Expeditor environment.
Client Management services considerations
When registering update sites in Client Management Services, make sure that the URL provided is accessible from both the server and clients that will install features from the update sites, regardless of which Client Management Services Server is servicing the request. This means that you cannot use localhost or 127.0.0.1 as the host name for a update site. Because the server accesses this URL when the update site is created, it is possible for the update site creation to succeed, even though the URL provided is not valid on the client. In this case, the feature installation task will fail. Consider placing update sites on a separate Web server to achieve this connectivity.
Parent topic: Planning for deployment: XPD621