You can choose between two methods of distributing HTTP requests to servers in the cluster: load balancing or failover to a "hot-spare." Note that IBM® Lotus® Quickr™ requires that HTTP requests sent to one node are continuously sent to that node for a predetermined amount of time known, sometimes referred to as "sticky time."
Parent topic: Configuring a cluster (optional)
About this task
The typical method is installing and setting up load balancing software. With load balancing, a virtual server is used to distribute HTTP requests so that the physical servers share the user load.
The maximum capacity of the cluster is approximately the sum of the capacities of the servers in the cluster. For example, a cluster of three servers that each support 1,000 users has approximately a maximum capacity of 3,000 concurrent users. However, if one server goes offline, the capacity of the cluster is reduced correspondingly (to 2,000 users in the example).
Therefore, the average capacity of a load-balanced cluster is less than the maximum possible, and allowance should be made for server downtime so that response times do not significantly decrease when a single server becomes unavailable. Having more than two servers in a cluster provides greater flexibility and reliability because when a server is taken offline for scheduled maintenance, failover can still occur among the remaining available servers.
You purchase a load balancing product separately, and set it up following the product documentation.
When you use load balancing, each physical server and place has an entry in the Place Catalog. In addition, there is an entry for the virtual server that represents the combination of all physical servers, and an entry for each place in the cluster that represents all the replicas of the place in the cluster.
Real-time updates to the Place Catalog (such as place creation, locking of a place, and place membership changes) are made in the place entries that correspond to the virtual server. The non-real time updates (such as place size, time last accessed, and time last modified) are made to the place entries that correspond to the physical servers in the cluster. This information allows the administrator to know the differences in access and size for the places in each of the physical servers in the cluster.
Use the qptool placecatalog -update
command to synchronize the place entries that correspond to the physical servers and the place entries that correspond to the virtual server.
When using the Edge components Load Balancer for IBM® WebSphere® Application Server, the Websphere documentation provides instructions for configuring the load-balanced servers so they will accept a packet that was addressed to the cluster address. For most platforms, this is done by setting or aliasing the loopback device to the cluster address. If the Lotus Quickr servers in the cluster are running on Microsoft® Windows® 2008 or IBM i, special instructions are needed to properly complete the configuration for the load balanced servers as described in the following topics:
Microsoft® Windows® 2008: See How to configure the loopback adapter on Microsoft Windows 2008
IBM i: See Load Balancing IBM i servers: configuring the loopback device
Failover to a hot-spare
About this task
A less common method for distributing HTTP requests is failover to a hot spare, in which a primary server and a secondary server are clustered. The primary server handles user requests, and the secondary server is held in reserve in case the primary server fails or requires a scheduled stoppage. When the primary server is taken offline, user requests fail over to the hot spare until the primary server comes back online. In this type of cluster, the resources of the hot spare are not utilized while the primary server is active: the capacity of the cluster is the capacity of the primary server. Therefore, if a given server specification supports 1,000 concurrent users, two such servers are required to support 1,000 users. If the hot spare is identical to the primary server, the capacity remains the same after the primary server fails over.
With the hot-spare solution data is maintained in separate entries in the Place Catalog for each physical server, and for each place on a physical server.