Multiple profile support

IBM® WebSphere® Portal creates an application server configuration profile to represent its application server configuration, such as datasource definitions, web application and portlet deployments, and Java virtual machine configuration. A configuration profile represents the full configuration of a single portal instance. Multiple profiles give you the ability to have multiple, independently configured portal instances running from the same installation. Before WebSphere Portal Version 7, there was only one configuration profile per installation, which was typically named wp_profile.

Note: For more information on application server profiles, see Managing profiles on non-z/OS operating systems.
Starting in WebSphere Portal Version 7, it is possible to create additional profiles in addition to the default profile, which is useful in the following popular scenarios:
  • Reuse a single installation for multiple independent portal instances, such as for various test or development efforts.
  • Recover from a configuration problem by deleting the current profile and re-creating it without having to re-install the product.
  • Create custom profiles to easily expand a cluster's capacity without having to manage the extra, nonessential resources of a regular standalone instance.
  • Update a Deployment Manager profile to handle portal servers and thus avoid all the manual preparation steps.
The following profile types can be generated:
portal.default
This is a profile holding a standalone portal server in the captured configuration. It might be used as a standalone server or after the federation as a base for a portal cluster.
managed.portal
This custom profile is enhanced with the portal run time environment but does not contain any servers. The main purpose of this profile is to use it as a run time environment for additional cluster members. After the federation of this custom profile, the standard portal tasks can be used to create a portal server cluster member from an existing cluster template.
management.portal.augment
This profile is created by augmenting a standard Deployment Manager profile. The resulting profile holds a deployment manager prepared for use with portal. It can be used to federate the other portal profiles immediately without the need for the additional manual steps. Because the deployment manager is often located on different hardware, there is the possibility to move this augmentation template to another installation and run it there.

Search Collection and Multiple Profiles

When you run the enable-profiles or replace-profiles tasks, all existing Search collections are captured in the profile template. The Search functionality does not support sharing Search collections between multiple profiles. Before running the enable-profiles or replace-profiles tasks, you should either delete all search collections, including the default Search collections to avoid search errors when you create the additional profiles. You can use the back up and restore procedures to preserve the search collections on the original profile or you can use the following export and import steps:
  1. Export the existing search collections.
  2. Remove the existing search collections.
  3. If you installed WebSphere Portal as a non-root user, run the chmod -R g+rwx /portal_server_root task to modify permissions for the Portal Server directory.
  4. Run the enable-profiles or replace-profiles configuration task to capture the Portal configuration in the profile template.
  5. Import the saved search collections on the original profile.
  6. Create new profiles using the profile templates; default search collections will be automatically created in the new profile.
  7. Run the chmod -R g+rx /portal_server_root task to restore permissions to the Portal Server directory.

If you want to share search collections between multiple Portal server instances, such as in a clustered or Portal Farm environment, then you must configure a remote search server to support the sharing of the search collections.

Special considerations for cluster configurations

As a best practice, you should manage all maintenance at the cluster level. That means that during maintenance application to a cluster, the entire cluster should be taken out of service, so that cluster-wide changes can take effect without affecting user traffic or potentially causing synchronization conflicts between cell managed resources, like enterprise applications and portlets, and the product binary files in the local file system. In a continuous availability environment, multiple clusters might be necessary, to allow traffic to continue to one cluster while another is being serviced.

Maintaining a WebSphere Portal installation with multiple profiles involves applying maintenance to the product binary files as well as applying maintenance to each profile instance. It is important that all profile instances and the WebSphere Portal product binary files are updated at the same time to avoid conflicts. If one of the profiles on a particular installation belongs to a cluster, then whenever that cluster is updated, the shared WebSphere Portal product binary files and all other profiles on the system must be updated as well to maintain synchronization.

Therefore, in the event that multiple portal profiles using a single set of product binary files are used as part of a cluster configuration, it is strongly recommended that all profiles sharing the same product binary files belong to the same cluster to stay consistent with the best practice of applying maintenance at the cluster boundary.