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 operating systems (shared installations only)
Each farm instance, including the original IBM® WebSphere® Portal installation in the farm, must be on the same operating system, including Linux variations, when a shared file system is used.
Session persistence and replication
Session 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 replication
Dynamic cache replication is not supported across a farm of standalone instances; therefore, you must 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 your business requirements. See the "Cache management considerations for portal farms" link 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 search
Portal 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 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.