Maintain multiple profiles on Linux
If you created additional WebSphere Portal profiles, the profiles now share the product installed files (binaries); therefore, any updates must be coordinated with the users of the various profiles because these updates can affect the runtime behavior of each profile. You must stop all servers across all profiles sharing the same set of binaries while the updates are occurring. Similarly, if the product binaries are shared across several systems supporting their own portal profiles, all IBMWebSphere Portal instances across these servers should be stopped during the update process. It is also probable that updates to each profile will be needed, especially in the case of product maintenance application. Updates to the profiles may require that application server instances be restarted in those profiles. In this case, it is also recommended that end user traffic be prevented to these server instances during the maintenance window by temporarily removing the target servers from any web servers or load balancers.
In the event that additional WebSphere Portal profiles are based on shared product binaries across multiple servers, it is required that the shared filesystem that contains the product binaries be shared at the same location on each server and that the location reflects the original installation location, so that the install location is consistent across each profile configuration. For instance, if WebSphere Portal is installed under the /opt/IBM/WebSphere directory, then that directory needs to be shared with other systems as /opt/IBM/WebSphere.
To maintain additional WebSphere Portal profiles:
- Modify the web servers or load balancer that routes requests to the application servers in these profiles to temporarily quiesce traffic to these servers, if applicable.
- Run the following tasks from the WP_PROFILE/bin directory to stop all application server instances of each profile:
- ./stopServer.sh server1 -username admin_userid -password foo
- ./stopServer.sh WebSphere_Portal -username admin_userid -password foo
- If the profiles are federated to a cell, run the ./stopNode.sh -username admin_userid -password foo task from the WP_PROFILE/bin directory of each profile's nodeagent.
- Apply the changes to the product binaries as appropriate, such as product maintenance for WAS or WebSphere Portal.
Apply WebSphere Portal maintenance will automatically update the initial profile created by product installation (wp_profile). In the case where product binaries are shared across multiple machines, it is assumed that the default installed profile, wp_profile, is present on the source server from which these product binaries are shared. This will allow wp_profile to be updated at the same time the product binaries are updated. Follow the instructions included with the product maintenance and the product update installer for updating the product binaries and the default wp_profile profile. Customer supplied binaries, such as custom JAR files, properties files, or other Filesystem updates, should be added to the binaries at this time as well.
- Apply changes to each profile.
Depending on the change required, application server instances may be required to be started. If WebSphere Portal maintenance is being applied to the profile, instructions are provided with the Portal Update Installer on how to update just a profile without having to reapply the updates product binaries. Customer supplied updates to enterprise applications, portlets, and other J2EE resource configurations should be applied at this time as well.
- After each profile has been updated, verify the changes, start any stopped servers and, if applicable, the nodeagent, and then return user traffic to the application server instances.
Parent
Create multiple profiles on Linux