Environment planning

This section lists some of the things you should consider before installing WebSphere Partner Gateway. Adequate planning enables you to decide on the deployment topology that fits your requirements.

Availability

System downtime can seriously affect your business productivity and profitability. When you create a high availability system, you are ensuring your hub community that the system is always up and running and ready to receive documents. A typical high availability environment ensures that the system is working 99.9 percent of the time, with some systems achieving 99.999 percent of the time. Availability levels can decrease due to events such as system failure, system overload, network congestion, and network attacks. To maximize availability, you need to provide system redundancy. You can accomplish this by having at least two implementations of each logical function (Community Console, Receiver, and Document Manager) on separate servers in your architecture. Therefore, if you place all three components on one server, you need a second server to provide redundancy. If you separate each component onto its own server, you need six servers in total to provide redundancy. Additionally, you should consider creating another set of servers in your disaster recovery location so that you can run the system from that location.

To create a highly available WebSphere Partner Gateway implementation, its supporting infrastructure (such as network, Internet connection, even power coming into your facility) must also be highly available. The high availability requirement also applies to MQ and your RDBMS. If either of these supporting applications fails, your production environment will fail.

Scalability

WebSphere Partner Gateway scales horizontally. That is, you increase its processing ability by adding instances of its components. The actual number of servers, instances of a particular component, or network capability that you will need depends on the following factors:

As these factors change, you can scale WebSphere Partner Gateway by adding multiple instances of its components. The Receiver, Community Console, and Document Manager instances can live anywhere independently. However, there are some things to consider when creating redundant WebSphere Partner Gateway components:

Note that as you scale WebSphere Partner Gateway, you must also scale the supporting infrastructure, such as WebSphere MQ and your RDBMS.

Once you have configured your servers, it is important to monitor your system performance to determine when and if additional servers are required to meet demands.

Data storage

Data storage is a key component in your topology as it is a WebSphere Partner Gateway prerequisite. How you address the shared storage requirement depends on your storage needs and the answers to the following questions:

If your requirements are low in these areas, you can consider implementing your shared storage on the same server as one or more of the WebSphere Partner Gateway components. If not, it should be on a separate server from WebSphere Partner Gateway. When high availability is a requirement, consider a redundant NAS product because it can scale independently from the servers. Note that your RDBMS and WebSphere MQ do not have to be on NAS.

Security

WebSphere Partner Gateway will work within a standard secure environment. However, you should consider the following things:

The Community Console requires that sticky sessions (also referred to as Server Affinity) be enabled if you are using a load balancer. Sticky sessions are used to tell the load balancer that if a client request comes from the same IP address within a configured time period, the request should be sent to the same server as specified the last time instead of selecting a new server.

The Console uses cookies to ensure that all incoming requests, via the browser, for a session go to the same server. Without the sticky sessions turned on, each request from the Console can be sent by the load balancer to a different server. This can cause problems. For example, the Console will not think that the user is logged in. Enabling sticky sessions at the IP Address level may impact scaling because the Recievers will also be affected. Participants with high document volumes can have their documents sent to the same Receiver instance each time because the load balancer will see the same client IP address being used for each document request. Another option is to enable stickiness only for cookies so that the Receivers are not affected.

Copyright IBM Corp. 2003, 2005