Administer shared portal farm installations
In a shared installation farm, there is one 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 WAS 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.
It is recommended that 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 that 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 that 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 the XMLAccess tool 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:
To restart an application, you can either access the WAS administration console on each server and restart the application, or you can 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.
- The application is restarted on each server
- Each server in the farm is restarted
If the administrative action is extensive, updating several WAS and WebSphere Portal assets at once, you may want to follow the instructions under the Maintain a portal farm section, which walks through an update procedure involving a second filesystem and database, ensuring that 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 has the added benefit of providing a fallback configuration if the changes do not work as expected.
Parent
Administer a portal farm