Search Tips   |   Advanced Search

Portal farm topology

A portal farm topology has a set of identically configured, stand-alone server instances.

Use clusters if...

Use portal farms if...

For portal farm administrative actions, rather than rely on the dmgr, we automate administrative actions across the servers, including restarting servers or application.


When a shared file system is used, each farm instance, including the original portal installation in the farm, must be on the same OS, including Linux variations.

If session persistence and replication is required, configure a distributed session database, then configure all farm instances use the same database and session table. By default, WebSphere Portal does not require an enabled session persistence.

Because dynamic cache replication is not supported across a farm of standalone instances, independently maintain caches on each farm instance.

With farm installations, there is no cell to manage the synchronization of application server configuration updates. Updates, such as to enterprise applications or datasource configuration, must be repeated on every server in the farm.

Each portal instance must have its own release database. Portal configuration updates must be made to every portal instance on the farm.

Portal search should be configured like it was part of a clustered environment. Set up the search server as a separate portal instance outside the farm.

Copy Java classes and JDBC system resources within the shared filesystem available to all servers in the farm.

Every farm instance should have an identical security configuration, including identical user repository configuration (LDAP),

Cache management

Because the server instances are independent, there is no coordination of dynamic cache content or invalidations. Changes made on one server may not be seen immediately on another server in the farm. Configure caches to expire within a reasonable amount of time to ensure updates are seen in a timely manner.

Portal caches Navigation, page layout, and access control. Automatically configured to expire. Most updates are seen immediately on a server when administrative changes are made directly and/or when a user logs off and then back into WebSphere Portal.

In a farm of unique installations, since administrative actions are necessary against all servers, and must be applied to all servers manually, expiration of the portal caches should not be a general concern. For shared configurations, configuration changes will generally appear across the farm when their caches expire, or when individual servers are restarted.

Content caches Updated when a content item changes either through authoring activity or syndication. With a farm, one server is designated as the subscriber for content syndication, whichs updates the cache on the subscriber. Deploy a content cache invalidation message bean on servers in the farm to consume messages from the subscriber server. By consuming content item update messages from the subscriber, the content caches on all servers can be kept in sync and up-to-date.

Portal farm setup options


Database sharing

For a farm with independent servers, all database domains can be shared except for the release domain. For a shared filesystem farm, all database domains can be shared because the application server configuration to which the release data is bound is also shared.

Load balancing

During the login process, several request steps are required to the same server. Moving between servers during the login process can cause the login to fail. Configure a network appliance that supports load balancing with affinity, such as IBM HTTP Server. The application server plugin assumes an application server cluster is in use, so there is some extra configuration.

Set up a portal farm

Creating the farm requires...

This documentation only covers the HTTP server plug-in but we can use any supported Web server.

If created a farm client with a read-only file system, manually gather logs from the temp directories on the farm members.

Parent: Installing

See also

  1. Server topologies
  2. Set up farm instances as unique installations
  3. Web content cache configuration
  4. Work with syndicators and subscribers
  5. Caching
  6. Choose the type of portal farm to create
  7. Set up the HTTP server plug-in on a portal farm
  8. Set up a highly available message bus
  9. Administer a portal farm
  10. Maintain a portal farm
  11. Portal farm considerations