Portal v6 Planning

 

+
Search Tips   |   Advanced Search

 

  1. Overview
  2. Backup and recovery
  3. Clustering considerations
  4. Software that can be installed on the portal machine

 

Overview

Developers should have access to their own portal environment for unit testing and to minimize contention over resources.

The integration and staging environment should mimic the intended production environment, including the platform, database, and operating system levels. The staging environment should imitate the type of traffic and load that are expected against the production environment. Promotion of applications from development to integration to staging and from staging to production needs to be tightly managed for quality assurance and version control.

The production environment should be designed for redundancy and failover and workload distribution. Data may be distributed across multiple databases and shared between multiple lines of production.

To transfer data between supported databases, tweak wpconfig_sourceDb.properties, which is a copy of wpconfig_dbdomain.properties, which was created automatically during install. We can choose to transfer a single domain or multiple domains.

WebSphere Portal data is categorized into four categories.

Data Description
Configuration Portal server setup, including...

  • database connection
  • object factories
  • deployment descriptors

This type of data typically is constant over the uptime of a server node and is either protected by file system security or application server administration rights.

Release Includes...

These resources are typically not modified during production and need administrative rights to do so. Administrators typically create release data on an integration server and stage it to the production system. Release data are protected by Portal Access Control and contains only data, not code.

In a setup that consists of multiple lines of production, one copy of the release data exists per cluster. Administrators must verify the content of the release databases is consistent across the different lines, in particular after modification of the release data on the production system.

Customization Data that is associated with a particular user only and that cannot be shared across users or user groups. Typical examples are PortletData or Implicitly Derived Pages. Since this data is scoped to a single user only, Portal Access Control protection is simplified to a great extent.

In a setup that consists of multiple lines of production, customization data is kept in a database that is shared across the lines of production. Therefore the data is automatically in sync across the lines of production.

Community Resources that are typically modified during production, such as shared documents or application resource. Typically users and groups are allowed to modify or delete shared resources. Community Resources are protected by Portal Access Control. Since documents are a preferred class of shared resources that are supported with its own storage mechanism, this type of resource will have 2 subcategories:

JCR Data: All the documents using this storage mechanism
Application Data: All the other shared application data, which are not documents

In a setup that consists of multiple lines of production, community data is kept in a database that is shared across the lines of production. Therefore the data is automatically in sync across the lines of production.

 

Database Domains

Separation of the portal data in the described classes allows one to store each class in its own set of database tables or the file system. The set of databases tables for one of these resources are called database domains. These database domains can now be moved into different databases, which may even be shared with other portal installations. The list of supported database domains is:

Database domain Sharable Storage method
Configuration no file system
Release no database
Customization yes database
Community yes database
JCR yes database
Feedback yes database
LikeMinds yes database
WMM yes database

The separation of the domains enables production nodes to be split into independent clusters that can share the same JCR, Community, and Customization database domains.

Each of these clusters is called a line of production.

For maintenance and staging purposes you may take a single line of production out of service while the other line is still serving requests with the old data. Once the first production line is updated it is taken into service again, and the second line is now updated using the same approach. Updates of data in the shared domain are critical because they will influence the other production line.

The capacity of the entire environment should be greater than the intended use so that individual servers can be taken out of production without affecting application availability.

Consult the WebSphere Portal Performance Tuning Guide when scaling a system for optimum performance.

To ensure that all of the system resources are available for the portal, production systems should be dedicated to the portal and should not run any other server software that is not related to the portal.

 

Security

When you are ready to configure security for the portal environment, decide if you will use an LDAP directory, an LDAP directory + Lookaside database, a database user registry, or a customer-supplied custom user registry for authentication.

We cannot use Cloudscape as a custom user registry or a database user registry for authentication. Use other supported database software, such as, but not limited to, IBM DB2 Universal Database Enterprise Server Edition.

If you plan to use external manager security software, use an LDAP server or an LDAP + Lookaside database for authentication.

 

Backup and recovery

As with any production-critical programs, you should plan for backup and recovery in the event of a system crash. As it becomes available, additional information about backup and recovery will be posted on the Web.

 

Cluster considerations

The production environment should use vertical clustering to take full advantage of the resources of a multiprocessor system. In addition, it should make use of horizontal cloning to allow for upward scalability.

To maximize security, horizontal clones should reside in different geographic locations to guard against natural disaster or site outages.

For redundancy, failover, and simpler maintenance, WebSphere Portal may be installed in several clusters, or lines of production, sharing some common data through the database

 

Software that can be installed on the portal machine

Software Required? Recommendation
IBM WebSphere Application Server Not required if installing WebSphere Application Server Network Deployment. WAS and WebSphere Portal must be installed on the same machine.
IBM WebSphere Application Server Network Deployment Required for clustered Portal Note that the following Network Deployment install media associated with Portal...

WebSphere Portal V6.0 and Workplace Web Content Management V6.0 - WebSphere Application Server Network Deployment for AIX, V6.0.2.9 (A-1) Multilingual (C949TML)

...does NOT contain the Web server plug-in installation wizard (launchpad.sh). To obtain install media that contains the wizard, download the following...

WebSphere Application Server Network Deployment V6.0 Application Server, IBM HTTP Server, Web server plug ins, Application Clients for AIX, 32bit-support, Multilingual (C5886ML)
Web server Optional.

We can install the Web server on the portal machine or on a separate machine.

To reduce points of failure and to offload processing, consider centralizing the Web server. The WAS plug-in that is installed on the Web server can take care of load balancing between remote Application Server profiles in a cluster.
Database server Required for Cloudscape.

Optional for other database servers. We can install the database server on the portal machine or on a separate (remote) machine.

If you are not using Cloudscape, install the database server on a remote machine. Using a remote database server can improve performance and security, and can reduce the impact of server failure.

Cloudscape is automatically installed with WebSphere Portal.

Database client

Required for DB2.

Optional for other database servers. The database client software can be used in place of a .zip or .jar file as long as the versions are compatible.

Use a remote database server to improve performance and security, and install the appropriate database client software on the portal machine.
LDAP server Optional.

We can install the directory server on the portal machine or on a separate (remote) machine.

Use a remote directory server to improve performance and security, and to reduce the impact of server failure.
LDAP client Optional.

If you use a remote directory server, client software for the directory server might be required on the portal machine.

Install the directory client if the remote directory server requires it.
IBM Lotus Domino Optional.

We can install Lotus Domino on the portal machine or on a separate machine.

Install Lotus Domino on a separate machine to improve performance and to reduce the impact of server failure.
IBM Lotus Sametime Optional.

We can install Lotus Sametime on the portal machine or on a separate machine.

Install Lotus Sametime on a separate machine to improve performance and to reduce the impact of server failure.
IBM Lotus QuickPlace Optional.

We can install Lotus QuickPlace on the portal machine or on a separate machine.

Install Lotus QuickPlace on a separate machine to improve performance and to reduce the impact of server failure.
External security manager Not recommended. Install the external security manager software, such as IBM Tivoli Access Manager for e-business, on a different machine.

 

World Wide Portal

 

Release Serviceability

 

Related concepts


Software and hardware topologies
Staging the portal to production

 

Related tasks


Sharing database domains between clusters

 

Related information


Supported hardware and software