test

Sun Java System Portal Server 7.1 Deployment Planning Guide

Chapter 6 Implementing Your Deployment Design

During the implementation phase of the solution life cycle you work from specifications and plans created during deployment design to build and test the deployment architecture, ultimately rolling out the deployment into production.

Implementation is beyond the scope of this guide, however this chapter describes how to monitor and tune a deployment prototype.

This chapter contains the following sections:

About Implementing Deployment Designs

After the deployment architecture has been approved and implementation specifications and plans have been completed, you enter the implementation phase of the solution life cycle. Implementation is a complex set of processes and procedures that requires careful planning to ensure success.

Implementation includes the following tasks:

Details of implementation are beyond the scope of this guide. However, the following sections provide overview information for some of these tasks.

Documenting the Portal

A comprehensive set of documentation on how your portal functions is an important mechanism to increasing the supportability of the system. The different areas that need to be documented to create a supportable solution include:

The run book outlines troubleshooting techniques as well as the deployment life cycle. Make this book available during the training and transfer of knowledge phase of the project.

Tip –

Do not wait until the end of the deployment project to begin this documentation phase. Documenting your portal should occur as an ongoing activity throughout the entire deployment.

Developing a Portal Prototype

ProcedureTo Develop a Portal Prototype

  1. Identify and remove obvious bottlenecks in the processor, memory, network, and disk.

  2. Setup a controlled environment to minimize the margin of error (defined as less than ten percent variation between identical runs).

    By knowing the starting data measurement baseline, you can measure the differences in data performance between sample gathering runs. Be sure measurements are taken over an adequate period of time and that you are able to capture and evaluate the results of these tests.

    Plan to have a dedicated machine for generating load simulation which is separate from the Portal Server machine. A dedicated machine helps you to uncover the origin of performance problems.

  3. Define a baseline performance for your deployment, before you add in the full complexity of the project.

  4. Using this initial benchmark, define the transaction volume your organization is committed to supporting in the short term and in the long run.

    Determine whether your current physical infrastructure is capable of supporting the transaction volume requirement you have defined.

    Identify services that are the first to max out as you increase the activity to the portal. This indicates the amount of headroom you have as well as identify where to expend your energies.

  5. Develop and refine the prototype workload that closely simulates the anticipated production environment agreed between you and the portal administrators and portal developers.

  6. Measure and monitor your traffic regularly to verify your prototype.

    Track CPU utilization over time. Load usually comes in spikes and keeping ahead of spikes involves a careful assessment of availability capabilities.

    Most organizations find that portal sites are “sticky” in nature. This means that site usage grows over time, even when the size of the user community is fixed, as users become more comfortable with the site. When the size of the user community also grows over time a successful portal site can see a substantial growth in the CPU requirements over a short period of time.

    When monitoring a portal server’s CPU utilization, determine the average web page latency during peak load and how that differs from the average latency.

    Expect peak loads to be four to eight times higher than the average load, but over short periods of time.

  7. Use the model for long-range scenario planning. The prototype can help you understand how dramatically you need to change your deployment to meet your overall growth projections for upcoming years.

  8. Keep the error logging level to ERROR and not MESSAGE. The MESSAGE error level is verbose and can cause the file system to quickly run out of disk space. The ERROR level logs all error conditions and exceptions.

  9. Monitor customized portal applications such as portlets.

  10. Monitor the following areas.

    • Portal Desktop

    • Channel rendering time

    • Sun JavaTM System Access Manager

    • Sun Java System Directory Server

    • Sun Java System Virtual Machine

    • Web container

    The following sections explain issues in terms of portal performance variables and provides guidelines for determining portal efficiency.

Access Manager Cache and Sessions

The performance of a portal system is affected to a large extent by the cache hit ratio of the Access Manager cache. This cache is highly tunable, but a trade-off exists between memory used by this cache and the available memory in the rest of the heap.

You can enable the amSDKStats logs to monitor the number of active sessions on the server and the efficiency of the Directory Server cache. These logs are located by default in the /var/opt/SUNWam/stats directory. Use the com.iplanet.am.stats.interval parameter to set the logging interval. Do not use a value less than five (5) seconds. Values of 30 to 60 seconds give good output without impacting performance.

The com.iplanet.services.stats.directory parameter specifies the log location, whether to a file or to the Portal Server administration console, and also is used to turn off the logs. You must restart the server for changes to take effect. Logs are not created until the system detects activity.

Note –

Multiple web container instances write logs to the same file.

The cache hit ratio displayed in the amSDKStats file gives both an internal value and an overall value since the server was started. Once a user logs in, the user’s session information remains in cache indefinitely or until the cache is filled up. When the cache is full, oldest entries are removed first. If the server has not needed to remove a user’s entry, it might be the case that on a subsequent login—days later, for example—the user’s information is retrieved from the cache. Much better performance occurs with high hit ratios. A hit ratio of a minimum of 80 percent is a good target although (if possible) an even higher ratio is desired.

Thread Usage

Use the web container tools to monitor the number of threads being used to service requests. In general, the number of threads actually used is generally lower than many estimates, especially in production sites where CPU utilization usually is far less than 100 percent.

Portal Usage Information

Portal Server does include a built-in reporting mechanism to monitor portal usage information by portal users. This includes which channels are accessed, how long the channels are accessed, and the ability to build a user behavioral pattern of the portal. Portal monitoring can be administered using the psconsole or cli psadmin. The following monitoring capabilities are possible:

User Based Tracking (UBT) is also administered using the psconsole or cli psadmin. UBT is disabled by default. To enable user based tracking, set property com.sun.portal.ubt.enable=true in file /var/opt/SUNWportal/portals/portal1/config. The level INFO, FINE, FINER, FINEST, OFF controls extent of data captured. Logs are routed to a file: /var/opt/SUNWportal/portals/portal1/logs/%instance/ubt.%u.%g.log which is configurable.

Identity and Directory Structure Design

A major part of implementing your portal involves designing your directory information tree (DIT). The DIT organizes your users, organizations, suborganizations into a logical or hierarchical structure that enables you to efficiently administer and assign appropriate access to users.

The top of the organization tree in Access Manager is called dc=fully-qualified-domain-name by default, but can be changed or specified at install time. Additional organizations can be created after installation to manage separate enterprises. All created organizations fall beneath the top-level organization. Within these suborganizations other suborganizations can be nested. The depth of the nested structure is not limited.

Note –

The top of the tree does not have to be called dc. Your organization can change this to fit its needs. However, when a tree is organized with a generic top, for example, dc, then organizations within the tree can share roles.

Roles are a grouping mechanism designed to be more efficient and easier to use for applications. Each role has members, or entries that possess the role. As with groups, you can specify role members either explicitly or dynamically.

The roles mechanism automatically generates the nsRole attribute containing the distinguished name (DN) of all role definitions in which the entry is a member. Each role contains a privilege or set of privileges that can be granted to a user or users. Multiple roles can be assigned to a single user.

The privileges for a role are defined in Access Control Instructions (ACIs). Portal Server includes several predefined roles. The Portal Server administration console enables you to edit a role’s ACI to assign access privileges within the Directory Information Tree. Built-in examples include SuperAdmin Role and TopLevelHelpDeskAdmin roles. You can create other roles that can be shared across organizations.

Creating a Custom Access Manager Service

Service Management in Access Manager provides a mechanism for you to define, integrate, and manage groups of attributes as an Access Manager service.

Readying a service for management involves:

See the Sun Java System Portal Server 6 Secure Remote Access 2005Q4 Administration Guide, Sun Java System Directory Server Enterprise Edition 6 2006Q1 Deployment Planning Guide and the Access Manager Deployment Guide for more information on planning your Access Manager and Directory Server structure.

Portal Desktop Design

The performance of Portal Server largely depends upon how fast individual channels perform. In addition, the user experience of the portal is based upon the speed with which the Portal Desktop is displayed. The Portal Desktop can only load as fast as the slowest displayed channel. For example, consider a Portal Desktop composed of ten channels. If nine channels are rendered in one millisecond but the tenth takes three seconds, the Portal Desktop does not appear until that tenth channel is processed by the portal. By making sure that each channel can process a request in the shortest possible time, you provide a better performing Portal Desktop.

Choosing and Implementing the Correct Aggregration Strategy

The options for implementing portal channels for speed and scalability include the following.

Working with Providers

Consider the following when planning to deploy providers:

Software Deployment

This section provides information on the software packaging mechanism, the software categories within the system, and compatibility with Java software.

Software Packaging

Portal Server uses a “dynamic WAR file” approach to deploy software to the system. Portal Server is installed using SolarisTM packages, which consist of individual files that comprise web applications, for example, JAR, JSP, template, and HTML files. The packages do not contain WAR or EAR files. The packages do contain web.xml fragments that are used to construct the Portal Server WAR file at installation time. This dynamically constructed file is then deployed to the web application container. As additional packages are added to the system, for example, for localization, the web application file is rebuilt and redeployed.

Note –

The WAR file packaging and deployment mechanism is for use only by Portal Server products. Customer modifications to the WAR file or any files used to build it are currently not supported.

Software Categories

Portal Server distinguishes between the following kinds of software that it installs onto the Portal Server node:

Note –

Static web content and dynamic web applications are all grouped together into a single WAR file.

Compatibility With Java Software

Portal Server software falls into three categories:

Client Support

Portal Server supports the following browsers as clients:

Multiple client types, whether based on HTML, WML, or other protocols, can access Access Manager and hence Portal Server. For this functionality to work, Access Manager uses the Client Detection service (client detection API) to detect the client type that is accessing the portal. The client type is then used to select the portal template and JSP files and the character encoding that is used for output.

Note –

Currently, Access Manager defines client data only for supported HTML client browsers, including Internet Explorer and Netscape Communicator. See the Access Manager documentation for more information.

Sun Java System Portal Server Mobile Access software extends the services and capabilities of the Portal Server platform to mobile devices and provides a framework for voice access. The software enables portal site users to obtain the same content that they access using HTML browsers.

Mobile Access software supports mobile markup languages, including xHTML, cHTML, HDML, HTML, and WML. It can support any mobile device that is connected to a wireless network through a LAN or WAN using either the HTTP or HTTPS protocol. In fact, the Portal Server Mobile Access software could support any number of devices, including automobiles, set-top boxes, PDAs, cellular phones, and voice.

Content and Design Implementation

The Portal Desktop provides the primary end-user interface for Portal Server and a mechanism for extensible content aggregation through the Provider Application Programming Interface (PAPI). The Portal Desktop includes a variety of providers that enable container hierarchy and the basic building blocks for building some types of channels. For storing content provider and channel data, the Portal Desktop implements a display profile data storage mechanism on top of an Access Manager service.

The various techniques you can use for content aggregation include:

See the Sun Java System Portal Server 7.1 Secure Remote Access Administration Guide and Sun Java System Portal Server 7.1 Developer Sample Guide for more information.

Placement of Static Portal Content

Place your static portal content in the web-container-instance-root/ https-server/docs directory or in a subdirectory under the web-container-instance-root/directory/https-server/docs (the document root for the web container). Do not place your content in the web-container-instance-root/SUNWportal/web-apps/https-server/portal/ directory, as this is a private directory. Any content here is subject to deletion when the Portal Server web application is redeployed during a patch or other update.

Integrating Applications

Integrating and deploying applications with Portal Server is one of your most important deployment tasks. The application types include:

Integrating Microsoft Exchange/Sun Java System Messaging Server

Using the JavaMailTM API is one of the primary options for integrating Microsoft Exchange messaging server with Portal Server. The JavaMail API provides a platform independent and protocol independent framework to build Java technology-based mail and messaging applications. The JavaMail API is implemented as a Java optional package that can be used on JDK 1.4 and later on any operating system. The JavaMail API is also a required part of the Java Platform, Enterprise Edition (Java EE).

JavaMail provides a common uniform API for managing mail. It enables service providers to provide a standard interface to their standards based or proprietary messaging systems using Java programming language. Using this API, applications can access message stores and compose and send messages.

Independent Software Vendors

Listed below are some types of independent software vendor (ISV) integrations.

Note –

Portal Server 7.1 is reliant on using the amsdk. Limited Realm Mode support is possible, however by default portal 7.1 will install in legacy mode. Sun One Java Directory Server 6 is supported and any LDAPv3 directory server.

The “depth” to which user interface integration occurs with Portal Server indicates how complete the integration is. Depth is a term used to describe the complementary nature of the integration, and points to such items as:

In general, the degree to which an application integrates in Portal Server can be viewed as follows:

Rolling Out a Production Deployment

Once the pilot or proof-of-concept deployment passes the test criteria, you are ready to roll out the deployment to a production environment. Typically, you roll out to a production environment in stages. A staged rollout is especially important for large deployments that affect a significant number of users.

The staged deployment can start with a small set of users and eventually expand the user base until the deployment is available to all users. A staged deployment can also start with a limited set of services and eventually phase in the remaining services. Staging services in phases can help isolate, identify, and resolve problems a service might encounter in a production environment.