Chapter 6 Implementation Module 3: Portal Server With Portlet Session Failover on Application Server Cluster
This chapter provides an overview of the portal service module in Figure 2–2 and documents the tasks that are required to implement it. The chapter includes the following sections:
Overview of the Portal Service Module
The portal service module of the reference configuration's deployment architecture illustrated in Figure 2–2consists of two instances of Sun Java System Portal Server running on two different computers. The module makes use of a hardware load balancer that is configured to provide service failover capability between the two Portal Server instances. All requests for portal services are addressed to the virtual service name and IP address of the load balancer. The load balancer directs each request to one of the two Portal Server instances.
This module implements portlet session failover. When a user logs in and is authenticated by the Access Manager service, the load balancer routes the portal request to one of the Portal Server instances, which builds and returns a Portal Desktop to the user. As the user accesses various portal channels and portlet applications from the desktop, the requests from the user are routed to the same Portal Server instance. Portlet session state is maintained by the web container supporting the Portal Server instance.
If the Portal Server instance fails, the system recovers as follows:
-
Service Failover. Subsequent requests are routed by the load balancer to the other Portal Server instance.
-
Portlet Session Failover. The new Portal Server instance rebuilds the Portal Desktop by using the Access Manager session state and retrieves portlet session state from a high availability database, thus making the service failover transparent to the user.
Portlet session failover depends upon high availability mechanisms provided by the web container. Hence, portlet session failover for the portal service module is achieved by using an Application Server cluster and its High Availability Session Store (HADB).
The architecture of the portal service module is shown in the following illustration.
Figure 6–1 Portal Service Module
The Portal Server instances run in a web container that is provided by Application Server. Each Portal Server instance runs in an Application Server instance on its respective computer. The instances are managed by Application Server node agents that are acting on behalf of the Domain Administration Server (DAS).
As shown in Figure 6–1, the Portal Server instances together constitute a single portal service, pstestPortal.
Also indicated in Figure 6–1 is that the Application Server instances are configured to operate within the context of an Application Server cluster. The cluster provides for high availability through an HADB cluster consisting of an HADB instance on ps1 and ps2.
The module also includes two components that are not replicated and therefore represent single points of failure:
-
Java DB. Java DB is the default relational database that is used to support Portal Server features such as the search engine, community membership, and portlet sample applications (wiki, survey, and filesharing). However, Java DB cannot be configured for high availability.
If support for communities is required in your deployment, you can switch to another relational database that can be configured for high availability. For example, instructions for configuring Portal Server to use Oracle RDBMS can be found at the Sun Developer Network web site (http://developers.sun.com/portalserver/reference/techart/databases.html).
-
Portal Server's Search engine. In most architectures, a single search instance is deployed on a dedicated node and is accessed by all Portal Server instances. However, for simplicity, the search instance is deployed in this module in a separate, non-clustered Application Server instance on ps1. It is not possible to have multiple instances of the search engine using the same database (not shown in Figure 6–1) and at the same time be accessible through a load balancer. As a result, if the search instance fails, the search channel and the subscriptions and collaboration services, which depend upon Java DB, will become inoperative.
The general approach to implementing this module is to first set up the Application Server cluster (plus an additional Application Server instance in which to deploy the search instance), and then to install, deploy, and configure the pstestPortal portal within the cluster. In setting up the cluster, the Java ES installer is run in Configure Now mode to install and configure Application Server, HADB, and Access Manager SDK. In setting up the pstestPortal portal, the Java ES installer is run in Configure Later mode to install Portal Server, Java DB, and Service Repository libraries. Following these procedures, load balancing is implemented to provide portal service failover. Then portlet session failover is set up.
This module can be scaled horizontally by adding an additional computer like ps2 and its respective components, and following the instructions in this chapter that apply to ps2.
Note –
The procedures in this chapter use the host names, domain name, and IP addresses shown in Figure 3–1 and Figure 6–1. However, you must map these host names, domain name, and IP addresses to equivalent names and addresses in your environment. For this reason, the procedures in this chapter show host names, domain name, and IP addresses as variables.
Setting Up an Application Server Cluster Node on ps1
This task creates the infrastructure for an Application Server cluster and sets up the first node of that cluster. It consists of the following procedures:
To Install Application Server on ps1
This procedure assumes that you are installing Java ES components on Solaris 10 8/07 OS or later version. Hence, no operating system patches need to be installed. The Java ES installer evaluates the state of the operating system and indicates if you need to install a patch. If you are using versions of the operating system older than Solaris 10 8/07 OS, it is better to install any required patches before you begin the actual Java ES installation procedure.
The following procedure installs Application Server, HADB, Java DB, and Access Manager SDK, all of which are needed to support Portal Server on this computer, and all of which can be configured using the Java ES installer's Configure Now capability. Installation of Portal Server requires custom configuration and is performed in a subsequent procedure (see Setting Up Portal Server on ps1).
The procedure runs the Java ES installer without saving a state file. You can choose to run the installer and capture your input in a state file (-saveState state-fileName). You could then use the state file to re-create the installation, if, for example you needed to reinstall these components.
-
Download the Java ES software distribution to ps1.
The procedure is documented in To Download the Software Distribution.
-
Log in as root or become superuser.
# su -
-
Start the Java ES installer.
# cd /portdist_71u2/Solaris_sparc
# ./installer
This procedure uses the GUI installer. The installer can also be run in text mode by using the - nodisplay option.
The Welcome panel opens.
-
In the Welcome panel, click Next.
The Software License Agreement panel opens.
-
In the Software License Agreement Panel, review the license terms and click Yes, Accept License.
The Choose Software Components panel opens.
-
In the Choose Software Components panel, select the following components:
-
Application Server Enterprise Edition 8.2 patch 2
-
Domain Administration Server
-
Application Server Node Agent
-
Command Line Administration Tool
-
-
High Availability Session Store 4.4.3 (automatically selected)
-
Java DB 10.2.2.1 (automatically selected)
-
Java DB Client
-
Java DB Server
-
-
Access Manager 7.1
-
Access Manager SDK
-
-
Install Multilingual Package(s) for all selected components (this is selected automatically but optional if using English)
-
-
Click Next.
The Dependency Warning panel opens.
-
In the Dependency Warning panel, choose Use Access Manager 7.1 Installed on a Remote Machine and click OK.
The installer evaluates the Java SE Software Development Kit on the computer and determines if an upgrades is required. On a fresh copy of Solaris 10 8/07 OS, an upgrade is needed, and the Java SE Software Development Kit Upgrade Required panel opens.
-
In the Java SE Software Development Kit Upgrade Required panel select Automatic Upgrade to the Version Included with the Installer and click Next.
The installer evaluates the Java ES shared components on the computer and determines if any upgrades are required. On a fresh copy of the Solaris 10 8/07 OS, shared component upgrades are needed, and the Shared Components Upgrades Required panel opens.
-
In the Shared Components Upgrades Required panel, click Next.
The installer upgrades the shared components. The Specify Installation Directories panel opens.
-
In the Specify Installation Directories panel, type the following values and click Next.
Input Field
Value
Application Server
/opt/SUNWappserver
Application Server Data and Configuration
/var/opt/SUNWappserver
Access Manager
/opt
The installer checks the system, and the System Check panel opens.
-
In the System Check panel, evaluate the results of the system check.
If the system check is favorable, click Next.
The Choose a Configuration Type panel opens.
-
In the Choose a Configuration Type panel, select Configure Now and click Next.
The Custom Configuration Panel opens.
-
In the Custom Configuration Panel, note the following message and click Next.
The following component products cannot be configured during installation: Java DB Click Next to configure the other components.
The Specify Administrator Account Preferences panel opens.
-
In the Specify Administrator Account Preferences Panel, type the following values and click Next.
Input Field
Value
Administrator User ID
admin
Administrator Password
app-server-admin-password
The Common Server Settings Panel opens.
-
In the Common Server Settings panel, type the following values and click Next.
Input Field
Value
Host Name
ps1
DNS Domain Name
pstest.com
Host IP Address
10.0.2.3
System User
root
System Group
root
The High Availability Session Store (HADB) panel opens.
-
In the Application Server:High Availability Session Store (HADB) panel, type the following values and click Next.
Input Field
Value
HADB Management Port
1862
HADB Resource Directory
/var/opt
HADB Administrator Group
root
The Application Server: Domain Administration Server panel opens.
-
In the Application Server: Domain Administration Server panel, type the following values and click Next.
Input Field
Value
Admin Port
4849
JMX Port
8686
HTTP Port
8080
HTTPS Port
8181
Master Password
app-server-master-password
The Application Server: Node Agent panel opens.
-
In the Application Server: Node Agent panel, type the following values and click Next.
Input Field
Value
Admin Host Name
ps1.pstest.com
Master Password
app-server-master-password
Admin Port
4849
Node Agent Name
na-ps1
The Access Manager: Specify Configuration Information panel opens.
-
In the Access Manager: Specify Configuration Information panel, type the following values and click Next.
The following values must match the values that were used when Access Manager was installed on am1 and am2).
Input Field
Value
Install Type
Legacy Mode
Administrator User ID
amAdmin
Administrator Password
access-manager-admin-password
LDAP User ID
amldapuser
LDAP Password
access-manager-LDAP-password
Password Encryption Key
password-enc-key
The Access Manager: Specify Directory Server panel opens.
-
In the Access Manager: Specify Directory Server Information panel, type the following values and click Next.
The following values must match the values that were used when Directory Server was installed on ds1 and ds2, except for the host and port values. Those values must match the directory service load balancer values.
Input Field
Value
Directory Server Host
ds.pstest.com
Directory Server Port
389
Access Manager Directory Root Suffix
dc=pstest,dc=com
Directory Manager DN
cn=Directory Manager
Directory Manager Password
directory-manager-password
The Access Manager: Specify Directory Server Data panel opens.
-
In the Access Manager: Specify Directory Server Data panel, type the following values and click Next.
Input Field
Value
Is Directory Server Provisioned With User Data?
Yes
Organization Marker Object Class
sunISManagedOrganization
Organization Naming Attribute
o
User Marker Object Class
inetorgperson
User Naming Attribute
uid
The Access Manager: Specify Web Container for Running Access Manager Services panel opens.
-
In the Access Manager: Specify Web Container for Running Access Manager Services panel, type the following values and click Next.
Input Field
Value
Remote Host
am.pstest.com
Services Deployment URI
amserver
Cookie Domain
.pstest.com
Remote Services Port
80
Remote Services Protocol
HTTP
The Ready to Install panel opens.
-
In the Ready to Install panel, indicate whether you want to open the software registration window during installation.
This panel enables you to register the components that you have selected for installation with Sun Connection. Sun Connection is a Sun-hosted service that helps you track, organize, and maintain Sun hardware and software. For example, Sun Connection can inform you of the latest available security fixes, recommended updates, and feature enhancements.
If you choose to register, information about the installation is sent to the Sun Connection database. You can also register at a later date, after installation has been completed.
-
Click Install.
The installer copies files to the computer. The installer also configures the Access Manager SDK to interoperate with the Access Manager service and the Directory Server service. The installer also creates an instance of the Application Server Domain Administration Server (DAS) for the default Application Server domain, which is domain1.
-
When the installation is complete, review the installation in the Summary field.
-
Click Exit to exit the installer.
-
Check the installation log files for any installation errors.
# cd /var/sadm/install/logs
# egrep -i 'fail|error' Java*
To Start the Application Server Domain
This procedure starts a Domain Administration Server (DAS) for the default domain (domain1) and the Application Server instance on ps1 in which it runs.
-
Run the start—domain command:
# /opt/SUNWappserver/sbin/asadmin start-domain --user admin domain1
When prompted, type the app-server-admin-password.
The response should indicate that you successfully started the domain:
Domain domain1 started
To Start a Node Agent on ps1
This procedure starts the node agent (na-ps1) on ps1 that was specified during Portal Server installation.
-
Run the start—node—agent command:
# /opt/SUNWappserver/sbin/asadmin start-node-agent --user admin na-ps1
When prompted, type the app-server-admin-password.
The response should indicate that you successfully started a node agent:
Command start-node-agent executed successfully.
To Create a Cluster Configuration
This procedure creates an Application Server cluster (pscluster) in the default domain (domain1). New Application Server instances will be created as members of this cluster on ps1 and ps2. The cluster configuration file must be created before you create the Application Server instances that constitute the cluster.
-
On ps1, run the create—cluster command:
# /opt/SUNWappserver/sbin/asadmin create-cluster --user admin pscluster
When prompted, type the app-server-admin-password.
The response should indicate that you successfully created the cluster and its cluster configuration file, pscluster-config:
Command create-cluster executed successfully.
To Create and Start an Application Server Instance
on ps1
This procedure creates and starts a new Application Server instance (as-cluster-inst-ps1) on ps1, which belongs to pscluster.
-
Create an Application Server instance.
# /opt/SUNWappserver/sbin/asadmin create-instance --user admin --cluster pscluster --nodeagent na-ps1 --systemproperties HTTP_LISTENER_PORT=80 as-cluster-inst-ps1
When prompted, type the app-server-admin-password.
The response should indicate that you successfully created the instance:
Command create-instance executed successfully.
-
Start the instance created in Step 1.
# /opt/SUNWappserver/sbin/asadmin start-instance --user admin as-cluster-inst-ps1
When prompted, type the app-server-admin-password.
The response should indicate that you successfully started the instance:
Command start-instance executed successfully.
Setting Up an Application Server Cluster Node on ps2
This task creates the second node of an Application Server cluster. It consists of the following procedures:
To Install Application Server on ps2
This procedure is very similar to the procedure for installing Application Server on ps1, except that you do not install the Domain Administration Server (DAS) component on ps2 because only one DAS instance is required in an Application Server cluster.
The procedure assumes that you are installing Java ES components on Solaris 10 8/07 OS or later version. Hence, no operating system patches need to be installed. The Java ES installer evaluates the state of the operating system and indicates if you need to install a patch. If you are using versions of the operating system older than Solaris 10 8/07 OS, it is better to install any required patches before you begin the actual Java ES installation procedure.
The following procedure installs Application Server, HADB, Java DB, and Access Manager SDK, all of which are needed to support Portal Server on this computer, and all of which can be configured using the Java ES installer's Configure Now capability. Installation of Portal Server requires custom configuration and is performed in a subsequent procedure (see To Install Portal Server on ps2).
The procedure runs the Java ES installer without saving a state file. You can choose to run the installer and capture your input in a state file (-saveState state-fileName). You could then use the state file to re-create the installation, if, for example you needed to reinstall these components.
-
Download the Java ES software distribution to ps2.
The procedure is documented in To Download the Software Distribution.
-
Log in as root or become superuser.
# su -
-
Start the Java ES installer.
# cd /portdist_71u2/Solaris_sparc
# ./installer
This procedure uses the GUI installer. The installer can also be run in text mode by using the - nodisplay option.
The Welcome panel opens.
-
In the Welcome panel, click Next.
The Software License Agreement panel opens.
-
In the Software License Agreement Panel, review the license terms and click Yes, Accept License.
The Choose Software Components panel opens.
-
In the Choose Software Components panel, select the following components:
-
Application Server Enterprise Edition 8.2 patch 2
-
Application Server Node Agent
-
Command Line Administration Tool
-
-
High Availability Session Store 4.4.3 (automatically selected)
-
Java DB 10.2.2.1 (automatically selected)
-
Java DB Client
-
Java DB Server
-
-
Install Multilingual Package(s) for all selected components (this is selected automatically but optional if using English)
-
-
Click Next.
The Dependency Warning panel opens.
-
In the Dependency Warning panel, choose Use Access Manager 7.1 Installed on a Remote Machine and click OK.
The installer evaluates the Java SE Software Development Kit on the computer and determines if an upgrades is required. On a fresh copy of Solaris 10 8/07 OS, an upgrade is needed, and the Java SE Software Development Kit Upgrade Required panel opens.
-
In the Java SE Software Development Kit Upgrade Required panel select Automatic Upgrade to the Version Included with the Installer and click Next.
The installer evaluates the Java ES shared components on the computer and determines if any upgrades are required. On a fresh copy of the Solaris 10 8/07 OS, shared component upgrades are needed, and the Shared Components Upgrades Required panel opens.
-
In the Shared Components Upgrades Required panel, click Next.
The installer upgrades the shared components. The Specify Installation Directories panel opens.
-
In the Specify Installation Directories panel, type the following values and click Next.
Input Field
Value
Application Server
/opt/SUNWappserver
Application Server Data and Configuration
/var/opt/SUNWappserver
The installer checks the system, and the System Check panel opens.
-
In the System Check panel, evaluate the results of the system check.
If the system check is favorable, click Next.
The Choose a Configuration Type panel opens.
-
In the Choose a Configuration Type panel, select Configure Now and click Next.
The Custom Configuration Panel opens.
-
In the Custom Configuration Panel, note the following message and click Next.
The following component products cannot be configured during installation: Java DB Click Next to configure the other components.
The Specify Administrator Account Preferences panel opens.
-
In the Specify Administrator Account Preferences Panel, type the following values and click Next.
Input Field
Value
Administrator User ID
admin
Administrator Password
app-server-admin-password
The Common Server Settings Panel opens.
-
In the Common Server Settings panel, type the following values and click Next.
Input Field
Value
Host Name
ps2
DNS Domain Name
pstest.com
Host IP Address
10.0.2.4
System User
root
System Group
root
The High Availability Session Store (HADB) panel opens.
-
In the Application Server:High Availability Session Store (HADB) panel, type the following values and click Next.
Input Field
Value
HADB Management Port
1862
HADB Resource Directory
/var/opt
HADB Administrator Group
root
The Application Server: Domain Administration Server panel opens.
-
In the Application Server: Node Agent panel, type the following values and click Next.
Input Field
Value
Admin Host Name
ps1.pstest.com
Master Password
app-server-master-password
Admin Port
4849
Node Agent Name
na-ps2
The Ready to Install panel opens.
-
In the Ready to Install panel, indicate whether you want to open the software registration window during installation.
This panel enables you to register the components that you have selected for installation with Sun Connection. Sun Connection is a Sun-hosted service that helps you track, organize, and maintain Sun hardware and software. For example, Sun Connection can inform you of the latest available security fixes, recommended updates, and feature enhancements.
If you choose to register, information about the installation is sent to the Sun Connection database. You can also register at a later date, after installation has been completed.
-
Click Install.
The installer copies files to the computer. The installer also configures the Access Manager SDK to interoperate with the Access Manager service and the Directory Server service. The installer also creates an instance of the Application Server Domain Administration Server (DAS) for the default Application Server domain, which is domain1.
-
When the installation is complete, review the installation in the Summary field.
-
Click Exit to exit the installer.
-
Check the installation log files for any installation errors.
# cd /var/sadm/install/logs
# egrep -i 'fail|error' Java*
To Start a Node Agent on ps2
This procedure starts the node agent (na-ps2) on ps2 that was specified during Portal Server installation.
-
Run the start—node—agent command:
# /opt/SUNWappserver/sbin/asadmin start-node-agent --user admin na-ps2
When prompted, type the app-server-admin-password.
When prompted, type the app-server-master-password.
The response should indicate that you successfully started a node agent:
Command start-node-agent executed successfully.
To Create and Start an Application Server Instance
on ps2
This procedure creates and starts a new Application Server instance (as-cluster-inst-ps2) on ps2, which belongs to pscluster.
-
Run the create—instance command:
# /opt/SUNWappserver/sbin/asadmin create-instance --user admin --host ps1.pstest.com --cluster pscluster --nodeagent na-ps2 --systemproperties HTTP_LISTENER_PORT=80 as-cluster-inst-ps2
When prompted, type the app-server-admin-password.
The response should indicate that you successfully created the instance:
Command create-instance executed successfully.
-
Run the start—instance command:
# /opt/SUNWappserver/sbin/asadmin start-instance --user admin --host ps1.pstest.com as-cluster-inst-ps2
When prompted, type the app-server-admin-password.
The response should indicate that you successfully started the instance:
Command start-instance executed successfully.
Setting Up a Non-Cluster Application Server Instance on ps1
This task creates an Application Instance on ps1 in which to deploy a Portal Server search instance. The Application Server instance is not part of the Application Server cluster (pscluster) in which the Portal Server instances are to be deployed. The task consists of the following procedure:
To Create and Start a Non-Cluster Application Server
Instance on ps1
This procedure creates and starts a new non-cluster Application Server instance (as-inst-ps1) on ps1, in which a search instance is to be deployed.
-
Create an Application Server instance.
# /opt/SUNWappserver/sbin/asadmin create-instance --user admin --nodeagent na-ps1 --systemproperties HTTP_LISTENER_PORT=5050 as-inst-ps1
When prompted, type the app-server-admin-password.
The response should indicate that you successfully created the instance:
Command create-instance executed successfully.
-
Start the instance created in Step 1.
# /opt/SUNWappserver/sbin/asadmin start-instance --user admin as-inst-ps1
When prompted, type the app-server-admin-password.
The response should indicate that you successfully started the instance:
Command start-instance executed successfully.
Setting Up Portal Server on ps1
This task consists of the following procedures:
To Install Portal Server on ps1
This procedure assumes that you are installing Portal Server on Solaris 10 8/07 OS or later version. Hence, no operating system patches need to be installed. The Java ES installer evaluates the state of the operating system and indicates if you need to install a patch. If you are using versions of the operating system older than Solaris 10 8/07 OS, it is better to install any required patches before you begin the actual Portal Server installation procedure.
This procedure runs the Java ES installer in Configure Later mode. After installation is complete, you manually configure a Portal Server instance to run in the Application Server cluster instance (as-cluster-inst-ps1).
The following procedure runs the Java ES installer without saving a state file. You can choose to run the installer and capture your input in a state file (-saveState state-filename). You could then use the state file to re-create the installation if, for example, you needed to reinstall Portal Server.
-
On ps1, navigate to the directory with the unzipped installer.
# cd /portdist_71u2/Solaris_sparc
-
Start the Java ES installer.
# ./installer
This procedure uses the GUI installer. The installer can also be run in text mode by using the - nodisplay option.
The Welcome panel opens.
-
In the Welcome panel, click Next.
The Software License Agreement panel opens.
-
In the Software License Agreement Panel, review the license terms and click Yes, Accept License.
The Choose Software Components panel opens.
-
In the Choose Software Components panel, select the following components:
-
Portal Server 7.1
-
Netlet Proxy
-
Rewriter Proxy
-
-
Portal Server Secure Remote Access 7.1
-
Service Registry 3.1
-
Service Registry Client Support
-
Unselect Access Manager and Directory Server, which are automatically selected by the installer.
Note –Service Registry is used by Portal Server to support the Web Services for Remote Portals (WSRP) standard, in particular the WSRP producer implementation, which enables the publishing of portlets for use by remote WSRP consumers. Because the dependency on Service Registry is for such a specialized capability, installation of Service Registry is optional. For that reason, Service Registry was not included in the logical and deployment architectures of the reference configuration.
-
-
Click Next.
The Dependency Warning panel opens.
-
In the Dependency Warning panel, choose Use Access Manager 7.1 Installed on a Remote Machine and click OK.
The Specify Installation Directories panel opens.
-
In the Specify Installation Directories panel, type the following values and click Next.
Input Field
Value
Portal Server
/opt
Service Registry
/opt
The installer checks the system, and the System Check panel opens.
-
In the System Check panel, evaluate the results of the system check.
If the system check is favorable, click Next.
The Choose a Configuration Type panel opens.
-
In the Choose a Configuration Type panel, select Configure Later and click Next.
The Ready to Install Panel opens.
Note –When you select the Configure Later option, Portal Server and Service Registry files will be copied to the computer, but no configuration takes place. You must configure these components after installation is complete.
For example, the Configure Now option would have automatically deployed Portal Server in the default Domain Administration Server instance. However, you want instead to deploy Portal Server in a clustered Application Server instance. Therefore, you install in Configure Later mode, and subsequently create the Portal Server instance and deploy it to the Application Server cluster instance, as-cluster-inst-ps1.
-
In the Ready to Install panel, indicate whether you want to open the software registration window during installation.
This panel enables you to register the components that you have selected for installation with Sun Connection. Sun Connection is a Sun-hosted service that helps you track, organize, and maintain Sun hardware and software. For example, Sun Connection can inform you of the latest available security fixes, recommended updates, and feature enhancements.
If you choose to register, information about the installation is sent to the Sun Connection database. You can also register at a later date, after installation has been completed.
-
Click Install.
The installer copies files to the computer.
-
When the installation is complete, review the installation in the Summary field.
-
Click Exit to exit the installer.
-
Check the installation log files for any installation errors.
# cd /var/sadm/install/logs
# egrep -i 'fail|error' Java*
To Create a Portal Server Instance on ps1
This procedure uses the psconfig command and a configuration file to create a portal (pstestPortal) as well as a Portal Server instance (ps-inst-ps1) and a search instance (search-inst-ps1) that are both associated with the portal. The procedure deploys the search instance into the non-cluster Application Server instance on ps1 (as-inst-ps1) and the portal Server instance into all instances in Application Server cluster (pscluster).
You begin with an appropriate example configuration file as a template and edit the file to specify parameter values that are needed for the reference configuration.
-
Create a config-ps1 configuration file.
Use the example14.xml file as a template.
# cd /opt/SUNWportal/samples/psconfig
# cp example14.xml config-ps1.xml
-
Open the config-ps1.xml file in a text editor.
-
Modify config-ps1.xml to use the non-default values in the following table:
Parameter
Value
AdministratorUserPassword (@ADMIN.PASSWORD@)
access-manager-admin-password
LDAPUserIdPassword (@AMLDAP.PASSWORD@)
access-manager-LDAP-password
DirectoryManagerPassword (@DIRMGR.PASSWORD@)
directory-manager-password
SearchServerID
search-inst-ps1
Host (@HOST.DOMAIN@)
ps1.pstest.com
Port (Search instance)
5050
WebContainerInstanceName (Search instance)
as-inst-ps1
WebContainerInstanceDir (Search instance)
/var/opt/SUNWappserver/nodeagents/na-ps1/as-inst-ps1
WebContainerDocRoot (Search instance)
/var/opt/SUNWappserver/nodeagents/na-ps1/as-inst-ps1/docroot
WebContainerAdminPort (@ADMIN.PORT@)
4849
WebContainerAdminPassword (@PASSWORD@)
app-server-admin-password
WebContainerMasterPassword (@MASTER.PASSWORD@)
app-server-master-password
PortalAccessURL
http://ps.pstest.com:80/portal
PrimaryPortalHost
ps1.pstest.com
PortalID
pstestPortal
InstanceID (Portal Server instance)
ps-inst-ps1
Port (Portal Server instance)
80
WebContainerInstanceName (Portal Server instance)
pscluster
WebContainerInstanceDir (Portal Server instance)
/var/opt/SUNWappserver/nodeagents/na-ps1/as-cluster-inst-ps1
WebContainerDocRoot (Portal Server instance)
/var/opt/SUNWappserver/nodeagents/na-ps1/as-cluster-inst-ps1/docroot
-
Save the modified config-ps1.xml file.
The modified file is reproduced in Example Configuration File: Portal Server Instance on ps1.
-
Run the psconfig command.
# /opt/SUNWportal/bin/psconfig --config /opt/SUNWportal/samples/psconfig/config-ps1.xml
The response should resemble the following:
Successfully created PSConfig.properties file Copying config templates from: /opt/SUNWportal/template/config Successfully created PortalDomainConfig.properties file Validating the Input Config XML File Configuring Cacao Agent for Portal Software Configuring Derby Server Instance Connecting to Cacao MBean Server Creating Portals Domain domain1 started Successfully created Portal: pstestPortal Configuring Samples
To Modify the Configuration of the Portal Server Instance
on ps1
The previous procedure deployed Portal Server by using pscluster as the target Application Server instance. The instance.id entry, however, needs to be targeted to as-cluster-inst-ps1, rather than to the cluster. The following procedure removes this entry from the pscluster configuration and adds it to the as-cluster-inst-ps1 configuration.
-
Remove the instance.id entry from the cluster configuration.
# /opt/SUNWappserver/sbin/asadmin delete-jvm-options --user admin --target pscluster "-Dcom.sun.portal.instance.id=ps-inst-ps1"
When prompted, type the app-server-admin-password.
The response should indicate that you successfully removed the instance from the cluster configuration:
Command delete-jvm-options executed successfully.
-
Add the instance.id entry to the as-cluster-inst-ps1 configuration.
# /opt/SUNWappserver/sbin/asadmin create-system-properties --user admin --target as-cluster-inst-ps1 com.sun.portal.instance.id=ps-inst-ps1
When prompted, type the app-server-admin-password.
The response should indicate that you successfully added Portal Server instance information to the Application Server instance on ps1:
Command create-system-properties executed successfully.
-
Restart the pscluster cluster.
The cluster needs to be restarted for changes in configuration to take effect.
# /opt/SUNWappserver/sbin/asadmin stop-cluster --user admin pscluster
# /opt/SUNWappserver/sbin/asadmin start-cluster --user admin pscluster
To Start and Verify Portal Server on ps1
You start the Portal Server instance by restarting the Application Server instance (as-cluster-inst-ps1) in which it is deployed. You then verify that the instance is running by accessing the portal Welcome page in a browser.
-
Stop the Application Server instance.
# /opt/SUNWappserver/sbin/asadmin stop-instance --user admin as-cluster-inst-ps1
When prompted, type the app-server-admin-password.
The response should indicate that you successfully stopped the instance:
Command stop-instance executed successfully.
-
Restart the Application Server instance.
# /opt/SUNWappserver/sbin/asadmin start-instance --user admin as-cluster-inst-ps1
When prompted, type the app-server-admin-password.
The response should indicate that you successfully started the instance:
Command start-instance executed successfully.
-
Verify that the Portal Server instance is running.
Setting Up Portal Server on ps2
This task consists of the following procedures:
To Install Portal Server on ps2
To properly set up Portal Server on ps2, Access Manager SDK must be configured manually. As a result, Access Manager SDK is installed with Portal Server on ps2 using the Configure Later option of the installer rather than being installed with Application Server using the Configure Now option (as it was on ps1).
-
Repeat the procedure that appears in To Install Portal Server on ps1, except for the following:
In the Choose Software Components panel (Step 5), select the following components:
-
Portal Server 7.1
-
Netlet Proxy
-
Rewriter Proxy
-
-
Portal Server Secure Remote Access 7.1
-
Access Manager 7.1
-
Access Manager SDK
-
-
Service Registry 3.1
-
Service Registry Client Support
-
Unselect Directory Server, which is automatically selected by the installer.
-
To Configure Access Manager SDK on ps2
Because Access Manager SDK was installed using the Configure Later option, you need to configure Access Manager SDK by modifying Access Manager configuration files. The standard approach for making these modifications is to run the amconfig command with an input file.
-
Change to the directory that contains the amconfig input file template, amsamplesilent.
# cd /opt/SUNWam/bin
-
Copy the template to a new file.
# cp amsamplesilent amconfigps2
-
In a text editor, edit the amconfigps2 file to set the Access Manager SDK configuration parameters.
Locate the configuration parameters that are listed in the following table, and change their values to the values shown in the table.
Parameter
Value
DEPLOY_LEVEL
4
SERVER_Name
am
SERVER_HOST
am.pstest.com
SERVER_PORT
80
ADMIN_PORT
4849
DS_HOST
ds.pstest.com
DS_DIRMGRPASSWD
directory-manager-password
ROOT_SUFFIX
"dc=pstest,dc=com"
ADMINPASSWD
access-manager-admin-password
AMLDAPUSERPASSWD
access-manager-LDAP-password
COOKIE_DOMAIN
pstest.com
AM_ENC_PWD
password-enc-key
NEW_OWNER
root
NEW_GROUP
other
PAM_SERVICE_NAME
other
AS81_INSTANCE
pscluster
AS81_INSTANCE_DIR
/var/opt/SUNWappserver/nodeagents/na-ps2/as-cluster-inst-ps2
AS81DOCS_DIR
/var/opt/SUNWappserver/nodeagents/na-ps2/as-cluster-inst-ps2/docroot
-
Run the amconfig command with the input file you modified in Step 3.
# /opt/SUNWam/bin/amconfig -s amconfigps2
The output should show failures after checking if Application Server is already configured with Access Manager. These errors are expected because the Access Manager configuration was already added to the Application Server cluster configuration when Access Manager SDK was installed and configured on ps1.
-
Verify that the Access Manager SDK is properly configured.
# /opt/SUNWam/bin/amadmin —u amadmin —m http://am.pstest.com:80
When prompted, type the access-manager-admin-password.
The output should show current session information.
To Create a Portal Server Instance on ps2
When you created a Portal Server instance (ps-inst-ps1) on ps1 (see To Create a Portal Server Instance on ps1), you deployed Portal Server to pscluster and created additional portal and instance configuration information on ps1.
To create a Portal Server instance (ps-inst-ps2) on ps2, you need to set up the portal's administrative infrastructure that is needed to copy the portal and instance configuration information from ps1 to ps2.
In addition, before you can use the portal's administrative interface to create ps-inst-ps2, you must remove ps_util.jar from the pscluster classpath, as described in the following procedure. If you try to run the psadmin -create-instance command without first removing ps_util.jar, psadmin will detect the presence of ps_util.jarand exit without creating a new instance.
The following procedure sets up the portal's administrative infrastructure, removes ps_util.jar from the pscluster classpath, creates a custom configuration file for creating ps-inst-ps2, and then uses the psadmin -create-instance command to create the new instance.
You begin with an appropriate example configuration file as a template and edit the file to specify parameter values that are needed for the reference configuration.
-
Set up the portal's administrative infrastructure.
-
Create a config-ps2 configuration file.
Use the example2.xml file as a template.
# cd /opt/SUNWportal/samples/psconfig
# cp example2.xml config-ps2.xml
-
Open the config-ps2.xml file in a text editor.
-
Modify the config-ps2.xml file to use parameter values that are appropriate for the reference configuration.
The modified config-ps2.xml file is reproduced in Example Configuration File: Portal Server Instance on ps2.
-
Run the psconfig command:
# /opt/SUNWportal/bin/psconfig --config /opt/SUNWportal/samples/psconfig/config-ps2.xml
The response should resemble the following:
Logs redirected to /var/opt/SUNWportal/logs/config/portal.fabric.0.0.log Creating directory: /etc/opt/SUNWportal Successfully created PSConfig.properties file Copying config templates from: /opt/SUNWportal/template/config Successfully created PortalDomainConfig.properties file Validating the Input Config XML File Configuring Cacao Agent for Portal Software Configuring Derby Server Instance Closing MBean Server connection ... Resetting log level ... Configuration Successful
-
-
Remove ps_util.jar from the pscluster classpath.
-
Start a browser.
-
Go to the following URL:
https://ps1.pstest.com:4849
The Application Server login page opens.
-
Log in to the Application Server Admin Console by typing the following values and clicking Login.
Input Field
Value
User ID
admin
Password
app-server-admin-password
The Application Server Admin Console opens.
-
Click on the small triangle next to Configurations on the Common Tasks panel.
The configurations are expanded.
-
Click on the small triangle next to pscluster-config.
The pscluster configuration is expanded.
-
Click on JVM Settings.
The frame on the right shows the configuration options.
-
In the right frame, select the Path Settings tab.
The JVM Classpath Settings panel opens.
-
Remove /opt/SUNWportal/lib/ps_util.jar from the Classpath Suffix list.
-
Click Save.
-
Restart the pscluster cluster.
The cluster needs to be restarted for the change in configuration to take effect. The following commands are run on ps2, but can also be run on ps1 without using the --host option.
# /opt/SUNWappserver/sbin/asadmin stop-cluster --user admin --host ps1.pstest.com pscluster
# /opt/SUNWappserver/sbin/asadmin start-cluster --user admin --host ps1.pstest.com pscluster
-
-
Create a custom configuration file to use when creating a new Portal Server instance.
-
Copy the configuration template to a new file.
# cd /opt/SUNWportal/template
# cp Webcontainer.properties.SJSAS81 Webcontainer.properties.ps-inst-ps2
-
Open Webcontainer.properties.ps-inst-ps2 in a text editor.
-
Set the parameters that are listed in the following table.
Parameter
Value
Host
ps2.pstest.com
Port
80
Scheme
http
WebContainerInstallDir
/opt/SUNWappserver/appserver
WebContainerInstanceName
pscluster
WebContainerDomainName
domain1
WebContainerInstanceDir
/var/opt/SUNWappserver/nodeagents/na-ps2/as-cluster-inst-ps2
WebContainerDocRoot
/var/opt/SUNWappserver/nodeagents/na-ps2/as-cluster-inst-ps2/docroot
WebContainerAdminHost
ps1.pstest.com
WebContainerAdminPort
4849
WebContainerAdminScheme
https
WebContainerAdminPassword
app-server-admin-password
WebContainerMasterPassword
app-server-master-password
-
Save your changes and close the file.
-
-
Create a new Portal Server instance.
Execute the following command on ps2:
# /opt/SUNWportal/bin/psadmin create-instance -u amadmin -p pstestPortal --instance ps-inst-ps2 --webconfig Webcontainer.properties.ps-inst-ps2
To Modify the Configuration of the Portal Server Instance
on ps2
The previous procedure deployed Portal Server by using pscluster as the target Application Server instance. The instance.id entry, however, needs to be targeted to as-cluster-inst-ps2, rather than to the cluster. The following procedure removes this entry from the pscluster configuration and adds it to the as-cluster-inst-ps2 configuration.
The following commands are run on ps2, but can also be run on ps1 without using the --host option.
-
Remove the instance.id entry from the cluster configuration.
# /opt/SUNWappserver/sbin/asadmin delete-jvm-options --user admin --target pscluster "-Dcom.sun.portal.instance.id=ps-inst-ps2" --host ps1.pstest.com
When prompted, type the app-server-admin-password.
The response should indicate that you successfully removed the instance from the cluster configuration:
Command delete-jvm-options executed successfully.
-
Add the instance.id entry to the as-cluster-inst-ps2 configuration.
# /opt/SUNWappserver/sbin/asadmin create-system-properties --user admin --target as-cluster-inst-ps2 com.sun.portal.instance.id=ps-inst-ps2 --host ps1.pstest.com
When prompted, type the app-server-admin-password.
The response should indicate that you successfully added Portal Server instance information to the Application Server instance on ps2:
Command create-system-properties executed successfully.
-
Restart the pscluster cluster.
The cluster needs to be restarted for changes in configuration to take effect.
# /opt/SUNWappserver/sbin/asadmin stop-cluster --user admin pscluster --host ps1.pstest.com
# /opt/SUNWappserver/sbin/asadmin start-cluster --user admin pscluster --host ps1.pstest.com
To Start and Verify Portal Server on ps2
You start the Portal Server instance by restarting the Application Server instance (as-cluster-inst-ps2) in which it is deployed. You then verify that the instance is running by accessing the portal Welcome page in a browser.
-
Stop the Application Server instance.
# /opt/SUNWappserver/sbin/asadmin stop-instance --user admin as-cluster-inst-ps2
When prompted, type the app-server-admin-password.
The response should indicate that you successfully stopped the instance:
Command stop-instance executed successfully.
-
Restart the Application Server instance.
# /opt/SUNWappserver/sbin/asadmin start-instance --user admin as-cluster-inst-ps2
When prompted, type the app-server-admin-password.
The response should indicate that you successfully started the instance:
Command start-instance executed successfully.
-
Verify that the Portal Server instance is running.
Implementing Load Balancing for the Portal Service
This task consists of the following procedures:
To Configure the Load Balancer for the Portal Service
This procedure describes how to configure the portal service load balancer (ps.pstest.com at IP address 10.0.3.11). The steps are relatively generic; the details depend on the load balancer you are using.
-
Populate the load balancer's Hosts Table.
Add the IP address for ps1.pstest.com and ps2.pstest.com to the load balancer's hosts table.
-
Populate the load balancer's Real Service Table.
Add the real services for ps1.pstest.com and ps2.pstest.com. A real service is identified by its IP address and port. Add 10.0.2.3:80 and 10.0.2.4:80.
-
Populate the load balancer's Service Group Table.
Add the service group for portal services. The service groups are sets of the real services that you defined in Step 2. The real services in the group must be capable of fulfilling the same type of request. The load balancer will distribute requests among the real services in the service group. When you define the service group for the ps.pstest.com, you add the real services that specify the Portal Server instances, 10.0.2.3:80 and 10.0.2.4.80.
-
Populate the load balancer's Virtual IP Table
A virtual service definition includes the outward-facing IP address and the port at which the load balancer accepts requests for a service, as well as the service group that you specified in Step 3, which actually handles the requests. The load balancer will accept requests at the virtual service address and distribute them among the service group. The virtual service definition for the Portal Server service should be ps.pstest.com, with the virtual IP address of 10.0.3.11:80, and with the service group consisting of the computers ps1.pstest.com and ps2.pstest.com.
-
Configure the load balancer to use Layer-7 (HTTP layer) load balancing.
-
Configure the load balancer with a scheduling type of either least connections or round robin.
Both scheduling types initially distribute the connections evenly between the Portal Server instances. Both scheduling types keep the connections evenly distributed if the connections are restarted.
-
Configure the load balancer for sticky routing.
The portal service load balancer must maintain session persistence; it must route all user requests subsequent to the first request, to the same Portal Server instance (except in the case of failure).
There are two options for sticking the user's portal session to the same Portal Server instance:
-
Load balancer passive cookies (also known as managed cookies). If your load balancer has this feature, it is the preferred solution.
-
Portal Server provides a mechanism analogous to the Access Manager's amlbcookie. You can specify the name of a cookie (for example, pslbcookie) in the lb.cookie.name property of the following file on both ps1 and ps2: /var/opt/SUNWportal/portals/pstestPortal/config/desktopconfig.properties
Each Portal Server instance assigns a value to this cookie at runtime. The value, which identifies the Portal Server instance, has the following syntax:
<portalID>.<instanceID>
For example, in the reference configuration, the value of the cookie for ps1.pstest.com will be pstestPortal.ps-inst-ps1 and for ps2.pstest.com the value will be pstestPortal.ps-inst-ps2.
The load balancer is configured for session persistence using this cookie.
-
-
Configure the health-check settings for the load balancer.
The recommended settings are specified in Table 3–5.
To Verify Load Balancing for the Portal Service
This procedure verifies that you can interact with Portal Server instances through the load balancer and that the load balancer provides service failover when a Portal Server instance fails.
-
Configure the Portal Server instances on ps1 and ps2 to support session cookies.
Portal Server provides a mechanism that is analogous to the Access Manager's amlbcookie in which you can specify the name of a session cookie, as follows:
-
In a text editor, open the following configuration file:
/var/opt/SUNWportal/portals/pstestPortal/config/desktopconfig.properties
-
Specify the name of a session cookie, as follows:
lb.cookie.name=pslbcookie
Each Portal Server instance assigns a value to this cookie at runtime. The value, which identifies the Portal Server instance, has the following syntax:
<portal ID>.<instance ID>
-
-
Restart the Portal Server instances on ps1 and ps2 by restarting the Application Server instances in which they are deployed.
See To Start and Verify Portal Server on ps1 and To Start and Verify Portal Server on ps2.
-
Log in to the DeveloperSample desktop.
-
Open the portal service in a browser.
Use the load balancer URL:
http://ps.pstest.com/portal
The portal Welcome page opens.
-
On the Samples box, click on the DeveloperSample.
The anonymous desktop for the DeveloperSample should be displayed.
-
Log in by typing the following values and clicking Login.
Input Field
Value
User ID
developer
Password
developer
The DeveloperSample desktop is displayed.
-
-
Determine which Portal Server instance handled the login request in Step 3.
You can determine the instance by opening the pslbcookie cookie in your browser and checking it's instance ID value. For example in the Firefox browser, do the following:
-
Choose Edit->Preferences->Privacy->Show Cookies.
-
Select the pstest.com portal.
-
Select the pslbcookie cookie.
-
Note the instance ID in the Content field.
For example, the value of the cookie for ps1.pstest.com will be pstestPortal.ps-inst-ps1, and for ps2.pstest.com the value will be pstestPortal.ps-inst-ps2.
-
-
Simulate a failure of the Portal Server instance that was noted in Step 4.
Failure of an Portal Server instance can result from a computer failure, a software failure, or a network failure. The method employed for simulating a failure in this service failover verification procedure is to shut down the Portal Server instance (by shutting down the Application Server instance in which it runs). Additionally, you could also simulate failure by unplugging the network cable or disabling the interface.
Run the following command on the computer (ps1 or ps2) hosting the instance identified in Step 2.
# /opt/SUNWappserver/sbin/asadmin stop-instance --user admin as-cluster-inst-ps1|ps2
When prompted, type the app-server-admin-password.
-
Repeat Step 3, above (log in to the DeveloperSample desktop).
If service failover is working correctly, the portal Welcome page opens, confirming that the load balancer has routed the login request to the remaining online Portal Server instance.
-
Recover the simulated failure of your original Portal Server instance.
Restart the Application Server instance that was shut down in Step 5.
# /opt/SUNWappserver/sbin/asadmin ststt-instance --user admin as-cluster-inst-ps1|ps2
When prompted, type the app-server-admin-password.
Implementing Portlet Session Failover
The following procedures use of an example portlet(PortletSessionCounter) to demonstrate how to set up and test portlet session failover. PortletSessionCounter is a portlet that stores session state information. In particular, it counts the number of times a user interacts with the portlet by accessing the developer desktop.
To implement portlet session failover, you first enable high availability for the Application Server cluster in which your Portal Server instances are running. You then deploy and set up high availability for the portlet. As a result, session state information that is created by the portlet will be saved in the Application Server's High Availability Session Store (HADB). If a Portal Server instance fails, the session state information is made available to a failover Portal Server instance.
This section consists of the following procedures.
To Configure the Availability Service for pscluster
To implement portlet session failover, you must first create an HADB cluster and configure Application Server availability service settings for pscluster, as described in this procedure.
-
Create an HADB cluster and add it to your Application Server cluster.
Run the following command on either ps1 or ps2:
# /opt/SUNWappserver/sbin/asadmin configure-ha-cluster --user admin --hosts ps1.pstest.com,ps2.pstest.com pscluster
When prompted, type the app-server-admin-password.
-
Start the Application Server Admin Console.
-
Start a browser.
-
Go to the following URL:
https://ps1.pstest.com/4849
The Application Server Admin Console login page opens.
-
Log in to the Application Server Admin Console by typing the following values and clicking Login.
Input Field
Value
User ID
admin
Password
app-server-admin-password?
The Application Server Admin Console opens.
-
-
Modify Availability Service settings.
-
Click on the small triangle next to Configurations in the left pane under Common Tasks.
The configurations are expanded.
-
Click on the small triangle next to pscluster-config.
The pscluster configuration is expanded.
-
Click on the Availability Service.
The Availability Service settings are displayed in the right pane.
-
Type the Availability Service settings shown in the following table.
Input Field
Value
Availability Service
Enabled
Store Pool Name
pscluster-hadb-pool
Ha-agent-hosts
10.0.2.3, 10.0.2.4
Ha-agent-ports
1862
Ha-db-name
pscluster
-
Click Save.
-
-
Close the Console.
-
Verify that HADB is working and that ps1 and ps2 are part of the HADB cluster.
-
Check the HADB status.
# /opt/SUNWhadb/4.4.3-5/bin/hadbm status pscluster
When prompted, type the app-server-admin-password.
The status of the pscluster high availability database should be FaultTolerant.
Database Status pscluster FaultTolerant
-
Check that ps1 and ps2 are part of the HADB cluster.
# /opt/SUNWhadb/4.4.3-5/bin/hadbm status --nodes pscluster
When prompted, type the app-server-admin-password.
When prompted, type the app-server-master-password.
All Application Server nodes should be in the running state.
NodeNo HostName Port NodeRole NodeState MirrorNode 0 ps1.pstest.com 15200 active running 1 1 ps2.pstest.com 15220 active running 0
-
To Set Up Session Failover for a Portlet
This procedure uses an example Session Counter portlet to demonstrate how to set up portlet session failover. Using this example, the procedure describes how to deploy a portlet into the pstestPortlet portal, enable high availability for the portlet, and create a desktop channel for the portlet.
-
Download the Session Counter portlet from the Open Portal Portlet Repository site:
https://portlet-repository.dev.java.net/public/Download.html
The sessioncounter.war file is downloaded.
-
Deploy the Session Counter portlet to DeveloperSample in the pstestPortal portal.
# /opt/SUNWportal/bin/psadmin deploy-portlet -u amadmin -d o=DeveloperSample,dc=pstest,dc=com -p pstestPortal sessioncounter.war
When prompted, type the access-manager-admin-password.
-
Enable high availability for the Session Counter portlet.
# /opt/SUNWappserver/sbin/asadmin set --user admin "domain.applications.web-module.sessioncounter.availability-enabled=true"
When prompted, type the app-server-admin-password.
-
Enable high availability for the Portal web application.
# /opt/SUNWappserver/sbin/asadmin set --user admin "domain.applications.web-module.portal.availability-enabled=true"
When prompted, type the app-server-admin-password.
-
Create a channel for the Session Counter portlet.
-
Create a display profile for the Session Counter portlet.
Save the display profile document in Example Display Profile: Session Counter Portlet to /tmp/developer-dp.xml.
-
Add the display profile to the developer user.
# /opt/SUNWportal/bin/psadmin add-display-profile -u amadmin -d uid=developer,ou=People,o=DeveloperSample,dc=pstest,dc=com -p pstestPortal /tmp/developer-dp.xml
When prompted, type the access-manager-admin-password.
-
To Verify Portlet Session Failover
In this procedure, you exercise the Session Counter portlet by successively reloading the developer desktop page in a browser. You first exercise the portlet while the Portal Server instance on ps2 is shut down, noting the session counter value. You then restart the Portal Server instance on ps2 and simulate a failure of the Portal Server instance on ps1so that the portal service fails over to the instance on ps2.
You then continue to refresh the browser and note the session counter value. If portlet session failover is working properly, the session counter value should continue to increase from its value before the failover occurred. If the session counter value is reset to 1, then session failover is not working.
-
Make sure that ps-inst-ps1 on ps1 is running and that ps-inst-ps2 on ps2 is shut down.
-
Start ps-inst-ps1 by starting the Application Server instance on ps1 in which it is deployed.
# /opt/SUNWappserver/sbin/asadmin start-instance --user admin as-cluster-inst-ps1
When prompted, type the app-server-admin-password.
-
Shut down ps-inst-ps2 by shutting down the Application Server instance on ps2 in which it is deployed.
# /opt/SUNWappserver/sbin/asadmin stop-instance --user admin as-cluster-inst-ps2
When prompted, type the app-server-admin-password.
-
-
Create a portlet session on ps1.
You create a session by accessing the Session Counter portlet on the Developer Sample desktop, as follows:
-
Open the portal service in a browser:
http://ps.pstest.com/portal
-
On the Samples box, click on the DeveloperSample.
The anonymous desktop for the DeveloperSample should be displayed.
-
Log in by typing the following values and clicking Login.
Input Field
Value
User ID
developer
Password
developer
The DeveloperSample desktop is displayed.
-
Click the Portlet Samples tab.
-
Look at the Session Counter channel.
The channel should show (in addition to other information):
Counter Value in Session is 1.
-
-
Click Reload in your browser.
Now the Session Counter channel should show:
Counter Value in Session is 2.
Every time you reload the desktop page, the counter value will increase.
-
Start ps-inst-ps2.
# /opt/SUNWappserver/sbin/asadmin start-instance --user admin as-cluster-inst-ps2
-
Simulate a failure of ps-inst-ps1.
In the configuration interface for your load balancer (ps.pstest.com), remove the real server instance, ps-inst-ps1, from the service group.
-
Click Reload in your browser.
Now the Session Counter channel should show:
Counter Value in Session is N.
Where the value of N is one integer greater than the last value in Step 3.
If session failover is not working, then the channel would show:
Counter Value in Session is 1.
-
Recover the simulated failure of the ps-inst-ps1 instance.
Return to the configuration interface for your load balancer, and re-enable the instance.
Tuning Portal Server Instances
Consider the following issues when tuning Portal Server instances to maximize performance:
Impact of Java DB on Performance
The Portal Service on Application Server Cluster reference configuration includes an instance of Java DB running on ps1. Java DB is the default database used to store configuration and membership data for Portal Server's community feature. Java DB is also used by portlet applications such as wiki, fileshare, and survey.
However, the use of Java DB has an impact on the overall performance of Portal Server. If you do not need the community feature and are not using a portlet application that requires Java DB, you can improve portal service performance by disabling the use of Java DB by the portal desktop and then shutting down the database.
Caution – Be careful not to shut down Java DB without disabling Java DB for the desktop, as this action seriously degrades performance.
This section consists of the following procedures:
To Disable the Use of Java DB by the Desktop
-
On ps1, change to the following directory:
# cd /var/opt/SUNWportal/portals/portal-ID/config
-
Edit the communitymc.properties file.
Remove the jdo entry from the manager.contributors list.
-
Restart the Portal Server instance by restarting the Application Server instance in which it is deployed.
-
Stop the Application Server instance.
# /opt/SUNWappserver/sbin/asadmin stop-instance --user admin as-cluster-inst-ps1
When prompted, type the app-server-admin-password.
The response should indicate that you successfully stopped the instance:
Command stop-instance executed successfully.
-
Start the Application Server instance.
# /opt/SUNWappserver/sbin/asadmin start-instance --user admin as-cluster-inst-ps1
When prompted, type the app-server-admin-password.
The response should indicate that you successfully started the instance:
Command start-instance executed successfully.
-
-
Repeat Steps 1 through 3 on ps2, except for the following:
Replace all occurrences of ps1 with ps2, including the instance ID (replacing ps-inst-ps1 with ps-inst-ps2).
To Shut Down Java DB
This procedure is performed only on ps1 where the Java DB instance is running (see Figure 6–1).
-
Run the following command on ps1:
# java -cp /opt/SUNWjavadb/lib/derbynet.jar org.apache.derby.drda.NetworkServerControl shutdown
Tuning Application Server Instances
Portal Server performs best when the web container in which it runs is tuned to optimize Portal Server performance. So, you must tune the Application Server instances that host Portal Server. For this module, Portal Server runs in the Application Server instances in the pstest cluster.
In the portal service reference configuration, no other component or application besides Portal Server runs in the Application Server instance. However, if you run other components or applications in the same Application Server instance, then be aware that optimizing the Application Server instance for Portal Server might negatively impact the performance of other components.
This section consists of the following procedures:
-
To Tune the Application Server Instance for Portal Server on ps1
-
Tune the Application Server Instance for Portal Server on ps2
To Tune the Application Server Instance for Portal
Server on ps1
Tuning the Application Server instances that host Portal Server is performed by using the perftune utility. This utility runs the amtune utility and also performs some tuning of Portal Server thread usage. For additional information about amtune, see Part I, Basic Performance Tuning, in Sun Java System Access Manager 7.1 Performance Tuning and Troubleshooting Guide.
-
On ps1, change to the following directory:
# cd /opt/SUNWam/bin/amtune
-
Open the amtune-env file in a text editor.
-
Confirm, or if necessary, modify the following values and save the changes.
WEB_CONTAINER=AS8 ASADMIN_PORT=80 DOMAIN_NAME=pstest.com AMTUNE_PCT_MEMORY_TO_USE=100 AMTUNEAMTU_MIN_PERM_SIZE_AS8=128 AMTUNE_TUNE_WEB_CONTAINER=false AMTUNE_MODE=REVIEW
Also, change all variables that are named CONTAINER_* to point to the as-cluster-inst-ps1 instance:
CONTAINER_*=/var/opt/SUNWappserver/nodeagents/ps1.pstest.com/as-cluster-inst-ps1
Note –In a Solaris zones deployment, also set AMTUNE_TUNE_OS=false.
-
Run the perftune utility.
# /opt/SUNWportal/bin/perftune directory-manager-password app-server-admin-password
The utility proposes suggested changes.
-
Review the suggested changes.
If no undesired changes are proposed, continue to the next step.
-
Modify the amtune-env file with the following value and save the changes.
AMTUNE_MODE=CHANGE
-
Repeat Step 4.
The utility will make all the changes proposed in Step 4.
-
Restart the computer.
Restarting the computer will affect changes to the operating system.
-
Start the Portal Server instance.
Starting Portal Server will affect changes made to the web container. You start Portal Server by starting the Application Server instance in which it is deployed.
# /opt/SUNWappserver/sbin/asadmin start-instance --user admin as-cluster-inst-ps1
When prompted, type the app-server-admin-password.
The response should indicate that you successfully started the instance:
Command start-instance executed successfully.
To Tune the Application Server Instance for Portal
Server on ps2
-
Repeat the procedure in To Tune the Application Server Instance for Portal Server on ps2, except for the following:
Replace all occurrences of ps1 with ps2.
Taking a Snapshot of the Module
When you have completed deploying the portal service module of the reference configuration, and before you move on to the next module, it is good practice to take a snapshot of the data in the Directory Server instance. By exporting ds-inst-ds1, you preserve the current state of your deployment in case you subsequently need to roll back directory information to this point in the reference configuration deployment process. The directory serves as the repository for service and user configuration information and therefore changes as each reference configuration module is deployed.
To take a snapshot of the directory on ds1
In this procedure you use the db2ldif command to export the directory to an ldif file. If you want to subsequently restore the directory, use an equivalent procedure with the ldif2db command.
-
On ds1 change directory as follows:
# cd /var/opt/SunWdsee/ds-inst-ds1
-
Stop the Directory Server instance.
# ./stop-slapd
-
Export the current state of the pstest directory to an ldif file.
# ./db2ldif -n pstest
The output should resemble the following:
ldiffile: /var/opt/SunWdsee/ds-inst-ds1/ldif/2008_05_20_140750.ldif [20/May/2008:14:07:56 +0100] - export pstest: Precessed 1000 entries (26%) ... [20/May/2008:14:08:02 +0100] - export pstest: Precessed 4165 entries (100%)
-
Rename the ldif file to something meaningful.
# mv /var/opt/SunWdsee/ds-inst-ds1/ldif/2008_05_20_140750.ldif /var/opt/SunWdsee/ds-inst-ds1/ldif/ps_module_complete.ldif
-
Restart the Directory Server instance.
# ./start-slapd
- © 2010, Oracle Corporation and/or its affiliates