Administer a portal farm
Because a farm is a series of independent server instances and not a cluster, specific procedures need to be followed to deploy updates to the farm that are different than when administering a cluster. Updates include changes to the system, such as, but not limited to, using or deploying portlets, adding or changing portal pages, changing file system resources, and changing IBM WebSphere Application Server configurations. The procedures differ depending on the type of farm: unique installations or shared installations. Choose the following task depending on the type of portal farm created:
- Administer unique portal farm installations
In a farm of uniquely installed IBM WebSphere Portal instances, each instance has its own release database while every other database domain is shared, including the JCR. Each unique installation also has its own unique IBM WebSphere Application Server configuration profile and its own WAS console. Therefore, application, server configuration, and service updates must be made on each server. It is highly recommended that such updates be automated through configuration scripts that call the appropriate command-line tools for making changes (for example xmlaccess, wsadmin). This automation enables the repetition of the exact same change on each server without the possibility of injecting human error.
- 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.
Parent Set up a portal farm