Portal farm considerations
The term "farm" refers to a series of identically configured, standalone server instances. The fact that they are standalone allows for the farm to be increased or decreased in size without having to worry about complex cluster configurations or inter-server awareness. Server farms offer a very simple way to build and maintain a highly scalable, highly available server environment.
There is a cost associated with the simplicity of the portal farm, which stems from not gaining the benefits from the application server clustering. Understanding these limitations and whether or not they pose any business risk is imperative to understanding if a portal farm is a suitable deployment pattern.
Common OSs (shared installations only)Each farm instance, including the original WebSphere Portal installation in the farm, must be on the same OS, including Linux variations, when a shared file system is used.
Session persistence and replicationSession persistence and replication is possible only through using a distributed session database. All WebSphere Portal farm instances need to specify the same database and session table if session persistence and replication is required. WebSphere Portal, by default, does not require an enabled session persistence.
Dynamic cache replicationDynamic cache replication is not supported across a farm of standalone instances; therefore, independently maintain caches on each farm instance. This means cache expirations should be configured to ensure updates to portal configuration and published content are visible within a reasonable amount of time. What "reasonable" is depends on business requirements. See the "Cache management considerations for portal farms" link below for additional information about caching.
No cell to manage the synchronization of application server configuration updates (unique farm installations only)There is no cell to manage the synchronization of application server configuration updates, which means that any update to the application server configuration, such as an update to an enterprise application or change to a datasource configuration, must be repeated on every server in the farm.
Each portal instance must have its own release database (unique farm installations only)Each portal instance must have its own release database, which means that portal configuration updates must be made to every portal instance on the farm.
Portal searchPortal search should be configured like it was part of a clustered environment. The search server should be set up as a separate portal instance outside the farm, which is configured to search the farm. See the "Using remote search service" link below for information.
Shared resources (shared installation only)Ensure that all system resources, such as Java classes and JDBC, are placed within the shared filesystem that each server in the farm uses so that they can be found when the portal instance is started.
Security
Every farm instance should have an identical security configuration, including identical user repository configuration, for example LDAP server, to ensure each farm instance has access to the same user and group information and participates seamlessly in the same single sign-on strategy.
- Cache management considerations for portal farms
- Portal farm setup options
- Database sharing and load balancing for portal farms
Parent
Portal farm topology
Use remote search service
Multiple profile support
Caching
Web content cache configuration
Work with syndicators and subscribers
Set up a portal farm