Administer shared portal farm installations
In a shared installation farm, there is one IBM WebSphere Portal installation whose file system serves as the configuration for the entire farm, which is referred to here as the master instance. That means that every farm instance shares the exact same databases and IBM WebSphere Application Server configuration profile. This one WebSphere Portal installation should have write access to the file system, while all other farm instances that share this file system should have read-only access. This means that all administrative actions can only be performed against the master instance.
IBM recommends the master instance either not be a part of regular production traffic, or if it is, it be temporarily removed from production traffic when the update is made, so the update can be tested before the other servers are affected. After a change is made to the master, depending on the nature of the change, it may take effect immediately across the entire farm or require the farm instances be restarted.
Changes made to WebSphere Portal's release configuration, such as new pages, page layout changes, access control changes, or other updates made using xmlaccess.sh that do not involve updates to portlet applications will take effect immediately since all farm instances share the same release database.
Changes made to the WAS configuration profile, which include JVM tuning changes and JDBC datasource changes, or updates to Java resources, which include updated JAR files in the file system, will not take effect until each server in the farm is restarted.
Likewise, updates to enterprise application or portlet EAR and WAR files will not take effect until one of the following occurs:
- The application is restarted on each server
- Each server in the farm is restarted
To restart an application, we can either access the WAS console on each server and restart the application, or use the wsadmin scripting command to restart the application. To restart the server, use the stop_WebSphere_Portal and start_WebSphere_Portal scripts profiled in the WP_PROFILE/PortalServer/bin directory.
If the administrative action is extensive, updating several WebSphere Application Server and WebSphere Portal assets at once, we may want to follow the instructions under the Maintaining a portal farm section, which walks through an update procedure involving a second filesystem and database, ensuring the updates are isolated from the original configuration and each server can be switched to the updated configuration, tested, and returned to production traffic without affecting other farm instances in any way. This option has the added benefit of providing a fallback configuration if the changes do not work as expected.
Parent Administer a portal farm